FD.io VPP  v21.10.1-2-g0a485f517
Vector Packet Processing
Data Fields
ipsec_itf_t_ Struct Reference

A dedicated IPSec interface type. More...

Data Fields

tunnel_mode_t ii_mode
 
int ii_user_instance
 
u32 ii_sw_if_index
 

Detailed Description

A dedicated IPSec interface type.

In order to support route based VPNs one needs 3 elements: an interface, for routing to resolve routes through, an SA from the peer to describe security, and encap, to describe how to reach the peer. There are two ways one could model this:

interface + encap + SA = (interface + encap) + SA = ipip-interface + SA transport mode

or

interface + encap + SA = interface + (encap + SA) = IPSec-interface + SA tunnel mode

It's a question of where you add the parenthesis, from the perspective of the external user the effect is identical.

The IPsec interface serves as the encap-free interface to be used in conjunction with an encap-describing tunnel mode SA.

VPP supports both models, which modelshould you pick? A route based VPN could impose 0, 1 or 2 encaps. the support matrix for these use cases is: 

   |  0  |  1  |  2  |

ipip | N | Y | Y | ipsec | P | Y | P |

Where P = potentially. ipsec could potnetially support 0 encap (i.e. transport mode) since neither the interface nor the SA requires encap. However, for a route beased VPN to use transport mode is probably wrong since one shouldn't use thransport mode for transit traffic, since without encap it is not guaranteed to return. ipsec could potnetially support 2 encaps, but that would require the SA to describe both, something it does not do at this time.

ipsec currently does not support:

  • multipoint interfaces but this is only because it is not yet implemented, rather than it cannot be done.

Internally the difference is that the midchain adjacency for the IPSec interface has no associated encap (whereas for an ipip tunnel it describes the peer). Consequently, features on the output arc see packets without any encap. Since the protecting SAs are in tunnel mode, they apply the encap. The midchain adj is stacked only once the proctecting SA is known, since only then is the peer known. Otherwise the VLIB graph nodes used are the same: (routing) --> ipX-michain --> espX-encrypt --> adj-midchain-tx --> (routing) where X = 4 or 6.

Some benefits to the ipsec interface:

  • it is slightly more efficient since the encapsulating IP header has its checksum updated only once.
  • even when the interface is admin up traffic cannot be sent to a peer unless the SA is available (since it's the SA that determines the encap). With ipip interfaces a client must use the admin state to prevent sending until the SA is available.

The best recommendations i can make are:

  • pick a model that supports your use case
  • make sure any other features you wish to use are supported by the model
  • choose the model that best fits your control plane's model.

gun reloaded, fire away.

Definition at line 94 of file ipsec_itf.h.

Field Documentation

◆ ii_mode

tunnel_mode_t ipsec_itf_t_::ii_mode

Definition at line 96 of file ipsec_itf.h.

◆ ii_sw_if_index

u32 ipsec_itf_t_::ii_sw_if_index

Definition at line 98 of file ipsec_itf.h.

◆ ii_user_instance

int ipsec_itf_t_::ii_user_instance

Definition at line 97 of file ipsec_itf.h.

The documentation for this struct was generated from the following file: