Request for Comments: 4303 BBN Technologies
Obsoletes: 2406 December 2005
Category: Standards Track
IP Encapsulating Security Payload (ESP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes an updated version of the Encapsulating
Security Payload (ESP) protocol, which is designed to provide a mix
of security services in IPv4 and IPv6. ESP is used to provide
confidentiality, data origin authentication, connectionless
integrity, an anti-replay service (a form of partial sequence
integrity), and limited traffic flow confidentiality. This document
obsoletes RFC 2406 (November 1998).
Table of Contents
1. Introduction ....................................................3
2. Encapsulating Security Payload Packet Format ....................5
2.1. Security Parameters Index (SPI) ...........................10
2.2. Sequence Number ...........................................12
2.2.1. Extended (64-bit) Sequence Number ..................12
2.3. Payload Data ..............................................13
2.4. Padding (for Encryption) ..................................14
2.5. Pad Length ................................................15
2.6. Next Header ...............................................16
2.7. Traffic Flow Confidentiality (TFC) Padding ................17
2.8. Integrity Check Value (ICV) ...............................17
3. Encapsulating Security Protocol Processing .....................18
3.1. ESP Header Location .......................................18
3.1.1. Transport Mode Processing ..........................18
3.1.2. Tunnel Mode Processing .............................19
3.2. Algorithms ................................................20
3.2.1. Encryption Algorithms ..............................21
3.2.2. Integrity Algorithms ...............................21
3.2.3. Combined Mode Algorithms ...........................22
3.3. Outbound Packet Processing ................................22
3.3.1. Security Association Lookup ........................22
3.3.2. Packet Encryption and Integrity Check Value
(ICV) Calculation ..................................22
3.3.2.1. Separate Confidentiality and
Integrity Algorithms ......................23
3.3.2.2. Combined Confidentiality and
Integrity Algorithms ......................24
3.3.3. Sequence Number Generation .........................25
3.3.4. Fragmentation ......................................26
3.4. Inbound Packet Processing .................................27
3.4.1. Reassembly .........................................27
3.4.2. Security Association Lookup ........................27
3.4.3. Sequence Number Verification .......................28
3.4.4. Integrity Check Value Verification .................30
3.4.4.1. Separate Confidentiality and
Integrity Algorithms ......................30
3.4.4.2. Combined Confidentiality and
Integrity Algorithms ......................32
4. Auditing .......................................................33
5. Conformance Requirements .......................................34
6. Security Considerations ........................................34
7. Differences from RFC 2406 ......................................34
8. Backward-Compatibility Considerations ..........................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
Appendix A: Extended (64-bit) Sequence Numbers ....................38
A1. Overview ...................................................38
A2. Anti-Replay Window .........................................38
A2.1. Managing and Using the Anti-Replay Window ............39
A2.2. Determining the Higher-Order Bits (Seqh) of the
Sequence Number ......................................40
A2.3. Pseudo-Code Example ..................................41
A3. Handling Loss of Synchronization due to Significant
Packet Loss ................................................42
A3.1. Triggering Re-synchronization ........................43
A3.2. Re-synchronization Process ...........................43
1. Introduction
This document assumes that the reader is familiar with the terms and
concepts described in the "Security Architecture for the Internet
Protocol" [Ken-Arch], hereafter referred to as the Security
Architecture document. In particular, the reader should be familiar
with the definitions of security services offered by the
Encapsulating Security Payload (ESP) and the IP Authentication Header
(AH), the concept of Security Associations, the ways in which ESP can
be used in conjunction with AH, and the different key management
options available for ESP and AH.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [Bra97].
The Encapsulating Security Payload (ESP) header is designed to
provide a mix of security services in IPv4 and IPv6 [DH98]. ESP may
be applied alone, in combination with AH [Ken-AH], or in a nested
fashion (see the Security Architecture document [Ken-Arch]).
Security services can be provided between a pair of communicating
hosts, between a pair of communicating security gateways, or between
a security gateway and a host. For more details on how to use ESP
and AH in various network environments, see the Security Architecture
document [Ken-Arch].
The ESP header is inserted after the IP header and before the next
layer protocol header (transport mode) or before an encapsulated IP
header (tunnel mode). These modes are described in more detail
below.
ESP can be used to provide confidentiality, data origin
authentication, connectionless integrity, an anti-replay service (a
form of partial sequence integrity), and (limited) traffic flow
confidentiality. The set of services provided depends on options
selected at the time of Security Association (SA) establishment and
on the location of the implementation in a network topology.
Using encryption-only for confidentiality is allowed by ESP.
However, it should be noted that in general, this will provide
defense only against passive attackers. Using encryption without a
strong integrity mechanism on top of it (either in ESP or separately
via AH) may render the confidentiality service insecure against some
forms of active attacks [Bel96, Kra01]. Moreover, an underlying
integrity service, such as AH, applied before encryption does not
necessarily protect the encryption-only confidentiality against
active attackers [Kra01]. ESP allows encryption-only SAs because
this may offer considerably better performance and still provide
adequate security, e.g., when higher-layer authentication/integrity
protection is offered independently. However, this standard does not
require ESP implementations to offer an encryption-only service.
Data origin authentication and connectionless integrity are joint
services, hereafter referred to jointly as "integrity". (This term
is employed because, on a per-packet basis, the computation being
performed provides connectionless integrity directly; data origin
authentication is provided indirectly as a result of binding the key
used to verify the integrity to the identity of the IPsec peer.
Typically, this binding is effected through the use of a shared,
symmetric key.) Integrity-only ESP MUST be offered as a service
selection option, e.g., it must be negotiable in SA management
protocols and MUST be configurable via management interfaces.
Integrity-only ESP is an attractive alternative to AH in many
contexts, e.g., because it is faster to process and more amenable to
pipelining in many implementations.
Although confidentiality and integrity can be offered independently,
ESP typically will employ both services, i.e., packets will be
protected with regard to confidentiality and integrity. Thus, there
are three possible ESP security service combinations involving these
services:
- confidentiality-only (MAY be supported)
- integrity only (MUST be supported)
- confidentiality and integrity (MUST be supported)
The anti-replay service may be selected for an SA only if the
integrity service is selected for that SA. The selection of this
service is solely at the discretion of the receiver and thus need not
be negotiated. However, to make use of the Extended Sequence Number
feature in an interoperable fashion, ESP does impose a requirement on
SA management protocols to be able to negotiate this feature (see
Section 2.2.1 below).
The traffic flow confidentiality (TFC) service generally is effective
only if ESP is employed in a fashion that conceals the ultimate
source and destination addresses of correspondents, e.g., in tunnel
mode between security gateways, and only if sufficient traffic flows
between IPsec peers (either naturally or as a result of generation of
masking traffic) to conceal the characteristics of specific,
individual subscriber traffic flows. (ESP may be employed as part of
a higher-layer TFC system, e.g., Onion Routing [Syverson], but such
systems are outside the scope of this standard.) New TFC features
present in ESP facilitate efficient generation and discarding of
dummy traffic and better padding of real traffic, in a backward-
compatible fashion.
Section 7 provides a brief review of the differences between this
document and RFC 2406.
2. Encapsulating Security Payload Packet Format
The (outer) protocol header (IPv4, IPv6, or Extension) that
immediately precedes the ESP header SHALL contain the value 50 in its
Protocol (IPv4) or Next Header (IPv6, Extension) field (see IANA web
page at http://www.iana.org/assignments/protocol-numbers). Figure 1
illustrates the top-level format of an ESP packet. The packet begins
with two 4-byte fields (Security Parameters Index (SPI) and Sequence
Number). Following these fields is the Payload Data, which has
substructure that depends on the choice of encryption algorithm and
mode, and on the use of TFC padding, which is examined in more detail
later. Following the Payload Data are Padding and Pad Length fields,
and the Next Header field. The optional Integrity Check Value (ICV)
field completes the packet.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Top-Level Format of an ESP Packet
* If included in the Payload field, cryptographic synchronization
data, e.g., an Initialization Vector (IV, see Section 2.3),
usually is not encrypted per se, although it often is referred
to as being part of the ciphertext.
The (transmitted) ESP trailer consists of the Padding, Pad Length,
and Next Header fields. Additional, implicit ESP trailer data (which
is not transmitted) is included in the integrity computation, as
described below.
If the integrity service is selected, the integrity computation
encompasses the SPI, Sequence Number, Payload Data, and the ESP
trailer (explicit and implicit).
If the confidentiality service is selected, the ciphertext consists
of the Payload Data (except for any cryptographic synchronization
data that may be included) and the (explicit) ESP trailer.
As noted above, the Payload Data may have substructure. An
encryption algorithm that requires an explicit Initialization Vector
(IV), e.g., Cipher Block Chaining (CBC) mode, often prefixes the
Payload Data to be protected with that value. Some algorithm modes
combine encryption and integrity into a single operation; this
document refers to such algorithm modes as "combined mode
algorithms". Accommodation of combined mode algorithms requires that
the algorithm explicitly describe the payload substructure used to
convey the integrity data.
Some combined mode algorithms provide integrity only for data that is
encrypted, whereas others can provide integrity for some additional
data that is not encrypted for transmission. Because the SPI and
Sequence Number fields require integrity as part of the integrity
service, and they are not encrypted, it is necessary to ensure that
they are afforded integrity whenever the service is selected,
regardless of the style of combined algorithm mode employed.
When any combined mode algorithm is employed, the algorithm itself is
expected to return both decrypted plaintext and a pass/fail
indication for the integrity check. For combined mode algorithms,
the ICV that would normally appear at the end of the ESP packet (when
integrity is selected) may be omitted. When the ICV is omitted and
integrity is selected, it is the responsibility of the combined mode
algorithm to encode within the Payload Data an ICV-equivalent means
of verifying the integrity of the packet.
If a combined mode algorithm offers integrity only to data that is
encrypted, it will be necessary to replicate the SPI and Sequence
Number as part of the Payload Data.
Finally, a new provision is made to insert padding for traffic flow
confidentiality after the Payload Data and before the ESP trailer.
Figure 2 illustrates this substructure for Payload Data. (Note: This
diagram shows bits-on-the-wire. So even if extended sequence numbers
are being used, only 32 bits of the Sequence Number will be
transmitted (see Section 2.2.1).)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (optional) | ^ p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| Rest of Payload Data (variable) | | y
~ ~ | l
| | | o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| | TFC Padding * (optional, variable) | v d
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Substructure of Payload Data
* If tunnel mode is being used, then the IPsec implementation
can add Traffic Flow Confidentiality (TFC) padding (see
Section 2.4) after the Payload Data and before the Padding
(0-255 bytes) field.
If a combined algorithm mode is employed, the explicit ICV shown in
Figures 1 and 2 may be omitted (see Section 3.3.2.2 below). Because
algorithms and modes are fixed when an SA is established, the
detailed format of ESP packets for a given SA (including the Payload
Data substructure) is fixed, for all traffic on the SA.
The tables below refer to the fields in the preceding figures and
illustrate how several categories of algorithmic options, each with a
different processing model, affect the fields noted above. The
processing details are described in later sections.
Table 1. Separate Encryption and Integrity Algorithms
What What What
# of Requ’d Encrypt Integ is
bytes [1] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI 4 M Y plain
Seq# (low-order bits) 4 M Y plain p
------ a
IV variable O Y plain | y
IP datagram [2] variable M or D Y Y cipher[3] |-l
TFC padding [4] variable O Y Y cipher[3] | o
------ a
Padding 0-255 M Y Y cipher[3] d
Pad Length 1 M Y Y cipher[3]
Next Header 1 M Y Y cipher[3]
Seq# (high-order bits) 4 if ESN [5] Y not xmtd
ICV Padding variable if need Y not xmtd
ICV variable M [6] plain
[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram
If transport mode -> next header and data
[3] ciphertext if encryption has been selected
[4] Can be used only if payload specifies its "real" length
[5] See section 2.2.1
[6] mandatory if a separate integrity algorithm is used
Table 2. Combined Mode Algorithms
What What What
# of Requ’d Encrypt Integ is
bytes [1] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI 4 M plain
Seq# (low-order bits) 4 M plain p
--- a
IV variable O Y plain | y
IP datagram [2] variable M or D Y Y cipher |-l