I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-mext-binding-revocation-10
Reviewer: Ben Campbell
Review Date: 25 Aug 2009
IESG Telechat date: 27 Aug 2009
Note: I was assigned to review revision 08 of this draft for the
last call ending 28 Aug, as well as this version (10) for the 27 Aug
Telechat. This review serves both purposes.
Summary: This draft is on the right track, but there are open
issues. Additionally, I have a number of editorial comments.
Major issues:
-- I think the security considerations need quite a bit of work. In
particular, there is very little guidance on authorization for
sending BRI messages. This seem to me have utility for DoS attacks,
particularly with the G bit set. There is mention of reusing
existing security associations if IPSec is used--but no mention of
what to do if IPSec is not used. (Perhaps it is required by the
underlying technology? If so, that should be mentioned here.) You
mention that authorization is required if the G-bit is set, but go
on to say authorization details are out of scope. I think that this
draft needs to either offer much more guidance on authentication
requirements. It would be helpful if the Security Considerations
section discussed the consequences of security failures, possible
attacks, etc.
Minor issues:
-- S3.4.2, paragraph 1: "responds with the appropriate status code
by sending a Binding Revocation Acknowledgement message"
Always, or just if the A bit is set?
-S4, paragraph 2: "verify that the mobile access gateway sending the
binding revocation indication message is authorized to invoke global
revocation"
How does it make such a verification?
-S5, second paragraph: "UDP encapsulation to traverse NATs"
Can you include a reference for UDP encapsulation?
-- Same Paragraph: "... port numbers ... will also be used"
Should this be normative?
-- Same paragraph, sentence starting with "For example..."
I don't think it's appropriate to include a normative statement
inside an "example". You could fix this by swapping the descriptive
language in the previous sentence with the normative language in the
"example".
-- Section 7.2, last paragraph: "If a mobility node receives a
Binding Revocation Indication message with a Revocation Trigger
value that is NOT in line with the Binding Revocation Indication
message intent, e.g., the Global (G) bit set and the Revocation
Trigger field vale is a per-MN specific, the receiving mobility node
SHOULD reject the Binding Revocation Indication message by sending a
Binding Revocation Acknowledgement message with the Status field set
to "Revocation Function NOT Supported"."
This paragraph seems to imply some under-specification around how to
tell the Revocation Trigger value is not in line with the
initiator's intent.
Also, do you really mean to send "... not supported"? This really
sounds like more of a "bad request" scenario.
Did you mean to capitalize the final "NOT"?
-- Section 7.3:
RFC3775 already talks about retransmission for Binding Update
messages. Does this really need to be specified separately?
-- 2nd paragraph: "SHOULD retransmit"
Can you offer guidance on when an implementation might reasonably
not do this? (i.e. why not a MUST?)
-- S8.1, 3rd para after bullets: "home agent SHOULD handle this case
based on the reason for sending the Binding Revocation Indication
message and its local policy"
Is this entirely local policy? Is there no guidance to offer about
how the "reason for sending" the BRI influences this decision? If
it's really just local policy, then I'm not sure you need a
normative statement (i.e. you SHOULD do whatever you choose to do...)
-- Last para: "SHOULD NOT"
Why not MUST NOT?
-- S 10.1.1, third bullet: "MUST send a Binding Revocation
Acknowledgement"
So the G bit and the revocation trigger field value of "per-peer
policy" is enough to require a BRA? Wouldn't this only apply when
the A bit is set? (I know the initiator may have been required to
set the A bit, but it seems wrong to expect the responder to infer
that.)
-- S 11.1, bullet 2: "SHOULD send a Binding Revocation
Acknowledgement"
Can you document reasons why a responder might not send the BRA, and
the consequences thereof? In particular, are there scenarios where
the initiator might go into retries because the responder chose not
to send a BRA?
-- same paragraph: "In all cases, the mobile node MUST follow
Section 11.2"
Do you really mean "in all cases"? This seems to contradict the
SHOULD in the previous sentence, and the "If the A bit is set"
condition in the first sentence in the paragraph.
-- Bullet 3: "mobile node MUST send"
Even if A bit is not set?
-- same bullet: "mobile node SHOULD send a Binding Revocation
Acknowledgement with the status field set to "Binding Does NOT Exist""
Even if A bit is not set?
-- Bullet 4: "MUST silently discard the Binding Revocation
Indication message"
Even if A bit is set?
-- S11.1, last paragraph: "could be used by the mobile node to
define what action"
I think this could use some more guidance, if you expect consistent
behavior across implementations.
-- S 11.2, 2nd bullet: "The mobile node MUST set the Status field to
an appropriate value. The mobile node sets the Status field to
success to reflect that it has received the Binding Revocation
Indication and acknowledge that its IP connectivity with its home
agent has been revoked"
I think this is under-specified. In particular, is the mobile node
allowed to set failure status values?
-- S 12: "BRI Maximum Number of Retries"
Why do you have both a max number of retries _and_ a max timeout? I
gathered from previous sections that retries stop after the backoff
hits max_brack-timeout. Did I read that wrong?
-- "initial minimum delay: "The default is 1 second but not less
than 0.5 seconds"
The default is a range? Or do you mean to say that the timer value
MUST not be set to less than 0.5 seconds?
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.
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.
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.
Please proof read the draft again. I found lots of missing articles
and plural/singular mismatches. I report a few of these below, but I
gave up on capturing them part way through. The RFC editor will
probably fix any of these that get through, but if you fix it
yourself, there is less danger of the meaning being changed by edits.
-- S1, paragraph 2:
Please expand MH on first use.
"notify its local mobility anchor peer with a bulk termination"
Does it really notify "with" a bulk termination, or "about" a bulk
termination?
-- S3: "describe the protocol overview"
s/describe/present
-- S3.1, paragraph 1:"the Acknowledge (A) bit is set"
The description seems to mix the two elements--the notification and
the request for acknowledgement. It might be easier to read and
understand if you separated out a single section on sending BRA
when the A bit is set, rather than repeating it for each scenario.
-- Paragraph 3: "On the other hand, the mobile access gateway
usually sends a de- registration message by sending a Proxy Binding
Update with a lifetime of zero to indicate to the local mobility
anchor of the termination of the PMIPv6 mobile node binding
registration."
Sentence logic is inverted. Suggest " ... indicate the
termination...to the local mobility anchor" This sentence structure
repeats throught the document. While the inverted form is not
technically wrong, it's difficult to read (for me, anyway).
-- Last Paragraph: "anchor, mobile access"
I suggest " ...anchor, or mobile access gateway..."
-- S3.2, first sentence
s/Binding.../The Binding...
-- Same paragraph, last sentence:
Do you mean "user" or "mobile node"?
-- S3.3, title:
s/"Multi-Care of"/"Multiple Care-of"
-- 3.4, first paragraph: "...where Binding Revocation mechanism is
needed..."
s/Binding/"The Binding"
-- 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.
-- 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?
-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 (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"
-- 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.
-- last paragraph: "A mobility entity MUST secure Binding Revocation
Indication and Binding Revocation Acknowledgement messages with the
same underlying security association, e.g., IPsec SA, that has been
used to secure the mobile node binding registration signaling."
You stated this normatively in section 4. Also, that section said
"if IPSec is used"--what if it's not?
-- 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.
-- 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?
-- paragraph 5: "value that NOT supported"
Normative NOT does not make sense here. I think you meant "... set
to a value that is not supported."
-- S 8.1, 2nd bullet: "The Revocation Trigger may be used by the
mobile node to take further steps if necessary"
I'm not sure what this means. More specification needed?
-- 4th bullet: "unless an Alternate Care-of Address mobility option
is included"
In which case you do what?
-- 1st paragraph after bullets: "terminating its IP connection"
What do you mean by terminating an IP connection?
-- 2nd para after bullets:
Please expand BCE on first use.
-- 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.
-- 7th bullet:
Please expand HNP on first use.
-- last bullet: "unless an Alternate Care-of Address mobility option
is included in the Binding Revocation Indication message."
in which case do what?
-- S 9.1.2, last bullet: "SHOULD examine mobility options"
What will it do with them? Is there more guidance that can be
offered, or is it entirely a matter "local policy"?
S 9.2.1, first bullet: "Binding Revocation Indication is formatted
as in Section 6.1"
Missing word(s)? Did you mean to say "Validate that..."
-- 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? 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
-- Bullet 5:
Why not MUST?
-- 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.
-- 4th bullet: "which SHOULD include at least the MN-ID option"
What if it doesn't? (and this seems like a strange place for a
normative SHOULD, as we are talking about responder behavior not
initiator behavior.)
-- 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.
-- S 10.1.2, title: "Sending Binding Revocation Acknowledgement"
The previous section said a lot about sending BRAs as well.
-- S 11.1, 5th bullet: "with this home address are being revoked"
s/are/as
-- bullet 6: "has multi Care-of Address bindings"
s/multi/multiple
-- same bullet: "consider all of its registered care-of addresses
bindings with this home address are being revoked"
s/are/as
-- IANA considerations: "<IANA-TBD>"
It's worth noting to the RFC editor to please replace this with the
actual value assigned by IANA.
"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?
-- References:
A later version (-15) exists of draft-ietf-netlmm-pmip6-ipv4-
support-14
_______________________________________________
Gen-art mailing list
gen-...@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
