Subject: [netlmm] GRE key question

From: Julien Laganier <[email-masked]>
Date: Fri, 8 Aug 2008 15:11:38 +0200

Hi Ahmad,

I'm wondering, what's the use of the LMA echoing back the downlink GRE 
key he received from the MAG in a PBU while sending a PBA.

I don't see any, if there's none I'd rather have the GRE key option 
conatin only one key: The downlink GRE key in PBU, and the uplink GRE 
key in PBA.

Can you clarify?

Thanks.

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 8 Aug 2008 08:49:33 -0500

Hi Julien,

It is more of a confirmation from the LMA to the MAG of the pair of GRE
keys that have been assigned to this binding during this PBU/PBA
exchange. It is also very useful and helpful for debugging purposes.
Additionally, I do not see any harm in echoing the downlink GRE key and
no advantage if we keep it out.

Unless you have something?

Regards,
Ahmad

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Friday, August 08, 2008 8:12 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> Subject: GRE key question
> 
> Hi Ahmad,
> 
> I'm wondering, what's the use of the LMA echoing back the 
> downlink GRE key he received from the MAG in a PBU while 
> sending a PBA.
> 
> I don't see any, if there's none I'd rather have the GRE key 
> option conatin only one key: The downlink GRE key in PBU, and 
> the uplink GRE key in PBA.
> 
> Can you clarify?
> 
> Thanks.
> 
> --julien
>

---

From: Julien Laganier <[email-masked]>
Date: Fri, 8 Aug 2008 16:49:04 +0200

Hi Ahmad,

> It is more of a confirmation from the LMA to the MAG of the pair of
> GRE keys that have been assigned to this binding during this PBU/PBA
> exchange. 

For a LMA to confirm to the MAG that a pair of GRE keys have been 
successfully negotiated, it is sufficient that the LMA includes the GRE 
key option with the uplink key (since it means he received the downlink 
key in PBU, and is sending an uplink key in the PBA.)

> It is also very useful and helpful for debugging purposes. 

As for debugging, it's quite easy to look on the wire to match a PBU 
with a PBA based on the sequence number, and see what pair of keys were 
established.

> Additionally, I do not see any harm in echoing the downlink GRE key
> and no advantage if we keep it out.

IMHO this is backward: I do not see any harm in not echoing the downlink 
GRE key and no advantage in having it in. Protocol should be made as 
simple as possible. 

--julien

-- 
--julien

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

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 8 Aug 2008 14:18:20 -0400

Agree with Julien.

Ahmad, I had raised this earlier. See 
http://www.ietf.org/mail-archive/web/netlmm/current/msg04909.html 

IMO, the LMA should only include the uplink GRE key. In the previous
discussion, I thought you had agreed to remove the text about carrying
the downlink GRE key in the Proxy Binding Ack. 

Vijay

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julien Laganier
> Sent: Friday, August 08, 2008 7:49 AM
> To: Ahmad Muhanna
> Cc: [email-masked]
> Subject: Re: [netlmm] GRE key question
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 11 Aug 2008 08:09:29 -0500

Hi Julien,
Sorry for the late reply.

It seems that also Vijay and Kent share the same views. I do not have a
very strong attachment to that functionality:) if you guys feel that
makes it simpler, sure we will update the draft to reflect this
agreement unless other people feels otherwise.

On the other hand, hopefully the chairs will confirm the IETF-72 netlmm
meeting room consensus on the mailing list in order to be able to move
forward with this draft without further delay.

Cheers!

Regards,
Ahmad

> Sent: Friday, August 08, 2008 9:49 AM
> Subject: Re: GRE key question
> 
> For a LMA to confirm to the MAG that a pair of GRE keys have 
> been successfully negotiated, it is sufficient that the LMA 
> includes the GRE key option with the uplink key (since it 
> means he received the downlink key in PBU, and is sending an 
> uplink key in the PBA.)
> 
> As for debugging, it's quite easy to look on the wire to 
> match a PBU with a PBA based on the sequence number, and see 
> what pair of keys were established.
> 
> IMHO this is backward: I do not see any harm in not echoing 
> the downlink GRE key and no advantage in having it in. 
> Protocol should be made as simple as possible. 
> 
> --julien
> 
> downlink 
> > > GRE key he received from the MAG in a PBU while sending a PBA.
> > >
> > > conatin only one key: The downlink GRE key in PBU, and the uplink 
> > > GRE key in PBA.
> > >
> > > Can you clarify?
> > >
> > > Thanks.
> > >
> > > --julien
> 
> 
> 
> --
> --julien
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 11 Aug 2008 08:11:08 -0500

