Re: [vpp-dev] IPsec tunnel interfaces?

[Christian Hopps]

> On May 11, 2020, at 11:03 AM, Christian Hopps  wrote:
> 
>> On May 11, 2020, at 9:56 AM, Neale Ranns (nranns)  wrote:
>> 
>> On 11/05/2020 14:28, "Christian Hopps"  wrote:
> 
>> 
>>   Is it *really* that big a deal to have a logical interface represent a 
>> tunnel mode SA? It actually seems a fairly elegant to me. Instead of tossing 
>> it out, why not just clean up the objectionable API pieces? The current 
>> changes can continue to be used for the GRE tunnel case, so the current work 
>> is not lost either.
>> 
>> We seem to have come full circle... there is a logical interface, it's 
>> called ipipX. Clearly the name of the interface is not important.
>> The logical interface shouldn't represent the SA, it should represent the 
>> peering, and it's the peering that defines the encap. I say this because SAs 
>> come and go as rekeying occurs, but the peering remains. You don't want to 
>> delete your interface and recreate all your routes, each time you rekey. In 
>> fact there's a good test; if the peering addresses can 
>> regularly/reasonably/etc change during a rekey, then the ipip case is 
>> definitely worse, since one would need to create a new ipip tunnel and IMO 
>> that would justify a different interface type.
>> 
>> What would be preferable/more efficient for your feature is if the encap 
>> were applied after your feature is run, but do I really need a new interface 
>> type just for that? let me see what I can do.

Do you think a fix will available before the next LTS release?

Thanks,
Chris.

> 
> Fantastic. :)
> 
> Thanks,
> Chris.
> 
>> 
>> /neale
>> 
>> 
>>   Thanks,
>>   Chris.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] IPsec tunnel interfaces?

[Christian Hopps]

> On May 11, 2020, at 9:56 AM, Neale Ranns (nranns)  wrote:
> 
> 
> 
> On 11/05/2020 14:28, "Christian Hopps"  wrote:
> 
> 
> 
>> On May 11, 2020, at 7:50 AM, Neale Ranns (nranns)  wrote:
>> 
>> 
>> 
>> From:  on behalf of Christian Hopps 
>> Date: Sunday 10 May 2020 at 14:33
>> To: "Neale Ranns (nranns)" 
>> Cc: Christian Hopps , vpp-dev 
>> Subject: Re: [vpp-dev] IPsec tunnel interfaces?
>> 
>>> On May 9, 2020, at 7:23 AM, Neale Ranns via 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.
>> 
>> This is the condition I don’t fully understand….
>> 
>> 
>> 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
>> 
>> At this point in old code, the packet does not have the tunnel encap added, 
>> it new code it does.
> 
>Right, so this is the problem, at this point -- pre-ipsec encapsulation -- 
> in the arc I am collecting (aggregating multiple us

Re: [vpp-dev] IPsec tunnel interfaces?

[Neale Ranns via lists.fd.io]

On 11/05/2020 14:28, "Christian Hopps"  wrote:



> On May 11, 2020, at 7:50 AM, Neale Ranns (nranns)  
wrote:
> 
>  
>  
> From:  on behalf of Christian Hopps 

> Date: Sunday 10 May 2020 at 14:33
> To: "Neale Ranns (nranns)" 
> Cc: Christian Hopps , vpp-dev 
> Subject: Re: [vpp-dev] IPsec tunnel interfaces?
>  
> > On May 9, 2020, at 7:23 AM, Neale Ranns via 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.
> 
> This is the condition I don’t fully understand….
> 
> 
> 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
> 
> At this point in old code, the packet does not have the tunnel encap 
added, it new code it does.

Right, so this is the problem, at this point -- pre-ipsec encapsulation -- 
in the arc I am collecting (aggregating multiple user IP packets) into a single 
payload to send over the IPsec SA tunnel. I can't have IP-IP packets here.

It's not OK to have to strip off superfluous IP headers (thus having paid a 
price to have them added, only to be immediately removed in the next node in 
the graph) from all the user packets just so I can get back to the 
functionality I had before 20.01, that's not the same 

Re: [vpp-dev] IPsec tunnel interfaces?

[Christian Hopps]

> On May 11, 2020, at 7:50 AM, Neale Ranns (nranns)  wrote:
> 
>
>
> From:  on behalf of Christian Hopps 
> Date: Sunday 10 May 2020 at 14:33
> To: "Neale Ranns (nranns)" 
> Cc: Christian Hopps , vpp-dev 
> Subject: Re: [vpp-dev] IPsec tunnel interfaces?
>
> > On May 9, 2020, at 7:23 AM, Neale Ranns via 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.
> 
> This is the condition I don’t fully understand….
> 
> 
> 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
> 
> At this point in old code, the packet does not have the tunnel encap added, 
> it new code it does.

