Subject: Re: [netlmm] AD review of draft-ietf-netlmm-grekey-option

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 16 Feb 2009 07:39:26 -0600

Hello Jari and all,

All of Jari's comments have been addressed in the attached version of
the draft. 
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-grekey-option-04.t
xt

The major changes are as follows:

1. Adopt a new flag "Key NOT Used" (K) bit in the GRE Key option to be
used (set) when negotiating GRE Encapsulation only mode. In this case,
GRE Key is IGNORED. This change required quite some text change
throughout the document.

2. Added the GRE processing on the datapath which under section 7: "Data
Packets Processing Considerations" which mainly include:

2.1. Negotiation of the TLV-header format using the (T) flag in PBU/PBA.
2.2. Address all GRE encapsulation cases in the context of PMIPv6.

3. Added a new status code "GRE TUNNELING BUT TLV-HEADER NOT SUPPORTED"
to the case when the GRE encapsulation negotiation is successful BUT
TLV-header tunneling is NOT supported at the LMA. The new status code is
less than 128 to indicate success BUT the MAG MUST NOT use GRE
encapsulation with UDP based tunneling.

4. Mandating that GRE Keys always present in the case of
re-registration.

5. Updated the security consideration section.

Please take a look and let me know if you have any concern or comments.

Regards,
Ahmad

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Sunday, February 01, 2009 3:19 PM
To: Soininen, Jonne (NSN - FI/Espoo); Muhanna, Ahmad (RICH1:2H10); ext
Sri Gundavelli
Cc: Khalil, Mohamed (RICH2:2S20); [email-masked]; Vidya Narayanan;
[email-masked]
Subject: AD review of draft-ietf-netlmm-grekey-option

Here is my AD review of this document. The spec is very well written and
in good shape. But please correct the following:

1) The acronym GRE needs to be expanded on first reference (and probably
in the title as well)

[Ahmad]
DONE.

2) Section 3.3.2 requirement to not use the keys in re-registrations
seems suspect to me. Mobile IPv6 is generally built to deal with loss of
state on either end; omitting the GRE key option from the
re-registrations assumes that the home agent side has not rebooted. I'm
not sure its a safe assumption, and even if it were, the benefits are
small. If you take this and the following comment into account, you can
simply the text quite a bit.

[Ahmad]
DONE.

3) It seems that the error case in Section 3.3.2 and 6.2 can be
generalized by having the LMA perform a policy check on whether GRE keys
or lack of GRE keys is allowed for the session in question. Please note
that such a check is very likely needed even in the initial
registration, not just handoff.

[Ahmad]
DONE.

4) The following is too vague:

      "On receiving a packet from the tunnel with the GRE encapsulation
      header, the mobile access gateway MUST use the GRE Key to
      determine the necessary special processing for the data packet,
      e.g., lookup the mobile node's layer-2 address, determine any
      special processing or treatment for the data packet flow, then
      remove the encapsulation header before forwarding the packet."

My understanding is that the GRE key allows the receiver to uniquely
determine which session this packet belongs to, assuming there are
overlapping addresses. Any other actions do not depend on the GRE key
but are part of the normal processing for THAT mobile node.
 
Maybe you could say:

    "On receiving a packet from the tunnel with the GRE encapsulation
      header, the mobile access gateway MUST use the GRE Key
      as an additional identifier to determine which mobile node this
      packet belongs to. The GRE encapsulation header is removed
      before further processing takes place."

Same fix is needed for Section 5.

[Ahmad]
DONE.

5) Typo:

        "When the local mobility anchor and the mobile access gateway
         successfully negotiates ..."

s/negotiates/negotiate/

[Ahmad]
DONE.

6) This behaviour seems more suited to a SHOULD than a MUST:

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

(Using GRE in this situation would be wasteful, but would not break
anything. The use of MUST is reserved for situations that might lead to
interoperability problems or other breakage.)

[Ahmad]
DONE.

7) Section 6 says:

      "If the Length field
      is set to 2, it indicates that the GRE key is not being carried in
      the option.  If the length field is set to a value of 6, it means
      that either the downlink or the uplink GRE key is carried."

However, the rest of the specification only talks about including or
omitting the entire option, not just this field. This seems to be an
inconsistency. If so, please make option to have a fixed format so that
the length is always 6.

[Ahmad]
DONE.

8) I did not understand this:

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

What is this trying to say? That if the configuration says to use IPsec
for tunneled data traffic, this should also apply to GRE? This seems
like a no-brainer...  Or are you trying to recommend some specific usage
called "GRE over IPsec". If so, you need a normative reference to
another spec.

[Ahmad]
DONE.

