2007/449 Detangle IPsec NAT Traversal

[Dan McDonald]

On Thu, Aug 02, 2007 at 04:50:52PM -0400, James Carlson wrote:
> 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

Just binds.  You need at least lport, and in in.iked's case, we use lport and
laddr.  No connect(3xn) is needed.

> 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)

Sorta.  The NAT-T values in PF_KEY/an-IPsec-SA are derived from a
NAT-Discovery protocol of some sort.  In our case, the IKE mods in RFC 3947.

UDP_NAT_T_ENDPOINT allows the reception of NAT-T packets and the transmission
of 0-SPI packets.  Transmitting ESP-in-UDP needs only a NAT-T SA.

> 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.

That part is correct with respect to inbound ESP-in-UDP packets.

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

Theoretically!  :)

We could implement ESP-in-UDP for IPv6.  Lemme quote 3948:

>    As defined in this document, UDP encapsulation of ESP packets is
>    written in terms of IPv4 headers.  There is no technical reason why
>    an IPv6 header could not be used as the outer header and/or as the
>    inner header.

Right now, however, we do not.  (We were granted an IPv6-big-rule exception
for the original NAT-T case.)

Dan