From sacadmin Thu Aug 2 13:22:52 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l72KMqVb028245; Thu, 2 Aug 2007 13:22:52 -0700 (PDT) Received: (from sommerfe@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l72KMqxj028241; Thu, 2 Aug 2007 13:22:52 -0700 (PDT) Date: Thu, 2 Aug 2007 13:22:52 -0700 (PDT) From: William Sommerfeld Message-Id: <200708022022.l72KMqxj028241@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Detangle IPsec NAT Traversal [PSARC/2007/449 FastTrack timeout 08/09/2007] Status: RO Content-Length: 563 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Detangle IPsec NAT Traversal 1.2. Name of Document Author/Supplier: Author: Dan McDonald 1.3 Date of This Document: 02 August, 2007 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From sommerfeld@sun.com Thu Aug 2 13:28:33 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l72KSXBP028494 for ; Thu, 2 Aug 2007 13:28:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l72KQH3C029488; Thu, 2 Aug 2007 13:26:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JM500203Y3TYP00@nwk-avmta-2.sfbay.sun.com>; Thu, 02 Aug 2007 13:26:17 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JM500JIJY3SEO90@nwk-avmta-2.sfbay.sun.com>; Thu, 02 Aug 2007 13:26:17 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l72KQFe5009999; Thu, 02 Aug 2007 16:26:15 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l72KQFcm000232; Thu, 02 Aug 2007 16:26:15 -0400 (EDT) Date: Thu, 02 Aug 2007 16:26:15 -0400 From: Bill Sommerfeld Subject: 2007/449 Detangle IPsec NAT Traversal To: PSARC-EXT Cc: dan.mcdonald@sun.com Message-id: <1186086375.29735.32.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 6108 I'm sponsoring the following fast-track for Dan McDonald. Case times out on 08/09/2007. Proposed release binding is Patch; it removes a Project Private interface and introduces several Committed interfaces. Title: "detangle" - Elimination of nattymod for IPsec NAT-Traversal, plus new public interfaces for NAT-Traversal. Description: ============ IPsec NAT Traversal (PSARC 2004/042) includes a nattymod STREAMS module as a Project Private component, which intercepts inbound packets in the kernel and shuffles them directly to ESP. This is tightly tied to our IKE implementation and requires the use of undocumented and private interfaces to plumb and initialize nattymod. We have need for a Public interface to allow the use of NAT Traversal with other key management daemons (see 6558864 and 6481450). This project proposes to remove nattymod, and in its place add a Committed interface to permit IPsec key management applications to enable NAT-Traversal security associations they manage. The overall reduction in ON code is approximately 575 lines (not including deleted Makefiles). Interface Table: ================ Interface Commitment level Description --------- ---------------- ----------- UDP_NAT_T_- Committed If applied to a UDP/IPv4 socket, ENDPOINT outbound packets send via the socket socket option will have the 0-SPI inserted and only packets with a 0-SPI will be delivered to the socket after it has been stripped (per RFC 3948). Also, non-0-SPI inbound packets will be shuffled off to ESP for processing if this socket option is enabled. PF_KEY *_NATT_ Committed These will be better documented in address exten- the pf_key(7P) man page to show sions. how ESP-in-UDP SAs can be managed. "nat_t_port" Project Private Test tool for UDP ports *other* than ike.config(4) the specified UDP port 4500. parameter. NOTE: BOTH sides speaking IKE must have matching nat_t_port settings for this to work. "ipsec-nat-t" Committed Per IANA. This should've been done in /etc/services with 2004/042. Documentation diffs: ==================== pf_key(7P) additional text -------------------------- The address extensions are represented with one to three letters after the word "address," representing (S)RC, (D)ST, (Nl)NAT-T local, (Nr)NAT-T remote, (Is)Inner source, and (Id)Inner destination. + Source and destination address extensions reflect outer-header selectors + for an IPsec SA. An SA is inbound or outbound depending on which of + the source or destination address is local to the node. Inner-source + and inner-destination selectors represent inner-header selectors for + Tunnel Mode SAs. A Tunnel Mode SA MUST have in its outer-headers either + IPPROTO_ENCAP or IPPROTO_IPV6 as its protocol selector, in addition to + filled-in Inner-address extensions. + + 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 + extensions represents the local node's external IP address if it is not + equivalent to the SA's local address. A non-zero remote NAT-T address + represents a peer's behind-a-NAT address if it is not equivalent to the + SA's remote address. An SA with NAT-T extensions will be able to + protect-and-transmit outbound traffic. Processing of inbound NAT-T + traffic requires a UDP socket bound to the appropriate local port and it + MUST have the UDP_NAT_T_ENDPOINT (see udp(7P)) socket option enabled. + Note that when an error occurs, only the base header is sent. Typical errors include: udp(7P) additional text ----------------------- Options at the IP level may be used with UDP; see ip(7P) or | ip6(7p). Additionally, there is one UDP-level option of interest + to IPsec Key Management applications (see ipsec(7P) and pf_key(7P): + + UDP_NAT_T_ENDPOINT + + If this boolean option is set, datagrams sent via this socket + will have a non-ESP marker inserted between the UDP header and + the data. Likewise, inbound packets that match the endpoint's + local-port will be demultiplexed between ESP or the endpoint itself + if a non-ESP marker is present. This option is only available on + IPv4 sockets (AF_INET), and the application must have sufficient + privilege to use PF_KEY sockets to also enable this option. There are a variety of ways that a UDP packet can be lost or ipsec(7P) additional text ------------------------- NAT Traversal IPsec's ESP can also encapsulate itself in UDP if IKE (see in.iked(1M)) discovers a Network Address Translator (NAT) between two communicating endpoints. + A UDP socket can be specified to be a NAT-Traversal endpoint. + See udp(7P) for details. Security Associations AH and ESP use Security Associations (SA). SA's are entities ipseckey(1M) ------------ Replace nat_{loc,rem,lport,rport} keyword descriptions with these: nat_loc
| If the local address in the SA (source or destination) is behind a NAT, this extension indicates the NAT node's globally-routable address. This can match the SA's local address if there is a nat_lport (see below) specified. nat_rem
| If the remote address in the SA (source or destination) is behind a NAT, this extension indicates that node's internal (that is, behind-the-NAT) address. This can match the SA's remote address if there is a nat_lport (see below) specified. nat_lport Identifies the local UDP port on which encapsulation of ESP occurs. nat_rport Identifies the remote UDP port on which encapsulation of ESP occurs. From carlsonj@phorcys.east.sun.com Thu Aug 2 13:53:09 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l72Kr9E7029223 for ; Thu, 2 Aug 2007 13:53:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l72KopRX035153; Thu, 2 Aug 2007 14:50:52 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JM500407Z8T7G00@nwk-avmta-2.sfbay.sun.com>; Thu, 02 Aug 2007 13:50:53 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JM500JAWZ8SESA0@nwk-avmta-2.sfbay.sun.com>; Thu, 02 Aug 2007 13:50:53 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l72Koqnu002188; Thu, 02 Aug 2007 16:50:52 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l72KoqW1002185; Thu, 02 Aug 2007 16:50:52 -0400 (EDT) Date: Thu, 02 Aug 2007 16:50:52 -0400 From: James Carlson Subject: Re: 2007/449 Detangle IPsec NAT Traversal In-reply-to: <1186086375.29735.32.camel@thunk> To: Bill Sommerfeld Cc: PSARC-EXT , Dan.McDonald@sun.com Message-id: <18098.17324.679880.964630@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1186086375.29735.32.camel@thunk> Status: RO Content-Length: 1360 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 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 From danmcd@sun.com Thu Aug 2 14:16:47 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l72LGl8q029964 for ; Thu, 2 Aug 2007 14:16:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l72LERDa022629; Thu, 2 Aug 2007 22:14:30 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JM6005070C4HA00@nwk-avmta-2.sfbay.sun.com>; Thu, 02 Aug 2007 14:14:28 -0700 (PDT) Received: from everywhere.east.sun.com ([129.148.19.2]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JM600J8H0C3EWB0@nwk-avmta-2.sfbay.sun.com>; Thu, 02 Aug 2007 14:14:28 -0700 (PDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l72LEIEn002076; Thu, 02 Aug 2007 17:14:19 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l72LEIoE002075; Thu, 02 Aug 2007 17:14:18 -0400 (EDT) Date: Thu, 02 Aug 2007 17:14:18 -0400 From: Dan McDonald Subject: Re: 2007/449 Detangle IPsec NAT Traversal In-reply-to: <18098.17324.679880.964630@gargle.gargle.HOWL> To: James Carlson Cc: Bill Sommerfeld , PSARC-EXT , Dan.McDonald@sun.com Message-id: <20070802211418.GA2015@sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <1186086375.29735.32.camel@thunk> <18098.17324.679880.964630@gargle.gargle.HOWL> X-Authentication-warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f User-Agent: Mutt/1.4.2.2i Status: RO Content-Length: 2141 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 From carlsonj@phorcys.east.sun.com Thu Aug 2 14:26:51 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l72LQoJe000024 for ; Thu, 2 Aug 2007 14:26:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l72LOV1G026465; Fri, 3 Aug 2007 05:24:33 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JM600C030SVEP00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 02 Aug 2007 14:24:31 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JM600FLH0SUQFA0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 02 Aug 2007 14:24:31 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l72LOUUi002401; Thu, 02 Aug 2007 17:24:30 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l72LOUuM002398; Thu, 02 Aug 2007 17:24:30 -0400 (EDT) Date: Thu, 02 Aug 2007 17:24:30 -0400 From: James Carlson Subject: Re: 2007/449 Detangle IPsec NAT Traversal In-reply-to: <20070802211418.GA2015@sun.com> To: Dan McDonald Cc: Bill Sommerfeld , PSARC-EXT , Dan.McDonald@sun.com Message-id: <18098.19342.591716.15360@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1186086375.29735.32.camel@thunk> <18098.17324.679880.964630@gargle.gargle.HOWL> <20070802211418.GA2015@sun.com> Status: RO Content-Length: 2034 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 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 From danmcd@sun.com Thu Aug 2 15:05:07 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l72M56f9001556 for ; Thu, 2 Aug 2007 15:05:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l72M2aLJ010425; Fri, 3 Aug 2007 06:02:48 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JM6007012KNW500@nwk-avmta-2.sfbay.sun.com>; Thu, 02 Aug 2007 15:02:47 -0700 (PDT) Received: from everywhere.east.sun.com ([129.148.19.2]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JM600JKV2KMEVE0@nwk-avmta-2.sfbay.sun.com>; Thu, 02 Aug 2007 15:02:46 -0700 (PDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l72M2bSA002148; Thu, 02 Aug 2007 18:02:37 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l72M2bsV002147; Thu, 02 Aug 2007 18:02:37 -0400 (EDT) Date: Thu, 02 Aug 2007 18:02:37 -0400 From: Dan McDonald Subject: Re: 2007/449 Detangle IPsec NAT Traversal In-reply-to: <18098.19342.591716.15360@gargle.gargle.HOWL> To: James Carlson Cc: Dan McDonald , Bill Sommerfeld , PSARC-EXT , danmcd@sun.com Message-id: <20070802220237.GB2015@sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <1186086375.29735.32.camel@thunk> <18098.17324.679880.964630@gargle.gargle.HOWL> <20070802211418.GA2015@sun.com> <18098.19342.591716.15360@gargle.gargle.HOWL> X-Authentication-warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f User-Agent: Mutt/1.4.2.2i Status: RO Content-Length: 4166 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, DST: Destination address (proto=4) DST: AF_INET: port 0, 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, 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: 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 From carlsonj@phorcys.east.sun.com Fri Aug 3 10:10:12 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l73HABTY019214 for ; Fri, 3 Aug 2007 10:10:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l73H7l1A019456; Sat, 4 Aug 2007 01:07:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JM700503JL3QP00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 03 Aug 2007 10:07:51 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JM700EO4JL2OT90@nwk-avmta-1.sfbay.Sun.COM>; Fri, 03 Aug 2007 10:07:51 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l73H7qaZ004688; Fri, 03 Aug 2007 13:07:52 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l73H7qJL004685; Fri, 03 Aug 2007 13:07:52 -0400 (EDT) Date: Fri, 03 Aug 2007 13:07:52 -0400 From: James Carlson Subject: Re: 2007/449 Detangle IPsec NAT Traversal In-reply-to: <20070802220237.GB2015@sun.com> To: Dan McDonald Cc: Bill Sommerfeld , PSARC-EXT Message-id: <18099.24808.4725.621934@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1186086375.29735.32.camel@thunk> <18098.17324.679880.964630@gargle.gargle.HOWL> <20070802211418.GA2015@sun.com> <18098.19342.591716.15360@gargle.gargle.HOWL> <20070802220237.GB2015@sun.com> Status: RO Content-Length: 591 Dan McDonald writes: > 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. Ah, that's the bit I needed to understand, thanks. I was expecting a closer tie here. -- James Carlson, Solaris Networking 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 From danmcd@Sun.COM Fri Aug 3 10:23:54 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l73HNs3Y019323 for ; Fri, 3 Aug 2007 10:23:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l73HLb5O023992; Fri, 3 Aug 2007 10:21:37 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JM700L03K80Z400@nwk-avmta-2.sfbay.sun.com>; Fri, 03 Aug 2007 10:21:36 -0700 (PDT) Received: from kebe.east.sun.com ([129.148.174.48]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JM700IIFK7ZJ960@nwk-avmta-2.sfbay.sun.com>; Fri, 03 Aug 2007 10:21:35 -0700 (PDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l73HLZsB024116; Fri, 03 Aug 2007 13:21:35 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l73HLZiK024115; Fri, 03 Aug 2007 13:21:35 -0400 (EDT) Date: Fri, 03 Aug 2007 13:21:35 -0400 From: Dan McDonald Subject: Re: 2007/449 Detangle IPsec NAT Traversal In-reply-to: <18099.24808.4725.621934@gargle.gargle.HOWL> To: James Carlson Cc: Dan McDonald , PSARC-EXT Message-id: <20070803172135.GC24010@kebe.East.Sun.COM> Organization: Sun Microsystems, Inc. - Solaris Networking & Security MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <1186086375.29735.32.camel@thunk> <18098.17324.679880.964630@gargle.gargle.HOWL> <20070802211418.GA2015@sun.com> <18098.19342.591716.15360@gargle.gargle.HOWL> <20070802220237.GB2015@sun.com> <18099.24808.4725.621934@gargle.gargle.HOWL> X-Authentication-warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f User-Agent: Mutt/1.4.2.2i Status: RO Content-Length: 470 On Fri, Aug 03, 2007 at 01:07:52PM -0400, James Carlson wrote: > > 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. > > Ah, that's the bit I needed to understand, thanks. I was expecting a > closer tie here. It's a point of principle for me --> KM and traffic keys should be as loosely coupled as possible. Historically, too many KM schemes have turned out to have holes in them. Dan From sommerfeld@sun.com Tue Aug 14 15:36:35 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l7EMaZdU027016 for ; Tue, 14 Aug 2007 15:36:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l7EMY97S025942; Tue, 14 Aug 2007 15:34:09 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JMS00003C0XX700@nwk-avmta-2.sfbay.sun.com>; Tue, 14 Aug 2007 15:34:09 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMS00B0IC0XAOD0@nwk-avmta-2.sfbay.sun.com>; Tue, 14 Aug 2007 15:34:09 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l7EMY87O004875; Tue, 14 Aug 2007 18:34:08 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l7EMY89E020106; Tue, 14 Aug 2007 18:34:08 -0400 (EDT) Date: Tue, 14 Aug 2007 18:34:07 -0400 From: Bill Sommerfeld Subject: Re: 2007/449 Detangle IPsec NAT Traversal In-reply-to: <1186086375.29735.32.camel@thunk> To: PSARC-EXT Cc: dan.mcdonald@sun.com Message-id: <1187130847.18736.48.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1186086375.29735.32.camel@thunk> Status: RO Content-Length: 386 On Thu, 2007-08-02 at 16:26 -0400, Bill Sommerfeld wrote: > I'm sponsoring the following fast-track for Dan McDonald. Case times > out on 08/09/2007. Proposed release binding is Patch; it removes a > Project Private interface and introduces several Committed interfaces. the discussion having converged and the timer having expired, I've marked this case as approved. - Bill