Difference between revisions of "VPP/IPSec"
(→Current Model) |
(→Current Model) |
||
| Line 33: | Line 33: | ||
There are several drawbacks to this approach: | 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 | + | *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. The SAs have an automatically generated SA-ID. |
*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 | *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. | *3) the API above is a concatenation of the 'create ipip tunnel ...' and 'ipsec sa add ...' APIs and needs to track changes in both. | ||
Revision as of 15:25, 20 May 2019
Contents
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.
DBGvpp# sh int
Name Idx State MTU (L3/IP4/IP6/MPLS) Counter Count
ipsec0 6 up 9000/0/0/0
DBGvpp# sh ipsec sa [0] sa 0x80000000 spi 101 mode tunnel protocol esp tunnel [1] sa 0xc0000000 spi 100 mode tunnel protocol esp tunnel
DBGvpp# sh ipsec tun
Tunnel interfaces
ipsec0
out-bound sa: [1] sa 0xc0000000 spi 100 mode tunnel protocol esp tunnel
in-bound sa: [0] sa 0x80000000 spi 101 mode tunnel protocol esp tunnel
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. The SAs have an automatically generated SA-ID.
- 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.
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.
Backends
As of 19.04 there are only two backends; native (i.e. use engined - the default) and DPDK (provided by the dpdk plugin). Backends must provide their own ESP and/or AH VPP nodes to perform the packet encrypt and decrypt -in other words a backend must provide the full packet switch path. This is a real barrier to the use of some new crypto library and a significant effort for the community to support.
DBGvpp# sh ipsec backends
IPsec AH backends available:
Name Index Active
crypto engine backend 0 yes
IPsec ESP backends available:
Name Index Active
crypto engine backend 0 yes
dpdk backend 1 no
Engines
The default IPSEc backend makes use of 'engines' that provide a byte stream based encrypt/decrypt service. The API between VPP and the engine is represented as an 'operation'. Each operation specifies, e.g., the algorithm[s] and keys and the address of the data to encrypt and the location to place any output.
There are three engines to choose from:
DBGvpp# sh crypto engines Name Prio Description ia32 100 Intel IA32 ISA Optimized Crypto ipsecmb 80 Intel(R) Multi-Buffer Crypto for IPsec Library 0.52.0 openssl 50 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.
DBGvpp# sh crypto handlers
Algo Type Active Candidates
des-cbc encrypt openssl openssl
decrypt openssl openssl
3des-cbc encrypt openssl openssl
decrypt openssl openssl
aes-128-cbc encrypt ia32 ia32 ipsecmb openssl
decrypt ia32 ia32 ipsecmb openssl
aes-192-cbc encrypt ia32 ia32 ipsecmb openssl
decrypt ia32 ia32 ipsecmb openssl
aes-256-cbc encrypt ia32 ia32 ipsecmb openssl
decrypt ia32 ia32 ipsecmb openssl
aes-128-ctr encrypt openssl openssl
decrypt openssl openssl
aes-192-ctr encrypt openssl openssl
decrypt openssl openssl
aes-256-ctr encrypt openssl openssl
decrypt openssl openssl
aes-128-gcm aead-encrypt ipsecmb ipsecmb openssl
aead-decrypt ipsecmb ipsecmb openssl
aes-192-gcm aead-encrypt ipsecmb ipsecmb openssl
aead-decrypt ipsecmb ipsecmb openssl
aes-256-gcm aead-encrypt ipsecmb ipsecmb openssl
aead-decrypt ipsecmb ipsecmb openssl
hmac-md5 hmac openssl openssl
hmac-sha-1 hmac ipsecmb ipsecmb openssl
hmac-sha-224 hmac ipsecmb ipsecmb openssl
hmac-sha-256 hmac ipsecmb ipsecmb openssl
hmac-sha-384 hmac ipsecmb ipsecmb openssl
hmac-sha-512 hmac ipsecmb ipsecmb openssl
