| Message ID | 20171220170607.41516-1-lorenzo@google.com |
|---|---|
| Headers | show |
| Series | : Support multiple VTIs with the same src+dst pair | expand |
On Thu, Dec 21, 2017 at 02:06:00AM +0900, Lorenzo Colitti wrote: > When using IPsec tunnel mode, VTIs provide many benefits compared > to direct configuration of xfrm policies / states. However, one > limitation is that there can only be one VTI between a given pair > of IP addresses. This does not allow configuring multiple IPsec > tunnels to the same security gateway. This is required by some > deployments, for example I-WLAN [3GPP TS 24.327]. > > This patchset introduces a new VTI_KEYED flag that allows > configuration of multiple VTIs between the same IP address > pairs. The semantics are as follows: > > - The output path is the same as current VTI behaviour, where a > routing lookup selects a VTI interface, and the VTI's okey > specifies the mark to use in the XFRM lookup. > - The input and ICMP error paths instead work by first looking up > an SA with a loose match that ignores the mark. That mark is > then used to find the tunnel by ikey (for input packets) or > okey (for ICMP errors). > > In order for ICMP errors to work, flags are added to the common > IP lookup functions to ignore the tunnel ikey and to look up > tunnels by okey instead of ikey. > > On the same IP address pair, keyed VTIs can coexist with each > other (as long as the ikeys are different), but cannot coexist > with keyless VTIs. This is because the existing keyless VTI > behaviour (which this series does not change) is to always accept > packets matching an input policy, regardless of whether there is > any matching XFRM state. Thus, the keyless VTI would accept the > traffic for the keyed tunnel and drop it because it would not > match the keyed tunnel's state. I think this is not the way we should go. Instead of creating some new sort of VTI interfaces that have incompatibilities with the old ones, we should create something new. The fact that you need new keyed VTIs looks a bit like a workaround of the design limitations the VTI interfaces have. Unfortunately this is not the only limitation of VTI and I think we don't get what we really want by changing VTI without breaking existing userspace. The problem is that VTI interfaces are IP tunnels, and this is not the thing we need. The tunnel is already implemented in the generic xfrm code. All we need is some interface we can route through. In particular we need something that can work with transport mode too. I showed already some ideas on creating xfrm interfaces at the IPsec workshop in Seoul and my plan is to discuss this at the upcomming IPsec workshop, so that we get something everybody is happy with. In particular I want to have feedback from the userspace IPsec IKE developers before we change/create something.
On Wed, Jan 3, 2018 at 9:10 PM, Steffen Klassert <steffen.klassert@secunet.com> wrote: > The fact that you need new keyed VTIs looks a bit like a workaround > of the design limitations the VTI interfaces have. Unfortunately > this is not the only limitation of VTI and I think we don't get what > we really want by changing VTI without breaking existing userspace. Actually, I added the flag mostly to ensure that there would be no changes in behaviour at all - so, for example, to return EEXIST if someone tried to create two VTIs on the same IP address pair without the flag. But perhaps that's not important. It's unlikely that anyone would be trying to do this, since it has always returned an error. If it's indeed not important, then I think it may be possible to fix the limitations that stop there from being two VTIs with the same IP address pair without introducing a new flag or userspace-visible changes. (I don't think it's too far off what this patch series does today.) If existing setups that only have one VTI per IP address pair continue to work as before, but setups where there is more than one VTI per IP address pair now work in some way, would that be acceptable? > The problem is that VTI interfaces are IP tunnels, and this is > not the thing we need. The tunnel is already implemented in the > generic xfrm code. All we need is some interface we can route > through. In particular we need something that can work with > transport mode too. Well, I'm not sure. Personally I think VTIs are a pretty natural fit for tunnel mode IPsec. For example, they provide an easy way to assign an IP address to an IPsec tunnel which is then used for packets originated on that tunnel. That doesn't really make much sense in transport mode, because in transport mode the IP addresses used are the ones of the physical interfaces that send the packets. > I showed already some ideas on creating xfrm interfaces at the > IPsec workshop in Seoul and my plan is to discuss this at the > upcomming IPsec workshop, so that we get something everybody is > happy with. In particular I want to have feedback from the > userspace IPsec IKE developers before we change/create something. I did look at the code in the ipsec-next-xfrmi tree for a while - wrote some tests for it, etc. The main reason I didn't pursue it is that, as written, it couldn't support our use cases. The main reasons were: 1. It needs to be bound to a specific underlying interface. It looks like that interface must have a 6-byte hardware address (and thus can't be a cellular interface), but I'm not 100% sure. By contrast, the VTI supports an optional underlying link index, and doesn't pose any requirements on hardware addresses. If it's possible to make the underlying interface optional, by storing the underlying ifindex instead of the dev (like tunnels do) then that might work. 2. It cannot use the output mark to influence routing of the transformed packets, because it uses the output mark/mask for its own purposes. Unfortunately, influencing routing of the transformed packets was the reason we proposed XFRMA_OUTPUT_MARK in the first place, so this is a showstopper :-(. Do you recall why you used the output mark for this, as opposed to the SA mark? If it's possible to use the SA mark instead, that might work. If you're willing to evolve the xfrmi design in response to our feedback, I can try to make the xfrmi code fit our use cases and send patches over the next couple of weeks. But I don't think we can wait until the discussion at the ipsec workshop to discover whether xfrmi might be a feasible solution for us. By then we'll either have had to do something out of tree (likely the keyed VTI patches, or something like them) or postponed this work to a future release. Thoughts?
On Fri, Jan 05, 2018 at 01:41:46AM +0900, Lorenzo Colitti wrote: > On Wed, Jan 3, 2018 at 9:10 PM, Steffen Klassert > <steffen.klassert@secunet.com> wrote: > > The fact that you need new keyed VTIs looks a bit like a workaround > > of the design limitations the VTI interfaces have. Unfortunately > > this is not the only limitation of VTI and I think we don't get what > > we really want by changing VTI without breaking existing userspace. > > Actually, I added the flag mostly to ensure that there would be no > changes in behaviour at all - so, for example, to return EEXIST if > someone tried to create two VTIs on the same IP address pair without > the flag. But perhaps that's not important. It's unlikely that anyone > would be trying to do this, since it has always returned an error. > > If it's indeed not important, then I think it may be possible to fix > the limitations that stop there from being two VTIs with the same IP > address pair without introducing a new flag or userspace-visible > changes. (I don't think it's too far off what this patch series does > today.) If existing setups that only have one VTI per IP address pair > continue to work as before, but setups where there is more than one > VTI per IP address pair now work in some way, would that be > acceptable? Well, it would be acceptable to support this. The reason why I don't want it is that we already had problems with such extensions in the past. The VTI interfaces were developed for one special usecase, then extended to try to support more. The result was that some user configurations did not work anymore. And still it has design limitations that we can't work around. Also we changed generic tunnel lookup code to flag that we use GRE keys for something that is not a GRE key but a VTI interface marker. Your patches need to extend the generic tunnel lookup code again for this very special usecase. I just don't want to mess around too much with this. > > > The problem is that VTI interfaces are IP tunnels, and this is > > not the thing we need. The tunnel is already implemented in the > > generic xfrm code. All we need is some interface we can route > > through. In particular we need something that can work with > > transport mode too. > > Well, I'm not sure. Personally I think VTIs are a pretty natural fit > for tunnel mode IPsec. For example, they provide an easy way to assign > an IP address to an IPsec tunnel which is then used for packets > originated on that tunnel. The IPsec tunnel endpoint addresses are already defined by the SA, so there is no need to define them again at the interface. All we need is some marker (maybe a new lookup key) to assign the SAs to a certain VTI interface. > That doesn't really make much sense in > transport mode, because in transport mode the IP addresses used are > the ones of the physical interfaces that send the packets. Right, and this is one of the limitations we can't overcome with a VTI. So we need to find a new solution for transport mode anyway. > > > I showed already some ideas on creating xfrm interfaces at the > > IPsec workshop in Seoul and my plan is to discuss this at the > > upcomming IPsec workshop, so that we get something everybody is > > happy with. In particular I want to have feedback from the > > userspace IPsec IKE developers before we change/create something. > > I did look at the code in the ipsec-next-xfrmi tree for a while - > wrote some tests for it, etc. To give people on the list a chance to follow what we are talking about, here is the link to the code: https://git.kernel.org/pub/scm/linux/kernel/git/klassert/linux-stk.git/log/?h=ipsec-next-xfrmi > The main reason I didn't pursue it is > that, as written, it couldn't support our use cases. The main reasons > were: > > 1. It needs to be bound to a specific underlying interface. It looks > like that interface must have a 6-byte hardware address (and thus > can't be a cellular interface), but I'm not 100% sure. By contrast, > the VTI supports an optional underlying link index, and doesn't pose > any requirements on hardware addresses. If it's possible to make the > underlying interface optional, by storing the underlying ifindex > instead of the dev (like tunnels do) then that might work. This should be possible. > 2. It cannot use the output mark to influence routing of the > transformed packets, because it uses the output mark/mask for its own > purposes. Unfortunately, influencing routing of the transformed > packets was the reason we proposed XFRMA_OUTPUT_MARK in the first > place, so this is a showstopper :-(. Do you recall why you used the > output mark for this, as opposed to the SA mark? If it's possible to > use the SA mark instead, that might work. Well, using the output mark was an easy way to get a lookup working for the first version. I already noticed that it was not a so good idea. Maybe we need some new lookup key for IPsec lookups... > > If you're willing to evolve the xfrmi design in response to our > feedback, I can try to make the xfrmi code fit our use cases and send > patches over the next couple of weeks. Yes, sure :-) The current code is just a discussion base, it was likely that it changes. > But I don't think we can wait > until the discussion at the ipsec workshop to discover whether xfrmi > might be a feasible solution for us. By then we'll either have had to > do something out of tree (likely the keyed VTI patches, or something > like them) or postponed this work to a future release. I don't want to rush with this, I want to have feedback from as many potential users as possible to be sure to end up with the right thing. I really want to avoid to have yet another inerface that is almost what we need, like VTI is.
Hi Lorenzo, I agree vti is very limiting! I am glad to hear about xfrmi. I saw two tunnels between gateways send traffic using VTI. So I am curious what is different in your case. Or are you dealing with something else? Here are a couple of outputs from libreswan testing this is the verbose output. https://swantest.libreswan.fi/results/blackswan/2018-01-05-swantest-3.22-596-g6bac0de35-master/netkey-vti-09/OUTPUT/west.console.verbose.txt [root@west netkey-vti-09]# ip xfrm state src 192.1.2.23 dst 192.1.2.45 proto esp spi 0x0eb97a56 reqid 16393 mode tunnel replay-window 32 flag af-unspec aead rfc4106(gcm(aes)) 0xcf25becdc6c196ff04b9e893d2caa387ed63bc96cf66ab7c1e5c74d32b9eeb801f06fbf3 128 src 192.1.2.45 dst 192.1.2.23 proto esp spi 0x507929e8 reqid 16393 mode tunnel replay-window 32 flag af-unspec aead rfc4106(gcm(aes)) 0x8b5f8143cb6f361e57b0096bc1a444a65e244f97ba76e8779b968bcae54b78cea7c17d38 128 src 192.1.2.23 dst 192.1.2.45 proto esp spi 0x73eab5cf reqid 16389 mode tunnel replay-window 32 flag af-unspec aead rfc4106(gcm(aes)) 0xb00cc4d0da414cba35c9a41e176fdafb92af0a7912d633c1c3f4623bee2d090173e3fca3 128 src 192.1.2.45 dst 192.1.2.23 proto esp spi 0x52581beb reqid 16389 mode tunnel replay-window 32 flag af-unspec aead rfc4106(gcm(aes)) 0x01b906499806ec2436ffe125f54ce297c3a3a14bb19fcbf51f16888c6927a20cd0dc5e67 128 a santized output https://swantest.libreswan.fi/results/blackswan/2018-01-05-swantest-3.22-596-g6bac0de35-master/netkey-vti-09/OUTPUT/west.console.txt Also from an older test: https://swantest.libreswan.fi/results/blackswan/2018-01-04-swantest-3.22-596-g6bac0de35-master/netkey-vti-02/OUTPUT/west.console.txt regards, -antony On Thu, Dec 21, 2017 at 02:06:00AM +0900, Lorenzo Colitti wrote: > When using IPsec tunnel mode, VTIs provide many benefits compared > to direct configuration of xfrm policies / states. However, one > limitation is that there can only be one VTI between a given pair > of IP addresses. This does not allow configuring multiple IPsec > tunnels to the same security gateway. This is required by some > deployments, for example I-WLAN [3GPP TS 24.327]. > > This patchset introduces a new VTI_KEYED flag that allows > configuration of multiple VTIs between the same IP address > pairs. The semantics are as follows: > > - The output path is the same as current VTI behaviour, where a > routing lookup selects a VTI interface, and the VTI's okey > specifies the mark to use in the XFRM lookup. > - The input and ICMP error paths instead work by first looking up > an SA with a loose match that ignores the mark. That mark is > then used to find the tunnel by ikey (for input packets) or > okey (for ICMP errors). > > In order for ICMP errors to work, flags are added to the common > IP lookup functions to ignore the tunnel ikey and to look up > tunnels by okey instead of ikey. > > On the same IP address pair, keyed VTIs can coexist with each > other (as long as the ikeys are different), but cannot coexist > with keyless VTIs. This is because the existing keyless VTI > behaviour (which this series does not change) is to always accept > packets matching an input policy, regardless of whether there is > any matching XFRM state. Thus, the keyless VTI would accept the > traffic for the keyed tunnel and drop it because it would not > match the keyed tunnel's state. > > Changes from RFC series: > - Processing of ICMP errors now works when ikey != okey. > - Series now contains changes to the common tunnel lookup > functions to match tunnels by okey and to ignore ikey when > matching. > - Fixed missing EXPORT_SYMBOL for xfrm_state_lookup_loose. > - Made vti6_lookup static as it should have been.