2007/449 Detangle IPsec NAT Traversal

[James Carlson]

Bill Sommerfeld writes:
> UDP_NAT_T_-	Committed		If applied to a UDP/IPv4 socket,
> ENDPOINT				outbound packets send via the socket
[...]
> +    Source and destination address extensions reflect outer-header selectors
> +    for an IPsec SA.  An SA is inbound or outbound depending on which of
[...]
> +    NAT-T local and NAT-T remote addresses store local and remote ports
> +    used for ESP-in-UDP encapsulation.  A non-zero local NAT-T address

Just checking that I understand how this works ...

The idea is (roughly) that some application opens a regular UDP
socket, binds and connects it, and then sets the UDP_NAT_T_ENDPOINT
option.  It then uses the PF_KEY interfaces to specify those same
source/destination address values and local/remote port values
(perhaps fetched from the UDP socket via getsockname/getpeername) to
tell the kernel to "wire" ESP into that particular UDP socket.  This
causes ESP-in-UDP packets on the socket to match, be vectored out, and
processed as expected to find inner stuff.

Is the reason why it's IPv4-only because NAT and other evil protocol
filters on IPv6 are considered "really unlikely?"

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677