Subject: [netlmm] Comments on draft-ietf-netlmm-grekey-option-05.txt

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 18 Feb 2009 16:35:39 -0800

Hello,

The draft has substantial number of changes since version 03. I read 
through the whole document again. Most of the comments are either minor 
or editorial.

> Abstract
> 
>    This specification defines a new Mobility Option for allowing the
>    mobile access gateway and the local mobility anchor to negotiate GRE
>    (Generic Routing Encapsulation) encapsulation mode and exchange the
>    downlink and uplink GRE keys which are used for marking the downlink
>    and uplink traffic that belong to a specific mobility session.  In
>    addition, the same mobility option is used to explicitly negotiate
>    the GRE encapsulation mode only without exchanging the GRE keys.

Re-word the last sentence to

    In
    addition, the same mobility option can be used to negotiate the
    GRE encapsulation mode without exchanging the GRE keys.

> 1.  Introduction
> 
>    Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile IPv6
>    support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4
>    encapsulation modes [RFC2473][RFC2003] for the tunneled traffic
>    between the local mobility anchor and the mobile access gateway.
>    There are scenarios where these encapsulation modes are not
>    sufficient to uniquely identify the destination of packets of a
>    specific binding.  

"binding" is a new term. I suggest using "mobility session" as described 
in RFC 5213.

>    This specification defines the GRE Key option to be used for the
>    negotiation of GRE encapsulation mode and exchange of the uplink and
>    downlink GRE keys.  The negotiated downlink and uplink GRE keys can
>    be used for marking the downlink and uplink traffic for a specific
>    mobility session.  In addition, this specification enables the mobile
>    access gateway and the local mobility anchor to explicitly negotiate
>    the GRE encapsulation mode only using the GRE Key mobility option
>    while omitting the GRE Key Identifier field. .

Re-word the last sentence to

    In addition, this specification enables the mobile
    access gateway and the local mobility anchor to negotiate the use
    of GRE encapsulation mode without exchanging the GRE keys.

>    A Policy Check
> 
>       When LMA receives an initial, handoff-triggered Binding Lifetime

s/initial/initial Binding Update/

>       Extension, or Binding Lifetime Extension Proxy Binding Update for
>       a mobility session, the LMA determines if the GRE encapsulation
>       mode only or GRE encapsulation and GRE keys are required based on
>       a policy check.  This policy could be a per MAG-LMA peer, a per-

s/MAG-LMA peer/MAG-LMA pair/

>    The LMA and the MAG will be able to distinguish each mobile node
>    flow(s) based on the GRE key present in the GRE header of the
>    tunneled payload packet, and route them accordingly.  However, the
>    GRE keys as in this specification apply to the individual mobility
>    binding updated by the Proxy Binding Update but not to all bindings
>    that the mobile may have registered following procedures described in
>    [ID-MCoA].

I don't understand this. In [ID-MCoA], the mobile node includes binding 
identifiers in the binding update to bind multiple CoAs to the same home 
address. In PMIPv6, these procedures are not invoked, since the mobile 
node is not sending the binding update. So its not clear what the last 
sentence is trying to say. Did you want to say that the GRE keys are 
always per Proxy CoA? If the LMA allows the mobile node to be connected 
via multiple Proxy CoAs, the GRE keys will be different per Proxy CoA? 
Not clear.

>    o  After receiving a successful Proxy Binding Acknowledgment message
>       with the GRE Key option and the uplink GRE key included in the GRE
>       Key Identifier field, the mobile access gateway MUST update the
>       related three fields in the mobile node Binding Update List entry
>       described in Section 4.1.  Additionally, the MAG MUST use the
>       assigned uplink GRE Key for tunneling all the traffic that belong
>       to this mobile node BUL entry and is originated from the mobile
>       node before forwarding the tunneled traffic to the LMA.

I suggest deleting the last sentence. The last paragraph in section 4.1 
already says

    o  The uplink GRE key used in the GRE encapsulation header of the
       tunneled payload packet from the mobile access gateway to the
       local mobility anchor that is originating from the mobile node.

