Subject: Re: [MEXT] AD review of draft-ietf-metxt-binding-revocation

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 12 Aug 2009 03:32:59 -0500

Hi, Jari,
Since I need to post some of the text before publishing anyway, please
take a look inline which address all of your comments.

Thanks and sorry for the delay.

Regards,
Ahmad

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Saturday, July 25, 2009 9:13 AM
> To: [email-masked]; [email-masked]
> Subject: AD review of draft-ietf-metxt-binding-revocation
> 
> I have reviewed this draft. It is basically in very good 
> shape, but I did see a few minor issues which I would like to 
> get corrected before last call.
> 
> Here are my detailed comments:
> 
> Section 5 talks about NATs and UDP encapsulation, but only 
> with respect to proxy mobility. Client mobility case should 
> be handled as well.
[Ahmad]

I updated the whole section as follows, please let me know if that
address your comment or if I need to add more details.

"
5.  Binding Revocation Messages over IPv4 Transport Network

   In some deployments, the network between the mobile access gateway
   and the local mobility anchor may only support IPv4 transport.
   Another case is when a mobile node which support client mobile IPv6
   roam to an access network where only IPv4 addressing and transport is
   supported.  In this case, the mobile node is required to register an
   IPv4 home address with its home agent using a mobile IPv6 Binding
   Update message.

   If the Proxy Binding Update and Proxy Binding Acknowledgment messages
   or the Binding Update and Binding Acknowledgement messages are sent
   using UDP encapsulation to traverse NATs, then the Binding Revocation
   messages are sent using the same UDP encapsulation.  The same UDP
   port that was used for exchanging the Proxy Binding Update and Proxy
   Binding Acknowledgement or the Binding Update and Binding
   Acknowledgement messages will also be used when transporting Binding
   Revocation messages over IPv4 using UDP encapsulation.  In other
   words, the destination UDP port of the Binding Revocation Indication
   message MUST be set to the source UDP port of the latest successfully
   processed Proxy Binding Update or Binding Update message which is
   already saved in the mobile node BCE.  For more details on tunneling
   Proxy Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, see
   [ID-PMIP6-IPv4] and [RFC5555], respectively.
"

> 
> The list of fields after Figure 4 might be more readable if 
> you included all fields, such as MH Type.

[Ahmad]
Sure, what about the following:

"
   MH Type

      <IANA-TBD> which identifies the mobility message as a Binding
      Revocation message.

   Reserved

      8-bit field reserved for future use.  The value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

   Checksum

      16-bit unsigned integer.  This field contains the checksum of the
      Mobility Header.  The checksum is calculated as described in
      [RFC3775].

   Binding Revocation Type

      8-bit unsigned integer.  It defines the type of the Binding
      Revocation Message.  It can be assigned one of the following
      values:

          0  Reserved
          1  Binding Revocation Indication Message
          2  Binding Revocation Acknowledgement Message
          All other values are reserved

   Binding Revocation Message Data

      The Binding Revocation Message Data follows the Binding Revocation
      Message format that is defined in this document for the specified
      value in the Binding Revocation Type field.  In this
      specification, it is either a Binding Revocation Indication as in
      Section 6.1 or Binding Revocation Acknowledgement as in
      Section 6.2.
"

> 
> >    Indication message, the responder MUST constructs the Binding
> MUST construct
> 
> >    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 them, it prevents any possible man in the middle
> >    reflection attack.
> >   
> 
> Its not clear to me what attacks you are talking about here. 
> Reflection attacks normally mean that the attacker sends a 
> packet that a third party responds to and sends the response 
> to the victim.
> 
> Perhaps you meant to say "... prevents the processing of a 
> message not constructed by an authorized party"?

[Ahmad]
Sure, here is the updated text:

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

> 
> >    BCE that belong to a specific realm, e.g. 
> @companyabc.com, that are
> 
> Please use example.com instead.
> 
> > wildcard
> >    NAI, e.g. [email-masked], to identify all the mobile nodes BCEs
> >    that need to be removed.
> >   
> You need to specify what the syntax of the wildcard format 
> is. Note that '*' is a legal character in the username 
> portion of a NAI [RFC4282], so I would recommend considering 
> another syntax (such as @example.com).

[Ahmad]
After thinking of this a little more, I think your suggestion of using
@example.com" is much easier. So here the modified text:

"
   When the local mobility anchor needs to revoke all mobile nodes proxy
   BCE that belong to a specific realm, e.g. @example.com, that are
   registered with the local mobility anchor and hosted at the mobile
   access gateway, the local mobility anchor MUST set the Global (G) bit
   and set the value of the Revocation Trigger field to "Revoking
   Mobility Node Local Policy".  In this case, the local mobility anchor
   MUST include a mobility option in the Binding Revocation Indication
   to identify the impacted bindings, e.g., MN-ID option with an NAI
   value of @example.com, to identify all the mobile nodes BCEs that
   have a MN-ID with a realm that matches the NAI value in the received
   MN-ID option and need to be removed.
"

> 
> I would like to change the retranmission procedure to use an 
> exponential back-off, in a style similar to RFC 3775, Section 
> 11.8. This procedure is both more friendly to other traffic 
> in a congestion situation, as well as faster in resending a 
> lost first packet.

[Ahmad]
Sure. Here is the updated text:

"
7.3.  Retransmission of Binding Revocation Indication

   If the sending mobility entity does not receive a Binding Revocation
   Acknowledgement in response to the outstanding initial Binding
   Revocation Indication before the InitMINDelayBRIs timer expires, the
   mobility entity, e.g.  LMA, SHOULD retransmit the same BRI message up
   to the BRIMaxRetriesNumber as defined in Section 12.

   The retransmissions by the sending mobility entity MUST use an
   exponential back-off process in which the timeout period is doubled
   upon each retransmission, until either the node receives a response
   or the timeout period reaches the value MAX_BRACK_TIMEOUT.  The
   sending mobility entity MAY continue to send these messages at this
   slower rate up to the BRIMaxRetriesNumber.

   If the revoking mobility entity does not receive a Binding Revocation
   Acknowledgement message after the maximum number of retransmits have
   been sent, the revoking mobility entity can clean the mobile node
   binding cache and all resources associated with this binding.  The
   revoking mobility entity may log the event.
"

Also a new MAX_BRACK_TIMEOUT has been defined under section 12:

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

> Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Aug 2009 12:06:46 +0300

Ahmad,

>    [ID-PMIP6-IPv4] and [RFC5555], respectively.

Looks good to me.

>       Section 6.1 or Binding Revocation Acknowledgement as in

OK

>    that was not constructed by an authorized party.

OK

>    MN-ID option and need to be removed.

OK

>       The default is 2 seconds.

Looks good to me.

Jari

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 12 Aug 2009 09:30:08 -0500

Hi,
We have submitted rev 08 which addresses all of Jar's comments.
Thanks.

Regards,
Ahmad

+++++++++++++++++++++++++++++++++++++

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, August 12, 2009 9:00 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-mext-binding-revocation-08.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Mobility EXTensions for IPv6 Working
Group of the IETF.

	Title           : Binding Revocation for IPv6 Mobility
	Author(s)       : A. Muhanna, et al.
	Filename        : draft-ietf-mext-binding-revocation-08.txt
	Pages           : 41
	Date            : 2009-08-12

This document defines a binding revocation mechanism to terminate a
mobile node's mobility session and the associated resources.  These
semantics are generic enough and can be used by mobility entities in the
case of Mobile IPv6 and its extensions.  This mechanism allows the
mobility entity which initiates the revocation procedure to request its
corresponding one to terminate either one, multiple or all specified
binding cache entries.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-0
8.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

> Sent: Wednesday, August 12, 2009 4:07 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]; [email-masked]
> Subject: Re: AD review of draft-ietf-metxt-binding-revocation
> 
> Ahmad,
> 
> >> The list of fields after Figure 4 might be more readable if you 
> >> included all fields, such as MH Type.
> >>     
> >
> > [Ahmad]
> >> Reflection attacks normally mean that the attacker sends a packet 
> >> that a third party responds to and sends the response to 
> the victim.
> >>
> >> Perhaps you meant to say "... prevents the processing of a message 
> >> not constructed by an authorized party"?
> >>     
> >
> > [Ahmad]
> is. Note 
> >> that '*' is a legal character in the username portion of a NAI 
> >> [RFC4282], so I would recommend considering another syntax 
> (such as 
> >> @example.com).
> >>     
> >
> > [Ahmad]
> >> exponential back-off, in a style similar to RFC 3775, 
> Section 11.8. 
> >> This procedure is both more friendly to other traffic in a 
> congestion 
> >> situation, as well as faster in resending a lost first packet.
> >>     
> >
> > [Ahmad]

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 12 Aug 2009 16:39:05 -0700

Hello Ahmad,

Thanks for updating the draft. I have some comments on the text below.

>    Acknowledgement messages will also be used when transporting Binding

Shouldn't we say "The same source and destination IPv4 addresses and UDP port numbers that were used to transmit the ..."

Also, maybe a matter of taste but IMHO it would be more logic that the BU and BA are mentioned before the PBU and PBA.

>    [ID-PMIP6-IPv4] and [RFC5555], respectively.

Here you're only covering the BRI sent by LMA to MAG, but you don't cover sending BRA, neither BRI being sent from MAG to LMA. Is this intentional? I think we ought to be complete... 

And again, I think it's better to mention BU before PBU.

Best,

--julien

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Aug 2009 07:12:58 +0300

At least the first comment from Julien is something that probably should 
be fixed. Ahmad, feel free to make these updates by posting a new draft, 
even if the Last Call is going on. Or you could wait until there's more 
comments.

Jari

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Aug 2009 01:54:49 -0500

Hi Julien,
Please inline.

Regards,
Ahmad

> From: Laganier, Julien [mailto:[email-masked]] 
> Sent: Wednesday, August 12, 2009 6:39 PM
> To: Muhanna, Ahmad (RICH1:2H10); Jari Arkko; 
> [email-masked]; [email-masked]
> Subject: RE: AD review of draft-ietf-metxt-binding-revocation
> 
> Hello Ahmad,
> 
> Shouldn't we say "The same source and destination IPv4 
> addresses and UDP port numbers that were used to transmit the ..."

[Ahmad]
Sure, we will fix this one. Please see below.

> 
> Also, maybe a matter of taste but IMHO it would be more logic 
> that the BU and BA are mentioned before the PBU and PBA.
> 
[Ahmad]
Good taste Julien! :) Personally, I do not see any difference or
significance value to which is mentioned first.

> Here you're only covering the BRI sent by LMA to MAG, but you 
> don't cover sending BRA, neither BRI being sent from MAG to 
> LMA. Is this intentional? I think we ought to be complete... 

[Ahmad]
In the first sentence we used Binding Revocation messages to avoid
mentioning BRI and BRA separately in order to optimize the text.
However, when the BRI was mentioned, we should have said, for example.
The idea here is just to clarify the first sentence. So what about the
following:
"
   If the Proxy Binding Update and Proxy Binding Acknowledgment messages
   or the Binding Update and Binding Acknowledgement messages are sent
   using UDP encapsulation to traverse NATs, then the Binding Revocation
   messages are sent using the same UDP encapsulation.  The same UDP
   port, source IPv4 address, and destination IPv4 address that were
   used for exchanging the Proxy Binding Update and Proxy Binding
   Acknowledgement or the Binding Update and Binding Acknowledgement
   messages will also be used when transporting Binding Revocation
   messages over IPv4 using UDP encapsulation.  In other words, e.g.,
   the destination UDP port, the destination IPv4 address, and the
   source IPv4 address of the Binding Revocation Indication message MUST
   be set to the source UDP port, source IPv4 address, and destination
   IPv4 address of the latest successfully processed Proxy Binding
   Update or Binding Update message, respectively.  For more details on
   tunneling Proxy Mobile IPv6 and Mobile IPv6 signaling messages over
   IPv4, see [ID-PMIP6-IPv4] and [RFC5555], respectively."

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Aug 2009 01:56:51 -0500

Hi, Jari,
Sure will fix it. Will wait a couple of days just in case we receive
more comments and then will publish a new revision.

Thanks.

Regards,
Ahmad

> Sent: Wednesday, August 12, 2009 11:13 PM
> To: Laganier, Julien
> Cc: Muhanna, Ahmad (RICH1:2H10); 
> At least the first comment from Julien is something that 
> probably should be fixed. Ahmad, feel free to make these 
> updates by posting a new draft, even if the Last Call is 
> going on. Or you could wait until there's more comments.
> 
> Jari
> 
> Laganier, Julien wrote:
> > Hello Ahmad,
> >
> > Also, maybe a matter of taste but IMHO it would be more 
> logic that the BU and BA are mentioned before the PBU and PBA.
> >
> >   
> > Here you're only covering the BRI sent by LMA to MAG, but 
> you don't cover sending BRA, neither BRI being sent from MAG 
> to LMA. Is this intentional? I think we ought to be complete... 
> >

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 13 Aug 2009 11:26:57 -0700

Hello Ahmad,

Pls. see below.

[...]
>    IPv4, see [ID-PMIP6-IPv4] and [RFC5555], respectively.

I still feel you're missing the source port in the above, aren't you? I modified a bit your text below:

    If the Proxy Binding Update and Proxy Binding Acknowledgment messages
    or the Binding Update and Binding Acknowledgement messages are sent
    using UDP encapsulation to traverse NATs, then the Binding Revocation
    messages are sent using the same UDP encapsulation.  The same UDP source 
    and destination port numbers and IPv4 addresses used for exchanging
    the Proxy Binding Update and Proxy Binding
    Acknowledgement or the Binding Update and Binding Acknowledgement
    messages will also be used when transporting Binding Revocation
    messages over IPv4 using UDP encapsulation.  For example, the source UDP
    port number, the destination UDP port number, the source IPv4 address, 
    and the destination IPv4 address of the Binding Revocation Indication
    message MUST be set to the destination UDP port number, the source UDP
    port number, destination IPv4 address, and source IPv4 address of the
    latest successfully processed Proxy Binding Update or Binding Update
    message received, respectively.  For more details on tunneling Proxy
    Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, see 
    [ID-PMIP6-IPv4] and [RFC5555], respectively.

What do you think?

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 13 Aug 2009 14:04:02 -0500

Hi Julien,

> I still feel you're missing the source port in the above, 
> aren't you? I modified a bit your text below:
> 
[Ahmad]
Perfect. Thanks!