Latest revision as of 07:41, 2 May 2023

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.

Deprecated Model

The current (deprecated) 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 user has no control over whether the ESP mode is tunnel mode or transport mode.

Protection 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 20 spi 200 crypto-key 6541686776336961656264656f6f6579 crypto-alg aes-gcm-128
 ipsec sa add 30 spi 300 crypto-key 6541686776336961656264656f6f6579 crypto-alg aes-gcm-128
 ipsec tunnel protect ipip0 sa-in 20 sa-out 30

This results in:

DBGvpp# sh int
              Name               Idx    State  MTU (L3/IP4/IP6/MPLS)     Counter          Count     
ipip0                             6      up          9000/0/0/0     

DBGvpp# sh ipsec sa
[0] sa 0x14 spi 200 mode transport protocol esp 
[1] sa 0x1e spi 300 mode transport protocol esp 

DBGvpp# sh ipsec protect    
ipip0
 output-sa:
  [1] sa 0x1e spi 300 mode transport protocol esp 
 input-sa:
  [0] sa 0x14 spi 200 mode transport protocol esp 

Note that the SAs are in transport mode. For tunnels the ESP acts on the post-encapsulated packet. So if this packet:

     +---------+------+
     | Payload | O-IP |
     +---------+------+

where O-IP is the overlay IP addrees that was routed into the tunnel, the resulting encapsulated packet will be:

     +---------+------+------+
     | Payload | O-IP | T-IP |
     +---------+------+------+

where T-IP is the tunnel's src.dst IP addresses. If the SAs used for protection are in transport mode then the ESP is inserted before T-IP, i.e.:

     +---------+------+-----+------+
     | Payload | O-IP | ESP | T-IP |
     +---------+------+-----+------+

If the SAs used for protection are in tunnel mode then another encapsulation occurs, i.e.:

     +---------+------+------+-----+------+
     | Payload | O-IP | T-IP | ESP | C-IP |
     +---------+------+------+-----+------+

where C-IP are the crypto endpoint IP addresses defined as the tunnel endpoints in the SA. The mode for the inbound and outbound SA must be the same.

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.

The drawback, from the user'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.

Rekeying a tunnel is achevied by updating the tunnel protection to provide the new set of protecting SAs. It is also possible to rekey a tunnel in 3 phases to achieve a make-before break:T

• 1) the inbould set of SAs includes both the old and 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

Multi-point Tunnels

IPSec is also supported on multi-point tunnels (currently for IP-in-IP and GRE).

In P2P mode the protecting SAs apply to all the traffic egressing/ingressing the tunnel - one can also think of this as the SA protects all traffic going to/from the only peer on the link. Likewise, since there's only one peer, there's also only one 'destination' for the tunnel - hence a tunnel can be considered as having a source and destination. When we switch to multi-point interfaces, then there is more than one peer on the link and hence more than one tunnel 'destination'. So we create a multi-point tunnel with its own subnet:

 create ipip tunnel src 10.0.0.1 p2mp
 set int ip addr ipip0 192.168.0.1/24

there are thus up to 256 peers on this link. this is the 'overlay'. But how is each of the peers reachable - i.e. what is there 'destination' in the underlay. This mapping between the overlay and underlay address is populated in the Tunnel Endpoint Information Base (TEIB). Control plane protocols like Next-Hop Resolution Protocol (NHRP) can provide these sorts of mappings. To programme an entry in the TEIB:

 create teib ipip0 peer 192.168.0.2 nh 10.1.1.1

What's the point of multipoint interfaces? Why not just create multiple p2p interfaces to each peer, each with a different subnet? Scale! interfaces are not cheap. Otherwise both solutions provide the same functionality.

The consequences for IPSec when we switch to multi-point interfaces, are that the SAs protect a specific peer on the link. So we create SAs as usual, then when adding tunnel protection, we must specify which peer on the link the SA applies to:

 create ipip tunnel src 10.0.0.1 p2mp
 set int ip addr ipip0 192.168.0.1/24
 ipsec sa add 20 spi 200 crypto-key A11E51E5B111 crypto-alg aes-gcm-128
 ipsec sa add 30 spi 300 crypto-key A11E51E5B222 crypto-alg aes-gcm-128
 ipsec tunnel protect ipip0 sa-in 20 sa-out 30 nh 192.168.0.2

and that's all there is to it.

Policy Mode

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

First an SPD is created:

 ipsec spd add 1

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