No need to repeat the text.

>    o  If the mobile access gateway sent a Proxy Binding Update message
>       with the GRE Key option and the downlink GRE key included and
>       received a successful Proxy Binding Acknowledgement message with a
>       status code <GRE KEY OPTION NOT REQUIRED>, the mobile access
>       gateway MUST consider that GRE encapsulation and GRE keys is not
>       required for this specific mobility binding.  The MAG follows
>       procedures in Proxy Mobile IPv6 specification [RFC5213] for the
>       handling of uplink and downlink traffic for this mobility binding
>       and MUST NOT include the GRE Key option in any subsequent Proxy
>       Binding Update message that is sent to the LMA for this mobility
>       session.

This paragraph uses both "mobility binding" and "mobility session". It 
should just use "mobility session".

> 6.2.  Proxy Binding Update Message Extension
> 
>    This specification extends the Proxy Binding Update message with one
>    new flag.  The flag is shown and described below.
> 
> 
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                       |          Sequence #           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |A|H|L|K|M|R|P|F|T|  Reserved   |           Lifetime            |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
>                   Figure 3: Proxy Binding Update message
> 
> 
>    TLV-header Format (T)
> 
>       When set, this flag indicates that the mobile access gateway
>       requests the use of the TLV-header for encapsulating IPv6-or-IPv4
>       in IPv4.  The TLV-header format is described later in this
>       specification.

You should probably say none of the other fields or flags in the binding 
update are modified by this document.

> 6.3.  Proxy Binding Acknowledgement Message Extension
> 
>    This specification extends the Proxy Binding Acknowledgement message
>    with a new flag.  This new flag is shown and described below.
> 
> 
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                       |    Status     |K|R|P|T|   Res |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |           Sequence #          |           Lifetime            |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
>               Figure 4: Proxy Binding Acknowledgement Message
> 
>    TLV-header Format (T)
> 
>       When set, this flag indicates that the sender of the Proxy Binding
>       Acknowledgement (LMA) supports tunneling IPv6-or-IPv4 in IPv4
>       using TLV-header format.

Same as above.

> 7.1.  Tunneling Format
> 
>    When GRE encapsulation mode only or GRE encapsulation and GRE keys
>    have been negotiated between the mobile access gateway and the local
>    mobility anchor for a specific mobility session, the mobile access
>    gateway is allowed to use various tunneling formats depending on the
>    mobile access gateway location and the networks's capabilities
>    between the MAG and the LMA.  

Whether you use the GRE keys or not with GRE encapsulation, there is no 
change in the tunneling formats. So please simplify the above sentence.

> While using GRE encapsulation, the
>    mobile access gateway can tunnel IPv6-or-IPv4 in IPv6 and IPv6-or-
>    IPv4 in IPv4 using vanilla GRE tunneling based on what described in
>    [RFC5213] and [ID-PMIP6-IPv4], or use UDP-based encapsulation to
>    tunnel IPv6-or-IPv4 in IPv4.

The above is hard to understand. Suggest breaking it up.

>    If UDP-based tunneling is used between the mobile access gateway and
>    the local mobility anchor after NAT has been detected in the path
>    between the MAG and the LMA while GRE encapsulation is required, the
>    TLV-header UDP tunneling format as shown in Figure 5 and described in
>    this specification MUST be used.

Re-phrase as

   If UDP-based tunneling is used between the mobile access gateway and
   the local mobility anchor after NAT has been detected in the path
   between the MAG and the LMA while GRE encapsulation is required, the
   TLV-header UDP tunneling format as shown in Figure 5 MUST be used.

You might want to add a reference to section 7.2 in the above sentence 
when you mention the TLV header.

> 7.3.  Mobile Access Gateway Operation
> 
>    When sending an IPv6 packet containing a Proxy Binding Update while

Re-word as "When sending a Proxy Binding Update message while...."

>    If the mobile access gateway sent a Proxy Binding Update with the GRE
>    key option included and the TLV-header Format (T) flag set and
>    received a successful Proxy Binding Acknowledgement with the GRE key
>    option included, the TLV-header Format (T) flag cleared, and the
>    status code <GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED>, the mobile
>    access gateway MUST NOT use GRE encapsulation for this mobility
>    session with UDP-based tunneling.  

Re-word as

   If the mobile access gateway receives a Proxy Binding
   Acknowledgement with the status <GRE TUNNELING BUT TLV-HEADER
   NOT SUPPORTED> in response to a Proxy Binding Update with the
   GRE key option and the 'T' flag set, the mobile access gateway
   MUST use GRE encapsulation for this mobility session without UDP
   or TLV headers. A Proxy Binding Acknowledgement message with
   status <GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED> will have
   the 'T' flag cleared.

> 7.3.1.  Sending and Receiving Data Packets
> 
>    When the mobile access gateway is located in an IPv6-enabled network,
>    the mobile access gateway encapsulates and decapsulates IPv6 packets
>    as described in [RFC5213].  In this case, IPv4 payload traffic is
>    encapsulated in IPv6 packets before being sent to the local mobility
>    anchor as described in [ID-PMIP6-IPv4].  In addition, if the mobile
>    access gateway is located in an IPv4-only network and no UDP
>    tunneling format is used, the mobile access gateway encapsulates and
>    decapsulates IPv4 packets as described in [ID-PMIP6-IPv4].  IPv6
>    traffic is encapsulated in IPv4 packets following the procedure in
>    [ID-PMIP6-IPv4] before being sent to the local mobility anchor.

Is the above paragraph relevant to the document? It assumes GRE 
encapsulation is not used. RFC 5213 and the PMIPv6 IPv4 support document 
already describe the above.

>          IPv4 header (src=V4CoA, dst=HA_V4ADDR)
> 
>          [UDP Header]
> 
>          [TLV Header]
> 
>          [GRE Header]
> 
>          IPv6/v4 header (src=V6/V4HoA, dst=V6/V4CN)
> 
>          Upper Layer protocols
> 
> 
>       Figure 8: IPv6-or-IPv4 over IPv4 Using TLV-header UDP Tunneling

How is figure 8 different from figure 5? Can't we just refer to figure 5 
here?

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 18 Feb 2009 23:17:27 -0600

Hi Vijay,
Thanks for the review and comments.
Please see inline.

Regards,
Ahmad

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Wednesday, February 18, 2009 6:36 PM
> To: Muhanna, Ahmad (RICH1:2H10); Jari Arkko
> Cc: [email-masked]
> Subject: Comments on draft-ietf-netlmm-grekey-option-05.txt
> 
> Hello,
> 
> The draft has substantial number of changes since version 03. 
> I read through the whole document again. Most of the comments 
> are either minor or editorial.
> 
> > Abstract
> > 
[Ahmad]
Sure.

> "binding" is a new term. I suggest using "mobility session" 
> as described in RFC 5213.

[Ahmad]
No problem.

>     of GRE encapsulation mode without exchanging the GRE keys.

[Ahmad]
Yes, I agree, simpler.

> s/initial/initial Binding Update/

[Ahmad]
Hmmm.. I guess the intention is to use one instance of "Proxy Binding
Update for all of these cases, initial, handoff-triggered, etc. May be
the question is: does using Binding Lifetime Extension Proxy Binding
Update makes sense or not? The last time I checked, RFC5213 uses this in
several places.

> s/MAG-LMA peer/MAG-LMA pair/

[Ahmad]
Sure.

> I don't understand this. In [ID-MCoA], the mobile node 
> includes binding identifiers in the binding update to bind 
> multiple CoAs to the same home address. In PMIPv6, these 
> procedures are not invoked, since the mobile node is not 
> sending the binding update. So its not clear what the last 
> sentence is trying to say. Did you want to say that the GRE 
> keys are always per Proxy CoA? If the LMA allows the mobile 
> node to be connected via multiple Proxy CoAs, the GRE keys 
> will be different per Proxy CoA? 
> Not clear.

[Ahmad]
Based on the current GRE draft and PMIPv6 specification, the GRE key is
applicable ONLY to the mobile node binding which was updated by the
PBU/PBA exchange. In case that there are other bindings for the same
mobile node, these bindings should not be updated. In other words, there
could be in the future another mechanism for MCoA for PMIPv6 and GRE
option can be used then to address multiple bindings but in the current
draft it is only to a single mobile node binding.

Does this makes it any better?

> I suggest deleting the last sentence. The last paragraph in 
> section 4.1 already says
> 

[Ahmad]
I guess the text at the end of section 4.1. describes what the uplink
GRE key is used for. However, the above text mandate the MAG to use the
uplink GRE to tunnel all packets from the mobile node to the LMA.
Although, the text seems similar but , IMO, they serve a little
different purposes.

> This paragraph uses both "mobility binding" and "mobility 
> session". It should just use "mobility session".

[Ahmad]
Sure, will take this as a global comment to always use mobility session.

> >                                       |          Sequence # 
>           |
> You should probably say none of the other fields or flags in 
> the binding update are modified by this document.

[Ahmad]
Sure. That is a good idea. 

> >                                       |    Status     
> |K|R|P|T|   Res |
> >       |           Sequence #          |           Lifetime  
>           |

[Ahmad]
Ok.

> Whether you use the GRE keys or not with GRE encapsulation, 
> there is no change in the tunneling formats. So please 
> simplify the above sentence.

[Ahmad]
True. I understood Jari comment as we need to clearly mention that all
modes are covered. But, I could have used something simpler. Please see
the text below the following comment.

> The above is hard to understand. Suggest breaking it up.

[Ahmad]
What about the following which also includes the above simplification:

   When GRE encapsulation is used, the mobile access gateway is allowed
   to use various tunneling formats depending on the mobile access
   gateway location and the networks's capabilities between the MAG and
   the LMA.  Using vanilla GRE encapsulation, the mobile access gateway
   can tunnel IPv6-or-IPv4 payload packet in IPv6 or in IPv4 following
   the rules in [RFC5213] and [ID-PMIP6-IPv4].

>    TLV-header UDP tunneling format as shown in Figure 5 MUST be used.
[Ahmad]
Sure.

> You might want to add a reference to section 7.2 in the above 
> sentence when you mention the TLV header.
> 

[Ahmad]
Ok.

>    status <GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED> will have

[Ahmad]
Thanks!

> Is the above paragraph relevant to the document? It assumes 
> GRE encapsulation is not used. RFC 5213 and the PMIPv6 IPv4 
> support document already describe the above.

[Ahmad]
You are right. Removing it is a good simplification. 
Done!

> How is figure 8 different from figure 5? Can't we just refer 
> to figure 5 here?

[Ahmad]
Hmm.. I guess they are the same. However, the original intention for
figure 5 to be in a generic form that is applicable to either end of the
tunnel. However, figure 8 include the source and destination addresses
of the outer IP header and the payload packet. I guess we can capture
that information in a text form and continue to reference figure 5.

Once again, Thanks Vijay for the detailed review!

Best Regards,
Ahmad

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 19 Feb 2009 12:10:16 -0800

Hi Ahmad,

> Update makes sense or not? The last time I checked, RFC5213 uses this in

I thought you wanted to say initial binding update as well as 
handoff-triggered binding lifetime extension. Now the text currently 
just says "initial". Initial what? Initial Proxy Binding Update or 
Initial initial Binding Lifetime Extension?

> Does this makes it any better?

Ok, got it. No need for any changes then.

Ok.

>    the rules in [RFC5213] and [ID-PMIP6-IPv4].

Sounds good.

> that information in a text form and continue to reference figure 5.

Sounds good to me.

Thanks
Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 19 Feb 2009 12:43:03 -0800 (PST)

Hi Ahmad,

One suggested change in Section 6.1 below on the option
scope.

Sri

> Section 6.1 GRE Key Option
>
> A new mobility option, the GRE Key option, is defined for use
> in the Proxy Binding Update and Proxy Binding Acknowledgment
> messages exchanged between the mobile access gateway and the
> local mobility anchor.  This option can be used for
> negotiating GRE encapsulation mode only or GRE encapsulation
> and exchanging the downlink and uplink GRE keys.  These GRE
> keys can be used by the peers in all GRE encapsulated payload
> packets for marking that specific mobile node's data traffic.
>

