2011年12月7日 星期三

NAT-Traversal

[wiki] NAT traversal and IPsec
http://en.wikipedia.org/wiki/NAT_traversal#NAT_traversal_and_IPsec

[wiki] NAT-T
http://en.wikipedia.org/wiki/NAT-T

NAT-T (NAT traversal in the IKE) is a method of enabling IPsec-protected IP datagrams to pass through network address translation (NAT). RFC 3947 defines the negotiation during the Internet key exchange (IKE) phase and RFC 3948 defines the UDP encapsulation.

An IP packet is modified while passing through a network address translator device in a manner that is incompatible with Internet Protocol Security (IPsec). NAT-T protects the original IPsec encoded packet by encapsulating it with another layer of UDP and IP headers.



How Does NAT-T work with IPSec?
https://supportforums.cisco.com/docs/DOC-16591

RFC3947: Negotiation of NAT-Traversal in the IKE
http://www.ietf.org/rfc/rfc3947.txt
(It seems NATT "MUST" use UDP dport 4500)
(Both data and IKE message after first Phase 1 negotiation could use UDP dport 4500)
3. Phase 1
The detection of support for NAT-Traversal and detection of NAT along the path between the two IKE peers occurs in IKE [RFC2409] Phase 1.

(......)
3.1. Detecting Support of NAT-Traversal
(......)
3.2. Detecting the Presence of NAT
(......)

4. Changing to New Ports
(......)
In Main Mode, the initiator MUST change ports when sending the ID payload if there is NAT between the hosts. The initiator MUST set both UDP source and destination ports to 4500. All subsequent packets sent to this peer (including informational notifications) MUST be sent on port 4500. In addition, the IKE data MUST be prepended with a non-ESP marker allowing for demultiplexing of traffic, as defined in [RFC3948].

Thus, the IKE packet now looks like this:

IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT, ] SIG_I

This assumes authentication using signatures. The 4 bytes of non-ESP marker are defined in the [RFC3948].

(......)

The responder MUST respond with all subsequent IKE packets to this peer by using UDP(4500,Y).

Similarly, if the responder has to rekey the Phase 1 SA, then the rekey negotiation MUST be started by using UDP(4500,Y). Any implementation that supports NAT traversal MUST support negotiations that begin on port 4500. If a negotiation starts on port 4500, then it doesn't need to change anywhere else in the exchange.


RFC3948: UDP Encapsulation of IPsec ESP Packets
http://www.ietf.org/rfc/rfc3948.txt
2.1. UDP-Encapsulated ESP Header Format
The UDP header is a standard [RFC0768] header, where
o the Source Port and Destination Port MUST be the same as that used by IKE traffic,
o the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and
o receivers MUST NOT depend on the UDP checksum being a zero value.

The SPI field in the ESP header MUST NOT be a zero value.


2.2. IKE Header Format for Port 4500
The UDP header is a standard [RFC0768] header and is used as defined in [RFC3947]. This document does not set any new requirements for the checksum handling of an IKE packet.

A Non-ESP Marker is 4 zero-valued bytes aligning with the SPI field of an ESP packet.



IPsec and NAT Traversal - System Administration Guide: IP Services
http://docs.oracle.com/cd/E19963-01/html/821-1453/ipsec-ov-24.html

Linux Kernel 2.6 using KAME-tools -- NAT-Traversal
http://www.ipsec-howto.org/x304.html#AEN471

Openswan / NATTraversal
http://wiki.openswan.org/index.php/Openswan/NATTraversal

沒有留言: