Subject: Re: [netlmm] Last call notice: draft-ietf-netlmm-grekey-option

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 13 Jan 2009 09:54:09 -0600

Hi Jouni,
Thanks for your detailed review, please see comments inline.

Regards, 
Ahmad

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of jouni korhonen
Sent: Monday, January 12, 2009 6:12 AM
To: Soininen Jonne (NSN - FI/Espoo)
Cc: [email-masked]
Subject: Re: [netlmm] Last call notice: draft-ietf-netlmm-grekey-option

Hi,

This is slightly lengthy review.. I do not have many, if any, real
technical comments as I think that part is now OK and the document is
ready from technical point of view. My comments are marked with [JiK]:

1.  Introduction

  The base 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

[JiK] s/[RFC2473] , [RFC2003]/[RFC2473][RFC2003] 
 
[Ahmad]
ok. 

  between the local mobility anchor and the mobile access gateway.

[JiK] Introduce the (LMA) and (MAG) acronyms here as they are used
     later in the draft. 
 
[Ahmad]
The draft reference RFC5213 as a source for terminology. I do not think
it is necessary to introduce it again here.

  There are scenarios where these encapsulation modes are not
  sufficient to uniquely identify the destination of packets of a
  specific flow.  Thus, there is a need for an encapsulation mode with
  richer semantics.  The Generic Routing Encapsulation [RFC2784] and

[JiK] Introduce (GRE) as the acronym is used later in the draft.

  the Key extension as defined in [RFC2890], has the required semantics
  to allow such distinction for use in Proxy Mobile IPv6.

  This document defines the GRE Key option to be used for the
  negotiation of GRE encapsulation mode and the 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 mobile node session or a specific flow.

[JiK] "mobile node session".. I cannot find the definition for this
     neither in this draft or in RFC5213. I would suggest using
     something else that can be found in RFC5213 or the give a
     definition in Section 2. 
 
[Ahmad]
sure, we can use mobile node binding. if acceptable, we can update some
other text where it is applicable. 

2.2.  Terminology

  All the general mobility related terminology and abbreviations are to
  be interpreted as defined in Mobile IPv6 specification [RFC3775] and
  Proxy Mobile IPv6 specification [RFC5213].  The following terms are
  used in this document.

  Downlink Traffic

     The traffic in the tunnel between the local mobility anchor and
     the mobile access gateway, heading towards the mobile access
     gateway and tunneled at the local mobility anchor.  This traffic
     is also called forward direction traffic.

  Uplink Traffic

     The traffic in the tunnel between the mobile access gateway and
     the local mobility anchor, heading towards the local mobility
     anchor and tunneled at the mobile access gateway.  This traffic is
     also called reverse direction traffic.

[JiK] Any specific reason to keep the "forward" and "reverse" direction
     traffic terms? They are not used anywhere in the rest of the
     draft. I would suggest removing them. 
 
[Ahmad]
Vijay raised the same comment and the answer was that originally the
draft was referencing forward and reverse only. We agreed to use uplink
and downlink but to keep a reference to forward and reverse because
these terminology is already being used in one SDO. 

  Downlink GRE Key

     The GRE key is assigned by the mobile access gateway and used by
     the local mobility anchor to mark the downlink traffic which

[JiK] Section 3.1 uses term "downlink payload packet".. for the
     consistency I would suggest using the same term here. 
 
[Ahmad]
I think downlink traffic is more generic. although at some time where
more detailed is needed, a reference to downlink payload packet is ok as
you referenced in section 3.1. 

     belongs to a specific mobile node session or flow as described in
     this document.

[JiK] The "mobile node session" again. 
[Ahmad]
please see comment above. 

  Uplink GRE Key

     The GRE key is assigned by the local mobility anchor and used by
     the mobile access gateway to mark the uplink traffic which belongs
     to a specific mobile node session or flow as described in this
     document.

[JiK] Same comments are for the Downlink GRE Key. 
[Ahmad]
please see comment above. 

3.1.  GRE Encapsulation Overview

  Using the GRE Key option defined in this specification, the mobile

[JiK] The draft uses both 'document' or 'specification' when referencing
itself.      
      Use either of them. 
 