Right, so this is the problem, at this point -- pre-ipsec encapsulation -- in 
the arc I am collecting (aggregating multiple user IP packets) into a single 
payload to send over the IPsec SA tunnel. I can't have IP-IP packets here.

It's not OK to have to strip off superfluous IP headers (thus having paid a 
price to have them added, only to be immediately removed in the next node in 
the graph) from all the user packets just so I can get back to the 
functionality I had before 20.01, that's not the same behavior. :)

> AGGREGATING AND QUEUEING OCCURS - The packet is encapsulated (along with any 
> others currently waiting) into the next-to-be-sent IPTFS pac

Re: [vpp-dev] IPsec tunnel interfaces?

[Neale Ranns via lists.fd.io]

From:  on behalf of Christian Hopps 
Date: Sunday 10 May 2020 at 14:33
To: "Neale Ranns (nranns)" 
Cc: Christian Hopps , vpp-dev 
Subject: Re: [vpp-dev] IPsec tunnel interfaces?

> On May 9, 2020, at 7:23 AM, Neale Ranns via 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.

This is the condition I don’t fully understand….


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

At this point in old code, the packet does not have the tunnel encap added, it 
new code it does.



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

In old code here you present the next crypto node with your IPTFS ‘frame’, i.e. 
payload. In new code you need to present this frame with the tunnel encap 
prepended and correct (IIUC your draft correctly your not playing tricks with 
the outer IP header’s length, so you don’t need control over how the ESP 
header/footer is crafted – it’s the ‘normal’ way). You can either do this by 
preserving and updating the encap that was on one of the original buffers, or 
slap on a new one. You can query the tunnel’s encap similarly to the way 
ipsec_tun_protect_update() 

Re: [vpp-dev] IPsec tunnel interfaces?

[Christian Hopps]

Just a general followup in case tl;dr

The point of traffic flow security/confidentiality is to hide the effects of 
the user traffic on the secure tunnel output. With IPTFS there is a complete 
decoupling so that one cannot infer anything about the encapsulated traffic 
from the IPsec tunnel data packets (when they are sent, how big they are, etc), 
there are other (more complex) methods for obfuscation that may or may not be 
better. 

In any case, having the user data traffic directly determine the IPsec tunnel 
behavior is inherently less secure than if it doesn't, so the idea that one 
could find an equivalence between a tunnel mode SA and a transport mode SA 
doesn't work here. For some uses of IPsec it may work, but not always.

In order to make transport mode work (e.g., to support the Cisco-preferred, 
thus common, GRE+transport IPsec config) we are going to have to do more 
standards work and probably put various limitations etc on the types of user IP 
that can be input (so that we can cache and replicate that information at will) 
-- but that does not represent an equivalence.

Thanks,
Chris.

> On May 10, 2020, at 8:33 AM, Christian Hopps  wrote:
> 
>> On May 9, 2020, at 7:23 AM, Neale Ranns via 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):
> 
> 

Re: [vpp-dev] IPsec tunnel interfaces?

[Christian Hopps]

> On May 9, 2020, at 7:23 AM, Neale Ranns via 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: 0x
   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 0x501


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 = 

Re: [vpp-dev] IPsec tunnel interfaces?

[Neale Ranns via lists.fd.io]

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:  on behalf of Christian Hopps 
> >> 
> >> Date: Wednesday 6 May 2020 at 14:32
> >> To: vpp-dev 
> >> Cc: Christian Hopps 
> >> 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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] IPsec tunnel interfaces?

[Christian Hopps]

On May 8, 2020, at 3:57 AM, Neale Ranns via lists.fd.io 
 wrote:
> 
>
>
> From:  on behalf of Christian Hopps 
> Date: Thursday 7 May 2020 at 23:27
> To: "Neale Ranns (nranns)" 
> Cc: Christian Hopps , vpp-dev 
> Subject: Re: [vpp-dev] IPsec tunnel interfaces?
>
> 
> 
> > On May 7, 2020, at 1:41 PM, Neale Ranns (nranns)  wrote:
> > 
> > 
> > Hi Chris,
> > 
> > On 07/05/2020 16:55, "Christian Hopps"  wrote:
> > 
> > 
> > 
> >> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns)  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.
> 
> You still have the choice to make the ipip interface unnumbered, or you can 
> assign it a subnet. Or if it’s an L2 interface (like the old ipsec-gre was 
> and the new protected GRE interface can be) you can add it to a BD. The end 
> points of the tunnel are your choice.
> 
> 
> 
> >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. :)
> 
> if your original packet that is routed into the tunnel was:
> 
>   [ IP (user-DIP, user-SIP) | TCP | Payload ]
> 
> Then the above configuration will give you:
> 
>  [ MAC | [ IP (tun-DIP, tun-SIP ) | ESP | IP (User-DIP, User-SIP) | TCP | 
> Payload ]
> 
> If you didn’t have protection on the tunnel interface, you’d get
> 
>  [ MAC | [ IP (tun-DIP, tun-SIP ) | IP (User-DIP, User-SIP) | TCP | Payload ]
> 
> So the SA acts like transport mode, i.e. it’s inserting the ESP header 
> between the tunnel IP h

Re: [vpp-dev] IPsec tunnel interfaces?

[Neale Ranns via lists.fd.io]

From:  on behalf of Christian Hopps 
Date: Thursday 7 May 2020 at 23:27
To: "Neale Ranns (nranns)" 
Cc: Christian Hopps , vpp-dev 
Subject: Re: [vpp-dev] IPsec tunnel interfaces?



> On May 7, 2020, at 1:41 PM, Neale Ranns (nranns)  wrote:
>
>
> Hi Chris,
>
> On 07/05/2020 16:55, "Christian Hopps"  wrote:
>
>
>
>> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns)  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.
You still have the choice to make the ipip interface unnumbered, or you can 
assign it a subnet. Or if it’s an L2 interface (like the old ipsec-gre was and 
the new protected GRE interface can be) you can add it to a BD. The end points 
of the tunnel are your choice.


>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. :)
if your original packet that is routed into the tunnel was:
  [ IP (user-DIP, user-SIP) | TCP | Payload ]
Then the above configuration will give you:
 [ MAC | [ IP (tun-DIP, tun-SIP ) | ESP | IP (User-DIP, User-SIP) | TCP | 
Payload ]
If you didn’t have protection on the tunnel interface, you’d get
 [ MAC | [ IP (tun-DIP, tun-SIP ) | IP (User-DIP, User-SIP) | TCP | Payload ]
So the SA acts like transport mode, i.e. it’s inserting the ESP header between 
the tunnel IP headers and the payload. This is what other uses are using as a 
replacement for the old config.
If your SA was in tunnel mode, then you’d get:
  [ MAC | [ IP (tun-DIP, tun-SIP ) | IP (SA-DIP, SA-SIP) | ESP | IP (User-DIP, 
User-SIP) | TCP | Payload ]
Which I think is the 3 headers you don’t want.
Are there other properties of a tunnel mode SA that you need that are lost with 
this approach?
/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

Re: [vpp-dev] IPsec tunnel interfaces?

[Christian Hopps]

> On May 7, 2020, at 1:41 PM, Neale Ranns (nranns)  wrote:
> 
> 
> Hi Chris,
> 
> On 07/05/2020 16:55, "Christian Hopps"  wrote:
> 
> 
> 
>> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns)  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:  on behalf of Christian Hopps 
>> Date: Wednesday 6 May 2020 at 14:32
>> To: vpp-dev 
>> Cc: Christian Hopps 
>> 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]

Re: [vpp-dev] IPsec tunnel interfaces?

[Neale Ranns via lists.fd.io]

Hi Chris,

On 07/05/2020 16:55, "Christian Hopps"  wrote:



> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns)  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.

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. 

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?

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:  on behalf of Christian Hopps 

> Date: Wednesday 6 May 2020 at 14:32
> To: vpp-dev 
> Cc: Christian Hopps 
> 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 (#16275): https://lists.fd.io/g/vpp-dev/message/16275
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] IPsec tunnel interfaces?

[Christian Hopps]

> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns)  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.

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?

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?

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.

Could we bring back the functionality using more "acceptable to the project" 
APIs or something?

Thanks,
Chris.

>
> /neale
>
>
> From:  on behalf of Christian Hopps 
> Date: Wednesday 6 May 2020 at 14:32
> To: vpp-dev 
> Cc: Christian Hopps 
> 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 (#16272): https://lists.fd.io/g/vpp-dev/message/16272
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] IPsec tunnel interfaces?

[Damjan Marion via lists.fd.io]

Is there a way to keep ipsecX naming, use of ipipX for ipsec tunnels seems to 
be confusing for many people...


> On 7 May 2020, at 14:15, Neale Ranns via lists.fd.io 
>  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.
>
> /neale
>
>
> From: mailto:vpp-dev@lists.fd.io>> on behalf of 
> Christian Hopps mailto:cho...@chopps.org>>
> Date: Wednesday 6 May 2020 at 14:32
> To: vpp-dev mailto:vpp-dev@lists.fd.io>>
> Cc: Christian Hopps mailto: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 (#16266): https://lists.fd.io/g/vpp-dev/message/16266
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] IPsec tunnel interfaces?

[Neale Ranns via lists.fd.io]

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.

/neale


From:  on behalf of Christian Hopps 
Date: Wednesday 6 May 2020 at 14:32
To: vpp-dev 
Cc: Christian Hopps 
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 (#16265): https://lists.fd.io/g/vpp-dev/message/16265
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]
-=-=-=-=-=-=-=-=-=-=-=-