Subject: RE: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 26 Aug 2009 03:58:16 -0500

Hi Ben,
Thanks for the detailed review and comments. 
Please allow me to address your comments in two parts. 

1. PART-I: Major and technical issues.
2. PART-II: remaining comments.

Please see answers inline for PART-I.

Regards,
Ahmad

> -----Original Message-----
> 
> 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. 
[Ahmad]
Binding Revocation is used between two peers to revoke/terminate a
mobility session(s) that have been created using an IPv6 mobility
protocol signaling (Client Mobile IPv6 or Proxy MIP6). RFC3775 and
RFC5213, which are the main protocols targeted by this specification,
specify that "IPsec SHOULD" be used. On the other hand, there is NO
other standard track specification which specify other security
mechanisms to secure the IPv6 mobility signaling. Therefore, Binding
Revocation specification assumes the use of whatever security mechanism
that currently available to secure the IPv6 mobility signaling.

> (Perhaps it is required by the underlying technology? 
> If so, that should be mentioned here.) 
[Ahmad]
That is not the intention. Please see above.

> 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. 
[Ahmad]
We could introduce a simple default mechanism inline with what we have
in RFC5213. 

> It would be helpful if the 
> Security Considerations section discussed the consequences of 
> security failures, possible attacks, etc.
> 
[Ahmad]
This specification do not introduce any security threats on the top of
what is being discussed in Client MIP6 and Proxy MIP6, RFC3775 and
RFC5213.

> 
> 
> 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?
[Ahmad]
This section describes the usecase when Global revocation is being used
by the MAG; there is no normative text in this section. In addition,
section 10.2.1. which talks about the use of the (G) bit by the MAG and
indicates that whenever the (G) bit is set the (A) bit MUST be set, is
correctly being referenced in this section and mentioned before the text
quoted above. 

> 
> 
> -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?
[Ahmad]
By checking the identity of the MAG if it is authorized for global
revocation or not. Would a reference to section 9.2.1. makes it clearer
or you think we need to add more clarification.

> 
> -S5, second paragraph: "UDP encapsulation to traverse NATs"
> 
> Can you include a reference for UDP encapsulation?
[Ahmad]
No problem.

> 
> -- 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".
[Ahmad]
Agreed. Will fix swap as suggested. Thanks.

> 
> -- 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"?
[Ahmad]
I thought it was a straight forward combination. If the Global (G) bit
is set, the Revocation trigger field value MUST contain one of the
Global revocation triggers. If the (G) bit is cleared, the revocation
trigger MUST contain a per-MN value. Any deviation, means this
functionality is not supported.

As far as why having "NOT" in capital letters, some drafts have the
whole cause value in capital letters, but it is also meant to say that
this is a bad request.

> 
> -- Section 7.3:
> 
> RFC3775 already talks about retransmission for Binding Update 
> messages. Does this really need to be specified separately?
> 
[Ahmad]
Yes. It is a separate protocol.
 
> -- 2nd paragraph: "SHOULD retransmit"
> 
> Can you offer guidance on when an implementation might 
> reasonably not do this? (i.e. why not a MUST?)
[Ahmad]
Since sending a BRI message is NOT a MUST to start with, I do not
believe that the retransmission needs to be mandated as a "MUST". A
strong recommendation using "SHOULD" gives more flexibility to the
initiator to retransmit based on the need and the scenario at hand. In
addition, I did not see anywhere in RFC3775 or RFC5213 where
retransmission is mandated.

> 
> -- 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...)

[Ahmad]
The intention here is to make sure that the home agent take in
consideration the reason for sending the BRI, i.e., Revocation Trigger
value and NOT to handle all of the BRI cases by applying a single
reaction. For example, if the Revocation Trigger value indicate an
administrative reason, then the HA probably have a lot of options for
handling such a case. On the other hand, an inter-MAG handover
Revocation Trigger value would probably require a more careful
consideration.

> 
> -- Last para: "SHOULD NOT"
> 
> Why not MUST NOT?
[Ahmad]

The problem we are trying to avoid here is: if we use "MUST NOT" then we
need to specify the behavior of the receiving node in case it receives a
BRI with all of the BID(s) included. Considering such case as an error
scenario is probably not the best way. Allowing it, then it is not "MUST
NOT" anymore.

> 
> -- 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.)
[Ahmad]
This case a little similar to the "SHOULD NOT" case above. If the (A)
bit is NOT set, what the receiving node should do. The intention is for
the MAG (responder) in the case of (G) revocation to always send the BRA
message.

> 
> -- 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?
[Ahmad]
Sure.
In this bullet it says that if the mobile node receives a BRI message
and the MN has an entry for the binding defined in the received BRI,
then the MN MUST send a BRA. In other words, if the MN successfully
process the BRI and still track this binding and still able to send a
BRA, then it MUST send a BRA. In all other circumstances, e.g., the MN
no longer tracking this binding, the MN received the BRI and before
processing the battery went down and no BRA is sent anyway, etc. The
whole idea is to make sure that the mandate on the mobile node is
reasonable and within the mobile node abilities to send a BRA.
Otherwise, we would like to offer the mobile node a reasonable excuse.

> 
> -- 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.

[Ahmad]
Yes. The bullet correctly reference section 11.2 which says:

"
11.2.  Sending Binding Revocation Acknowledgement

   When the mobile node receives a Binding Revocation Indication from
   its home agent, the mobile node processes the received Binding
   Revocation Indication as in Section 11.1.  If the mobile node is
   required to send a Binding Revocation Acknowledgement message in
   response to the received Binding Revocation Indication, the mobile
   node sends a packet to its home agent containing a Binding Revocation
   Acknowledgement according to the procedure in Section 7.1 and the
   following:
"

The key text is: "If the mobile node is required to send a BRA.." That
requirement is defined in the bullet you reference under section 11.1.

> 
> -- Bullet 3: "mobile node MUST send"
> 
> Even if A bit is not set?

[Ahmad]
Please see response to the comment about processing the BRI when the (G)
bit is set, as described above.

> 
> -- 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?
[Ahmad]
:)
As you said earlier, it is inferred that is being set but if it is not
being set, we need to specify the behavior of the MN. In this case, it
is very important for the MN to send a BRA message and inform the HA
that since BRI did not have the HoA IPv4 option, the MN can not identify
the impacted binding. This is to give the HA an indication that it needs
to resend BRI with the HoA IPv4 option included.

> 
> -- Bullet 4: "MUST silently discard the Binding Revocation 
> Indication message"
> 
> Even if A bit is set?
[Ahmad]
In other words, this is a fatal error. When the (P) bit is set, the MN
binding is for a proxy MIPv6 binding which SHOULD never be sent to the
MN but to a MAG. In this case, the MN should silently discard the
message.

> 
> -- 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.
> 
[Ahmad]
Thanks. This probably was intentionally left like it is because, it is
probably very difficult to get all implementations to agree on a common
behavior. However, the text was meant as a reminder to implementations
in order to take that in consideration.

> -- 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?
[Ahmad]
Yes, it could. E.g., if the MN received a BRI with Revocation Trigger
value set to: a non supported value or "8  Possible Out-of Sync BCE
State", the MN could send a BRA with status code set to failure.

> 
> -- 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?
[Ahmad]
May be the name is misleading. What the "Maximum BRA TIMEOUT" means is
the MAX time the initiator waits before it retransmits. Here is the
text, please let me know if you have any suggestions for modification.

"   
Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT)

      This variable specifies the maximum delay timeout in seconds
      before the revoking mobility entity retransmits a BRI message.
      The default is 2 seconds.
"

I will respond to the rest of the comments separately in order to make
it easier for audience to follow.
Many thanks again for the detailed comments.

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 27 Aug 2009 03:08:51 -0500

Hi Ben,
Please see answers in line for PART-II.

> From: Ben Campbell [mailto:[email-masked]] 
> Subject: Gen-ART LC and Telechat Review of
draft-ietf-mext-binding-revocation-10
> 
> 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.
> 

[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:)

> 
> 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.

> 
> 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:) 

> 
> Please proof read the draft again. 
[Ahmad]
Sure. Will try again. Appreciate your effort in finding some of them; I
should say many!

> 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.
[Ahmad]
Will do our best to catch the remaining ones.

> 
> -- S1, paragraph 2:
> 
> Please expand MH on first use.
[Ahmad]
Ok.
> 
> "notify its local mobility anchor peer with a bulk termination"
> 
> Does it really notify "with" a bulk termination, or "about" a 
> bulk termination?
[Ahmad]
Thx. Will use about.

> 
> -- S3: "describe the protocol overview"
> 
> s/describe/present
[Ahmad]
Ok.

> 
> -- 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..."
[Ahmad]
Ok. Thx.

> 
> -- S3.2, first sentence
> s/Binding.../The Binding...
[Ahmad]
Ok.

> 
> -- 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.

> 
> -- S3.3, title:
> 
> s/"Multi-Care of"/"Multiple Care-of"
[Ahmad]
Ok.

> 
> -- 3.4, first paragraph: "...where Binding Revocation 
> mechanism is needed..."
> 
> s/Binding/"The Binding"
[Ahmad]
Ok.

> 
> -- 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. 
"

> 
> -- 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.

> 
> -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.

