Skip to main content

4.4.2.1. Data Items in the SAD

The following data items MUST be in the SAD:

Security Parameter Index (SPI)​

A 32-bit value selected by the receiving end of an SA to uniquely identify the SA.

  • In an SAD entry for an outbound SA, the SPI is used to construct the packet's AH or ESP header.
  • In an SAD entry for an inbound SA, the SPI is used to map traffic to the appropriate SA (see text on unicast/multicast in Section 4.1).

Sequence Number Counter​

A 64-bit counter used to generate the Sequence Number field in AH or ESP headers. 64-bit sequence numbers are the default, but 32-bit sequence numbers are also supported if negotiated.

Sequence Counter Overflow​

A flag indicating whether overflow of the sequence number counter should generate an auditable event and prevent transmission of additional packets on the SA, or whether rollover is permitted. The audit log entry for this event SHOULD include the SPI value, current date/time, Local Address, Remote Address, and the selectors from the relevant SAD entry.

Anti-Replay Window​

A 64-bit counter and a bit-map (or equivalent) used to determine whether an inbound AH or ESP packet is a replay.

Note: If anti-replay has been disabled by the receiver for an SA, e.g., in the case of a manually keyed SA, then the Anti-Replay Window is ignored for the SA in question. 64-bit sequence numbers are the default, but this counter size accommodates 32-bit sequence numbers as well.

AH Authentication Algorithm​

AH Authentication algorithm, key, etc. This is required only if AH is supported.

ESP Encryption Algorithm​

ESP Encryption algorithm, key, mode, IV, etc. If a combined mode algorithm is used, these fields will not be applicable.

ESP Integrity Algorithm​

ESP integrity algorithm, keys, etc. If the integrity service is not selected, these fields will not be applicable. If a combined mode algorithm is used, these fields will not be applicable.

ESP Combined Mode Algorithms​

ESP combined mode algorithms, key(s), etc. This data is used when a combined mode (encryption and integrity) algorithm is used with ESP. If a combined mode algorithm is not used, these fields are not applicable.

Lifetime of this SA​

A time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur. This may be expressed as a time or byte count, or a simultaneous use of both with the first lifetime to expire taking precedence.

Requirements:

  • A compliant implementation MUST support both types of lifetimes
  • MUST support a simultaneous use of both

Certificate Constraints: If time is employed, and if IKE employs X.509 certificates for SA establishment, the SA lifetime must be constrained by the validity intervals of the certificates, and the NextIssueDate of the Certificate Revocation Lists (CRLs) used in the IKE exchange for the SA. Both initiator and responder are responsible for constraining the SA lifetime in this fashion.

Note: The details of how to handle the refreshing of keys when SAs expire is a local matter. However, one reasonable approach is:

(a) Byte Count​

If byte count is used, then the implementation SHOULD count the number of bytes to which the IPsec cryptographic algorithm is applied. For ESP, this is the encryption algorithm (including Null encryption) and for AH, this is the authentication algorithm. This includes pad bytes, etc. Note that implementations MUST be able to handle having the counters at the ends of an SA get out of synch, e.g., because of packet loss or because the implementations at each end of the SA aren't doing things the same way.

(b) Two Kinds of Lifetime​

There SHOULD be two kinds of lifetime:

  • Soft lifetime: Warns the implementation to initiate action such as setting up a replacement SA
  • Hard lifetime: When the current SA ends and is destroyed

(c) Packet Delivery​

If the entire packet does not get delivered during the SA's lifetime, the packet SHOULD be discarded.

IPsec Protocol Mode​

Tunnel or transport. Indicates which mode of AH or ESP is applied to traffic on this SA.

Stateful Fragment Checking Flag​

Indicates whether or not stateful fragment checking applies to this SA.

Bypass DF Bit (T/F)​

Applicable to tunnel mode SAs where both inner and outer headers are IPv4.

DSCP Values​

The set of DSCP values allowed for packets carried over this SA. If no values are specified, no DSCP-specific filtering is applied. If one or more values are specified, these are used to select one SA among several that match the traffic selectors for an outbound packet. Note that these values are NOT checked against inbound traffic arriving on the SA.

Bypass DSCP (T/F) or Map to Unprotected DSCP Values​

Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values -- applicable to tunnel mode SAs. This feature maps DSCP values from an inner header to values in an outer header, e.g., to address covert channel signaling concerns.

Path MTU​

Any observed path MTU and aging variables.

Tunnel Header IP Source and Destination Address​

Both addresses must be either IPv4 or IPv6 addresses. The version implies the type of IP header to be used. Only used when the IPsec protocol mode is tunnel.

Last updated on