Hi Vijay,

Sure we discussed it, but I do not recall that we had agreement to
remove it.
Anyhow, please see my response to Julien email. 

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Friday, August 08, 2008 1:18 PM
> To: Julien Laganier; Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> Subject: RE: [netlmm] GRE key question
> 
> Agree with Julien.
> 
> IMO, the LMA should only include the uplink GRE key. In the 
> previous discussion, I thought you had agreed to remove the 
> text about carrying the downlink GRE key in the Proxy Binding Ack. 
> 
> Vijay
> 
> > successfully negotiated, it is sufficient that the LMA includes the 
> > GRE key option with the uplink key (since it means he received the 
> > downlink key in PBU, and is sending an uplink key in the PBA.)
> > 
> match a PBU 
> > with a PBA based on the sequence number, and see what pair of keys 
> > were established.
> > 
> > IMHO this is backward: I do not see any harm in not echoing the 
> > downlink GRE key and no advantage in having it in. Protocol 
> should be 
> > made as simple as possible.
> > 
> > --julien
> > 
> > > > From: Julien Laganier 
> [mailto:[email-masked]]
> > > > I'm wondering, what's the use of the LMA echoing back 
> the downlink 
> > > > option conatin only one key: The downlink GRE key in 
> PBU, and the 
> > > > uplink GRE key in PBA.
> > > >
> > > > Can you clarify?
> > > >
> > > > Thanks.
> > > >
> > > > --julien
> > 
> > 
> > 
> > --
> > --julien
> >

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 11 Aug 2008 12:16:27 -0500

Ahmad,

Agree with Vijay. Why do you need to include the DL key in the PBAck?
Does not make sense.
PBU includes the UL key and PBAck the DL key.

-Raj

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Thu, 14 Aug 2008 11:17:17 +0300

Ahmad,

Both Vidya and I have been on vacation and thus, asking the GRE to become a
WG document has been delayed a bit. I will send the consensus question
today.

However, this shouldn't stop you revising the document, though the name
won't change until the consensus call is over.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 14 Aug 2008 10:29:27 -0700

Hello Ahmad and all,

I have reviewed this document, and have some comments.
They are mostly editorial, but there are some more important
points as well.  These comments also include specific points
about where GRE keys may not be required after all.  This
is closely related to some recent discussion on the mailing
list, so my comments are mostly redundant but I left them
anyway for your consideration.

-----------------------------------------------------------

Abstract:

Regarding:
                                                   ...  differential
   processing can be applied by the tunnel peers over those flows.

How about:
                                                   ...  tunnel peers
   can process individual flows differently.

<side note: sentences using active voice are typically easier to read>

Section 1.  Introduction

Replace:
   This document defines an extension to the base Proxy Mobile IPv6
   specification,
by:
   This document defines a new Mobility Option,

Also see comment below for description in section 6.

Section 3.  GRE Encapsulation and Keys Exchange

- "Keys Exchange" -->  "Key Exchange"      <multiple occurrences>
OR (if the plurality of keys is of overriding importance)
- "Keys Exchange" -->  "Exchanging Keys"

Somehow, the process of "Keys Exchange" just sounds wrong!
I think the second formulation would require more changes in
the subsequent text (e.g., in Section 3.3.1.  Initial GRE Keys Exchange)
so I am hoping you'll agree to the first one.

pg. 2, pg. 3:
-  "is also referenced as forward direction traffic" -->
     "is also called forward direction traffic"      (two occurrences)

Section 3.3.  GRE Keys Exchange Mechanism
-   "Keys Exchange"  -->  "Key Exchange"

Section 3.3.1.  Initial GRE Keys Exchange
-   "Keys Exchange"  -->  "Key Exchange"
-   delete "overlapping"

Regarding:
    ... the LMA MUST include the uplink GRE key and echo the downlink
   included in the GRE Key Identifier field of the option.

Why is the downlink key included?

Section 3.3.2.  GRE Keys De-registration
-  "GRE Keys De-registration" -->  "Deregistering GRE Keys"

Regarding:
   If the GRE key option is present in the initial PBU, it MUST always
   be present in the re-registration or de-registration messages and
   with the same GRE key value.
I think this is overkill.  For deregistration, the GRE session
identifier would be enough to identify the BCE, right?

But even for re-registration, this is not needed unless the
lifetime of the GRE key is specified to be identical to the
Binding Lifetime.  If that is desired, then it should be stated
in the draft.  However, I don't really see that it's desirable.
All in all, I think that section 3.3.2 should be deleted.

This will also entail various revisions to section 4.2.

