IKEv2 and NAT traversal unclear

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

All quoted text is from this section of draft-ietf-ipsec-ikev2-10.txt:
> 2.23 NAT Traversal
...
>    It is a common practice of NATs to translate TCP and UDP port numbers
>    as well as addresses and use the port numbers of inbound packets to
>    decide which internal node should get a given packet. For this
>    reason, even though IKE packets MUST be sent from and to UDP port
>    500, they MUST be accepted coming from any port and responses MUST be
>    sent to the port from whence they came. This is because the ports may
>    be modified as the packets pass through NATs. Similarly, IP addresses
>    of the IKE endpoints are generally not included in the IKE payloads
>    because the payloads are cryptographically protected and could not be
>    transparently modified by NATs.
...
>    The specific requirements for supporting NAT traversal are listed
>    below.  Support for NAT traversal is optional. In this section only,
>    requirements listed as MUST only apply to implementations supporting
>    NAT traversal.

It's my opinion that section 2.23 has too much unnecessary explanatory
text that makes it unclear. It is not necessary to explain what a NAT
is and why they exist. A reference would be almost sufficient. Also,
based on reading the paragraphs above, it would seem that only those IKEv2
implementations that support NAT traversal would need to be able to send
IKE packets back to the exact port they came from. Of course this is not
true, because the requirement is stated outside of section 2.23, but this
just shows that you should state each requirement only once.

>       The IKE responder MUST include in its IKE_SA_INIT response Notify
>       payloads of type NAT_DETECTION_SOURCE_IP and
>       NAT_DETECTION_DESTINATION_IP. The IKE initiator MUST check these
>       payloads if present and if they do not match the addresses in the
> 
> 
> 
> IKEv2                 draft-ietf-ipsec-ikev2-10.txt            [Page 36]
> 
> Internet-Draft                                           August 16, 2003
> 
> 
>       outer packet MUST tunnel all future IKE, ESP, and AH packets
>       associated with this IKE_SA over UDP port 4500.  To tunnel IKE
>       packets over UDP port 4500, the IKE header has four octets of zero
>       prepended and the result immediately follows the UDP header. To
>       tunnel ESP packets over UDP port 4500, the ESP header immediately
>       follows the UDP header. Since the first four bytes of the ESP
>       header contain the SPI, and the SPI cannot validly be zero, it is
>       always possible to distinguish ESP and IKE messages.

Is it really so that the NAT_DETECTION_* payloads are only sent in one
direction in IKEv2, while in IKEv1 they are sent both ways? Remember that
in IKEv1 the NAT-D payload is sent both ways because an endpoint only knows
that a NAT exist when a NAT-D payload it *receives* doesn't match the packet
header. Then in IKEv2 the responder will know that a NAT exists iff the
initiator switches ports? What if the initiator initiates to 4500 at the
beginning already?

One inclarity is whether it's possible to use encapsulation in port 4500
for IKE and ESP without the presence of a NAT. I can see reasons for
both wanting to allow it and to disallow it, mainly depending on what you
think of the firewall in-between.

Disclaimer: I've not read the whole IKEv2 draft, just searched for NAT..

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