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
