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.

SAD Lookup Mechanisms

Outbound Processing

For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache.

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.

(See Section 4.1 for details on the algorithm that MUST be used for mapping inbound IPsec datagrams to SAs.)

SAD Entry Parameters

The following parameters are associated with each entry in the SAD. They should all be present except where otherwise noted, e.g., AH Authentication algorithm. This description does not purport to be a MIB, only a specification of the minimal data items required to support an SA in an IPsec implementation.

Selector Population

For each of the selectors defined in Section 4.4.1.1, the entry for an inbound SA in the SAD MUST be initially populated with the value or values negotiated at the time the SA was created. (See the paragraph in Section 4.4.1 under "Handling Changes to the SPD while the System is Running" for guidance on the effect of SPD changes on extant SAs.)

For a receiver, these values are used to check that the header fields of an inbound packet (after IPsec processing) match the selector values negotiated for the SA. Thus, the SAD acts as a cache for checking the selectors of inbound traffic arriving on SAs. For the receiver, this is part of verifying that a packet arriving on an SA is consistent with the policy for the SA. (See Section 6 for rules for ICMP messages.)

These fields can have the form of specific values, ranges, ANY, or OPAQUE, as described in Section 4.4.1.1, "Selectors".

SAD Entries Without SPD Correspondence

Note also that there are a couple of situations in which the SAD can have entries for SAs that do not have corresponding entries in the SPD:

1. Since this document does not mandate that the SAD be selectively cleared when the SPD is changed, SAD entries can remain when the SPD entries that created them are changed or deleted.
2. If a manually keyed SA is created, there could be an SAD entry for this SA that does not correspond to any SPD entry.

Multicast SA Support

Note: The SAD can support multicast SAs, if manually configured.

Outbound Multicast SA

An outbound multicast SA has the same structure as a unicast SA. The source address is that of the sender, and the destination address is the multicast group address.

Inbound Multicast SA

An inbound, multicast SA must be configured with the source addresses of each peer authorized to transmit to the multicast SA in question. The SPI value for a multicast SA is provided by a multicast group controller, not by the receiver, as for a unicast SA.

Because an SAD entry may be required to accommodate multiple, individual IP source addresses that were part of an SPD entry (for unicast SAs), the required facility for inbound, multicast SAs is a feature already present in an IPsec implementation. However, because the SPD has no provisions for accommodating multicast entries, this document does not specify an automated way to create an SAD entry for a multicast, inbound SA. Only manually configured SAD entries can be created to accommodate inbound, multicast traffic.

Implementation Guidance: SPD-S to SAD Linking

This document does not specify how an SPD-S entry refers to the corresponding SAD entry, as this is an implementation-specific detail. However, some implementations (based on experience from RFC 2401) are known to have problems in this regard.

Problem: Simply storing the (remote tunnel header IP address, remote SPI) pair in the SPD cache is not sufficient, since the pair does not always uniquely identify a single SAD entry.

Examples of Non-Uniqueness:

• Two hosts behind the same NAT could choose the same SPI value.
• A host is assigned an IP address (e.g., via DHCP) previously used by some other host, and the SAs associated with the old host have not yet been deleted via dead peer detection mechanisms.

Consequence: This may lead to packets being sent over the wrong SA or, if key management ensures the pair is unique, denying the creation of otherwise valid SAs.

Recommendation: Implementors should implement links between the SPD cache and the SAD in a way that does not engender such problems.