> (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.

> 
> -- 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."

> -- 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?
[Ahmad]
Will follow on this in PART-I.

> 
> -- 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?
[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." 

> 
> -- 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."

[Ahmad]
Yes. Thx.

> 
> -- 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?
[Ahmad]
I think this is similar to the comment about S11.1. in PART-I. I assume
it is resolved.

> 
> -- 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.
All of this to avoid a long debate and allow all options to exist
without mandating one or the other.

One more clarification: when it says the "care-of address of the
Binding" it means the care-of address that the home agent is saving
inside the MN BCE.

> 
> -- 1st paragraph after bullets: "terminating its IP connection"
> 
> What do you mean by terminating an IP connection?
[Ahmad]
Removing the mobile node routing entry that associates the mobile node
HoA to the IP-in-IP tunnel pointing to the mobile node care-of address.
In other words, the MN will not be reachable using its HoA, Home
Address.

> 
> -- 2nd para after bullets:
> 
> Please expand BCE on first use.
[Ahmad]
Sure.

> 
> -- 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.

> 
> -- 7th bullet:
> 
> Please expand HNP on first use.
[Ahmad]
Sure.

> 
> -- 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.

> 
> -- 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"?

[Ahmad]
If the status is partial success, the MAG may include the HNP options of
the mobile nodes which failed revocation.  In the case of Binding Does
Not exist, the BRA may include the HoA, etc. It becomes useful, if the
LMA/HA per local policy is required to log the event, it could list
those mobile nodes HNP(s) or HoA.

> 
> 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..."
[Ahmad]
Yes. Thanks.

> 
> -- 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".

> 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:
"

> 
> -- 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"?

> 
> -- 4th bullet: "which SHOULD include at least the MN-ID option"
> 
> What if it doesn't? 
[Ahmad]
The MAG should silently discard the BRI.

> (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.

> 
> -- 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.
"
> 
> -- S 10.1.2, title: "Sending Binding Revocation Acknowledgement"
> 
> The previous section said a lot about sending BRAs as well.
[Ahmad]
Okay; will see if we can optimize.

> 
> -- 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
[Ahmad]
Sure.

> 
> -- same bullet: "consider all of its registered care-of 
> addresses bindings with this home address are being revoked"
> 
> s/are/as
[Ahmad]
Sure. Thx.

> 
> -- IANA considerations: "<IANA-TBD>"
> 
> It's worth noting to the RFC editor to please replace this 
> with the actual value assigned by IANA.

[Ahmad]
Sure.

> 
> "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.?

> 
> -- References:
> 
> A later version (-15) exists of 
> draft-ietf-netlmm-pmip6-ipv4-support-14
[Ahmad]
Sure; it came out after we published revision 10.

Once again,
Thanks a lot for the detailed and thorough review, we appreciate it!

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 27 Aug 2009 13:32:50 -0500

Hi, Ben,

> >> Summary: This draft is on the right track, but there are 
> open issues.
> 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.
> > [Ahmad]
> > Revocation specification assumes the use of whatever security 
> > mechanism that currently available to secure the IPv6 mobility 
> > signaling.
> 
> I think there are still a couple of issues here. First, Since 
> the underlying RFCs only specify IPSec at SHOULD strength, 
> this draft needs to discuss the consequences of not using it 
> for BRI. Depending on those consequences, it might be enough 
> to just warn implementors that, if you don't use IPSec, 
> certain bad things can happen. 
[Ahmad]
It is NOT expected that BRI/BRA will use a different security mechanism
than what is being used for securing IPv6 mobility signaling. Therefore,
in order to alert implementors of the danger if IPsec is NOT used, IMO,
that needs to be discussed in related IPv6 mobility specifications,
e.g., RFC3775 and RFC5213, which is already there. On the other hand, it
is very difficult to anticipate the criteria of other security
mechanisms that would possibly be used in the future to secure IPv6
mobility signaling and consequently BRI/BRA. 

> OTOH, it might be that BRI has 
> greater security risks than for 3775/5213, and you might (for 
> example) need to strengthen the IPSec requirement for BRI.
> 
> I admit to not being an expert on 3375/5213, so it may be 
> true that BRI is no riskier than the underlying 
> technology--but even if that is true I'd like to see some 
> discussion to support it.
[Ahmad]
Both IPv6 mobility signaling and BRI/BRA use the same IPv6 layer
signaling. I am not sure what impact the underlying technology has on
BRI./BRA that does not have on BU/BA.

> 
> Second, I think that there is probably more guidance needed 
> on authorization decisions even if you do use IPSec. For 
> example, do you assume that any trusted peer can remove any 
> binding? 
[Ahmad]
No. The revoking mobility entity revokes only those mobility session(s)
which are registered with it. No mobility node can revoke a mobility
session that is registered with a different trusted mobility node.

> Is a trusted peer only allowed to remove bindings 
> that it previously established using the same SA? 
[Ahmad]
I believe I addressed this via another comment earlier. The answer is
NO.

> If an SA is 
> torn down and a new one established, what authorization gets 
> inherited, if any? 
[Ahmad]
When the SA is torn down and a new one is established, the new SA is
valid for both BU/BA and BRI/BRA. In other words, the new SA will still
have the same SPD which allows the BU/BA and BRI/BRA messages, etc. If
your question is about authorization of Global revocation, that
authorization should be done separately.

> Do you assume that a peer that is trusted 
> to establish bindings is trusted for BRI? 
[Ahmad]
Of course. The node which initiated or granted the registration should
have the authority to revoke it. 
Do you see any problem there? 

> Do you need to 
> provision policies around these, and if so what are the moving parts?

[Ahmad]
The text under the security section was supposed to capture this. The
SPD should be updated to allow MH type of 'Binding Revocation message'.
If it is not enough, let us know what is missing and we can add/modify
as needed.

> >> 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.
> > [Ahmad]
> It's possible that might help--can you point to the section 
> of 5213 you have in mind? 

[Ahmad]
Section 4, paragraph 6.

> It might also be enough to have 
> more discussion on what an implementor needs to think about 
> to do authorization correctly. For example, does it make 
> sense to statically provision that a trusted peer can remove 
> any binding for "foo.com"? 
[Ahmad]
Sure, static configuration what RFC5213 has under section 4. However, in
our case, is the peer authorized to use Global Revocation or not. This
is not restricted to a certain realm but the restriction as mentioned
above to sessions that is hosted at the revoking mobility node.

> Is authorization policy 
> dynamically determined by prior actions (i.e. a peer can 
> revoke all bindings _it_ established for "foo.com", but not 
> bindings that another device established for "foo.com"?
[Ahmad]
That is the very fundamental requirement for this protocol.

> 
> Probably more than anything, it would help to discuss the 
> sort bad things that this authorization is intended to prevent.

[Ahmad]
Ok. We can elaborate and add some text here. Thx.

> That's a little hard to believe without some supporting text. Again,  
> this could be my lack of knowledge of IPv6 mobility talking. But for  
> example, do RFC3775 and/or 5213 already have something a 
> mechanism for  
> one mobility element to tell another to drop bindings in bulk?

[Ahmad]
Yes. For example, the client which has multiple Bindings (referenced by
different Binding IDs) could send a single message (de-registration, a
BU with lifetime zero) and request the server (HA) to delete all
bindings which belong to this Mobile node.  

> > by the MAG; there is no normative text in this section.
> 
> Understood (but I had similar questions in the normative sections).
> 
> > In addition,
> > section 10.2.1. which talks about the use of the (G) bit by 
> the MAG  
> > and
> > correctly being referenced in this section and mentioned 
> before the  
> > text
> > quoted above.
> 
> But this text talks about how you form a BRA, not how the initiator  
> formed the BRI. Would you expect a responder to just assume (without  
> checking) that the A bit was set if it sees a G-bit set? 
> 
> There's a lot of interaction between these bit settings that 
> make for  
> some pretty complicated state transitions. As described, it expects  
> the responder to infer the A bit value based on the G-bit value. It  
> would be much cleaner to to implement if it were defined so that the  
> responder always sends a BRA if the A bit is set, and never if it is  
> not.
> 
> As a thought experiment, how would you recommend an implementer to  
> handle the case where a responder got BRI with the G bit set 
> and the A  
> bit not set? (I'm not asking for the draft to specify 
> that--it's just  
> a discussion point.)
>
[Ahmad]
Ok. I guess to close on this issue, It is fair to require that the
responder send BRA only when the (A) bit is set. Because, also, if the
initiator did not set the (A) bit, it may very well not expecting a BRA
and possibly NOT saving the BRI as an outstanding one to start with.
Thanks; will make sure that is addressed as a global comment and will
make sure that all places are fixed.
 
> Actually, this is really more of a 9.2.1 issue. (I reviewed things  
> linearly.) I think a reference here would help, but note I 
> had similar  
> comments about 9.2.1 further down.
[Ahmad]
This should be addressed as part of the authorization clarification.

> The text indicated those as examples. Are they the only scenarios  
> where the trigger value can be out of line with the "intent"? 
[Ahmad]
The valid combinations are:

Global Revocation==>>> (G) bit set and Revocation Trigger = a Global
revocation trigger.
Per-MN Revocation ==>> (G) bit cleared and Revocation Trigger = a per-MN
revocation trigger.

> I guess  
> part of my problem is that "intent" is a vague term here. The  
> important thing is to make sure that all legal combinations are  
> specified. I think they may be later on (again, reviewing linearly),  
> but they are scattered around the draft.
[Ahmad]
The Global Revocation Triggers are defined under section 6.1.

> Okay.
> A MUST retransmit if you don't get the ack to a BRI does not in any  
> way imply MUST send a BRI.
[Ahmad]
A good point; but in RFC3775 and RFC5213 there is no MUST for
retransmission either.
For example under section 6.9.4 of RFC5213, it says:

"
   2.  If the mobile access gateway fails to receive a valid matching
       response for a registration or re-registration message within the
       retransmission interval, it SHOULD retransmit the message until a
       response is received.
"

> 
> In this case, my concern is that you have two ways to decide not to  
> send a retransmission--one is that the value of BRIMaxRetriesNumber  
> could be set sufficiently low (zero, I assume) to prevent  
> retransmissions. The second is that the implementator could 
> choose not  
> to honor the SHOULD, even if BRIMaxRetriesNumber has a higher value.  
> If you want to allow the latter, it would help to have some guidance  
> (or examples) about scenarios where this would make sense, and the  
> consequences of doing it.

[Ahmad]
I believe 'SHOULD" here is to offer the implementation more flexibility.
A simple implementation could interpret 'SHOULD' as always retransmits
and moves on and still be compliant to the specification. Others may
build more complex logics which should not be prevented.

> A note to that effect would be helpful.
[Ahmad]
Sure, thx.

> On the contrary, it's not necessary to describe what the 
> responder has  
> to do for every possible violation of MUST level requirements by the  
> initiator. But it _is_ necessary to do that for violations of SHOULD  
> level requirements, because that is much more likely to 
> happen. So by  
> making this a SHOULD you've created more work on the part of the  
> responder than if it were a MUST.
> 
> OTOH, if it really doesn't matter to the responder one way or 
> another,  
> then I'm not sure you need either.
> 
> BTW, It's not necessary for the responder to treat every MUST  
> violation by the sender as an error--Postel's law should 
> applies here.  
> I suspect the real requirement is that the _receiver_ MUST 
> ignore any  
> BIDs if present, right?

[Ahmad]
No.
In this case, the mobile node may have registered multiple bindings,
i.e., multiple care-of addresses for the same HoA. Each bindings is
assigned one Binding ID. Let us assume that the MN has BIDs(1, 2, 3, and
4) just for the sake of this discussion.

The home agent may send a BRI with [BIDs (1,4)], this means ONLY BIDs (1
& 4) are being revoked. 2 & 3 still active.
The home agent may send a BRI with [BIDs (1, 2, 3, & 4)] to revoke all
of these 4 Bindings (In this case ALL Bindings). Well, this is NOT
recommended, the HA could have sent a BRI with NO BID(s) and accomplish
the same result.

> > bit is NOT set, what the receiving node should do. The 
> intention is  
> > for
> > the MAG (responder) in the case of (G) revocation to always 
> send the  
> > BRA
> > message.
> 
> This goes back to my previous comment. You require the responder to  
> make complex decisions on whether to send a BRA, based on the A-bit,  
> the G-bit, the responder role, etc. It would make life much easier  
> (read: less error prone) for the implementor if you could make this  
> entirely dependent on a single flag.
[Ahmad]
Will fix this as pointed earlier.

> I don't think one needs to worry about scenarios such as "battery  
> failed" in deciding to make a requirement a MUST or a SHOULD. If we  
> did, it would not be possible to have _any_ MUSTs.
> 
> In this particular case, not sending the BRA appears to do harm, in  
> that it may induce unnecessary retransmissions on the sender's part.
> 
> 
> 
> >
> >>
> So this is really an editorial issue then. The problem is in the  
> phrase "in all cases". Putting "all cases" here, then a loophole of  
> "if required" in the referenced section is confusing. I propose  
> changing the sentence to say something to the effect of:
> 
> "In all cases where the MN sends a BRA, it MUST do so according to  
> section 11.1"
[Ahmad]
Sure, will adopt this text.

> > Please see response to the comment about processing the BRI 
> when the  
> > (G)
> ... and please see my response.
[Ahmad]
Will be resolved as mentioned above.

> See my previous response about it being better to make explicit  
> decisions on the A bit rather than inferences due to other bits. In  
> this particular case, the sender has _already_ violated a MUST if it  
> didn't set the A-bit. (And I assume that if it did not set 
> the A bit,  
> it probably isn't waiting for a BRA--otherwise it is doubly broken).  
> Is it really that important for it to get the BRA under those  
> circumstances?
[Ahmad
Will resolve as mentioned earlier above.

> Okay.
> Okay--I think adding a sentence or two that at least 
> indicates that it  
> sends a successful status on success, and sends an appropriate error  
> status if an error occurs would help.
[Ahmad]
Sure, will add a note to that extent.

> So it's the maximum interval between any two retransmission, not the  
> maximum time before retransmissions stop, right? That is, once you  
> reach MAX_BRACK_TIMEOUT you stop backing-off, but you may 
> continue to  
> send retransmissions at an interval of MAX_BRACK_TIMEOUT until you  
> reach max retries? If so, it might be useful to add something to the  
> effect of:
> 
> "Once the interval between retransmissions reaches 
> MAX_BRACK_TIMEOUT,  
> the exponential back-off will cease. If the total number of  
> retransmissions has not yet reached BRIMaxRetriesNumber, the sender  
> will continue to retransmit at intervals of MAX_BRACK_TIMEOUT 
> it does  
> so."
[Ahmad]
Sure. Thx.

> Thanks!
[Ahmad]
Thanks to your detailed review!

> Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Aug 2009 21:56:16 -0500

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.

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"

-S4, paragraph 2: "verify that the mobile access gateway sending the  
binding revocation indication message is authorized to invoke global  
revocation"

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.

-- Section 7.3:

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...)

Why not MUST NOT?

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 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?

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:

Does it really notify "with" a bulk termination, or "about" a bulk  
termination?

s/describe/present

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).

-- S3.2, first sentence

-- S3.3, title:

-- 3.4, first paragraph: "...where Binding Revocation mechanism is  
needed..."

s/Binding/"The Binding"

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."

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."

-- 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?

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"

-- 4th bullet: "unless an Alternate Care-of Address mobility option is  
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."

-- 7th bullet:

-- last bullet: "unless an Alternate Care-of Address mobility option  
is included in the Binding Revocation Indication message."

in which case do what?

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"

-- 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"

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/are/as

s/multi/multiple

-- same bullet: "consider all of its registered care-of addresses  
bindings with this home address are being revoked"

s/are/as

It's worth noting to the RFC editor to please replace this with the  
actual value assigned by IANA.

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Aug 2009 23:08:03 -0500

Note that the address listed in the draft tracker for Julien bounces-- 
trying again with the address on the MEXT wg page:

On Aug 25, 2009, at 9:56 PM, Ben Campbell wrote:

> 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  
> issues. Additionally, I have a number of editorial comments.
>
> Major issues:
>
> 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"
>
> 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"."
>
> tell the Revocation Trigger value is not in line with the  
> initiator's intent.
>
> Can you offer guidance on when an implementation might reasonably  
> not do this? (i.e. why not a MUST?)
>
> 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...)
>
> 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.)
>
> the consequences thereof? In particular, are there scenarios where  
> the initiator might go into retries because the responder chose not  
> to send a BRA?
>
> -- S11.1, last paragraph: "could be used by the mobile node to  
> define what action"
>
> 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"
>
> -- "initial minimum delay: "The default is 1 second but not less  
> than 0.5 seconds"
>
> 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.
>
> 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.
>
> 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.
>
> understand if you separated out a  single section on sending BRA  
> when the A bit is set, rather than repeating it for each scenario.
>
> 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."
>
> 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  
> 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.
>
> You stated this normatively in section 4. Also, that section said  
> "if IPSec is used"--what if it's not?
>
> 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."
>
> 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?
>
> Normative NOT does not make sense here. I think you meant "... set  
> to a value that is not supported."
>
> -- 4th bullet: "unless an Alternate Care-of Address mobility option  
> is included"
>
> S 9.2.1, first bullet: "Binding Revocation Indication is formatted  
> as in Section 6.1"
>
> 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."
>
> 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.
>
> Also, in the various name spaces, do you want a column indicating  
> what RFC or other document specifies a given value?
>
> -- References:
>
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Aug 2009 17:30:10 -0500

On Aug 26, 2009, at 3:58 AM, Ahmad Muhanna wrote:

> mechanism

I think there are still a couple of issues here. First, Since the  
underlying RFCs only specify IPSec at SHOULD strength, this draft  
needs to discuss the consequences of not using it for BRI. Depending  
on those consequences, it might be enough to just warn implementors  
that, if you don't use IPSec, certain bad things can happen. OTOH, it  
might be that BRI has greater security risks than for 3775/5213, and  
you might (for example) need to strengthen the IPSec requirement for  
BRI.

I admit to not being an expert on 3375/5213, so it may be true that  
BRI is no riskier than the underlying technology--but even if that is  
true I'd like to see some discussion to support it.

Second, I think that there is probably more guidance needed on  
authorization decisions even if you do use IPSec. For example, do you  
assume that any trusted peer can remove any binding? Is a trusted peer  
only allowed to remove bindings that it previously established using  
the same SA? If an SA is torn down and a new one established, what  
authorization gets inherited, if any? Do you assume that a peer that  
is trusted to establish bindings is trusted for BRI? Do you need to  
provision policies around these, and if so what are the moving parts?

> We could introduce a simple default mechanism inline with what we have

It's possible that might help--can you point to the section of 5213  
you have in mind? It might also be enough to have more discussion on  
what an implementor needs to think about to do authorization  
correctly. For example, does it make sense to statically provision  
that a trusted peer can remove any binding for "foo.com"? Is  
authorization policy dynamically determined by prior actions (i.e. a  
peer can revoke all bindings _it_ established for "foo.com", but not  
bindings that another device established for "foo.com"?

Probably more than anything, it would help to discuss the sort bad  
things that this authorization is intended to prevent.

That's a little hard to believe without some supporting text. Again,  
this could be my lack of knowledge of IPv6 mobility talking. But for  
example, do RFC3775 and/or 5213 already have something a mechanism for  
one mobility element to tell another to drop bindings in bulk?

There's a lot of interaction between these bit settings that make for  

As a thought experiment, how would you recommend an implementer to  
handle the case where a responder got BRI with the G bit set and the A  
bit not set? (I'm not asking for the draft to specify that--it's just  
a discussion point.)

Actually, this is really more of a 9.2.1 issue. (I reviewed things  
linearly.) I think a reference here would help, but note I had similar  
comments about 9.2.1 further down.

Thanks!

Thanks!

where the trigger value can be out of line with the "intent"? I guess  

Okay.

retransmissions. The second is that the implementator could choose not  

> scenario is probably not the best way. Allowing it, then it is not  

On the contrary, it's not necessary to describe what the responder has  
to do for every possible violation of MUST level requirements by the  
initiator. But it _is_ necessary to do that for violations of SHOULD  
level requirements, because that is much more likely to happen. So by  
making this a SHOULD you've created more work on the part of the  
responder than if it were a MUST.

OTOH, if it really doesn't matter to the responder one way or another,  
then I'm not sure you need either.

BTW, It's not necessary for the responder to treat every MUST  
violation by the sender as an error--Postel's law should applies here.  
I suspect the real requirement is that the _receiver_ MUST ignore any  
BIDs if present, right?

didn't set the A-bit. (And I assume that if it did not set the A bit,  

Okay.

> State", the MN could send a BRA with status code set to failure.

Okay--I think adding a sentence or two that at least indicates that it  
sends a successful status on success, and sends an appropriate error  
status if an error occurs would help.

reach MAX_BRACK_TIMEOUT you stop backing-off, but you may continue to  

"Once the interval between retransmissions reaches MAX_BRACK_TIMEOUT,  
the exponential back-off will cease. If the total number of  
retransmissions has not yet reached BRIMaxRetriesNumber, the sender  
will continue to retransmit at intervals of MAX_BRACK_TIMEOUT it does  
so."

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Aug 2009 17:37:08 -0500

Hi Jari--comments inline:

On Aug 26, 2009, at 5:05 AM, Jari Arkko wrote:

> Ben,
>
> Thanks for your review!
>
> Wrt. authorization, the document does make it clear that bulk  
> revocation requires explicit authorization (search for  
> "authorization"). The document does not say how to achieve this, but  
> I would assume a global configuration flag or a list of authorized  
> peers. We could add this to the document, if you think it helps.

I think it would help. Even some non-normative examples might help.

I think the most important thing is to give guidance on what the  
implementor needs to consider, and what sort of bad things can happen  
without proper authentication.

>
> When it comes to non-bulk revocation messages, I'm not sure their  
> requirements are any different from the rest of the signaling.  
> First, the protocol intrinsically enables only the revocation of  
> sessions created by the two parties. Secondly, existing messages can  
> already be used to create and delete sessions from clients --  
> binding revocation simply adds a capability to do that from the  
> server side as well. Additional requirements for authorization  
> mechanisms could be added here, but I'm not sure its needed.
>

I think it would help to add that to the security considerations,  
along with some discussion on whether the ability to revoke from the  
server side adds any new considerations. I can accept that the answer  
may be "no, it doesn't", but that is easier to accept with some  
supporting discussion :-)

> Jari

---

From: Ben Campbell <[email-masked]>
Date: Thu, 27 Aug 2009 15:47:30 -0500

Thanks for the response. Comments inline. I will remove sections where  
I think we are in agreement.

> draft-ietf-mext-binding-revocation-10

[...]

> 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.

> comments after addressing all of PART-II comments.

Agreed.

> development of this specification is to use one or the other:)

