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

ESP Introduction

> From: Stephen Kent <kent@bbn.com>
> I also don't understand Bill's explanation of the difference between an
> SAID and an SPI, since an SA is identified by the SPI (in context).

As I noted, this latter assumption is in error.

Unfortunately, Kent's lack of understanding lead to a significant
problem with the ESP terminology used throughout.

For example, in the introduction, s/he writes:

   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

Since the SPI is destination based, and does not imply a particular
sender (especially in a multicast environment) or Security Association,
"data origin authentication" is not provided by ESP.

Technically, "data origin authentication" requires a long term key,
usually verified in the form of a signature.  It is a term normally
reserved for applications such as email.  ESP is defined for ephemeral
keys.  Again, "data origin authentication" is not provided by ESP.

As I've noted before on this list, Internet Protocols do not provide
"connectionless" anything.  Perhaps Kent meant to use the technical term
"datagram".  Most of us would simply say "data integrity".

In any case, the integrity can either be provided by the cipher or the
independent authenticator algorithms, and should not be listed as a
special "feature" of ESP.  We argued this long ago.  I remember a very
critical Rogaway draft.  Indeed, after defining it as a separate ESP
feature, Kent consolidates it under "authentication" in the remainder of
the draft.

The term "gateway" is incorrect (obsolete term for "router") or limiting
(as in application gateway).

Inexplicably, the _useful_ RFC-1827 "Overview" is entirely missing.  The
RFC-1827 "Requirements Terminology" is missing, and should be RFC-2116.
The RFC-1827 "Key Management" information is missing, although some of
that belonged in the Architecture.  The RFC-1827 "transform" language is
missing.

**** And, Kent has refused to incorporate the WG consensus that ****
**** authentication-only should use AH, not ESP.                ****

In all, I found over a dozen errors in the Introduction alone.  I won't
bore you with all of them.

**** Most egregious is that it is missing critical information  ****
**** from RFC-1827: the IP Next Header/Protocol number :-(.     ****

Here is a replacement:

1.  Introduction

   The Encapsulating Security Payload (ESP) provides confidentiality for
   IP datagrams by encrypting the payload data to be protected.  Depend-
   ing on the user's security requirements, either an upper protocol-
   layer segment (such as TCP or UDP) is encrypted (transport-mode), or
   an entire IP datagram is encrypted and tunneled to the destination
   (tunnel-mode).

   To work properly without changing the entire Internet infrastructure
   (particularly non-participating routers), ESP is placed within a
   datagram having unencrypted IP headers.  The information in the unen-
   crypted IP headers is used to route the protected datagram.

   For more details about ESP in various network environments, see
   "Security Architecture for the Internet Protocol" [RFC-1825x].  That
   document provides important background for this specification, such
   as an explanation of Security Associations, forms of Security Associ-
   ation management, guidelines on transport and tunnel modes of opera-
   tion, and interaction between ESP and the Authentication Header (AH)
   [RFC-1826x].

   ESP may optionally provide authentication and integrity.  Users
   desiring authentication and/or integrity without confidentiality
   should use AH instead of ESP.

   ESP may also provide a form of anti-replay service, depending upon
   the selection of integrity.  The enforcement of replay protection is
   solely at the discretion of the receiver.

   Security services can be provided between:

   -  a pair of single user hosts,

   -  a single user host and a security firewall router, or

   -  a pair of firewall routers.

   In the latter case, together with the tunnel mode of encapsulation,
   ESP may provide traffic flow confidentiality.  Traffic aggregation at
   the firewalls may be able to mask source to destination patterns of
   the protected internal users.

   In this document, the key words "MAY", "MUST", "optional", "recom-
   mended", "required", "SHOULD", and "SHOULD NOT", are to be inter-
   preted as described in [RFC-2119].

1.1.  Performance

   Use of this specification will increase the protocol processing costs
   in participating systems, and will also increase the communications
   latency.  The increased latency is primarily due to time required for
   encryption and decryption of each datagram.  This can be very time
   intensive to implement.


1.2.  Construction

   ESP may appear as the final payload header.  The header immediately
   preceding the ESP Header will always contain the value 50 (0x32) in
   its Next Header (Protocol) field.

    <--             Transparent              --> <-- Opaque -->
   +-----------+-----------------+--------------+--------------+
   | IP Header |  other headers  |  ESP Header  |   ESP Data   |
   +-----------+-----------------+--------------+--------------+

   The Encapsulating Security Payload has two components.

   The transparent ESP Header consists of the unencrypted field(s) of
   the payload.  The transparent field(s) of the unencrypted ESP Header
   inform the intended recipient how to properly process the opaque
   data.

   The opaque ESP Data consists of protected fields for the ESP trans-
   form(s).


1.3.  Transforms

   Cipher and authenticator algorithms, and the precise format of opaque
   ESP data associated with them, are known as "ESP transforms".  It is
   intended that the ESP format should be sufficiently general to permit
   the specification of new transforms as new cryptographic algorithms
   are developed.

   The parameter description requirements for companion transform docu-
   ments are described in [RoadMap].

   When the optional authenticator transform requires a separate key,
   that key is generated after any cipher keys.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: