> 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. > 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. :) 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 (#16277): https://lists.fd.io/g/vpp-dev/message/16277 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] -=-=-=-=-=-=-=-=-=-=-=-