[Ahmad]
Is there a problem in using both? 

  access gateway and the local mobility anchor can negotiate GRE
  encapsulation mode and exchange the GRE keys for marking the downlink
  and uplink traffic.

[JiK] Later in this section "uplink payload packet" etc are used. In
general
      I found several terms saying about the same throughout the draft.
E.g.,
      uplink traffic, uplink payload packet, data packet, traffic flow,
      tunneled packet etc. I would suggest aligning the terminology. For
      example when talking about tunneled traffic I would suggest using
      term "uplink/downlink payload packets". I won't list places for
the
      rest of the draft as they are so many. 
 
[Ahmad]
I am not sure if that needs to be addressed. If there is a specific
example where one of these terminologies is not appropriately used or
reflect the intention, we can address it as needed. IMO, these
terminologies are used to reflect the proper level of details that is
addressed in the paragraph, sentence, etc. 

[JiK] I would also like to state is somewhere more clearly that it is
      the "user traffic" that gets encapsulated inside the GRE headers
      and then tunneled inside the PMIP tunnel. It is there in the draft
      but imho could be said more clearly at the beginning of the draft.

[Ahmad]
I think that is clearly understood. of course, user traffic is the one
tunneled, exactly like in Client MIP6 and PMIPv6 using IP-in-IP
encapsulation. I do not think there is a need for that emphasis here. 

  [snip]

  The LMA and the MAG will be able to distinguish each mobile node

[JiK] First uses of the LMA and the MAG. In general the draft uses
      names expanded and as acronyms inconsistently.. even using
      both conventions in the same sentence.  
 
[Ahmad]
These terms have already introduced in RFC5213 which is referenced in
RFC5213. There is no problem at all in using the expanded form and the
acronym itself interchangeably. That is the preferred style that have
been followed in RFC3775, 5213, etc.
 
 I won't list them from
      now on as they are so many. Those should be change to be
      consistent. 
 
[Ahmad]
please see comment above. 

  flow(s) based on the GRE key present in the GRE header of the
  tunneled packet, and route them accordingly.

3.3.  GRE Key Exchange Mechanism

  The following subsections describe how the mobile access gateway and
  the local mobility anchor exchange downlink and uplink GRE keys using
  proxy mobile IPv6 registration procedure.

[JiK] s/proxy mobile/Proxy Mobile 
 
[Ahmad]
It does not reference the protocol name here. so proxy mobile should be
ok. 

3.3.1.  Initial GRE Key Exchange

  When the mobile access gateway determines, based on, e.g., private
  IPv4 address support [RFC1918], the MAG local policy, or the MAG-LMA
  peer agreement, that GRE encapsulation is needed and GRE keys is
  required, the mobile access gateway MUST include the GRE Key option
  in the initial Proxy Binding Update message sent to the local
  mobility anchor.  The mobile access gateway MUST include the downlink

[JiK] The above is a rather long sentence. I would break it into smaller
      ones. 
 
[Ahmad]
hmmm... looks fine to me:-) 
     
  GRE key in the GRE Key Identifier field of the GRE Key option.

  After successfully processes the initial Proxy Binding Update and

[JiK] "After successfullt processes"..? who? Suggest rewriting
      "After the LMA has successfully processed.." 
 
[Ahmad]
The LMA. I believe Vijay pointed out to use "After successfully
processing..." which I agreed to. 

  accepting the downlink GRE key, the LMA MUST include the GRE Key
  option with the uplink GRE key in the GRE Key Identifier field when
  sending a successful Proxy Binding Acknowledgement to the MAG.

[JiK] This is rather complex one sentence paragraph. Suggest rewriting
      the whole paragraph:

 "After the LMA has successfully processed the initial Proxy Binding
  Update and accepted the downlink GRE key, the LMA sends a Binding
  Acknowledgement indicating a success to the MAG. The Binding 
  Acknowledgement MUST include the GRE Key option with the uplink GRE
  Key in the GRE Key Identifier field.
 " 
[Ahmad]
I hope you do not mind keeping the original with Vijay correction. 

