Message-ID: <CAKD1Yr3jumaDOxwKzDA9PavuG7q=FdwHG-x278265MO=ur_EtQ@mail.gmail.com>
Date:   Fri, 5 Jan 2018 01:41:46 +0900
From:   Lorenzo Colitti <lorenzo@...gle.com>
To:     Steffen Klassert <steffen.klassert@...unet.com>
Cc:     netdev@...r.kernel.org,
        Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>,
        Nathan Harold <nharold@...gle.com>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH ipsec-next 0/7]: Support multiple VTIs with the same
 src+dst pair

On Wed, Jan 3, 2018 at 9:10 PM, Steffen Klassert
<steffen.klassert@...unet.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?

Powered by blists - more mailing lists