Okay. Believe it or not, I usually gripe about too many acronyms :-)

[...]

> 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.)
>   can clean up the applicable resources.

s/which/that, but otherwise I think it works.

Okay.

>> sending mobility node? If so, it would help to use it later

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".

> 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?

> 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.

[...]

>> I have trouble parsing this sentence.

(You did not respond to this one.)

> Hopefully this clarifies the question related "if SA has been renewed

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?

[...]
> the BRI is set to the source IP address of the packet that carried the

Are all of those choices interoperable?

> 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>.

[...]

> 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.

[...]

> The same comment as the one under 4th bullet of S8.1.

Same response :-)

> case, the LMA sends a BRA with status code "Global Revocation NOT

I think it would be helpful to say that in the draft.

>> these are true, but does not set the values, correc"t"

[...]

>      the included mobility options to identify the impacted mobile

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.)

> Sure, what about "MUST process"?

I think that helps.

> 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 :-)  )

Okay.

>      the Binding Revocation Acknowledgement to "Revocation failed - MN

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.

[...]
> 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.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 26 Aug 2009 13:05:40 +0300

Ben,

Thanks for your review!

Wrt. authorization, the document does make it clear that bulk revocation 
requires explicit authorization (search for "authorization"). The 
document does not say how to achieve this, but I would assume a global 
configuration flag or a list of authorized peers. We could add this to 
the document, if you think it helps.

