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

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 1 Sep 2009 14:28:00 -0500

> >>>>
> >>>> -- S7.2, paragraph 2: "Since some mobility entities, e.g., local 
> >>>> mobility anchor and mobile access gateway, are allowed 
> to receive 
> >>>> and possibly send a Binding Revocation Indication or Binding 
> >>>> Revocation Acknowledgement for different cases, 
> therefore, if IPsec 
> >>>> is used to secure signaling between the local mobility 
> anchor and 
> >>>> mobile access gateway, it prevents any of them from processing a 
> >>>> Binding Revocation message that was not constructed by an 
> >>>> authorized party."
> >>>>
> >>>> I have trouble parsing this sentence.
> >>
> >> (You did not respond to this one.)
> >
> > [Ahmad]
> > We basically wanted to say that since the MAG and LMA are 
> both allowed 
> > to send BRI and receive BRA, IPsec will enable the peer to 
> detect if a 
> > man in the middle, for example, reflected a BRI message that it has 
> > initiated back to the peer and consequently silently drop that BRI 
> > message. In the broader sense, we wanted to say that IPsec 
> enables any 
> > of the peers to detect if the received BRI is coming from an 
> > unauthorized party and consequently ignore without processing it.
> >
> > I hope we got it right:)
> 
> I think if you replace the ".. allowed
> to receive and possibly send a Binding Revocation Indication 
> or Binding Revocation Acknowledgement for different cases" 
> with "...allowed to send BRI and receive BRA", it would be 
> easier to read.

[Ahmad]
Sure, makes sense.

Thanks again for all the comments. 
Hopefully will get a new revision before the end of the week.

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 1 Sep 2009 15:35:48 -0500

Hi Ben,
Please see inline.

Regards,
Ahmad
> -----Original Message-----
> 
> >
> >>
> >> 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.
> >
> 
> Again, I'm looking for discussion on what the impact of 
> choosing _not_ to use IPSec, since it is only required at a 
> SHOULD strength. I think the answer to the similar point below helps.
[Ahmad]
Ok. 

> 
> 
> >>
> >> More inline:
> >>
> >> On Aug 27, 2009, at 1:32 PM, Ahmad Muhanna wrote:
> >>
> >>> Hi, Ben,
> >>>
> >>>>>
> >>>>>> -----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.
> >>>>
> >>>> 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.
> >>>
> >>
> >> 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.
> 
> Okay, thanks!
> 
> 
> 
> >
> >
> >>
> >>
> >>>
> >>>> 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.
> >>
> >> 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:)
> >
> 
> Heh :-)
> 
> So is it true that using bulk revocation without IPSec could make it  
> possible for an attacker to masquerade as an authorized party, and  
> delete large numbers of bindings with a single BRI? 
[Ahmad]
Well, we need to be a little careful here:) I think what you meant to
say here is without any security mechanism.
So, If no valid SA is being used to protect the binding revocation
signaling and, I assume, the MIP6/PMIP6 signaling, then a lot of bad
things could happen.

> Or there  
> underlying architectural features that prevent or make this hard? 
[Ahmad]
I am not quite sure what you mean by the underlying architectural
features in this context. But I can say the following: If no security
mechanism (SA) is being used, neither BU/BA nor BRI/BRA are allowed to
be used for establishing nor revoking mobility sessions. 
  
> think just discussing that in the SecCon would go a long way towards  
> addressing my concerns.)
[Ahmad]
I am in the process of rewriting the security section and the whole
draft to address all comments. Will revaluate before publishing whether
we need anything specific here.

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 2 Sep 2009 01:12:33 -0500

Hi Ben,
Please see inline.

Regards,
Ahmad

> From: Ben Campbell [mailto:[email-masked]] 
> Subject: Re: [PART-I] Gen-ART LC and Telechat Review of 
> draft-ietf-mext-binding-revocation-10
> On Sep 1, 2009, at 3:35 PM, Ahmad Muhanna wrote:
> 
> [...]
> 
> >>
> In particular, without an authentication mechanism.
> 
> Right, and those bad things seem at least slightly worse with 
> BRI than without it, due to the bulk revocation mechanism--so 
> additional mention seems appropriate.
[Ahmad]
Will try to address this in the new revision. Hopefully, this week.

> Hmm--maybe this is all some confusion on my part. Somewhere I 
> got the impression the requirement to use IPSec for BU 
> messages was SHOULD strength. But in rereading RFC3775, I see 
> it at MUST strength. But I am then confused by the language 
> in this draft that says "If IPSec is used..."
> 
> So, to close on this--do you consider the _use_ of IPSec for 
> BRI to be a SHOULD or MUST? If it's a MUST, then I withdraw 
> my comments about "what happens if you don't use IPSec?", and 
> apologize for the confusion.
[Ahmad]
As you mentioned, RFC3775 mandates the use of IPsec to protect BU/BA
between the MN and the HA. However, RFC5213, Proxy Mobile IPv6, mandates
the implementation of IPsec on the MAG and LMA. So, as you see it is not
straight forward:) On the other hand, I understand what you are trying
to say. Let me work with the authors on this and will share the security
related text before publishing. I am sure we can come up with a text
that reasonably address your concern while staying within the wg
consensus.

> > draft to address all comments. Will revaluate before publishing 
> > whether we need anything specific here.
> 
> Okay.
> 
> Thanks!
> 
> Ben.
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 1 Sep 2009 14:22:15 -0500

HI--I think we're almost closed on this Part II --remaining comments  
below:

On Aug 29, 2009, at 2:14 AM, Ahmad Muhanna wrote:

[...]
>
>> Does the potential guess-ability of a sequence number have
>> security implications?
>
> [Ahmad]
> Not at all. Packet must pass IPsec authentication first.

But remembering that IPSec is only a should, does that answer change  
if IPSec is not used? I guess the question is around what damage would  
be done if it was guessed.

>
>>
>> [...]
>>
>>
>>>
>>>>
>>>> -- S7.2, paragraph 2: "Since some mobility entities, e.g., 
>>>> local mobility anchor and mobile access gateway, are allowed
>>>> 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."
>>>>
> 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
> message. In the broader sense, we wanted to say that IPsec enables any

I think if you replace the ".. allowed
to receive and possibly send a Binding Revocation Indication
or Binding Revocation Acknowledgement for different cases" with  
"...allowed
to send BRI and receive BRA", it would be easier to read.
>
>>
>> [...]
>>>>
>>>> -- 4th bullet: "unless an Alternate Care-of Address mobility 
>>>> option is included"
>>>>
>>>> In which case you do what?
>>> [Ahmad]
>>> Thanks! It is a long story:)
>>>
>>> What it means here is the following:
>>> The destination IP address of the packet is set to the care-of
>>> address.
>>> However, if the home agent include an Alternate care-of
>> address option
>>> in the BRI, the destination IP address MUST NOT be set to
>> the care-of
>>> address.
>>>
>>> When the home agent is able to include an Alternate Care-of
>> Address in
>>> the BRI? ONLY when the mobile node sends a BU message with the
>>> Alternate
>>> Care-of address included in the BU. If the MN include the Alternate
>>> Care-of address inside the BU, the source IP address of the packet
>>> carrying the BU is different than the IP address inside the
>> Alternate
>>> Care-of address.
>>>
>>> NOW: It depends on the home agent implementation:
>>> 1. The home agent can send the BRI message to the care-of address
>>> regardless, if this care-of address received as the source IP
>>> address of
>>> the packet carrying the BU or inside the BU in the Alternate Care-of
>>> address option.
>>>
>>> 2. If the home agent saves the source address of the packet
>> carried
>>> the
>>> BU in addition to the MN care-of address in the MN BCE,
>> then the home
>>> agent can send the packet that carries the BRI message to
>> the source
>>> IP
>>> address of the packet that carried the BU.
>>>
>>> 3. Depends on implementation of the home agent, the home agent may
>>> send
>>> the BRI to the MN care-of address all the time.
>>>
>>> The key point here is: If the HA include the Alternate
>> care-of address
>>> inside the BRI, then the destination IP address of the
>> packet carrying
>>> the BRI is set to the source IP address of the packet that
>> carried the
>>> BU.
>>
>> Are all of those choices interoperable?
> [Ahmad]
> Yes.

Okay.

>
>>
>> But in any case, I think you need at least some guidance. Right now,
>> you have a conditional MUST without an "else" clause for that
>> condition. A simple ..., in which case, the destination
>> address SHOULD
>> (or MAY) be set to <something>.
>
> [Ahmad]
> Here is the new text:
>
> "
>   o  The care-of address for the binding MUST be used as the
>      destination address in the packet's IPv6 header, unless an
>      Alternate Care-of Address mobility option is included in the
>      Binding Revocation Indication.  If an Alternate Care-of Address
>      option is included in the Binding Revocation Indication message,
>      the destination address in the packet's IPv6 header SHOULD be set
>      to the source IP address of the packet that carried the latest
>      successful Binding Update with the Alternate Care-of address
>      included.
> "

Okay, that helps.

[...]

>>
>>
>>>> Also, the language here sounds more like
>>>> you are talking about the initiator. The responder validates
>>>> these are true, but does not set the values, correc"t"
>>> [Ahmad]
>>> True. Will reword it.
>>>
>>
>> [...]
>>
>>>>
>>>> -- Bullet 5:
>>>>
>>>> Why not MUST?
>>> [Ahmad]
>>> Good question. Since the sub-bullets include the proper normative, I
>>> believe we can remove "SHOULD" and rely on the sub bullet normative
>>> text.
>>>
>>> "
>>>  o  If the Global (G) bit is NOT set, the local mobility
>> anchor uses
>>>     the included mobility options to identify the impacted mobile
>>>     node binding as follows:
>>> "
>>>
>>
>> Hmm, I don't see any normative statement in that sub-bullet.
>> (The all-
>> caps NOT is in a condition clause, not a normative statement--and
>> therefore probably should not be all-caps.)
>>
> [Ahmad]
> Are you saying the text in the sub-bullets is not normative?

Ah, I see you were talking about the bullets subordinate to the bullet  
you quoted--nevermind.

(But the NOT in "bit is NOT set" really should not be capitalized).

[...]

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 1 Sep 2009 14:39:15 -0500

Hi Ahmad,

Comments inline. I deleted items I think we can consider closed.

On Aug 29, 2009, at 3:21 AM, Ahmad Muhanna wrote:

[...]

>
>>
>> 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".
>>
>> _don't_ use it, bad things could happen. (See my comment on
>> that point further down.)
>>
>> 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]
> 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
> 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.
>

Again, I'm looking for discussion on what the impact of choosing _not_  
to use IPSec, since it is only required at a SHOULD strength. I think  
the answer to the similar point below helps.

>>>>> mobility session(s) that have been created using an IPv6 mobility
>>>> I think there are still a couple of issues here. First, Since the
>>>> underlying RFCs only specify IPSec at SHOULD strength, this draft
>>> in order to alert implementors of the danger if IPsec is NOT used,
>>> the other hand, it is very difficult to anticipate the criteria of
>> 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
>> identical to those for the base technology, so the IPSec
>> related security considerations are identical to those in
>> RFCXXXX/YYYY).
> [Ahmad]

Okay, thanks!

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

Heh :-)

So is it true that using bulk revocation without IPSec could make it  
possible for an attacker to masquerade as an authorized party, and  
delete large numbers of bindings with a single BRI? Or there  
underlying architectural features that prevent or make this hard? (I  
think just discussing that in the SecCon would go a long way towards  
addressing my concerns.)

[...]

[...]

>>
>>
>> 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.
>
> [Ahmad]
> Okay. I need to see what we can do here. We probably can add some
> guidance.
>

Okay, thanks!

[...]

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 1 Sep 2009 16:02:07 -0500

[...]

> signaling and, I assume, the MIP6/PMIP6 signaling, then a lot of bad

Right, and those bad things seem at least slightly worse with BRI than  
without it, due to the bulk revocation mechanism--so additional  
mention seems appropriate.

> be used for establishing nor revoking mobility sessions.

Hmm--maybe this is all some confusion on my part. Somewhere I got the  
impression the requirement to use IPSec for BU messages was SHOULD  
strength. But in rereading RFC3775, I see it at MUST strength. But I  
am then confused by the language in this draft that says "If IPSec is  
used..."

So, to close on this--do you consider the _use_ of IPSec for BRI to be  
a SHOULD or MUST? If it's a MUST, then I withdraw my comments about  
"what happens if you don't use IPSec?", and apologize for the confusion.

Okay.

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 2 Sep 2009 08:22:11 -0500

I think we've got closure on all Part I issues, pending the actual  
text :-)

Thanks!

Ben.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 5 Sep 2009 03:04:59 -0500

Hello,

We have updated the draft to address all comments. 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-1
1.txt

In summary, here is a list of the major changes:

1. Enhanced to the security text mainly under section 6.1. and section
13 (Security Considerations) to address Ben comments. In addition, we
eliminated the Security Model section based on Ralph's comment.

2. Enhanced the text for MAG authorization and defined a default
mechanism as specified under section 13, Security Considerations.

3. Addressed Pasi's comments by adding text to clearly specify that the
current specification uses mobile node identifier option, MN-ID, with
subtype 1, as stated mainly under section 5.1. In addition, we defined
the format of "wild card" NAI as per the use of this specification, text
under section 8.1.1.

4. Addressed all the remaining of Ralph's detailed comments in several
places of the document.

5. Clarified that the responder sends BRA only if the Acknowledge (A)
bit is set. Text was tweaked in several places.

6. all nits and editorial comments....

Please let me know if you still have any issue.

Thanks for all of your comments and help!

Regards,
Ahmad

> From: Muhanna, Ahmad (RICH1:2H10) 
> Sent: Thursday, August 27, 2009 1:33 PM
> To: 'Ben Campbell'
> Cc: Khalil, Mohamed (RICH2:2S20); [email-masked]; 
> [email-masked]; [email-masked]; General 
> Area Review Team; [email-masked]; Jari Arkko; 
> [email-masked]; Laganier, Julien
> Subject: RE: [PART-I] Gen-ART LC and Telechat Review of 
> > on those consequences, it might be enough to just warn implementors 
> 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 
> > I admit to not being an expert on 3375/5213, so it may be true that 
> 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.
> 
> > 
> > >
> > >
> > >> (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'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.
> 
> > 
> > >
> > >> 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.
> > 
> > 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.  
> 
> > 
> > >
> > >>
> > >>
> > >> 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.
> > 
> > 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
> > > 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.
> > 
> > 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.
>  
> > >
> > >>
> > >>
> > >> -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.
> > 
> > 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.
> 
> > 
> > >>
> > >> -- 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.
> > >
> > 
> > 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.
> 
> 
> > > 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.
> > 
> > Okay.
> > 
> > >
> > >> -- 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.
> > 
> > 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.
> 
> > 
> > >
> > >>
> > >> -- 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.
> > 
> > A note to that effect would be helpful.
> [Ahmad]
> Sure, thx.
> 
> > 
> > >
> > >>
> > >> -- 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.
> > 
> > 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.
> 
> > 
> > >
> > >>
> > >> -- 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.
> > 
> > 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.
> 
> > 
> > >
> > >>
> > >> -- 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.
> > 
> > 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.
> > 
> > 
> > 
> > >
> > >>
> > >> -- 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.
> > 
> > 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.
> 
> > 
> > >
> > >>
> > >> -- 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.
> > 
> > ... and please see my response.
> [Ahmad]
> Will be resolved as mentioned 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.
> > 
> > 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.
> 
> > 
> > >
> > >>
> > >> -- 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.
> > 
> > Okay.
> > 
> > >
> > >
> > >> -- 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.
> > 
> > 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.
> 
> > 
> > >
> > >>
> > >> -- 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.
> > > "
> > >
> > 
> > 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.
> 
> > 
> > > 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
> > 
> > Thanks!
> [Ahmad]
> Thanks to your detailed review!
> 
> > 
> > Ben.
> >

---

From: Ben Campbell <[email-masked]>
Date: Fri, 11 Sep 2009 11:59:43 -0500

On Sep 10, 2009, at 5:35 PM, Ahmad Muhanna wrote:

> Hi Ben,
> Thanks for the follow up. Please see answers inline.
>
> Regards,
> Ahmad
>
>
>> Subject: Re: Gen-ART LC and Telechat Review of
>> This is a followup on revision 12, since it came out before I
>> got to revision 11:
>>
>> Overall, I think this revision is much better. Most of my
>> concerns have been addressed, but I have a few minor ones remaining.
>>
>> Specific comments:
>>
>>
>> -- Section 10.1, 2nd bullet:
>>
>> I don't think we resolved my concern about the SHOULD  in the
>> last sentence. To recap, I think that needs to either be a
>> MUST, or the draft should offer guidance about the reasoning
>> for the SHOULD and the consequences of not following it. I'm
>> picking on this one in particular because it seems like not
>> sending a BRA when the A bit was set is likely to cause
>> retransmissions on the part of the initiator.
>
> [Ahmad]
> If the MN does NOT have a binding in its BUL for the HoA address  
> that is
> included in the Type 2 Routing header, the mobile node should not
> respond back (that was specifically discussed in details on the wg  
> ml).
> It is like instructing the MN to delete a session that does not exist.
> Although, the (A) bit is set, it is up to the mobile node whether to
> send a BRA or not. I do not believe we need to mandate that via a  
> MUST.
> I am sure some handset vendors will not like that at all.

Did the work group consider that if a MN doesn't respond, it can  
expect to get a bunch of retransmissions--each of which it will need  
to parse, check for bindings, etc.; possibly  eating more resources  
than responding in the first place would have?

I could understand if the concern was that the MN might get irrelevant  
(or even malicious) BRIs from arbitrary sources, but since they should  
only be arriving from trusted peers over established SAs, I find the  
choice surprising.

But in any case, my concern was that it should be a MUST _or_ it  
should have discussion of the consequences of not doing it. A line or  
two mentioning why this is a should, under what circumstances it makes  
sense to not respond, and most importantly pointing out the potential  
for needless retransmission would help.

>
>>
>> Also, the last sentence does not seem to make grammatical
>> sense after the edits.
>
> Thx, here is the new text, please let me know if you are okay with it.
>
>   o  If the Acknowledge (A) bit is set in the Binding Revocation
>      Indication and its Binding Update List contains an entry for the
>      IP address in the Type 2 routing header, the mobile node MUST  
> send
>      a Binding Revocation Acknowledgement.  However, in all other  
> cases
>      when the Acknowledge (A) bit is set in the BRI, the mobile node
>      SHOULD sends a Binding Revocation Acknowledgement following
> Section 10.2.

That's better, depending on the resolution of the SHOULD discussion  
above.

>
>>
>> -- Same section, 4th bullet:
>>
>> This one  still seems to ignore the A bit value. Given the
>> other edits, am I correct in assuming that you expect a BRA
>> if the A bit was set, otherwise a silent discard?
>
> [Ahmad]
> I believe we discussed this a little before. It is a fatal error and  
> the
> MN should never receive a BRI with the (P) bit set. That why this
> behavior is the same regardless of the (A) bit is set or not. If you
> feel that some clarification about the (A) bit needs to be added, I  
> can
> say,
> ...... regardless if the Acknowledge (A) bit is set or not, the mobile
> node MUST silently discard the BRI message.

 From previous discussion, I thought we had converged on the idea that  
the A-bit should always be authoritative, rather than having the A-bit  
treatment change due to context. Again, my concern is that the sender  
is likely to retransmit multiple times if you don't respond.

>
>>
>> -- Section 11, (InitMINDelayBRIs) (I think I commented on 
>> this, but can't find the resolution)
>>
>> Did you intend for the _default_ to be a range (between .5
>> and 1 sec), or did you mean to say the default was 1 second,
>> and it must not be configured to less than .5 seconds? I
>> suspect the latter, but it's not clear from the text.
>
> [Ahmad]
> Sure, will fix this as follows:
>
>   Initial Minimum Delay Between BRI messages (InitMINDelayBRIs)
>
>      This variable specifies the initial delay timeout in seconds
>      before the revoking mobility entity retransmits a BRI message.
>      The default is 1 second but not to be configured less than 0.5
> seconds.

That's better, thanks!

>
>
>
>>
>> -- Security Considerations:
>>
>> I think there is enough potential for confusion about when
>> IPSec is required to put some non-normative description of
>> when it is and isn't required, along with references to the
>> normative requirements.
>>
> [Ahmad]
> I suppose this is just a comment that does not need clarification or
> anything like that.

It was more a suggestion that you add a sentence or two to the SA  
discussion in the security considerations section,  of the form of  
"RFCXXXX requires that IPSec be used when sending Binding Update [or  
whatever] messages. However RFCYYYY requires IPSec to be implemented,  
but does not necessarily mandate it's use. "

>
> Thanks again Ben for your review and comments!
>
>>
>> Thanks!
>>
>> Ben.
>>
>>
>>
>>
>>
>> On Sep 5, 2009, at 3:04 AM, Ahmad Muhanna wrote:
>>
>>> Hello,
>>>
>> http://www.ietf.org/internet-drafts/draft-ietf-mext-binding- 
>> revocation
>>> -1
>>> 1.txt
>>>
>>>
>>> 3. Addressed Pasi's comments by adding text to clearly specify that
>>> the current specification uses mobile node identifier
>> option, MN-ID,
>>> with subtype 1, as stated mainly under section 5.1. In addition, we
>>> defined the format of "wild card" NAI as per the use of this
>>> specification, text under section 8.1.1.
>>>
>>>> [email-masked]; [email-masked]; General Area
>>>> Review Team; [email-masked]; Jari Arkko;
>>>> 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.
>>>>
>>>>
>>>> session(s) which are registered with it. No mobility node
>> can revoke
>>>> a mobility session that is registered with a different trusted
>>>> mobility node.
>>>>
>>>>
>>>> I believe I addressed this via another comment earlier.
>> The answer is
>>>> NO.
>>>>
>>>>> If an SA is
>> 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.
>>>>
>>>> Of course. The node which initiated or granted the registration
>>>> should have the authority to revoke it.
>>>> 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.
>>>>
>>>>>
>>>>>>
>>>>>>
>>>> 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
>> (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.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Minor issues:
>>>>>>>
>>>> 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.
>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>> 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
>>>>      response for a registration or re-registration
>> message within
>>>> the
>> message until
>>>> a
>>>> as always retransmits and moves on and still be compliant to the
>>>> specification. Others may build more complex logics which
>> should not
>>>> be prevented.
>>>>
>>>>>
>>>>>>
>>>>>>>
>> 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.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>> Revocation  Acknowledgement according to the procedure in Section
>>>> 7.1 and the
>>>>>> following:
>>>>>> "
>>>>>>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 10 Sep 2009 17:35:25 -0500

Hi Ben,

Regards,
Ahmad

> retransmissions on the part of the initiator.

[Ahmad]
If the MN does NOT have a binding in its BUL for the HoA address that is
included in the Type 2 Routing header, the mobile node should not
respond back (that was specifically discussed in details on the wg ml).
It is like instructing the MN to delete a session that does not exist.
Although, the (A) bit is set, it is up to the mobile node whether to
send a BRA or not. I do not believe we need to mandate that via a MUST.
I am sure some handset vendors will not like that at all.

   o  If the Acknowledge (A) bit is set in the Binding Revocation
      Indication and its Binding Update List contains an entry for the
      IP address in the Type 2 routing header, the mobile node MUST send
      a Binding Revocation Acknowledgement.  However, in all other cases
      when the Acknowledge (A) bit is set in the BRI, the mobile node
      SHOULD sends a Binding Revocation Acknowledgement following
Section 10.2.

> if the A bit was set, otherwise a silent discard?

[Ahmad]
I believe we discussed this a little before. It is a fatal error and the
MN should never receive a BRI with the (P) bit set. That why this
behavior is the same regardless of the (A) bit is set or not. If you
feel that some clarification about the (A) bit needs to be added, I can
say,
...... regardless if the Acknowledge (A) bit is set or not, the mobile
node MUST silently discard the BRI message.

[Ahmad]

[Ahmad]

---

From: Ben Campbell <[email-masked]>
Date: Thu, 10 Sep 2009 16:39:15 -0500

This is a followup on revision 12, since it came out before I got to  
revision 11:

Overall, I think this revision is much better. Most of my concerns  
have been addressed, but I have a few minor ones remaining.

Specific comments:

I don't think we resolved my concern about the SHOULD  in the last  
sentence. To recap, I think that needs to either be a MUST, or the  
draft should offer guidance about the reasoning for the SHOULD and the  
consequences of not following it. I'm picking on this one in  
particular because it seems like not sending a BRA when the A bit was  
set is likely to cause retransmissions on the part of the initiator.

Also, the last sentence does not seem to make grammatical sense after  
the edits.

This one  still seems to ignore the A bit value. Given the other  
edits, am I correct in assuming that you expect a BRA if the A bit was  
set, otherwise a silent discard?

-- Section 11, (InitMINDelayBRIs) (I think I commented on this, but  
can't find the resolution)

Did you intend for the _default_ to be a range (between .5 and 1 sec),  
or did you mean to say the default was 1 second, and it must not be  
configured to less than .5 seconds? I suspect the latter, but it's not  
clear from the text.

I think there is enough potential for confusion about when IPSec is  
required to put some non-normative description of when it is and isn't  
required, along with references to the normative requirements.

Thanks!

Ben.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 12 Sep 2009 03:23:44 -0500

Hi Ben,
Hopefully we can close on all of the open issues.
Please see inline.

Regards,
Ahmad
> >> draft should offer guidance about the reasoning for the SHOULD and 
> >> the consequences of not following it. I'm picking on this one in 
> > If the MN does NOT have a binding in its BUL for the HoA 
> address that 
> > is included in the Type 2 Routing header, the mobile node 
> should not 
> Did the work group consider that if a MN doesn't respond, it 
> can expect to get a bunch of retransmissions--each of which 
> it will need to parse, check for bindings, etc.; possibly  
> eating more resources than responding in the first place would have?
> 
> I could understand if the concern was that the MN might get 
> irrelevant (or even malicious) BRIs from arbitrary sources, 
> but since they should only be arriving from trusted peers 
> over established SAs, I find the choice surprising.
> 
> But in any case, my concern was that it should be a MUST _or_ 
> it should have discussion of the consequences of not doing 
> it. A line or two mentioning why this is a should, under what 
> circumstances it makes sense to not respond, and most 
> importantly pointing out the potential for needless 
> retransmission would help.

[Ahmad]
Yes we discussed that, but there are cases when the MN is not able to
send a BRA, for example, losing coverage, etc. "SHOULD" still a very
strong requirement, the node MUST do it unless there is a very good
valid reason not to.

But, please see below. 

> sense after 
> That's better, depending on the resolution of the SHOULD 
> discussion above.

[Ahmad] 
Here is the text with the proposed addition as suggested above:

   o  If the Acknowledge (A) bit is set in the Binding Revocation
      Indication and its Binding Update List contains an entry for the
      IP address in the Type 2 routing header, the mobile node MUST send
      a Binding Revocation Acknowledgement.  However, in all other cases
      when the Acknowledge (A) bit is set in the BRI, the mobile node
      SHOULD sends a Binding Revocation Acknowledgement following
Section
      10.2. In the case when the MN does not send a BRA message in
response 
      to a BRI with the Acknowledge (A) bit is set, the MN may receive a

      retransmit of the BRI message.

Is that acceptable?

> is likely to retransmit multiple times if you don't respond.
[Ahmad]
Yes, the (A) bit is authoritative when it is used according to this
specification. If used in violation of this specification, then we
should have the choice to NOT allow it to be that authoritative!
Again, this is a fatal error that is NOT supposed to happen. But, what
about if we recommend to the MN to send a BRA with code "Revocation
Function NOT Supported"

---

From: Ben Campbell <[email-masked]>
Date: Mon, 14 Sep 2009 14:02:10 -0500

Hi Ahmad,

Please see inline for my suggested text for the retransmission issue.  
Otherwise, I agree this closes the open issues.

Thanks!

Ben.

>      retransmit of the BRI message.

Mostly. I would say "one or more" retransmissions, as they are likely  
to get several. Also, keep in mind this causes additional work for the  
initiator, who would have to retransmit in the first case. Perhaps  
something to the effect of:

  "Note that anytime the MN does not send an requested acknowledgement  
to a BRI, the initiator is likely to retransmit the BRI multiple  
times. This causes additional load on the initiator who sends the  
retransmissions, as well as on the MN that will receive and process  
them."

> about if we recommend to the MN to send a BRA with code "Revocation

I like the idea of recommending sending the BRA with a non-supported  
code.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 14 Sep 2009 14:06:10 -0500

Hi Ben,

I am fine with your proposed text.
Many thanks for your review and comments.

Regards,
Ahmad

> Sent: Monday, September 14, 2009 2:02 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> [email-masked]; General Area Review Team; [email-masked]; 
> Jari Arkko; [email-masked]; Laganier, Julien
> >> irrelevant (or even malicious) BRIs from arbitrary 
> sources, but since 
> >> they should only be arriving from trusted peers over 
> established SAs, 
> >> I find the choice surprising.
> >>
> >> two mentioning why this is a should, under what circumstances it 
> >> makes sense to not respond, and most importantly pointing out the 
> >> potential for needless retransmission would help.
> >
> > [Ahmad]
> discussion 
> >      to a BRI with the Acknowledge (A) bit is set, the MN 
> may receive 
> > a
> >
> Mostly. I would say "one or more" retransmissions, as they 
> are likely to get several. Also, keep in mind this causes 
> additional work for the initiator, who would have to 
> retransmit in the first case. Perhaps something to the effect of:
> 
>   "Note that anytime the MN does not send an requested 
> acknowledgement to a BRI, the initiator is likely to 
> retransmit the BRI multiple times. This causes additional 
> load on the initiator who sends the retransmissions, as well 
> as on the MN that will receive and process them."
> 
> 
> >>
> >>>
> >>>>
> >>>> edits, am I correct in assuming that you expect a BRA if 
> the A bit 
> >>>> was set, otherwise a silent discard?
> >>>
> >>> [Ahmad]
> >> the A-bit should always be authoritative, rather than having the 
> >> A-bit treatment change due to context. Again, my concern 
> is that the 
> >> sender is likely to retransmit multiple times if you don't respond.
> > [Ahmad]
> I like the idea of recommending sending the BRA with a 
> non-supported code.
> 
> >
> >>
> >>
> >>>
> >>>>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 16 Sep 2009 17:31:43 -0500

Hi Ahmad,

I guess that's okay since the removed text talks about behavior under  
an error condition anyway, so I won't object further if you do it this  
way. But I actually prefer the old text with the warning about  
retransmissions. My concern is, the proposal below simply leaves the  
case of A being set but having no matching binding undefined. I think  
that makes implementors even more likely to decide not to send a BRA  
in that case.

  Is the warning about retransmissions causing concern?

On Sep 16, 2009, at 5:19 PM, Ahmad Muhanna wrote:

> Hello Ben,
>
> Thinking about this a little more, I think that you also would  
> accept if
> we remove the text causing grief all together:) In other words, what
> about if we reword the text as below:
>
> OLD TEXT:
> =========
>      SHOULD sends a Binding Revocation Acknowledgement, the mobile  
> node
>      MUST do so according to Section 10.2.
>
> NEW TEXT:
> =========
>
>      a Binding Revocation Acknowledgement.
>
>
> This way we do not need to add the clarification note.
>
> What do you think?
>
> Please let me know and many thanks again!
>
> Regards,
> Ahmad
>
>
>> Sent: Monday, September 14, 2009 2:06 PM
>> To: 'Ben Campbell'
>> Subject: RE: Gen-ART LC and Telechat Review of
>>> [email-masked]; General Area Review Team; [email-masked]; Jari
>>> Arkko; [email-masked]; Laganier, Julien
>> are likely
>> acknowledgement
>> non-supported
>>>>>>> -- Section 11, (InitMINDelayBRIs) (I think I commented 
>> on this,
>>>>>>> but can't find the resolution)
>>>>>>>
>>>>>>> Did you intend for the _default_ to be a range
>> (between .5 and 1
>>>>>>> sec), or did you mean to say the default was 1 second, and it
>>>>>>> must not be configured to less than .5 seconds? I suspect the
>>>>>>> latter, but it's not clear from the text.
>>>>>>
>>>>>> [Ahmad]

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 16 Sep 2009 17:19:29 -0500

Hello Ben,

Thinking about this a little more, I think that you also would accept if
we remove the text causing grief all together:) In other words, what
about if we reword the text as below:

OLD TEXT:
=========
      SHOULD sends a Binding Revocation Acknowledgement, the mobile node

NEW TEXT:
=========

What do you think? 

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 16 Sep 2009 17:34:00 -0500

Hi Ben,

Not at all. 
I just thought that would work better for you. But, I am okay with
keeping the text and adding the note.

Regards,
Ahmad

> Sent: Wednesday, September 16, 2009 5:32 PM
> I guess that's okay since the removed text talks about 
> behavior under an error condition anyway, so I won't object 
> further if you do it this way. But I actually prefer the old 
> text with the warning about retransmissions. My concern is, 
> the proposal below simply leaves the case of A being set but 
> having no matching binding undefined. I think that makes 
> implementors even more likely to decide not to send a BRA in 
> that case.
> 
> > Thinking about this a little more, I think that you also 
> would accept 
> > if we remove the text causing grief all together:) In other words, 
> > what about if we reword the text as below:
> >
> > OLD TEXT:
> > =========

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 30 Sep 2009 01:12:28 -0500

Hello All,

We have submitted a new revision (13) of the Binding Revocation draft
which addresses all comments including Ben and Ralph outstanding ones.
In summary, we did the following:

1. After some discussion, we removed the Acknowledge (A) bit but
maintained the same logic.
2. We also simplified the structure of the document to eliminate
duplication and moved all common text under The Initiator and Responder
sections.
3. For simplification, added new terminology: Initiator and Responder.
4. Defined a new Error Code "Proxy Binding Revocation NOT Supported" to
allow the mobile node to reject a BRI with the (P) bit is set.

Please take a look and let us know if you still have any comments or you
are satisfied with the way your comments have been addressed.

3.txt

Many thanks in advance!

Regards,
Ahmad

> Sent: Wednesday, September 16, 2009 5:34 PM
> To: 'Ben Campbell'
> I just thought that would work better for you. But, I am okay 
> with keeping the text and adding the note.
> 
> Regards,
> Ahmad
>  
> 
> behavior under