On May 8, 2020, at 3:57 AM, Neale Ranns via lists.fd.io <nranns=cisco....@lists.fd.io> wrote: > > > > From: <vpp-dev@lists.fd.io> on behalf of Christian Hopps <cho...@chopps.org> > Date: Thursday 7 May 2020 at 23:27 > To: "Neale Ranns (nranns)" <nra...@cisco.com> > Cc: Christian Hopps <cho...@chopps.org>, vpp-dev <vpp-dev@lists.fd.io> > Subject: Re: [vpp-dev] IPsec tunnel interfaces? > > > > > On May 7, 2020, at 1:41 PM, Neale Ranns (nranns) <nra...@cisco.com> wrote: > > > > > > Hi Chris, > > > > On 07/05/2020 16:55, "Christian Hopps" <cho...@chopps.org> wrote: > > > > > > > >> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns) <nra...@cisco.com> wrote: > >> > >> > >> Hi Chris, > >> > >> They were replaced by ipip interfaces protected by SAs: > >> https://wiki.fd.io/view/VPP/IPSec#Tunnel_Mode > >> > >> the tunnel always adds encap. You can configure your SA to add additional > >> encap if you want. > > > > Ok, but that's not a replacement for the old functionality, right? The > > old functionality had the SA tunnel represented as an unnumbered interface > > that could be routed onto efficiently using the FIB. The unnumbered > > interface used the SA tunnel endpoint addresses. > > > > It is intended to be a replacement. If it's not then there's a problem and > > I'll address it. > > Great. :) > > > > > Both old an new have one critical thing in common, there's an interface and > > an inbound and outbound SA. > > The old functionality had a ip-in-ip interface tightly coupled to two SAs, > > so tight that there was a dedicated interface type, ipsecX, and the > > interface and SAs were configured at the same time. In the new model that > > coupling is loose; there's a ipip interface and its associated SAs, they > > are configured independently and bound together. > > If you made the ipsecX unnumbered you now make the ipipX unnumbered. If you > > had routes through ipsecX, now you route through IpipX. > > > > The wiki shows the that SA tunnel mode is re-encapsulating the already > > encapsulated IP-IP tunnel traffic. So now I have 3 IP headers instead of > > the 2 IP headers as before? > > > > If an SA is in transport mode it does not add headers, if it's in tunnel > > mode it does. When a packet egresses the tunnel it is encapped by that > > tunnel, if you don't want another set of IP headers then configure the SA > > that protects the tunnel to be in transport mode. > > So with the old functionality the interface was unnumbered, and used the SA > endpoint IPs for the it's encapsulating IP header. Using it with SA in tunnel > mode did not produce 3 IP headers. That's what we need to fix I guess, it > should only produce 2 IP headers, the user's and the SA tunnel IP header. > > You still have the choice to make the ipip interface unnumbered, or you can > assign it a subnet. Or if it’s an L2 interface (like the old ipsec-gre was > and the new protected GRE interface can be) you can add it to a BD. The end > points of the tunnel are your choice. > > > > > Putting aside the wasted IP header bandwidth for the moment though, I > > don't understand what's actually supposed to be happening here. What does > > the configuration look like? I have an SA with endpoints > > (Local-IP,Remote-IP) and I have user traffic with (User-SIP,User-DIP). > > Previously I had an unnumbered interface that used the SAs > > (Local-IP,Remote-IP) for it's IP header. I then routed traffic for > > (User-DIP) over that unnumbered interface. How does one configure that with > > this ipip tunnel replacement? > > > > create ipip src Local-IP dst remote-IP > > set int unnum ipip0 use Eth0 > > ipsec sa add id 5 [crypto .. ] [integ ..] mode=transport > > ipsec sa add id 6 [crypto .. ] [integ ..] mode=transport > > ipsec tun protect ipip0 in 5 out 6 > > set int state ipip0 up > > > > ip route User-DIP/32 via ipip0 > > > > does that get you what you need? > > No, using transport mode IPsec is not an option. It must be an SA in standard > tunnel mode. And it can't have 3 IP headers. :) > > if your original packet that is routed into the tunnel was: > > [ IP (user-DIP, user-SIP) | TCP | Payload ] > > Then the above configuration will give you: > > [ MAC | [ IP (tun-DIP, tun-SIP ) | ESP | IP (User-DIP, User-SIP) | TCP | > Payload ] > > If you didn’t have protection on the tunnel interface, you’d get > > [ MAC | [ IP (tun-DIP, tun-SIP ) | IP (User-DIP, User-SIP) | TCP | Payload ] > > So the SA acts like transport mode, i.e. it’s inserting the ESP header > between the tunnel IP headers and the payload. This is what other uses are > using as a replacement for the old config.
> If your SA was in tunnel mode, then you’d get: > > [ MAC | [ IP (tun-DIP, tun-SIP ) | IP (SA-DIP, SA-SIP) | ESP | IP > (User-DIP, User-SIP) | TCP | Payload ] > > Which I think is the 3 headers you don’t want. > > Are there other properties of a tunnel mode SA that you need that are lost > with this approach? I need to use tunnel mode SAs provided by IKEv2. Transport mode is an optional (normally on-the-wire IKEv2 negotiated) feature of IPsec. These tunnel mode SAs will have IPTFS enabled on them, and that functionality is only defined for IPsec tunnel mode SAs. There will be future work in IETF/ipsecme to enable a form of transport mode support in IPTFS to handle the Cisco-preferred GRE with transport mode IPsec configuration, but that is not available today, and obviously won't be the only option standardized. Thanks, Chris. > /neale > > > > > > > Thanks, > Chris. > > > > > > I did read through the Wiki and it seems that this change was motivated > > by wanting to cleanup the IPsec API, but that hardly seems like > > justification to eliminate the efficient use of an entire variant of > > commonly used IPsec functionality. > > > > Cleaning up the API was one motivation. It was a pain that each time we > > added new attributes to SA creation (like ESN, UDP, algo=foo) (for use with > > the SPD) we had to make similar changes to both the ipsec and ipsec_gre > > create APIs. The other motivation was removing 2 interface types that did > > exactly the same as the existing ipip and gre tunnels (and the same goes > > for their APIs too, like how do I configure what DCSP, ECN, DF to copy on > > encap/decap). > > > > /neale > > > > > > > > Could we bring back the functionality using more "acceptable to the > > project" APIs or something? > > > > Thanks, > > Chris. > > > >> > >> /neale > >> > >> > >> From: <vpp-dev@lists.fd.io> on behalf of Christian Hopps > >> <cho...@chopps.org> > >> Date: Wednesday 6 May 2020 at 14:32 > >> To: vpp-dev <vpp-dev@lists.fd.io> > >> Cc: Christian Hopps <cho...@chopps.org> > >> Subject: [vpp-dev] IPsec tunnel interfaces? > >> > >> Hi, vpp-dev, > >> > >> Post 19.08 seems to have removed IPsec logical interfaces. > >> > >> One cannot always use transport mode IPsec. > >> > >> How can I get the efficiency of route based (FIB) IPsec w/o transport > >> mode? Adding superfluous encapsulations (wasting bandwidth) to replace > >> this (seemingly lost, hope not) functionality is not an option. > >> > >> Thanks, > >> Chris. > >> > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16283): https://lists.fd.io/g/vpp-dev/message/16283 Mute This Topic: https://lists.fd.io/mt/74027328/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
