[RFCs/IDs] [Plain Text] [From draft-ietf-ipsec-esp-v3]
PROPOSED STANDARD
Errata
Network Working Group S. Kent
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
Kent Standards Track [Page 1]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
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
Kent Standards Track [Page 2]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
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
Kent Standards Track [Page 3]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
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.
Kent Standards Track [Page 4]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
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.
Kent Standards Track [Page 5]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
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
Kent Standards Track [Page 6]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
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.
Kent Standards Track [Page 7]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
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
Kent Standards Track [Page 8]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
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
TFC padding [3] variable O Y Y cipher | o
--- a
Padding 0-255 M Y Y cipher d
Pad Length 1 M Y Y cipher
Next Header 1 M Y Y cipher
Seq# (high-order bits) 4 if ESN [4] Y [5]
ICV Padding variable if need Y [5]
ICV variable O [6] plain
[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram
If transport mode -> next header and data
[3] Can be used only if payload specifies its "real" length
[4] See Section 2.2.1
[5] The algorithm choices determines whether these are
transmitted, but in either case, the result is invisible
to ESP
[6] The algorithm spec determines whether this field is
present
The following subsections describe the fields in the header format.
"Optional" means that the field is omitted if the option is not
selected, i.e., it is present in neither the packet as transmitted
nor as formatted for computation of an ICV (see Section 2.7).
Whether or not an option is selected is determined as part of
Security Association (SA) establishment. Thus, the format of ESP
packets for a given SA is fixed, for the duration of the SA. In
contrast, "mandatory" fields are always present in the ESP packet
format, for all SAs.
Note: All of the cryptographic algorithms used in IPsec expect their
input in canonical network byte order (see Appendix of RFC 791
[Pos81]) and generate their output in canonical network byte order.
IP packets are also transmitted in network byte order.
Kent Standards Track [Page 9]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
ESP does not contain a version number, therefore if there are
concerns about backward compatibility, they MUST be addressed by
using a signaling mechanism between the two IPsec peers to ensure
compatible versions of ESP (e.g., Internet Key Exchange (IKEv2)
[Kau05]) or an out-of-band configuration mechanism.
2.1. Security Parameters Index (SPI)
The SPI is an arbitrary 32-bit value that is used by a receiver to
identify the SA to which an incoming packet is bound. The SPI field
is mandatory.
For a unicast SA, the SPI can be used by itself to specify an SA, or
it may be used in conjunction with the IPsec protocol type (in this
case ESP). Because the SPI value is generated by the receiver for a
unicast SA, whether the value is sufficient to identify an SA by
itself or whether it must be used in conjunction with the IPsec
protocol value is a local matter. This mechanism for mapping inbound
traffic to unicast SAs MUST be supported by all ESP implementations.
If an IPsec implementation supports multicast, then it MUST support
multicast SAs using the algorithm below for mapping inbound IPsec
datagrams to SAs. Implementations that support only unicast traffic
need not implement this de-multiplexing algorithm.
In many secure multicast architectures (e.g., [RFC3740]), a central
Group Controller/Key Server unilaterally assigns the group security
association's SPI. This SPI assignment is not negotiated or
coordinated with the key management (e.g., IKE) subsystems that
reside in the individual end systems that comprise the group.
Consequently, it is possible that a group security association and a
unicast security association can simultaneously use the same SPI. A
multicast-capable IPsec implementation MUST correctly de-multiplex
inbound traffic even in the context of SPI collisions.
Each entry in the Security Association Database (SAD) [Ken-Arch] must
indicate whether the SA lookup makes use of the destination, or
destination and source, IP addresses, in addition to the SPI. For
multicast SAs, the protocol field is not employed for SA lookups.
For each inbound, IPsec-protected packet, an implementation must
conduct its search of the SAD such that it finds the entry that
matches the "longest" SA identifier. In this context, if two or more
SAD entries match based on the SPI value, then the entry that also
matches based on destination, or destination and source, address
comparison (as indicated in the SAD entry) is the "longest" match.
This implies a logical ordering of the SAD search as follows:
Kent Standards Track [Page 10]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
1. Search the SAD for a match on {SPI, destination address,
source address}. If an SAD entry matches, then process the
inbound ESP packet with that matching SAD entry. Otherwise,
proceed to step 2.
2. Search the SAD for a match on {SPI, destination address}.
If the SAD entry matches, then process the inbound ESP
packet with that matching SAD entry. Otherwise, proceed to
step 3.
3. Search the SAD for a match on only {SPI} if the receiver has
chosen to maintain a single SPI space for AH and ESP, or on
{SPI, protocol} otherwise. If an SAD entry matches, then
process the inbound ESP packet with that matching SAD entry.
Otherwise, discard the packet and log an auditable event.
In practice, an implementation MAY choose any method to accelerate
this search, although its externally visible behavior MUST be
functionally equivalent to having searched the SAD in the above
order. For example, a software-based implementation could index into
a hash table by the SPI. The SAD entries in each hash table bucket's
linked list are kept sorted to have those SAD entries with the
longest SA identifiers first in that linked list. Those SAD entries
having the shortest SA identifiers are sorted so that they are the
last entries in the linked list. A hardware-based implementation may
be able to effect the longest match search intrinsically, using
commonly available Ternary Content-Addressable Memory (TCAM)
features.
The indication of whether source and destination address matching is
required to map inbound IPsec traffic to SAs MUST be set either as a
side effect of manual SA configuration or via negotiation using an SA
management protocol, e.g., IKE or Group Domain of Interpretation
(GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03]
groups use a 3-tuple SA identifier composed of an SPI, a destination
multicast address, and source address. An Any-Source Multicast group
SA requires only an SPI and a destination multicast address as an
identifier.
The set of SPI values in the range 1 through 255 are reserved by the
Internet Assigned Numbers Authority (IANA) for future use; a reserved
SPI value will not normally be assigned by IANA unless the use of the
assigned SPI value is specified in an RFC. The SPI value of zero (0)
is reserved for local, implementation-specific use and MUST NOT be
sent on the wire. (For example, a key management implementation
might use the zero SPI value to mean "No Security Association Exists"
Kent Standards Track [Page 11]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
during the period when the IPsec implementation has requested that
its key management entity establish a new SA, but the SA has not yet
been established.)
2.2. Sequence Number
This unsigned 32-bit field contains a counter value that increases by
one for each packet sent, i.e., a per-SA packet sequence number. For
a unicast SA or a single-sender multicast SA, the sender MUST
increment this field for every transmitted packet. Sharing an SA
among multiple senders is permitted, though generally not
recommended. ESP provides no means of synchronizing packet counters
among multiple senders or meaningfully managing a receiver packet
counter and window in the context of multiple senders. Thus, for a
multi-sender SA, the anti-replay features of ESP are not available
(see Sections 3.3.3 and 3.4.3.)
The field is mandatory and MUST always be present even if the
receiver does not elect to enable the anti-replay service for a
specific SA. Processing of the Sequence Number field is at the
discretion of the receiver, but all ESP implementations MUST be
capable of performing the processing described in Sections 3.3.3 and
3.4.3. Thus, the sender MUST always transmit this field, but the
receiver need not act upon it (see the discussion of Sequence Number
Verification in the "Inbound Packet Processing" section (3.4.3)
below).
The sender's counter and the receiver's counter are initialized to 0
when an SA is established. (The first packet sent using a given SA
will have a sequence number of 1; see Section 3.3.3 for more details
on how the sequence number is generated.) If anti-replay is enabled
(the default), the transmitted sequence number must never be allowed
to cycle. Thus, the sender's counter and the receiver's counter MUST
be reset (by establishing a new SA and thus a new key) prior to the
transmission of the 2^32nd packet on an SA.
2.2.1. Extended (64-bit) Sequence Number
To support high-speed IPsec implementations, Extended Sequence
Numbers (ESNs) SHOULD be implemented, as an extension to the current,
32-bit sequence number field. Use of an ESN MUST be negotiated by an
SA management protocol. Note that in IKEv2, this negotiation is
implicit; the default is ESN unless 32-bit sequence numbers are
explicitly negotiated. (The ESN feature is applicable to multicast
as well as unicast SAs.)
Kent Standards Track [Page 12]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
The ESN facility allows use of a 64-bit sequence number for an SA.
(See Appendix A, "Extended (64-bit) Sequence Numbers", for details.)
Only the low-order 32 bits of the sequence number are transmitted in
the plaintext ESP header of each packet, thus minimizing packet
overhead. The high-order 32 bits are maintained as part of the
sequence number counter by both transmitter and receiver and are
included in the computation of the ICV (if the integrity service is
selected). If a separate integrity algorithm is employed, the high
order bits are included in the implicit ESP trailer, but are not
transmitted, analogous to integrity algorithm padding bits. If a
combined mode algorithm is employed, the algorithm choice determines
whether the high-order ESN bits are transmitted or are included
implicitly in the computation. See Section 3.3.2.2 for processing
details.
2.3. Payload Data
Payload Data is a variable-length field containing data (from the
original IP packet) described by the Next Header field. The Payload
Data field is mandatory and is an integral number of bytes in length.
If the algorithm used to encrypt the payload requires cryptographic
synchronization data, e.g., an Initialization Vector (IV), then this
data is carried explicitly in the Payload field, but it is not called
out as a separate field in ESP, i.e., the transmission of an explicit
IV is invisible to ESP. (See Figure 2.) Any encryption algorithm
that requires such explicit, per-packet synchronization data MUST
indicate the length, any structure for such data, and the location of
this data as part of an RFC specifying how the algorithm is used with
ESP. (Typically, the IV immediately precedes the ciphertext. See
Figure 2.) If such synchronization data is implicit, the algorithm
for deriving the data MUST be part of the algorithm definition RFC.
(If included in the Payload field, cryptographic synchronization
data, e.g., an Initialization Vector (IV), usually is not encrypted
per se (see Tables 1 and 2), although it sometimes is referred to as
being part of the ciphertext.)
Note that the beginning of the next layer protocol header MUST be
aligned relative to the beginning of the ESP header as follows. For
IPv4, this alignment is a multiple of 4 bytes. For IPv6, the
alignment is a multiple of 8 bytes.
With regard to ensuring the alignment of the (real) ciphertext in the
presence of an IV, note the following:
o For some IV-based modes of operation, the receiver treats
the IV as the start of the ciphertext, feeding it into the
algorithm directly. In these modes, alignment of the start
of the (real) ciphertext is not an issue at the receiver.
Kent Standards Track [Page 13]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
o In some cases, the receiver reads the IV in separately from
the ciphertext. In these cases, the algorithm specification
MUST address how alignment of the (real) ciphertext is to be
achieved.
2.4. Padding (for Encryption)
Two primary factors require or motivate use of the Padding field.
o If an encryption algorithm is employed that requires the
plaintext to be a multiple of some number of bytes, e.g.,
the block size of a block cipher, the Padding field is used
to fill the plaintext (consisting of the Payload Data,
Padding, Pad Length, and Next Header fields) to the size
required by the algorithm.
o Padding also may be required, irrespective of encryption
algorithm requirements, to ensure that the resulting
ciphertext terminates on a 4-byte boundary. Specifically,
the Pad Length and Next Header fields must be right aligned
within a 4-byte word, as illustrated in the ESP packet
format figures above, to ensure that the ICV field (if
present) is aligned on a 4-byte boundary.
Padding beyond that required for the algorithm or alignment reasons
cited above could be used to conceal the actual length of the
payload, in support of TFC. However, the Padding field described is
too limited to be effective for TFC and thus should not be used for
that purpose. Instead, the separate mechanism described below (see
Section 2.7) should be used when TFC is required.
The sender MAY add 0 to 255 bytes of padding. Inclusion of the
Padding field in an ESP packet is optional, subject to the
requirements noted above, but all implementations MUST support
generation and consumption of padding.
o For the purpose of ensuring that the bits to be encrypted
are a multiple of the algorithm's block size (first bullet
above), the padding computation applies to the Payload Data
exclusive of any IV, but including the ESP trailer
fields. If a combined algorithm mode requires transmission
of the SPI and Sequence Number to effect integrity, e.g.,
replication of the SPI and Sequence Number in the Payload
Data, then the replicated versions of these data items, and
any associated, ICV-equivalent data, are included in the
computation of the pad length. (If the ESN option is
Kent Standards Track [Page 14]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
selected, the high-order 32 bits of the ESN also would enter
into the computation, if the combined mode algorithm
requires their transmission for integrity.)
o For the purposes of ensuring that the ICV is aligned on a
4-byte boundary (second bullet above), the padding
computation applies to the Payload Data inclusive of the IV,
the Pad Length, and Next Header fields. If a combined mode
algorithm is used, any replicated data and ICV-equivalent
data are included in the Payload Data covered by the padding
computation.
If Padding bytes are needed but the encryption algorithm does not
specify the padding contents, then the following default processing
MUST be used. The Padding bytes are initialized with a series of
(unsigned, 1-byte) integer values. The first padding byte appended
to the plaintext is numbered 1, with subsequent padding bytes making
up a monotonically increasing sequence: 1, 2, 3, .... When this
padding scheme is employed, the receiver SHOULD inspect the Padding
field. (This scheme was selected because of its relative simplicity,
ease of implementation in hardware, and because it offers limited
protection against certain forms of "cut and paste" attacks in the
absence of other integrity measures, if the receiver checks the
padding values upon decryption.)
If an encryption or combined mode algorithm imposes constraints on
the values of the bytes used for padding, they MUST be specified by
the RFC defining how the algorithm is employed with ESP. If the
algorithm requires checking of the values of the bytes used for
padding, this too MUST be specified in that RFC.
2.5. Pad Length
The Pad Length field indicates the number of pad bytes immediately
preceding it in the Padding field. The range of valid values is 0 to
255, where a value of zero indicates that no Padding bytes are
present. As noted above, this does not include any TFC padding
bytes. The Pad Length field is mandatory.
Kent Standards Track [Page 15]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2.6. Next Header
The Next Header is a mandatory, 8-bit field that identifies the type
of data contained in the Payload Data field, e.g., an IPv4 or IPv6
packet, or a next layer header and data. The value of this field is
chosen from the set of IP Protocol Numbers defined on the web page of
the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates
IPv6, and a value of 6 indicates TCP.
To facilitate the rapid generation and discarding of the padding
traffic in support of traffic flow confidentiality (see Section 2.4),
the protocol value 59 (which means "no next header") MUST be used to
designate a "dummy" packet. A transmitter MUST be capable of
generating dummy packets marked with this value in the next protocol
field, and a receiver MUST be prepared to discard such packets,
without indicating an error. All other ESP header and trailer fields
(SPI, Sequence Number, Padding, Pad Length, Next Header, and ICV)
MUST be present in dummy packets, but the plaintext portion of the
payload, other than this Next Header field, need not be well-formed,
e.g., the rest of the Payload Data may consist of only random bytes.
Dummy packets are discarded without prejudice.
Implementations SHOULD provide local management controls to enable
the use of this capability on a per-SA basis. The controls should
allow the user to specify if this feature is to be used and also
provide parametric controls; for example, the controls might allow an
administrator to generate random-length or fixed-length dummy
packets.
DISCUSSION: Dummy packets can be inserted at random intervals to mask
the absence of actual traffic. One can also "shape" the actual
traffic to match some distribution to which dummy traffic is added as
dictated by the distribution parameters. As with the packet length
padding facility for Traffic Flow Security (TFS), the most secure
approach would be to generate dummy packets at whatever rate is
needed to maintain a constant rate on an SA. If packets are all the
same size, then the SA presents the appearance of a constant bit rate
data stream, analogous to what a link crypto would offer at layer 1
or 2. However, this is unlikely to be practical in many contexts,
e.g., when there are multiple SAs active, because it would imply
reducing the allowed bandwidth for a site, based on the number of
SAs, and that would undermine the benefits of packet switching.
Implementations SHOULD provide controls to enable local
administrators to manage the generation of dummy packets for TFC
purposes.
Kent Standards Track [Page 16]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
2.7. Traffic Flow Confidentiality (TFC) Padding
As noted above, the Padding field is limited to 255 bytes in length.
This generally will not be adequate to hide traffic characteristics
relative to traffic flow confidentiality requirements. An optional
field, within the payload data, is provided specifically to address
the TFC requirement.
An IPsec implementation SHOULD be capable of padding traffic by
adding bytes after the end of the Payload Data, prior to the
beginning of the Padding field. However, this padding (hereafter
referred to as TFC padding) can be added only if the Payload Data
field contains a specification of the length of the IP datagram.
This is always true in tunnel mode, and may be true in transport mode
depending on whether the next layer protocol (e.g., IP, UDP, ICMP)
contains explicit length information. This length information will
enable the receiver to discard the TFC padding, because the true
length of the Payload Data will be known. (ESP trailer fields are
located by counting back from the end of the ESP packet.)
Accordingly, if TFC padding is added, the field containing the
specification of the length of the IP datagram MUST NOT be modified
to reflect this padding. No requirements for the value of this
padding are established by this standard.
In principle, existing IPsec implementations could have made use of
this capability previously, in a transparent fashion. However,
because receivers may not have been prepared to deal with this
padding, the SA management protocol MUST negotiate this service prior
to a transmitter employing it, to ensure backward compatibility.
Combined with the convention described in Section 2.6 above, about
the use of protocol ID 59, an ESP implementation is capable of
generating dummy and real packets that exhibit much greater length
variability, in support of TFC.
Implementations SHOULD provide local management controls to enable
the use of this capability on a per-SA basis. The controls should
allow the user to specify if this feature is to be used and also
provide parametric controls for the feature.
2.8. Integrity Check Value (ICV)
The Integrity Check Value is a variable-length field computed over
the ESP header, Payload, and ESP trailer fields. Implicit ESP
trailer fields (integrity padding and high-order ESN bits, if
applicable) are included in the ICV computation. The ICV field is
optional. It is present only if the integrity service is selected
and is provided by either a separate integrity algorithm or a
combined mode algorithm that uses an ICV. The length of the field is
Kent Standards Track [Page 17]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
specified by the integrity algorithm selected and associated with the
SA. The integrity algorithm specification MUST specify the length of
the ICV and the comparison rules and processing steps for validation.
3. Encapsulating Security Protocol Processing
3.1. ESP Header Location
ESP may be employed in two ways: transport mode or tunnel mode.
3.1.1. Transport Mode Processing
In transport mode, ESP is inserted after the IP header and before a
next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of
IPv4, this translates to placing ESP after the IP header (and any
options that it contains), but before the next layer protocol. (If
AH is also applied to a packet, it is applied to the ESP header,
Payload, ESP trailer, and ICV, if present.) (Note that the term
"transport" mode should not be misconstrued as restricting its use to
TCP and UDP.) The following diagram illustrates ESP transport mode
positioning for a typical IPv4 packet, on a "before and after" basis.
(This and subsequent diagrams in this section show the ICV field, the
presence of which is a function of the security services and the
algorithm/mode selected.)
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
|<---- encryption ---->|
|<-------- integrity ------->|
In the IPv6 context, ESP is viewed as an end-to-end payload, and thus
should appear after hop-by-hop, routing, and fragmentation extension
headers. Destination options extension header(s) could appear
before, after, or both before and after the ESP header depending on
the semantics desired. However, because ESP protects only fields
after the ESP header, it generally will be desirable to place the
destination options header(s) after the ESP header. The following
diagram illustrates ESP transport mode positioning for a typical IPv6
packet.
Kent Standards Track [Page 18]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
---------------------------------------------------------
|<--- encryption ---->|
|<------ integrity ------>|
* = if present, could be before ESP, after ESP, or both
Note that in transport mode, for "bump-in-the-stack" or "bump-in-
the-wire" implementations, as defined in the Security Architecture
document, inbound and outbound IP fragments may require an IPsec
implementation to perform extra IP reassembly/fragmentation in order
to both conform to this specification and provide transparent IPsec
support. Special care is required to perform such operations within
these implementations when multiple interfaces are in use.
3.1.2. Tunnel Mode Processing
In tunnel mode, the "inner" IP header carries the ultimate (IP)
source and destination addresses, while an "outer" IP header contains
the addresses of the IPsec "peers", e.g., addresses of security
gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6
over IPv4 and IPv4 over IPv6. In tunnel mode, ESP protects the
entire inner IP packet, including the entire inner IP header. The
position of ESP in tunnel mode, relative to the outer IP header, is
the same as for ESP in transport mode. The following diagram
illustrates ESP tunnel mode positioning for typical IPv4 and IPv6
packets.
Kent Standards Track [Page 19]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<--------- encryption --------->|
|<------------- integrity ------------>|
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
------------------------------------------------------------
|<--------- encryption ---------->|
|<------------ integrity ------------>|
* = if present, construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is discussed in
the Security Architecture document.
3.2. Algorithms
The mandatory-to-implement algorithms for use with ESP are described
in a separate RFC, to facilitate updating the algorithm requirements
independently from the protocol per se. Additional algorithms,
beyond those mandated for ESP, MAY be supported. Note that although
both confidentiality and integrity are optional, at least one of
these services MUST be selected, hence both algorithms MUST NOT be
simultaneously NULL.
Kent Standards Track [Page 20]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
3.2.1. Encryption Algorithms
The encryption algorithm employed to protect an ESP packet is
specified by the SA via which the packet is transmitted/received.
Because IP packets may arrive out of order, and not all packets may
arrive (packet loss), each packet must carry any data required to
allow the receiver to establish cryptographic synchronization for
decryption. This data may be carried explicitly in the payload
field, e.g., as an IV (as described above), or the data may be
derived from the plaintext portions of the (outer IP or ESP) packet
header. (Note that if plaintext header information is used to derive
an IV, that information may become security critical and thus the
protection boundary associated with the encryption process may grow.
For example, if one were to use the ESP Sequence Number to derive an
IV, the Sequence Number generation logic (hardware or software) would
have to be evaluated as part of the encryption algorithm
implementation. In the case of FIPS 140-2 [NIST01], this could
significantly extend the scope of a cryptographic module evaluation.)
Because ESP makes provision for padding of the plaintext, encryption
algorithms employed with ESP may exhibit either block or stream mode
characteristics. Note that because encryption (confidentiality) MAY
be an optional service (e.g., integrity-only ESP), this algorithm MAY
be "NULL" [Ken-Arch].
To allow an ESP implementation to compute the encryption padding
required by a block mode encryption algorithm, and to determine the
MTU impact of the algorithm, the RFC for each encryption algorithm
used with ESP must specify the padding modulus for the algorithm.
3.2.2. Integrity Algorithms
The integrity algorithm employed for the ICV computation is specified
by the SA via which the packet is transmitted/received. As was the
case for encryption algorithms, any integrity algorithm employed with
ESP must make provisions to permit processing of packets that arrive
out of order and to accommodate packet loss. The same admonition
noted above applies to use of any plaintext data to facilitate
receiver synchronization of integrity algorithms. Note that because
the integrity service MAY be optional, this algorithm may be "NULL".
To allow an ESP implementation to compute any implicit integrity
algorithm padding required, the RFC for each algorithm used with ESP
must specify the padding modulus for the algorithm.
Kent Standards Track [Page 21]