When it comes to non-bulk revocation messages, I'm not sure their 
requirements are any different from the rest of the signaling. First, 
the protocol intrinsically enables only the revocation of sessions 
created by the two parties. Secondly, existing messages can already be 
used to create and delete sessions from clients -- binding revocation 
simply adds a capability to do that from the server side as well. 
Additional requirements for authorization mechanisms could be added 
here, but I'm not sure its needed.

Jari

---

From: Ben Campbell <[email-masked]>
Date: Thu, 27 Aug 2009 17:24:34 -0500

Hi Ahmad,

Let me comment on the security issues at a high level up front, since  
I think I can tie together responses to several of your comments  
below. More specific comments imbedded:

I think the email from Jari helped clarify things for me to a point  
that I can make my concerns a little more precise. You clarify further  
down that mobile nodes are _never_ allowed to revoke bindings that  
weren't associated with them in the first place. This actually  
addresses a lot of my concerns, and I think it is fundamental enough  
to be reiterated in the SecCons section.

I still have concerns about the use of IPSec, though, as without IPSec  
of some other form of authentication, an attacker could conceivably  
impersonate the node that bindings were associated with. This is  
particularly bothersome in use cases that allow a node to revoke  
bindings without having to know the details of each individual  
binding, such as the G-bit, or an included NAI of the form  
"@example.com".

I'm not saying that this draft needs to make IPSec into a MUST. But it  
is appropriate for it to point out that if you _don't_ use it, bad  
things could happen. (See my comment on that point further down.)

It may be that using MIPv6 without IPSec is just as bad without BRI as  
with it--in which case it's fair to say that any attacks enabled by  
not using IPSec with BRI are no worse than using the base technologies  
without BRI. (Such statements are easier to believe with some  
discussion to support them, though :-) )

More inline:

> mobility signaling and consequently BRI/BRA.

Sure--but it's appropriate for the BRI spec to say "If BRI is used  
without IPSec, these bad things can happen in addition to the bad  
things that might happen if you use the base technology without  
IPSec." Or alternatively, "The bad things that can happen with BRI  
without IPSec are functionally identical to those for the base  
technology, so the IPSec related security considerations are identical  
to those in RFCXXXX/YYYY).

> BRI./BRA that does not have on BU/BA.

If I use just BU/BA without IPSec, is there a way an attacker could  
delete bindings in bulk without having to know all the details for  
each binding?

> authorization should be done separately.

So it may seem obvious to you, but it's worth mentioning that the node  
needs to make sure the new SA is with the same node as the old SA.

> Do you see any problem there?

No, if you can be sure the node is really the node you think it is.

> If it is not enough, let us know what is missing and we can add/modify

Given the "you can only delete your own bindings" constraint, this is  
probably okay.

>> of 5213 you have in mind?

I think that would help, although it's still worth mentioning that for  
that sort of authorization to be meaningful, you have to have some  
degree of authentication (IPSec or otherwise).

> That is the very fundamental requirement for this protocol.

Okay, that helps. It's fundemental enough it might be worth  
reiterating in the SecCons section.

> bindings which belong to this Mobile node.

Okay, that supports the idea that BRI considerations are similar those  
for the base technologies. Does the ability for an HA to delete  
bindings at a MN change things?

[...]

> make sure that all places are fixed.

Thanks, I think this helps.

> This should be addressed as part of the authorization clarification.

Okay

Okay.

Okay.

> build more complex logics which should not be prevented.

In general, SHOULDs should be used when there are specific reasons you  
think an implementation might not want to do something, not for open  
ended flexibility. SHOULDs without additional guidance are typically  
bad for interoperability.

In this case, I'm reasonably convinced that SHOULD is okay here, but  
I'd like to see some guidance around it. For example, does it make  
sense to have a note indicating that an implementation might choose  
not to retransmit if it either does not need reliable delivery, or if  
it has some other (preferably interoperable)  reliability mechanism?  
(Although one wonders why an implementation would set the A-bit but  
not retransmit.)

I know that RFC3775/5213 may not do this--but I think it's reasonable  
to try to improve the way we (as the whole IETF) do things over time.

> recommended, the HA could have sent a BRI with NO BID(s) and  

Okay, I think I understand now--there are two ways to delete all  
bindings, and you are basically preferring one but not requiring it,  
right?

[...]

>> that it may induce unnecessary retransmissions on the sender's part.

(You did not follow up on this one)

[...]

Thanks!

Ben.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 29 Aug 2009 02:14:55 -0500

Hi, Ben,
Sorry for the late reply, hope to close on all comments; please see
inline.

> 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!

> 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 ...... "

[Ahmad]
Ok.

> >> 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.

> "could be 
> 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.
> >> Indication with Acknowledge
> 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.

> (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:)
 
