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

From: Jari Arkko <[email-masked]>
Date: Sun, 01 Feb 2009 23:18:37 +0200

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)

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.

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.

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.

5) Typo:

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

s/negotiates/negotiate/

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

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.

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.

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

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.

Jari

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

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 1 Feb 2009 22:23:44 -0800 (PST)

Hi Jari,

Thanks for the review. Some comments below.

On Sun, 1 Feb 2009, Jari Arkko wrote:

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

I agree, carrying the options consistently in all messages, including
even echoing in reply messages will keep some consistency and simpliefied
processing on both ends. There was some discussion and some how it
ended up this way.

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

Ok.

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

The idea was to allow the option to be used by the peers for
negotiating GRE encap mode alone and not always implicitly
when keys are negotiated. We should have used a flag in the
option for explicit indication of non key presence, as supposed
to manage it with the size. Either way, rest of the text should
allow this possibility and should be fixed.

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

May be this should be rephrased better. When using payload protection
on data traffic, the ESP protection should be applied on the outer
tunnel header, its not for recommending any new mode. We will rephrase
this.

IPv4-ESP-GRE-IPv4

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

Agree. The key association is always for a mobile node session. We
will rephrase this.

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

May be we should have had one section on the data path considerations,
either way. If its decided to define the GRE encap mode in this spec,
as part of the encap and key negotiation, as supposed to in DSMIP, we
can add some encap/decap considerations.

Regards
Sri

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Feb 2009 08:36:55 +0200

Sri,

>> inconsistency. If so, please make option to have a fixed format so 
>> that the length is always 6.
>>
>
> when keys are negotiated.

I did not see any of this in the text... I think that is a fine idea, 
but you need to specify it.

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

OK

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

Right. I'm not pushing you to do it in this spec -- you could also have 
a third spec that contains those things. But it needs to be somewhere, 
and somehow this spec looks like the likely place to do it.

Jari

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 2 Feb 2009 00:49:56 -0600

Hello Jari,
Thanks for the review. Please see comments inline.

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]
Sure.

> 
> 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]
I agree. That was my personal views but the majority of people who
participated in that specific discussion supported this. But I see your
point.

> 
> 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]
I believe that in some earlier version this addressed both initial and
re-registration but some how is not captured for the initial
registration. However, one thing is not clear here. Do you mean here
just to use policy based in deciding if GRE keys is needed or NOT? 

I see your point with respect to policy for the initial registration but
I think that in the case of re-registration, it could be simpler to
check if GRE key is part of the BCE.

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

[Ahmad]
Sure. Looks good to me.

> Same fix is needed for Section 5.

[Ahmad]
Ok.
>          successfully negotiates ..."

[Ahmad]
Ok.

> (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]
Sure. Makes sense.

> 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]
Sure, we will use a GRE key value of zero in this case to keep the
length of 6 always. Will update the draft accordingly.

> 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]
I just wanted to avoid more detailed on the encapsulation order for the
tunnel vs. transport ESP. I tried to find a document to reference but
was not quickly able to point one. May be what we need to do is to be
more specific on this by defining the order of the headers in both
cases.

> 
> 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. 
[Ahmad]
Sure.

> 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]
Sure.
> 
> 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]
We felt that there was no need for this since it is addressed in dsmip.
On the other hand, I personally believed that dsmip was not the best
place for it. If the decision is to move it to this document, we will
add it.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Feb 2009 10:26:45 +0200

Ahmad, thanks for your response. I'm responding to the parts that still 

> check if GRE key is part of the BCE.

I think both initial and re-registration can be handled via policy. The 
LMA knows whether it has overlapping address domains, and if it does, it 
needs to require keyed GRE. Note that due to movement, the LMA already 
needs to be capable of changing the tunnel parameters for a given 
mobile. I do not see a problem in allowing one MAG to use GRE and the 
next not. But if someone does see a problem, it is really easy to 
implement this as a policy in the LMA side.

The re-reg check is sensible and easy to implement. But given all the 
above, I'm not sure we really need it.

