Re: [Anima] RFC8994's IPsec tunnel description
{clearing out inbox}
Toerless Eckert wrote:
>> 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" ?
If I didn't answer somewhere, it's "Upper Layer Protocol" (e.g., "TCP")
>> 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.:
Yes, the kicker is how packets from that interface are fit into the PAD/SPD.
Ideally, they skip the PAD entirely, and have a (pair of) linked SPD (IPsec
SA) entries. One for outgoing. And the incoming one is linked so that
anything coming out appears to come out the Interface. There should be no
enforcement of Traffic Selectors (TS). I think Cisco got this right all
those years ago.
> In Linux this is less clear to me. There where much later IPsec VTI
> interfaces, but they seemed to have some limitations.
The VTI and XFRM Tunnel interfaces are seemingly identical in most ways,
except that VTI is created/managed by ioctl (which are a pain from languages
other than C), while XFRM Tunnel ocurrs via the NETLINK socket.
The problem that I see is that the packets still seems to go through the
PAD, when it really shouldn't.
> 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.
Agreed.
> 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.
WHen someone shows up with hardware that can't be used, we should have this
discussion.
I will attempt to put together some slides for 119 that address the ULA
addressing on the ACP DULL side that I am attempting to implement.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] RFC8994's IPsec tunnel description
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, :: - :::::::) >TSr = (0, 0-65535, :: - :::::::) > >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. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > -- --- t...@cs.fau.de ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] RFC8994's IPsec tunnel description
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, :: - :::::::) TSr = (0, 0-65535, :: - :::::::) 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 Rather than packets that look like: (b) IPv6-LL ESP(nh=41) IPv6-LL[nh=41,4] IPv6-ULA[2] ULP The TS are "everything", so one in fact needs policy based routing on top of this in order to make anything work. 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? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