3.3.2.  GRE Key Exchange During Binding Re-registration

  If the MAG has successfully negotiated and exchanged the initial GRE
  keys with the LMA for a specific binding, the MAG SHOULD NOT include
  the GRE Key option with the downlink GRE key in the Proxy Binding
  Update which is used for requesting a Binding Lifetime Extension.

  However, during inter-MAG handoff and if the new mobile access
  gateway determines, based on, e.g., private IPv4 address support, the
  MAG local policy, the MAG-LMA peer agreement, or an indication during
  the handoff process, that GRE encapsulation and GRE key exchange is
  required, the new mobile access gateway MUST include the GRE key
  option with the downlink GRE key in the Proxy Binding Update which is
  used for requesting an after handoff Binding Lifetime extension.  In

[JiK] The above sentence is very long and thus hard to understand. 
 
[Ahmad]
hmmm... long.. It is exactly the same number of words as your suggested
text + the description of the use of the PBU at hand.
Seriously, I do not see the complexity and if there is no technical
issue with it, we should keep it.
 
      I would suggest rewriting it. For example:

 "However, during inter-MAG handoff the new MAG MUST include the GRE
  key option with the downlink GRE key in the Proxy Binding Update if
  the GRE encapsulation and the GRE key exchange is required. The new
  MAG determines the GRE requirement e.g., based on private IPv4 address
  support, the MAG local policy, the MAG-LMA peer agreement, or an
  indication during the handoff process."

  this case, the new MAG may either pick a new downlink GRE key or use
  the downlink GRE key that was used by the previous MAG for the same
  binding.  For the new MAG to know the downlink GRE key used by the
  previous MAG, it may require transfer of context from the previous
  MAG to the new MAG during a handover.  Such mechanisms are out-of-
  scope for this document.

[JiK] Up to this point 'handoff' has been used. In the above paragraph
      'handover' is used instead. 
 
[Ahmad]
sure we can use handoff instead. IMO, as long as the two terms have the
same meaning, then it is not an issue to use both of them. 

  If the LMA successfully processes a handoff-triggered Binding
  Lifetime Extension Proxy Binding Update message which contains a GRE
  key option with a downlink GRE key included, the LMA MUST return the
  same uplink GRE key that was exchanged with the previous MAG and is
  saved in the respected BCE.

[JiK] Expand BCE on the first use.  
 
[Ahmad]
sure, fine with me.
 
 Also the sentence is a size of one   paragraph. 
[Ahmad]
That should not be a problem;) 

  If the LMA receives handoff-triggered Binding Lifetime Extension
  Proxy Binding Update message without the GRE key option for a BCE
  that is using GRE keys and GRE encapsulation, the LMA MUST reject the
  Proxy Binding Update by sending a Proxy Binding Acknowledgement
  message with the status field is set to <GRE KEY OPTION REQUIRED> as
  defined in Section 6.2.

[JiK] One sentence paragraph again.

  If the LMA receives a no handoff Binding Lifetime extension Proxy

[JiK] ".. a no handoff Binding.." A bit strange way to say this. 
      Consider a better way of saying. However, I don't have a
      better wording in my mind now.  
 
[Ahmad]
Vijay suggested a new text for this paragraph and I agreed to it. Below
the agreed upon paragraph.
 
<snip>
> Suggest re-writing it as
> 
> Typically, the MAG does not include the GRE Key Option in a Proxy
> Binding Update message sent to refresh an existing binding. 
> However,
> if the LMA receives a Proxy Binding Update from the current MAG to
> extend the existing binding, and the Proxy Binding Update messages
> contains the GRE Key option and the downlink GRE Key identifier, it
> MUST NOT reject the Proxy Binding Update message. In this case,
> the LMA processes the Proxy Binding Update normally and if the
> included downlink GRE key is different than the one saved in the
> respected BCE, the LMA MUST update the BCE with the new downlink 
> GRE
> key.
[Ahmad]
Sure. Looks fine to me. 
<snip> 

  Binding Update message with the GRE key option and the downlink GRE
  key included from the same MAG that is currently hosting the
  respected binding current pCoA, the LMA MUST NOT reject the Proxy

[JiK] Expand pCoA on the first use. 
 
[Ahmad]
thx. 

  Binding Update because of the GRE key option being included in a
  binding reregistration Proxy Binding Update message.  In this case,
  the LMA processes the Proxy Binding Update normally and if the
  included downlink GRE key is different than the one saved in the
  respected BCE, the LMA MUST update the BCE with the new downlink GRE
  key.

