(October 2018, September 2019)
IPsec secures IPv4 and IPv6 with (depending on configuration):
These documents provide a grounding in IPsec concepts:
ipsec(4), the OpenBSD man pageTwo protocols provide most of the security for IPsec:
IPsec operates in one of two modes:
Besides ESP and AH, IKE (internet key exchange) is the other protocol closely associated with IPsec.
IKE handles peer authentication and connection negotiation, based on IPsec security policies. When an IKE daemon starts (generally, depending on implementation), it reads the IPsec configuration, and creates appropriate entries in the SPD (security policy database). The OS kernel tests each network packet to see if it matches a security policy.
When a peer first authenticates and negotiates a successfully connection (i.e., matches a policy), the IKE daemon (again, depending on IPsec implementation) creates a pair of SA’s (security associations) in the SAD (security association database). Why a pair? SA’s are unidirectional, so one SA is used for sending to the peer and other SA for receiving from the peer. If the OS kernel matches a packet against a security policy from the SPD, it transforms the packet according to the linked SA.
An SPD generally resides in OS/kernel space.
Although IKE creates/updates/deletes entries in the kernel/OS SPD and SAD, the IKE daemon itself typically runs in user-space.
StrongSwan is simply a keying daemon that (on Linux and FreeBSD) interacts with the kernel’s SPD via the setkey(8) system call.
An SA holds all information (e.g., the negotiated encryption method and key) necessary to transform a packet.
IKE doesn’t always immediately create SA’s following peer negotiation. In some implementations, the IKE daemon may be configured to not create SA’s, and let the OS create the SA’s “on demand” — when the kernel sees matching traffic, it makes an upcall† to the IKE daemon causing it to create the SA’s.
The OS tests each packet against policies in the SPD. If a packet fails to match any policy, it’s either discarded or passed out of IPsec for further processing (e.g., forwarded according to the system routing tables).
The IPsec tunnel terminates when the SA lifetimes expire, or when the something deletes the security associations from the SAD.
The policies in the SPD define what must be done with packets. The security associations in the SAD define how to transform the packets.
† An upcall “allows the kernel to execute a function in userspace, and potentially be returned information as a result.”
“Phase 1” and “phase 2” are the two stages of IKE negotiation.
Phase 1 is the Diffie-Hellman exchange (and similar), where peers that do not yet trust each other create a shared secret for subsequent communication. I.e., by merely exchanging unencrypted non-sensitive information, the two peers each create one secret they both know, without either of them disclosing the secret to each other or any eavesdropping third party.
After phase 1 completes, the two peer can communicate securely in phase 2. During phase 2, IKE negotiates between the peers to agree on the security parameters necessary to create SA’s.
Then end result of completing phase 1 and phase 2 is that the peers each hold a matched pair of security associations they can use to securely exchange packets.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.hald001/onikseaso.htm
The IKEv2 protocol is very similar to IKEv1 in many respects. Both protocols establish SAs in two phases. They first establish an SA that securely carries IKE messages between the peers, and subsequently establish additional SAs to carry the protected ESP or AH traffic. For IKEv2, the SA that carries IKE messages is referred to as the IKE SA, and the SAs for ESP and AH are child SAs.
For IKEv1, the corresponding terms for the two types of SAs are “ISAKMP SA” and “IPSec SA”. We use the terms “phase 1 SA” and “phase 2 SA” to refer to the two SA types when the version of IKE is unknown or unimportant.
The message formats defined for IKEv2 are very similar to those for IKEv1. Both formats start with a message header that contains a protocol version field, so a receiving node can receive both types of messages on a single UDP port (by default, port 500), and easily tell whether the message is IKEv1 or IKEv2. Both include variable length payloads of a similar generic format.
The specific content and sequences of messages for IKEv2 are quite different from IKEv1. In IKEv2, all communications consist of pairs of messages: a request and a response. The pair is called an “exchange”. The initial exchanges consist of the IKE_SA_INIT exchange and the IKE_AUTH exchange. These two exchanges establish both the IKE SA and the first Child SA. Subsequent exchanges are the CREATE_CHILD_SA exchanges and INFORMATIONAL exchanges, which perform other duties such as establishing additional child SAs and deleting SAs.
Prefer IKEv2 instead of IKEv1.
RFC 5996: Internet Key Exchange Protocol Version 2 (IKEv2)
Dead peer detection periodically (e.g., every 10 seconds) sends “are you alive?” queries to the peer. If the peer fails to respond to a number of consecutive queries, IPsec deletes the SA from the SAD.
RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
When two peers communicate with IKE [2] and IPSec [3], the situation may arise in which connectivity between the two goes down unexpectedly. This situation can arise because of routing problems, one host rebooting, etc., and in such cases, there is often no way for IKE and IPSec to identify the loss of peer connectivity. As such, the SAs can remain until their lifetimes naturally expire, resulting in a “black hole” situation where packets are tunneled to oblivion. It is often desirable to recognize black holes as soon as possible so that an entity can failover to a different peer quickly. Likewise, it is sometimes necessary to detect black holes to recover lost resources.
[…] consider two DPD peers A and B. If there is ongoing valid IPSec traffic between the two, there is little need for proof of liveliness. The IPSec traffic itself serves as the proof of liveliness. If, on the other hand, a period of time lapses during which no packet exchange occurs, the liveliness of each peer is questionable. Knowledge of the peer’s liveliness, however, is only urgently necessary if there is traffic to be sent. For example, if peer A has some IPSec packets to send after the period of idleness, it will need to know if peer B is still alive. At this point, peer A can initiate the DPD exchange.
To this end, each peer may have different requirements for detecting proof of liveliness. Peer A, for example, may require rapid failover, whereas peer B’s requirements for resource cleanup are less urgent. In DPD, each peer can define its own “worry metric” - an interval that defines the urgency of the DPD exchange. Continuing the example, peer A might define its DPD interval to be 10 seconds. Then, if peer A sends outbound IPSec traffic, but fails to receive any inbound traffic for 10 seconds, it can initiate a DPD exchange.
Peer B, on the other hand, defines its less urgent DPD interval to be 5 minutes. If the IPSec session is idle for 5 minutes, peer B can initiate a DPD exchange the next time it sends IPSec packets to A.
It is important to note that the decision about when to initiate a DPD exchange is implementation specific. An implementation might even define the DPD messages to be at regular intervals following idle periods.
The DPD exchange is a bidirectional (HELLO/ACK) Notify message.
Host Alpha creates an inbound and an outbound SA for an IPsec connection. Host Alpha assigns each SA a locally-unique SPI (an arbitrary 32-bit value). During the IKE exchange, the Host Alpha sends the SPI for its inbound SA to its peer, Host Beta. (And Host Beta replies with its inbound SPI.) When the peer, Host Beta, later sends IPsec packets to Host Alpha, Host Beta includes the SPI that identifies Host Alpha’s incoming SA in the packet’s ESP header. Using the SPI from the packet header, Host Alpha knows which SA to apply to the packet it received.
Usually, for incoming packets, the SPI alone is enough to identify the correct SA.
When Host Alpha wants to send an outgoing packet, it must choose the correct SA to transform the packet based on other selectors, since nothing has assigned an SPI yet. Host Alpha may look at a number of selection criteria when choosing an SA. The selectors usually include local IP address, remote IP address, and the local and remote ports.
https://security.stackexchange.com/questions/56434/understanding-the-details-of-spi-in-ike-and-ipsec
RFC 4301: Appendix A: Glossary
Security Parameters Index (SPI) An arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet should be bound. For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type. Additional IP address information is used to identify multicast SAs. The SPI is carried in AH and ESP protocols to enable the receiving system to select the SA under which a received packet will be processed. An SPI has only local significance, as defined by the creator of the SA (usually the receiver of the packet carrying the SPI); thus an SPI is generally viewed as an opaque bit string. However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing.
SPD-S: For traffic that is to be protected using IPsec, the entry consists of the values of the selectors that apply to the traffic to be protected via AH or ESP, controls on how to create SAs based on these selectors, and the parameters needed to effect this protection (e.g., algorithms, modes, etc.). Note that an SPD-S entry also contains information such as “populate from packet” (PFP) flag (see paragraphs below on “How To Derive the Values for an SAD entry”) and bits indicating whether the SA lookup makes use of the local and remote IP addresses in addition to the SPI (see AH [Ken05b] or ESP [Ken05a] specifications).
[…]
4.4.1.1. Selectors
An SA may be fine-grained or coarse-grained, depending on the selectors used to define the set of traffic for the SA. For example, all traffic between two hosts may be carried via a single SA, and afforded a uniform set of security services. Alternatively, traffic between a pair of hosts might be spread over multiple SAs, depending on the applications being used (as defined by the Next Layer Protocol and related fields, e.g., ports), with different security services offered by different SAs. Similarly, all traffic between a pair of security gateways could be carried on a single SA, or one SA could be assigned for each communicating host pair. The following selector parameters MUST be supported by all IPsec implementations to facilitate control of SA granularity.
- Remote IP Address(es) […]
- Local IP Address(es) […]
- Next Layer Protocol: Obtained from the IPv4 “Protocol” or the IPv6 “Next Header” fields […]
- If the Next Layer Protocol uses two ports (as do TCP, UDP, SCTP, and others), then there are selectors for Local and Remote Ports. […]
- If the Next Layer Protocol value is ICMP, then there is a 16-bit selector for the ICMP message type and code. […]
- Name: This is not a selector like the others above. It is not acquired from a packet. A name may be used as a symbolic identifier for an IPsec Local or Remote address. […] in support of access control when an IP address would not be appropriate for the Remote IP address selector, e.g., for “road warriors”.
[…]
4.4.2. Security Association Database (SAD)
In each IPsec implementation, there is a nominal Security Association Database (SAD), in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache. For inbound processing, for unicast SAs, the SPI is used either alone to look up an SA or in conjunction with the IPsec protocol type. If an IPsec implementation supports multicast, the SPI plus destination address, or SPI plus destination and source addresses are used to look up the SA.
In addition to the SPD and SAD, IPsec-v3 specifies a third database type: the Peer Authorization Database. The PAD holds information needed during peer authentication, linking IPsec with the key management protocol (e.g., IKE). Neither Linux nor the BSD’s appear to use a PAD (as of 2018).
For many cases, no. Send IPsec traffic through a VTI interface to make it routable. If VTI interfaces aren’t available on the platform, look at GRE.
A VTI (virtual tunnel interfaces) acts almost like a real network interface. Routing IPsec with VTI works much like a GRE tunnel, but without the minor overhead of encapsulation.
VTI devices are local. Because VTI adds no extra encapsulation, the other end doesn’t necessarily need a matching VTI interface so long as it has appropriate IPsec policies.
Linux added basic VTI support in 2012 (kernel 3.6) with important fixes in 2014 (kernel 3.14).
See ip-tunnel(8).
$ ip tunnel add vti20 remote 203.0.113.123 mode vti key 20
$ ip -s tunnel show vti20
$ ip tunnel del vti20
The device name can be anything but should start with vti….
Linux treats devices named vti… specially in a few cases, like when it reports statistics.
Virtual xfrm (“transform”) interfaces (ip-xfrm(8)), added to Linux kernel 4.19 in 2018, address some limitations of the older VTI implementation:
A RHEL7 knowledgebase article describes setting up an IPsec VTI tunnel with Libreswan. Also see Security Guide 4.6. Securing Virtual Private Networks Using Libreswan.
Remember that IKE uses UDP ports 500 (for IKE session negotiation) and 4500 (for IKEv2 NAT traversal), and ESP uses port 50.
Use OpenSSL to generate a shared secret:
🐚 ~ $ openssl rand -base64 48
8eZ8k3ilzO/TVFEEKxhWQAqxW3GwPfkRNLfJ6q06WQi4aM9sAAWNz2QLIpBdLWaN
Put the shared secret in /etc/ipsec.secrets on both machines like this:
10.0.1.106 10.0.1.107 : PSK '8eZ8k3ilzO/TVFEEKxhWQAqxW3GwPfkRNLfJ6q06WQi4aM9sAAWNz2QLIpBdLWaN'
Create /etc/ipsec.d/vti-ls-0.conf on both machines:
conn myvpn
left=10.0.1.106
leftid=10.0.1.106
leftsubnet=0.0.0.0/0
right=10.0.1.107
rightid=10.0.1.107
rightsubnet=0.0.0.0/0
ike=3des-md5
## phase 1 ##
keyexchange=ike
## phase 2 ##
phase2=esp
phase2alg=3des-md5
authby=secret
compress=no
pfs=yes
auto=start
mark=5/0xffffffff
vti-interface=vti-ls-0
vti-routing=no
Start IPsec on both boxes, and add routes as desired:
🐚 ~ # ipsec start
🐚 ~ # ip route add 10.0.0.0/24 dev vti-ls-0
Libreswan implicitly creates the vti-ls-0 interface.
The example above sets leftsubnet and rightsubnet as 0.0.0.0/0, i.e., the default route that matches all addresses.
Why does this not result in all packets matching the IPsec policy?
Because of the packet mark set by the VTI interface acts as a policy selector.
Only marked packets match.
Create a VTI interface manually like:
🐚 ~ # ip link add name vti0 type vti key VTI_KEY local LOCAL_ADDR remote REMOTE_ADDR
🐚 ~ # ip link set vti0 up
🐚 ~ # ip addr add LOCAL_VIRTUAL_ADDR/24 dev vti0
(ip-link(8) describes key as “either a number or an IPv4 address-like dotted quad” and gives an example key of “102”.)
The ip-xfrm(8) man page:
xfrm is an IP framework for transforming packets (such as encrypting their payloads). This framework is used to implement the IPsec protocol suite (with the state object operating on the Security Association Database, and the policy object operating on the Security Policy Database).
ip xfrm state … manipulates SA’s (security associations).
The state/SA includes the actual security parameters and keys.
Since SA’s are unidirectional, we’ll have two states for each connection.
ip xfrm policy … manipulates entries in the SPD (security policy database).
A policy defines the traffic to which a state/SA should apply, based on source/destination addresses and protocols.
If a packet matches an SPD entry, the appropriate SA processes/encrypts it.
So, what do we need to manually set up the policies and states?
Each of the two states/SA’s (send, receive) needs two keys: an encryption key, and a peer authentication key. xxd dumps the hex value of a file, so we can use it to harvest a key like xxd -p -l 32 -c 32 /dev/random. (xxd writes octets, so 8×32=256 bits for a key.)
Each of the two states also need an SPI and reqid.
The SPI is the 32-bit IPsec SPI, which we could generate like xxd -p -l 4 /dev/random.
What’s the reqid?
The reqid ties the IPsec security policies to the matching SA’s.
Why is reqid needed in addition to the SPI?
The SA’s in both directions share the same reqid, and the reqid ties all the SA’s together in cases where more than two SA’s exist for a policy (e.g., during rekeying).
https://github.com/torvalds/linux/blob/master/net/xfrm/xfrm_state.c
/* Each xfrm_state may be linked to two tables:
1. Hash table by (spi,daddr,ah/esp) to find SA by SPI. (input,ctl)
2. Hash table by (daddr,family,reqid) to find what SAs exist for given
destination/tunnel endpoint. (output)
*/
[…]
u32 reqid,
[…]
So, both the SPI and reqid get used.
The SPI identifies the SA for incoming packets.
The reqid (along with selectors like the destination address) identifies the SA for outgoing packets.
reqid is 32-bit, like SPI.
🐚 ~ $ key_enc_a=$(xxd -p -l 32 -c 32 /dev/random)
🐚 ~ $ key_auth_a=$(xxd -p -l 32 -c 32 /dev/random)
🐚 ~ $ key_end_b=$(xxd -p -l 32 -c 32 /dev/random)
🐚 ~ $ key_auth_b=$(xxd -p -l 32 -c 32 /dev/random)
🐚 ~ $ spi_a=$(xxd -p -l 4 /dev/random)
🐚 ~ $ spi_b=$(xxd -p -l 4 /dev/random)
🐚 ~ $ reqid=$(xxd -p -l 4 /dev/random)
🐚 ~ $ sudo ip xfrm state add src 192.0.2.1 dst 198.51.100.20 proto esp \
spi "0x${spi_a}" reqid "0x${reqid}" mode tunnel \
auth sha256 "0x${key_auth_a}" enc aes "0x${key_enc_a}"
🐚 ~ $ sudo ip xfrm state add src 198.51.100.20 dst 192.0.2.1 proto esp \
spi "0x${spi_b}" reqid "0x${reqid}" mode tunnel \
auth sha256 "0x${key_auth_b}" enc aes "0x${key_enc_b}"
Create policies to match the SA’s, and add the routes. On the left box:
🐚 ~ $ sudo ip xfrm policy add src 10.0.0.0/24 dst 172.16.0.0/24 dir out \
tmpl src 192.0.2.1 dst 198.51.100.20 proto esp \
reqid "0x${reqid}" mode tunnel
🐚 ~ $ sudo ip xfrm policy add src 172.16.0.0/24 dst 10.0.0.0/24 dir fwd \
tmpl src 198.51.100.20 dst 192.0.2.1 proto esp \
reqid "0x${reqid}" mode tunnel
🐚 ~ $ sudo ip xfrm policy add src 172.16.0.0/24 dst 10.0.0.0/24 dir in \
tmpl src 198.51.100.20 dst 192.0.2.1 proto esp \
reqid "0x${reqid}" mode tunnel
🐚 ~ $ sudo ip route add 172.16.0.0/24 dev eth0 src 10.0.0.1
On the right box:
🐚 ~ $ sudo ip xfrm policy add src 172.16.0.0/24 dst 10.0.0.0/24 dir out tmpl src 198.51.100.20 dst 192.0.2.1 proto esp reqid "0x${reqid[2]}" mode tunnel
🐚 ~ $ sudo ip xfrm policy add src 10.0.0.0/24 dst 172.16.0.0/24 dir fwd tmpl src 192.0.2.1 dst 198.51.100.20 proto esp reqid "0x${reqid[1]}" mode tunnel
🐚 ~ $ sudo ip xfrm policy add src 10.0.0.0/24 dst 172.16.0.0/24 dir in tmpl src 192.0.2.1 dst 198.51.100.20 proto esp reqid "0x${reqid[1]}" mode tunnel
🐚 ~ $ sudo ip route add 10.0.0.0/24 dev eth0 src 172.16.0.1
When done playing, clear out the above manual config with:
🐚 ~ $ sudo ip xfrm state flush
🐚 ~ $ sudo ip xfrm policy flush
…
🐚 ~ $ sudo lxc-create -n vpn-alpha -t debian -- -r buster
🐚 ~ $ sudo lxc-create -n vpn-beta -t debian -- -r buster
🐚 ~ $ sudo lxc-start -n vpn-alpha
🐚 ~ $ sudo lxc-start -n vpn-beta
root@vpn-alpha:~# ip link add name vti0 type vti key 20 local 10.0.0.110 remote 10.0.0.175
root@vpn-alpha:~# ip link set vti0 up
root@vpn-alpha:~# ip addr add 192.168.98.1/24 dev vti0
IPsec creates a boundary between unprotected and protected interfaces, for a host or a network (see Figure 1 below). Traffic traversing the boundary is subject to the access controls specified by the user or administrator responsible for the IPsec configuration. These controls indicate whether packets cross the boundary unimpeded, are afforded security services via AH or ESP, or are discarded.
Figure 1 from RFC 4301:
Unprotected
^ ^
| |
+-------------|-------|-------+
| +-------+ | | |
| |Discard|<--| V |
| +-------+ |B +--------+ |
................|y..| AH/ESP |..... IPsec Boundary
| +---+ |p +--------+ |
| |IKE|<----|a ^ |
| +---+ |s | |
| +-------+ |s | |
| |Discard|<--| | |
| +-------+ | | |
+-------------|-------|-------+
| |
V V
Protected
The protection offered by IPsec is based on requirements defined by a Security Policy Database (SPD) […] packets are selected for one of three processing actions based on IP and next layer header information (“Selectors”, Section 4.4.1.1) matched against entries in the SPD. Each packet is either PROTECTed using IPsec security services, DISCARDed, or allowed to BYPASS IPsec protection, based on the applicable SPD policies identified by the Selectors.
Each policies in the SPD specifies: security protocol (AH or ESP), mode (transport or tunnel), security service options, cryptographic algorithms, and in what combinations to use those protocols and services.
Security Associations (SA’s).
The concept of a “Security Association” (SA) is fundamental to IPsec. Both AH and ESP make use of SAs, and a major function of IKE is the establishment and maintenance of SAs.
An SA is a simplex “connection” that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH, or ESP […] To secure typical, bi-directional communication between two IPsec-enabled systems, a pair of SAs (one in each direction) is required. IKE explicitly creates SA pairs in recognition of this common usage requirement.
For an SA used to carry unicast traffic, the Security Parameters Index (SPI) by itself suffices to specify an SA. […for multicast traffic, the SPI isn’t sufficient…] Each entry in the SA Database (SAD) (Section 4.4.2) must indicate whether the SA lookup makes use of the destination IP address, or the destination and source IP addresses, in addition to the SPI.
(The Index maps a policy in the SPD to an SA.)
RFC 4301 conceives of three databases in an IPsec implementation:
IPsec decisions preempt system routing:
The IPsec model described here embodies a clear separation between forwarding (routing) and security decisions, to accommodate a wide range of contexts where IPsec may be employed. Forwarding may be trivial, in the case where there are only two interfaces, or it may be complex, e.g., if the context in which IPsec is implemented employs a sophisticated forwarding function. IPsec assumes only that outbound and inbound traffic that has passed through IPsec processing is forwarded in a fashion consistent with the context in which IPsec is implemented. Support for nested SAs is optional; if required, it requires coordination between forwarding tables and SPD entries to cause a packet to traverse the IPsec boundary more than once.
The Security Policy Database (SPD)
An SA is a management construct used to enforce security policy for traffic crossing the IPsec boundary. Thus, an essential element of SA processing is an underlying Security Policy Database (SPD) that specifies what services are to be offered to IP datagrams and in what fashion. The form of the database and its interface are outside the scope of this specification. However, this section specifies minimum management functionality that must be provided, to allow a user or system administrator to control whether and how IPsec is applied to traffic transmitted or received by a host or transiting a security gateway. The SPD, or relevant caches, must be consulted during the processing of all traffic (inbound and outbound), including traffic not protected by IPsec, that traverses the IPsec boundary. This includes IPsec management traffic such as IKE. An IPsec implementation MUST have at least one SPD, and it MAY support multiple SPDs, if appropriate for the context in which the IPsec implementation operates. There is no requirement to maintain SPDs on a per-interface basis, as was specified in RFC 2401 [RFC2401]. However, if an implementation supports multiple SPDs, then it MUST include an explicit SPD selection function that is invoked to select the appropriate SPD for outbound traffic processing. The inputs to this function are the outbound packet and any local metadata (e.g., the interface via which the packet arrived) required to effect the SPD selection function. The output of the function is an SPD identifier (SPD-ID).
The SPD is an ordered database, consistent with the use of Access Control Lists (ACLs) or packet filters in firewalls, routers, etc. The ordering requirement arises because entries often will overlap due to the presence of (non-trivial) ranges as values for selectors. Thus, a user or administrator MUST be able to order the entries to express a desired access control policy. There is no way to impose a general, canonical order on SPD entries, because of the allowed use of wildcards for selector values and because the different types of selectors are not hierarchically related.
Processing Choices: DISCARD, BYPASS, PROTECT
An SPD must discriminate among traffic that is afforded IPsec protection and traffic that is allowed to bypass IPsec. This applies to the IPsec protection to be applied by a sender and to the IPsec protection that must be present at the receiver. For any outbound or inbound datagram, three processing choices are possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec.
Each SPD entry specifies packet disposition as BYPASS, DISCARD, or PROTECT. The entry is keyed by a list of one or more selectors. The SPD contains an ordered list of these entries. The required selector types are defined in Section 4.4.1.1. These selectors are used to define the granularity of the SAs that are created in response to an outbound packet or in response to a proposal from a peer.
For traffic protected by IPsec, the Local and Remote address and ports in an SPD entry are swapped to represent directionality, consistent with IKE conventions. In general, the protocols that IPsec deals with have the property of requiring symmetric SAs with flipped Local/Remote IP addresses.
How to Derive the Values for an SAD Entry
For each selector in an SPD entry, the entry specifies how to derive the corresponding values for a new SA Database (SAD, see Section 4.4.2) entry from those in the SPD and the packet. The goal is to allow an SAD entry and an SPD cache entry to be created based on specific selector values from the packet, or from the matching SPD entry.
Selectors.
An SA may be fine-grained or coarse-grained, depending on the selectors used to define the set of traffic for the SA. For example, all traffic between two hosts may be carried via a single SA, and afforded a uniform set of security services. Alternatively, traffic between a pair of hosts might be spread over multiple SAs, depending on the applications being used (as defined by the Next Layer Protocol and related fields, e.g., ports), with different security services offered by different SAs. Similarly, all traffic between a pair of security gateways could be carried on a single SA, or one SA could be assigned for each communicating host pair. The following selector parameters MUST be supported by all IPsec implementations to facilitate control of SA granularity. Note that both Local and Remote addresses should either be IPv4 or IPv6, but not a mix of address types.
- Remote IP Address(es) (IPv4 or IPv6): […] a single IP address (via a trivial range), or a list of addresses (each a trivial range), or a range of addresses […]
- Local IP Address(es) (IPv4 or IPv6): [as above]
- Next Layer Protocol: […] Local and Remote Ports […]
- Name: This is not a selector like the others above. It is not acquired from a packet. [It’s inherited from a named SPD, and might be used, e.g., to identify a “road warrior”.]
Peer Authorization Database (PAD) (RFC4301):
The Peer Authorization Database (PAD) provides the link between the SPD and a security association management protocol such as IKE. It embodies several critical functions:
- identifies the peers or groups of peers that are authorized to communicate with this IPsec entity
- specifies the protocol and method used to authenticate each peer
- provides the authentication data for each peer
- constrains the types and values of IDs that can be asserted by a peer with regard to child SA creation, to ensure that the peer does not assert identities for lookup in the SPD that it is not authorized to represent, when child SAs are created
- peer gateway location info, e.g., IP address(es) or DNS names, MAY be included for peers that are known to be “behind” a security gateway
The PAD provides these functions for an IKE peer when the peer acts as either the initiator or the responder.
To perform these functions, the PAD contains an entry for each peer or group of peers with which the IPsec entity will communicate. An entry names an individual peer (a user, end system or security gateway) or specifies a group of peers (using ID matching rules defined below). The entry specifies the authentication protocol (e.g., IKEv1, IKEv2, KINK) method used (e.g., certificates or pre- shared secrets) and the authentication data (e.g., the pre-shared secret or the trust anchor relative to which the peer’s certificate will be validated).
Six types of IDs are supported for entries in the PAD, consistent with the symbolic name types and IP addresses used to identify SPD entries. The ID for each entry acts as the index for the PAD, i.e., it is the value used to select an entry. All of these ID types can be used to match IKE ID payload types. The six types are:
- DNS name (specific or partial)
- Distinguished Name (complete or sub-tree constrained)
- RFC 822 email address (complete or partially qualified)
- IPv4 address (range)
- IPv6 address (range)
- Key ID (exact match only)
The first three name types can accommodate sub-tree matching as well as exact matches. A DNS name may be fully qualified and thus match exactly one name, e.g., foo.example.com. Alternatively, the name may encompass a group of peers by being partially specified, e.g., the string “.example.com” could be used to match any DNS name ending in these two domain name components.
Once an entry is located based on an ordered search of the PAD based on ID field matching, it is necessary to verify the asserted identity, i.e., to authenticate the asserted ID. For each PAD entry, there is an indication of the type of authentication to be performed. This document requires support for two required authentication data types:
- X.509 certificate
- pre-shared secret
Once an IKE peer is authenticated, child SAs may be created. Each PAD entry contains data to constrain the set of IDs that can be asserted by an IKE peer, for matching against the SPD. Each PAD entry indicates whether the IKE ID is to be used as a symbolic name for SPD matching, or whether an IP address asserted in a traffic selector payload is to be used.
During the initial IKE exchange, the initiator and responder each assert their identity via the IKE ID payload and send an AUTH payload to verify the asserted identity. One or more CERT payloads may be transmitted to facilitate the verification of each asserted identity.
When an IKE entity receives an IKE ID payload, it uses the asserted ID to locate an entry in the PAD, using the matching rules described above. The PAD entry specifies the authentication method to be employed for the identified peer. This ensures that the right method is used for each peer and that different methods can be used for different peers. The entry also specifies the authentication data that will be used to verify the asserted identity. This data is employed in conjunction with the specified method to authenticate the peer, before any CHILD SAs are created.
Child SAs are created based on the exchange of traffic selector payloads, either at the end of the initial IKE exchange or in subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now authenticated) IKE peer is used to constrain creation of child SAs; specifically, the PAD entry specifies how the SPD is searched using a traffic selector proposal from a peer. There are two choices: either the IKE ID asserted by the peer is used to find an SPD entry via its symbolic name, or peer IP addresses asserted in traffic selector payloads are used for SPD lookups based on the remote IP address field portion of an SPD entry. It is necessary to impose these constraints on creation of child SAs to prevent an authenticated peer from spoofing IDs associated with other, legitimate peers.
The default automated key management protocol selected for use with IPsec is IKEv2.
When an automated SA/key management protocol is employed, the output from this protocol is used to generate multiple keys for a single SA. This also occurs because distinct keys are used for each of the two SAs created by IKE. If both integrity and confidentiality are employed, then a minimum of four keys are required. Additionally, some cryptographic algorithms may require multiple keys, e.g., 3DES.
Consider a situation in which a remote host (SH1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1’s traffic must pass. An example of this situation would be a mobile host crossing the Internet to his home organization’s firewall (SG2). This situation raises several issues:
- How does SH1 know/learn about the existence of the security gateway SG2?
- How does it authenticate SG2, and once it has authenticated SG2, how does it confirm that SG2 has been authorized to represent H2?
- How does SG2 authenticate SH1 and verify that SH1 is authorized to contact H2?
- How does SH1 know/learn about any additional gateways that provide alternate paths to H2?
To address these problems, an IPsec-supporting host or security gateway MUST have an administrative interface that allows the user/administrator to configure the address of one or more security gateways for ranges of destination addresses that require its use. This includes the ability to configure information for locating and authenticating one or more security gateways and verifying the authorization of these gateways to represent the destination host. (The authorization function is implied in the PAD.) This document does not address the issue of how to automate the discovery/verification of security gateways.
“The Security Policy Database (SPD)”, the SPD (or associated caches) MUST be consulted during the processing of all traffic that crosses the IPsec protection boundary, including IPsec management traffic. If no policy is found in the SPD that matches a packet (for either inbound or outbound traffic), the packet MUST be discarded. To simplify processing, and to allow for very fast SA lookups (for SG/BITS/BITW), this document introduces the notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S), and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As mentioned earlier, the SAD acts as a cache for checking the selectors of inbound IPsec-protected traffic arriving on SAs.) There is nominally one cache per SPD. For the purposes of this specification, it is assumed that each cached entry will map to exactly one SA.
For inbound IPsec traffic, the SAD entry selected by the SPI serves as the cache for the selectors to be matched against arriving IPsec packets, after AH or ESP processing has been performed.
OpenBSD calls the rules in the SPD “flows”. Here we see the flows/SPD rules and the SAD entries:
bsd # ipsecctl -s all
FLOWS:
flow esp in from 10.0.46.0/24 to 10.0.0.0/24 peer 20n.nn.219.190 srcid 10.0.0.50/32 dstid 20n.nn.219.190/32 type use
flow esp out from 10.0.0.0/24 to 10.0.46.0/24 peer 20n.nn.219.190 srcid 10.0.0.50/32 dstid 20n.nn.219.190/32 type require
flow esp in from 10.0.10.0/24 to 10.0.0.0/24 peer 20n.nn.217.230 srcid 10.0.0.50/32 dstid 20n.nn.217.230/32 type use
flow esp out from 10.0.0.0/24 to 10.0.10.0/24 peer 20n.nn.217.230 srcid 10.0.0.50/32 dstid 20n.nn.217.230/32 type require
flow esp in from 10.0.1.0/24 to 10.0.0.0/24 peer 20n.nn.204.134 srcid 10.0.0.50/32 dstid 20n.nn.204.134/32 type use
flow esp out from 10.0.0.0/24 to 10.0.1.0/24 peer 20n.nn.204.134 srcid 10.0.0.50/32 dstid 20n.nn.204.134/32 type require
SAD:
esp tunnel from 20n.nn.217.230 to 10.0.0.50 spi 0x338d7414 auth hmac-sha1 enc 3des-cbc
esp tunnel from 10.0.0.50 to 20n.nn.217.230 spi 0x58db0d95 auth hmac-sha1 enc 3des-cbc
esp tunnel from 20n.nn.204.134 to 10.0.0.50 spi 0x5dfa6164 auth hmac-sha1 enc des-cbc
esp tunnel from 20n.nn.219.190 to 10.0.0.50 spi 0x7247a33a auth hmac-sha1 enc aes
esp tunnel from 10.0.0.50 to 20n.nn.204.134 spi 0x96c0978c auth hmac-sha1 enc des-cbc
esp tunnel from 10.0.0.50 to 20n.nn.219.190 spi 0xff779a61 auth hmac-sha1 enc aes
The life of an IPsec tunnel looks something like this:
Generic routing encapsulation (GRE) provides encapsulation of packets but no encryption. GRE is truly generic; it can encapsulate almost any protocol (any OSI layer 3 protocol). For example, GRE enables transmission of non-IP protocols like IPX or AppleTalk over IP networks. GRE can tunnel any layer-3 protocols, routing protocols, multicast, etc.
GRE is light-weight. It simply wraps the tunneled protocol at one end with a new IP header, and strips that additional header at the other end of the GRE tunnel. That amounts to only an additional 24 bytes per packet (though additional GRE options can add up to another 12 bytes).
Configuration of a GRE tunnel includes:
Additionally, each end of the tunnel is assigned an “inside” IP address. The addresses for both ends of the tunnel must share a subnet. These addresses are only used to route traffic down the GRE tunnel.
“IPsec over GRE” encrypts data in IPsec, then sends that encrypted data through a GRE tunnel. This exposes any data communicated outside IPsec, potentially including routing protocols.
“GRE over IPsec” sends data into a GRE tunnel, then encrypts all the data with IPsec.