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

[[e-mail] (Arnaud Ebalard)]

Hi,

"Jan Zorz @ go6.si" <[e-mail]> writes:

> On 1/24/11 8:33 PM, marcelo bagnulo braun wrote:
>> 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.
>
> 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.

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