RFC 1827

IP Encapsulating Security Payload (ESP)

📅 published August 1995, from ietf

RFC 1827: IP Encapsulating Security Payload (ESP) 🎀

okay bestie, this is RFC 1827 💖 It's from the Network Working Group, written by R. Atkinson at the Naval Research Laboratory. It's a Standards Track doc, and it's dated August 1995. Iconic, honestly 👑

Status of this Memo ✨

This doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅

ABSTRACT 🌸

This document describes the IP Encapsulating Security Payload (ESP). So ESP is a mechanism for giving IP datagrams integrity and confidentiality 🔥 In some circumstances it can also provide authentication to IP datagrams. And it works with both IPv4 and IPv6, which is so slay 🦋

1. INTRODUCTION 🦋

okay so 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 it's used with certain authentication algorithms [Atk95b]. The IP Authentication Header may be used together with ESP to provide authentication.

Users who want integrity and authentication without confidentiality should use the IP Authentication Header (AH) instead of ESP ✨ This doc assumes you already know the related document "IP Security Architecture". That one defines the overall Internet-layer security architecture for IPv4 and IPv6, and it gives you the important background for this spec [Atk95a]. Read it first, bestie 📚

1.1 Overview 🌈

So ESP tries to provide confidentiality and integrity by encrypting the data you want protected and putting that 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. Wrapping up the protected data is what gives confidentiality to the entire original datagram, so it's not optional, it's necessary 💅

Heads up, using this spec is going to increase the IP protocol processing costs in participating systems, and it'll bump up communications latency too 🙈 The latency hit is mostly from the encryption and decryption that's needed for every IP datagram carrying an Encapsulating Security Payload.

In Tunnel-mode ESP, the original IP datagram goes into the encrypted portion of the Encapsulating Security Payload 🧚 That whole ESP frame then sits inside a datagram that has unencrypted IP headers. Those unencrypted headers are what get 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 right before the transport-layer protocol header (e.g., TCP, UDP, or ICMP) ✨ This mode saves bandwidth, because there are no encrypted IP headers or IP options. Bandwidth bestie 🍓

In the case of IP, an IP Authentication Header may show up as a header on an unencrypted IP packet. It may also show up as a header after the IP header and before the ESP header in a Transport-mode ESP packet, and as a header inside 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 mainly there to protect the contents of the unencrypted IP headers. The encrypted Authentication Header is only used to provide authentication for the encrypted IP packet. We get into this more later in the doc 👑

The Encapsulating Security Payload is structured a bit differently from other IP payloads, and honestly that's the vibe 💅 The first component of the ESP payload consists of the unencrypted field(s) of the payload. The second component consists of encrypted data. The field(s) of the unencrypted ESP header tell 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's 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, no cap 🫶

1.2 Requirements Terminology 💜

In this document, the words that define how strong each particular requirement is are usually capitalised. Here they are, bestie:

  • MUST This word, or the adjective "REQUIRED", means that the item is an absolute requirement of the specification. No skipping it 😭
  • 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 a big part of the IP security architecture, but a specific key management protocol is not included in this spec 💅 The reason is a long history in the public literature of subtle flaws in key management algorithms and protocols, so yikes 🙈 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 the Security Parameter Index (SPI), which gets described in more detail below. This decoupling lets several different key management mechanisms be used. More importantly, it lets the key management protocol be changed or corrected without unduly impacting the security protocol implementations 🎀 So 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 requirements are incorporated here by reference [Atk95a].

The key management mechanism negotiates a number of parameters for each security association 🧚 That includes the keys, but also other info that the communicating parties use, like the cryptographic algorithms and modes, and the security classification level if there is one. The key management protocol implementation usually creates and maintains a logical table with the several parameters for each current security association. An ESP implementation normally needs to read that security parameter table to figure out 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 right before an ESP header will always contain the value 50 in its Next Header (IPv6) or Protocol (IPv4) field 🦋 ESP is an unencrypted header followed by encrypted data. The encrypted data includes both the protected ESP header fields and the protected user data. That user data is either an entire IP datagram or an upper-layer protocol frame (e.g., TCP or UDP). Here's a high-level diagram of a secure IP datagram:

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

And here's a more detailed diagram of the ESP Header 🎀

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

Encryption and authentication algorithms, plus the precise format of the Opaque Transform Data that goes with them, are known as "transforms" 🌸 The ESP format is designed to support new transforms in the future, so new or additional cryptographic algorithms can slide in later 🔥 The transforms are specified by themselves rather than in the main body of this spec. 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 👑

3.1 Fields of the Encapsulating Security Payload 🍓

The SPI is a 32-bit pseudo-random value that identifies 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, but the name got changed because the semantics used here aren't exactly the same as in those other protocols 🙈

The SPI values in the range 0x00000001 through 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 that are 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 current IPv4 practices, where an explicit Sensitivity Label is normally used with Compartmented Mode Workstations and other systems that require 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. That's the rule, no debate 💅

4. ENCAPSULATING SECURITY PROTOCOL PROCESSING ✨

okay so this is where we get into the step-by-step of what happens when ESP is running between two parties 🫶 it's giving main character energy. Multicast only differs from unicast when it comes to key management (check the SPI definition above for the deets 💅). There are two modes. Tunnel-mode wraps an entire IP datagram inside ESP 🎀, and Transport-mode wraps a transport-layer frame (like UDP or TCP) inside ESP 🦋. Bestie, "Transport-mode" must not be misconstrued as meaning it's only for TCP and UDP 😭. For example, an ICMP message MAY be sent in either mode depending on the circumstance 🌈. ESP processing happens before IP fragmentation on output and after IP reassembly on input 🧚. The rest of this section walks through how each mode works.

4.1 ESP in Tunnel-mode 🎀

