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