8 This is not a description on how IPSec works. Please read:
10 - https://tools.ietf.org/html/rfc4301
11 - https://tools.ietf.org/html/rfc4302
12 - https://tools.ietf.org/html/rfc4303
15 I would also suggest this:
17 - https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN
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):
24 - https://www.youtube.com/channel/UC1usFRN4LCMcfIV7UjHNuQg/featured
27 IPSec VPNs come in two flavours; policy and route based, the
28 difference is how the Security Association (SA) is chosen.
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).
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.
48 There are three components to the model:
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.
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
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.
68 The virtual interface can be represented in two ways:
70 - interface + encap + SA = (interface + encap) + SA = ipip-interface + SA transport mode
74 - interface + encap + SA = interface + (encap + SA) = IPSec-interface + SA tunnel mode
76 It's a question of where you add the parenthesis, from the perspective
77 of the external user the effect is identical.
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.
82 A route based VPN could impose 0, 1 or 2 encaps. the support matrix for these use cases is:
84 .. code-block:: console
88 --------------------------
92 Where P = potentially.
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.
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:
110 .. code-block:: console
112 (routing) --> ipX-michain --> espX-encrypt --> adj-midchain-tx --> (routing)
117 Some benefits to the ipsec interface:
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.
125 The best recommendations I can make are:
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.
132 Multi-point Interfaces
133 ^^^^^^^^^^^^^^^^^^^^^^
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.
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).
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.
150 .. code-block:: console
152 ip route add 10.0.0.0/8 via 192.168.1.1 mipip0
157 .. code-block:: console
159 ip route add 10.0.0.0/8 via ipip0
162 but one should always use a next-hop on a multi-access interface, so
163 this is not a restriction.
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.
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:
180 - protect: Either encrypt or decrypt with a specific SA
182 The 'resolve' action which (as per-RFC4301) states that an IKE session
183 should be initiated, is not supported.
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.
191 .. rubric:: Footnotes:
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.