Re: NAT Traversal in IKEv2

[Ari Huttunen <Ari.Huttunen@f-secure.com>]

Van Aken Dirk wrote:
> 
> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
>>IMHO, NAT traversal is currently unnecessarily complicated.
>>If we can imagine tweaking some things that we could not tweak
>>when specifying it for IKEv1, we could make it simpler.
>>I would myself throw out transport mode, and specify only
>>tunnel mode for NAT traversal. I would also make IKEv2 always
>>floated, so we can get rid of the ugly part of changing
>>a protocol from one port to another.
> 
> 
> Just to be clear, are you saying that the port for IKEv2 should 
> always be floated even if NAT-traversal is not negotiated?

Yes. It would be much cleaner if IKE packet format was the same
before and after discovering the existance of a NAT, and on the
same ports. (Based on the experience of having gone through the
discussions for producing NAT traversal drafts once already, the
ESP-in-UDP and IKE should stay on the same port. I'm not wishing
to change that.)

Still, this is not a major issue. I don't see a lot of complaints
about the current scheme on this list.

(Van Aken Dirk...)
> Is there a reason for not allowing IKEv2 to not use floating ports ?
> In this way IKEv2 would behave like any other UDP based protocol

I parse this as 'always use'.. Yes, this makes every IKEv2 packet
larger by 4 bytes, according to the current floating scheme. It's also
bound to have, maybe, interoperability issues with earlier IKEs and
maybe firewalls/NATs. Still, I'd prefer the least complex protocol possible.
You can reduce the 4 bytes to even 1 bit if you can tweak both the
IKEv2 and an ESPv2 specification. (Steal one bit of the SPI field..)
I'm not saying you should do it, but it's a possibility.

Ari

-- 
I play it cool and dig all jive,
  that's the reason I stay alive.
   My motto as I live and learn,
    is dig and be dug in return. <Langston Hughes>

Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com

F(ully)-Secure products: Securing the Mobile Enterprise