[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IKEv2 and NAT traversal unclear



Ari Huttunen writes:
> >       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
> >       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?

I think they MUST be sent both ways, but of course only the initiator
can do the decision to move to port 4500. The responder needs to see
the NAT_DETECTION_* payloads from the initiator to know if it is
behind (propably static) NAT, so it can start sending keepalives, and
whether it should allow dynamic updating of the the initiator (i.e if
initiator is behind NAT). The initiator needs to see the
NAT_DETECTION_* payload from the responder to see which end is behind
NAT. If initiator detects either end is behind NAT it needs to change
to port 4500, and if it detects it itself is behind NAT it should
start sending keepalives.

If it detects responder is behind NAT, it might enable dynamic address
update (if the responder is behind dynamic NAT the initiator propably
needs some other protocol to find out the responder and the responder
needs to somehow inform the NAT about the incoming IKE requests so
they will be forwarded to it). 

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

I am currently in the progress of reading the draft completely, and I
have some other comments, but when I read the 2.23 and noticed this
same error myself, I remembered that you complained about this
earlier. I had assumed this had been fixed already, but it wasn't.

So here is a new proposed text for the NAT-T:
----------------------------------------------------------------------
      IKE MUST listen on port 4500 as well as port 500. IKE MUST respond
      to the IP address and port from which packets arrived.

      Both IKE initiator and responder MUST include in their
      IKE_SA_INIT packets Notify payloads of type
      NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP. Those
      payloads can be used to detect if there is NAT between the
      hosts, and which end is behind the NAT. The location of the
      payloads in the IKE_SA_INIT packets are just after the Ni and Nr
      payloads (before the optional CERTREQ payload).

      If none of the NAT_DETECTION_SOURCE_IP payload(s) received
      matches the hash of the source IP and port found from the IP
      header of the packet containing the payload, it means that the
      the other end is behind NAT (i.e someone along the route changed
      the source address of the original packet to match the address
      of the NAT box). In this case this end should allow dynamic
      update of the other ends IP address, as described later.

      If the NAT_DETECTION_DESTINATION_IP payload received does not
      match the hash of the destination IP and port found from the IP
      header of the packet containing the payload, it means that this
      end is behind NAT (i.e the original sender sent the packet to
      address of the NAT box, which then changed the destination
      address to this host). In this case the this end should start
      sending keepalive packets as explaind in [Hutt02].

      The IKE initiator MUST check these payloads if present and if
      they do not match the addresses in the 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.

      The original source and destination IP address required for the
      transport mode TCP and UDP packet checksum fixup (see [Hutt02])
      are obtained from the Traffic Selectors associated with the
      exchange. In the case of NAT-T, the Traffic Selectors MUST
      contain exactly one IP address which is then used as the
      original IP address.

      There are cases where a NAT box decides to remove mappings that
      are still alive (for example, the keepalive interval is too
      long, or the NAT box is rebooted). To recover in these cases,
      hosts that are not behind a NAT SHOULD send all packets
      (including retranmission packets) to the IP address and port
      from the last valid authenticated packet from the other end (i.e
      dynamically update the address). A host behind a NAT SHOULD NOT
      do this because it opens a DoS attack possibility. Any
      authenticated IKE packet or any authenticated UDP encapsulated
      ESP packet can be used to detect that the IP address or the port
      has changed.
----------------------------------------------------------------------

i will come back to the other comments later. 
-- 
kivinen@xxxxxx
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/