Subject: Some IKE/NAT questions

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Mon, 24 Feb 2003 23:21:58 -0500

I'm reading my sneak preview soon-to-be-available version
of IKEv2, and also trying to write a tutorial. Anyway,
that's caused me to think deeply about NATs and IKE. Here
are some questions.

1) Why are there NAT-DETECTION-SOURCE-IP and
NAT-DETECTION-DESTINATION-IPs in message 1,
since Bob isn't going to do anything with them?
It's only those notify payloads in message 2 that
affect the protocol, if I'm reading the spec
correctly.

2) Would it be useful to do a "You Tarzan" optional
payload in message 1? That would allow Alice to initiate
communication with a node behind a NAT box that doesn't
have a global IP address, but does have a name. The
NAT gateway could look for this field in IKE messages
and translate the destination IP address to be Bob's
(Tarzan's) inner IP address.

3) There's some conniptions going on because helpful
NAT boxes are doing strange things with packets on UDP
port 500, because of how IKEv1 was specified. (If I'm
understanding things, life
would have been simpler if IKEv1 simply said to
reply to the UDP port from which the packet was
received, but instead it said reply to 500). But
IKEv1 didn't so NATs look for port 500 and do weird things.
As a result, IKEv2 seems to be trying to detect whether
there's a NAT, and if so, to use port 3500 so that IKEv2
can do the right thing, i.e., if a NAT has translated
the UDP port, simply reply to whatever port you get the
packet on.

Anyway, why not always use port 3500, and stop using
500 for IKEv2 (other than perhaps trying port 500 in
case you're talking to an IKEv1-only node).

Radia

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Feb 2003 10:13:18 +0100

In your previous mail you wrote:

=> you should read my "address management for IKEv2" proposal
(draft-dupont-ikev2-addrmgmt-00.txt). I am working on a second
version, I'll send it to you in private.

=> they can't be in message 1 because the used hash is not
yet negociated...

=> the specs seems to have many little issues, this is why
I wrote my proposal.

=> the only reasonable help you can get from NATs is
their auto-destruction (:-). IMHO I don't believe this
(NAT name to address translation) will work or is desirable.

   received, but instead it said reply to 500).

=> yes, this is the issue. In IKEv2 there is an absolute rule
about this: replies use reversed addresses and ports.a

   But IKEv1 didn't so NATs look for port 500 and do weird things.

=> more weird things (:-).

=> 4500

=> yes, the NAT traversal itself is well defined in IKEv2.
The issue is there are some little details (as you've found
according to your next messages) which need to be improved/fixed.

=> we had already this discussion (port 500 or a new port).
BTW NAT traversal has a major security problem and it is very
fine to be able to associate the port 4500 to IPsec (i.e.,
not only IKE) with active NAT traversal.

Thanks

[email-masked]