support generation and consumption of padding.

           a. For the purpose of ensuring that the bits to be encrypted
              are a multiple of the algorithm's blocksize (first bullet
              above), the padding computation applies to the Payload
              Data exclusive of the IV, the Pad Length, and Next Header
              fields.

           b. For the purposes of ensuring that the Authentication Data
              is aligned on a 4-byte boundary (second bullet above), the
              padding computation applies to the Payload Data inclusive
              of the IV, the Pad Length, and Next Header fields.

   If Padding bytes are needed but the encryption algorithm does not
   specify the padding contents, then the following default processing
   MUST be used.  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.)

   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




 
RFC 2406           IP Encapsulating Security Payload       November 1998


   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 is specified by the
   authentication function selected.  The Authentication Data field is
   optional, and is included only if the authentication service has been
   selected for the SA in question.  The authentication algorithm
   specification MUST specify the length of the ICV and the comparison
   rules and processing steps for validation.

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-
   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.  In the context of




 
RFC 2406           IP Encapsulating Security Payload       November 1998


   IPv4, this translates to placing ESP after the IP header (and any
   options that it contains), but before the upper layer protocol.