-  "successfully process"  -->  "successfully processes"

Section 5.2.  Operational Summary

  "o  Upon the successful process of"  -->
      "o  After successfully processing"
But, in this bulleted item, the PBA ought to only have
the uplink GRE key.

Replace:
                                 ....     before forwarding the packet
      after removing the encapsulation headers.
by:
                                 ....     before removing the
      encapsulation headers and forwarding the packet.
(assuming this was what was meant)

Section 6.  Message Formats

Regarding:
   This section defines an extension to the Mobile IPv6 [RFC3775]
   protocol messages ...

First of all, as the text is written now, the section actually
defines an extension to the Proxy MIPv6 messages, not the RFC3775
messages.  However, I think it would be a good idea anyway to
allow GRE encapsulation between RFC3775 home agents and mobile
nodes.  If you agree with this, then some minor rewording is
needed in section 6.1.

Section 6.2.  Status Codes

-   "defined for using them"  -->  "defined for use"
-   "using Proxy Mobile IPv6 protocol"  -->  "using Proxy Mobile IPv6"
OR:
    "using Proxy Mobile IPv6 protocol"  -->
    "using the Proxy Mobile IPv6 protocol"
OR:
    "using Proxy Mobile IPv6 protocol"  -->  "using RFC 5213"

The following sentence should be deleted, or moved to section 7:
   The value allocation for this usage needs to be approved by the IANA
   and must be updated in the IANA registry.

Section 7.  IANA Considerations

-  "defines a new Option"  -->  "defines a new Mobility Option"

Section 9.  Acknowledgments

   "Allesio Casati"  -->  "Alessio Casati"

-----------------------------------------------------------

Regards,
Charlie P.

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 14 Aug 2008 12:52:52 -0500

Hi Charlie,

> nodes.  If you agree with this, then some minor rewording is

There was a discussion about whether GRE keys are needed at all for MIP6.
And at least as far as I can recollect the conclusion was that GRE keys were
not required for MIP6 (RFC3775). Hence this option should be specific to
PMIP6 only. I do not believe there is a need for GRE keys in MIP6 BU/BAck
messages. 

-Basavaraj

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 14 Aug 2008 11:39:51 -0700

Hello Basavaraj,

> PMIP6 only. I do not believe there is a need for GRE keys in MIP6 BU/BAck

I agree it is not _needed_.  My only point was that, since we are
already going to have the option specified and standardized, we
might consider _allowing_ home agents and mobile nodes to use
it whenever doing so might be potentially useful.  It's almost like
getting a free lunch.  You don't have to eat it if it tastes bad.

Regards,
Charlie P.

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 14 Aug 2008 13:48:51 -0500

Hi Charlie,

If we want to add GRE encapsulation as another tunnelling mode between the
MN and HA, that's fine. We should include the option in 3775bis. Default
encap would be IP-in-IP but possibly GRE as well if supported by both ends
and requested in the signaling.

-Basavaraj

I don't know about the free lunch part, there is always a catch ;)

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 14 Aug 2008 11:49:44 -0700 (PDT)

Hi Charlie,

> getting a free lunch.  You don't have to eat it if it tastes bad.

This discussion came up and I was in favour of allowing this for
CMIP usage as well. Reason: As a vendor we add support for PMIP6,
define GRE tunneling capability in hardware and if we cannot make
use of that fro CMIP, its a waste of resources. Its another encap
modes and if a CMIP node wants to request and if the HA supports
it, it should be allowed. I tried to bring this work to MEXT and
as I remember even the AD agreed that the GRE option will not be
resticted to CMIP usage, even if that is defined in the NETLMM WG.
Unless there is a good reason, I do not think the option usage should
be restricted to PMIP only. Atleast, we have a clear need to be
able to use this capability in both the mobility management
protocols.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 15 Aug 2008 23:16:07 -0500

Thanks Jonne.

We will work on updating the draft taking in consideration all received
comments thus far and will wait for the consensus call to conclude for
publishing the new revision.

Cheers!

Regards,
Ahmad

> From: Soininen Jonne (NSN FI/Espoo) [mailto:[email-masked]] 
> Sent: Thursday, August 14, 2008 3:17 AM
> To: Muhanna, Ahmad (RICH1:2H10); Julien Laganier
> Cc: [email-masked]; Vijay Devarapalli; [email-masked]; 
> Vidya Narayanan
> Both Vidya and I have been on vacation and thus, asking the 
> GRE to become a WG document has been delayed a bit. I will 
> send the consensus question today.
> 
> However, this shouldn't stop you revising the document, 
> though the name won't change until the consensus call is over.
> 
> Cheers,
> 
> Jonne.
> 
> 
> > It seems that also Vijay and Kent share the same views. I 
> do not have 
> > a very strong attachment to that functionality:) if you 
> guys feel that 
> > On the other hand, hopefully the chairs will confirm the IETF-72 
> > netlmm meeting room consensus on the mailing list in order 
> to be able 
> > to move forward with this draft without further delay.
> > 
> > Cheers!
> > 
> > 
> > Regards,
> > Ahmad
> >  
> > 
> >> downlink GRE key and no advantage in having it in.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 17 Aug 2008 18:25:49 -0500

Hello Charlie,

Sorry for the late reply, I took few days off:)
Thanks for your review and comments. Please see reply in line.

Regards,
Ahmad

> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Thursday, August 14, 2008 12:29 PM
> To: Muhanna, Ahmad (RICH1:2H10); Khalil, Mohamed 
> (RICH2:2S20); Sri Gundavelli; Kent Leung (kleung)
> Cc: [email-masked]
> Subject: Some comments on draft-muhanna-netlmm-grekey-option-04.txt
> 
> 
> Hello Ahmad and all,
> 
> about where GRE keys may not be required after all.  This is 
> closely related to some recent discussion on the mailing 

[Ahmad]
Thanks. It sounds better. Will fix it.
 
>    This document defines a new Mobility Option,

[Ahmad]
Sure.

> the subsequent text (e.g., in Section 3.3.1.  Initial GRE 
> Keys Exchange) so I am hoping you'll agree to the first one.

[Ahmad]
We will adopt the first option and update accordingly. 

>      "is also called forward direction traffic"      (two occurrences)

[Ahmad]
Thx. Will fix it.

> -   "Keys Exchange"  -->  "Key Exchange"
[Ahmad]
Will do. Thx.

> Why is the downlink key included?

[Ahmad]
I agree. We had some earlier discussion and we agreed to fix it by
allowing the LMA to return only the uplink GRE key without echoing the
downlink GRE key.

> -  "GRE Keys De-registration" -->  "Deregistering GRE Keys"

[Ahmad]
Thx. Sounds much better.

> I think this is overkill.  For deregistration, the GRE 
> session identifier would be enough to identify the BCE, right?

[Ahmad]
Yes. We will make it optional for the MAG to include the GRE key in the
de-registration.

> Binding Lifetime.  If that is desired, then it should be 
> stated in the draft.  However, I don't really see that it's desirable.

[Ahmad]
Yes, the lifetime of the GRE key is tied to the mobile Node binding
lifetime. We will clarify the text to ensure that the GRE key option is
included in the re-registration. Also, Kent raised an issue related to
re-registration after inter-MAG handoff in which we will make sure that
in that case, the downlink GRE key could be different.

> All in all, I think that section 3.3.2 should be deleted.

[Ahmad]
We added this section based on a discussion on the ml regarding the
inclusion of GRE key option in the de-registration PBU. Later on Kent
suggested offlist calling this section as "GRE Keys Re-registration and
De-registration" to allow some text about the case of inter-MAG handoff.
Taking in consideration your comment about the title, we could call this
section "Reregistering GRE keys" and at the same time include one line
to mention that MAG may include the GRE Key option when sending a PBU
with lifetime zero.

Would that address your concern and be acceptable?

> -  "successfully process"  -->  "successfully processes"
[Ahmad]
No problem. Thx.

> But, in this bulleted item, the PBA ought to only have the 
> uplink GRE key.

[Ahmad]
Sure.

> (assuming this was what was meant)
[Ahmad]
We will. Thx.
 
> First of all, as the text is written now, the section 
> actually defines an extension to the Proxy MIPv6 messages, 
> not the RFC3775 messages.  However, I think it would be a 
> good idea anyway to allow GRE encapsulation between RFC3775 
> home agents and mobile nodes.  If you agree with this, then 
> some minor rewording is needed in section 6.1.

[Ahmad]
I read through your email exchange with Raj and Sri. We will continue to
allow GRE encapsulation between RFC3775 home agents and mobile nodes and
will update section 6.1. accordingly.

>     "using Proxy Mobile IPv6 protocol"  -->  "using RFC 5213"
[Ahmad]
Sure.
 
>    and must be updated in the IANA registry.

[Ahmad]
Sure. Will move it and make sure it fits in section 7.
> -  "defines a new Option"  -->  "defines a new Mobility Option"

[Ahmad]
Ok.
>    "Allesio Casati"  -->  "Alessio Casati"
[Ahmad]
Thanks.