> On May 9, 2020, at 7:23 AM, Neale Ranns via lists.fd.io > <nranns=cisco....@lists.fd.io> wrote: > > > > 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?
SO, I have implemented https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01 in VPP 19.08. The functionality is working as specified in the draft using tunnel mode SAs. Conceptually what happens (commonly) is this: Pkt Pkt Single IPsec Tunnel Pkt --- --- -------------------------------------- [UA]..[Un] ---> user-intf [ VPP ] sa-tunnel-intf ---> [IP(SATunnel) + ESP + [UA]..[Un][Pad]] The encpasulation *has* to occur at the SA tunnel point, not pre-encapsulated by a generic IP-IP interface with a transport mode SA attached to it downstream. The key here is that there is not a 1-1 mapping of user IP packets to IPsec packets. FWIW, this isn't just a problem for this particular IPTFS technology, there are other simple cases (e.g., sending only pad IPsec packets for limited traffic flow confidentiality) where there is not a 1-1 mapping between user IP packets and SA tunnel mode packets. Now, re-architecting IPTFS to exist outside of IPsec so that it could be a new generic IP tunnel technology is certainly a fun idea (topic for another thread), it's just not an option, or relevant to the functionality that appears to have been lost in VPP. Here's a packet trace for how this works (incoming ping): USER-SIDE: 00:00:08:845351: dpdk-input ... ICMP echo_request checksum 0xaea9 00:00:08:845366: ethernet-input 00:00:08:845382: ip4-input-no-checksum ICMP: 11.11.11.253 -> 12.12.12.12 ICMP echo_request checksum 0xaea9 00:00:08:845389: ip4-lookup ICMP: 11.11.11.253 -> 12.12.12.12 ICMP echo_request checksum 0xaea9 00:00:08:845396: ip4-midchain ICMP: 11.11.11.253 -> 12.12.12.12 ICMP echo_request checksum 0xaea9 00:00:08:845402: iptfs-encap4-tun sa_index: 1 AGGREGATING AND QUEUEING OCCURS - The packet is encapsulated (along with any others currently waiting) into the next-to-be-sent IPTFS packet, which is queued to be sent on a timer from another thread, that output thread follows: SEUCRE-SIDE: Packet 1 This is the next IPTFS packet to send (in this case it just has the 1 ping packet inside but usually has multiple when there's real traffic): 00:00:08:851581: handoff_trace HANDED-OFF: from thread 1 trace index 0 00:00:08:851581: iptfs-output IPTFS Basic Header: flags: 0 resv 0 offset 0:[output gen: 526 pkt 0 of 1]: datablock 0: type: IPv4 offset: 4 pktlen: 84 datablock 1: type: Pad offset: 88 pktlen: 1382 00:00:08:851622: dpdk-esp4-encrypt spi 1112 seq 1 seq_hi 0 iv_size 0 trunc_size 0 pad_bytes 0 next_header 143 cipher none auth none IPTFS Basic Header: flags: 0 resv 0 offset 0 This is the output from the DPDK encryption offload (same packet as above but encrypted) Packet 2 00:00:08:851659: dpdk-crypto-input cryptodev-id 0 next-index 1 00:00:08:851663: ip4-lookup fib 0 dpo-idx 3 flow hash: 0x00000000 IPSEC_ESP: 13.13.13.11 -> 13.13.13.12 00:00:08:851671: ip4-rewrite 00:00:08:851676: TenGigabitEthernet65/0/1-output TenGigabitEthernet65/0/1 IP4: f8:f2:1e:3c:08:29 -> f8:f2:1e:3c:09:b1 IPSEC_ESP: 13.13.13.11 -> 13.13.13.12 00:00:08:851682: TenGigabitEthernet65/0/1-tx TenGigabitEthernet65/0/1 tx queue 5 buffer 0x3feb11e: current data -32, length 1514, buffer-pool 0, ref-count 1, totlen-nifb 0, trace handle 0x5000001 To arrive at this setup the code I add myself as a feature. VNET_FEATURE_INIT (iptfs_encap4_tun_feat_node, static) = { .arc_name = "ip4-output", .node_name = "iptfs-encap4-tun", .runs_before = VNET_FEATURES ("esp4-encrypt-tun", "dpdk-esp4-encrypt-tun"), }; ipsec_add_feature ("ip4-output", "iptfs-encap4-tun", &tfsm->encap4_tun_feature_index); then inside ipsec_tunnel_feature_set I do (in a callback, but whatever): vnet_feature_enable_disable_with_index ( arc, tfsm->encap4_tun_feature_index, t->sw_if_index, enable, &t->output_sa_index, sizeof (t->output_sa_index)); To enable the IPTFS feature on the ipsec* interface arc. If I have missed a simple way to do this with the new code, I'm all ears and thankful for help. :) Thanks, Chris. > > /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 (#16297): https://lists.fd.io/g/vpp-dev/message/16297 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] -=-=-=-=-=-=-=-=-=-=-=-
