> On Jun 26, 2020, at 4:22 AM, Neale Ranns (nranns) <nra...@cisco.com> wrote: > > Hi Chris, > > As far as I'm concerned, it's your plugin, you can add whatever functionality > you need. If you separate the new interface type out into another plugin, so > it can be used without your feature, then the community will benefit twice. > Let's just make sure we document the whys and hows of each model. > > My preferred outcome though would be to try and find a way for your feature > to work with the existing model. If you'd like to explore those possibilities > perhaps we could discuss code specifics.
Hi Neale, I can try some code specifics. A major part of IPTFS is the constructing of the inner ESP payload, and emitting this with specific timing disassociated with the carried user traffic as described previously (and documented in https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01). I'm going to leave out optimizations that may re-use buffers etc.. to keep things simple.. This IPTFS machinery receives and terminates the user (protected) packet buffer through the graph. IPTFS encapsulates this user packet into 1 or more IPTFS payloads along with other user traffic to the same SA. It then paces the output of these IPTFS payloads on a disconnected output worker. These IPTFS payloads are passed on to the esp_encrypt for adding ESP and the outer tunnel encap. So: e.g., No IPTFS, SA tunnel mode. [IP-A] [IP-A] [IPsec-IP|ESP|IP-A] worker A: [IP-A] -> ipsec-output -> esp-encrypt [outer-encap added] -> ip-lookup ... -> "if-tx" [IP-B] [IP-B] [IPsec-IP|ESP|IP-B] worker A: [IP-A] -> ipsec-output -> esp-encrypt [outer-encap added] -> ip-lookup ... -> "if-tx" [IP-C] [IP-C] [IPsec-IP|ESP|IP-C] worker A: [IP-A] -> ipsec-output -> esp-encrypt [outer-encap added] -> ip-lookup ... -> "if-tx" IPTFS: [IP-A] [IP-A] [TFS|IP-A] worker A: ipsec-output -> iptfs-encap-enq -> encapsualte with other user traffic construct in PACEQ [IP-B] [IP-B] [TFS|IP-A|IP-B] worker A: ipsec-output -> iptfs-encap-enq -> encapsualte with other user traffic construct in PACEQ [IP-C] [IP-C] [TFS|IP-A|IP-B|IP-C] worker A: ipsec-output -> iptfs-encap-enq -> encapsualte with other user traffic construct in PACEQ [TFS|IP-A|IP-B|IP-C] worker A: PACEQ -> iptfs-pacer (timed) enqueue to OUTQ [TFS|IP-A|IP-B|IP-C] [TFS|IP-A|IP-B|IP-C] [IPsec-IP|ESP|TFS|IP-A|IP-B|IP-C] worker B: OUTQ -> iptfs_output (timed) -> esp-encrypt [outer-encap added] -> ip-lookup ... -> "if-tx" Code Details (where does IPTFS hook): SA Policy Directed in ipsec_output_inline if (p0->policy == IPSEC_POLICY_ACTION_PROTECT) { ... if (sa->protocol == IPSEC_PROTOCOL_ESP) { if (ipsec_sa_is_IPTFS (sa)) next_node_index = im->tfs_encap_node_index; else if (is_ipv6) next_node_index = im->esp6_encrypt_node_index; else next_node_index = im->esp4_encrypt_node_index; Interface Directed [iptfs init code] ipsec_add_feature ("ip4-output", "iptfs-encap4-tun", &tfsm->encap4_tun_feature_index); [tunnel create code] In ipsec_tunnel_feature_set Instead of: arc = vnet_get_feature_arc_index ("ip4-output"); vnet_feature_enable_disable_with_index (arc, esp4_feature_index, t->sw_if_index, enable, &t->output_sa_index, sizeof (t->output_sa_index)); A callback is made to the TFS code which does: arc = vnet_get_feature_arc_index ("ip4-output"); 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)); This latter Interface Directed code is what has been removed from VPP. The packets I receive on this path were not not (and should not) be already pre-encapsulated with any outer tunnel IP header, or I'm going to have to immediately remove this encap before placing the user traffic in the the TFS payload (see above). Having the overhead of adding an IP header, then immediately removing it simply to get traffic directed to my IPTFS encap routine is not a reasonable replacement. So the "new model" in VPP is that I have to add a non-encapsulating interface to direct the user traffic to me for TFS processing (i.e., unencapsulated). This interface is going to bear a striking resemblance to the one that was just removed from 19.08 VPP. :) Thanks, Chris. > > /neale > > tpyed by my fat tumhbs >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16824): https://lists.fd.io/g/vpp-dev/message/16824 Mute This Topic: https://lists.fd.io/mt/74962223/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
