Hi Chris,
On 07/05/2020 16:55, "Christian Hopps" <cho...@chopps.org> wrote:
> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns) <nra...@cisco.com> 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: <vpp-dev@lists.fd.io> on behalf of Christian Hopps
<cho...@chopps.org>
> Date: Wednesday 6 May 2020 at 14:32
> To: vpp-dev <vpp-dev@lists.fd.io>
> Cc: Christian Hopps <cho...@chopps.org>
> Subject: [vpp-dev] IPsec tunnel interfaces?
>
> Hi, vpp-dev,
>
> Post 19.08 seems to have removed IPsec logical interfaces.
>
> One cannot always use transport mode IPsec.
>
> How can I get the efficiency of route based (FIB) IPsec w/o transport
mode? Adding superfluous encapsulations (wasting bandwidth) to replace this
(seemingly lost, hope not) functionality is not an option.
>
> Thanks,
> Chris.
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#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]
-=-=-=-=-=-=-=-=-=-=-=-