4.1.  Extensions to the Conceptual Data Structure

  Every mobile access gateway maintains a Binding Update List entry for

[JiK] BCE is already used in other places of the draft. Why not using
      Binding Update List (BUL) as well? 
 
[Ahmad]
This is very interesting;)
when using the BCE, you commented that needs to be expanded. When having
the expanded form of BUL, you want the acronym. Sure:)

  each currently attached mobile node, as explained in Section 6.1 of
  the Proxy Mobile IPv6 specification [RFC5213].  To support this
  specification, the conceptual Binding Update List entry data
  structure must be extended with the following three new additional
  fields.

  o  A flag indicating whether GRE encapsulation is enabled for the
     mobile node's traffic flows.

  o  The Downlink GRE Key used in the GRE encapsulation header of the
     tunneled packet from the local mobility anchor to the mobile
     access gateway that is destined to the mobile node.  This GRE Key
     is generated by the MAG and communicated to the LMA in the GRE Key
     option in the Proxy Binding Update message.

[JiK] MAG and Mobile Access Gateway used interchangeably. 
[Ahmad]
Yes, that is good:) 

  o  The Uplink GRE Key used in the GRE encapsulation header of the
     tunneled packet from the mobile access gateway to the local

[JiK] tunneled payload packet? 
[Ahmad]
Are you suggesting changing tunneled packet to tunneled payload packet? 

     mobility anchor that is originating from the mobile node.  This
     GRE Key is obtained from the GRE Key Identifier field of the GRE
     Key option present in the received Proxy Binding Acknowledgement
     message sent by the LMA as specified in this document.

4.2.  Operational Summary

  o  If the MAG determines that GRE encapsulation and GRE key is
     required, the MAG MUST include the GRE Key option with the
     downlink GRE key in the GRE Key Identifier field in the Proxy
     Binding Update message that is sent by the mobile access gateway
     to the local mobility anchor.

[JiK] MAG and Mobile Access Gateway used interchangeably. 
[Ahmad]
same as above. 

  o  After receiving a successful Proxy Binding Acknowledgment message
     with the GRE Key option which includes the uplink GRE key, 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 originating from the mobile node before

     forwarding the tunneled traffic to the LMA.

[JiK] tunneling all the payload packets originating..? Also
      MAG and Mobile Access Gateway used interchangeably.

  o  If the mobile access gateway included the GRE Key option in the
     Proxy Binding Update for a specific mobile node and the local
     mobility anchor accepts the Proxy Binding Update by sending a
     Proxy Binding Acknowledgement with a success status code (less
     than 128) other than <GRE KEY OPTION NOT REQUIRED>, but without

     the GRE Key option, then the mobile access gateway MUST consider
     that the local mobility anchor does not support GRE Key option as
     per this specification.  The mobile access gateway SHOULD NOT
     include the GRE Key option in any subsequent Proxy Binding Update
     message that is sent to that LMA.

[JiK] LMA and local mobility anchor used interchangeably. 
[Ahmad]
sure. 

  o  If the mobile access gateway sent a Proxy Binding Update message
     without the GRE Key option, but the received Proxy Binding
     Acknowledgement has the Status Code <GRE KEY OPTION REQUIRED>,
     indicating that the GRE encapsulation and GRE key is required, the
     mobile access gateway SHOULD resend the Proxy Binding Update
     message with the GRE Key option.  If the MAG does not support the
     GRE Key option, the MAG MAY log the event and possibly raise an
     alarm to indicate a possible misconfiguration.

[JiK] MAG and Mobile Access Gateway used interchangeably....

[snip]

5.2.  Operational Summary

  o  After successfully processes a Proxy Binding Update message with

[JiK] "After the LMA has successfully processed a Proxy Binding..." 
[Ahmad]
I prefer the existing style;) 

     the GRE Key option which includes a downlink GRE key in the GRE
     Key Identifier field for Initial GRE Key exchange as in
     Section 3.3.1, the local mobility anchor MUST include the GRE Key
     option with the uplink GRE key in the GRE Key Identifier field
     when responding with a successful Proxy Binding Acknowledgement
     message.

  o  If the GRE tunneling is negotiated and the downlink and uplink GRE
     keys have been exchanged between the mobile access gateway and the
     local mobility anchor for a specific binding, the local mobility
     anchor MUST use the negotiated downlink GRE key in the GRE header
     of every packet that is destined to the mobile node of this
     specific binding over the GRE tunnel to the mobile access gateway.

