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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf