IPsec Anti-Replay Algorithm without Bit Shifting
RFC 6479

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

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
   usual 32- or 64-bit window, no interoperability issues are caused.

Zhang & Tsou                  Informational                     [Page 2]
RFC 6479               IPsec Anti-Replay Algorithm          January 2012