As per Relevance of the word encapsulating, we have this rfc below:
Network Working Group R.
Request for Comments: 1827 Naval Research
Category: Standards Track August 1995
IP Encapsulating Security Payload (ESP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document describes the IP Encapsulating Security Payload (ESP).
ESP is a mechanism for providing integrity and confidentiality to
datagrams. In some circumstances it can also provide
to IP datagrams. The mechanism works with both IPv4 and IPv6.
1.
ESP is a mechanism for providing integrity and confidentiality to
datagrams. It may also provide authentication, depending on
algorithm and algorithm mode are used. Non-repudiation
protection from traffic analysis are not provided by ESP. The
Authentication Header (AH) might provide non-repudiation if used
certain authentication algorithms [Atk95b]. The IP
Header may be used in conjunction with ESP to provide authentication
Users desiring integrity and authentication without
should use the IP Authentication Header (AH) instead of ESP.
document assumes that the reader is familiar with the
document "IP Security Architecture", which defines the
Internet-layer security architecture for IPv4 and IPv6 and
important background for this specification [Atk95a].
1.1
The IP Encapsulating Security Payload (ESP) seeks to
confidentiality and integrity by encrypting data to be protected
placing the encrypted data in the data portion of the
Encapsulating Security Payload. Depending on the user's
requirements, this mechanism may be used to encrypt either
transport-layer segment (e.g., TCP, UDP, ICMP, IGMP) or an entire
datagram. Encapsulating the protected data is necessary to
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
costs in participating systems and will also increase
communications latency. The increased latency is primarily due
the encryption and decryption required for each IP
containing an Encapsulating Security Payload
In Tunnel-mode ESP, the original IP datagram is placed in
encrypted portion of the Encapsulating Security Payload and
entire ESP frame is placed within a datagram having unencrypted
headers. The information in the unencrypted IP headers is used
route the secure datagram from origin to destination. An
IP Routing Header might be included between the IP Header and
Encapsulating Security Payload
In Transport-mode ESP, the ESP header is inserted into the
datagram immediately prior to the transport-layer protocol
(e.g., TCP, UDP, or ICMP). In this mode bandwidth is
because there are no encrypted IP headers or IP options
In the case of IP, an IP Authentication Header may be present as
header of an unencrypted IP packet, as a header after the IP
and before the ESP header in a Transport-mode ESP packet, and also
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
Tunnel-mode ESP header of a single packet, the unencrypted IPv
Authentication Header is primarily used to provide protection for
contents of the unencrypted IP headers and the
Authentication Header is used to provide authentication only for
encrypted IP packet. This is discussed in more detail later in
document
The Encapsulating Security Payload is structured a bit
than other IP payloads. The first component of the ESP
consist of the unencrypted field(s) of the payload. The
component consists of encrypted data. The field(s) of
unencrypted ESP header inform the intended receiver how to
decrypt and process the encrypted data. The encrypted data
includes protected fields for the security protocol and also
encrypted encapsulated IP datagram
The concept of a "Security Association" is fundamental to ESP. It
described in detail in the companion document "Security
for the Internet Protocol" which is incorporated here by
[Atk95a]. Implementors should read that document before reading
one
Atkinson Standards Track [Page 2]
RFC 1827 Encapsulating Security Payload August 1995
1.2 Requirements
In this document, the words that are used to define the
of each particular requirement are usually capitalised. These
are
-
This word or the adjective "REQUIRED" means that the item is
absolute requirement of the specification
-
This word or the adjective "RECOMMENDED" means that there
exist valid reasons in particular circumstances to ignore
item, but the full implications should be understood and the
carefully weighed before taking a different course
-
This word or the adjective "OPTIONAL" means that this item
truly optional. One vendor might choose to include the
because a particular marketplace requires it or because
enhances the product, for example; another vendor may omit
same item
2. KEY
Key management is an important part of the IP security architecture
However, a specific key management protocol is not included in
specification because of a long history in the public literature
subtle flaws in key management algorithms and protocols. IP tries
decouple the key management mechanisms from the security
mechanisms. The only coupling between the key management
and the security protocol is with the Security Parameter Index (SPI),
which is described in more detail below. This decoupling
several different key management mechanisms to be used.
importantly, it permits the key management protocol to be changed
corrected without unduly impacting the security
implementations. Thus, a key management protocol for IP is
specified within this memo. The IP Security Architecture
key management in more detail and specifies the key
requirements for IP. Those key management requirements
incorporated here by reference [Atk95a].
The key management mechanism is used to negotiate a number
parameters for each security association, including not only the
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
parties. The key management protocol implementation usually
and maintains a logical table containing the several parameters
each current security association. An ESP implementation
needs to read that security parameter table to determine how
process each datagram containing an ESP (e.g., which algorithm/
and key to use).
3. ENCAPSULATING SECURITY PAYLOAD
The Encapsulating Security Payload (ESP) may appear anywhere
the IP header and before the final transport-layer protocol.
Internet Assigned Numbers Authority has assigned Protocol Number 50
to ESP [STD-2]. The header immediately preceding an ESP header
always contain the value 50 in its Next Header (IPv6) or
(IPv4) field. ESP consists of an unencrypted header followed
encrypted data. The encrypted data includes both the protected
header fields and the protected user data, which is either an
IP datagram or an upper-layer protocol frame (e.g., TCP or UDP).
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
the Opaque Transform Data associated with them are known
"transforms". The ESP format is designed to support new
in the future to support new or additional cryptographic algorithms
The transforms are specified by themselves rather than in the
body of this specification. The mandatory transform for use with
is defined in a separate document [KMS95]. Other optional
exist in other separate specifications and additional
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
The SPI is a 32-bit pseudo-random value identifying the
association for this datagram. If no security association has
established, the value of the SPI field shall be 0x00000000. An
is similar to the SAID used in other security protocols. The
has been changed because the semantics used here are not exactly
same as those used in other security protocols
The set of SPI values in the range 0x00000001 though 0x000000FF
reserved to the Internet Assigned Numbers Authority (IANA) for
use. A reserved SPI value will not normally be assigned by
unless the use of that particular assigned SPI value is
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
The encrypted IP datagram need not and does not normally contain
explicit Security Label because the SPI indicates the
level. This is an improvement over the current practices with IPv
where an explicit Sensitivity Label is normally used
Compartmented Mode Workstations and other systems requiring
Labels [Ken91] [DIA]. In some situations, users MAY choose to
explicit labels (for example, IPSO labels as defined by RFC-1108
might be used with IPv4) in addition to using the implicit
provided by ESP. Explicit label options could be defined for
with IPv6 (e.g., using the IPv6 End-to-End Options Header or the IPv
Hop-by-Hop Options Header). Implementations MAY support
labels in addition to implicit labels, but implementations are
required to support explicit labels. Implementations of ESP
systems claiming to provide multi-level security MUST
implicit labels
4. ENCAPSULATING SECURITY PROTOCOL
This section describes the steps taken when ESP is in use between
communicating parties. Multicast is different from unicast only
the area of key management (See the definition of the SPI, above,
more detail on this). There are two modes of use for ESP. The
mode, which is called "Tunnel-mode", encapsulates an entire
datagram inside ESP. The second mode, which is called "Transport
Mode", encapsulates a transport-layer (e.g., UDP, TCP) frame
ESP. The term "Transport-mode" must not be misconstrued
restricting its use to TCP and UDP. For example, an ICMP message
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
fragmentation on output and after IP reassembly on input.
section describes protocol processing for each of these two modes
4.1 ESP in Tunnel-
In Tunnel-mode ESP, the ESP header follows all of the end-to-
headers (e.g., Authentication Header, if present in cleartext)
immediately precedes an tunnelled IP datagram
The sender takes the original IP datagram, encapsulates it into
ESP, uses at least the sending userid and Destination Address as
to locate the correct Security Association, and then applies
appropriate encryption transform. If host-oriented keying is in use
then all sending userids on a given system will have the
Security Association for a given Destination Address. If no key
been established, then the key management mechanism is used
establish an encryption key for this communications session prior
the use of ESP. The (now encrypted) ESP is then encapsulated in
cleartext IP datagram as the last payload. If strict red/
separation is being enforced, then the addressing and
information in the cleartext IP headers and optional payloads MAY
different from the values contained in the (now encrypted
encapsulated) original datagram
The receiver strips off the cleartext IP header and
optional IP payloads (if any) and discards them. It then uses
combination of Destination Address and SPI value to locate
correct session key to use for this packet. It then decrypts the
using the session key that was just located for this packet
If no valid Security Association exists for this session (
example, the receiver has no key), the receiver MUST discard
encrypted ESP and the failure MUST be recorded in the system log
audit log. This system log or audit log entry SHOULD include the
value, date/time, cleartext Sending Address, cleartext
Address, and the cleartext Flow ID. The log entry MAY also
other identifying data. The receiver might not wish to react
immediately informing the sender of this failure because of
strong potential for easy-to-exploit denial of service attacks
If decryption succeeds, the original IP datagram is then removed
the (now decrypted) ESP. This original IP datagram is then
as per the normal IP protocol specification. In the case of
claiming to provide multilevel security (for example, a B1
Compartmented Mode Workstation) additional appropriate
access controls MUST be applied based on the security level of
Atkinson Standards Track [Page 6]
RFC 1827 Encapsulating Security Payload August 1995
receiving process and the security level associated with
Security Association. If those mandatory access controls fail,
the packet SHOULD be discarded and the failure SHOULD be logged
implementation-specific procedures
4.2 ESP in Transport-
In Transport-mode ESP, the ESP header follows the end-to-end
(e.g., Authentication Header) and immediately precedes a transport
layer (e.g., UDP, TCP, ICMP) header
The sender takes the original transport-layer (e.g., UDP, TCP, ICMP
frame, encapsulates it into the ESP, uses at least the sending
and Destination Address to locate the appropriate
Association, and then applies the appropriate encryption transform
If host-oriented keying is in use, then all sending userids on
given system will have the same Security Association for a
Destination Address. If no key has been established, then the
management mechanism is used to establish a encryption key for
communications session prior to the encryption. The (now encrypted
ESP is then encapsulated as the last payload of a cleartext
datagram
The receiver processes the cleartext IP header and cleartext
IP headers (if any) and temporarily stores pertinent
(e.g., source and destination addresses, Flow ID, Routing Header).
It then decrypts the ESP using the session key that has
established for this traffic, using the combination of
destination address and the packet's Security Association
(SPI) to locate the correct key
If no key exists for this session or the attempt to decrypt fails
the encrypted ESP MUST be discarded and the failure MUST be
in the system log or audit log. If such a failure occurs,
recorded log data SHOULD include the SPI value, date/time received
clear-text Sending Address, clear-text Destination Address, and
Flow ID. The log data MAY also include other information about
failed packet. If decryption does not work properly for some reason
then the resulting data will not be parsable by the implementation'
protocol engine. Hence, failed decryption is generally detectable
If decryption succeeds, the original transport-layer (e.g., UDP, TCP
ICMP) frame is removed from the (now decrypted) ESP. The
from the cleartext IP header and the now decrypted transport-
header is jointly used to determine which application the data
be sent to. The data is then sent along to the
application as normally per IP protocol specification. In the
of a system claiming to provide multilevel security (for example,
Atkinson Standards Track [Page 7]
RFC 1827 Encapsulating Security Payload August 1995
B1 or Compartmented Mode Workstation), additional Mandatory
Controls MUST be applied based on the security level of the
process and the security level of the received packet's
Association
4.3.
Some transforms provide authentication as well as confidentiality
integrity. When such a transform is not used, then
Authentication Header might be used in conjunction with
Encapsulating Security Payload. There are two different
to using the Authentication Header with ESP, depending on which
is to be authenticated. The location of the Authentication
makes it clear which set of data is being authenticated
In the first usage, the entire received datagram is authenticated
including both the encrypted and unencrypted portions, while only
data sent after the ESP Header is confidential. In this usage,
sender first applies ESP to the data being protected. Then the
plaintext IP headers are prepended to the ESP header and its
encrypted data. Finally, the IP Authentication Header is
over the resulting datagram according to the normal method.
receipt, the receiver first verifies the authenticity of the
datagram using the normal IP Authentication Header process. Then
authentication succeeds, decryption using the normal IP ESP
occurs. If decryption is successful, then the resulting data
passed up to the upper layer
If the authentication process were to be applied only to the
protected by Tunnel-mode ESP, then the IP Authentication Header
be placed normally within that protected datagram. However, if
were using Transport-mode ESP, then the IP Authentication
would be placed before the ESP header and would be calculated
the entire IP datagram
If the Authentication Header is encapsulated within a Tunnel-mode
header, and both headers have specific security classification
associated with them, and the two security classification levels
not identical, then an error has occurred. That error SHOULD
recorded in the system log or audit log using the
described previously. It is not necessarily an error for
Authentication Header located outside of the ESP header to have
different security classification level than the ESP header'
classification level. This might be valid because the cleartext
headers might have a different classification level after the
has been encrypted using ESP
Atkinson Standards Track [Page 8]
RFC 1827 Encapsulating Security Payload August 1995
5. CONFORMANCE
Implementations that claim conformance or compliance with
specification MUST fully implement the header described here,
support manual key distribution with this header, MUST comply
all requirements of the "Security Architecture for the
Protocol" [Atk95a], and MUST support the use of DES CBC as
in the companion document entitled "The ESP DES-CBC Transform
[KMS95]. Implementors MAY also implement other ESP transforms
Implementers should consult the most recent version of the "
Official Standards" RFC for further guidance on the status of
document
6. SECURITY
This entire document discusses a security mechanism for use with IP
This mechanism is not a panacea, but it does provide an
component useful in creating a secure internetwork
Cryptographic transforms for ESP which use a block-chaining
and lack a strong integrity mechanism are vulnerable to a cut-and
paste attack described by Bellovin and should not be used unless
Authentication Header is always present with packets using that
transform [Bel95].
Users need to understand that the quality of the security provided
this specification depends completely on the strength of
encryption algorithm has been implemented, the correctness of
algorithm's implementation, upon the security of the key
mechanism and its implementation, the strength of the key [CN94]
[Sch94, p233] and upon the correctness of the ESP and
implementations in all of the participating systems
If any of these assumptions do not hold, then little or no
security will be provided to the user. Use of high
development techniques is recommended for the IP
Security Payload
Users seeking protection from traffic analysis might consider the
of appropriate link encryption. Description and specification
link encryption is outside the scope of this note
If user-oriented keying is not in use, then the algorithm in
should not be an algorithm vulnerable to any kind of Chosen
attack. Chosen Plaintext attacks on DES are described in [BS93]
[Mat94]. Use of user-oriented keying is recommended in order
preclude any sort of Chosen Plaintext attack and to generally
cryptanalysis more difficult. Implementations SHOULD support user
Atkinson Standards Track [Page 9]
RFC 1827 Encapsulating Security Payload August 1995
oriented keying as is described in the IP Security
[Atk95a].
This document benefited greatly from work done by Bill Simpson,
Metzger, and Phil Karn to make general the approach
defined by the author for SIP, SIPP, and finally IPv6.
Many of the concepts here are derived from or were influenced by
US Government's SP3 security protocol specification, the ISO/IEC'
NLSP specification, or from the proposed swIPe security
[SDNS89, ISO92a, IB93, IBK93, ISO92b]. The use of DES
confidentiality is closely modeled on the work done for the SNMPv
[GM93]. Steve Bellovin, Steve Deering, Dave Mihelcic, and
Orman provided solid critiques of early versions of this memo
[Atk95a] Atkinson, R., "Security Architecture for the
Protocol", RFC 1825, NRL, August 1995.
[Atk95b] Atkinson, R., "IP Authentication Header", RFC 1826, NRL
August 1995.
[Bel89] Steven M. Bellovin, "Security Problems in the TCP/
Protocol Suite", ACM Computer Communications Review, Vol. 19,
No. 2, March 1989.
[Bel95] Steven M. Bellovin, Presentation at IP Security
Group Meeting, Proceedings of the 32nd Internet
Task Force, March 1995, Internet Engineering Task Force
Danvers, MA
[BS93] Eli Biham and Adi Shamir, "Differential Cryptanalysis of
Data Encryption Standard", Springer-Verlag, New York, NY
1993.
[CN94] John M. Carroll & Sri Nudiati, "On Weak Keys and Weak Data
Foiling the Two Nemeses", Cryptologia, Vol. 18, No. 23,
July 1994. pp. 253-280
[CERT95] Computer Emergency Response Team (CERT), "IP Spoofing
and Hijacked Terminal Connections", CA-95:01, January 1995.
Available via anonymous ftp from info.cert.org
Atkinson Standards Track [Page 10]
RFC 1827 Encapsulating Security Payload August 1995
[DIA] US Defense Intelligence Agency (DIA), "Compartmented
Workstation Specification", Technical
DDS-2600-6243-87.
[GM93] Galvin J., and K. McCloghrie, "Security Protocols
version 2 of the Simple Network Management
(SNMPv2)", RFC 1446, Trusted Information Systems, Hughes
Systems, April 1993.
[Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6)
Specification, Work in Progress, October 1994.
[IB93] John Ioannidis & Matt Blaze, "Architecture and
of Network-layer Security Under Unix", Proceedings of the
Security Symposium, Santa Clara, CA, October 1993.
[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe
Network-Layer Security for IP", presentation at the
1993 IETF Meeting, Columbus, Ohio
[ISO92a] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-
DIS 11577, International Standards Organisation, Geneva
Switzerland, 29 November 1992.
[ISO92b] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-
DIS 11577, Section 13.4.1, page 33, International
Organisation, Geneva, Switzerland, 29 November 1992.
[Ken91] Kent, S., "US DoD Security Options for the
Protocol", RFC 1108, BBN Communications, November 1991.
[KMS95] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-
Transform", RFC 1829, Qualcomm, Inc., Piermont, Daydreamer
August 1995.
[Mat94] Matsui, M., "Linear Cryptanalysis method for DES Cipher",
Proceedings of Eurocrypt '93, Berlin, Springer-Verlag, 1994.
[NIST77] US National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standard (FIPS)
46, January 1977.
[NIST80] US National Bureau of Standards, "DES Modes of Operation
Federal Information Processing Standard (FIPS)
81, December 1980.
Atkinson Standards Track [Page 11]
RFC 1827 Encapsulating Security Payload August 1995
[NIST81] US National Bureau of Standards, "Guidelines for
and Using the Data Encryption Standard", Federal
Processing Standard (FIPS) Publication 74, April 1981.
[NIST88] US National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standard (FIPS)
46-1, January 1988.
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, USC/Information Sciences Institute, 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
in NIST Publication NIST-IR-90-4250, February 1990.
The views and specification here are those of the author and are
necessarily those of his employer. The Naval Research Laboratory
not passed judgement on the merits, if any, of this work. The
and his employer specifically disclaim responsibility for
problems arising from correct or incorrect implementation or use
this specification
AUTHOR'S
Randall
Information Technology
Naval Research
Washington, DC 20375-5320
Phone: (202) 404-7090
Fax: (202) 404-7942
EMail: atkinson@itd.nrl.navy.
Atkinson Standards Track [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