We have discussed this in the past to not to make the option
restricted to PBU/PBA. It was agreed by Raj, Charlie and few
others. Vijay and Ahmad also agreed to this, Jari also agreed
to this at the MEXT meeting when discussing this work item. If
there is no contention we need to insert these 2 lines.

Insert:

This option can also be used in Binding Update and Binding
Acknowledgment messages exchanged between a mobile node and a
home agent.

Thanks
Sri

> This option can be used for negotiating GRE encapsulation
> mode only or GRE encapsulation and exchanging the downlink
> and uplink GRE keys.  These GRE keys can be used by the peers
> in all GRE encapsulated payload packets for marking that
> specific mobile node's data traffic.

>> | A|H|L|K|M|R|P|F|T|  Reserved   |           Lifetime            |
> You might want to add a reference to section 7.2 in the above sentence when 
> you mention the TLV header.
>
> Is the above paragraph relevant to the document? It assumes GRE encapsulation 
> is not used. RFC 5213 and the PMIPv6 IPv4 support document already describe 
> the above.
>
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 19 Feb 2009 15:11:38 -0600

Hi Sri,

> Subject: Re: [netlmm] Comments on 
> draft-ietf-netlmm-grekey-option-05.txt
> 
> 
> Hi Ahmad,
> 
> One suggested change in Section 6.1 below on the option scope.
> 
> Sri
> 
> 
> 
> > A new mobility option, the GRE Key option, is defined for 
> use in the 
> > Proxy Binding Update and Proxy Binding Acknowledgment messages 
> > exchanged between the mobile access gateway and the local mobility 
> > anchor.  This option can be used for negotiating GRE encapsulation 
> and uplink 
> > GRE keys.  These GRE keys can be used by the peers in all GRE 
> > encapsulated payload packets for marking that specific 
> mobile node's 
> > data traffic.
> >
> 
> to this at the MEXT meeting when discussing this work item. 
> If there is no contention we need to insert these 2 lines.
> 

[Ahmad]
What you just mentioned above matches my recollection to make this
option available to BU/BA.
Sure, if there is no objection, I can insert these two lines under
section 6.1.

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 19 Feb 2009 15:38:06 -0600

Hi Vijay,

> Subject: Re: Comments on draft-ietf-netlmm-grekey-option-05.txt
> 
> Hi Ahmad,
> 
> Ahmad Muhanna wrote:
> 
> >>>    A Policy Check
> >>>
> > Update makes sense or not? The last time I checked, RFC5213 
> uses this 
> > in several places.
> 
> handoff-triggered binding lifetime extension. Now the text 
> currently just says "initial". Initial what? Initial Proxy 
> Binding Update or Initial initial Binding Lifetime Extension?

[Ahmad]
Yes. I believe we are both on the same page. 

Instead of saying:
When LMA receives an initial Proxy Binding Update, handoff-triggered
Binding Lifetime Extension Proxy Binding Update, or Binding Lifetime
Extension Proxy Binding Update for a mobility session, 

I just tried to simplify the text by saying:
When LMA receives an initial, handoff-triggered Binding Lifetime
Extension, or Binding Lifetime 
Extension Proxy Binding Update for a mobility session, 

Best Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 24 Feb 2009 09:42:00 -0600

Hi All,

> > restricted to PBU/PBA. It was agreed by Raj, Charlie and 
> few others. 
> > Vijay and Ahmad also agreed to this, Jari also agreed to 
> this at the 
> > MEXT meeting when discussing this work item.
> What you just mentioned above matches my recollection to make 
> this option available to BU/BA.
> Sure, if there is no objection, I can insert these two lines 
> under section 6.1.
> 
> > Insert:
> > 

[Ahmad]
Since there was no objection, I will insert the text suggested by Sri
under section 6.1. in the new revision.

Regards,
Ahmad