|
Re: [PART-II] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
2009-08-27 18:12:23
Thanks for the response. Comments inline. I will remove sections where
I think we are in agreement.
On Aug 27, 2009, at 3:08 AM, Ahmad Muhanna wrote:
Hi Ben,
Please see answers in line for PART-II.
-----Original Message-----
From: Ben Campbell [mailto:ben(_at_)estacado(_dot_)net]
Subject: Gen-ART LC and Telechat Review of
draft-ietf-mext-binding-revocation-10
[...]
[PART-II]
Nits/editorial comments:
-- General:
This draft has some significant organization issues that make
it harder to read than it needs to be. In particular, the
sections that discuss protocol details keep repeating text
that is effectively the same for each type of device. It
would be much easier to read if you did things like separate
out acknowledgement handling, race condition handling,
binding identification, retransmissions, handovers, etc into
their own sections, and have the sections on specific device
roles only discuss things specific to those devices. You have
some of the common bits separated out, but you still repeat
them over and over in the role specific sections. Not only is
this hard to read, it is prone to error.
[Ahmad]
Thanks. I appreciate this comment.
Will make every effort to correct any error or unnecessary
duplication.
It may be worth noting that describing a protocol which handles the
interactions of several entities and usecases that are established
using
different protocols is not the easiest job ever:)
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.
As an example, I found that this structure confused my
attempts to understand when an acknowledgement is required.
Some sections said "if the Acknowledge bit was set", but
other sections that did not mention the A bit also required
acknowledgement.
[Ahmad]
I think we discussed this in PART-I and will follow up on your
follow-up
comments after addressing all of PART-II comments.
Agreed.
The sentence structure tends to be very long and wordy, with
very little punctuation. This is aggravated by the fact that
you don't make use of the acronyms and device role names once
you establish them. For example, spelling out phrases like
Binding Revocation Indication and Local Mobility Anchor every
time they are used makes for very long sentences.
[Ahmad]
I see what you are saying. However, we are trying to follow the
style of
main IP mobility protocols specifications. It seems that there are two
styles for doing this. One is to always use acronyms as soon as they
are
established. TWO: do not use acronyms except in figures and tables, if
they exist and text related to them. I personally prefer a combination
of these two styles but the comments we received earlier during the
development of this specification is to use one or the other:)
Okay. Believe it or not, I usually gripe about too many acronyms :-)
[...]
-- 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.)
-- 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.
"
-- same paragraph: "In this case, the mobile access gateway
could send a Router Advertisement message to the mobile node
with the home network prefix valid lifetime set to zero."
In order to accomplish what?
[Ahmad]
Since in PMIPv6, the MN does not participate in any mobility
signaling,
the mobile node is not aware that the advertised HNP is not anchored
at
the MAG. So, when the MAG receives a BRI for a specific binding, i.e.,
specific HNP binding to the current pCoA, the MAG clears associated
resources; but until the mobile node receives such Router
Advertisement,
it wont know that it CAN not use this HNP.
Okay.
-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".
(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? 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.
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. Also, if an implementation
chose to use sequential values, does it have to worry about rollovers?
Does the potential guess-ability of a sequence number have security
implications?
-- 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.
[...]
-- 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.)
-- 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? Or that the BRI can only be sent
on an SA where some binding registration signaling has occurred?
[...]
-- 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?
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.
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>.
[...]
-- 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? 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 :-)
-- 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.
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.)
-- 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.
-- 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 :-) )
(and this seems like a strange place for
a normative SHOULD, as we are talking about responder
behavior not initiator behavior.)
[Ahmad]
Will reword it to say: If only the MN-ID is included, ...
Will also check to see if a normative text is needed under the MAG
being
a sender and fix it accordingly.
Okay.
-- 5th bullet: "The mobile access gateway SHOULD validate
that the mobile node is no longer attached to the mobile
access gateway before sending a successful Binding Revocation
Acknowledgement message to the local mobility anchor.
However, if the mobile access gateway verified that the
mobile node is still directly attached, the mobile access
gateway MUST set the status field in the Binding Revocation
Acknowledgement to "Revocation failed - MN is Attached"."
These two sentences seem to contradict each other. I think
you mean to check if the node is attached, then do one thing
if not and another thing if it is.
[Ahmad]
That is what the text supposed to mean. Will replace the word
"validate"
by "ensure" for the bullet to read as follows:
"
o If the Revocation Trigger field value in the received Binding
Revocation Indication message indicates inter-MAG handover, e.g.,
Inter-MAG Handover - Unknown, and the Acknowledge (A) bit is set,
the mobile access gateway uses the mobility option(s) included in
the Binding Revocation Indication message to identify the mobile
node binding. The mobile access gateway SHOULD ensure that the
mobile node is no longer attached to the mobile access gateway
before sending a successful Binding Revocation Acknowledgement
message to the local mobility anchor. However, if the mobile
access gateway verified that the mobile node is still directly
attached, the mobile access gateway MUST set the status field in
the Binding Revocation Acknowledgement to "Revocation failed - MN
is Attached.
"
Actually, I think the problem is I missed the word "successful" in
"successful BRA". I read it as "don't send a response unless A is
true, in which case you send a response" :-) That was a reading
error on my part.
[...]
"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.
[...]
Thanks!
Ben.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|