In Tunnel-mode ESP, the ESP header comes after all of the end-to-end headers (like the Authentication Header, if it's in cleartext) and sits right before a tunnelled IP datagram 🍓.

The sender grabs the original IP datagram and encapsulates it into ESP. It uses at least the sending userid and the Destination Address to find the correct Security Association, then applies the right encryption transform 🔐. If host-oriented keying is in use, every sending userid on a given system gets the same Security Association for a given Destination Address. If no key has been set up yet, the key management mechanism establishes an encryption key for this session before ESP gets used 🔑. The now-encrypted ESP then gets wrapped in a cleartext IP datagram as the last payload. And if strict red/black separation is being enforced, the addressing and other info in those cleartext IP headers and optional payloads MAY be different from the values in the (now encrypted and encapsulated) original datagram 🙈.

The receiver strips off the cleartext IP header and any cleartext optional IP payloads, then tosses them 🗑️. Next, it uses the Destination Address plus the SPI value to find the correct session key for the packet, and decrypts the ESP with that key 🔓.

If there's no valid Security Association for this session (say 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 log entry SHOULD include the SPI value, date/time, cleartext Sending Address, cleartext Destination Address, and cleartext Flow ID. It MAY also include other identifying data. The receiver might not want to immediately tell the sender about the failure, since that's a huge opening for easy-to-exploit denial of service attacks 🚨.

If decryption works, the original IP datagram gets pulled out of the now-decrypted ESP and processed like normal, per the IP protocol spec ✅. For systems claiming to provide multilevel security (like a B1 or Compartmented Mode Workstation), additional appropriate mandatory access controls MUST be applied based on the security level of the receiving process and the security level associated with this Security Association 🛡️. If those access controls fail, the packet SHOULD be discarded and the failure SHOULD be logged using implementation-specific procedures.

4.2 ESP in Transport-mode 🦋

In Transport-mode ESP, the ESP header follows the end-to-end headers (like the Authentication Header) and sits right in front of a transport-layer header (UDP, TCP, or ICMP) 💜.

The sender takes the original transport-layer frame (e.g., UDP, TCP, ICMP) and encapsulates it into ESP. It uses at least the sending userid and Destination Address to find the appropriate Security Association, then applies the encryption transform ✨. Same deal with host-oriented keying: every sending userid on a given system shares the same Security Association for a given Destination Address. If no key has been established yet, the key management mechanism sets up an encryption key for this session before encryption happens 🗝️. The now-encrypted ESP then rides along as the last payload of a cleartext IP datagram.

The receiver processes the cleartext IP header and any cleartext optional IP headers, and temporarily stashes the important bits (source and destination addresses, Flow ID, Routing Header) 📦. Then it decrypts the ESP using the session key established for this traffic, using the destination address and the packet's Security Association Identifier (SPI) to find the correct key 🔐.

If no key exists for this session or the decryption attempt fails, the encrypted ESP MUST be discarded and the failure MUST be recorded in the system log or audit log 🚫. If that happens, the recorded log data SHOULD include the SPI value, date/time received, clear-text Sending Address, clear-text Destination Address, and the Flow ID. The log data MAY also include other information about the failed packet. If decryption doesn't work properly, the resulting data won't be parsable by the implementation's protocol engine, so failed decryption is generally detectable 👀.

If decryption succeeds, the original transport-layer frame is removed from the now-decrypted ESP. The info from the cleartext IP header and the now-decrypted transport-layer header gets used together to figure out which application the data should go to 🎯. The data then gets sent along to that application as normal, per the IP protocol spec. And for systems claiming to provide multilevel security (like a B1 or Compartmented Mode Workstation), additional Mandatory Access Controls MUST be applied based on the security level of the receiving process and the security level of the received packet's Security Association 👑.

4.3. Authentication 🔏

Some transforms give you authentication as well as confidentiality and integrity 💖. When one of those isn't being used, the Authentication Header might be used alongside Encapsulating Security Payload. There are two ways to do this, depending on which data you want authenticated, and where the Authentication Header sits makes it clear which data is covered 🌸.

In the first usage, the entire received datagram gets authenticated (both the encrypted and unencrypted parts), but only the data after the ESP header is confidential 🤫. Here's the order of operations. The sender applies ESP to the data being protected first. Then the other plaintext IP headers get stuck on in front of the ESP header and its now-encrypted data. Finally, the IP Authentication Header is calculated over the whole resulting datagram using the normal method. On receipt, the receiver verifies the authenticity of the entire datagram using the normal IP Authentication Header process first. If authentication succeeds, decryption happens through the normal IP ESP process. If decryption is successful, the resulting data gets passed up to the upper layer 🪄.

If authentication were only applied to the data protected by Tunnel-mode ESP, the IP Authentication Header would sit normally inside that protected datagram. But if you're using Transport-mode ESP, the IP Authentication Header goes before the ESP header and is calculated across the entire IP datagram 📐.

Now, if the Authentication Header is encapsulated within a Tunnel-mode ESP header, both headers have specific security classification levels, and those two levels aren't identical, then an error has occurred. That error SHOULD be recorded in the system log or audit log using the procedures described previously 🚩. It's not necessarily an error for an Authentication Header located outside the ESP header to have a different classification level than the ESP header's classification level. That might be valid, because the cleartext IP headers might have a different classification level after the data has been encrypted using ESP 😌.

5. CONFORMANCE REQUIREMENTS 📋

okay this part is the checklist, bestie 💅. Implementations that claim conformance or compliance with this specification MUST fully implement the header described here, MUST support manual key distribution with this header, MUST comply with all requirements of the "Security Architecture for the Internet Protocol" [Atk95a], and MUST support the use of DES CBC as specified 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 "IAB Official Standards" RFC for further guidance on the status of this document 🌈.

6. SECURITY CONSIDERATIONS 🚨

this one is serious, so read it fr 💀. This entire document discusses a security mechanism for use with IP. It's not a panacea, but it does provide an important component for creating a secure internetwork 🔥.

Cryptographic transforms for ESP that use a block-chaining algorithm and lack a strong integrity mechanism are vulnerable to a cut-and-paste attack described by Bellovin [Bel95], so they should not be used unless the Authentication Header is always present with packets using that ESP transform 😱.

Users need to understand that the quality of the security provided by this specification depends completely on the strength of whichever encryption algorithm has been implemented, the correctness of that algorithm's implementation, the security of the key management mechanism and its implementation, the strength of the key [CN94] [Sch94, p233], and the correctness of the ESP and IP implementations in all of the participating systems 🧠.

If any of these assumptions don't hold, then little or no real security will be provided to the user 💔. Use of high assurance development techniques is recommended for the IP Encapsulating Security Payload 🛠️.

Users seeking protection from traffic analysis might consider the use of appropriate link encryption 👀. Description and specification of link encryption is outside the scope of this note 🙃.

If user-oriented keying is not in use, then the algorithm in use should not be an algorithm vulnerable to any kind of Chosen Plaintext attack. Chosen Plaintext attacks on DES are described in [BS93] and [Mat94] 📚. Use of user-oriented keying is recommended in order to preclude any sort of Chosen Plaintext attack and to generally make cryptanalysis more difficult 🔐. Implementations SHOULD support user-oriented keying as is described in the IP Security Architecture [Atk95a] 💜.

ACKNOWLEDGEMENTS ✨

bestie, the people who shaped this spec deserve ALL the flowers 💐🫶. Bill Simpson, Perry Metzger, and Phil Karn 👑 took the approach the author first came up with for SIP, then SIPP, and finally IPv6, and made it general. That's a glow-up 😭.

A lot of the ideas here come from or were inspired by the US Government's SP3 security protocol, the ISO/IEC NLSP spec, or the proposed swIPe security protocol 🔐 [SDNS89, ISO92a, IB93, IBK93, ISO92b]. The DES confidentiality bit was closely modeled on the SNMPv2 work [GM93], so that's another shoutout 🦋. And Steve Bellovin, Steve Deering, Dave Mihelcic, and Hilarie Orman gave honest critiques of the early drafts, which is literally how good specs get made 💅.

REFERENCES 📚

Okay, here's the whole reading list, labels and all, so you can dig in 🤓🌸:

  • [Atk95a] Atkinson, R., "Security Architecture for the Internet 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/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, No. 2, March 1989.
  • [Bel95] Steven M. Bellovin, Presentation at IP Security Working Group Meeting, Proceedings of the 32nd Internet Engineering Task Force, March 1995, Internet Engineering Task Force, Danvers, MA.
  • [BS93] Eli Biham and Adi Shamir, "Differential Cryptanalysis of the 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 Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org.
  • [DIA] US Defense Intelligence Agency (DIA), "Compartmented Mode Workstation Specification", Technical Report DDS-2600-6243-87.
  • [GM93] Galvin J., and K. McCloghrie, "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN 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 Implementation of Network-layer Security Under Unix", Proceedings of the USENIX Security Symposium, Santa Clara, CA, October 1993.
  • [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio.
  • [ISO92a] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992.
  • [ISO92b] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, Section 13.4.1, page 33, International Standards Organisation, Geneva, Switzerland, 29 November 1992.
  • [Ken91] Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, BBN Communications, November 1991.
  • [KMS95] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC 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) Publication 46, January 1977.
  • [NIST80] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980.
  • [NIST81] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981.
  • [NIST88] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 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 published in NIST Publication NIST-IR-90-4250, February 1990.

DISCLAIMER 🫣

Real talk, this part is the legal tea ☕. The views and spec in here belong to the author 🦋, and they're not necessarily the views of his employer. The Naval Research Laboratory has not passed judgement on the merits, if any, of this work 🙈. The author and his employer specifically disclaim responsibility for any problems that come up from correct or incorrect implementation or use of this specification. So if your implementation goes sideways, that's on you, bestie 💀.

AUTHOR'S ADDRESS 🌈

The author is Randall Atkinson, and here's where to reach him 💌:

Randall Atkinson
Information Technology Division
Naval Research Laboratory
Washington, DC 20375-5320
USA

Phone:  (202) 404-7090
Fax:    (202) 404-7942
EMail:  atkinson@itd.nrl.navy.mil

And that's the whole thing, bestie! 🎀💖✨ Thanks for sticking with me through all three parts 🫶🧚

📦 where this page comes from