Subject: [Mip4] WGLC: draft-ietf-mip4-gre-key-extension-00.txt

From: "McCann Peter-A001034" <[email-masked]>
Date: Wed, 9 Jun 2010 11:55:42 -0400

This message announces a 2-week working group last call on:

"GRE Key Extension for Mobile IPv4"
draft-ietf-mip4-gre-key-extension-00.txt

The last call will end at 24:00 UTC on Wednesday, June 23 2010.

   The GRE specification contains a Key field, which MAY contain a value
   that is used to identify a particular GRE data stream.  This
   specification defines a new Mobile IP extension that is used to
   exchange the value to be used in the GRE Key field.  This extension
   further allows the Mobility Agents to setup the necessary protocol
   interfaces prior to receiving the mobile's traffic.  The new
   extension option allows a foreign agent to request GRE tunneling
   without disturbing the Home Agent behavior specified for Mobile Ipv4.
   GRE tunneling provides an advantage that allows operator's private
   home networks to be overlaid and allows the HA to provide overlapping
   home addresses to different subscribers.  When the tuple < Care of
   Address, Home Address and Home Agent Address > is the same across
   multiple subscriber sessions, GRE tunneling will provide a means for
   the FA and HA to identify data streams for the individual sessions
   based on the GRE key.  In the absence of this key identifier, the
   data streams cannot be distinguished from each other, a significant
   drawback when using IP-in-IP tunneling.

Please respond to this working group last call:

* If you have no comments on the draft, and support its advancement,
  simply respond with a line containing something like

    "I support the advancement of this document to the IESG with a
     request for publication as a Proposed Standard RFC."

   If you have comments, please use a line similar to the one above,
   and supplement this with your comments.

* If you *don't* support its advancement, respond with a line
  containing something like the following, supplemented by your
  comments -

    "I don't support the advancement of this document to the IESG with
     a request for publication as a Proposed Standard RFC, for the
     following reasons:"
    ...

Please direct all replies to the Mobile IPv4 mailing list,
[email-masked].

-Pete

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Fri, 25 Jun 2010 16:38:18 -0400

Hmmm... no responses.  Without some reviews and support we
cannot progress this document.

I have some comments that should be addressed before we move
forward:

Abstract:
   to setup
SHOULD BE:
   to set up

   extension option allows
SHOULD BE:
   extension allows

   for Mobile Ipv4.
SHOULD BE:
   for Mobile IPv4.

   provides an advantage that allows operator's private
   home networks to be overlaid
SHOULD BE:
   allows an operator's private
   home networks to be overlaid
What does it mean for home networks to be overlaid?

Section 1: 
   text above is repeated.  Fix it here too.

Section 4.1:

   If the MN does not set the 'G' bit, and the local policy allows the
   FA to override the 'G' bit setting received from the MS, the FA MUST
   include the GRE-Key Extension as defined in this memo in the
   Registration Request message to request GRE encapsulation for the
   session.
SHOULD BE:
   If the MN does not set the 'G' bit, and the local policy requires the
   FA to override the 'G' bit setting received from the MS, the FA MUST
   include the GRE-Key Extension as defined in this memo in the 
   Registration Request that it propagates to the HA.  The presence of
   this extension is a request for GRE encapsulation that takes
precedence
   over the setting of the 'G' bit in the Registration Request.  The FA
   MUST NOT modify the 'G' bit in the Registration Request because it is
   covered by the Mobile-Home Authentication Extension. 

Section 4.2:
   If the HA receives
   the GRE Key Extension in a Registration Request and does not
   recognize GRE Key Extension, it MUST send an RRP with code 'Unknown
   Extension (0xY1)' per [RFC3344].
I was unable to find any such error code in RFC3344.  If the HA doesn't
recognize a non-skippable extension, RFC3344 specifies that the RRQ is
silently discarded.

   it MUST send an RRP with code 'Requested
   Encapsulati on Unavailable (0xYY)'.
SHOULD BE:
   it MUST send an RRP with code 'Requested
   Encapsulation Unavailable (0x8b)' per [RFC3024].

By the way, why are all of these response codes in hex?  The assigned
numbers document has them in decimal.

Section 5:
   The GRE Key extension MAY be included in Registration Requests
   [RFC3344], whose 'G' bit is enabled. 
This is at best misleading, because the extension can also be included
in Registration Requests whose 'G' bit is clear.

It looks like Figure 1 was drawn to include both the extension
format diagram and the description of the fields (the caption
is way down below the field descriptions).  Suggest pulling
out the description of the fields into the body of the text.

Section 6:
   The GRE Key extension defined in this memo is as defined in
   [RFC3344].  IANA should assign a value for this Extension.
SHOULD BE:
   The GRE Key extension defined in this memo is a Mobile IP extension
   as defined in [RFC3344].  IANA should assign a Type value for this
Extension
   from the non-skippable range (0-127).

Section 7:
Perhaps add the following paragraph:

   Despite its name, the GRE Key extension has little to do with
   security.  The word "Key" here is not used in the cryptographic
   sense of a shared secret that must be protected, but rather is
   used in the sense of an "index" or demultiplexing value that can
   be used to distinguish packets belonging to a given flow.

-Pete

McCann Peter-A001034 wrote:
>    The GRE specification contains a Key field, which MAY contain a
>    value that is used to identify a particular GRE data stream.  This
>    without disturbing the Home Agent behavior specified for Mobile
>    Ipv4. GRE tunneling provides an advantage that allows operator's
>    private home networks to be overlaid and allows the HA to provide
>    overlapping home addresses to different subscribers.  When the
>    tuple < Care of Address, Home Address and Home Agent Address > is
>    the same across multiple subscriber sessions, GRE tunneling will
>    provide a means for the FA and HA to identify data streams for the
>    individual sessions based on the GRE key.  In the absence of this
>    key identifier, the data streams cannot be distinguished from each
>    other, a significant drawback when using IP-in-IP tunneling.
> 
>

---

From: "Mizikovsky, Semyon B (Simon)" <[email-masked]>
Date: Sat, 26 Jun 2010 12:40:46 -0500

Pete, I will review it by Wednesday.

Semyon Mizikovsky
Alcatel Lucent
Wireless Security & Fraud Prevention
Wireless Standards Department
600/700 Mountain Avenue, 3C-506L
Murray Hill, NJ 07974, USA
(O) 1+908-582-0729
(M) 1+732-239-7533
(F)  1+908-743-4361

PLEASE  NOTE MY NEW EMAIL ADDRESS:
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of McCann Peter-A001034
Sent: Friday, June 25, 2010 4:38 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Mip4] WGLC: draft-ietf-mip4-gre-key-extension-00.txt

Hmmm... no responses.  Without some reviews and support we cannot progress this document.

Abstract:
   to setup
SHOULD BE:
   to set up

   extension option allows
SHOULD BE:
   extension allows

   for Mobile Ipv4.
SHOULD BE:
   for Mobile IPv4.

Section 1:

Section 4.1:

   this extension is a request for GRE encapsulation that takes precedence

Section 4.2:
   If the HA receives
   the GRE Key Extension in a Registration Request and does not
   recognize GRE Key Extension, it MUST send an RRP with code 'Unknown
   Extension (0xY1)' per [RFC3344].
I was unable to find any such error code in RFC3344.  If the HA doesn't recognize a non-skippable extension, RFC3344 specifies that the RRQ is silently discarded.

By the way, why are all of these response codes in hex?  The assigned numbers document has them in decimal.

Section 5:
   The GRE Key extension MAY be included in Registration Requests
   [RFC3344], whose 'G' bit is enabled.
This is at best misleading, because the extension can also be included in Registration Requests whose 'G' bit is clear.

It looks like Figure 1 was drawn to include both the extension format diagram and the description of the fields (the caption is way down below the field descriptions).  Suggest pulling out the description of the fields into the body of the text.

Section 6:
   as defined in [RFC3344].  IANA should assign a Type value for this Extension

Section 7:

-Pete

--
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Mizikovsky, Semyon B (Simon)" <[email-masked]>
Date: Wed, 30 Jun 2010 08:28:53 -0500

1. The G-bit set by the MN MUST not be manipulated by the FA, and shall be taken literally. If FA policy allows GRE encapsulation and FA adds the GRE-Key Extension, but HA does not support GRE encapsulation and does not understand this extension, than perfectly good RRQ will be "corrupted" by the FA by adding this non-skippable extension, and rejected by the HA with "Unknown Extension". This is not good. In other words, if MN does not set the G-bit, the FA MUST NOT add the GRE-Key extension.

2. As the corollary, if the HA receives the RRQ with G=0 and GRE-KEY Extension present, and it recognizes this extension, it MUST reject the RRQ as improperly formatted. If the HA receives the RRQ with G=0 and the HA does not recognize the GRE-KEY extension, it should treat the RRQ as if the GRE-KEY extension were not present.

3. If the RRQ has the G=1 (set by the MN, of course, because FA can not manipulate it!), and it does not contain the GRE-KEY extension, it would indicate to the HA that FA does not support the GRE-KEY extension, and the RRQ should be treated as usual according to the RFC 3344.

4. If the RRQ has the G=1 (set by the MN, of course, because FA can not manipulate it!), and it does contain the GRE-KEY extension, it would indicate to the HA that FA supports the GRE-KEY extension, and the RRQ should be treated by the HA according to the local policy, i.e. the GRE Key encapsulation can be chosen.

Semyon Mizikovsky
Alcatel Lucent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of McCann Peter-A001034
Sent: Friday, June 25, 2010 4:38 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Mip4] WGLC: draft-ietf-mip4-gre-key-extension-00.txt

Abstract:
   to setup
SHOULD BE:
   to set up

   extension option allows
SHOULD BE:
   extension allows

   for Mobile Ipv4.
SHOULD BE:
   for Mobile IPv4.

Section 1:

Section 4.1:

Section 4.2:
   If the HA receives

Section 5:

Section 6:

Section 7:

-Pete