Hi, Ben,
Sorry for the late reply, hope to close on all comments; please see
inline.
-----Original Message-----
[...]
[PART-II]
Nits/editorial comments:
-- General:
I understand that, and I hope I didn't come off too critical.
I know that it is very hard to make a draft that is both
readable and correct, particularly when you have so many use
cases that require different application behavior.
[Ahmad]
Not at all. I thank you much for the thorough review and comments!
-- Same paragraph, last sentence:
Do you mean "user" or "mobile node"?
[Ahmad]
I meant the user, because if the reason, administrative, then it
probably requires the user intervention.
Interesting. I assume there are cases where a typical mobile
node would just quietly reestablish the binding. I gather you
expect cases where it can't do so without some (possibly
reconfiguration) effort on the user's part, right? It's worth
thinking about whether there is some guidance you can give to
implementors here. (I'm not sure there is--just something to
think about.)
[Ahmad]
Probably we can allow it to be applicable to the user and mobile node.
What about if we just state "This mechanism enables the user or the
mobile node to react ...... "
-- S3.4.1, first paragraph, first sentence:
Unclear sentence: What is doing the "hosting"? The LMA,
the MAG, or
the BRI message? I think you mean the MAG, but the
sentence structure
is ambiguous.
[Ahmad]
What about the following?
"
The local mobility anchor may send a Binding Revocation Indication
message with the appropriate revocation trigger value to
the mobile
access gateway which hosts a specific PMIPv6 binding to indicate
that
the mobile node binding has been terminated and the mobile access
gateway
can clean up the applicable resources.
s/which/that, but otherwise I think it works.
[Ahmad]
Ok.
-S 7.1, first paragraph: "node, initiator, constructs"
Confusing sentence structure. Is "initiator" a name for
the sending
mobility node? If so, it would help to use it later
[Ahmad]
Sure. Will remove it.
Actually, I meant to propose you keep it, so that you could
simplify later sentences. For example, you could substitute
"The initiatior"
for "The mobility node that sends a Binding Revocation
Indication message".
[Ahmad]
Ok.
(the next paragraph uses the same structure again.)
-- 2nd paragraph: "In the BRI message, the initiator MUST set the
Sequence Number field to the next sequence number available for
Binding Revocation"
Does this conflict with the section 6.1 statement that it
"could be
random"
[Ahmad]
I do not see a conflict with sec 6.1. If the sequence random is set
using a random generator, then the next sequence number is
random too.
I think there is some danger that an implementor will be
confused by the words "sequence" and "next" for something
that is not necessarily sequential. I gather you don't care
how the implementation selects this number as long as there
are no collisions, right?
[Ahmad]
Yes.
It might be helpful to have a
sentence or two that say that--as "it could be random"
doesn't fully explain that you expect this to be local policy.
[Ahmad]
Sure.
More importantly, this implies a requirement that the
responder MUST NOT attempt to infer meaning from the sequence
numbers--for example, out-of-sequence numbers are
meaningless.
[Ahmad]
True. The use of the sequence number is to enable the initiator to match
the BRA with the outstanding associated BRI. Since the chance of having
more than one outstanding BRI, we MUST make sure that there is no
collision.
Also, if an implementation chose to use
sequential values, does it have to worry about rollovers?
[Ahmad]
No.
Does the potential guess-ability of a sequence number have
security implications?
[Ahmad]
Not at all. Packet must pass IPsec authentication first.
-- Same Paragraph: "Since sending Binding Revocation Indication
message is not done on a regular basis, a 16 bit sequence number
field is large enough to allow the initiator to match the Binding
Revocation Acknowledgement to the outstanding Binding Revocation
Indication with Acknowledge
(A) bit set using the sequence number field only."
Sentence is hard to follow. I suggest separating the idea that you
can match BRAs to BRIs with a 16 bit sequence number from the idea
that you only get a BRA if the BRI had it's A bit set.
[Ahmad]
Sure. What about the following:
"Since sending Binding Revocation Indication message is not
done on a
regular basis, a 16 bit sequence number field is large
enough to allow
the initiator to match the Binding Revocation
Acknowledgement to its
outstanding Binding Revocation Indication that had the
Acknowledge (A)
bit set."
Actually, I think the point would be clearer if you dropped
the part about the A bit entirely--that is sufficiently
spelled out elsewhere.
For example:
"Since sending a Binding Revocation Indication message is not
done on a regular basis, a 16-bit field is large enough to
allow the initiator to match a Binding Revocation
Acknowledgement to its associated Binding Revocation Indication.
[Ahmad]
Ok. Thx.
[...]
-- S7.2, paragraph 2: "Since some mobility entities, e.g.,
local mobility anchor and mobile access gateway, are allowed
to receive and possibly send a Binding Revocation Indication
or Binding Revocation Acknowledgement for different cases,
therefore, if IPsec is used to secure signaling between the
local mobility anchor and mobile access gateway, it prevents
any of them from processing a Binding Revocation message that
was not constructed by an authorized party."
I have trouble parsing this sentence.
(You did not respond to this one.)
[Ahmad]
We basically wanted to say that since the MAG and LMA are both allowed
to send BRI and receive BRA, IPsec will enable the peer to detect if a
man in the middle, for example, reflected a BRI message that it has
initiated back to the peer and consequently silently drop that BRI
message. In the broader sense, we wanted to say that IPsec enables any
of the peers to detect if the received BRI is coming from an
unauthorized party and consequently ignore without processing it.
I hope we got it right:)
-- Paragraph 3: "Upon receiving a packet carrying a Binding
Revocation Indication or Binding Revocation Acknowledgement,
the receiving mobility entity verifies that the packet was
received protected with the security association that has
been used during the binding registration signaling phase,
e.g., an IPsec SA."
Normative?
[Ahmad]
Sure. Will use "MUST verify". To make it clearer, what about the
following:
"
Upon receiving a packet carrying a Binding Revocation
Indication or
Binding Revocation Acknowledgement, the receiving mobility entity
MUST verify that the packet was received protected with
the security
association that is being used for the protection of the binding
registration signaling between the two peers, e.g., an IPsec SA.
"
Hopefully this clarifies the question related "if SA has
been renewed
etc."
It helps, but it's still a little vague. Do you mean to say that (at
least for the non-G bit case), that the BRI can only revoke bindings
that were established on the same SA?
[Ahmad]
No. this is applicable to all BRI messages regardless if it is Global or
per-MN.
Or that the BRI can
only be sent
on an SA where some binding registration signaling has occurred?
[Ahmad]
What we meant here is any SA that is currently used for protecting BU/BA
and BRI/BRA message (i.e., SPD allows all MH for BU/BA and Binding
Revocation Message) between the two peers.
[...]
-- 4th bullet: "unless an Alternate Care-of Address mobility
option is included"
In which case you do what?
[Ahmad]
Thanks! It is a long story:)
What it means here is the following:
The destination IP address of the packet is set to the care-of
address.
However, if the home agent include an Alternate care-of
address option
in the BRI, the destination IP address MUST NOT be set to
the care-of
address.
When the home agent is able to include an Alternate Care-of
Address in
the BRI? ONLY when the mobile node sends a BU message with the
Alternate
Care-of address included in the BU. If the MN include the Alternate
Care-of address inside the BU, the source IP address of the packet
carrying the BU is different than the IP address inside the
Alternate
Care-of address.
NOW: It depends on the home agent implementation:
1. The home agent can send the BRI message to the care-of address
regardless, if this care-of address received as the source IP
address of
the packet carrying the BU or inside the BU in the Alternate Care-of
address option.
2. If the home agent saves the source address of the packet
carried
the
BU in addition to the MN care-of address in the MN BCE,
then the home
agent can send the packet that carries the BRI message to
the source
IP
address of the packet that carried the BU.
3. Depends on implementation of the home agent, the home agent may
send
the BRI to the MN care-of address all the time.
The key point here is: If the HA include the Alternate
care-of address
inside the BRI, then the destination IP address of the
packet carrying
the BRI is set to the source IP address of the packet that
carried the
BU.
Are all of those choices interoperable?
[Ahmad]
Yes.
By default, when there is no Alternate Care-of address involved, the
client (MN/MAG) will always be able to process BRI messages that are
sent to the Care-of address.
If the client (MN/MAG) include Alternate Care-of address in the BU/PBU,
then the server will send the BA/PBA to the source IP address of the
packet that carried the BU/PBU. If the server saves the source IP
address in the MN BCE, then the server will send any BRI to the source
IP address and include the alternate care-of address in the BRI. That
should be fine with the client. If the server does not save the source
IP address in the MN BCE, the server will send the BRI to the care-of
address which was included in the alternate Care-of address in the
BU/PBU. That should be fine too.
All of this to avoid a long debate and allow all options to exist
without mandating one or the other.
That's a bit of a red flag:-) Adding flexibility for its own
sake, or
just because the work group has trouble picking something, is often
bad for interoperability. I guess the answer to my interop question
above will indicate whether that is a problem in this
specific case or
not.
[Ahmad]
Please see answer above.
But in any case, I think you need at least some guidance. Right now,
you have a conditional MUST without an "else" clause for that
condition. A simple ..., in which case, the destination
address SHOULD
(or MAY) be set to <something>.
[Ahmad]
Here is the new text:
"
o The care-of address for the binding MUST be used as the
destination address in the packet's IPv6 header, unless an
Alternate Care-of Address mobility option is included in the
Binding Revocation Indication. If an Alternate Care-of Address
option is included in the Binding Revocation Indication message,
the destination address in the packet's IPv6 header SHOULD be set
to the source IP address of the packet that carried the latest
successful Binding Update with the Alternate Care-of address
included.
"
[...]
-- S9.1.1, third bullet: "The Revocation Trigger may be used
by the mobile access gateway to learn the mobile node's
latest movement."
I don't understand what you mean here.
[Ahmad]
The Revocation Trigger has some values like: Inter-MAG handover Same
access type, inter-MAG handover different access type, etc.
When the
MAG
receives a such BRI, the MAG learns something about the MN
movement
and
may verify if the MN is still attached or not.
Okay, so "learning something about it's movement" really means
something like "learning that it moved" and maybe "why it moved",
right?
[Ahmad]
Yes.
Not necessarily where it moved to, etc.
[...]
-- last bullet: "unless an Alternate Care-of Address mobility
option is included in the Binding Revocation Indication message."
in which case do what?
[Ahmad]
The same comment as the one under 4th bullet of S8.1.
Same response :-)
[Ahmad]
Same text as the one above will be added to this bullet.
-- 2nd bullet: "If the Global (G) bit is set and the
Revocation Trigger value is "Per-Peer Policy", the Proxy (P)
bit MUST be set and the Binding Revocation Indication SHOULD
contain the mobile access gateway ID in the MN-ID option."
What if it's not?
[Ahmad]
If the MN-ID option is not included, the LMA will not be able to
verify
whether the MAG is authorized to use Global revocation or
not. In this
case, the LMA sends a BRA with status code "Global Revocation NOT
Authorized".
I think it would be helpful to say that in the draft.
[Ahmad]
Ok.
Also, the language here sounds more like
you are talking about the initiator. The responder validates
these are true, but does not set the values, correc"t"
[Ahmad]
True. Will reword it.
[...]
-- Bullet 5:
Why not MUST?
[Ahmad]
Good question. Since the sub-bullets include the proper normative, I
believe we can remove "SHOULD" and rely on the sub bullet normative
text.
"
o If the Global (G) bit is NOT set, the local mobility
anchor uses
the included mobility options to identify the impacted mobile
node binding as follows:
"
Hmm, I don't see any normative statement in that sub-bullet.
(The all-
caps NOT is in a condition clause, not a normative statement--and
therefore probably should not be all-caps.)
[Ahmad]
Are you saying the text in the sub-bullets is not normative?
-- S 10.1.1, paragraph 1: "MUST validate the packet
according to Section 7.2 and the following"
Much of "the following" involves things well beyond validation.
[Ahmad]
Sure, what about "MUST process"?
I think that helps.
[Ahmad]
Ok.
-- 4th bullet: "which SHOULD include at least the MN-ID option"
What if it doesn't?
[Ahmad]
The MAG should silently discard the BRI.
It's worth saying that (unless already covered elsewhere.) (Also, my
previous comments about silent discard interaction with A-bit
probably
applies :-) )
[Ahmad]
Will check and if it is not included, will add it here.
"Binding Revocation Message"
Can you include a URL pointing to the table that this is to
be inserted into?
"new name space"
Where does the new name space go? Can you offer a URL to the
registry for it? (applies to all 3 name spaces)
Also, in the various name spaces, do you want a column
indicating what RFC or other document specifies a given value?
[Ahmad]
Yes. IANA has already created those fields as needed. Do you think
that
we still need a URL, etc.?
Maybe not, if IANA was okay with it. The important thing now is to
make sure the authors of any future extensions that add things to
those name spaces can properly identify where to put them.
[Ahmad]
Ok. Thanks again!
[...]
Thanks!
Ben.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf