rfc1827.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        R. Atkinson
Request for Comments: 1827                     Naval Research Laboratory
Category: Standards Track                                    August 1995


                IP Encapsulating Security Payload (ESP)

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.

ABSTRACT

   This document describes the IP Encapsulating Security Payload (ESP).
   ESP is a mechanism for providing integrity and confidentiality to IP
   datagrams.  In some circumstances it can also provide authentication
   to IP datagrams.  The mechanism works with both IPv4 and IPv6.

1. INTRODUCTION

   ESP is a mechanism for providing integrity and confidentiality to IP
   datagrams.  It may also provide authentication, depending on which
   algorithm and algorithm mode are used.  Non-repudiation and
   protection from traffic analysis are not provided by ESP.  The IP
   Authentication Header (AH) might provide non-repudiation if used with
   certain authentication algorithms [Atk95b].  The IP Authentication
   Header may be used in conjunction with ESP to provide authentication.
   Users desiring integrity and authentication without confidentiality
   should use the IP Authentication Header (AH) instead of ESP.  This
   document assumes that the reader is familiar with the related
   document "IP Security Architecture", which defines the overall
   Internet-layer security architecture for IPv4 and IPv6 and provides
   important background for this specification [Atk95a].

1.1 Overview

   The IP Encapsulating Security Payload (ESP) seeks to provide
   confidentiality and integrity by encrypting data to be protected and
   placing the encrypted data in the data portion of the IP
   Encapsulating Security Payload.  Depending on the user's security
   requirements, this mechanism may be used to encrypt either a
   transport-layer segment (e.g., TCP, UDP, ICMP, IGMP) or an entire IP
   datagram.  Encapsulating the protected data is necessary to provide
   confidentiality for the entire original datagram.



Atkinson                    Standards Track                     [Page 1]

RFC 1827             Encapsulating Security Payload          August 1995


   Use of this specification will increase the IP protocol processing
   costs in participating systems and will also increase the
   communications latency.  The increased latency is primarily due to
   the encryption and decryption required for each IP datagram
   containing an Encapsulating Security Payload.

   In Tunnel-mode ESP, the original IP datagram is placed in the
   encrypted portion of the Encapsulating Security Payload and that
   entire ESP frame is placed within a datagram having unencrypted IP
   headers.  The information in the unencrypted IP headers is used to
   route the secure datagram from origin to destination. An unencrypted
   IP Routing Header might be included between the IP Header and the
   Encapsulating Security Payload.

   In Transport-mode ESP, the ESP header is inserted into the IP
   datagram immediately prior to the transport-layer protocol header
   (e.g., TCP, UDP, or ICMP). In this mode bandwidth is conserved
   because there are no encrypted IP headers or IP options.

   In the case of IP, an IP Authentication Header may be present as a
   header of an unencrypted IP packet, as a header after the IP header
   and before the ESP header in a Transport-mode ESP packet, and also as
   a header within the encrypted portion of a Tunnel-mode ESP packet.
   When AH is present both in the cleartext IP header and also inside a
   Tunnel-mode ESP header of a single packet, the unencrypted IPv6
   Authentication Header is primarily used to provide protection for the
   contents of the unencrypted IP headers and the encrypted
   Authentication Header is used to provide authentication only for the
   encrypted IP packet.  This is discussed in more detail later in this
   document.

   The Encapsulating Security Payload is structured a bit differently
   than other IP payloads. The first component of the ESP payload
   consist of the unencrypted field(s) of the payload.  The second
   component consists of encrypted data.  The field(s) of the
   unencrypted ESP header inform the intended receiver how to properly
   decrypt and process the encrypted data.  The encrypted data component
   includes protected fields for the security protocol and also the
   encrypted encapsulated IP datagram.

   The concept of a "Security Association" is fundamental to ESP.  It is
   described in detail in the companion document "Security Architecture
   for the Internet Protocol" which is incorporated here by reference
   [Atk95a].  Implementors should read that document before reading this
   one.






Atkinson                    Standards Track                     [Page 2]

RFC 1827             Encapsulating Security Payload          August 1995


