Inline On Mon, Dec 11, 2023 at 10:48:57AM -0500, Michael Richardson wrote: > RFC8994 says: > > 6.8.3.1. Native IPsec > > An ACP node that is supporting native IPsec MUST use IPsec in tunnel > mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next > Header of 41). It MUST use local and peer link-local IPv6 addresses > for encapsulation. Manual keying MUST NOT be used, see Section 6.2. > Traffic Selectors are: > > TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > IPsec tunnel mode is required because the ACP will route and/or > forward packets received from any other ACP node across the ACP > secure channels, and not only its own generated ACP packets. With > IPsec transport mode (and no additional encapsulation header in the > ESP payload), it would only be possible to send packets originated by > the ACP node itself because the IPv6 addresses of the ESP must be the > same as that of the outer IPv6 header. > > ---- > > I know that we did many rounds to get this right, but I feel that maybe we > did it wrong. > > The goal are packets that look like: > > (a) IPv6-LL ESP[nh=41] IPv6-ULA[1] ULP
What is "ULP" ? > Rather than packets that look like: > (b) IPv6-LL ESP(nh=41) IPv6-LL[nh=41,4] IPv6-ULA[2] ULP Right > The TS are "everything", so one in fact needs policy based routing on top of > this in order to make anything work. What you want to have is some form of virtual IPsec interface, which in Cisco IOS was introduced in 2007, e.g.: https://www.cisco.com/c/en/us/td/docs/net_mgmt/vpn_solutions_center/2-0/ip_security/provisioning/guide/IPsecPG1.html Other vendors likely similarily in the same time frame. And to the best of my understanting, (a) is what we will get from those interfaces. See also RFC4303, Section 3.1.2. In Linux this is less clear to me. There where much later IPsec VTI interfaces, but they seemed to have some limitations. The latest thing seems to be the xfrm interface which i found in recent strongswan docs, and which supposeldy are supported since 2018: https://docs.strongswan.org/docs/5.9/features/routeBasedVpn.html But i couldn't fully figure out yet, how to configure them, or what header they actually generate. I guess linux means RTFS *sigh*. > What we actually want are transport-mode ESP packets that transport IPIP > packets between ACP nodes. It looks identical to (a) on the wire, but it's > wired into the network stack slightly differently. > > Why didn't we say this? I don't remember that anyone brought up this option in ANIMA. I think we did select the option we have because we expected it to be the to-be-best hardware supported option back when we wrote the text - given the prior evidence in commercial routers. Given how ACP is designed to support different secure channel option, worst case we have to amend our stack with one more IPsec option, if thats what's easier in Linux. But it would be quite annoying if Linux choose a different stack option than what commercial routers had for a decade. If on the other hand we made a mistake and didn't match what the commercial router implementations use, then of course, we can obsolete our currently documented option and replace it. But i don't think/hope that that is the case. Cheers Toerless > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
