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
B2.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
B3. 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
Appendix B2.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 seems unlikely to occur
if any significant fraction of the traffic on the SA in question is
TCP, because 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.
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.
B3.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.
B3.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 AH (or ESP) 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.