[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

No Subject



<c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-970722142031Z-5156@tsntsrv2.timestep
.com>
From: Roy Pereira <rpereira@TimeStep.com>
To: "'ipsec@tis.com'" <ipsec@tis.com>, "'Karen Seo'" <kseo@bbn.com>
Subject: RE: New draft -- IPSEC ESP
Date: Tue, 22 Jul 1997 10:20:31 -0400
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version
4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk

Wasn't "draft-ietf-ipsec-esp-04.txt", released on May 30 as shown below?

  From: 	Karen Seo[SMTP:kseo@bbn.com]
  Sent: 	Friday, May 30, 1997 5:08 PM
  To: 	ipsec@tis.com
  Cc: 	kseo@bbn.com
  Subject: 	New draft -- IPSEC ESP

  Network Working Group                             Stephen Kent, BBN
Corp
  Internet Draft                           Randall Atkinson, @Home
Network
  draft-ietf-ipsec-esp-04.txt                                  30 May
1997



>----------
>From: 	Karen Seo[SMTP:kseo@bbn.com]
>Sent: 	Monday, July 21, 1997 6:33 PM
>To: 	ipsec@tis.com
>Subject: 	New draft -- IPSEC ESP
>
>
>
>
>Network Working Group                             Stephen Kent, BBN Corp
>Internet Draft                           Randall Atkinson, @Home Network
>draft-ietf-ipsec-esp-04.txt                                 21 July 1997
>
>
>
>
>
>
>                IP Encapsulating Security Payload (ESP)
>
>
>
>
>Status of This Memo
>
>   This document is an Internet Draft. Internet Drafts are working
>   documents of the Internet Engineering Task Force (IETF), its Areas,
>   and its working groups. Note that other groups may also distribute
>   working documents as Internet Drafts.
>
>   Internet Drafts are draft documents valid for a maximum of 6 months.
>   Internet Drafts may be updated, replaced, or obsoleted by other
>   documents at any time. It is not appropriate to use Internet Drafts
>   as reference material or to cite them other than as "work in
>   progress".
>
>   This particular Internet Draft is a product of the IETF's IPsec
>   working group. It is intended that a future version of this draft be
>   submitted to the IPng Area Directors and the IESG for possible
>   publication as a standards-track protocol.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Kent, Atkinson                                                  [Page 1]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>Table of Contents
>
>   1. Introduction......................................................3
>   2. Encapsulating Security Payload Packet Format......................4
>      2.1  Security Parameters Index....................................5
>      2.2  Sequence Number .............................................5
>      2.3  Payload Data.................................................5
>      2.4  Padding (for Encryption).....................................6
>      2.5  Pad Length...................................................7
>      2.6  Next Header..................................................7
>      2.7  Authentication Data..........................................7
>   3. Encapsulating Security Protocol Processing........................7
>      3.1  ESP Header Location..........................................7
>      3.2  Outbound Packet Processing..................................10
>         3.2.1  Security Association Lookup............................10
>         3.2.2  Sequence Number Generation.............................10
>         3.2.3  Packet Encryption......................................10
>            3.2.3.1 Scope of Encryption................................10
>            3.2.3.2 Encryption Algorithms..............................11
>         3.2.4  Integrity Check Value Calculation......................11
>            3.2.4.1  Scope of Authentication Protection................11
>            3.2.4.2  Authentication Padding............................11
>            3.2.4.3  Authentication Algorithms.........................12
>         3.2.5  Fragmentation..........................................12
>      3.3  Inbound Packet Processing...................................12
>         3.3.1  Pre-ESP Processing Overview............................12
>         3.3.2  Security Association Lookup............................12
>         3.3.3  Sequence Number Verification...........................13
>         3.3.4  Integrity Check Value Verification.....................14
>         3.3.5  Packet Decryption......................................15
>   4. Auditing.........................................................15
>   5. Conformance Requirements.........................................16
>   6. Security Considerations..........................................16
>   7. Differences from RFC 1827........................................16
>   Acknowledgements....................................................17
>   References..........................................................17
>   Disclaimer..........................................................19
>   Author Information..................................................19
>
>
>
>
>
>
>
>
>
>
>
>Kent, Atkinson                                                  [Page 2]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>1.  Introduction
>
>   The Encapsulating Security Payload (ESP) header is designed to
>   provide a mix of security services in IPv4 and IPv6.  ESP may be
>   applied alone, in combination with the IP Authentication Header (AH)
>   [KA97b], or in a nested fashion, e.g., through the use of tunnel mode
>   (see "Security Architecture for the Internet Protocol" [KA97a],
>   hereafter referred to as the Security Architecture document).
>   Security services can be provided between a pair of communicating
>   hosts, between a pair of communicating security gateways, or between
>   a security gateway and a host.  For more details on how to use ESP
>   and AH in various network environments, see the Security Architecture
>   document [KA97a].
>
>   The ESP header is inserted after the IP header and before the upper
>   layer protocol header (transport mode) or before  an encapsulated IP
>   header (tunnel mode).  These modes are described in more detail
>   below.
>
>   ESP is used to provide confidentiality, data origin authentication,
>   connectionless integrity, an anti-replay service (a form of partial
>   sequence integrity), and limited traffic flow confidentiality.  The
>   set of services provided depends on options selected at the time of
>   Security Association establishment and on the placement of the
>   implementation.  Confidentiality may be selected independent of all
>   other services.  However, use of confidentiality without
>   integrity/authentication (either in ESP or separately in AH) may
>   subject traffic to certain forms of active attacks that could
>   undermine the confidentiality service (see [Bel96].  Data origin
>   authentication and connectionless integrity are joint services
>   (hereafter referred to jointly as "authentication) and are offered as
>   an option in conjunction with confidentiality.  The anti-replay
>   service may be selected only if data origin authentication is
>   selected, and its election is solely at the discretion of the
>   receiver.  Traffic flow confidentiality requires selection of tunnel
>   mode, and is most effective if implemented at a security gateway,
>   where traffic aggregation may be able to mask true source-destination
>   patterns.
>
>   It is assumed that the reader is familiar with the terms and concepts
>   described in the Security Architecture document.  In particular, the
>   reader should be familiar with the definitions of security services
>   offered by ESP and AH, the concept of Security Associations, the ways
>   in which ESP can be used in conjunction with the Authentication
>   Header (AH), and the different key management options available for
>   ESP and AH.  (With regard to the last topic, the current key
>   management options required for both AH and ESP are manual keying and
>
>
>Kent, Atkinson                                                  [Page 3]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>   automated keying via Oakley/ISAKMP.)
>
>2.  Encapsulating Security Payload Packet Format
>
>
>   The protocol header (IPv4, IPv6, or Extension) immediately preceding the
>   ESP header will contain the value 50 in its Protocol (IPv4) or Next
>   Header (IPv6, Extension) field [STD-2].
>
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
>   |               Security Parameters Index (SPI)                 | ^
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Auth.
>   |                      Sequence Number                          |
>|Coverage
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | -----
>   |                    Payload Data* (variable)                   | |   ^
>   ~                                                               ~ |   |
>   |                                                               | |   |
>   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Confid.
>   |               |     Padding (0-255 bytes)                     |
>|Coverage*
>   +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
>   |                               |  Pad Length   | Next Header   | v   v
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------
>   |                 Authentication Data (variable)                |
>   ~                                                               ~
>   |                                                               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>        * If included in the Payload field, cryptographic synchronization
>          data, e.g., an IV, usually is not encrypted per se, although it
>          often is referred to as being part of the ciphertext.
>
>
>
>
>   The following subsections define the fields in the header format.
>   "Optional" means that the field is omitted if the option is not
>   selected, i.e., it is present in neither the packet as transmitted
>   nor as formatted for computation of an ICV.  Whether or not an option
>   is selected is defined as part of Security Association (SA)
>   establishment.  Thus the format of ESP packets for a given SA is
>   fixed, for the duration of the SA.  In contrast, "mandatory" fields
>   are always present in the ESP packet format, for all SAs.
>
>
>
>
>
>Kent, Atkinson                                                  [Page 4]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>2.1  Security Parameters Index
>
>   The SPI is an arbitrary 32-bit value that uniquely identifies the
>   Security Association for this datagram, relative to the destination
>   IP address contained in the IP header (with which this security
>   header is associated) and relative to the security protocol employed.
>   The set of SPI values in the range 1 through 255 are reserved by the
>   Internet Assigned Numbers Authority (IANA) for future use; a reserved
>   SPI value will not normally be assigned by IANA unless the use of the
>   assigned SPI value is specified in an RFC.  It is ordinarily selected
>   by the destination system upon establishment of an SA (see the
>   Security Architecture document for more details).  (A zero value may
>   be used within an ESP implementation for local debugging purposes,
>   but no ESP packets should be transmitted with a zero SPI value.)  The
>   SPI field is mandatory.
>
>2.2  Sequence Number
>
>   This unsigned 32-bit field contains a monotonically increasing
>   counter value (sequence number).  The sender's counter and the
>   receiver's counter are initialized to 0 when an SA is established.
>   (The first packet sent using a given SA will have a Sequence Number
>   of 1; see Section 3.2.2 for more details on how the Sequence Number
>   is generated.) The transmitted Sequence Number must never be allowed
>   to cycle.  Thus, the sender's counter and the receiver's counter MUST
>   be reset (by establishing a new SA and thus a new key) prior to the
>   transmission of 2^32nd packet on an SA.
>
>   The Sequence Number is mandatory.  It is always included in an ESP
>   packet, to ensure alignment of the Payload field on an 8-byte
>   boundary (in support of IPv6).  Even if authentication is not
>   selected as a security service for the SA, or if ESP is employed in
>   an IPv4 environment, this field MUST be present.
>
>   Processing of the Sequence Number field is at the discretion of the
>   receiver, i.e., the sender MUST always transmit this field, but the
>   receiver need not act upon it (see the discussion of Sequence Number
>   Verification in the "Inbound Processing" section below).
>
>
>2.3  Payload Data
>
>   Payload Data is a variable-length field containing data described by
>   the Next Header field. The Payload Data field is mandatory and is an
>   integral number of bytes in length.  If the algorithm used to encrypt
>   the payload requires cryptographic synchronization data, e.g., an
>   Initialization Vector (IV), then this data MAY be carried explicitly
>
>
>Kent, Atkinson                                                  [Page 5]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>   in the Payload field.  Any encryption algorithm that requires such
>   explicit, per-packet synchronization data MUST indicate the length,
>   any structure for such data, and the location of this data as part of
>   an RFC specifying how the algorithm is used with ESP.  If such
>   synchronization data is implicit, the algorithm for deriving the data
>   MUST be part of the RFC.
>
>2.4  Padding (for Encryption)
>
>   Several factors require or motivate use of the Padding field.
>
>
>             If an encryption algorithm is employed that requires the
>             plaintext to be a multiple of some number of bytes, e.g., the
>             block size of a block cipher, the Padding field is used to fill
>             the plaintext (consisting of the Payload Data, Pad Length and
>             Next Header fields, as well as the Padding) to the size required
>             by the algorithm.
>
>             Padding also may be required, irrespective of encryption
>             algorithm requirements, to ensure that the resulting ciphertext
>             terminates on a 4-byte boundary. Specifically, the Pad Length
>             and Next Header fields must be right aligned within a 4-byte
>             word, as illustrated in the ESP packet format figure above.
>
>             Padding beyond that required for the algorithm or alignment
>             reasons cited above, may be used to conceal the actual length of
>             the payload, in support of (partial) traffic flow
>             confidentiality.  However, inclusion of such additional padding
>             has adverse bandwidth implications and thus its use should be
>             undertaken with care.
>
>
>   The transmitter MAY add 0-255 bytes of padding.  Inclusion of the
>   Padding field in an ESP packet is optional, but all implementations
>   MUST support generation and consumption of padding.
>
>   As a default, the Padding bytes are initialized with a series of
>   (unsigned, 1-byte) integer values.  The first padding byte appended
>   to the plaintext is numbered 1, with subsequent padding bytes making
>   up a monotonically increasing sequence: 1, 2, 3, ...  When this
>   padding scheme is employed, the receiver SHOULD inspect the Padding
>   field.  (This scheme was selected because of its relative simplicity,
>   ease of implementation in hardware, and because it offers limited
>   protection against certain forms of "cut and paste" attacks in the
>   absence of other integrity measures, if the receiver checks the
>   padding values upon decryption.)
>
>
>Kent, Atkinson                                                  [Page 6]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>   Any encryption algorithm that requires Padding other than the default
>   described above, MUST define the Padding contents (e.g., zeros or
>   random data) and any required receiver processing of these Padding
>   bytes in an RFC specifying how the algorithm is used with ESP.  In
>   such circumstances, the content of the Padding field will be
>   determined by the encryption algorithm and mode selected and defined
>   in the corresponding algorithm RFC.  The relevant algorithm RFC MAY
>   specify that a receiver MUST inspect the Padding field or that a
>   receiver MUST inform senders of how the receiver will handle the
>   Padding field.
>
>2.5  Pad Length
>
>   The Pad Length field indicates the number of pad bytes immediately
>   preceding it.  The range of valid values is 0-255, where a value of
>   zero indicates that no Padding bytes are present.  The Pad Length
>   field is mandatory.
>
>2.6  Next Header
>
>   The Next Header is an 8-bit field that identifies the type of data
>   contained in the Payload Data field, e.g., an extension header in
>   IPv6 or an upper layer protocol identifier.  The value of this field
>   is chosen from the set of IP Protocol Numbers defined in the most
>   recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned
>   Numbers Authority (IANA).  The Next Header field is mandatory.
>
>2.7  Authentication Data
>
>   The Authentication Data is a variable-length field containing an
>   Integrity Check Value (ICV) computed over the ESP packet minus the
>   Authentication Data.  The length of the field depends upon the
>   authentication function selected.  The mandatory-to-implement
>   authentication algorithms, HMAC with MD5 or SHA-1, both yield 96-bit
>   ICV's because of the truncation convention (see Section 3.2.4.3)
>   adopted for use in IPsec.  The Authentication Data field is optional,
>   and is included only if the authentication service has been selected
>   for the SA in question.
>
>3.  Encapsulating Security Protocol Processing
>
>   3.1 ESP Header Location
>
>   Like AH, ESP may be employed in two ways: transport mode or tunnel
>   mode.  The former mode is applicable only to host implementations and
>   provides protection for upper layer protocols, but not the IP header.
>   (In this mode, note that for "bump-in-the-stack" or "bump-in-the-
>
>
>Kent, Atkinson                                                  [Page 7]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>   wire" implementations, as defined in the Security Architecture
>   document, inbound and outbound IP fragments may require an IPsec
>   implementation to perform extra IP reassembly/fragmentation in order
>   to both conform to this specification and provide transparent IPsec
>   support.  Special care is required to perform such operations within
>   these implementations when multiple interfaces are in use.)
>
>   In transport mode, ESP is inserted after the IP header and before an
>   upper layer protocol, e.g., TCP, UDP, ICMP, etc.  or before any other
>   IPsec headers that have already been inserted, e.g., AH.  In the
>   context of IPv4, this translates to placing ESP after the IP header
>   (and any options that it contains), but before the upper layer
>   protocol.  (Note that the term "transport" mode should not be
>   misconstrued as restricting its use to TCP and UDP. For example, an
>   ICMP message MAY be sent using either "transport" mode or "tunnel"
>   mode.)  The following diagram illustrates ESP transport mode
>   positioning for a typical IPv4 packet, on a "before and after" basis.
>   (The "ESP trailer" encompasses any Padding, plus the Pad Length, and
>   Next Header fields.)
>
>                 BEFORE APPLYING ESP
>            ----------------------------
>      IPv4  |orig IP hdr  |     |      |
>            |(any options)| TCP | Data |
>            ----------------------------
>
>                 AFTER APPLYING ESP
>            -------------------------------------------------
>      IPv4  |orig IP hdr  | ESP |     |      |   ESP   | ESP|
>            |(any options)| Hdr | TCP | Data | Trailer |Auth|
>            -------------------------------------------------
>                                |<----- encrypted ---->|
>                          |<------ authenticated ----->|
>
>
>   In the IPv6 context, ESP is viewed as an end-to-end payload, and thus
>   should appear after hop-by-hop, routing, and fragmentation extension
>   headers.  The destination options extension header(s) could appear
>   either before or after the ESP header depending on the semantics
>   desired.  However, since ESP protects only fields after the ESP
>   header, it generally may be desirable to place the destination
>   options header(s) after the ESP header.  The following diagram
>   illustrates ESP transport mode positioning for a typical IPv6 packet.
>
>
>
>
>
>
>Kent, Atkinson                                                  [Page 8]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>                     BEFORE APPLYING ESP
>            ---------------------------------------
>      IPv6  |             | ext hdrs |     |      |
>            | orig IP hdr |if present| TCP | Data |
>            ---------------------------------------
>
>
>                     AFTER APPLYING ESP
>            ---------------------------------------------------------
>      IPv6  | orig |hxh,rtg,frag|dest|ESP|dest|   |    | ESP   | ESP|
>            |IP hdr|if present**|opt*|Hdr|opt*|TCP|Data|Trailer|Auth|
>            ---------------------------------------------------------
>                                         |<---- encrypted ---->|
>                                     |<---- authenticated ---->|
>
>                * = if present, could be before ESP, after ESP, or both
>               ** = hop by hop, routing, fragmentation headers
>
>   Tunnel mode ESP may be employed in either hosts or security gateways.
>   When ESP is implemented in a security gateway (to protect subscriber
>   transit traffic), tunnel mode must be used.  In tunnel mode, the
>   "inner" IP header carries the ultimate source and destination
>   addresses, while an "outer" IP header may contain distinct IP
>   addresses, e.g., addresses of security gateways.  In tunnel mode, ESP
>   protects the entire inner IP packet, including the entire inner IP
>   header. The position of ESP in tunnel mode, relative to the outer IP
>   header, is the same as for ESP in transport mode.  The following
>   diagram illustrates ESP tunnel mode positioning for typical IPv4 and
>   IPv6 packets.
>
>            -----------------------------------------------------------
>      IPv4  | new IP hdr* |     | orig IP hdr*  |   |    | ESP   | ESP|
>            |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
>            -----------------------------------------------------------
>                                |<--------- encrypted ---------->|
>                          |<----------- authenticated ---------->|
>
>            ---------------------------------------------------------------
>      IPv6  | new* | ext hdrs*|   | orig*| ext hdrs*|   |    | ESP   | ESP|
>            |IP hdr|if present|ESP|IP hdr|if present|TCP|Data|Trailer|Auth|
>            ---------------------------------------------------------------
>                                  |<---------- encrypted ----------->|
>                              |<----------- authenticated ---------->|
>
>               * = construction of outer IP hdr/extensions and modification
>                      of inner IP hdr/extensions is discussed below.
>
>
>
>Kent, Atkinson                                                  [Page 9]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>3.2  Outbound Packet Processing
>
>   In transport mode, the transmitter encapsulates the upper layer
>   protocol information in the ESP header/trailer, and retains the
>   specified IP header (and any IP extension headers in the IPv6
>   context).  In tunnel mode, the outer and inner IP header/extensions
>   can be inter-related in a variety of ways.  The construction of the
>   outer IP header/extensions during the encapsulation process is
>   described in the Security Architecture document.
>
>3.2.1  Security Association Lookup
>
>   ESP is applied to an outbound packet only after an IPsec
>   implementation determines that the packet is associated with an SA
>   that calls for ESP processing.  The process of determining what, if
>   any, IPsec processing is applied to outbound traffic is described in
>   the Security Architecture document.
>
>3.2.2  Sequence Number Generation
>
>   As noted in Section 2.2, the Sequence Number field is always included
>   in ESP packets, even if the anti-replay service, or the
>   authentication service, have not been enabled for the SA.  The
>   sender's counter is initialized to 0 when an SA is established.  The
>   transmitter increments the Sequence Number for this SA, checks to
>   ensure that the counter has not cycled, and inserts the new value
>   into the Sequence Number field.  Thus the first packet sent using a
>   given SA will have a Sequence Number of 1.  A transmitter MUST NOT
>   send a packet on an SA if doing so would cause the Sequence Number to
>   cycle.  An attempt to transmit a packet that would result in sequence
>   number overflow is an auditable event.  (Note that this approach to
>   Sequence Number management does not require use of modular
>   arithmetic.)
>
>3.2.3  Packet Encryption
>
>3.2.3.1 Scope of Encryption
>
>   In transport mode, the transmitter encapsulates the original upper
>   layer protocol information into the ESP payload field, adds any
>   necessary padding, and encrypts the result (Payload Data, Padding,
>   Pad Length, and Next Header) using the key, encryption algorithm, and
>   algorithm mode indicated by the SA.  In tunnel mode, the transmitter
>   encapsulates and encrypts the entire original IP datagram (plus the
>   Padding, Pad Length, and Next Header).
>
>   If authentication is selected, encryption is performed first, before
>
>
>Kent, Atkinson                                                 [Page 10]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>   the authentication, and the encryption does not encompass the
>   Authentication Data field.  This order of processing facilitates
>   rapid detection and rejection of replayed or bogus packets by the
>   receiver, prior to decrypting the packet, hence potentially reducing
>   the impact of denial of service attacks.  It also allows for the
>   possibility of parallel processing of packets at the receiver, i.e.,
>   decryption can take place in parallel with authentication.  Note that
>   since the Authentication Data is not protected by encryption, a keyed
>   authentication algorithm must be employed to compute the ICV.
>
>3.2.3.2 Encryption Algorithms
>
>The encryption algorithm employed is specified by the SA.  ESP is
>designed for use with symmetric encryption algorithms.  Because IP
>packets may arrive out of order, each packet must carry any data
>required to allow the receiver to establish cryptographic
>synchronization for decryption.  This data may be carried explicitly in
>the payload field, e.g., as an IV (as described above), or the data may
>be derived from the packet header.  Since ESP makes provision for
>padding of the plaintext, encryption algorithms employed with ESP may
>exhibit either block or stream mode characteristics.
>
>At the time of writing, one mandatory-to-implement encryption algorithm
>and mode has been defined for ESP.  It is based on the Data Encryption
>Standard (DES) [NIST77] in Cipher Block Chaining Mode [NIST80].  Details
>of use of this mode are contained in [MS97].
>
>
>3.2.4  Integrity Check Value Calculation
>
>3.2.4.1  Scope of Authentication Protection
>
>   If authentication is selected for the SA, the transmitter computes
>   the ICV over the ESP packet minus the Authentication Data.  Thus the
>   SPI, Sequence Number, Payload Data, Padding (if present), Pad Length,
>   and Next Header are all encompassed by the ICV computation.  Note
>   that the last 4 fields will be in ciphertext form, since encryption
>   is performed prior to authentication.
>
>3.2.4.2  Authentication Padding
>
>   For some authentication algorithms, the byte string over which the
>   ICV computation is performed must be a multiple of a blocksize
>   specified by the algorithm.  If the length of this byte string does
>   not match the blocksize requirements for the algorithm, implicit
>   padding MUST be appended to the end of the ESP packet, prior to ICV
>   computation.  The padding octets MUST have a value of zero.  The
>
>
>Kent, Atkinson                                                 [Page 11]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>   blocksize (and hence the length of the padding) is specified by the
>   algorithm specification.  This padding is not transmitted with the
>   packet.
>
>3.2.4.3  Authentication Algorithms
>
>   The authentication algorithm employed for the ICV computation is
>   specified by the SA.  For point-to-point communication, suitable
>   authentication algorithms include keyed Message Authentication Codes
>   (MACs) based on symmetric encryption algorithms (e.g., DES) or on
>   one-way hash functions (e.g., MD5 or SHA-1).  For multicast
>   communication, one-way hash algorithms combined with asymmetric
>   signature algorithms are suitable.  As of this writing, the
>   mandatory-to-implement authentication algorithms are based on the
>   former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5
>   [Riv92].  The output of the HMAC computation is truncated to the
>   leftmost 96 bits.  Other algorithms, possibly with different ICV
>   lengths, MAY be supported.
>
>3.2.5  Fragmentation
>
>   If necessary, fragmentation is performed after ESP processing within
>   an IPsec implementation.  Thus, transport mode ESP is applied only to
>   whole IP datagrams (not to IP fragments).  An IP packet to which ESP
>   has been applied may itself be fragmented by routers en route, and
>   such fragments must be reassembled prior to ESP processing at a
>   receiver.  In tunnel mode, ESP is applied to an IP packet, the
>   payload of which may be a fragmented IP packet.  For example, a
>   security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec
>   implementation (as defined in the Security Architecture document) may
>   apply tunnel mode ESP to such fragments.
>
>3.3  Inbound Packet Processing
>
>3.3.1  Pre-ESP Processing Overview
>
>   If required, reassembly is performed prior to ESP processing.
>
>3.3.2  Security Association Lookup
>
>   Upon receipt of a (reassembled) packet containing an ESP Header, the
>   receiver determines the appropriate (unidirectional) SA, based on the
>   destination IP address and the SPI.  (This process is described in
>   more detail in the Security Architecture document.)  The SA indicates
>   whether the Authentication Data field should be present, and it will
>   specify the algorithms and keys to be employed for decryption and ICV
>   computations (if applicable).
>
>
>Kent, Atkinson                                                 [Page 12]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>   If no valid Security Association exists for this session (for
>   example, the receiver has no key), the receiver MUST discard the
>   packet; this is an auditable event.  The audit log entry for this
>   event SHOULD include the SPI value, date/time, Source Address,
>   Destination Address, and (in IPv6) the cleartext Flow ID.
>
>3.3.3  Sequence Number Verification
>
>   All ESP implementations MUST support the anti-replay service, though
>   its use may be enabled or disabled on a per-SA basis.  This service
>   MUST NOT be enabled unless the authentication service also is enabled
>   for the SA, since otherwise the Sequence Number field has not been
>   integrity protected.  (Note that there are no provisions for managing
>   transmitted Sequence Number values among multiple senders directing
>   traffic to a single, multicast SA.  Thus the anti-replay service
>   SHOULD NOT be used in a multi-sender multicast environment that
>   employs a single, multicast SA.)  If an SA establishment protocol
>   such as Oakley/ISAKMP is employed, then the receiver SHOULD notify
>   the transmitter, during SA establishment, if the receiver will
>   provide anti-replay protection and SHOULD inform the transmitter of
>   the window size.
>
>   If the receiver enables the anti-replay service for this SA, the
>   receive packet counter for the SA MUST be initialized to zero when
>   the SA is established.  For each received packet, the receiver MUST
>   verify that the packet contains a Sequence Number that does not
>   duplicate the Sequence Number of any other packets received during
>   the life of this SA.  This SHOULD be the first ESP check applied to a
>   packet after it has been matched to an SA, to speed rejection of
>   duplicate packets.
>
>   Duplicates are rejected through the use of a sliding receive window.
>   (How the window is implemented is a local matter, but the following
>   text describes the functionality that the implementation must
>   exhibit.)  A MINIMUM window size of 32 MUST be supported; but a
>   window size of 64 is preferred and SHOULD be employed as the default.
>   A window size of 64 or larger MAY be chosen by the receiver.  If a
>   larger window size is chosen, it MUST be a multiple of 32.  If any
>   window size other than the default of 64 is employed by the receiver,
>   it MUST be reported to the transmitter during SA negotiation.
>
>   The "right" edge of the window represents the highest, validated
>   Sequence Number value received on this SA.  Packets that contain
>   Sequence Numbers lower than the "left" edge of the window are
>   rejected.  Packets falling within the window are checked against a
>   list of received packets within the window.  An efficient means for
>   performing this check, based on the use of a bit mask, is described
>
>
>Kent, Atkinson                                                 [Page 13]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>   in the Security Architecture document.
>
>   If the received packet falls within the window and is new, or if the
>   packet is to the right of the window, then the receiver proceeds to
>   ICV verification.  If the ICV validation fails, the receiver MUST
>   discard the received IP datagram as invalid; this is an auditable
>   event.  The audit log entry for this event SHOULD include the SPI
>   value, date/time, Source Address, Destination Address, the Sequence
>   Number, and (in IPv6) the Flow ID.  The receive window is updated
>   only if the ICV verification succeeds.
>
>   DISCUSSION:
>
>      Note that if the packet is either inside the window and new, or is
>      outside the window on the "right" side, the receiver MUST
>      authenticate the packet before updating the Sequence Number window
>      data.
>
>3.3.4  Integrity Check Value Verification
>
>   If authentication has been selected, the receiver computes the ICV
>   over the ESP packet minus the Authentication Data using the specified
>   authentication algorithm and verifies that it is the same as the ICV
>   included in the Authentication Data field of the packet.  Details of
>   the computation are provided below.
>
>   If the computed and received ICV's match, then the datagram is valid,
>   and it is accepted.  If the test fails, then the receiver MUST
>   discard the received IP datagram as invalid; this is an auditable
>   event.  The log data SHOULD include the SPI value, date/time
>   received, Source Address, Destination Address, and (in IPv6) the
>   cleartext Flow ID.
>
>   DISCUSSION:
>
>      Begin by removing and saving the ICV value (Authentication Data
>      field).  Next check the overall length of the ESP packet minus the
>      Authentication Data.  If implicit padding is required, based on
>      the blocksize of the authentication algorithm, append zero-filled
>      bytes to the end of the ESP packet directly after the Next Header
>      field.  Perform the ICV computation and compare the result with
>      the saved value.  (For the mandatory-to-implement authentication
>      algorithms, HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5
>      [Riv92], the output of the HMAC computation is truncated to the
>      leftmost 96 bits.  Other algorithms may have different ICV
>      lengths.) (If a digital signature and one-way hash are used for
>      the ICV computation, the matching process is more complex and will
>
>
>Kent, Atkinson                                                 [Page 14]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>      be described in the algorithm specification.)
>
>
>3.3.5  Packet Decryption
>
>   The receiver decrypts the ESP Payload Data, Padding, Pad Length, and
>   Next Header using the session key that has been established for this
>   traffic.  If an explicit IV is present in the Payload Field, it is
>   input to the decryption algorithm as per the algorithm specification.
>   If an implicit IV is employed, a local version of the IV is
>   constructed and input to the decryption algorithm as per the
>   algorithm specification.  (Decryption may take place in parallel with
>   authentication, but care must be taken to avoid possible race
>   conditions with regard to packet access and reconstruction of the
>   decrypted packet.)
>
>   After decryption, the original IP datagram is reconstructed and
>   processed per the normal IP protocol specification.  The exact steps
>   for reconstructing the original datagram depend on the mode (tunnel
>   vs transport) and are described in the Security Architecture
>   document.  At a minimum, in an IPv6 context, the receiver SHOULD
>   ensure that the decrypted data is 8-byte aligned, to facilitate
>   processing by the protocol identified in the Next Header field.
>
>   Note that there are two ways in which the decryption can "fail".  The
>   selected SA may not be correct or the encrypted ESP packet could be
>   corrupted.  (The latter case would be detected if authentication is
>   selected for the SA, as would tampering with the SPI.  However, an SA
>   mismatch might still occur due to tampering with the IP Destination
>   Address.)  In either case, the erroneous result of the decryption
>   operation (an invalid IP datagram or transport-layer frame) will not
>   necessarily be detected by IPsec, and is the responsibility of later
>   protocol processing.
>
>
>4. Auditing
>
>   Not all systems that implement ESP will implement auditing.  However,
>   if ESP is incorporated into a system that supports auditing, then the
>   ESP implementation MUST also support auditing and MUST allow a system
>   administrator to enable or disable auditing for ESP.  For the most
>   part, the granularity of auditing is a local matter.  However,
>   several auditable events are identified in this specification and for
>   each of these events a minimum set of information that SHOULD be
>   included in an audit log is defined.  Additional information also MAY
>   be included in the audit log for each of these events, and additional
>   events, not explicitly called out in this specification, also MAY
>
>
>Kent, Atkinson                                                 [Page 15]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>   result in audit log entries.  There is no requirement for the
>   receiver to transmit any message to the purported transmitter in
>   response to the detection of an auditable event, because of the
>   potential to induce denial of service via such action.
>
>5.  Conformance Requirements
>
>   Implementations that claim conformance or compliance with this
>   specification MUST implement the ESP syntax and processing described
>   here and MUST comply with all requirements of the Security
>   Architecture document.  If the key used to compute an ICV is manually
>   distributed, correct provision of the anti-replay service would
>   require correct maintenance of the counter state at the transmitter,
>   until the key is replaced, and there likely would be no automated
>   recovery provision if counter overflow were imminent.  Thus a
>   compliant implementation SHOULD NOT provide this service in
>   conjunction with SAs that are manually keyed.  A compliant ESP
>   implementation MUST support the following mandatory-to-implement
>   algorithms (specified in [KBC97] and in [MS97].
>
>             - DES in CBC mode
>             - HMAC with MD5
>             - HMAC with SHA-1
>
>
>
>6.  Security Considerations
>
>   Security is central to the design of this protocol, and this security
>   considerations permeate the specification.  Additional security-
>   relevant aspects of using IPsec protocol are discussed in the
>   Security Architecture document.
>
>
>7. Differences from RFC 1827
>
>   This document differs from RFC 1827 [ATK95] in several significant
>   ways.  The major difference is that, this document attempts to
>   specify a complete framework and context for ESP, whereas RFC 1827
>   provided a "shell" that was completed through the definition of
>   transforms.  The combinatorial growth of transforms motivated the
>   reformulation of the ESP specification as a more complete document,
>   with options for security services that may be offered in the context
>   of ESP.  Thus, fields previously defined in transform documents are
>   now part of this base ESP specification.  For example, the fields
>   necessary to support authentication (and anti-replay) are now defined
>   here, even though the provision of this service is an option.  The
>
>
>Kent, Atkinson                                                 [Page 16]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>   fields used to support padding for encryption, and for next protocol
>   identification, are now defined here as well.  Packet processing
>   consistent with the definition of these fields also is included in
>   the document.
>
>
>Acknowledgements
>
>   Many of the concepts embodied in this specification were derived from
>   or influenced by the US Government's SP3 security protocol, ISO/IEC's
>   NLSP, or from the proposed swIPe security protocol.  [SDNS89, ISO92
>   IB93].
>
>   For over 2 years, this document has evolved through multiple versions
>   and iterations.  During this time, many people have contributed
>   significant ideas and energy to the process and the documents
>   themselves.  The authors would like to thank Karen Seo for providing
>   extensive help in the review, editing, background research, and
>   coordination for this version of the specification.  The authors
>   would also like to thank the members of the IPSEC and IPng working
>   groups, with special mention of the efforts of (in alphabetic order):
>   Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David
>   Mihelcic, Hilarie Orman, William Simpson and Nina Yuan.
>
>References
>
>
>   [ATK95]   R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC
>             1827, August 1997.
>
>   [Bel89]   Steven M. Bellovin, "Security Problems in the TCP/IP
>             Protocol Suite", ACM Computer Communications Review, Vol.
>             19, No. 2, March 1989.
>
>   [Bel96]   Steven M. Bellovin, "Problem Areas for the IP Security
>             Protocols", Proceedings of the Sixth Usenix Unix Security
>             Symposium, July, 1996.
>
>   [CERT95]  Computer Emergency Response Team (CERT), "IP Spoofing
>             Attacks and Hijacked Terminal Connections", CA-95:01,
>             January 1995.  Available via anonymous ftp from
>             info.cert.org.
>
>   [DH95]    Steve Deering & Robert Hinden, Internet Protocol Version 6
>             (Ipv6)  Specification, RFC 1883, December 1995.
>
>   [IB93]    John Ioannidis & Matt Blaze, "Architecture and
>
>
>Kent, Atkinson                                                 [Page 17]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>             Implementation of Network-layer Security Under Unix",
>             Proceedings of the USENIX Security Symposium, Santa Clara,
>             CA, October 1993.
>
>   [ISO92]   ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
>             DIS 11577, International Standards Organisation, Geneva,
>             Switzerland, 29 November 1992.
>
>   [KA97a]   Steve Kent, Randall Atkinson, "Security Architecture for
>             the Internet Protocol", Internet Draft, ?? 1997.
>
>   [KA97b]   Steve Kent, Randall Atkinson, "IP Authentication Header",
>             Internet Draft, ?? 1997.
>
>   [KBC97]   Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC:
>             Keyed-Hashing for Message Authentication", RFC-2104,
>             February 1997.
>
>   [Ken91]   Steve Kent, "US DoD Security Options for the Internet
>             Protocol (IPSO)", RFC-1108, November 1991.
>
>   [MS97]    Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform",
>             RFC-xxxx, August 1997.
>
>   [NIST77]  US National Bureau of Standards, "Data Encryption
>             Standard", Federal Information Processing Standard (FIPS)
>             Publication 46, January 1977.
>
>   [NIST80]  US National Bureau of Standards, "DES Modes of Operation"
>             Federal Information Processing Standard (FIPS) Publication
>             81, December 1980.
>
>   [NIST81]  US National Bureau of Standards, "Guidelines for
>             Implementing and Using the Data Encryption Standard",
>             Federal Information Processing Standard (FIPS) Publication
>             74, April 1981.
>
>   [NIST88]  US National Bureau of Standards, "Data Encryption
>             Standard", Federal Information Processing Standard (FIPS)
>             Publication 46-1, January 1988.
>
>   [Riv92]   Ronald Rivest, "The MD5 Message Digest Algorithm," RFC-
>             1321, April 1992.
>
>   [SHA]     NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995
>
>   [STD-2]   J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20
>
>
>Kent, Atkinson                                                 [Page 18]
>
>
>Internet Draft              IP Encapsulating                21 July 1997
>                         Security Payload (ESP)
>
>
>             October 1994.
>
>   [Sch94]   Bruce Schneier, Applied Cryptography, John Wiley & Sons,
>             New York, NY, 1994. ISBN 0-471-59756-2
>
>   [SDNS89]  SDNS Secure Data Network System, Security Protocol 3, SP3,
>             Document SDN.301, Revision 1.5, 15 May 1989, as published
>             in NIST Publication NIST-IR-90-4250, February 1990.
>
>
>Disclaimer
>
>   The views and specification here are those of the authors and are not
>   necessarily those of their employers.  The authors and their
>   employers specifically disclaim responsibility for any problems
>   arising from correct or incorrect implementation or use of this
>   specification.
>
>
>
>Author Information
>
>   Stephen Kent
>   BBN Corporation
>   70 Fawcett Street
>   Cambridge, MA  02140
>   USA
>   E-mail: kent@bbn.com
>   Telephone: +1 (617) 873-3988
>
>   Randall Atkinson
>   @Home Network
>   385 Ravendale Drive
>   Mountain View, CA 94043
>   USA
>   E-mail: rja@inet.org
>
>
>
>
>
>
>
>
>
>
>
>
>
>Kent, Atkinson                                                 [Page 19]
>
>
>