Revision as of 07:53, 15 May 2019

IPSec

Basics

Two flavours of IPSec are available: Tunnel and Policy mode.

Tunnel Mode

An IP-in-IP or GRE tunnel is 'protected' by a pair of Security Associations (SA) - one for inbound/local traffic and one for outbound/remote. All ESP packets whose SPI matches that of the inbound SA are 'classified' to have arrived on the tunnel. All packets that egress the tunnel are ESP protected using the outbound SA.

Current Model

The current model for creating such a protected tunnel is a dedicated interface type; either ipsec or ipsec-gre. These are created e.g.;

 create ipsec tunnel local-ip 10.0.0.1 remote-ip 10.0.0.2 local-spi 100 remote-spi 101 local-crypto-key A11E51E5B1E0 remote-crypto-key A11E51E5B1E0 crypto-alg aes-gcm-128

this command will create: one tunnel ipsecX and two associated SAs. There exists a dump API for the tunnels. There are several drawbacks to this approach:

• 1) for the API user to know the ID/index of the created SAs (in order to read stats) it must use the dump API s to determine which SAs are associated with the tunnel
• 2) VPP has two interface types, ipsec and -ipsec-gre, that act exactly like a IP-in-IP and GRE tunnel respectively that have ESP as an output feature
• 3) the API above is a concatenation of the 'create ipip tunnel ...' and 'ipsec sa add ...' APIs and needs to track changes in both.
• 4) the use has no control over whether the ESP mode is tunnel mode or transport mode.
• 5) It's not possible to associate more than one inbound SA for the tunnel. This prevents a make-before-break rekey.

Proposed Model

A separation of the creation of the interface, SAs and the protection that they provide:

 create ipip tunnel src 10.0.0.1 dst 10.0.0.2
 ipsec sa add id 1 spi 1001 crypto-key A11E51E5B111 crypto-alg aes-gcm-128
 ipsec sa add id 2 spi 1002 crypto-key A11E51E5B222 crypto-alg aes-gcm-128
 ipsec tunnel protect ipip0 sa-in [1, ...] sa-out 2

this approach solves all the above drawbacks:

• 1) the user is directly responsible fro constructing the SAs so knows their identity.
• 2) we reuse the existing IP-in-IP (or GRE) tunnel
• 3) re-use of the separate APIs for the creation of the tunnel and SAs
• 4) the mode of the SA controls the mode of the ESP encapsulation.
• 5) multiple inbound SAs can be associated with the tunnel protection.

the drawback, from the usr's perspective, is that what used to take 1 API call now takes 4.

For VPP code this introduces a new data-type, an ipsec-tun-protection, which acts as the 'binding' between the tunnel and its associated SAs.

To rekey the tunnel, the user creates new SAs and the can complete the make-before-break rekeying in 3 phases:

• 1) add the new inbound SA

 ipsec tun protect ipip0 sa-in [old, new] sa-out old

• 2) after some time (when it is considered the peer has updated to the new inbound SA) we switch to using the new outbound SA.

 ipsec tun protect ipip0 sa-in [old, new] sa-out new

• 3) after some more time or when the SA stats say traffic has arrived on the new inbound SA, we can safely remove the old inbound SA

 ipsec tun protect ipip0 sa-in [new] sa-out new

Policy Mode

Policy mode follows the use of IPSec as described in RFC4031.

First and SPD is created:

 ipsec spd add AA

SAs are created to protected traffic:

 ipsec sa add id 2 spi X ...

that match given policies:

 ipsec policy add spd AA action .. sa 2 [inbound|outbound] [match criteria]

then the SPD is applied to an interface:

 set interface ipsec spd eth0 AA

traffic that ingresses and egresses eth0 is subject to the inbound and outbound policies respectively of the SPD

IPSec Implementations

There are many implementations for IPSec that are open sourced, principally there is the suite of implementations (both SW and HW) that are provided by the DPDK crypto-devices and openSSL. As of 19.04 VPP also has its own IPSec implementation that makes use of Intel's vector cyptographic instructions.

There are two, slightly overlapping, mechanisms to choose an implementation; backends and engines. Engines were introduced in 19.04 and is the preferred mechanism we are migrating away from backends as time and resource permits.

Engines and/or backends apply to both modes of IPSec as described above.

Engines

There are three engines to choose from:

* native - VPP implemention using Intel vector instructions
* Intel's IPSec-multi-buffer library.
* openSSL

The engines are all plugins. Each engine registers at a given priority and indicates its capability to support a particular cryptographic algorithm. Not all engines support all algorithms. The engines are listed above in priority order.

Backends

As of 19.04 there are only two backends; native (i.e. use engined - the default) and DPDK (provided by the dpdk plugin).