1.2 Requirements Terminology

   In this document, the words that are used to define the significance
   of each particular requirement are usually capitalised.  These words
   are:

   - MUST

      This word or the adjective "REQUIRED" means that the item is an
      absolute requirement of the specification.

   - SHOULD

      This word or the adjective "RECOMMENDED" means that there might
      exist valid reasons in particular circumstances to ignore this
      item, but the full implications should be understood and the case
      carefully weighed before taking a different course.

   - MAY

      This word or the adjective "OPTIONAL" means that this item is
      truly optional.  One vendor might choose to include the item
      because a particular marketplace requires it or because it
      enhances the product, for example; another vendor may omit the
      same item.

2. KEY MANAGEMENT

   Key management is an important part of the IP security architecture.
   However, a specific key management protocol is not included in this
   specification because of a long history in the public literature of
   subtle flaws in key management algorithms and protocols.  IP tries to
   decouple the key management mechanisms from the security protocol
   mechanisms.  The only coupling between the key management protocol
   and the security protocol is with the Security Parameter Index (SPI),
   which is described in more detail below.  This decoupling permits
   several different key management mechanisms to be used.  More
   importantly, it permits the key management protocol to be changed or
   corrected without unduly impacting the security protocol
   implementations. Thus, a key management protocol for IP is not
   specified within this memo.  The IP Security Architecture describes
   key management in more detail and specifies the key management
   requirements for IP.  Those key management requirements are
   incorporated here by reference [Atk95a].

   The key management mechanism is used to negotiate a number of
   parameters for each security association, including not only the keys
   but other information (e.g., the cryptographic algorithms and modes,



Atkinson                    Standards Track                     [Page 3]

RFC 1827             Encapsulating Security Payload          August 1995


   security classification level, if any) used by the communicating
   parties.  The key management protocol implementation usually creates
   and maintains a logical table containing the several parameters for
   each current security association. An ESP implementation normally
   needs to read that security parameter table to determine how to
   process each datagram containing an ESP (e.g., which algorithm/mode
   and key to use).

3. ENCAPSULATING SECURITY PAYLOAD SYNTAX

   The Encapsulating Security Payload (ESP) may appear anywhere after
   the IP header and before the final transport-layer protocol.  The
   Internet Assigned Numbers Authority has assigned Protocol Number 50
   to ESP [STD-2].  The header immediately preceding an ESP header will
   always contain the value 50 in its Next Header (IPv6) or Protocol
   (IPv4) field.  ESP consists of an unencrypted header followed by
   encrypted data.  The encrypted data includes both the protected ESP
   header fields and the protected user data, which is either an entire
   IP datagram or an upper-layer protocol frame (e.g., TCP or UDP).  A
   high-level diagram of a secure IP datagram follows.

  |<--        Unencrypted              -->|<----    Encrypted   ------>|
  +-------------+--------------------+------------+---------------------+
  | IP Header   | Other IP Headers   | ESP Header | encrypted data      |
  +-------------+--------------------+------------+---------------------+

   A more detailed diagram of the ESP Header follows below.

  +-------------+--------------------+------------+---------------------+
  |             Security Association Identifier (SPI), 32 bits          |
  +=============+====================+============+=====================+
  |             Opaque Transform Data, variable length                  |
  +-------------+--------------------+------------+---------------------+

   Encryption and authentication algorithms, and the precise format of
   the Opaque Transform Data associated with them are known as
   "transforms".  The ESP format is designed to support new transforms
   in the future to support new or additional cryptographic algorithms.
   The transforms are specified by themselves rather than in the main
   body of this specification.  The mandatory transform for use with IP
   is defined in a separate document [KMS95].  Other optional transforms
   exist in other separate specifications and additional transforms
   might be defined in the future.








Atkinson                    Standards Track                     [Page 4]

RFC 1827             Encapsulating Security Payload          August 1995


3.1 Fields of the Encapsulating Security Payload

   The SPI is a 32-bit pseudo-random value identifying the security
   association for this datagram.  If no security association has been
   established, the value of the SPI field shall be 0x00000000.   An SPI
   is similar to the SAID used in other security protocols.  The name
   has been changed because the semantics used here are not exactly the
   same as those used in other security protocols.

   The set of SPI values in the range 0x00000001 though 0x000000FF are
   reserved to the Internet Assigned Numbers Authority (IANA) for future
   use.  A reserved SPI value will not normally be assigned by IANA
   unless the use of that particular assigned SPI value is openly
   specified in an RFC.

   The SPI is the only mandatory transform-independent field.
   Particular transforms may have other fields unique to the transform.
   Transforms are not specified in this document.

3.2 Security Labeling with ESP

   The encrypted IP datagram need not and does not normally contain any
   explicit Security Label because the SPI indicates the sensitivity
   level.  This is an improvement over the current practices with IPv4
   where an explicit Sensitivity Label is normally used with
   Compartmented Mode Workstations and other systems requiring Security
   Labels [Ken91] [DIA].  In some situations, users MAY choose to carry
   explicit labels (for example, IPSO labels as defined by RFC-1108
   might be used with IPv4) in addition to using the implicit labels
   provided by ESP.  Explicit label options could be defined for use
   with IPv6 (e.g., using the IPv6 End-to-End Options Header or the IPv6
   Hop-by-Hop Options Header).  Implementations MAY support explicit
   labels in addition to implicit labels, but implementations are not
   required to support explicit labels.  Implementations of ESP in
   systems claiming to provide multi-level security MUST support
   implicit labels.

4. ENCAPSULATING SECURITY PROTOCOL PROCESSING

   This section describes the steps taken when ESP is in use between two
   communicating parties.  Multicast is different from unicast only in
   the area of key management (See the definition of the SPI, above, for
   more detail on this).  There are two modes of use for ESP.  The first
   mode, which is called "Tunnel-mode", encapsulates an entire IP
   datagram inside ESP.  The second mode, which is called "Transport-
   Mode", encapsulates a transport-layer (e.g., UDP, TCP) frame inside
   ESP.  The term "Transport-mode" must not be misconstrued as
   restricting its use to TCP and UDP. For example, an ICMP message MAY



Atkinson                    Standards Track                     [Page 5]

RFC 1827             Encapsulating Security Payload          August 1995


   be sent either using the "Transport-mode" or the "Tunnel-mode"
   depending upon circumstance.  ESP processing occurs prior to IP
   fragmentation on output and after IP reassembly on input.  This
   section describes protocol processing for each of these two modes.

4.1 ESP in Tunnel-mode

   In Tunnel-mode ESP, the ESP header follows all of the end-to-end
   headers (e.g., Authentication Header, if present in cleartext) and
   immediately precedes an tunnelled IP datagram.

   The sender takes the original IP datagram, encapsulates it into the
   ESP, uses at least the sending userid and Destination Address as data
   to locate the correct Security Association, and then applies the
   appropriate encryption transform.  If host-oriented keying is in use,
   then all sending userids on a given system will have the same
   Security Association for a given Destination Address.  If no key has
   been established, then the key management mechanism is used to
   establish an encryption key for this communications session prior to
   the use of ESP.  The (now encrypted) ESP is then encapsulated in a
   cleartext IP datagram as the last payload.  If strict red/black
   separation is being enforced, then the addressing and other
   information in the cleartext IP headers and optional payloads MAY be
   different from the values contained in the (now encrypted and
   encapsulated) original datagram.

   The receiver strips off the cleartext IP header and cleartext
   optional IP payloads (if any) and discards them.  It then uses the
   combination of Destination Address and SPI value to locate the
   correct session key to use for this packet.  It then decrypts the ESP
   using the session key that was just located for this packet.

   If no valid Security Association exists for this session (for
   example, the receiver has no key), the receiver MUST discard the
   encrypted ESP and the failure MUST be recorded in the system log or
   audit log.  This system log or audit log entry SHOULD include the SPI
   value, date/time, cleartext Sending Address, cleartext Destination
   Address, and the cleartext Flow ID.  The log entry MAY also include
   other identifying data.  The receiver might not wish to react by
   immediately informing the sender of this failure because of the
   strong potential for easy-to-exploit denial of service attacks.

   If decryption succeeds, the original IP datagram is then removed from
   the (now decrypted) ESP.  This original IP datagram is then processed
   as per the normal IP protocol specification.  In the case of system
   claiming to provide multilevel security (for example, a B1 or
   Compartmented Mode Workstation) additional appropriate mandatory
   access controls MUST be applied based on the security level of the



Atkinson                    Standards Track                     [Page 6]