Re: NAT Traversal in IKEv2

[Charlie_Kaufman@notesdev.ibm.com]

Van Aken Dirk wrote:
> 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

Ari Huttunen responded:
> 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.

I think you're talking about two different issues. I believe the first note
concerns whether IKEv2 might be better off not using UDP port 500 as both
the sending and receiving port for all IKE messages, but rather behave more
like other UDP based protocols and have the initiator use a dynamically
allocated port and the responder use a fixed port (perhaps 500). This would
make NAT traversal work more like traditional UDP based protocols so long
as the initiator is the one whose address is NATed.

I see no serious problems with that proposal, though there are some minor
ones. Some people want IKE messages to originate from "privileged ports"
even though that concept doesn't exist on many network devices. And for
devices where an IKE daemon controls port 500, that is a more natural port
to send on than allocating one. What do others think? I think the spec has
to say that you accept messages from any port anyway if you want to handle
NAT traversal. Should we say it's OK to send from a dynamic port
(optionally)?

I believe the response is talking about sending IKE messages in a modified
format on UDP port 3500 rather than on port 500. Currently that is done in
order to share port 3500 with its use in ESP encapsulation. I believe we
should allow implementations to always use that format and port, but we may
want to allow use of port 500 especially for nodes that want to negotiate
either IKEv1 or IKEv2. Currently, the spec doesn't say support of port 3500
is required at all by an implementation that doesn't want to support NAT
traversal. We could simplify things greatly by saying that IKEv2 always
runs over port 3500 and the initiator can use dynamically allocated ports.
Would people be up for that? I'm torn between wanting simplification and
wanting to minimize changes. I never fully understood the NAT traversal
subtleties until last week. And I might still not... what am I missing?

      --charlie kaufman