9) Early on in the document you talk about GRE protection being
applicable to specific flows: "... to a specific mobile node session or
a specific flow." But there is nothing in the document to actually do
this, you really only support it for individual bindings. I would remove
the mention of flows in this specification. Note that with
mext-multiplecoa and few other things that are in the pipeline, you will
be able to have multiple bindings and specify which flow should use
which binding. One thing that you should probably specify here, though,
is that the GRE keys apply to the individual binding updated by the
Binding Update, not all bindings if the mobile node has multiple (and
add an informative reference to mext-multiplecoa).

[Ahmad]
DONE.

10) There has to be some document that actually defines what happens in
the data plane when GRE or GRE with keys are used. We are already having
a discussion about the lack of GRE specification in dsmip. There's an
associated problem with this document. It specifies the signaling well,
but is almost silent on what happens with the packets. I do not believe
its hard to specify the rules for processing GRE packets; this is mostly
references to GRE specifications and copying of the rules from RFC 3775
etc on what the general behaviour of tunneling is in Mobile IPv6. But it
needs to be specified somewhere. My suggestion would be to place that in
this document. This would potentially also solve the issue from dsmip,
as it could reference this specification.
[Ahmad]
DONE.

Jari

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 16 Feb 2009 08:46:29 -0600

Correction, This version have been submitted to the I-D archives.

Regards,
Ahmad

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Muhanna, Ahmad 
> (RICH1:2H10)
> Sent: Monday, February 16, 2009 7:39 AM
> To: Jari Arkko; [email-masked]
> Subject: Re: [netlmm] AD review of draft-ietf-netlmm-grekey-option
> 
> Hello Jari and all,
> 
> All of Jari's comments have been addressed in the attached 
> version of the draft. 
> 1. Adopt a new flag "Key NOT Used" (K) bit in the GRE Key 
> option to be used (set) when negotiating GRE Encapsulation 
> only mode. In this case, GRE Key is IGNORED. This change 
> required quite some text change throughout the document.
> 
> 2. Added the GRE processing on the datapath which under 
> section 7: "Data Packets Processing Considerations" which 
> mainly include:
> 
> to the case when the GRE encapsulation negotiation is 
> successful BUT TLV-header tunneling is NOT supported at the 
> LMA. The new status code is less than 128 to indicate success 
> BUT the MAG MUST NOT use GRE encapsulation with UDP based tunneling.
> 
> To: Soininen, Jonne (NSN - FI/Espoo); Muhanna, Ahmad 
> (RICH1:2H10); ext Sri Gundavelli
> Cc: Khalil, Mohamed (RICH2:2S20); [email-masked]; Vidya 
> Narayanan; [email-masked]
> Here is my AD review of this document. The spec is very well 
> written and in good shape. But please correct the following:
> 
> 1) The acronym GRE needs to be expanded on first reference 
> (and probably in the title as well)
> 
> [Ahmad]
> DONE.
> 
> 2) Section 3.3.2 requirement to not use the keys in 
> re-registrations seems suspect to me. Mobile IPv6 is 
> generally built to deal with loss of state on either end; 
> omitting the GRE key option from the re-registrations assumes 
> that the home agent side has not rebooted. I'm not sure its a 
> safe assumption, and even if it were, the benefits are small. 
> If you take this and the following comment into account, you 
> can simply the text quite a bit.
> 
> [Ahmad]
> DONE.
> 
> 3) It seems that the error case in Section 3.3.2 and 6.2 can 
> be generalized by having the LMA perform a policy check on 
> whether GRE keys or lack of GRE keys is allowed for the 
> session in question. Please note that such a check is very 
> likely needed even in the initial registration, not just handoff.
> 
> [Ahmad]
> DONE.
> 
> My understanding is that the GRE key allows the receiver to 
> uniquely determine which session this packet belongs to, 
> assuming there are overlapping addresses. Any other actions 
> do not depend on the GRE key but are part of the normal 
> processing for THAT mobile node.
>  
> Maybe you could say:
> 
> (Using GRE in this situation would be wasteful, but would not 
> break anything. The use of MUST is reserved for situations 
> that might lead to interoperability problems or other breakage.)
> 
> [Ahmad]
> DONE.
> 
> 7) Section 6 says:
> 
>       "If the Length field
> However, the rest of the specification only talks about 
> including or omitting the entire option, not just this field. 
> This seems to be an inconsistency. If so, please make option 
> to have a fixed format so that the length is always 6.
> 
> [Ahmad]
> DONE.
> 
> What is this trying to say? That if the configuration says to 
> use IPsec for tunneled data traffic, this should also apply 
> to GRE? This seems like a no-brainer...  Or are you trying to 
> recommend some specific usage called "GRE over IPsec". If so, 
> you need a normative reference to another spec.
> 
> [Ahmad]
> DONE.
> 
> 9) Early on in the document you talk about GRE protection 
> being applicable to specific flows: "... to a specific mobile 
> node session or a specific flow." But there is nothing in the 
> document to actually do this, you really only support it for 
> individual bindings. I would remove the mention of flows in 
> this specification. Note that with mext-multiplecoa and few 
> other things that are in the pipeline, you will be able to 
> have multiple bindings and specify which flow should use 
> which binding. One thing that you should probably specify 
> here, though, is that the GRE keys apply to the individual 
> binding updated by the Binding Update, not all bindings if 
> the mobile node has multiple (and add an informative 
> reference to mext-multiplecoa).
> 
> [Ahmad]
> DONE.
> 
> 10) There has to be some document that actually defines what 
> happens in the data plane when GRE or GRE with keys are used. 
> We are already having a discussion about the lack of GRE 
> specification in dsmip. There's an associated problem with 
> this document. It specifies the signaling well, but is almost 
> silent on what happens with the packets. I do not believe its 
> hard to specify the rules for processing GRE packets; this is 
> mostly references to GRE specifications and copying of the 
> rules from RFC 3775 etc on what the general behaviour of 
> tunneling is in Mobile IPv6. But it needs to be specified 
> somewhere. My suggestion would be to place that in this 
> document. This would potentially also solve the issue from 
> dsmip, as it could reference this specification.
> [Ahmad]
> DONE.
> 
> Jari
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Feb 2009 14:51:51 +0200

