Re: [vpp-dev] ipsec interface revisted.
Hi Neale,
Thanks very much for this!
I will try and get this tested ASAP (it will require a bit of work to port to
master to test).
> For rx have you added a ip-protocol dispatch in the decypt? If so we can
> upstream that change in this patch if you like.
That is a very interesting idea, and is aligned with our current push in the
IETF to get the IPTFS next header value allocated from the IP protocols IANA
registry. :)
Alas, for now I have a custom patch in the v4, v6, check in esp decrypt (vnet
and dpdk) looking for IPTFS protocol.
For the most part I used a set of callbacks named "tfs" I added to ipsec to
hook in. In this particular case though it's hard-coded for now.
Thanks,
Chris.
> On Jul 6, 2020, at 4:57 AM, Neale Ranns via lists.fd.io
> wrote:
>
>
>
> From: Christian Hopps
> Date: Friday 26 June 2020 at 12:13
> To: "Neale Ranns (nranns)"
> Cc: Christian Hopps , vpp-dev
> Subject: Re: [vpp-dev] ipsec interface revisted.
>
>
>
>
>> On Jun 26, 2020, at 4:22 AM, Neale Ranns (nranns) 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;
>
> Interfac
Re: [vpp-dev] ipsec interface revisted.
From: Christian Hopps
Date: Friday 26 June 2020 at 12:13
To: "Neale Ranns (nranns)"
Cc: Christian Hopps , vpp-dev
Subject: Re: [vpp-dev] ipsec interface revisted.
On Jun 26, 2020, at 4:22 AM, Neale Ranns (nranns)
mailto: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.
Reasonable or otherwise, that’s what the model would expect. All output
features get packets with encap already applied, since the output fe
Re: [vpp-dev] ipsec interface revisted.
> On Jun 26, 2020, at 4:22 AM, Neale Ranns (nranns) 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. :)
Th
Re: [vpp-dev] ipsec interface revisted.
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. /neale tpyed by my fat tumhbs -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16820): https://lists.fd.io/g/vpp-dev/message/16820 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] ipsec interface revisted.
Hi Neale, It's maybe worth pointing this out: using policy based IPsec continues to work fine for me. What I had and lost is route based IPsec, i.e., a destination interface that directs traffic to an SA *without trying to "partially-implement" the tunnel mode SA functionality*. The new code is making the assumption that a tunnel mode SA's encap function can be 1-1 replaced by an upstream IPIP encapsulating function. This assumption is what is breaking me b/c my ESP payload is not a simple single IP packet. Each of my ESP payloads is an aggregate of IP packets sometimes padded sometimes fractional. These payloads are emitted on a fixed timed interval (which determines if there is padding or not) and encapsulated only upon being emitted. *Specifically* this cannot be driven by the users (inner) traffic or we've failed -- all of this is the function the IPTFS SA implements. All of this is coded and working for policy directed tunnel mode SAs. Having to somehow replicate this functionality in two places (one place for policy based, and then in some new tightly coupled encapsulating custom interface type) to support the vpp post 19.08 optimization couldn't be seen as being "cleaner" by any subjective measure I hope. So, in order to make things work post 19.08 I'm going to have to (re-)introduce a new "iptfs" interface type to VPP, so that I can have traffic directed to my SA w/o any encapsulation being done beforehand. If the goal was to avoid requiring per-use case interface types I don't think it worked for me. Basically I'm going to have to put back what was removed, maybe with a few refinements since I'm there already. Will that be acceptable when I eventually try and upstream the code? There's also the distinct possibility that we can't get this extra work funded in which case it would then only be available externally based on 19.08 which would be a shame as this work is based on the what is being done in ipsecme WG of the IETF. I would guess this would be seen as a poor outcome by others too. FWIW the GRE use-case was, and remains, a transport mode use of IPsec, so no extra assumptions are being made for that use case. The new code probably is an improvement for GRE with transport mode IPsec, but for the purpose of discussing IPsec tunnel mode functionality it's a bit distracting. Thanks, Chris. > On Jun 23, 2020, at 8:51 AM, Neale Ranns (nranns) wrote: > > > Hi Chris, > > On 22/06/2020 13:09, "Christian Hopps" wrote: > >> >> - It operates directly with the IPsec tunnel mode and transport mode SAs >> without needing to mangle the internal definition of SA tunnel into >> transport mode. > >Do you have any comments on this point? This is what I was talking about > when I said a "cleaner abstraction". > > 'cleaner' is a subjective term and subjective analysis is subject to bias; my > biases are clear. That's why I tried to frame this discussion with an > objective comparison of use case. First in what we can't do with ipip/gre > then in what we 'can't' do with xfrms. More later.. > >> - CRITICAL: Its use does not impose any encapsulation on the traffic itself. >> >> Critical implies that without this some use cases are impossible. What is it >> that cannot be done with the tunnel model? > >- You can't tunnel non-singular IP traffic with IPIP (my use case requires > this) IOW "ipip-only" model assumes the ESP payload is a single IP packet > that will be wrapped with an outer IP packet. > > More on this below... > >- You can't do route based transport mode IPsec using ipip (my use case > doesn't require this). > > That's true, but is that a use case? Route based VPNs apply to transit > traffic, as well as locally generated, and one shouldn't send transit traffic > using a transport mode SA, i.e. without encap that ensures it returns. > >Both of these speak to the "more powerful abstraction" point. > >- The xfrm interface allows for route-based selection, but also allows for > additional policy restrictions. This might be possible with IPIP model, but > again it doesn't seem as clean/obvious. > > VPP supports policy based VPNs using an SPD attached to an interface. Any > interface type could be used. > >There's a reason that linux went with this approach as their improvement > on the VTI interface, rather than just re-using IPIP tunnel after > re-interpreting tunnel mode SAs into transport mode SAs like the new VPP code > does. The latter makes assumptions about the IPsec tunnel mode payload and > generally feels like a restricted "works for me/good enough" solution, rather > than a clean abstraction one can build new use cases on (as I am trying to > do). > > I'm sure that had compelling reasons, but do they translate to VPP? Were they > for architectural reasons that don't apply. For example, was the choice of a > new interface type required to support HW offload? I'll try and find more > info. Perhaps yo
Re: [vpp-dev] ipsec interface revisted.
Hi Chris, On 22/06/2020 13:09, "Christian Hopps" wrote: > > - It operates directly with the IPsec tunnel mode and transport mode SAs without needing to mangle the internal definition of SA tunnel into transport mode. Do you have any comments on this point? This is what I was talking about when I said a "cleaner abstraction". 'cleaner' is a subjective term and subjective analysis is subject to bias; my biases are clear. That's why I tried to frame this discussion with an objective comparison of use case. First in what we can't do with ipip/gre then in what we 'can't' do with xfrms. More later.. > - CRITICAL: Its use does not impose any encapsulation on the traffic itself. > > Critical implies that without this some use cases are impossible. What is it that cannot be done with the tunnel model? - You can't tunnel non-singular IP traffic with IPIP (my use case requires this) IOW "ipip-only" model assumes the ESP payload is a single IP packet that will be wrapped with an outer IP packet. More on this below... - You can't do route based transport mode IPsec using ipip (my use case doesn't require this). That's true, but is that a use case? Route based VPNs apply to transit traffic, as well as locally generated, and one shouldn't send transit traffic using a transport mode SA, i.e. without encap that ensures it returns. Both of these speak to the "more powerful abstraction" point. - The xfrm interface allows for route-based selection, but also allows for additional policy restrictions. This might be possible with IPIP model, but again it doesn't seem as clean/obvious. VPP supports policy based VPNs using an SPD attached to an interface. Any interface type could be used. There's a reason that linux went with this approach as their improvement on the VTI interface, rather than just re-using IPIP tunnel after re-interpreting tunnel mode SAs into transport mode SAs like the new VPP code does. The latter makes assumptions about the IPsec tunnel mode payload and generally feels like a restricted "works for me/good enough" solution, rather than a clean abstraction one can build new use cases on (as I am trying to do). I'm sure that had compelling reasons, but do they translate to VPP? Were they for architectural reasons that don't apply. For example, was the choice of a new interface type required to support HW offload? I'll try and find more info. Perhaps you have good source you can share. In my case I want to insert myself into a place in the graph that appears to no longer exist. IPTFS is a tunnel that carriers multiple or fractional inner IP packets per outer IP packet -- this simply does not map to an IPIP interface, where it would easily map to an XFRM style interface. So it definitely is a loss of functionality. ... I don't follow your reasoning. Your feature runs in the ip4-output path of an interface. It will therefore, per-buffer, get; 1) an ip4 packet, because that's what the 'contract' of the ip4-output feature guarantees. 2) they will all be destined to the [single] peer that is reachable through the interface, because that's what routing has decided is the fate of these packets. Of course you are free to over-ride the routing decision if you wish, but at the end of the feature arc the tunnel's adjacency will ship the packet out the phy thru which the peer is reachable. Now this applies regardless of the interface type. For example, if, and I'm not suggesting you do this, but if, you were to protect the tunnel with a tunnel mode SA, and in your feature vnet_buffer_advance'd away the first 20 bytes of buffer data, then, what you receive, would be functionally equivalent to the xfrm model, and what you transmit also the same; a packet to the peer. The difference being that in the ipip/gre model your feature is expected to produce a packet for the next node with those 20 bytes on the front. But in either case the next feature on the arc is expecting an ipv4 packet, because it expects the same guarantees your feature benefitted from. Which leads me to think that you are not using the existing esp4-encrypt node unmodified? In your current implementation, how do you communicate the change in packet type to the next node? You say 'IPTFS is a tunnel', perhaps this is where our view point differs. I have a strong routing bias, and we're talking route based VPNs here __ the tunnel is used for routing, it is through the tunnel that the routes are advertised, and so the FIB chooses these tunnels to [load-balance] the traffic to. The fact that they are secured, or have IPTFS, or ACLs, or NAT or whatever else enabled on them is value add. The tunnel exists for routing, it is not created by one those features. Additionally I'm worried there may be even newer changes being made in VPP that are making further assumptions (restrictions) based on the new "ipip-only" model (something to do with
Re: [vpp-dev] ipsec interface revisted.
> On Jun 22, 2020, at 4:11 AM, Neale Ranns via lists.fd.io > wrote: > > > > From: on behalf of Christian Hopps > Date: Thursday 18 June 2020 at 18:20 > To: vpp-dev > Cc: Christian Hopps > Subject: [vpp-dev] ipsec interface revisted. > > Hi, > > So to revisit this topic from a different angle. I believe VPP needs > something like the xfrm linux interface [1]. If I understand things correctly > this actually provides what was useful (but more-so) with old ipsec interface > functionality that has been lost. It is also a much cleaner/more powerful > abstraction than the current "ipip tunnel with transport mode SA" trick that > replaced the old ipsec interface functionality. > > As you say, replaced by ipip/gre tunnel interface, which shows the > functionality has not been lost. Route based VPNs are still supported. > > > The idea is to have an interface that one can use as a result of a FIB > lookup. SAs can be attached to this interface. The replacement for the old > ipsec interface functionality that was removed after 19.08, is that you > attach a simple *tunnel mode* SA with "accept all" policy to the xfrm > interface. You can also attach more complex policies if you care to, but the > common and highly efficient case will be "accept all". > > The win here is that: > > - FIB Fast: You get an interface that can be the result of the forwarding > lookup > . highly efficient especially with common zero cost match all policy > . compare to adding complex ip policy directly to all your ingress > interfaces (expensive). > - You have one interface for both IPv4 and IPv6 > > All of which are available with the ipip/gre tunnel model. Yes. > > - It operates directly with the IPsec tunnel mode and transport mode SAs > without needing to mangle the internal definition of SA tunnel into transport > mode. Do you have any comments on this point? This is what I was talking about when I said a "cleaner abstraction". > - CRITICAL: Its use does not impose any encapsulation on the traffic itself. > > Critical implies that without this some use cases are impossible. What is it > that cannot be done with the tunnel model? - You can't tunnel non-singular IP traffic with IPIP (my use case requires this) IOW "ipip-only" model assumes the ESP payload is a single IP packet that will be wrapped with an outer IP packet. - You can't do route based transport mode IPsec using ipip (my use case doesn't require this). Both of these speak to the "more powerful abstraction" point. - The xfrm interface allows for route-based selection, but also allows for additional policy restrictions. This might be possible with IPIP model, but again it doesn't seem as clean/obvious. There's a reason that linux went with this approach as their improvement on the VTI interface, rather than just re-using IPIP tunnel after re-interpreting tunnel mode SAs into transport mode SAs like the new VPP code does. The latter makes assumptions about the IPsec tunnel mode payload and generally feels like a restricted "works for me/good enough" solution, rather than a clean abstraction one can build new use cases on (as I am trying to do). In my case I want to insert myself into a place in the graph that appears to no longer exist. IPTFS is a tunnel that carriers multiple or fractional inner IP packets per outer IP packet -- this simply does not map to an IPIP interface, where it would easily map to an XFRM style interface. So it definitely is a loss of functionality. Additionally I'm worried there may be even newer changes being made in VPP that are making further assumptions (restrictions) based on the new "ipip-only" model (something to do with rewrites/adjacencies maybe? -- my understanding here is minimal). It's been hard to justify, time-wise, tracking changes in code that seems engineered to not work for me. :) Thanks, Chris. > > /neale > > > Thoughts? > > Thanks, > Chris. > > [1] - > https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#XFRM-Interfaces-on-Linux > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16780): https://lists.fd.io/g/vpp-dev/message/16780 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] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] ipsec interface revisted.
From: on behalf of Christian Hopps Date: Thursday 18 June 2020 at 18:20 To: vpp-dev Cc: Christian Hopps Subject: [vpp-dev] ipsec interface revisted. Hi, So to revisit this topic from a different angle. I believe VPP needs something like the xfrm linux interface [1]. If I understand things correctly this actually provides what was useful (but more-so) with old ipsec interface functionality that has been lost. It is also a much cleaner/more powerful abstraction than the current "ipip tunnel with transport mode SA" trick that replaced the old ipsec interface functionality. As you say, replaced by ipip/gre tunnel interface, which shows the functionality has not been lost. Route based VPNs are still supported. The idea is to have an interface that one can use as a result of a FIB lookup. SAs can be attached to this interface. The replacement for the old ipsec interface functionality that was removed after 19.08, is that you attach a simple *tunnel mode* SA with "accept all" policy to the xfrm interface. You can also attach more complex policies if you care to, but the common and highly efficient case will be "accept all". The win here is that: - FIB Fast: You get an interface that can be the result of the forwarding lookup . highly efficient especially with common zero cost match all policy . compare to adding complex ip policy directly to all your ingress interfaces (expensive). - You have one interface for both IPv4 and IPv6 All of which are available with the ipip/gre tunnel model. - It operates directly with the IPsec tunnel mode and transport mode SAs without needing to mangle the internal definition of SA tunnel into transport mode. - CRITICAL: Its use does not impose any encapsulation on the traffic itself. Critical implies that without this some use cases are impossible. What is it that cannot be done with the tunnel model? /neale Thoughts? Thanks, Chris. [1] - https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#XFRM-Interfaces-on-Linux -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16778): https://lists.fd.io/g/vpp-dev/message/16778 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] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] ipsec interface revisted.
Hi, So to revisit this topic from a different angle. I believe VPP needs something like the xfrm linux interface [1]. If I understand things correctly this actually provides what was useful (but more-so) with old ipsec interface functionality that has been lost. It is also a much cleaner/more powerful abstraction than the current "ipip tunnel with transport mode SA" trick that replaced the old ipsec interface functionality. The idea is to have an interface that one can use as a result of a FIB lookup. SAs can be attached to this interface. The replacement for the old ipsec interface functionality that was removed after 19.08, is that you attach a simple *tunnel mode* SA with "accept all" policy to the xfrm interface. You can also attach more complex policies if you care to, but the common and highly efficient case will be "accept all". The win here is that: - FIB Fast: You get an interface that can be the result of the forwarding lookup . highly efficient especially with common zero cost match all policy . compare to adding complex ip policy directly to all your ingress interfaces (expensive). - You have one interface for both IPv4 and IPv6 - It operates directly with the IPsec tunnel mode and transport mode SAs without needing to mangle the internal definition of SA tunnel into transport mode. - CRITICAL: Its use does not impose any encapsulation on the traffic itself. Thoughts? Thanks, Chris. [1] - https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#XFRM-Interfaces-on-Linux-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16754): https://lists.fd.io/g/vpp-dev/message/16754 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] -=-=-=-=-=-=-=-=-=-=-=-
