Security Architecture for the Internet Protocol
obsoletes
- rfc-2401 — Security Architecture for the Internet Protocol
updated by
- rfc-6040 — Tunnelling of Explicit Congestion Notification
- rfc-7619 — The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)
updates
- rfc-3168 — The Addition of Explicit Congestion Notification (ECN) to IP
Extracted elements (29)
IPsec security protocols are designed to be cryptographic algorithm-independent. Mandatory and default algorithms are specified in separate RFCs so they can be updated without affecting the standardization status of AH, ESP, or IKEv2 specifications, enabling timely response to cryptanalytic advances.
SA bundles (iterated application of multiple SAs) are no longer a required architectural element. Nested SAs can be achieved by coordinating SPD entries with IP forwarding tables to cause packets to traverse the IPsec boundary more than once, but this is outside the IPsec module scope and thus potentially harder to manage.
SPD decorrelation separates overlapping policy entries into non-overlapping entries to enable caching of SPD lookups, which is critical for performance in security gateways and BITS/BITW implementations. Native host implementations implicitly cache via socket-to-SA binding and may not need decorrelation.
Tunnel mode is required when either end of an SA is a security gateway because: (a) packets must reach the specific gateway with which the SA was negotiated; (b) all fragments must be delivered to the same IPsec instance for reassembly; (c) inner/outer headers are needed to retain fragmentation state across the IPsec processing boundary.
AH and ESP cannot be applied in transport mode to IPv4 fragments; only tunnel mode can be used for fragmented IPv4 packets. For simplicity, the same restriction applies to IPv6, even though IPv6 would technically permit carrying a plaintext fragment on a transport mode SA.
IKEv2 (as published concurrently) does not enable negotiation of a single SA binding multiple pairs of local/remote addresses and ports; instead it treats multiple addresses as unordered sets that can be arbitrarily paired. Users MUST NOT include multiple selector sets in an SPD entry unless the intent aligns with IKE 'mix and match' semantics.
A host implementation of IPsec MUST support both transport and tunnel mode. A security gateway MUST support tunnel mode and MAY support transport mode, with transport mode permitted only when the gateway acts as a host.
A sender SHOULD put traffic of different DSCP classes but with the same selector values on different SAs to support QoS appropriately. The IPsec implementation MUST permit establishment of multiple SAs between a given sender and receiver with the same selectors.
Every IPsec implementation MUST have a management interface for the SPD that allows ordering of entries and creation of entries consistent with the defined selectors. The system administrator MUST be able to control whether users or applications can override system policies.
If a multicast-capable IPsec implementation encounters SPI collisions between a GSA and a unicast SA (possible when a Group Controller/Key Server assigns SPIs unilaterally), it MUST correctly de-multiplex inbound traffic.
IPsec implementations MUST support ESP and MAY support AH. AH support was downgraded to MAY because ESP can provide integrity without confidentiality, making it functionally comparable to AH in most contexts.
Named SPD entries used by a responder for access control (e.g., for road warriors) MUST be supported by all IPsec implementations. The name communicated via IKE in the ID payload is bound to the Remote IP address in the SAD entry created by the negotiation.
Use of ESP to provide confidentiality without integrity is NOT RECOMMENDED. An ESP SA that employs both NULL encryption and no integrity algorithm MUST NOT be instantiated; an attempt to negotiate such an SA is an auditable event.
Whenever either end of a security association is a security gateway, the SA MUST be tunnel mode, with two exceptions: when the security gateway is acting as a host (e.g., for SNMP) and when providing security between two intermediate systems along a path.
A Security Association (SA) is a simplex connection providing security services via AH or ESP (not both). Bidirectional communication requires a pair of SAs. An SA is identified by an SPI, optionally combined with destination address and/or source address for lookup purposes.
ICMP error messages received on the unprotected side are forwarded to the IPsec implementation, which may use the embedded original datagram header to correlate with an SA. ICMP messages received on the protected side are processed normally. Protected transit ICMP messages must be examined to apply access control.
Non-initial IP fragments lack port/ICMP-type/MH-type selector fields. RFC 4301 defines three handling models: (1) tunnel mode SAs carrying all fragments; (2) separate tunnel mode SAs for non-initial fragments; (3) stateful fragment checking. If an SA requires non-ANY port selectors, arriving non-initial fragments MUST be discarded.
Path MTU handling requires that IPsec respect the DF bit per SPD policy (copy, clear, or set) and that PMTU discovery information propagate appropriately. PMTU values associated with an SA are subject to aging to recover from stale low-MTU information.
SPD selectors that MUST be supported include Remote IP Address(es), Local IP Address(es), Next Layer Protocol, Local Port/ICMP type+code/MH type, and Remote Port/ICMP type+code/MH type. Each selector supports ranges, lists of ranges, and the special values ANY and OPAQUE.
The Peer Authorization Database (PAD) provides a link between an SA management protocol (IKE) and the SPD. Each PAD entry identifies a peer, specifies the authentication method and data, and authorizes the set of child SAs the peer may create. It is consulted to authenticate peers and verify SA proposals.
The 'populate from packet' (PFP) flag in an SPD-S entry controls SA selector granularity: if set for selector X, the new SA takes its value for X from the triggering packet; otherwise it takes the (potentially broader) range from the SPD entry. This allows fine- or coarse-grained SA creation from the same policy entry.
The Security Association Database (SAD) stores parameters for each established SA, including SPI, AH/ESP algorithm identifiers and keys, sequence number counter, anti-replay window, SA lifetime, IPsec mode, tunnel endpoint addresses, and DSCP/DF bit handling flags.
The Security Policy Database (SPD) is an ordered database logically divided into SPD-S (IPsec-protected traffic), SPD-I (inbound bypassed/discarded traffic), and SPD-O (outbound bypassed/discarded traffic). Each entry specifies DISCARD, BYPASS, or PROTECT action keyed by a set of traffic selectors.
The security afforded by IPsec ultimately depends on the quality of its implementation and the operating environment: defects in OS security, poor random number sources, insecure system management protocols, and other environmental factors outside the scope of the IPsec standards can all degrade protection. IPsec is only one part of an overall system security architecture.
Inbound packet processing: IPsec-protected packets undergo SAD lookup by SPI (and optionally destination/source address), cryptographic verification, and anti-replay check. After decryption/authentication, the inner packet is checked against SPD policy to confirm it was appropriately protected. Unprotected packets are checked against SPD-I for BYPASS authorization.
Inbound SA lookup proceeds in three ordered steps: (1) match SPI + destination + source address; (2) match SPI + destination address; (3) match SPI alone (or SPI + protocol if separate AH/ESP SPI spaces). The first matching SAD entry is used; if none matches, the packet is discarded and an auditable event is logged.
Outbound packet processing: (1) look up SPD using selectors; (2) if DISCARD, drop packet; (3) if BYPASS, forward without IPsec; (4) if PROTECT, look for a matching SA in the SAD; (5) if no SA exists, invoke IKE to create one; (6) apply AH or ESP per the SA parameters and forward the protected packet.
For tunnel mode IPv4 headers (Section 5.1.2.1), the outer header's TTL, TOS, DF bit, and fragmentation fields are derived from the inner header or SPD configuration. The outer destination address is the remote tunnel endpoint; the outer source address is the local tunnel endpoint.
In tunnel mode, an outer IP header specifying the IPsec endpoints wraps the original packet; the AH or ESP security protocol header appears after the outer IP header and before the inner IP header. In IPv4 transport mode, the security protocol header appears immediately after the IP header and any options, before TCP/UDP.