RFC 5840
Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility
RFC 5840: Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility ✨
Okay bestie, let's start with the basics 🎀
- Number and ISSN: RFC 5840, ISSN 2070-1721 🦋
- Stream: IETF (Internet Engineering Task Force)
- Authors: K. Grewal (Intel Corporation), G. Montenegro (Microsoft Corporation), and M. Bhatia (Alcatel-Lucent) 👑
- Category: Standards Track
- Date: April 2010
- Obsoletes and updates: the header doesn't list any RFCs that this one obsoletes or updates 🌸
Abstract ✨
Okay so this doc describes the Wrapped Encapsulating Security Payload (WESP) protocol. It's built on top of the Encapsulating Security Payload (ESP) from RFC 4303, and it's designed to help middleboxes do two things: (1) figure out whether data confidentiality is being used inside ESP, and (2) if it's not, inspect the IPsec packets for network monitoring and access control 🔍
The tea is that right now, the IPsec ESP standard has no deterministic way to tell encrypted payloads from unencrypted ones just by looking at a packet. That's a real problem for intermediate devices, which need to deep inspect a packet before deciding what to do with it (Inspect and/or Allow/Drop) 😭
The mechanism in this document lets you easily tell integrity-only ESP apart from ESP-encrypted packets, and it doesn't give up any of the security that ESP already provides 💅
Status of This Memo
This is an Internet Standards Track document 🎀
It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 📚
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5840 🦋
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info, as they stand on the date this document was published. Please read them carefully because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ⚖️
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. Some of the copyright holders for that older material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from whoever controls the copyright in those materials, this document can't be modified outside the IETF Standards Process, and derivative works of it can't be created outside the IETF Standards Process either. The one exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌈
Table of Contents
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
1.2. Applicability Statement ....................................4
2. Wrapped ESP (WESP) Header Format ................................5
2.1. UDP Encapsulation ..........................................8
2.2. Transport and Tunnel Mode Considerations ...................9
2.2.1. Transport Mode Processing ...........................9
2.2.2. Tunnel Mode Processing .............................10
2.3. IKE Considerations ........................................11
3. Security Considerations ........................................12
4. IANA Considerations ............................................13
5. Acknowledgments ................................................13
6. References .....................................................14
6.1. Normative References ......................................14
6.2. Informative References ....................................141. Introduction ✨
Okay, so ESP in IPsec [RFC4303] is what specifies how ESP packet encapsulation works. It also says ESP can provide data confidentiality and data integrity services. Integrity without confidentiality ("integrity-only ESP") is possible using the ESP-NULL encryption algorithm [RFC2410] or combined-mode algorithms like AES-GMAC [RFC4543]. The exact encapsulation and algorithms get negotiated out of band, using things like Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306], and it all depends on policy 🧚
Enterprise environments usually have tons of security policies (plus the tools to enforce them). These cover access control, content screening, firewalls, network monitoring, deep packet inspection, Intrusion Detection and Prevention Systems (IDS and IPS), virus and worm scanning and detection, and more. To enforce all that, network tools and intermediate devices need to see into packets, from simple header inspection all the way down to deeper payload examination. The catch is that network security protocols which encrypt data in transit stop these tools from doing those jobs 😭
When you run IPsec in an enterprise, it's preferable to use ESP instead of Authentication Header (AH) [RFC4302], because AH doesn't work in NAT environments 🙈 To keep those monitoring functions working, it's also preferable to use integrity-only ESP. In a mixed-mode environment, some packets with sensitive data use a given encryption cipher suite, while other packets use integrity-only ESP. For an intermediate device to tell which packets are integrity-only, it would need to know every policy in use for each protected session. That's clearly not practical 💀
You could try heuristics-based methods to parse the packets, but those can get super expensive, since they need a bunch of rules for each protocol and payload. Even then, parsing might not be robust, because fields in an encrypted packet can happen to look like the fields for a given protocol or heuristic rule. And when packets might be encrypted, it's wasteful to run them through heuristic rules when a simple exception policy (for example, allow, drop, or redirect) can handle them instead. Since heuristic rules for telling encrypted from non-encrypted data are non-deterministic, there needs to be a different way for intermediate devices to work in encrypted data environments. There are also loads of different types and classes of network devices in one network, and a deterministic approach gives a simple solution for all of them 🎀 Enterprises usually use both stateful and stateless packet inspection. These considerations hit stateless mechanisms especially hard, like router Access Control Lists (ACLs) and NetFlow exporters. Still, a deterministic approach gives a simple solution for all the device types in a network, whether they're stateful or stateless 🦋
This document defines a mechanism that adds extra information to relevant IPsec packets, so intermediate devices can efficiently tell encrypted traffic apart from integrity-only traffic. And for consistency, this extended format can also carry encrypted packets without losing any disambiguation 💖
This document is consistent with how ESP works in NAT environments [RFC3947] 🌸
The design principles for this protocol are:
- Allow easy identification and parsing of integrity-only IPsec traffic
- Leverage the existing hardware IPsec parsing engines as much as possible to minimize additional hardware design costs
- Minimize the packet overhead in the common case
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. These are the official requirement words, so pay attention to them 📌
1.2. Applicability Statement
Okay so this doc only applies to the wrapped ESP header defined below. It doesn't change ESP [RFC4303] or the IP Authentication Header (AH) [RFC4302] 🎀
There are two well-accepted ways for intermediate security devices to tell encrypted and unencrypted ESP traffic apart:
- The heuristics approach [Heuristics] has the intermediate node inspect the unchanged ESP traffic, to figure out with extremely high probability whether the traffic stream is encrypted.
- The Wrapped ESP (WESP) approach, which this document describes, is different. It requires the ESP endpoints to be modified to support the new protocol. In return, WESP lets the intermediate node tell encrypted and unencrypted traffic apart deterministically, with a simpler implementation for the intermediate node ✨
Both approaches are being documented at the same time by the IP Security Maintenance and Extensions (IPsecME) Working Group. WESP (this document) is a Standards Track RFC, while the heuristics approach is expected to be published as an Informational RFC 🦋 While endpoints are being updated to adopt WESP, both approaches are expected to coexist for years. That's because the heuristic approach is still needed to inspect traffic where at least one endpoint hasn't been modified. In other words, intermediate nodes are expected to support both approaches to get good security and performance during the transition period 🫶
2. Wrapped ESP (WESP) Header Format ✨
okay so WESP encapsulation uses protocol number 141 🎀 which means the outer header (IPv4, IPv6, or Extension) sitting right before the WESP header SHALL contain the value (141) in its Protocol (IPv4) or Next Header (IPv6, Extension) field. 💅 WESP adds extra attributes to each packet so you can tell encrypted and non-encrypted data apart, and so parsing gets easier 🧚 It follows RFC 4303 for all IPv6 and IPv4 considerations (alignment stuff too), so no need to reinvent the wheel bestie 🫶
this extension is basically a wrapper around the existing ESP protocol 🎁 It adds 4 octets at the front of the existing ESP packet for IPv4. For IPv6, you might need some extra padding, and we'll get into that below 👀
here's what the packet looks like 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wrapped ESP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: WESP Packet Formatby keeping the body of the existing ESP packet format exactly as it is 🌸 a compliant implementation can just slap the new header on top without touching the body. The new header is identified by protocol value 141. Here's the detailed version 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrLen | TrailerLen | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Detailed WESP Packet FormatWhere:
Next Header, 8 bits: this field MUST be the same as the Next Header field in the ESP trailer when you're using ESP in the Integrity-only mode 🔐 When you use ESP with encryption, the "Next Header" field loses this name and semantics and becomes an empty field that MUST be initialized to all zeros 🫧 The receiver MUST do some sanity checks before the WESP packet is accepted ✅ In Integrity-only mode, the receiver MUST ensure that the Next Header field in the WESP header and the Next Header field in the ESP trailer match, and the packet MUST be dropped if they don't 💀 Similarly, when using WESP with encryption, the receiver MUST ensure that the Next Header field in the WESP header is an empty field initialized to zero. The WESP flags dictate whether the packet is encrypted 🔥
HdrLen, 8 bits: this is the offset, in octets, from the beginning of the WESP header to the beginning of the Rest of Payload Data (so, past the IV if it's present, plus any other WESP options defined in the future) within the encapsulated ESP header 🧁 HdrLen MUST be set to zero when using ESP with encryption. When using integrity-only ESP, these HdrLen values are invalid: any value less than 12, any value that isn't a multiple of 4, and any value that isn't a multiple of 8 when using IPv6 🙈 The receiver MUST ensure that this field matches the header offset computed from the negotiated Security Association (SA), and MUST drop the packet if it doesn't match 🚫
TrailerLen, 8 bits: this contains the size, in octets, of the Integrity Check Value (ICV) used by the negotiated algorithms within the IPsec SA 🌈 TrailerLen MUST be set to zero when using ESP with encryption. The receiver MUST only accept the packet if this field matches the value computed from the negotiated SA. This is the anti-sneaky check 🕵️♀️ It makes sure the sender isn't deliberately setting this value to hide part of the payload from a trusted intermediary device. Not on my watch 😤
Flags, 8 bits: the bits are defined most-significant-bit (MSB) first, so bit 0 is the most significant bit of the flags octet 🦄
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V V|E|P| Rsvd |
+-+-+-+-+-+-+-+-+
Figure 3: Flags FormatVersion (V), 2 bits: this MUST be sent as 0 and checked by the receiver 🔍 If the version is different from an expected version number (for example, one negotiated via the control channel), the packet MUST be dropped by the receiver 🗑️ Future changes to the WESP header require a new version number. The version of WESP defined in this document doesn't allow for any extensions. Old implementations can still find the encapsulated cleartext packet using the HdrLen field, as long as the 'E' bit isn't set 🥹 Intermediate nodes dealing with unknown versions might not be able to parse the packet correctly, so how they treat these packets is policy dependent (for example, the policy could say to drop them) 🤷♀️
Encrypted Payload (E), 1 bit: setting this bit to 1 means the WESP (and therefore ESP) payload is protected with encryption 🔒 If it's set to 0, the payload is using integrity-only ESP. Setting or clearing this bit also changes the value in the WESP Next Header field, as described above 🎀 The recipient MUST ensure this flag is consistent with the negotiated policy, and MUST drop the incoming packet otherwise 🛑
Padding header (P), 1 bit: if it's set (value 1), the 4-octet padding is present. If it's not set (value 0), the 4-octet padding is absent 🍓 This padding MUST be used with IPv6 in order to preserve IPv6 8-octet alignment. If WESP is used with UDP encapsulation (see Section 2.1 below) and IPv6, the Protocol Identifier (0x00000002) takes up 4 octets, so the IPv6 padding isn't needed, since the header is already on an 8-octet boundary 🧠 This padding MUST NOT be used with IPv4, because it isn't needed to guarantee 4-octet IPv4 alignment 🙅♀️
Rsvd, 4 bits: reserved for future use 🌙 The reserved bits MUST be sent as 0, and the receiver MUST ignore them. Future documents that define any of these bits MUST NOT affect the distinction between encrypted and unencrypted packets, or the semantics of HdrLen 💜 So even if new bits get defined, old implementations will still find the encapsulated packet correctly 🥰 Intermediate nodes dealing with unknown reserved bits might not be able to parse the packet correctly, so their treatment is policy dependent (for example, the policy could dictate dropping them) 🫠
Future versions of this protocol might change the version number and/or the reserved bits sent, possibly by negotiating them over the control channel 🛸
so yeah, the WESP format extends the standard ESP header by the first 4 octets for IPv4, and optionally (see above) by 8 octets for IPv6 🤓✨
2.1. UDP Encapsulation
this section describes how to run the new packet format over the existing UDP encapsulation of ESP defined in RFC 3948 🦋 This lets you reuse the existing IKE negotiation of the UDP port for Network Address Translation Traversal (NAT-T) discovery and usage [RFC3947] [RFC4306], and it keeps the existing UDP ports for ESP (port 4500) 💖 With UDP encapsulation, the packet format looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Port (4500) | Dest Port (4500) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier (value = 0x00000002) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrLen | TrailerLen | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: UDP-Encapsulated WESP HeaderWhere:
Source/Destination port (4500) and checksum: these describe the UDP encapsulation header, per RFC 3948 🎀
Protocol Identifier: a brand new field that demultiplexes between UDP encapsulation of IKE, UDP encapsulation of ESP per RFC 3948, and the UDP encapsulation in this specification ✨
According to RFC 3948, Section 2.2, a 4-octet value of zero (0) right after the UDP header is a Non-ESP marker, which tells you the data after it is an IKE packet 🧚 Similarly, a value greater than 255 means the packet is an ESP packet, and those 4 octets can be treated as the ESP Security Parameter Index (SPI). BUT RFC 4303, Section 2.1 says the values 1-255 are reserved and cannot be used as the SPI 🤯 So we borrow one of those reserved values to signal that the UDP encapsulated ESP header contains this new packet format 🫶
The remaining fields in the packet have the same meaning as in Section 2 above 🌸
2.2. Transport and Tunnel Mode Considerations
this extension works for both transport and tunnel mode 🦋 The ESP Next Header field is what tells these two modes apart, same as in the existing IPsec specifications 💅
2.2.1. Transport Mode Processing ✨
Okay so in transport mode, ESP gets tucked in right after the IP header and before the next layer protocol, like TCP, UDP, ICMP, and friends 🦋 Here's how WESP gets applied to ESP transport mode for a typical packet, shown as a "before and after" glow-up 💅
BEFORE APPLYING WESP -IPv4
-------------------------------------------------
|orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
|<---- encryption ---->|
|<------- integrity -------->|
AFTER APPLYING WESP - IPv4
--------------------------------------------------------
|orig IP hdr | WESP | ESP | | | ESP | ESP|
|(any options)| Hdr | Hdr | TCP | Data | Trailer | ICV|
--------------------------------------------------------
|<---- encryption ---->|
|<------- integrity -------->|
BEFORE APPLYING WESP - IPv6
--------------------------------------------------------------
| orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment |ESP|opt*|TCP|Data|Trailer| ICV|
--------------------------------------------------------------
|<---- encryption --->|
|<----- integrity ------->|
AFTER APPLYING WESP - IPv6
--------------------------------------------------------------
| orig |hop-by-hop,dest*,| | |dest| | | ESP | ESP|
|IP hdr|routing,fragment |WESP|ESP|opt*|TCP|Data|Trailer| ICV|
--------------------------------------------------------------
|<---- encryption --->|
|<----- integrity ------->|
* = if present, could be before WESP, after ESP, or bothEverything else is handled the same way as in RFC 4303, so no new drama there 💖
2.2.2. Tunnel Mode Processing 🌸
In tunnel mode, ESP sits after the new IP header and before the original IP header, just like RFC 4303 says 🧚 This diagram shows how WESP gets slotted into ESP tunnel mode for a typical packet, again as a before-and-after moment ✨
BEFORE APPLYING WESP - IPv4
---------------------------------------------------------
|new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)|ESP| (any options) |TCP|Data|Trailer| ICV|
---------------------------------------------------------
|<--------- encryption --------->|
|<----------- integrity ------------>|
AFTER APPLYING WESP - IPv4
--------------------------------------------------------------
|new IP hdr* | | | orig IP hdr* | | | ESP | ESP|
|(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV|
--------------------------------------------------------------
|<--------- encryption --------->|
|<----------- integrity ------------>|
BEFORE APPLYING WESP - IPv6
-----------------------------------------------------------------
|new IP|new ext | |orig IP|orig ext| | | ESP | ESP|
| hdr* | hdrs* |ESP| hdr* | hdrs * |TCP|Data|Trailer| ICV|
-----------------------------------------------------------------
|<--------- encryption ---------->|
|<------------- integrity ----------->|
AFTER APPLYING WESP - IPv6
-----------------------------------------------------------------
|new IP|new ext | | |orig IP|orig ext| | | ESP | ESP|
| hdr* | hdrs* |WESP|ESP| hdr* | hdrs * |TCP|Data|Trailer| ICV|
-----------------------------------------------------------------
|<--------- encryption ---------->|
|<------------- integrity ----------->|
* = if present, construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is discussed in
the Security Architecture document.All other considerations are as per RFC 4303, so you already know the vibe 🫶
2.3. IKE Considerations 🔐
This document assumes that WESP negotiation happens through IKEv2. To negotiate this new ESP encapsulation format via IKEv2 [RFC4306], both parties need to be on the same page about using the new packet format. A notification method that works like USE_TRANSPORT_MODE, which is defined in RFC 4306, can get this done 💜
The notification USE_WESP_MODE (value 16415) MUST be included in a request message that also includes an SA payload asking for a CHILD_SA that uses ESP. It tells the other side that the sender supports the WESP version defined in this document, and it asks for the CHILD_SA to use WESP mode instead of plain ESP for the SA that gets created 🎀 If the request is accepted, the response MUST also include a notification of type USE_WESP_MODE. If the responder declines, the CHILD_SA will be established using ESP, as per RFC 4303. And if that's not okay with the initiator, the initiator MUST delete the SA 😭
Note: Except when using this option to negotiate WESP mode, all CHILD_SAs will use standard ESP.
Negotiating WESP this way keeps every other negotiation parameter intact, including NAT-T [RFC3948] 🌈 NAT-T is totally compatible with this wrapped format and can be used as-is, with no changes at all, anywhere NAT is in the picture and needs to be accounted for ✨
WESP version negotiation is not introduced as part of this specification 🍓 If a future specification updates the WESP version, that document MUST specify how the WESP version is negotiated 👑
3. Security Considerations 🔥
Okay, this part is important, bestie 🥺 This document builds on the existing ESP encapsulation format, the UDP encapsulation definitions in RFC 3948, and IKE negotiation of the new encapsulation, so the security observations made in those documents also apply here 💀 On top of that, this document lets intermediate devices see into IPsec ESP encapsulated frames for network monitoring purposes. That means you should take care not to send sensitive data over connections that use the definitions in this document, based on network domain or administrative policy 🚨 A strong key agreement protocol, like IKEv2, together with a strong policy engine should be used to decide the right security policy for the traffic streams and the data being carried over them 🛡️
ESP is end-to-end, so it will be impossible for intermediate devices to verify that all the fields in the WESP header are correct 😳 That means someone could modify the WESP header so the packet sneaks past a firewall, as long as the WESP header fields are set to something the firewall will allow. So the endpoint must verify the sanity of the WESP header before accepting the packet 🫣 In an extreme case, someone colluding with the attacker could change the WESP fields back to their original values so that the attack goes unnoticed 💀 However, this is not a new problem. It already exists in IPsec 🙄
4. IANA Considerations 📋
The WESP protocol number assigned by IANA out of the IP Protocol Number space is 141 🔢
The USE_WESP_MODE notification number assigned out of the "IKEv2 Notify Message Types - Status Types" registry's 16384-40959 (Expert Review) range is 16415 💖
The SPI value of 2 has been assigned by IANA out of the reserved SPI range from the SPI values registry, to indicate use of the WESP protocol within a UDP-encapsulated, NAT-T environment 🦋
IANA has created a new registry for "WESP Flags" that gets managed like this 💅
- The first 2 bits are the WESP Version Number. The value 0 is assigned to the version defined in this specification. Further assignments of the WESP Version Number are managed via the IANA Policy of "Standards Action" [RFC5226]. For WESP version numbers, the unassigned values are 1, 2, and 3.
- The Encrypted Payload bit is used to indicate whether the payload is encrypted or uses integrity-only ESP.
- The Padding Present bit is used to signal the presence of padding.
- The remaining 4 bits of the WESP Flags are undefined, and future assignment is managed via the IANA Policy of "IETF Review" [RFC5226] ✨
5. Acknowledgments 🫶
The authors would like to thank these people for their feedback on updating the definitions in this document 🌸
David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron Sheffer, Pasi Eronen, Men Long, David Durham, Prashant Dewan, Marc Millier, Russ Housley, and Jari Arkko, among others 💜
Manav Bhatia would also like to shout out Swati and Maitri for their continued support 🎀
6. References 📚
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm
and Its Use With IPsec", RFC 2410, November 1998.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC
4543, May 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.6.2. Informative References
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[Heuristics] Kivinen, T. and D. McDonald, "Heuristics for Detecting
ESP-NULL packets", Work in Progress, March 2010.Authors' Addresses 🦋
Ken Grewal
Intel Corporation
2111 NE 25th Avenue, JF3-232
Hillsboro, OR 97124
USA
EMail: ken.grewal@intel.com
Gabriel Montenegro
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
EMail: gabriel.montenegro@microsoft.com
Manav Bhatia
Alcatel-Lucent
Manyata Embassy
Nagawara Bangalore
India
EMail: manav.bhatia@alcatel-lucent.comThat's the whole RFC, bestie 🌈✨ WESP is giving tunnel and transport realness 💖
📦 where this page comes from
- ietf: rfc5840 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms