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.
[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.
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
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.
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
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
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.
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
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.