[JiK] "..of every tunneled payload packet that is.." ? 
[Ahmad]
sure. 

  o  If the received Proxy Binding Update message does not contain the
     GRE Key option, and if the local mobility anchor determines that
     GRE encapsulation and GRE key is required, e.g., overlapping IPv4
     private addressing is in use, LMA local policy or LMA-MAG peer
     policy, the local mobility anchor MUST reject the request and send
     the Proxy Binding Acknowledgement message to the mobile access
     gateway with the status code <GRE KEY OPTION REQUIRED> as defined
     in Section 6.2, indicating that GRE encapsulation and GRE key is
     required.

[JiK] "..that GRE encapsulation and GRE key are required." ? 
[Ahmad]
sure. 

  o  If after receiving Proxy Binding Update message with the GRE Key
     option and successfully processes the Proxy Binding Update, the
     local mobility anchor determines that GRE encapsulation and key
     exchange is not required for this specific binding, e.g., private
 
[JiK] "..exchange are not.." ? 
[Ahmad]
sure. 

     IPv4 addressing is not in use, the LMA MUST send a Proxy Binding
     Acknowledgement message to the MAG with the status code <GRE KEY
     OPTION NOT REQUIRED>.  The local mobility anchor MUST NOT include
     the GRE Key option.

[JiK] "The local LMA MUST NOT include the GRE Key option in that Proxy
      Binding Acknowledgement." ? 
 
[Ahmad]
Is not that understood? 

[snip] 
 
  o  On receiving a packet from the tunnel with the GRE encapsulation
     header, the local mobility anchor MUST use the GRE Key present in
     the GRE extension header to determine the necessary special
     processing for the data packet, e.g., lookup the mobile node's
     home gateway address, determine any special processing or
     treatment for the data packet flow, then remove the encapsulation
     header before forwarding the packet.

[JiK] "data packet"? How about using "payload packet" etc? 
 
[Ahmad]
ok. 

[snip]

  GRE Key Identifier

     32-bit field containing the Downlink or the Uplink GRE Key. This

[JiK] s/Downlink or the Uplink/downlink or the uplink 
 
[Ahmad]
ok. 

     field is present in the GRE Key option only if the GRE keys are
     being exchanged using the Proxy Binding Update and Proxy Binding
     Acknowledgement messages.

[JiK] Maybe it could be said again here that who puts and allocates
      uplink & downlink keys? 
[Ahmad]
I guess that will be over kill. It is already documented; unless the
current is not enough. 

That's all for now.

Cheers,
       Jouni

On Tue, Dec 23, 2008 at 4:11 PM, Soininen Jonne (NSN - FI/Espoo) <
[email-masked]> wrote:
> Hello everybody,
>
> the last call time ended yesterday. It seems that there is no single
mail on
> the list on this last call. So, this WGLC is a failure. I will start a
new
> last call after the holidays as this might have been missed due to the
> discussions on IPv4 support and the holiday preparations...
>
> Cheers,
>
> Jonne.
> ext Soininen Jonne (NSN FI/Espoo) wrote:
>>
>> <chair hat on>
>> Everybody,
>>
>> Hereby we would like to start the last-call on
>> draft-ietf-netlmm-grekey-option. The last call is as follows:
>>
>> Draft: draft-ietf-netlmm-grekey-option-02.txt
>> Start: 8.12.2008
>> End: 22.12.2008 (EOB PST)
>>
>> Please, if you haven't done so, read the draft. If you have read,
comment,
>> and at least acknowledge your ok.
>>
>> Vidya & Jonne
>> <chair hat off>
>>  
>
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
>

_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: jouni korhonen <[email-masked]>
Date: Fri, 16 Jan 2009 10:51:37 +0200

Hi Ahmad,

Minor feedback. See comments inline.

On Jan 13, 2009, at 5:54 PM, Ahmad Muhanna wrote:

> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of jouni korhonen
> sure, we can use mobile node binding. if acceptable, we can update  
> some other text where it is applicable.

"mobile node binding" would be much better.

> draft was referencing forward and reverse only. We agreed to use  
> uplink and downlink but to keep a reference to forward and reverse  
> because these terminology is already being used in one SDO.