> length of 6 always. Will update the draft accordingly.

No, this does not address my concern. I do not care how you encode the 
option; omitting the field and putting in a zero are just different ways 
of doing the same thing.

My concern was that the rest of the draft talks about omitting or 
including the ENTIRE OPTION. So from the point of view of the rest of 
the draft, you had no need to encode the missing key value.

However, as was already pointed out in another mail, your intent was to 
use this option to signal the use of plain GRE as well. This makes 
sense, but again, needs to be documented. For that its fine to omit the 
key field. However, the rest of the draft has to be changed to talk 
about this functionality.

> place for it. If the decision is to move it to this document, we will
AFAICT there is no specification of what to do with the data packets. 
RFC 3775, for instance, had quite a bit of text to talk about how the 
tunneling is performed. None of that exists for the moment for the GRE case.

The place of that text is less important, as long as it exists, I'm fine.

Jari

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 2 Feb 2009 02:43:05 -0600

Hi Jari,
A quick follow up inline.

> 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 
> I agree. That was my personal views but the majority of 
> people who participated in that specific discussion supported 
> this. But I see your point.

[Ahmad]
It is fair to mention here that what started the discussion on the ml in
the first place was the requirement to include the GRE Key in the
de-registration PBU. Since de-registration is clearly mentioned in the
draft in a different place and you did not comment on it, is fair to
assume that your concern here is for re-registration only?

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 2 Feb 2009 02:45:05 -0600

Minor correction.

Regards,
Ahmad

> > participated in that specific discussion supported this. But I see 
> > your point.
> 
> [Ahmad]
> It is fair to mention here that what started the discussion 
> on the ml in the first place was the requirement to include 
> the GRE Key in the de-registration PBU. Since de-registration 

   ^^ GRE Key option ^^^^

> is clearly mentioned in the draft in a different place and 
> you did not comment on it, is fair to assume that your 
> concern here is for re-registration only?
> 
> > 
> > >

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Feb 2009 10:45:06 +0200

Ahmad,

> assume that your concern here is for re-registration only?

Yes. I do not care what is doen for de-registration. I think the current 
text for that is fine.

Jari

---

From: Julien Laganier <[email-masked]>
Date: Mon, 2 Feb 2009 10:49:44 +0100

> good shape. But please correct the following:

[...]

> 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
> This would potentially also solve the issue from dsmip, as it could
> reference this specification.
>

IMHO it makes sense to have the GRE tunneling behavior specified in a
self-contained specification for both control and data plane since I do not
see a scenario in which it is useful to implement only one of these two
aspects.

(why would I need to signal anything w.r.t. GRE tunneling if I have no data
to handle / how would I know how to handle the data, which GRE key to use,
if I don't have the signaling)

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 2 Feb 2009 09:27:51 -0600

Hi Jari,
Please see inline.

> 
> Ahmad, thanks for your response. I'm responding to the parts 
> that still need discussion:
> 
> > I see your point with respect to policy for the initial 
> registration 
> > but I think that in the case of re-registration, it could 
> be simpler 
> > to check if GRE key is part of the BCE.
> >   
> 
> I think both initial and re-registration can be handled via 
> policy. The LMA knows whether it has overlapping address 
> domains, and if it does, it needs to require keyed GRE. 

[Ahmad]
I am not sure if that policy is simply if the LMA supports address
overlapping or not, i.e. a per-LMA policy. IMO, It could be more
specific to a per-MN policy. Also, there have been several requests that
GRE encapsulation does not need to be specific to address overlapping
BUT at least this one can be a per MAG-LMA policy.

> Note 
> that due to movement, the LMA already needs to be capable of 
> changing the tunnel parameters for a given mobile. I do not 
> see a problem in allowing one MAG to use GRE and the next 
> not. 

[Ahmad]
Sure. But this seems to me a per-peer policy. Do you see this happens on
a per-MN basis?
i.e. , both MN1 and MN2 move from MAG1 (where GRE is being used for both
MNs) to MAG2 and LMA has a policy to allow MN1 to move without GRE keys
while MN2 to move with?

> But if someone does see a problem, it is really easy to 
> The re-reg check is sensible and easy to implement. But given 
> all the above, I'm not sure we really need it.
[Ahmad]
I see the value of simplification to state that this could be handled
per LMA policy. However, I believe that policy could sometime be a per
MAG-LMA and sometimes more specific to a per-MN. 

IMO, to state that this can be decided based on a per-LMA policy only is
probably not specific enough; especially during the re-registration.
What we can do is to add the per-LMA policy to what the draft currently
has. I agree, that should simplify the text.

> 
> >> 7) Section 6 says:
> >>
> >>       "If the Length field
> >>       is set to 2, it indicates that the GRE key is not 
> being carried 
> >> in
> 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]
> No, this does not address my concern. I do not care how you 
> encode the option; omitting the field and putting in a zero 
> are just different ways of doing the same thing.
> 
> My concern was that the rest of the draft talks about 
> omitting or including the ENTIRE OPTION. So from the point of 
> view of the rest of the draft, you had no need to encode the 
> missing key value.
> 
> However, as was already pointed out in another mail, your 
> intent was to use this option to signal the use of plain GRE 
> as well.

[Ahmad]
Without getting deep into intentions:) the draft never initially
introduced the use of the GRE option to explicitly negotiate GRE
encapsulation mode alone. I remember we discussed the choice of using a
flag in the PBU but that was discarded as it would be not acceptable.
But at any rate, adding a flag in the GRE option as pointed by Sri is
fine. 

> This makes sense, but again, needs to be documented. 
> For that its fine to omit the key field. However, the rest of 
> the draft has to be changed to talk about this functionality.

[Ahmad]
Ok.

> >> in the data plane when GRE or GRE with keys are used.
> >> 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 
> RFC 3775, for instance, had quite a bit of text to talk about 
> how the tunneling is performed. None of that exists for the 
> moment for the GRE case.
> 

[Ahmad]
Hmmm.. somehow, I thought that was described in dsmip. No problem, will
add a separate section for it.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 Feb 2009 14:56:28 +0200

Ahmad,

> specific to a per-MN policy.

A per-MN policy is fine. What I am saying is that for initial 
registration, re-registration, movement, etc the LMA performs a policy 
decision. Possibly a per-MN policy decision. But you do not have to 
encode that policy in the RFC, or state that the policy must be that you 
cannot change from one mode to another.

Jari

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 3 Feb 2009 10:11:55 -0600

Jari,

> registration, re-registration, movement, etc the LMA performs 
> a policy decision. Possibly a per-MN policy decision. But you 
> do not have to encode that policy in the RFC, or state that 
> the policy must be that you cannot change from one mode to another.

[Ahmad]
Sure, as long as we state it as a "policy decision" without labeling
that policy as LMA local policy, for example, then it is generic enough
and should cover all cases.

Thx.

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 11 Feb 2009 20:04:12 -0500

Hi Jari, Ahmad,

> length of 6 always. Will update the draft accordingly.

I would avoid use GRE key of '0'. My understanding is that if the length
is set to 2, it means GRE encapsulation is being used without using any
keys. The length when set to '6' indicates that the keys are also
present in the option. Lets stick to that. 

Sri suggested using a flag to indicate the use of GRE keys as opposed to
plain GRE encapsulation. Thats fine, but is really redundant if you have
the above. 

> more specific on this by defining the order of the headers in both

Perhaps we should say GRE over IPsec is not currently supported as far
as this document goes. If the tunneled data traffic needs IPsec ESP
protection, GRE encapsulation SHOULD NOT be used. We can re-visit this
once we have a standard mechanism to use IPsec ESP in tunnel mode with
GRE keys.

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Thu, 12 Feb 2009 02:07:19 +0100

> once we have a standard mechanism to use IPsec ESP in tunnel mode with

Sorry to jump in but, but I'm wondering what would prevent applying 
IPsec tunnel mode protection to a GRE tunnel?

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 12 Feb 2009 02:12:32 +0100

> IPsec tunnel mode protection to a GRE tunnel?
	
...and the same with IPsec transport mode.

--julien

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 11 Feb 2009 20:33:29 -0500

Hi Julien, 

> IPsec tunnel mode protection to a GRE tunnel?

I don't know how the SPD entry would look like. Would IPsec get a packet
that has the format IPv4-GRE-IPv4? If you want the final packet to be
IPv4-ESP-GRE-IPv4, you actually need a transport mode ESP SPD entry. So
you are not really using IPsec in tunnel mode. If you want to use
different IPsec SAs for different GRE flows, you need the GRE keys as
selectors. This is again not specified, right? IMO, we need to specify
how ESP tunnel mode encapsulation and GRE encapsulation would work
together. 

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Thu, 12 Feb 2009 02:49:58 +0100

Hi Vijay,

> how ESP tunnel mode encapsulation and GRE encapsulation would work

So far I haven't seen a convincing case about using different IPsec SAs 
for different GRE flows.

Thus you'd simply have the protocol number for GRE (47) in the traffic 
selector.

Depending on the kind of IPsec protection you want to apply, you'd have 
to chose b/w IPsec tunnel mode and transport mode.

If the IPsec protection is to be applied b/w the GRE tunnel endpoint it 
seems IPsec transport mode would be appropriate, in which case an 
IPvx-GRE-IPvx packet would end up on the wire as IPvx-ESP-GRE-IPvx.

If the IPsec protection is to be applied only on a portion of the path 
between the GRE tunnel endpoints, then an IPvx-GRE-IPvx packet would end 
up on the wire as IPvx-ESP-IPvx-GRE-IPvx.

In conclusion I do not think we need to say anything special w.r.t. 
applying IPsec protection to GRE tunneling.

--julien

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 11 Feb 2009 21:16:17 -0500

Hi Julien,

Julien Laganier wrote:
> Hi Vijay,
> 
> Vijay Devarapalli wrote:
>> Hi Julien,
>> 
>>>> Perhaps we should say GRE over IPsec is not currently supported as
>>>> far as this document goes. If the tunneled data traffic needs
>>>> IPsec ESP protection, GRE encapsulation SHOULD NOT be used. We can
>>>> re-visit this once we have a standard mechanism to use IPsec ESP
>>>> in tunnel mode with GRE keys.
>> I don't know how the SPD entry would look like. Would IPsec get a
>> packet that has the format IPv4-GRE-IPv4? If you want the final
>> packet to be IPv4-ESP-GRE-IPv4, you actually need a transport mode
>> ESP SPD entry. So you are not really using IPsec in tunnel mode. If
>> you want to use different IPsec SAs for different GRE flows, you
>> need the GRE keys as selectors. This is again not specified, right?
>> IMO, we need to specify how ESP tunnel mode encapsulation and GRE
>> encapsulation would work together.
> 
> So far I haven't seen a convincing case about using different IPsec
> SAs for different GRE flows.

You might be right on this. I haven't really explored this.

> If the IPsec protection is to be applied b/w the GRE tunnel endpoint
> it seems IPsec transport mode would be appropriate, in which case an

For PMIPv6, this would always apply. 

> applying IPsec protection to GRE tunneling.

At the minimum we have to show the SPD entries, assuming transport mode
SA between the MAG and the LMA.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 11 Feb 2009 23:52:01 -0600

Hi Vijay,

> Subject: RE: [netlmm] AD review of draft-ietf-netlmm-grekey-option
> 
> Hi Jari, Ahmad,
> 
> > > 7) Section 6 says:
> > > 
> > >       "If the Length field
> I would avoid use GRE key of '0'. 
[Ahmad]
Sure, we will not.

> My understanding is that if 
> the length is set to 2, it means GRE encapsulation is being 
> used without using any keys. The length when set to '6' 
> indicates that the keys are also present in the option. Lets 
> stick to that.

[Ahmad]
The point that Jari was making, as I understood it, is that the GRE Key
option should have the same format all the time. i.e. in case of GRE
encapsulation only or GRE encapsulation with Keys. That meant to me that
we need a solution to maintain the length field to 6. That where Sri
suggestions comes in the picture. 

On the other hand, it is a little late Vijay:-) I have already made all
the changes which all over the document to fix this portion using one of
the reserved bits (K) Key NOT Used.

Coming back to the GRE Key value being zero. In the case when the (K)
bit is set, the receiver, e.g., the LMA will ignore the value in the GRE
Identifier field. However, in that case, would we allow the use of '0'
in the GRE Key field. I mean it means nothing because that value is
ignored anyway.

I just wanted to check if you have any opinion on this one. 

> 
> Sri suggested using a flag to indicate the use of GRE keys as 
> opposed to plain GRE encapsulation. Thats fine, but is really 
> redundant if you have the above. 
> 
> > >       used to protect the mobile node's tunneled data 
> traffic where 
> > > GRE
> > I just wanted to avoid more detailed on the encapsulation order for 
> > the tunnel vs. transport ESP. I tried to find a document to 
> reference 
> > but was not quickly able to point one. May be what we need 
> to do is to 
> > be more specific on this by defining the order of the 
> headers in both 
> > cases.
> 
> Perhaps we should say GRE over IPsec is not currently 
> supported as far as this document goes. If the tunneled data 
> traffic needs IPsec ESP protection, GRE encapsulation SHOULD 
> NOT be used. We can re-visit this once we have a standard 
> mechanism to use IPsec ESP in tunnel mode with GRE keys.

[Ahmad] I also went over your email exchange with Julien. But let me
reply back here. My understanding is that both tunnel mode and transport
mode could be used with transport mode being preferred. But, What about
the following text without going into the debate of tunnel vs.
transport:
"
In Proxy Mobile IPv6 [RFC5213], the use of IPsec for protecting a mobile
node's data traffic is optional. However, if IPsec ESP as in [RFC4303]
is used to protect the mobile node's tunneled data traffic where GRE
encapsulation is used, the GRE header MUST be protected by the ESP
header.
"

Would that be enough for this draft?

---

From: jouni korhonen <[email-masked]>
Date: Thu, 12 Feb 2009 15:02:41 +0200

Hi,

On Feb 12, 2009, at 3:49 AM, Julien Laganier wrote:

>>> supported as far
>>> Sorry to jump in but, but I'm wondering what would prevent  
>>> applying IPsec tunnel mode protection to a GRE tunnel?
>> packet
> Thus you'd simply have the protocol number for GRE (47) in the  
> traffic selector.
>
> Depending on the kind of IPsec protection you want to apply, you'd  
> have to chose b/w IPsec tunnel mode and transport mode.
>
> If the IPsec protection is to be applied only on a portion of the  
> path between the GRE tunnel endpoints, then an IPvx-GRE-IPvx packet  
> would end up on the wire as IPvx-ESP-IPvx-GRE-IPvx.
>

Even if this looks straightforward, it would be better written down  
somewhere.
Also, can we now ignore the dsmip6 draft with its TLV+GRE stuff and  
assume it
does not affect the above stackings?

- Jouni

---

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

Hi Ahmad,

Ahmad Muhanna wrote:
> encapsulation only or GRE encapsulation with Keys. 

Looking at the thread again, Jari's point was that it was not clear that 
GRE encapsulation could be used without exchanging keys.

That meant to me that
> I just wanted to check if you have any opinion on this one. 

Using a flag is fine with me.

> Would that be enough for this draft?

No. We at least need to say that ESP in transport mode is used for 
protecting GRE encapsulated MN traffic between the MAG and the LMA. 
According to RFC 5213, tunneled mode ESP is used to protect MN traffic 
between the MAG and the LMA.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 12 Feb 2009 13:30:33 -0600

Hi Vijay,

> > What about the following text without going into the debate 
> of tunnel vs.
> > transport:
> > "
> > In Proxy Mobile IPv6 [RFC5213], the use of IPsec for protecting a 
> > mobile node's data traffic is optional. However, if IPsec ESP as in 
> > [RFC4303] is used to protect the mobile node's tunneled 
> data traffic 
> > where GRE encapsulation is used, the GRE header MUST be 
> protected by 
> > the ESP header.
> > "
> > 
> No. We at least need to say that ESP in transport mode is 
> used for protecting GRE encapsulated MN traffic between the 
> MAG and the LMA. 
> According to RFC 5213, tunneled mode ESP is used to protect 
> MN traffic between the MAG and the LMA.
> 
[Ahmad]
Sure will add it and possibly a word about the fact that SA can NOT be
per flow or GRE key. Will share this specific text sometime today.

Regards,
Ahmad

---

From: Julien Laganier <[email-masked]>
Date: Thu, 12 Feb 2009 22:27:42 +0100

Hi Vijay,

Vijay Devarapalli wrote:
>>> My understanding is that if the length is set to 2, it means GRE 
>>> encapsulation is being used without using any keys. The length when 
>>> set to '6' indicates that the keys are also present in the option. 
>>> Lets stick to that.
>>
>> [Ahmad]
>>> far as this document goes. If the tunneled data traffic needs IPsec 
>>> ESP protection, GRE encapsulation SHOULD NOT be used. We can re-visit 
>>> this once we have a standard mechanism to use IPsec ESP in tunnel 
>>> mode with GRE keys.
>>

I think both tunnel mode and transport mode can equally be used. It 
depends on what sort of protection the deployment is seeking. I do not 
think we should reach the point where we tell people what are their 
security requirements w.r.t. to their data. Remember that we're not 
talking about securing a signaling protocol here.

--julien

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 13 Feb 2009 00:01:27 -0600

Hi Vijay and Julien,

> Sure will add it and possibly a word about the fact that SA 
> can NOT be per flow or GRE key. Will share this specific text 
> sometime today.

[Ahmad]
What about the following text under the security section?

"
   In Proxy Mobile IPv6 [RFC5213], the use of IPsec for protecting a
   mobile node's data traffic is optional.  Additionally, Proxy Mobile
   IPv6 recommends the use of ESP in tunnel mode when using ESP in
   protecting the mobile node's data traffic.  However, if IPsec ESP as
   in [RFC4303] is used to protect the mobile node's tunneled data
   traffic where GRE encapsulation is used, the GRE header MUST be
   protected by the ESP header.  In addition, both the ESP transport or
   the ESP tunnel mode can be used to protect the mobile node data
   traffic.  Currently, there is no mechanism to use the GRE key as a
   selector for IPsec SA.  Therefore, the granularity of the IPsec SA is
   limited to the tunnel endpoints and can not be finer, e.g., a per
   flow SA.
"

---

From: Julien Laganier <[email-masked]>
Date: Fri, 13 Feb 2009 19:12:08 +0100

Hi Ahmad,

>    limited to the tunnel endpoints and can not be finer, e.g., a per

Thanks for the updated text. I massaged it a bit below:

     In Proxy Mobile IPv6 [RFC5213], the use of IPsec [RFC4301] for
     protecting a mobile node's data traffic is optional.  Additionally,
     Proxy Mobile IPv6 recommends the use of ESP in tunnel mode when
     using ESP in protecting the mobile node's data traffic.  However,
     when GRE encapsulation is used, both IPsec tunnel mode and transport
     mode can be used to protect the GRE header. The IPsec traffic
     selectors will contain the protocol number for GRE, and there is
     currently no mechanism to use the GRE key as a traffic selector.

Best,

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 13 Feb 2009 13:03:34 -0600

Thanks Julien. 
Looks good to me!

Regards,
Ahmad

> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Friday, February 13, 2009 12:12 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Vijay Devarapalli; [email-masked]
> Subject: Re: [netlmm] AD review of draft-ietf-netlmm-grekey-option
> 
> Ahmad Muhanna wrote:
> > Hi Vijay and Julien,
> 
> Hi Ahmad,
> 
> > [Ahmad]