RFC 1827 (rfc1827) - Page 2 of 12
IP Encapsulating Security Payload (ESP)
Alternative Format: Original Text Document
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