That's OK.

> [JiK] The draft uses both 'document' or 'specification' when  
> referencing itself.
>       Use either of them.
>
> [Ahmad]

It is a matter of readability in general. However, not a big deal.

>       I found several terms saying about the same throughout the  
> draft. E.g.,
>       term "uplink/downlink payload packets". I won't list places  
> for the
> example where one of these terminologies is not appropriately used  
> or reflect the intention, we can address it as needed. IMO, these  
> terminologies are used to reflect the proper level of details that  
> is addressed in the paragraph, sentence, etc.

Well, it was a suggestion only. My personal preference would be using  
as much as possible consistent terminology. Again, not a big deal from  
my side.

> I think that is clearly understood. of course, user traffic is the  
> one tunneled, exactly like in Client MIP6 and PMIPv6 using IP-in-IP  

Fair enough. Is there anything that would be needed to say of ESP  
protected user traffic with GRE?

> These terms have already introduced in RFC5213 which is referenced  
> in RFC5213. There is no problem at all in using the expanded form  
> and the acronym itself interchangeably. That is the preferred style  
> that have been followed in RFC3775, 5213, etc.

Well, I did not like that style ;) That's why I pointed it out. But,  
again, this was just a suggestion.

> I hope you do not mind keeping the original with Vijay correction.

Not at all.

> Vijay suggested a new text for this paragraph and I agreed to it.  
> Below the agreed upon paragraph.

Ack. Vijay's text is ok.

> when using the BCE, you commented that needs to be expanded. When  
> having the expanded form of BUL, you want the acronym. Sure:)

I wanted BCE expanded once when you introduce the acronym the first  
time. In case of Binding Update List acronym was never used but only  
the expanded form. I am just after a consistent way of using acronyms.

> Are you suggesting changing tunneled packet to tunneled payload  

Yes. This is related to what I suggested earlier in section 3.1.

>       Binding Acknowledgement." ?

I like explicit text ;) Anyway, just a suggestion again.

Cheers,
	Jouni

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 16 Jan 2009 14:02:55 -0500

RFC 5213 uses "mobility session". Please use that. Don't use "mobile
node binding".

Vijay

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of jouni korhonen
> Sent: Friday, January 16, 2009 12:52 AM
> To: Ahmad Muhanna
> Cc: [email-masked]
> >   All the general mobility related terminology and 
> abbreviations are  
> > to
> >      anchor and tunneled at the mobile access gateway.  
> This traffic  
> > is
> >       tunneled packet etc. I would suggest aligning the 
> terminology.  
> > For

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 16 Jan 2009 13:08:20 -0600

Hi Jouni,
Thanks again. Please see inline.

Regards,
Ahmad

> From: jouni korhonen [mailto:[email-masked]] 
> >
> >
> Fair enough. Is there anything that would be needed to say of 
> ESP protected user traffic with GRE?

[Ahmad]
May be we need to specify the order of the encapsulated headers or at
least that both MAG and LMA need to have the same order. It seems that I
am not in my best shape the last few days;) at least concentration wise!
Do you have any suggested text?

> Yes. This is related to what I suggested earlier in section 3.1.

[Ahmad]
Ok.

Best Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 16 Jan 2009 13:08:36 -0600

sounds good to me.

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Friday, January 16, 2009 1:03 PM
> To: jouni korhonen; Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> Subject: RE: [netlmm] Last call notice: 
> draft-ietf-netlmm-grekey-option
> 
> RFC 5213 uses "mobility session". Please use that. Don't use 
> "mobile node binding".
> 
> Vijay
> 
> > >       and then tunneled inside the PMIP tunnel. It is 
> there in the 
> > > draft

---

From: jouni korhonen <[email-masked]>
Date: Mon, 19 Jan 2009 20:04:45 +0200

Hi Ahmad,

Sorry for the delay.

> Do you have any suggested text?

No, I don't have any good text readily in mind.. and as part of the
unclearness on this originates from the combination of pmip-ip4  
support and
dsmip6 GRE part (for me at least!), I think it is now better to wait  
for MEXT
first to conclude their GRE encapsulation discussion (now that the  
discussion
in reopened again).

Cheers,
	Jouni

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 19 Jan 2009 17:09:18 -0600

