src/vnet/ipsec/ipsec.rst

   1 .. _ipsec:
   2
   3 .. toctree::
   4
   5 IPSec (IP Security)
   6 ===================
   7
   8 This is not a description on how IPSec works. Please read:
   9
  10   - https://tools.ietf.org/html/rfc4301
  11   - https://tools.ietf.org/html/rfc4302
  12   - https://tools.ietf.org/html/rfc4303
  13
  14
  15 I would also suggest this:
  16
  17   - https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN
  18
  19
  20 If you're interested in cryptography, I would recommend this excellent
  21 introductory lecture series (there is also a book, but you'll have to
  22 buy it, IMHO it's worth it):
  23
  24   - https://www.youtube.com/channel/UC1usFRN4LCMcfIV7UjHNuQg/featured
  25
  26
  27 IPSec VPNs come in two flavours; policy and route based, the
  28 difference is how the Security Association (SA) is chosen.
  29
  30
  31 Route Base VPNs
  32 ---------------
  33
  34 There are two aspects of a route based VPN; all packets to a
  35 particular peer are encrypted by the same SA and routing
  36 decides the peer to which to forward traffic (as routing always
  37 does). Therefore, routing is choosing the SA. Of course the same must
  38 be true in reverse, that all packets from a given peer are decrypted
  39 with the same SA. Another way of expressing this is to say a peer is
  40 'protected' by this SA (really a pair of SAs; one for rx and tx).
  41
  42 The 'standard' [#i1]_ way of representing this protected peer is by
  43 using a point-to-point virtual interface to which the peer is
  44 attached and the SA pair is associated. Prefixes
  45 that require protection are routed through this virtual interface and
  46 hence implicitly to the peer.
  47
  48 There are three components to the model:
  49
  50 - The SAs; An **ipsec_sa_t**, use the force, read the source.
  51 - The virtual interface
  52 - The protection - the association of the SAs to the interface.
  53
  54
  55 The protection is represented by a **ipsec_tun_protect_t**. The "tun"
  56 part comes from the fact that the protected interface is usually a
  57 tunnel. IMO It would have been better if the author had not assumed
  58 this [#i2]_.
  59 The protection associates a single TX SA and up to four RX SAs to an
  60 interface. Four is as many as can fit on one cache-line. Multiple RX
  61 SAs mean that a peer can be using any SA in the set, this is
  62 particularly useful during rekeying because it is not possible for the
  63 peers to swap their RX and TX SAs at exactly the same moment in the
  64 traffic stream. Instead they can add the new RX immediately, then swap
  65 the TX after a short delay, then remove the old RX after another short
  66 delay. This will minimize, if not eliminate, packet loss.
  67
  68 The virtual interface can be represented in two ways:
  69
  70  - interface + encap + SA = (interface + encap) + SA = ipip-interface + SA transport mode
  71
  72 or
  73
  74  - interface + encap + SA = interface + (encap + SA) = IPSec-interface + SA tunnel mode
  75
  76 It's a question of where you add the parenthesis, from the perspective
  77 of the external user the effect is identical.
  78
  79 The IPSec interface serves as the encap-free interface to be used in
  80 conjunction with an encap-describing tunnel mode SA. VPP supports both models.
  81
  82 A route based VPN could impose 0, 1 or 2 encaps. the support matrix for  these use cases is:
  83
  84 .. code-block:: console
  85
  86
  87          |  0  |  1  |  2  |
  88    --------------------------
  89    ipip  |  N  |  Y  |  Y  |
  90    ipsec |  P  |  Y  |  P  |
  91
  92 Where P = potentially.
  93
  94 Ipsec could potentially support 0 encap (i.e. transport mode) since
  95 neither the interface nor the SA *requires* encap. However, for a
  96 route based VPN to use transport mode is probably wrong since one
  97 shouldn't use transport mode for transit traffic, since without encap
  98 it is not guaranteed to return. IPSec could potentially support 2
  99 encaps, but that would require the SA to describe both, something it
 100 does not do at this time.
 101
 102 Internally the difference is that the mid-chain adjacency for the IPSec
 103 interface has no associated encap (whereas for an ipip tunnel it
 104 describes the peer). Consequently, features on the output arc see
 105 packets without any encap. Since the protecting SAs are in tunnel
 106 mode, they apply the encap. The mid-chain adj is stacked only once the
 107 protecting SA is known, since only then is the peer known. Otherwise
 108 the VLIB graph nodes used are the same:
 109
 110 .. code-block:: console
 111
 112    (routing) --> ipX-michain --> espX-encrypt --> adj-midchain-tx --> (routing)
 113
 114     where X = 4 or 6.
 115
 116
 117 Some benefits to the ipsec interface:
 118
 119 - it is slightly more efficient since the encapsulating IP header has its checksum updated only once.
 120 - even when the interface is admin up traffic cannot be sent to a peer
 121   unless the SA is available (since it's the SA that determines the
 122   encap). With ipip interfaces a client must use the admin state to
 123   prevent sending until the SA is available.
 124
 125 The best recommendations I can make are:
 126
 127 - pick a model that supports your use case
 128 - make sure any other features you wish to use are supported by the model
 129 - choose the model that best fits your control plane's model.
 130
 131
 132 Multi-point Interfaces
 133 ^^^^^^^^^^^^^^^^^^^^^^
 134
 135 As mentioned above route based VPNs protect all packets destined to
 136 a given peer with the same SA pair. This protection was modelled using
 137 a virtual p2p interface, so one could legitimately reason that
 138 all traffic through the interface is protected with the SA pair or all
 139 traffic to the peer is protected, since they are one in the
 140 same. However, when we consider multi-point interfaces, we have to
 141 think of protection applying to the peers on the link.
 142
 143 When using IPSec protection on a P2MP link the **ipsec_tun_protect_t**
 144 will be specific to a particular peer (in the P2P case this peer is
 145 the usual special all zero address).
 146
 147 All other aspects of using route based VPNs remains the same. The
 148 routes are resolved via specific peers on the interface, i.e.
 149
 150 .. code-block:: console
 151
 152   ip route add 10.0.0.0/8 via 192.168.1.1 mipip0
 153
 154
 155 rather than
 156
 157 .. code-block:: console
 158
 159   ip route add 10.0.0.0/8 via ipip0
 160
 161
 162 but one should always use a next-hop on a multi-access interface, so
 163 this is not a restriction.
 164
 165 The data-path is unchanged, in both P2P and P2MP case the SA to
 166 use for TX comes from the adjacency, and for RX it's the SPI that
 167 matches to the SA and interface.
 168
 169
 170 Policy Based VPNs
 171 -----------------
 172
 173 At the risk of stating the obvious, in a policy based VPN the SA is
 174 chosen based on a specific IPSec policy. A policy describes what
 175 attributes of the packets to match and what action to take if
 176 matched. Actions are:
 177
 178 - bypass: Ignore it
 179 - discard: Drop it
 180 - protect: Either encrypt or decrypt with a specific SA
 181
 182 The 'resolve' action which (as per-RFC4301) states that an IKE session
 183 should be initiated, is not supported.
 184
 185 Policies are stored in a security policy database (SPD). An SPD is
 186 attached to an interface. Packets that ingress and egress the
 187 interface are matched against the policies in the attached SPD.
 188 This is IPSec as described in RFC4301.
 189
 190
 191 .. rubric:: Footnotes:
 192
 193 .. [#i1] Standard in inverted commas because, at least to my
 194          knowledge, there is no official standard (RFC) that states it
 195          should be this way. It is probably this way because routers
 196          model/implement/restrict/etc IPSec as an interface
 197          input/output feature.
 198 .. [#i2] That's a self criticism.
 199