Subject: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 24 Jan 2011 20:33:58 +0100

The ID has had 3 reviews as we require.
So, we are now  ready to ask the WG if they think we should adopt the 
document.

Please express your opinion before monday 31st jan.

Reviews can be found:

The I-D: draft-korhonen-mext-mip6-altsec-06  has been reviewed by:

1. Jan Zorz
http://www.ietf.org/mail-archive/web/mext/current/msg04489.html

2. Domagoz Premec
http://www.ietf.org/mail-archive/web/mext/current/msg04457.html

3. Ryuji Wakikawa
http://www.ietf.org/mail-archive/web/mext/current/msg04470.html

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Mon, 24 Jan 2011 21:47:32 +0100

> Please express your opinion before monday 31st jan.

Well, I think this I-D should go forward as it solves some issues with 
current thinking of mobile part of the stack, and it has an 
implementation, that works fine.

Regards, Jan Zorz
go6.si

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 24 Jan 2011 22:58:09 +0100

Hi,

> implementation, that works fine.

At some point, I wanted to test the implementation initially provided on 
http://dsmipv6-tls.nokia.net but when I went to the site later it was
no more available (current status). BTW, I was told the source code
would be available for review but never got a pointer. Which
implementation are you using? 

Regarding the draft, I am *against* adopting the document for the reasons
already given on the list a while ago (see [1]):

> Honestly, I *must* be missing something. To make a parallel, to me, you
> are trying to change a screwdriver into a hammer. And I still don't
> understand why.
>
> If you simply need a solution to encapsulate IPv4 or IPv6 packets over
> UDP with an ESP header, why don't you simply use an IKE daemon with
> support for MOBIKE? Or if you really want to use TLS for key
> provisioning, some DTLS-based VPN?
>
> Here, you combine UDP-encapsulated IPsec packet format for NAT-T (copy
> and paste of ESP rfc, iirc), replace usual IKE for key establishment by a
> *custom* protocol based on TLS and HTTP to provide key provisioning. There
> is even a section (5.6.5) to provide a mapping between TLS ciphersuites
> and the algs used to protect IPsec-piggybacked packets.

To me, what the draft describes is a patchwork based on MIPv6, ESP and
TLS. Instead of building on top of those protocols (read modularity and
interoperability), it reuses (hijacks) various blocks of associated
standards in a non-modular way. For instance, one has to reimplement ESP
in userspace to support the protocol.

Additionally, it does not support RO.

Cheers,

a+

[1]: http://permalink.gmane.org/gmane.ietf.mip6/10368

---

From: <[email-masked]>
Date: Mon, 24 Jan 2011 22:03:33 +0000

Inline:

>in userspace to support the protocol.

We are specifying an encapsulation method in the I-D. To say that one has
to reimplement ESP in userspace is incorrect.
We are reusing TLS which is widely implemented today. I do not see a
problem with reuse.

>Additionally, it does not support RO.

We are adding RO support to the spec. It is not a big deal to support RO
between MIP6 nodes. Securing the RO signaling messages between the MN-HA
uses the same method used for the BU/BAck messages.

-Raj

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 24 Jan 2011 16:05:43 -0800 (PST)

----- Original Message ----
> From: "Jan Zorz @ go6.si" <[email-masked]>
> To: [email-masked]
> Sent: Mon, January 24, 2011 2:47:32 PM
> Subject: Re: [MEXT] Call for WG adoption of I-D: 
>draft-korhonen-mext-mip6-altsec
> 
> Well, I think this I-D should go forward  as it solves some issues with current 
>thinking of mobile part of the stack, and  it has an implementation, that works 
>fine.
> 

+1

--behcet

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Tue, 25 Jan 2011 09:05:58 +0100

> Additionally, it does not support RO.

Currently weakest point of the draft. This needs to be changed, as I 
pointed out in review.

Regards, Jan

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 25 Jan 2011 09:13:15 +0100

Hi,

> to reimplement ESP in userspace is incorrect.

Then please explain how one is supposed to get the format described in
section 6.4 which is *explicitly* borrowed from RFC 4303 w/o
reimplementing it in userspace?

Or are you pushing SP and SA in order to reuse what is already
implemented in the IPsec stack?

BTW, is the packages/sources of your implementation still available
somewhere? I expected the patches to be pushed upstream at some point.

Cheers,

a+

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 25 Jan 2011 22:48:54 +0000

Hi Raj,
 
> We are specifying an encapsulation method in the I-D. To say that one
> has to reimplement ESP in userspace is incorrect.

The encapsulation format you have in the I-D is:

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
:         IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya)        :
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
:            UDP header (src-port=Xp,dst-port=Yp)               :
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|PType=8|                    SPI                                | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|                      Sequence Number                          | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
|                    Payload Data* (variable)                   | |   ^
:                                                               : |   |
|                                                               | |Conf.
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|               |     Padding (0-255 bytes)                     | |ered*
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
|                               |  Pad Length   | Next Header   | v   v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|         Integrity Check Value-ICV   (variable)                |
:                                                               :
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 7: UDP Encapsulated Binding Management Message Format

Which looks like a copy/paste of the ESP specification [RFC4303]:

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
|               Security Parameters Index (SPI)                 | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|                      Sequence Number                          | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
|                    Payload Data* (variable)                   | |   ^
~                                                               ~ |   |
|                                                               | |Conf.
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|               |     Padding (0-255 bytes)                     | |ered*
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
|                               |  Pad Length   | Next Header   | v   v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|         Integrity Check Value-ICV   (variable)                |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 1.  Top-Level Format of an ESP Packet

So the question is: Is your intent to provide a UDP encapsulation format for the already specified ESP protocol, or to provide an alternative encapsulation format to ESP?

--julien

---

From: Hidetoshi Yokota <[email-masked]>
Date: Wed, 26 Jan 2011 10:41:51 +0900

Hi,

I also tested the implementation, which worked very well, succeeding in
setting up an inter-continental MIPv6 connection without any hassle. I
believe that the I-D can resolve one of the deployment issues and thus
support it as a WG draft. I hope to see it really deployed in commercial
mobile networks and devices.

Regards,
-- 
Hidetoshi

---

From: jouni korhonen <[email-masked]>
Date: Wed, 26 Jan 2011 09:55:07 +0200

Few things. The draft already states that "The Padding, Pad Length, Next
Header and ICV fields follow the rules of Section 2.4 to 2.8 of [RFC4303]
unless otherwise stated in this document." So, we follow the ESP format
but feel no shame on changing it if we see a reason to do so.

The reason why we chose to do it like this was two fold: 1) some ciphers
etc when used would need ~equivalent encapsulation anyway. 2) if we had
come up with our very own format the question on the list would have
been "why not using RFC4303 encapsulation format". Actually.. the latter
already happened offline.

- Jouni

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 26 Jan 2011 23:19:35 +0000

Hi Jouni,

I understand you "follow the ESP format but feel no shame on changing it if we see a reason to do so", but I am (shamelessly ;) wondering about the actual reason to do so, as per one of the famous Architectural Principles of the Internet documented in RFC 1958: 

   3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

Would you mind enlightening us?

--julien

jouni korhonen wrote:
> 
> Few things. The draft already states that "The Padding, Pad Length,
> Next Header and ICV fields follow the rules of Section 2.4 to 2.8 of
> [RFC4303] unless otherwise stated in this document." So, we follow
> the ESP format but feel no shame on changing it if we see a reason
> to do so.
> 
> The reason why we chose to do it like this was two fold: 1) some
> ciphers etc when used would need ~equivalent encapsulation anyway. 
> 2) if we had come up with our very own format the question on the
> list would have been "why not using RFC4303 encapsulation format".
> Actually.. the latter already happened offline.
> 
> - Jouni
> 
> 
> >>> standards in a non-modular way. For instance, one has to
> reimplement
> >> ESP
> > |PType=8|                    SPI                                |
> ^Int.
> |Cov-
> > |                      Sequence Number                          |
> |ered
> > :                                                               : |
> |
> |Conf.
> |Cov-
> > |                      Sequence Number                          |
> |ered
> > ~                                                               ~ |
> |
> |Conf.
> > So the question is: Is your intent to provide a UDP encapsulation
> format for the already specified ESP protocol, or to provide an
> alternative encapsulation format to ESP?
> >
> > --julien

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 26 Jan 2011 18:32:18 -0500

Hi Chairs,

> Please express your opinion before monday 31st jan.

I support the adoption of this draft as a mext wg document.

Thanks
Suresh

---

From: Ahmad Muhanna <[email-masked]>
Date: Wed, 26 Jan 2011 19:58:33 -0500

Hello Chairs,

I support adopting this draft as a WG document. 

Regards,
Ahmad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
Sent: Monday, January 24, 2011 11:34 AM
To: mext
Subject: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec

The ID has had 3 reviews as we require.
So, we are now  ready to ask the WG if they think we should adopt the document.

Reviews can be found:

1. Jan Zorz

2. Domagoz Premec

3. Ryuji Wakikawa

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 27 Jan 2011 08:15:15 -0800

Julien,

> without of course using this argument to reject improvements.

I couldn't agree more!

Fred

---

From: Jouni <[email-masked]>
Date: Sat, 29 Jan 2011 00:24:42 +0200

Just a question for my clarification. Do you mean simply taking the UDP encap + ESP format or also inheriting everything those respective RFCs say about their processing etc?

- JOuni

On Jan 28, 2011, at 9:18 PM, Laganier, Julien wrote:

> Hello again,
> 
> Thought that maybe making my question a bit more specific would help: 
> 
> So, why don't you simply define a UDP encapsulation to ESP, instead of duplicating ESP functionality into your framework?
> 
> --julien
> 
> Laganier, Julien wrote:
>> 
>> Hi Jouni,
>> 
>> I understand you "follow the ESP format but feel no shame on changing
>> it if we see a reason to do so", but I am (shamelessly ;) wondering
>> about the actual reason to do so, as per one of the famous
>> Architectural Principles of the Internet documented in RFC 1958:
>> 
>>>>>> To me, what the draft describes is a patchwork based on MIPv6,
>> ESP
>>> and
>>>>>> TLS. Instead of building on top of those protocols (read
>> modularity
>>>>> and
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
>> --
>>> ---
>>>> |PType=8|                    SPI                                |
>>> ^Int.
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
>> -
>>> ---
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
>> --
>>> ---
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
>> --
>>> -
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
>> -
>>> ---
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -
>> --
>>> ---

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 28 Jan 2011 19:18:39 +0000

Hello again,

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 28 Jan 2011 22:29:50 +0000

Either. 

IMHO both would be cleaner that the current approach. I understand the latter might also have some caveat but maybe they can be dealt with in an elegant manner, without introducing too much complexity, e.g., see Arnaud's m6t (http://tools.ietf.org/html/draft-ebalard-mext-m6t-02.txt)

--julien

Jouni wrote: 
> 
> Just a question for my clarification. Do you mean simply taking the UDP
> encap + ESP format or also inheriting everything those respective RFCs
> say about their processing etc?
> 
> - JOuni
> 
> 
> > So, why don't you simply define a UDP encapsulation to ESP, instead
> of duplicating ESP functionality into your framework?
> >
> > --julien
> >
> > Laganier, Julien wrote:
> >>
> >> Hi Jouni,
> >>
> >>>> |                    Payload Data* (variable)                   |
> |
> >>> ^
> >>>> :                                                               :
> |
> >>> |
> >>>> |                                                               |
> >>> |Conf.
> >>>> +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |
> >>> |
> >>>> |                               |  Pad Length   | Next Header   |
> v
> >>> v
> >>>> |                    Payload Data* (variable)                   |
> |
> >>> ^
> >>>> ~                                                               ~
> |
> >>> |
> >>>> |                                                               |
> >>> |Conf.
> >>>> +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |
> >>> |
> >>>> |                               |  Pad Length   | Next Header   |
> v
> >>> v

---

From: Jouni <[email-masked]>
Date: Sat, 29 Jan 2011 00:54:55 +0200

Hmm.. we do handle SPIs differently and our "ESP" can be absent even if UDP encap is used. Would that be an issue regarding the reuse of existing formats?

- Jouni

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 28 Jan 2011 23:10:07 +0000

None of these two points explains to me why you have to duplicate ESP functionality:

1) You have chosen to handle SPI differently, but I don't know why. 

2) As to ESP being absent, if the goal is to not protect some of the user-plane traffic, you can use ESP-NULL, or just the UDP encap...

--julien

None of the above explains why you need to 

Jouni wrote:
>  
> Hmm.. we do handle SPIs differently and our "ESP" can be absent even if
> UDP encap is used. Would that be an issue regarding the reuse of
> existing formats?
> 
> - Jouni
> 
> 
> > IMHO both would be cleaner that the current approach. I understand
> the latter might also have some caveat but maybe they can be dealt with
> in an elegant manner, without introducing too much complexity, e.g.,
> see Arnaud's m6t (http://tools.ietf.org/html/draft-ebalard-mext-m6t-
> 02.txt)
> >
> > --julien
> >
> > Jouni wrote:
> >>
> >>>>>>> We are specifying an encapsulation method in the I-D. To say
> that
> >>>>> one
> >>>>>> |PType=8|                    SPI
> >>>>>> |                      Sequence Number
> >>>>>> :
> :
> >>>>>> +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> >>>>> |Cov-
> >>>>>> |               |     Padding (0-255 bytes)
> |
> >>>>> |ered*
> >>>>>> :
> :
> >>>>>> |               Security Parameters Index (SPI)
> |
> >>>>> ^Int.
> >>>>>> |                      Sequence Number
> >>>>>> ~
> ~
> >>>>>> +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> >>>>> |Cov-
> >>>>>> |               |     Padding (0-255 bytes)
> |
> >>>>> |ered*
> >>>>>> ~
> ~

---

From: liu dapeng <[email-masked]>
Date: Mon, 31 Jan 2011 08:34:08 +0800

Hi all,

I support this I-D being adopted as WG document. It is useful to
simplify the deployment of MIPv6/DSMIPv6. I also have the chance to
test the implementation on mobile phone, it works fine. Thanks.

Regards,
Dapeng Liu