2007/449 Detangle IPsec NAT Traversal

[Dan McDonald]

On Thu, Aug 02, 2007 at 05:24:30PM -0400, James Carlson wrote:
> Dan McDonald writes:
> > On Thu, Aug 02, 2007 at 04:50:52PM -0400, James Carlson wrote:
> > > 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.
> 
> How does IPsec associate this particular socket with some PF_KEY
> entry if the UDP socket isn't fully bound?

It doesn't.  The socket, if so marked, merely allows the shuffling-off of
ESP-in-UDP for datagrams that hit that socket.

It's up to Key Management (e.g. IKE) to pin these sockets up.  And usually
the KM traffic uses the 0-SPI value with its peer.

> Can the remote address float?  What happens if I have some specific
> fully-bound UDP sockets open, plus one that's only locally bound on
> the same address and port?

Normal demux rules apply, but if that inbound UDP hits one that's marked as
NAT_T_ENDPOINT it'll either shuffle-and-strip or strip-0-spi, depending.

> > 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.
> 
> OK.  But those addresses and ports could at least in theory come from
> the UDP socket as I described, right?

The socket's address(es) itself are always the normal src/dst address for an
IPsec SA.

If you punchin with Solaris via a NAT box, utter "ipseckey -np dump" and look
at the different address extensions.  Here's one sample from punchin.east:

Base message (version 2) type DUMP, SA type ESP.
Message length 360 bytes, seq=1, pid=106888.
SA: SADB_ASSOC spi=0xf51089fc, replay=32, state=MATURE
SA: Authentication algorithm = hmac-md5
SA: Encryption algorithm = aes-cbc
SA: flags=0xc00a0000 < X_USED X_UNIQUE X_NATT_REM X_TUNNEL >
SRC: Source address (proto=4)
SRC: AF_INET: port 0, <XXX KEBE SAYS withheld>
DST: Destination address (proto=4)
DST: AF_INET: port 0, <XXX KEBE SAYS punchin server Internet-side>
NRM: NAT-T remote address (proto=17)
NRM: AF_INET: port 4500, 192.168.1.100.
INS: Inner source address (proto=0)
INS: AF_INET: port 0, <XXX KEBE SAYS withheld>
IND: Inner destination address (proto=0)
IND: AF_INET: port 0, 0.0.0.0.
KMC: Protocol 1, cookie="default" (1)
AKY: Authentication key.
AKY: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/128
EKY: Encryption key.
EKY: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/128
SID: Source identity, uid=0, type user-FQDN (mbox)
SID: <XXX KEBE SAYS withheld>
 LT: Lifetime information
CLT: 384 bytes protected, 0 allocations used.
CLT: SA added at time Thu Aug 02 17:56:36 2007
CLT: SA first used at time Thu Aug 02 17:56:45 2007
CLT: Time now is Thu Aug 02 17:56:51 2007
SLT: Soft lifetime information:  0 bytes of lifetime, 0 allocations.
SLT: 6480 seconds of post-add lifetime.
SLT: 0 seconds of post-use lifetime.
SLT: Soft expiration occurs in 6465 seconds, at Thu Aug 02 19:44:36 2007.
HLT: Hard lifetime information:  0 bytes of lifetime, 0 allocations.
HLT: 7200 seconds of post-add lifetime.
HLT: 0 seconds of post-use lifetime.
HLT: Hard expiration occurs in 7185 seconds, at Thu Aug 02 19:56:36 2007.

Notice there's a NAT-Remote?  (Now technically tunnel mode SAs don't need
NRM/NLC, but that's a detail.)

The punchin server has a socket open on it's "punchin server Internet-side"
address, at port 4500.  THAT socket has nattymod today, and will use
UDP_NAT_T_ENDPOINT tomorrow.

> > 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.
> 
> Understood.  I was asking about how the bits get tied together -- the
> association of the UDP socket with particular PF_KEY entries.

There is no association, but if there's no socket with UDP_NAT_T_ENDPOINT, no
inbound bits will move.

You're not supposed to manually-add NAT-T Security Associations, but you
can.  If there's no IKE or other app with a NAT_T_ENDPOINT UDP socket, you'll
never see inbound traffic for the inbound NAT-T SA.  My test rigs for
detangle have such a setup, if you want to see.

Dan