Security Architecture for the Internet Protocol
obsoleted by
- rfc-4301 — Security Architecture for the Internet Protocol
obsoletes
- rfc-1825 — Security Architecture for the Internet Protocol
updated by
- rfc-3168 — The Addition of Explicit Congestion Notification (ECN) to IP
Extracted elements (30)
Fine-granularity SAs (e.g., per-session keying) are generally more vulnerable to traffic analysis than coarse-granularity ones carrying traffic from many subscribers, because an observer can more easily correlate traffic patterns to specific communications.
IPsec is designed to be algorithm-independent so that different user communities can select different algorithm sets (creating cliques if required). A standard set of default algorithms is specified to facilitate interoperability in the global Internet while retaining modularity.
The SPI value is normally selected by the destination (receiver) system rather than the sender. This design ensures that manually configured SAs cannot conflict with automatically configured SAs, and that SAs from multiple sources cannot conflict with each other at the same destination.
Tunnel mode is required for any transit SA involving a security gateway to avoid fragmentation and reassembly problems with IPsec packets, and to handle situations where multiple paths via different security gateways exist to the same destination behind those gateways.
Bump-in-the-stack (BITS) and bump-in-the-wire (BITW) implementation approaches allow IPsec deployment without access to the native IP stack source code; BITW devices are typically IP-addressable and must operate as a security gateway when supporting a router or firewall.
The SPD and SAD selector model must support 'OPAQUE' values for transport layer protocol, source/destination ports, and user ID fields, because these may be inaccessible in received ESP packets due to encryption; implementations SHOULD support OPAQUE for port and transport protocol selectors.
A compliant implementation MUST NOT allow instantiation of an ESP SA that employs both a NULL encryption and a NULL authentication algorithm. An attempt to negotiate such an SA is an auditable event.
A compliant implementation MUST support both time-based and byte-count-based SA lifetimes and MUST support simultaneous use of both (the first to expire takes precedence). When IKE uses X.509 certificates, the SA lifetime must be constrained by certificate validity intervals and the NextIssueDate of CRLs used in the IKE exchange.
A host MUST support both transport and tunnel mode. A security gateway is required to support only tunnel mode; if it supports transport mode, that should be used only when the gateway is acting as a host (e.g., for network management).
A host or security gateway MUST have an administrative interface that allows configuration of the address of a relevant security gateway for destination addresses requiring its use, including authentication information and backup gateway information needed to verify the gateway's authorization to represent the destination host.
For ESP, although both confidentiality and authentication are optional, they cannot both be omitted. At least one MUST be selected; it MUST NOT be possible to configure both the encryption and authentication algorithms as NULL.
For every IPsec implementation there MUST be an administrative interface that allows a user or system administrator to manage the SPD. The management interface MUST allow creation of entries consistent with the defined selectors and MUST support total ordering of entries.
Four SA combination cases MUST be supported by compliant IPsec hosts or security gateways: (1) end-to-end host-to-host, (2) security gateway-to-gateway VPN tunnel, (3) nested end-to-end plus gateway-to-gateway, and (4) remote host tunneling to a security gateway with an end-to-end SA to an internal host.
If no policy is found in the SPD that matches a packet (for either inbound or outbound traffic), the packet MUST be discarded.
In transport mode, if both AH and ESP are applied, AH SHOULD appear as the first header after IP, prior to ESP, so that AH covers the ciphertext output of ESP.
IPsec mandates support for both manual and automated SA and cryptographic key management. The default automated key management protocol is IKE; other automated SA management protocols MAY be employed.
Multiple senders to a multicast group SHOULD use a single Security Association (and hence SPI) for all traffic to that group when a symmetric key encryption or authentication algorithm is employed, as data origin authentication of individual senders is not achievable in this context.
SPD entries MUST be ordered and the SPD MUST always be searched in the same order so that the first matching entry is consistently selected; this ensures deterministic processing in the presence of wildcard selector overlap.
When a single bit string is generated for multiple keys, the encryption key(s) MUST be taken from the first (leftmost, high-order) bits and the authentication key(s) MUST be taken from the remaining bits, ensuring consistent key derivation at both SA endpoints.
Whenever either end of a security association is a security gateway, the SA MUST be tunnel mode. Thus any SA between two security gateways, or between a host and a security gateway carrying transit traffic, is always tunnel mode.
A Security Association (SA) is a simplex 'connection' that affords security services using either AH or ESP but not both. An SA is uniquely identified by a triple: Security Parameter Index (SPI), IP Destination Address, and security protocol (AH or ESP). Two SAs (one in each direction) are required for typical bidirectional communication.
PMTU (Path MTU Discovery) state is maintained per SA in the SAD. An SA entry stores observed path MTU and aging variables; the DF bit handling and PMTU propagation are separate considerations for tunnel-mode IPsec to avoid blackholing when inner packets exceed the path MTU.
SA bundles are sequences of SAs through which traffic must be processed to satisfy a security policy requiring a combination of services not achievable with a single SA. Two combination approaches are defined: transport adjacency (multiple protocols without tunneling) and iterated tunneling (multiple layers via IP tunneling).
SA selectors determine the granularity of a security association. Required selector types for all implementations include: Destination IP Address, Source IP Address, Transport Layer Protocol, and Source/Destination Ports. Name (user ID or system name) is required for host and gateway implementations. Selectors may be single values, ranges, wildcards, or 'OPAQUE' when fields are inaccessible due to encryption or fragmentation.
The anti-replay window is a 32-bit counter and bitmap used to determine whether an inbound AH or ESP packet is a replay. It is required for all implementations but used only for inbound traffic; if anti-replay is disabled (e.g., for manually keyed SAs), the window is not used.
The Security Association Database (SAD) stores parameters for each active SA. For inbound lookup the SAD is indexed by: Destination IP Address, IPsec Protocol (AH or ESP), and SPI. Each entry holds cryptographic algorithm parameters and keys, sequence number counter, anti-replay window, SA lifetime, protocol mode, and path MTU.
The Security Policy Database (SPD) specifies what security services are to be offered to IP datagrams. For any datagram, three processing choices are possible: discard, bypass IPsec, or apply IPsec. The SPD contains an ordered list of policy entries keyed by selectors, and must be consulted for all inbound and outbound traffic.
The security afforded by IPsec is critically dependent on the quality of implementation and the operating environment, including OS security, quality of random number sources, and system management practices—none of which are within the scope of IPsec standards. IPsec is only one part of an overall system security architecture.
Outbound IPsec processing follows three steps: (1) match packet selectors against the ordered outbound SPD to find the first matching policy; (2) match against SA bundles in the SAD, creating a new SA bundle via key management if none exists; (3) apply the SA bundle to perform the required IPsec processing. If no key management entity is found at step 2, drop the packet.
For IPv4 tunnel mode, the outer IP header is independently constructed: version=4, TOS copied from inner header, TTL constructed (inner TTL decremented by the encapsulator before forwarding), Protocol set to AH or ESP, src/dst addresses from the SA endpoints, and IP options are never copied from the inner header.