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

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 12 Jul 2010 11:39:49 -0700

Hi Simon.  Sorry for the delay. I've been on PTO.  Appreciate the
review.

My comments below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mizikovsky, Semyon B (Simon)
Sent: Wednesday, June 30, 2010 6:29 AM
To: McCann Peter-A001034; [email-masked]
Cc: [email-masked]
Subject: Re: [Mip4] WGLC: draft-ietf-mip4-gre-key-extension-00.txt

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.

[Kent Leung (kleung)] The G-bit is set in the Agent Advertisement by FA
when it supports GRE tunneling.  However, MN can decide to use GRE or
IPinIP tunneling in the registration.  Typically in today's deployments,
FA advertises with G-bit enabled, but MN registers w/o G-bit in the
Registration Request.  This creates the issue that GRE Key cannot be
used unless MN requires GRE tunneling, which MN doesn't care about.
There is no method for FA to force MN to set the G-bit in the request.
Also, backwards compatibility is an issue.  In the case when the tunnel
is between FA and HA, the G-bit in the request is not germane to the MN.
It would be more practical that FA and HA negotiate the use of GRE Key.

My main pt here is that if we required that G-bit MUST be set in the
request, then this impacts backward compatibility with existing MNs.  We
need a solution that extends the protocol to support GRE Key w/o
requiring upgrades to all MNs.  I would agree with you if we didn't need
to worry about backward compatibility.

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.

[Kent Leung (kleung)] This is related to #1.

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.

[Kent Leung (kleung)] Yes.  In this case GRE tunneling would be used
between FA and HA assuming that HA also supports GRE.

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.
[Kent Leung (kleung)] Right.

Kent

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]

[Kent Leung (kleung)] Will address Pete's comments in another email.
<snip>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 12 Jul 2010 11:55:11 -0700

Hi Pete.  Thanks for the review comments.  I agree with most of them.
Will coordinate with rest of authors to update the draft.  A few
comments below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
McCann Peter-A001034
Sent: Friday, June 25, 2010 1: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.

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.

[Kent Leung (kleung)] OK for above.

   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?
[Kent Leung (kleung)] We should clarify that operator's home networks
may consist of multiple VPNs.

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. 

[Kent Leung (kleung)] OK

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.

[Kent Leung (kleung)] Agree.  

   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.
[Kent Leung (kleung)] Agree.

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.
[Kent Leung (kleung)] Right.

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

[Kent Leung (kleung)] OK

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.

[Kent Leung (kleung)] OK

Thanks again.

Kent

-Pete

McCann Peter-A001034 wrote:
> 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

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