Section 14.2. IPsec Architecture

The current IPsec architecture is specified in RFC 2401 [Kent and Atkinson 1998c]; we refer to the replacement described in the RFC 2401bis draft as the new architecture. Although many of the details in the new architecture differ from the current version, the fundamental ideas and underlying principles remain the same.

The IPsec Processing Model

In the new architecture, the SPD selection and routing functions are separated; consequently, SPD entries are no longer associated with an interface. This means that for uni-cast packets, the meaning of the security parameter index (SPI) no longer depends on the destination address. Whether the SPI's meaning depends on the IPsec protocol is a local matter; an implementation can use a single number space for both AH and ESP, or it can use separate number spaces for each.

Implementations are no longer required to support nesting or SA bundles but are still free to do so. The new specification describes a method of achieving the same results through entries in the SPD and forwarding tables.

IPsec is now allowed to process fragmented IPv4but not IPv6tunnel-mode packets. The new architecture specifies several methods for dealing with fragments, and fields supporting this are now required in the SPD.

Finally, AH support is no longer required, but implementations are free to provide it. This recognizes the fact that although in almost all cases, the ESP-provided integrity is sufficient, in a small number of contexts, the extra protection that AH provides is useful.

The Security Policy Database

In the new architecture, the function and form of the SPD are specified much more precisely than in RFC 2401. Recall from Chapter 10 that the SPD describes the processing to be applied to each packet by matching selectors in the packet with selectors in the SPD. Also recall that the SPD is ordered so that the more specific of overlapping policies will be applied before the more general.

In the new architecture, the SPD conceptually consists of three disjoint but interleaved parts:

SPD-I	The entries that describe the inbound traffic that should be discarded or bypass IPsec
SPD-O	The entries that describe the outbound traffic that should be discarded or bypass IPsec
SPD-S	The entries that describe traffic to which IPsec should be applied

The disposition of inbound traffic is specified in either the SPD-I or the SPD-S. Similarly, the disposition of outbound traffic is specified in either the SPD-O or the SPD-S. We could, for example, describe outbound processing as checking the SPD-O to see whether a packet should be discarded or bypass IPsec and then checking the SPD-S if no matching entry is found in the SPD-O.

The new architecture envisions that caches will be associated with each of the three parts of the SPD. For example, when a packet first matches an SPD-O entry, the entry will be placed in the SPD-O cache. The rationale is that using the caches would improve IPsec's performance.

Unfortunately, the ordering of the SPD can cause problems with using caches this way. Suppose, for example, that a more general overlapping entry is cached, but the more specific is not. If a packet matching the more specific policy is presented for processing, IPsec will find the incorrectthat is, more generalcached entry and perform the wrong action on the packet. To solve this problem, the new architecture includes a method for decorrelating the SPD entriesthat is, for removing overlapping policies by breaking them into multiple disjoint policies.

Traffic to 192.168.1.10 should have ESP applied.
Traffic to 192.168.1.1 through 192.168.1.200 should be discarded.

Notice that the order is important because if policy 2 were checked first, traffic to 192.168.1.10 would be discarded instead of having ESP applied. To decorrelate these entries, we transform the second policy into two policies, neither of which overlaps the first policy:

Notice that in this case, we can check the policies in any order without ambiguity. In particular, we can add these decorrelated policies to the caches without fear of mishandling a packet.

Traffic Selectors

The new architecture SPD is enhanced to allow more flexible packet handling. Selectors are now specified as lists of ranges. For example, we can specify that a policy should apply to destination addresses 192.168.1.1-192.168.1.13, 192.168.1.25-192.168.1.100, and 10.1.0.1-10.1.0.50. Single addresses are expressed as a trivial range. Ports can be specified in the same way, so in the new architecture, we can specify port ranges.

For ICMP packets, we can specify the type and code fields (Figure 2.24) instead of a port, so we have increased granularity for these packets. Similarly, we can specify the IPv6 mobility header (MH) type as a policy selector.

In addition to the selectors, the SPD indicates the mode (transport or tunnel), the local and remote tunnel addresses for tunnel mode, whether the SA should use extended 64-bit sequence numbers, the IPsec protocol (AH or ESP), cryptographic algorithms, some flags specifying how to handle fragments and the differentiated service bits, and the populate from packet (PFP) flags that specify whether the SA should use the selector from the packet or from the SPD.

Support for Multicast

The new architecture supports multicast and anycast as well as unicast packets. As discussed above, the SPI or perhaps the SPI and the IPsec protocol are sufficient to locate the SA for an incoming unicast packet. Because a third party, rather than the destination host, usually supplies the SPI for multicast packets, a collision with a host-generated SPI is possible, and further steps are required to avoid ambiguity.

An IPsec-protected single-source multicast group packet is specified by the source address, destination address, and SPI, so these three quantities are consulted to determine the appropriate SA. In the case of a multisource multicast group, only the destination address and SPI are used to specify the SA. Thus, there are three ways of mapping an IPsec packet to its SA, and we must have some way of ensuring that we do this in an unambiguous way.

The new architecture accomplishes this by using a "longest match" rule. When processing an incoming packet, IPsec first searches the SAD for a match on the SPI and source and destination addresses. If there is no match, the SAD is searched again, looking for a match on destination address and SPI. If there is still no match, the SAD is searched for a matching SPI. If this last search also fails, there is no SA for this packet, and the packet is dropped.

The Peer Authorization Database

The new architecture adds a third database, the peer authorization database (PAD), to the SPD and SAD. The PAD is used to tie together IKE and the SPD. It contains information on which peers are allowed to negotiate AH or ESP SAs with the host.

As an example, consider a mobile host that establishes a VPN with a security gateway on its home network from many different IP addresses. In this case, it is obviously not possible to simply use the mobile host's source address to locate the proper policy or check whether it's authorized. Instead, the mobile host sends identifying information in the Identity payload, which the security gateway uses to check authorization and to locate an appropriate policy.

The PAD also includes information on the method of identity authorizationshared secret, digital signature, and so onthat the responder should use to verify the identity of the initiator. If certificates are involved, the PAD contains information on acceptable root certificates and revocation lists.

In short, the PAD contains the information that the responder needs to execute the authorization protocol with an initiator. The PAD may be notional in the sense that its functions are part of the SA management softwareIKE or the equivalentand that no distinct database exists. Whether or not the PAD exists as a distinct database is a local matter. The new architecture uses it as the (possibly notional) locus of information needed to perform initiator authorization and to locate the appropriate SPD entries.