> 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  
[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.

> > 2. If the home agent saves the source address of the packet 
> carried  
> > the
> > agent can send the packet that carries the BRI message to 
> the source  
> > IP
[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.
  
> above will indicate whether that is a problem in this 
[Ahmad]
Please see answer above.

> (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.
"
> > 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
[Ahmad]
Yes.

> Not necessarily where it moved to, etc.
> 
> [...]
> 
> >
> >
> >>
[Ahmad]
Same text as the one above will be added to this bullet.

[Ahmad]
Ok.

> therefore probably should not be all-caps.)
[Ahmad]
Are you saying the text in the sub-bullets is not normative?

[Ahmad]
Ok.

> previous comments about silent discard interaction with A-bit 
[Ahmad]
Will check and if it is not included, will add it here.

> those name spaces can properly identify where to put them.
[Ahmad]
Ok. Thanks again!

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 29 Aug 2009 03:21:17 -0500

Hi Ben,
Will address and comment on open ones. Please see inline.

Regards,
Ahmad

> Subject: Re: [PART-I] Gen-ART LC and Telechat Review of 
> Let me comment on the security issues at a high level up 
> front, since I think I can tie together responses to several 
> of your comments below. More specific comments imbedded:
> 
> I think the email from Jari helped clarify things for me to a 
> point that I can make my concerns a little more precise. You 
> clarify further down that mobile nodes are _never_ allowed to 
> revoke bindings that weren't associated with them in the 
> first place. This actually addresses a lot of my concerns, 
> and I think it is fundamental enough to be reiterated in the 
> SecCons section.
[Ahmad]
Sure, we can make that clear.

> 
> I still have concerns about the use of IPSec, though, as 
> without IPSec of some other form of authentication, an 
> attacker could conceivably impersonate the node that bindings 
> were associated with. This is particularly bothersome in use 
> cases that allow a node to revoke bindings without having to 
> know the details of each individual binding, such as the 
> G-bit, or an included NAI of the form "@example.com".
> 
> I'm not saying that this draft needs to make IPSec into a 
> MUST. 
[Ahmad]
If it comes to me, I am comfortably fine with that:)

> But it is appropriate for it to point out that if you 
> _don't_ use it, bad things could happen. (See my comment on 
> that point further down.)
> 
> It may be that using MIPv6 without IPSec is just as bad 
> without BRI as with it--in which case it's fair to say that 
> any attacks enabled by not using IPSec with BRI are no worse 
> than using the base technologies without BRI. (Such 
> statements are easier to believe with some discussion to 
> support them, though :-) )

[Ahmad]
When IPsec is used, the only issue that we identified that needs special
attention was the Global Revocation with Revocation Trigger value
"Per-Peer Policy" when sent from the MAG [because it deletes all
sessions between the two peers]. Although, some people still disagreed
that there is no great risk in there and no special treatment should
take place. At any rate, since this message coming from a peer in the
visited network, we wanted the home network to have the upper hand and
be able to give specific privileges to peers in the different visited
networks, i.e., MAGs. What this means? the ability to establish an IPsec
SA between the MAG and the LMA does not give the MAG the automatic
privilege to use Global Revocation with Revocation Trigger value of
"per-Peer Policy". That why we required authorization.

> >> that, if you don't use IPSec, certain bad things can happen.
> > [Ahmad]
> > It is NOT expected that BRI/BRA will use a different security 
> > mechanism than what is being used for securing IPv6 mobility 
> > signaling.
> > Therefore,
> > in order to alert implementors of the danger if IPsec is NOT used, 
> > IMO, that needs to be discussed in related IPv6 mobility 
> > specifications, e.g., RFC3775 and RFC5213, which is already 
> there. On 
> > the other hand, it is very difficult to anticipate the criteria of 
> > other security mechanisms that would possibly be used in 
> the future to 
> > secure IPv6 mobility signaling and consequently BRI/BRA.
> >
> 
> Sure--but it's appropriate for the BRI spec to say "If BRI is 
> used without IPSec, these bad things can happen in addition 
> to the bad things that might happen if you use the base 
> technology without IPSec." Or alternatively, 

> "The bad things 
> that can happen with BRI without IPSec are functionally 
> identical to those for the base technology, so the IPSec 
> related security considerations are identical to those in 
> RFCXXXX/YYYY).
[Ahmad]
We can add something similar to this. Thx.

> true that 
> If I use just BU/BA without IPSec, is there a way an attacker 
> could delete bindings in bulk without having to know all the 
> details for each binding?

[Ahmad]
Well, there is no mechanism with BU/BA to delete mobility sessions in
bulk as proposed in Binding Revocation; On the other hand, If BU/BA are
used without IPsec, Operators will run out of money quickly:) and they
probably will use Global BRI/BRA (without security) to stop the
bleeding:)

> >> assume that any trusted peer can remove any binding?
> > [Ahmad]
> >> Is a trusted peer only allowed to remove bindings that it 
> previously 
> >> established using the same SA?
> > [Ahmad]
> > valid for both BU/BA and BRI/BRA. In other words, the new SA will 
> > still have the same SPD which allows the BU/BA and BRI/BRA 
> messages, 
> > etc. If your question is about authorization of Global revocation, 
> > that authorization should be done separately.
> 
> So it may seem obvious to you, but it's worth mentioning that 
> the node needs to make sure the new SA is with the same node 
> as the old SA.
[Ahmad]
Sure.

> No, if you can be sure the node is really the node you think it is.
[Ahmad]
Sure. Will tweak the text to ensure this is clear.

[Ahmad]
Ok.

> reiterating in the SecCons section.
[Ahmad]
No problem. Thx.

> 
> 
> >>
> >
> > [Ahmad]
> > Yes. For example, the client which has multiple Bindings 
> (referenced  
> > by
[Ahmad]
Not really.

> >       response for a registration or re-registration 
> message within  
> > the

[Ahmad]
Okay. I need to see what we can do here. We probably can add some
guidance.

> > assigned one Binding ID. Let us assume that the MN has 
> BIDs(1, 2, 3,  
> > and
[Ahmad]
True.

Many thanks one more time!

Regards,
Ahmad