Ahmad,

I have looked at the new version. It looks much better and clearly a lot 
of work went to it, thanks! A couple of issues remain, which I hope we 
can address quickly. In the mean time, given the amount of changes, can 
we get others in the WG to review the document and state that they are 
OK with the result? I don't want to ask for another WGLC, but some 
reviews are warranted.

> GRE Key is IGNORED. This change required quite some text change

Hmm. I actually agreed with Vijay as he said earlier in the thread that 
the omitting the key field would have been the best solution.

My original point was that the draft talked about omitting the field but 
did not specify the semantics. Now that we all agree the draft needs to 
allow non-keyed GRE negotation, it would have been just a matter of 
putting that in. I'm sorry but I missed text in 3.2 that was already 
talking about this. However, there was missing text in, e.g., Section 4.2.

I do not oppose the K key, but I think its a bit of unnecessary 
complexity. Feel free to do what you want with it. Note that the change 
would be easy, e.g.,

The mobile access gateway
MUST include the GRE Key option in the Proxy Binding Update with the
Key NOT Used (K) bit set.  In this case, the MAG MAY set the GRE Key
   Identifier field to any value including zero.

to

The mobile access gateway
MUST include the GRE Key option in the Proxy Binding Update but omit the GRE Key Identifier field.

and so on in the rest of the document. I do like the changes that you 
did for Sections 3.2 and 4.2 otherwise.

> 2.2. Address all GRE encapsulation cases in the context of PMIPv6.

Ok.

> encapsulation with UDP based tunneling.

OK.

> 4. Mandating that GRE Keys always present in the case of

OK.

> Please take a look and let me know if you have any concern or comments.

OK.

New issue:

> In the case when GRE encapsulation mode only is negotiated between the 
> MAG and LMA, the mechanism used to exchange or deliver these GRE keys, 
> if used, to the MAG and LMA is out-of scope of this specification.

Unnecessary underspecification. It would have been simplest to just say 
that if you negotiate no GRE keys, then no GRE keys are used.

Same text appears in 3.2.

Issue 6 from my original review (MUST vs. SHOULD) does not appear to be 
handled in the new version.

> 7.1. Tunneling Format   
>                
>             When GRE encapsulation and GRE keys have been negotiated 
> between the   
>             mobile access gateway and the local mobility anchor for a 
> specific   
>             mobility session,

Shouldn't this section define the behaviour for all GRE encapsulation 
cases (whether keys are involved or not)?

> The distinction   
>             between IP and TLV encapsulation is needed because the 
> Proxy Binding   
>             Update will never be sent in TLV-header UDP tunnel format.

Better as: The distinction between IP and TLV encapsulation is needed, 
because both Proxy Binding Updates (IP packets) and data packets (GRE 
packets) can be sent over the same UDP tunnel.

> tunnelled
> tunnelling
s/ll/l/

> Any handoff-triggered Binding Lifetime Extension Proxy Binding Update   
>             message may renegotiate the tunnelling format. Therefore
There is no BLEPBU message... what you probably want to say is "Any 
Proxy Binding Update message triggered by a handoff (Section 5.3.4 of 
RFC 5213) ...

> When sending IPv6 packets to a mobile node located in an IPv4   
>   network, the local mobility anchor follows the format negotiated in   
>   the Proxy Binding Update/Acknowledgement exchange as described in   
>   [ID-PMIP6-IPv4]. In the case when TLV-tunneling format and the GRE   
>   encapsulation for a specific mobility session have been successfully   
>   negotiated between the local mobility anchor and the mobile access   
>   gateway, the local mobility anchor follows the TLV-header UDP based   
>   headers tunneling order as shown in Figure 8 when sending or   
>   receiving tunnelled IPv4 or IPv6 payload packets to or from the   
>   mobile access gateway, respectively.

To a mobile node? You mean a mag?

Overall, Section 7 was very hard to follow. Lots of statements with many 
conditions, and I was not convinced that all cases were really handled.

Jari

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 18 Feb 2009 09:21:34 -0600

Hi Jari,

> Subject: Re: AD review of draft-ietf-netlmm-grekey-option
> 
> Ahmad,
> 
> I have looked at the new version. It looks much better and 
> clearly a lot of work went to it, thanks! A couple of issues 
> remain, which I hope we can address quickly. In the mean 
> time, given the amount of changes, can we get others in the 
> WG to review the document and state that they are OK with the 
> result? 

[Ahmad]
I agree.

I don't want to ask for another WGLC, but some 
> option to be 
> Hmm. I actually agreed with Vijay as he said earlier in the 
> thread that the omitting the key field would have been the 
> best solution.
> 
> My original point was that the draft talked about omitting 
> the field but did not specify the semantics. Now that we all 
> agree the draft needs to allow non-keyed GRE negotation, it 
> would have been just a matter of putting that in. I'm sorry 
> but I missed text in 3.2 that was already talking about this. 
> However, there was missing text in, e.g., Section 4.2.
> 
> I do not oppose the K key, but I think its a bit of 
> unnecessary complexity. Feel free to do what you want with 
> it. Note that the change would be easy, e.g.,
> 
> MUST include the GRE Key option in the Proxy Binding Update 
> with the Key NOT Used (K) bit set.  In this case, the MAG MAY 
> set the GRE Key
> and so on in the rest of the document. I do like the changes 
> that you did for Sections 3.2 and 4.2 otherwise.
>

[Ahmad]
NO problem. I will update without the (K) bit and spin another revision
with this change.
 
> > 2. Added the GRE processing on the datapath which under section 7: 
> > "Data Packets Processing Considerations" which mainly include:
> >
> successful BUT 
> > TLV-header tunneling is NOT supported at the LMA. The new 
> status code 
> > is less than 128 to indicate success BUT the MAG MUST NOT use GRE 
> Unnecessary underspecification. It would have been simplest 
> to just say that if you negotiate no GRE keys, then no GRE 
> keys are used.
> 
[Ahmad]
Ok.
 
> Issue 6 from my original review (MUST vs. SHOULD) does not 
> appear to be handled in the new version.
>

[Ahmad]
My bad. Will fix it.
 
> Shouldn't this section define the behaviour for all GRE 
> encapsulation cases (whether keys are involved or not)?

[Ahmad]
Yes. Will update the text and make sure that all cases are captured
wherever applicable.

> Better as: The distinction between IP and TLV encapsulation 
> is needed, because both Proxy Binding Updates (IP packets) 
> and data packets (GRE

[Ahmad]
Ok. Will fix it.

[Ahmad]
Ok.

> There is no BLEPBU message... what you probably want to say 
> is "Any Proxy Binding Update message triggered by a handoff 
> (Section 5.3.4 of RFC 5213) ...
> 

[Ahmad]
Sure. That reads better.

> To a mobile node? You mean a mag?

[Ahmad]
Yes. 
I was debating this because I did not want the sentence to give the
impression that the final destination is the MAG. But the MAG is fine.

> conditions, and I was not convinced that all cases were 

[Ahmad]
Is there any specific ones stands out other than the case of GRE
encapsulation without key.
I will go through it one more time and make sure that all cases are
covered.

I will spin a new revision quickly, hopefully today or tomorrow and I
hope folks will review the new revision and provide comments or say that
they are ok with it.

Thanks for the quick review and comment.

Regards,
Ahmad

---

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Feb 2009 17:26:51 +0200

Ahmad,

> encapsulation without key.

Not really, but if you and others re-read it and try to think about the 
logic, maybe that helps.

Jari