> > least that both MAG and LMA need to have the same order. It 
> seems that 
> > I am not in my best shape the last few days;) at least 
> concentration 
> > wise!
> No, I don't have any good text readily in mind.. and as part 
> of the unclearness on this originates from the combination of 
> pmip-ip4 support and
> dsmip6 GRE part (for me at least!), I think it is now better 
> to wait for MEXT first to conclude their GRE encapsulation 
> discussion (now that the discussion in reopened again).
> 
[Ahmad]
Yes, that what I said in response to domagoj.
So, you need to post your response on that thread;)

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 26 Jan 2009 20:34:18 +0200

Hello,

it seems that the discussion in general was mostly about editorials and 
cleaning up the spec. I believe that Ahmad will publish an edited 
version soon now, right?

The only "issue" that seems to be left in limbo during the last call, is 
this discussion about the encapsulation order. Is there a proposal on 
the table (are you proposing to solve this in the DS-MIP6 GRE part?

If this last thing is solved, I think the document did pass the last 
call. And we could prepare this document for the IESG.'

Cheers,

Jonne.
ext Ahmad Muhanna wrote:
>>>>> I think that is clearly understood. of course, user traffic
>>>>>           
>>>> is the one
>>>>         
>>>>> encapsulation. I do not think there is a need for that
>>>>>           
>>>> emphasis here.
>>>>
>>> May be we need to specify the order of the encapsulated 
>>>       
>> headers or at 
>>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 26 Jan 2009 13:27:09 -0600

Hi Jonne,
Please see inline.

Regards,
Ahmad

> From: Soininen, Jonne (NSN - FI/Espoo) 
> [mailto:[email-masked]] 
> Sent: Monday, January 26, 2009 12:34 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: jouni korhonen; [email-masked]
> it seems that the discussion in general was mostly about 
> editorials and cleaning up the spec. I believe that Ahmad 
> will publish an edited version soon now, right?
[Ahmad]
Yes. Hopefully by tomorrow.

> 
> The only "issue" that seems to be left in limbo during the 
> last call, is this discussion about the encapsulation order. 
> Is there a proposal on the table (are you proposing to solve 
> this in the DS-MIP6 GRE part?

[Ahmad]
I believe the proposal to suggest something for the encapsulation order.
Something like the following:

"If IPsec ESP is used to protect the mobile node's tunneled data traffic
where GRE encapsulation is used, GRE over IPsec is RECOMMENDED."

Would adding the above text to the security section be acceptable? 

The security section (8) will look like the following:
"
8.  Security Considerations

   The GRE Key Option, defined in this document, that can be carried in
   Proxy Binding Update and Proxy Binding Acknowledgement messages,
   reveals the group affiliation of a mobile node identified by its NAI
   or an IP address.  It may help an attacker in targeting flows
   belonging to a specific group.  This vulnerability can be prevented,
   by enabling confidentiality protection on the Proxy Binding Update
   and Proxy Binding Acknowledgement messages where the presence of the
   NAI and GRE Key Options establish a mobile node's relation to a
   specific group.  This vulnerability can also be avoided by enabling
   confidentiality protection on all the tunneled data packets between
   the mobile access gateway and the local mobility anchor, for hiding
   all the markings.

   <NEW-TEXT-START>
   In Proxy Mobile IPv6 [RFC5213], the use of IPsec for protecting a
mobile 
   node's data traffic is optional. However, if IPsec ESP is used to
protect 
   the mobile node's tunneled data traffic where GRE encapsulation is
used,
   GRE over IPsec is RECOMMENDED.
  <NEW-TEXT-END>
"

> 
> If this last thing is solved, I think the document did pass 
> the last call. And we could prepare this document for the IESG.'

[Ahmad]
If the proposed text is acceptable, then we can have the updated draft
by tomorrow.

> >> unclearness on this originates from the combination of
> >> pmip-ip4 support and
> >> for MEXT first to conclude their GRE encapsulation discussion (now 
> >> that the discussion in reopened again).
> >>
> >>     
> > [Ahmad]

---

From: jouni korhonen <[email-masked]>
Date: Tue, 27 Jan 2009 16:54:00 +0200

Hi Ahmad,

I am OK with the new text.

Cheers,
	Jouni