IPsec Anti-Replay Algorithm without Bit Shifting
RFC 6479
|
| Document |
Type |
|
RFC - Informational
(January 2012; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
ISE
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
ISE state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 6479 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
Sean Turner
|
|
IESG note |
|
ISE Submission
|
|
Send notices to |
|
rfc-ise@rfc-editor.org
|
Independent Submission X. Zhang
Request for Comments: 6479 T. Tsou
Category: Informational Futurewei Technologies
ISSN: 2070-1721 January 2012
IPsec Anti-Replay Algorithm without Bit Shifting
Abstract
This document presents an alternate method to do the anti-replay
checks and updates for IP Authentication Header (AH) and
Encapsulating Security Protocol (ESP). The method defined in this
document obviates the need for bit shifting and it reduces the number
of times an anti-replay window is adjusted.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6479.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Zhang & Tsou Informational [Page 1]
RFC 6479 IPsec Anti-Replay Algorithm January 2012
Table of Contents
1. Introduction ....................................................2
2. Description of New Anti-Replay Algorithm ........................3
3. Example of New Anti-Replay Algorithm ............................5
4. Security Considerations .........................................9
5. Normative References ............................................9
6. Acknowledgements ................................................9
1. Introduction
"IP Authentication Header" [RFC4302] and "IP Encapsulating Security
Payload (ESP)" [RFC4303] define an anti-replay service that employs a
sliding window mechanism. The mechanism, when enabled by a receiver,
uses an anti-replay window of size W. This window limits how far out
of order a packet can be, relative to the packet with the highest
sequence number that has been authenticated so far. The window can
be represented by a range [WB, WT], where WB=WT-W+1. The whole
anti-replay window can be thought of as a string of bits. The value
of each bit indicates whether or not a packet with that sequence
number has been received and authenticated, so that the replay packet
can be detected and rejected. If the packet is received, the
receiver gets the sequence number S in the packet. If S is inside
window (S<=WT and S>=WB), then the receiver checks the corresponding
bit (location is S-WB) in the window to see if this S has already
been seen. If S<WB, the packet is dropped. If S>WT and is
validated, the window is advanced by (S-WT) bits. The new window
becomes [WB+S-WT, S]. The new bits in this new window are set to
indicate that no packets with those sequence numbers have been
received. The typical implementation (for example, the integrity
algorithm [RFC4302]) is done by shifting (S-WT) bits. In normal
cases, the packets arrive in order, which results in continuous
updates and bit-shifting operations.
[RFC4302] and [RFC4303] define minimum window sizes of 32 and 64.
But no requirement is established for minimum or recommended window
sizes beyond 64 packets. The window size needs to be based on
reasonable expectations for packet re-ordering. For a high-end,
multi-core network processor with multiple crypto cores, a window
size bigger than 64 or 128 is needed due to the varied IPsec
processing latency caused by different cores. In such a case, the
window sliding is tremendously costly even with hardware acceleration
to do the bit shifting. This document describes an alternate method
to avoid bit shifting. It only discusses the anti-replay processing
at the receiving side. The processing is always safe and has no
interoperability effects. Even with a window size bigger than the
Show full document text