Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
RFC 4304

Document Type RFC - Proposed Standard (December 2005; No errata)
Author Stephen Kent 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 4304 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Russ Housley
Send notices to (None)
Network Working Group                                            S. Kent
Request for Comments: 4304                              BBN Technologies
Category: Standards Track                                  December 2005

              Extended Sequence Number (ESN) Addendum to
                  IPsec Domain of Interpretation (DOI)
                   for Internet Security Association
                  and Key Management Protocol (ISAKMP)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   The IP Security Authentication Header (AH) and Encapsulating Security
   Payload (ESP) protocols use a sequence number to detect replay.  This
   document describes extensions to the Internet IP Security Domain of
   Interpretation (DOI) for the Internet Security Association and Key
   Management Protocol (ISAKMP).  These extensions support negotiation
   of the use of traditional 32-bit sequence numbers or extended (64-
   bit) sequence numbers (ESNs) for a particular AH or ESP security

Kent                        Standards Track                     [Page 1]
RFC 4304               ESN Addendum to ISAKMP DOI          December 2005

1.  Introduction

   The specifications for the IP Authentication Header (AH) [AH] and the
   IP Encapsulating Security Payload (ESP) [ESP] describe an option for
   use of extended (64-bit) sequence numbers.  This option permits
   transmission of very large volumes of data at high speeds over an
   IPsec Security Association, without rekeying to avoid sequence number
   space exhaustion.  This document describes the additions to the IPsec
   DOI for ISAKMP [DOI] that are needed to support negotiation of the
   extended sequence number (ESN) option.

   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119 [Bra97].

2.  IPsec Security Association Attribute

   The following SA attribute definition is used in Phase II of an
   Internet Key Exchange Protocol (IKE) negotiation.  The attribute type
   is Basic (B).  Encoding of this attribute is defined in the base
   ISAKMP specification [ISAKMP].  Attributes described as basic MUST
   NOT be encoded as variable.  See [IKE] for further information on
   attribute encoding in the IPsec DOI.  All restrictions listed in
   [IKE] also apply to the IPsec DOI and to this addendum.

   Attribute Type

              class                        value           type
       Extended (64-bit) Sequence Number    11              B

   Class Values

       This class specifies that the Security Association will be using
       64-bit sequence numbers.  (See [AH] and [ESP] for a description
       of extended (64-bit) sequence numbers.)

       RESERVED                0
       64-bit Sequence Number  1

Kent                        Standards Track                     [Page 2]
RFC 4304               ESN Addendum to ISAKMP DOI          December 2005

3.  Attribute Negotiation

   If an implementation receives a defined IPsec DOI attribute (or
   attribute value) that it does not support, an ATTRIBUTES-NOT-SUPPORT
   SHOULD be sent and the security association setup MUST be aborted.

   If an implementation receives any attribute value but the value for
   64-bit sequence numbers, the security association setup MUST be

4.  Security Considerations

   This memo pertains to the Internet Key Exchange protocol [IKE], which
   combines ISAKMP [ISAKMP] and Oakley [OAKLEY] to provide for the
   derivation of cryptographic keying material in a secure and
   authenticated manner.  Specific discussion of the various security
   protocols and transforms identified in this document can be found in
   the associated base documents and in the cipher references.

   The addition of the ESN attribute does not change the underlying
   security characteristics of IKE.  In using ESNs with ESP, it is
   important to employ an encryption mode that is secure when very large
   volumes of data are encrypted under a single key.  Thus, for example,
   Data Encryption Standard (DES) in Cipher Block Chaining (CBC) mode
   would NOT be suitable for use with the ESN, because no more than 2^32
   blocks should be encrypted under a single DES key in that mode.
   Similarly, the integrity algorithm used with ESP or AH should be
   secure relative to the number of packets being protected.  To avoid
   potential security problems imposed by algorithm limitations, the SA
Show full document text