acket sent using a given SA will
contain a sequence number of 1.
If anti-replay is enabled (the default), the sender checks to ensure
that the counter has not cycled before inserting the new value in the
Sequence Number field. In other words, the sender MUST NOT send a
packet on an SA if doing so would cause the sequence number to cycle.
An attempt to transmit a packet that would result in sequence number
overflow is an auditable event. The audit log entry for this event
SHOULD include the SPI value, current date/time, Source Address,
Destination Address, and (in IPv6) the cleartext Flow ID.
The sender assumes anti-replay is enabled as a default, unless
otherwise notified by the receiver (see Section 3.4.3). Thus,
typical behavior of an ESP implementation calls for the sender to
establish a new SA when the Sequence Number (or ESN) cycles, or in
anticipation of this value cycling.
If the key used to compute an ICV is manually distributed, a
compliant implementation SHOULD NOT provide anti-replay service. If
a user chooses to employ anti-replay in conjunction with SAs that are
manually keyed, the sequence number counter at the sender MUST be
correctly maintained across local reboots, etc., until the key is
replaced. (See Section 5.)
If anti-replay is disabled (as noted above), the sender does not need
to monitor or reset the counter. However, the sender still
increments the counter and when it reaches the maximum value, the
counter rolls over back to zero. (This behavior is recommended for
multi-sender, multicast SAs, unless anti-replay mechanisms outside
Kent Standards Track [Page 25]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
the scope of this standard are negotiated between the sender and
receiver.)
If ESN (see Appendix) is selected, only the low-order 32 bits of the
sequence number are transmitted in the Sequence Number field,
although both sender and receiver maintain full 64-bit ESN counters.
The high order 32 bits are included in the integrity check in an
algorithm/mode-specific fashion, e.g., the high-order 32 bits may be
appended after the Next Header field when a separate integrity
algorithm is employed.
Note: If a receiver chooses to not enable anti-replay for an SA, then
the receiver SHOULD NOT negotiate ESN in an SA management protocol.
Use of ESN creates a need for the receiver to manage the anti-replay
window (in order to determine the correct value for the high-order
bits of the ESN, which are employed in the ICV computation), which is
generally contrary to the notion of disabling anti-replay for an SA.
3.3.4. Fragmentation
If necessary, fragmentation is performed after ESP processing within
an IPsec implementation. Thus, transport mode ESP is applied only to
whole IP datagrams (not to IP fragments). An IP packet to which ESP
has been applied may itself be fragmented by routers en route, and
such fragments must be reassembled prior to ESP processing at a
receiver. In tunnel mode, ESP is applied to an IP packet, which may
be a fragment of an IP datagram. For example, a security gateway or
a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as
defined in the Security Architecture document) may apply tunnel mode
ESP to such fragments.
NOTE: For transport mode -- As mentioned at the end of Section 3.1.1,
bump-in-the-stack and bump-in-the-wire implementations may have to
first reassemble a packet fragmented by the local IP layer, then
apply IPsec, and then fragment the resulting packet.
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire
implementations, it will be necessary to examine all the extension
headers to determine if there is a fragmentation header and hence
that the packet needs reassembling prior to IPsec processing.
Fragmentation, whether performed by an IPsec implementation or by
routers along the path between IPsec peers, significantly reduces
performance. Moreover, the requirement for an ESP receiver to accept
fragments for reassembly creates denial of service vulnerabilities.
Thus, an ESP implementation MAY choose to not support fragmentation
and may mark transmitted packets with the DF bit, to facilitate Path
MTU (PMTU) discovery. In any case, an ESP implementation MUST
Kent Standards Track [Page 26]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
support generation of ICMP PMTU messages (or equivalent internal
signaling for native host implementations) to minimize the likelihood
of fragmentation. Details of the support required for MTU management
are contained in the Security Architecture document.
3.4. Inbound Packet Processing
3.4.1. Reassembly
If required, reassembly is performed prior to ESP processing. If a
packet offered to ESP for processing appears to be an IP fragment,
i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set,
the receiver MUST discard the packet; this is an auditable event.
The audit log entry for this event SHOULD include the SPI value,
date/time received, Source Address, Destination Address, Sequence
Number, and (in IPv6) the Flow ID.
NOTE: For packet reassembly, the current IPv4 spec does NOT require
either the zeroing of the OFFSET field or the clearing of the MORE
FRAGMENTS flag. In order for a reassembled packet to be processed by
IPsec (as opposed to discarded as an apparent fragment), the IP code
must do these two things after it reassembles a packet.
3.4.2. Security Association Lookup
Upon receipt of a packet containing an ESP Header, the receiver
determines the appropriate (unidirectional) SA via lookup in the SAD.
For a unicast SA, this determination is based on the SPI or the SPI
plus protocol field, as described in Section 2.1. If an
implementation supports multicast traffic, the destination address is
also employed in the lookup (in addition to the SPI), and the sender
address also may be employed, as described in Section 2.1. (This
process is described in more detail in the Security Architecture
document.) The SAD entry for the SA also indicates whether the
Sequence Number field will be checked, whether 32- or 64-bit sequence
numbers are employed for the SA, and whether the (explicit) ICV field
should be present (and if so, its size). Also, the SAD entry will
specify the algorithms and keys to be employed for decryption and ICV
computation (if applicable).
If no valid Security Association exists for this packet, the receiver
MUST discard the packet; this is an auditable event. The audit log
entry for this event SHOULD include the SPI value, date/time
received, Source Address, Destination Address, Sequence Number, and
(in IPv6) the cleartext Flow ID.
Kent Standards Track [Page 27]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
(Note that SA management traffic, such as IKE packets, does not need
to be processed based on SPI, i.e., one can demultiplex this traffic
separately based on Next Protocol and Port fields, for example.)
3.4.3. Sequence Number Verification
All ESP implementations MUST support the anti-replay service, though
its use may be enabled or disabled by the receiver on a per-SA basis.
This service MUST NOT be enabled unless the ESP integrity service
also is enabled for the SA, because otherwise the Sequence Number
field has not been integrity protected. Anti-replay is applicable to
unicast as well as multicast SAs. However, this standard specifies
no mechanisms for providing anti-replay for a multi-sender SA
(unicast or multicast). In the absence of negotiation (or manual
configuration) of an anti-replay mechanism for such an SA, it is
recommended that sender and receiver checking of the sequence number
for the SA be disabled (via negotiation or manual configuration), as
noted below.
If the receiver does not enable anti-replay for an SA, no inbound
checks are performed on the Sequence Number. However, from the
perspective of the sender, the default is to assume that anti-replay
is enabled at the receiver. To avoid having the sender do
unnecessary sequence number monitoring and SA setup (see section
3.3.3), if an SA establishment protocol is employed, the receiver
SHOULD notify the sender, during SA establishment, if the receiver
will not provide anti-replay protection.
If the receiver has enabled the anti-replay service for this SA, the
receive packet counter for the SA MUST be initialized to zero when
the SA is established. For each received packet, the receiver MUST
verify that the packet contains a Sequence Number that does not
duplicate the Sequence Number of any other packets received during
the life of this SA. This SHOULD be the first ESP check applied to a
packet after it has been matched to an SA, to speed rejection of
duplicate packets.
ESP permits two-stage verification of packet sequence numbers. This
capability is important whenever an ESP implementation (typically the
cryptographic module portion thereof) is not capable of performing
decryption and/or integrity checking at the same rate as the
interface(s) to unprotected networks. If the implementation is
capable of such "line rate" operation, then it is not necessary to
perform the preliminary verification stage described below.
The preliminary Sequence Number check is effected utilizing the
Sequence Number value in the ESP Header and is performed prior to
integrity checking and decryption. If this preliminary check fails,
Kent Standards Track [Page 28]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
the packet is discarded, thus avoiding the need for any cryptographic
operations by the receiver. If the preliminary check is successful,
the receiver cannot yet modify its local counter, because the
integrity of the Sequence Number has not been verified at this point.
Duplicates are rejected through the use of a sliding receive window.
How the window is implemented is a local matter, but the following
text describes the functionality that the implementation must
exhibit.
The "right" edge of the window represents the highest, validated
Sequence Number value received on this SA. Packets that contain
sequence numbers lower than the "left" edge of the window are
rejected. Packets falling within the window are checked against a
list of received packets within the window. If the ESN option is
selected for an SA, only the low-order 32 bits of the sequence number
are explicitly transmitted, but the receiver employs the full
sequence number computed using the high-order 32 bits for the
indicated SA (from his local counter) when checking the received
Sequence Number against the receive window. In constructing the full
sequence number, if the low-order 32 bits carried in the packet are
lower in value than the low-order 32 bits of the receiver's sequence
number, the receiver assumes that the high-order 32 bits have been
incremented, moving to a new sequence number subspace. (This
algorithm accommodates gaps in reception for a single SA as large as
2**32-1 packets. If a larger gap occurs, additional, heuristic
checks for re-synchronization of the receiver sequence number counter
MAY be employed, as described in the Appendix.)
If the received packet falls within the window and is not a
duplicate, or if the packet is to the right of the window, and if a
separate integrity algorithm is employed, then the receiver proceeds
to integrity verification. If a combined mode algorithm is employed,
the integrity check is performed along with decryption. In either
case, if the integrity check fails, the receiver MUST discard the
received IP datagram as invalid; this is an auditable event. The
audit log entry for this event SHOULD include the SPI value,
date/time received, Source Address, Destination Address, the Sequence
Number, and (in IPv6) the Flow ID. The receive window is updated
only if the integrity verification succeeds. (If a combined mode
algorithm is being used, then the integrity protected Sequence Number
must also match the Sequence Number used for anti-replay protection.)
A minimum window size of 32 packets MUST be supported when 32-bit
sequence numbers are employed; a window size of 64 is preferred and
SHOULD be employed as the default. Another window size (larger than
the minimum) MAY be chosen by the receiver. (The receiver does NOT
notify the sender of the window size.) The receive window size
Kent Standards Track [Page 29]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
should be increased for higher-speed environments, irrespective of
assurance issues. Values for minimum and recommended receive window
sizes for very high-speed (e.g., multi-gigabit/second) devices are
not specified by this standard.
3.4.4. Integrity Check Value Verification
As with outbound processing, there are several options for inbound
processing, based on features of the algorithms employed.
3.4.4.1. Separate Confidentiality and Integrity Algorithms
If separate confidentiality and integrity algorithms are employed
processing proceeds as follows:
1. If integrity has been selected, the receiver computes the
ICV over the ESP packet minus the ICV, using the specified
integrity algorithm and verifies that it is the same as the
ICV carried in the packet. Details of the computation are
provided below.
If the computed and received ICVs match, then the datagram
is valid, and it is accepted. If the test fails, then the
receiver MUST discard the received IP datagram as invalid;
this is an auditable event. The log data SHOULD include the
SPI value, date/time received, Source Address, Destination
Address, the Sequence Number, and (for IPv6) the cleartext
Flow ID.
Implementation Note:
Implementations can use any set of steps that results in the
same result as the following set of steps. Begin by
removing and saving the ICV field. Next check the overall
length of the ESP packet minus the ICV field. If implicit
padding is required, based on the block size of the
integrity algorithm, append zero-filled bytes to the end of
the ESP packet directly after the Next Header field, or
after the high-order 32 bits of the sequence number if ESN
is selected. Perform the ICV computation and compare the
result with the saved value, using the comparison rules
defined by the algorithm specification.
2. The receiver decrypts the ESP Payload Data, Padding, Pad
Length, and Next Header using the key, encryption algorithm,
algorithm mode, and cryptographic synchronization data (if
any), indicated by the SA. As in Section 3.3.2, we speak
here in terms of encryption always being applied because of
Kent Standards Track [Page 30]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
the formatting implications. This is done with the
understanding that "no confidentiality" is offered by using
the NULL encryption algorithm (RFC 2410).
- If explicit cryptographic synchronization data, e.g.,
an IV, is indicated, it is taken from the Payload
field and input to the decryption algorithm as per
the algorithm specification.
- If implicit cryptographic synchronization data is
indicated, a local version of the IV is constructed
and input to the decryption algorithm as per the
algorithm specification.
3. The receiver processes any Padding as specified in the
encryption algorithm specification. If the default padding
scheme (see Section 2.4) has been employed, the receiver
SHOULD inspect the Padding field before removing the padding
prior to passing the decrypted data to the next layer.
4. The receiver checks the Next Header field. If the value is
"59" (no next header), the (dummy) packet is discarded
without further processing.
5. The receiver reconstructs the original IP datagram from:
- for transport mode -- outer IP header plus the
original next layer protocol information in the ESP
Payload field
- for tunnel mode -- the entire IP datagram in the ESP
Payload field.
The exact steps for reconstructing the original datagram
depend on the mode (transport or tunnel) and are described
in the Security Architecture document. At a minimum, in an
IPv6 context, the receiver SHOULD ensure that the decrypted
data is 8-byte aligned, to facilitate processing by the
protocol identified in the Next Header field. This
processing "discards" any (optional) TFC padding that has
been added for traffic flow confidentiality. (If present,
this will have been inserted after the IP datagram (or
transport-layer frame) and before the Padding field (see
Section 2.4).)
If integrity checking and encryption are performed in parallel,
integrity checking MUST be completed before the decrypted packet is
passed on for further processing. This order of processing
facilitates rapid detection and rejection of replayed or bogus
Kent Standards Track [Page 31]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
packets by the receiver, prior to decrypting the packet, hence
potentially reducing the impact of denial of service attacks.
Note: If the receiver performs decryption in parallel with integrity
checking, care must be taken to avoid possible race conditions with
regard to packet access and extraction of the decrypted packet.
3.4.4.2. Combined Confidentiality and Integrity Algorithms
If a combined confidentiality and integrity algorithm is employed,
then the receiver proceeds as follows:
1. Decrypts and integrity checks the ESP Payload Data, Padding,
Pad Length, and Next Header, using the key, algorithm,
algorithm mode, and cryptographic synchronization data (if
any), indicated by the SA. The SPI from the ESP header, and
the (receiver) packet counter value (adjusted as required
from the processing described in Section 3.4.3) are inputs
to this algorithm, as they are required for the integrity
check.
- If explicit cryptographic synchronization data, e.g.,
an IV, is indicated, it is taken from the Payload
field and input to the decryption algorithm as per
the algorithm specification.
- If implicit cryptographic synchronization data, e.g.,
an IV, is indicated, a local version of the IV is
constructed and input to the decryption algorithm as
per the algorithm specification.
2. If the integrity check performed by the combined mode
algorithm fails, the receiver MUST discard the received IP
datagram as invalid; this is an auditable event. The log
data SHOULD include the SPI value, date/time received,
Source Address, Destination Address, the Sequence Number,
and (in IPv6) the cleartext Flow ID.
3. Process any Padding as specified in the encryption algorithm
specification, if the algorithm has not already done so.
4. The receiver checks the Next Header field. If the value is
"59" (no next header), the (dummy) packet is discarded
without further processing.
5. Extract the original IP datagram (tunnel mode) or
transport-layer frame (transport mode) from the ESP Payload
Data field. This implicitly discards any (optional) padding
Kent Standards Track [Page 32]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
that has been added for traffic flow confidentiality. (If
present, the TFC padding will have been inserted after the
IP payload and before the Padding field (see Section 2.4).)
4. Auditing
Not all systems that implement ESP will implement auditing. However,
if ESP is incorporated into a system that supports auditing, then the
ESP implementation MUST also support auditing and MUST allow a system
administrator to enable or disable auditing for ESP. For the most
part, the granularity of auditing is a local matter. However,
several auditable events are identified in this specification and for
each of these events a minimum set of information that SHOULD be
included in an audit log is defined.
- No valid Security Association exists for a session. The
audit log entry for this event SHOULD include the SPI value,
date/time received, Source Address, Destination Address,
Sequence Number, and (for IPv6) the cleartext Flow ID.
- A packet offered to ESP for processing appears to be an IP
fragment, i.e., the OFFSET field is non-zero or the MORE
FRAGMENTS flag is set. The audit log entry for this event
SHOULD include the SPI value, date/time received, Source
Address, Destination Address, Sequence Number, and (in IPv6)
the Flow ID.
- Attempt to transmit a packet that would result in Sequence
Number overflow. The audit log entry for this event SHOULD
include the SPI value, current date/time, Source Address,
Destination Address, Sequence Number, and (for IPv6) the
cleartext Flow ID.
- The received packet fails the anti-replay checks. The audit
log entry for this event SHOULD include the SPI value,
date/time received, Source Address, Destination Address, the
Sequence Number, and (in IPv6) the Flow ID.
- The integrity check fails. The audit log entry for this
event SHOULD include the SPI value, date/time received,
Source Address, Destination Address, the Sequence Number, and
(for IPv6) the Flow ID.
Additional information also MAY be included in the audit log for each
of these events, and additional events, not explicitly called out in
this specification, also MAY result in audit log entries. There is
no requirement for the receiver to transmit any message to the
Kent Standards Track [Page 33]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
purported sender in response to the detection of an auditable event,
because of the potential to induce denial of service via such action.
5. Conformance Requirements
Implementations that claim conformance or compliance with this
specification MUST implement the ESP syntax and processing described
here for unicast traffic, and MUST comply with all additional packet
processing requirements levied by the Security Architecture document
[Ken-Arch]. Additionally, if an implementation claims to support
multicast traffic, it MUST comply with the additional requirements
specified for support of such traffic. If the key used to compute an
ICV is manually distributed, correct provision of the anti-replay
service requires correct maintenance of the counter state at the
sender (across local reboots, etc.), until the key is replaced, and
there likely would be no automated recovery provision if counter
overflow were imminent. Thus, a compliant implementation SHOULD NOT
provide anti-replay service in conjunction with SAs that are manually
keyed.
The mandatory-to-implement algorithms for use with ESP are described
in a separate document [Eas04], to facilitate updating the algorithm
requirements independently from the protocol per se. Additional
algorithms, beyond those mandated for ESP, MAY be supported.
Because use of encryption in ESP is optional, support for the "NULL"
encryption algorithm also is required to maintain consistency with
the way ESP services are negotiated. Support for the
confidentiality-only service version of ESP is optional. If an
implementation offers this service, it MUST also support the
negotiation of the "NULL" integrity algorithm. NOTE that although
integrity and encryption may each be "NULL" under the circumstances
noted above, they MUST NOT both be "NULL".
6. Security Considerations
Security is central to the design of this protocol, and thus security
considerations permeate the specification. Additional security-
relevant aspects of using the IPsec protocol are discussed in the
Security Architecture document.
7. Differences from RFC 2406
This document differs from RFC 2406 in a number of significant ways.
o Confidentiality-only service -- now a MAY, not a MUST.
Kent Standards Track [Page 34]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
o SPI -- modified to specify a uniform algorithm for SAD lookup
for unicast and multicast SAs, covering a wider range of
multicast technologies. For unicast, the SPI may be used
alone to select an SA, or may be combined with the protocol,
at the option of the receiver. For multicast SAs, the SPI is
combined with the destination address, and optionally the
source address, to select an SA.
o Extended Sequence Number -- added a new option for a 64-bit
sequence number for very high-speed communications. Clarified
sender and receiver processing requirements for multicast SAs
and multi-sender SAs.
o Payload data -- broadened model to accommodate combined mode
algorithms.
o Padding for improved traffic flow confidentiality -- added
requirement to be able to add bytes after the end of the IP
Payload, prior to the beginning of the Padding field.
o Next Header -- added requirement to be able to generate and
discard dummy padding packets (Next Header = 59)
o ICV -- broadened model to accommodate combined mode
algorithms.
o Algorithms -- Added combined confidentiality mode algorithms.
o Moved references to mandatory algorithms to a separate
document.
o Inbound and Outbound packet processing -- there are now two
paths: (1) separate confidentiality and integrity
algorithms and (2) combined confidentiality mode
algorithms. Because of the addition of combined mode
algorithms, the encryption/decryption and integrity sections
have been combined for both inbound and outbound packet
processing.
8. Backward-Compatibility Considerations
There is no version number in ESP and no mechanism enabling IPsec
peers to discover or negotiate which version of ESP each is using or
should use. This section discusses consequent backward-compatibility
issues.
First, if none of the new features available in ESP v3 are employed,
then the format of an ESP packet is identical in ESP v2 and v3. If a
combined mode encryption algorithm is employed, a feature supported
only in ESP v3, then the resulting packet format may differ from the
ESP v2 spec. However, a peer who implements only ESP v2 would never
negotiate such an algorithm, as they are defined for use only in the
ESP v3 context.
Kent Standards Track [Page 35]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Extended Sequence Number (ESN) negotiation is supported by IKE v2 and
has been addressed for IKE v1 by the ESN Addendum to the IKE v1
Domain of Interpretation (DOI).
In the new ESP (v3), we make two provisions to better support traffic
flow confidentiality (TFC):
- arbitrary padding after the end of an IP packet
- a discard convention using Next Header = 59
The first feature is one that should not cause problems for a
receiver, since the IP total length field indicates where the IP
packet ends. Thus, any TFC padding bytes after the end of the packet
should be removed at some point during IP packet processing, after
ESP processing, even if the IPsec software does not remove such
padding. Thus, this is an ESP v3 feature that a sender can employ
irrespective of whether a receiver implements ESP v2 or ESP v3.
The second feature allows a sender to send a payload that is an
arbitrary string of bytes that do not necessarily constitute a well-
formed IP packet, inside of a tunnel, for TFC purposes. It is an
open question as to what an ESP v2 receiver will do when the Next
Header field in an ESP packet contains the value "59". It might
discard the packet when it finds an ill-formed IP header, and log
this event, but it certainly ought not to crash, because such
behavior would constitute a DoS vulnerability relative to traffic
received from authenticated peers. Thus this feature is an
optimization that an ESP v3 sender can make use of irrespective of
whether a receiver implements ESP v2 or ESP v3.
9. Acknowledgements
The author would like to acknowledge the contributions of Ran
Atkinson, who played a critical role in initial IPsec activities, and
who authored the first series of IPsec standards: RFCs 1825-1827.
Karen Seo deserves special thanks for providing help in the editing
of this and the previous version of this specification. The author
also would like to thank the members of the IPSEC and MSEC working
groups who have contributed to the development of this protocol
specification.
10. References
10.1. Normative References
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
Kent Standards Track [Page 36]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
[DH98] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[Eas04] 3rd Eastlake, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
[Ken-Arch] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[Pos81] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
10.2. Informative References
[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security
Protocols", Proceedings of the Sixth Usenix Unix Security
Symposium, July, 1996.
[HC03] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", Work in Progress, November 3, 2002.
[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[Ken-AH] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[Kra01] Krawczyk, H., "The Order of Encryption and Authentication
for Protecting Communications (Or: How Secure Is SSL?)",
CRYPTO' 2001.
[NIST01] Federal Information Processing Standards Publication 140-2
(FIPS PUB 140-2), "Security Requirements for Cryptographic
Modules", Information Technology Laboratory, National
Institute of Standards and Technology, May 25, 2001.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[Syverson] P. Syverson, D. Goldschlag, and M. Reed, "Anonymous
Connections and Onion Routing", Proceedings of the
Symposium on Security and Privacy, Oakland, CA, May 1997,
pages 44-54.
Kent Standards Track [Page 37]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Appendix A: Extended (64-bit) Sequence Numbers
A1. Overview
This appendix describes an extended sequence number (ESN) scheme for
use with IPsec (ESP and AH) that employs a 64-bit sequence number,
but in which only the low-order 32 bits are transmitted as part of
each packet. It covers both the window scheme used to detect
replayed packets and the determination of the high-order bits of the
sequence number that are used both for replay rejection and for
computation of the ICV. It also discusses a mechanism for handling
loss of synchronization relative to the (not transmitted) high-order
bits.
A2. Anti-Replay Window
The receiver will maintain an anti-replay window of size W. This
window will limit how far out of order a packet can be, relative to
the packet with the highest sequence number that has been
authenticated so far. (No requirement is established for minimum or
recommended sizes for this window, beyond the 32- and 64-packet
values already established for 32-bit sequence number windows.
However, it is suggested that an implementer scale these values
consistent with the interface speed supported by an implementation
that makes use of the ESN option. Also, the algorithm described
below assumes that the window is no greater than 2^31 packets in
width.) All 2^32 sequence numbers associated with any fixed value
for the high-order 32 bits (Seqh) will hereafter be called a sequence
number subspace. The following table lists pertinent variables and
their definitions.
Var. Size
Name (bits) Meaning
---- ------ ---------------------------
W 32 Size of window
T 64 Highest sequence number authenticated so far,
upper bound of window
Tl 32 Lower 32 bits of T
Th 32 Upper 32 bits of T
B 64 Lower bound of window
Bl 32 Lower 32 bits of B
Bh 32 Upper 32 bits of B
Seq 64 Sequence Number of received packet
Seql 32 Lower 32 bits of Seq
Seqh 32 Upper 32 bits of Seq
Kent Standards Track [Page 38]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
When performing the anti-replay check, or when determining which
high-order bits to use to authenticate an incoming packet, there are
two cases:
+ Case A: Tl >= (W - 1). In this case, the window is within one
sequence number subspace. (See Figure 1)
+ Case B: Tl < (W - 1). In this case, the window spans two
sequence number subspaces. (See Figure 2)
In the figures below, the bottom line ("----") shows two consecutive
sequence number subspaces, with zeros indicating the beginning of
each subspace. The two shorter lines above it show the higher-order
bits that apply. The "====" represents the window. The "****"
represents future sequence numbers, i.e., those beyond the current
highest sequence number authenticated (ThTl).
Th+1 *********
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 1 -- Case A
Th ====**************
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 2 -- Case B
A2.1. Managing and Using the Anti-Replay Window
The anti-replay window can be thought of as a string of bits where
`W' defines the length of the string. W = T - B + 1 and cannot
exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and
the top-most bit corresponds to T, and each sequence number from Bl
through Tl is represented by a corresponding bit. The value of the
bit indicates whether or not a packet with that sequence number has
been received and authenticated, so that replays can be detected and
rejected.
Kent Standards Track [Page 39]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
When a packet with a 64-bit sequence number (Seq) greater than T is
received and validated,
+ B is increased by (Seq - T)
+ (Seq - T) bits are dropped from the low end of the window
+ (Seq - T) bits are added to the high end of the window
+ The top bit is set to indicate that a packet with that sequence
number has been received and authenticated
+ The new bits between T and the top bit are set to indicate that
no packets with those sequence numbers have been received yet.
+ T is set to the new sequence number
In checking for replayed packets,
+ Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <=
Tl, then check the corresponding bit in the window to see if
this Seql has already been seen. If yes, reject the packet. If
no, perform integrity check (see Appendix A2.2. below for
determination of Seqh).
+ Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <=
Tl, then check the corresponding bit in the window to see if
this Seql has already been seen. If yes, reject the packet. If
no, perform integrity check (see Appendix A2.2. below for
determination of Seqh).
A2.2. Determining the Higher-Order Bits (Seqh) of the Sequence Number
Because only `Seql' will be transmitted with the packet, the receiver
must deduce and track the sequence number subspace into which each
packet falls, i.e., determine the value of Seqh. The following
equations define how to select Seqh under "normal" conditions; see
Section A3 for a discussion of how to recover from extreme packet
loss.
+ Under Case A (Figure 1):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1
+ Under Case B (Figure 2):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th
Kent Standards Track [Page 40]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
A2.3. Pseudo-Code Example
The following pseudo-code illustrates the above algorithms for anti-
replay and integrity checks. The values for `Seql', `Tl', `Th' and
`W' are 32-bit unsigned integers. Arithmetic is mod 2^32.
If (Tl >= W - 1) Case A
If (Seql >= Tl - W + 1)
Seqh = Th
If (Seql <= Tl)
If (pass replay check)
If (pass integrity check)
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else reject packet
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else
Seqh = Th + 1
If (pass integrity check)
Tl = Seql (shift bits)
Th = Th + 1
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else Case B
If (Seql >= Tl - W + 1)
Seqh = Th - 1
If (pass replay check)
If (pass integrity check)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
Else reject packet
Else
Seqh = Th
If (Seql <= Tl)
If (pass replay check)
If (pass integrity check)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
Else reject packet
Kent Standards Track [Page 41]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
A3. Handling Loss of Synchronization due to Significant Packet Loss
If there is an undetected packet loss of 2^32 or more consecutive
packets on a single SA, then the transmitter and receiver will lose
synchronization of the high-order bits, i.e., the equations in
Section A2.2. will fail to yield the correct value. Unless this
problem is detected and addressed, subsequent packets on this SA will
fail authentication checks and be discarded. The following procedure
SHOULD be implemented by any IPsec (ESP or AH) implementation that
supports the ESN option.
Note that this sort of extended traffic loss is likely to be detected
at higher layers in most cases, before IPsec would have to invoke the
sort of re-synchronization mechanism described in A3.1 and A3.2. If
any significant fraction of the traffic on the SA in question is TCP,
the source would fail to receive ACKs and would stop sending long
before 2^32 packets had been lost. Also, for any bi-directional
application, even ones operating above UDP, such an extended outage
would likely result in triggering some form of timeout. However, a
unidirectional application, operating over UDP, might lack feedback
that would cause automatic detection of a loss of this magnitude,
hence the motivation to develop a recovery method for this case.
Note that the above observations apply to SAs between security
gateways, or between hosts, or between host and security gateways.
The solution we've chosen was selected to:
+ minimize the impact on normal traffic processing
+ avoid creating an opportunity for a new denial of service attack
such as might occur by allowing an attacker to force diversion of
resources to a re-synchronization process
+ limit the recovery mechanism to the receiver -- because anti-
replay is a service only for the receiver, and the transmitter
generally is not aware of whether the receiver is using sequence
numbers in support of this optional service, it is preferable for
recovery mechanisms to be local to the receiver. This also
allows for backward compatibility.
Kent Standards Track [Page 42]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
A3.1. Triggering Re-synchronization
For each SA, the receiver records the number of consecutive packets
that fail authentication. This count is used to trigger the re-
synchronization process, which should be performed in the background
or using a separate processor. Receipt of a valid packet on the SA
resets the counter to zero. The value used to trigger the re-
synchronization process is a local parameter. There is no
requirement to support distinct trigger values for different SAs,
although an implementer may choose to do so.
A3.2. Re-synchronization Process
When the above trigger point is reached, a "bad" packet is selected
for which authentication is retried using successively larger values
for the upper half of the sequence number (Seqh). These values are
generated by incrementing by one for each retry. The number of
retries should be limited, in case this is a packet from the "past"
or a bogus packet. The limit value is a local parameter. (Because
the Seqh value is implicitly placed after the ESP (or AH) payload, it
may be possible to optimize this procedure by executing the integrity
algorithm over the packet up to the endpoint of the payload, then
compute different candidate ICVs by varying the value of Seqh.)
Successful authentication of a packet via this procedure resets the
consecutive failure count and sets the value of T to that of the
received packet.
This solution requires support only on the part of the receiver,
thereby allowing for backward compatibility. Also, because re-
synchronization efforts would either occur in the background or
utilize an additional processor, this solution does not impact
traffic processing and a denial of service attack cannot divert
resources away from traffic processing.
Author's Address
Stephen Kent
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Kent Standards Track [Page 43]
RFC 4303 IP Encapsulating Security Payload (ESP) December 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kent Standards Track [Page 44]