Hi Chris, > 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. The only difference in VPP between a transport and tunnel mode SA is the presence of the encap. So I think it’s fair to say that what you need is an interface to interact with the L[23] system, ‘encap’ to describe how to encap/decap packets (i.e. what to copy from overlay/underlay (DSCP, ECN, etc) and an SA (for the algo set); Interface + encap + SA VPP doesn’t model encap separately. So it’s a question of where you add the parenthesis. (interface + encap) + SA = ipip tunnel + transport mode SA Or Interface + (encap + SA) = ipsec dedicated interface + tunnel mode SA In both cases the same information is available, it’s just modelled differently. The first model is used since it reuses the types/functionality that VPP already has to support other use case, without the need for a dedicated interface type. Is it not possible for you to work with the first model, or is it less convenient? /neale 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 (#16291): https://lists.fd.io/g/vpp-dev/message/16291 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] -=-=-=-=-=-=-=-=-=-=-=-
