RFC 8221
Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 8221 ✨ Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) 🎀
Okay bestie, this one is the IPsec "which crypto is allowed" doc, and it's giving main character energy 💅. It was written by P. Wouters (Red Hat), D. Migault, J. Mattsson (Ericsson), Y. Nir (Check Point), and T. Kivinen, and it came out in October 2017 🍓. It's a Standards Track document, which means it's an official Internet standard, not just a vibe 💜. It's part of the IETF's ISSN 2070-1721 series.
It obsoletes RFC 7321 🦋, so this is the new and improved version that replaces it. It doesn't update anything else. Also, the whole point is to keep ESP and AH using crypto that's up to date while keeping IPsec interoperable, so everyone can still talk to each other 🫶.
This is part 1 of 3, so buckle up 🧚. We're covering the title block, status and copyright stuff, the table of contents, and then Sections 1 through 3.
Abstract ✨
Okay so this document replaces RFC 7321, which had the same title. The big goal is to let ESP and AH use crypto that's current, and to keep IPsec interoperable, which is the ultimate slay 👑.
Status of This Memo 📜
This is an Internet Standards Track document. 🌸
It's a product of the IETF, so it represents what the IETF community agreed on. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 💖.
You can find the current status, any errata, and how to give feedback at https://www.rfc-editor.org/info/rfc8221 🔥.
Copyright Notice 💜
Copyright (c) 2017 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 (https://trustee.ietf.org/license-info) as they were in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions 🙈. Code components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🎀.
Table of Contents 🌈
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Updating Algorithm Implementation Requirements and Usage
Guidance . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Manual Keying . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Encryption Must Be Authenticated . . . . . . . . . . . . . . 6
5. ESP Encryption Algorithms . . . . . . . . . . . . . . . . . . 7
6. ESP and AH Authentication Algorithms . . . . . . . . . . . . 9
7. ESP and AH Compression Algorithms . . . . . . . . . . . . . . 10
8. Summary of Changes from RFC 7321 . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 151. Introduction 🦋
Okay so ESP [RFC4303] and AH [RFC4302] are the mechanisms that apply cryptographic protection to data sent over an IPsec Security Association (SA) [RFC4301]. Iconic work 😭.
This document gives guidance and recommendations so ESP and AH can use algorithms that are up to date. The tricky part is making sure that, over time, IPsec implementations can use secure, current crypto while staying interoperable 🫶.
1.1. Updating Algorithm Implementation Requirements and Usage Guidance 💅
The field of cryptography is always changing ✨. New, stronger algorithms show up, and existing ones turn out to be less secure than everyone thought 💀. So algorithm requirements and usage guidance have to get updated every so often to match the new reality. The choices for algorithms MUST be conservative to minimize the risk of algorithm compromise. Algorithms also need to suit a wide range of CPU architectures and device types, from high-end bulk encryption devices all the way down to small, low-power Internet of Things (IoT) devices 🧚.
The algorithm requirements and usage guidance might need to change over time to keep up with the world. That's why the choice of mandatory-to-implement algorithms was taken out of the main Internet Key Exchange Protocol Version 2 (IKEv2) specification [RFC7296] and put into its own separate document 🌸.
1.2. Updating Algorithm Requirement Levels 🌷
The mandatory-to-implement algorithm of tomorrow should already be available in most AH/ESP implementations by the time it becomes mandatory 🔥. This document tries to find and introduce those algorithms for future mandatory-to-implement status. There's no guarantee that algorithms used today will become mandatory later 😬. Published algorithms keep getting hit with cryptographic attacks, and they might get too weak or even completely broken before this document gets updated 💔.
This document only gives recommendations for mandatory-to-implement algorithms and for "too weak" algorithms that are recommended not to be implemented. So, any algorithm in the IPsec IANA registry that isn't mentioned here MAY be implemented 🙌. The plan is for this document to be updated over time, and future versions will only mention algorithms whose status has changed. To be clear, when an algorithm was mentioned in [RFC7321], this document states its status update explicitly 📝.
Even though this document updates algorithms to keep AH/ESP communication secure over time, it also wants to keep AH/ESP implementations interoperable 🫶. Interoperability is handled by introducing or deprecating algorithms bit by bit. This document also looks at new AH/ESP use cases, like IoT 🌈.
Deprecation of an algorithm is supposed to happen gradually 🦋. That gives various implementations time to update which algorithms they support while still interoperating. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to MUST- or SHOULD, instead of straight to MUST NOT (see Section 2). Similarly, an algorithm that isn't listed as mandatory-to-implement is expected to be introduced with a SHOULD instead of a MUST 💖.
IoT is a big deal now, and its adoption of AH/ESP means this specific use case has to be considered too 🧸. IoT devices are resource-constrained, so their algorithm choices are driven by keeping the code footprint small, the computation light, and the messages small 🍓. This document marks "(IoT)" next to any algorithm that's specifically listed for IoT devices. Requirement levels marked as "IoT" apply to IoT devices, and also to server-side implementations that might need to interoperate with them, including general-purpose VPN gateways 🌸.
1.3. Document Audience 🎀
The recommendations here mostly target AH/ESP implementers, because implementations need to meet both high security expectations and high interoperability between different vendors and different versions 💜. Interoperability needs a smooth move toward more secure cipher suites. That can look different from a user's point of view, since a user might deploy and configure AH/ESP with only the safest cipher suite 👀.
This document doesn't recommend any particular algorithm use. It only gives recommendations for implementations. How a specific user uses algorithms is decided by their own security policy requirements, which are outside this document's scope 🙅♀️.
The algorithms covered here are the ones IANA lists as part of the IKEv2 parameters. IKEv1 is out of scope. IKEv1 is deprecated, so the recommendations here MUST NOT be considered for IKEv1, and IKEv1 parameters MUST NOT be considered by this document either 🚫.
The IANA registry for "Internet Key Exchange Version 2 (IKEv2) Parameters" has some entries that aren't for use with ESP or AH. This document doesn't change the status of those algorithms 🧚.
2. Requirements Language 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📚.
Okay so we also define some extra terms here 🌈:
- SHOULD+: This means the same as SHOULD. However, an algorithm marked SHOULD+ will probably be promoted to a MUST at some point in the future 🚀.
- SHOULD-: This means the same as SHOULD. However, an algorithm marked SHOULD- may be deprecated to a MAY in a future version of this document 🥀.
- MUST-: This means the same as MUST. However, we expect that at some point this algorithm will no longer be a MUST in a future document. Its status will be decided later, but if a future revision changes the status of a MUST- algorithm, it will stay at least at a SHOULD or SHOULD- level 🌷.
- IoT: The Internet of Things 🧸.
3. Manual Keying 🔐
Manual keying SHOULD NOT be used, because it's inherently dangerous 😱. Without a secure keying protocol like IKE, IPsec doesn't offer Perfect Forward Secrecy (PFS) protection. There's no entity making sure session keys get refreshed, SPI uniqueness is tracked, or nonces, Initialization Vectors (IVs), and counters are used only once 💀. This document was written for deploying ESP/AH using IKE [RFC7296] and assumes keying happens with IKEv2 or higher ✨.
If manual keying is used anyway, Counter Mode algorithms such as ENCR_AES_CTR, ENCR_AES_CCM, ENCR_AES_GCM, and ENCR_CHACHA20_POLY1305 MUST NOT be used 🚫. That's because they don't work with a secure, persistent handling of the counter (as explained in the Security Considerations section of [RFC3686]). This especially applies to IoT devices that keep no state across reboots 🔌. At the time of writing, ENCR_AES_CBC is the only mandatory-to-implement encryption algorithm suitable for manual keying 🎀.
Part 1 done, bestie 🫶💖. Part 2 is next, so stay tuned 🦋✨.
4. Encryption Must Be Authenticated 🔐✨
okay bestie, encryption WITHOUT authentication is basically a locked door with no lock on the handle 💀 it's not effective, so it MUST NOT be used 🙅♀️ IPsec gives you three ways to get encryption AND authentication together:
- ESP with an Authenticated Encryption with Associated Data (AEAD) cipher
- ESP with a non-AEAD cipher + authentication
- ESP with a non-AEAD cipher + AH with authentication
the fastest, most modern option is ESP with a combined-mode cipher, like an AEAD cipher 🏎️💨 it handles encryption/decryption AND authentication in one step. so the AEAD cipher is set as the encryption algorithm and the authentication algorithm is set to none. examples are ENCR_AES_GCM_16 and ENCR_CHACHA20_POLY1305 🫶
then there's the more traditional route: ESP with an encryption algorithm and a separate authentication algorithm. this one is slower bc the data gets processed twice, once for encryption/decryption and once for authentication 🐢 an example is ENCR_AES_CBC combined with AUTH_HMAC_SHA2_512_256.
the last option is ESP+AH, and this one is NOT RECOMMENDED 🙈 it's the slowest, AND it eats more octets because of the double header, which means a smaller effective MTU for the encrypted data. ESP is only doing confidentiality here (no authentication algorithm), and a second IPsec protocol, AH, handles the authentication. an example is ESP with ENCR_AES_CBC with AH with AUTH_HMAC_SHA2_512_256 💅
5. ESP Encryption Algorithms 🎀
here's the big cipher lineup, the whole vibe check ✨
+-------------------------+------------+---------+----------------+
| Name | Status | AEAD | Comment |
+-------------------------+------------+---------+----------------+
| ENCR_DES_IV64 | MUST NOT | No | UNSPECIFIED |
| ENCR_DES | MUST NOT | No | [RFC2405] |
| ENCR_3DES | SHOULD NOT | No | [RFC2451] |
| ENCR_BLOWFISH | MUST NOT | No | [RFC2451] |
| ENCR_3IDEA | MUST NOT | No | UNSPECIFIED |
| ENCR_DES_IV32 | MUST NOT | No | UNSPECIFIED |
| ENCR_NULL | MUST | No | [RFC2410] |
| ENCR_AES_CBC | MUST | No | [RFC3602][1] |
| ENCR_AES_CCM_8 | SHOULD | Yes | [RFC4309](IoT) |
| ENCR_AES_GCM_16 | MUST | Yes | [RFC4106][1] |
| ENCR_CHACHA20_POLY1305 | SHOULD | Yes | [RFC7634] |
+-------------------------+------------+---------+----------------+[1] - This requirement level is for 128-bit and 256-bit keys. 192-bit keys remain at the MAY level.
(IoT) - This requirement is for interoperability with IoT. Only 128-bit keys are at the given level.
okay so IPsec sessions can live for a REALLY long time and carry tons of packets 🧚 so we need to move to 256-bit keys long term 🔑 that's why the requirement level for 128-bit keys AND 256-bit keys is MUST (when applicable) 👑 the status for 256-bit keys got glowed up from MAY in [RFC7321] to MUST 📈
IANA has handed out codes for crypto algorithms the IETF never specified. those are marked UNSPECIFIED 🤷♀️ usually they're only used in specific cases, and with no spec, interop is a whole mess for IPsec 😭 those algorithms weren't in [RFC7321] either, and this doc makes it clear that they MUST NOT be implemented for IPsec communications 🚫
same deal with algorithms IANA registered that aren't expected to secure IPsec at all. those are marked non-IPsec, and so they MUST NOT be implemented 🙅♀️
a bunch of older ciphers that are not well tested and never really got widely implemented have been changed to MUST NOT 🗑️
ENCR_3DES got downgraded from MAY in [RFC7321] to SHOULD NOT 📉 ENCR_CHACHA20_POLY1305 is the more modern move and a better alternative to ENCR_3DES than ENCR_AES_CBC is, so it's expected to be favored to replace ENCR_3DES ✨
ENCR_BLOWFISH got downgraded to MUST NOT bc it's been deprecated for YEARS in favor of TWOFISH 🥀 but TWOFISH isn't standardized for ESP, so it's not listed in this doc. some implementations do support TWOFISH using a private range number, fyi 🤓
ENCR_NULL was set to MUST in [RFC7321] and it stays a MUST so you can use ESP with only authentication 🫶 that's preferred over AH because of NAT traversal 🌐 ENCR_NULL is expected to remain MUST based on protocol requirements.
ENCR_AES_CBC status stays at MUST 💜 it MUST be implemented so implementations that followed [RFC7321] can still talk to each other. BUT the industry is trending toward AEAD encryption, and the overhead of ENCR_AES_CBC is still pretty big, so it's expected to get replaced by AEAD algorithms long term 🦋
ENCR_AES_CCM_8 was set to MAY in [RFC7321] and got raised from MAY to SHOULD so it can work with IoT devices 🌸 since that's not a general VPN use case, it's expected to stay at SHOULD.
ENCR_AES_GCM_16 got updated from SHOULD+ to MUST to favor authenticated encryption and AEAD algorithms 🔥 it's already widely implemented for ESP bc of its better performance and key longevity compared to ENCR_AES_CBC 💅
ENCR_CHACHA20_POLY1305 wasn't ready for prime time at the time of [RFC7321] 🥺 the Crypto Forum Research Group (CFRG) and others have recommended it as an alternative to AES-CBC and AES-GCM 🌈 at the time of writing there still aren't enough ESP implementations of it to bump it up to SHOULD+, so its status is SHOULD for now and it's expected to become MUST long term ⭐
6. ESP and AH Authentication Algorithms 🛡️
the authentication algorithm recs in this section are aimed at two kinds of communications:
- Authenticated-only communications without encryption, such as ESP with NULL encryption or AH communications.
- Communications that are encrypted with a non-AEAD algorithm that MUST be combined with an authentication algorithm.
+------------------------+----------------+-------------------------+
| Name | Status | Comment |
+------------------------+----------------+-------------------------+
| AUTH_NONE | MUST / | [RFC7296][RFC5282] |
| | MUST NOT | AEAD-only |
| AUTH_HMAC_MD5_96 | MUST NOT | [RFC2403][RFC7296] |
| AUTH_HMAC_SHA1_96 | MUST- | [RFC2404][RFC7296] |
| AUTH_DES_MAC | MUST NOT | UNSPECIFIED |
| AUTH_KPDK_MD5 | MUST NOT | UNSPECIFIED |
| AUTH_AES_XCBC_96 | SHOULD / MAY | [RFC3566][RFC7296] |
| | | (IoT) |
| AUTH_AES_128_GMAC | MAY | [RFC4543] |
| AUTH_AES_256_GMAC | MAY | [RFC4543] |
| AUTH_HMAC_SHA2_256_128 | MUST | [RFC4868] |
| AUTH_HMAC_SHA2_512_256 | SHOULD | [RFC4868] |
+------------------------+----------------+-------------------------+(IoT) - This requirement is for interoperability with IoT.
AUTH_NONE got downgraded from MAY in [RFC7321] to MUST NOT 🚫 the ONLY time AUTH_NONE is okay is when you've picked authenticated encryption algorithms from Section 5 ✅ every other case, AUTH_NONE MUST NOT be selected. ESP and AH both give you authentication, so you might be tempted to stack them up 🥞 but as [RFC7321] mentioned, it is NOT RECOMMENDED to use ESP with NULL authentication (with non-authenticated encryption) together with AH. some configurations of that combo have been shown to be insecure [PD10] 😱 also, AUTH_NONE authentication can't be combined with ESP NULL encryption.
AUTH_HMAC_MD5_96 and AUTH_KPDK_MD5 weren't mentioned in [RFC7321]. MD5 is known to be vulnerable to collisions, so these algorithms MUST NOT be used 💀
AUTH_HMAC_SHA1_96 got downgraded from MUST in [RFC7321] to MUST- bc there's an industry-wide trend to deprecate it 📉
AUTH_DES_MAC wasn't mentioned in [RFC7321] either. DES is known to be vulnerable, so it MUST NOT be used 🙅♀️
AUTH_AES_XCBC_96 is set as SHOULD only in the scope of IoT 🌱 IoT deployments tend to prefer AES-based Hashed Message Authentication Code (HMAC) functions so they can avoid implementing SHA2. for wide VPN deployment, since it hasn't been widely adopted, it got downgraded from SHOULD to MAY 🫠
AUTH_AES_128_GMAC status got downgraded from SHOULD+ to MAY. along with AUTH_AES_192_GMAC and AUTH_AES_256_GMAC, these algorithms should only be used for AH and not for ESP ⚠️ if you're using ENCR_NULL, AUTH_HMAC_SHA2_256_128 is recommended for integrity. if you're using AES-GMAC in ESP without authentication, ENCR_NULL_AUTH_AES_GMAC is recommended. so yeah, these stay at MAY 🤷♀️
AUTH_HMAC_SHA2_256_128 wasn't mentioned in [RFC7321] bc no SHA2-based authentication was mentioned there 🙈 AUTH_HMAC_SHA2_256_128 MUST be implemented so it can replace AUTH_HMAC_SHA1_96 🔄 BUT there's a long-standing common implementation bug where this algorithm truncates the hash at 96 bits instead of 128 bits 😬 so it's recommended that implementations prefer AUTH_HMAC_SHA2_512_256 over AUTH_HMAC_SHA2_256_128 if they implement AUTH_HMAC_SHA2_512_256.
AUTH_HMAC_SHA2_512_256 SHOULD be implemented as a future replacement for AUTH_HMAC_SHA2_256_128, or whenever stronger security is needed 💪 this value got picked over AUTH_HMAC_SHA2_384 bc the extra overhead of AUTH_HMAC_SHA2_512 is negligible 🫧
7. ESP and AH Compression Algorithms 🗜️
+----------------+----------+-------------+
| Name | Status | Comment |
+----------------+----------+-------------+
| IPCOMP_OUI | MUST NOT | UNSPECIFIED |
| IPCOMP_DEFLATE | MAY | [RFC3173] |
| IPCOMP_LZS | MAY | [RFC2395] |
| IPCOMP_LZJH | MAY | [RFC3051] |
+----------------+----------+-------------+compression wasn't mentioned in [RFC7321] 🫧 since it's not widely deployed, it stays optional at the MAY level 🌸
8. Summary of Changes from RFC 7321 📋
here's the tea on what changed from RFC 7321 ☕ ✨
+-------------------+----------+-----------------+
| Algorithm | RFC 7321 | RFC 8221 |
+-------------------+----------+-----------------+
| ENCR_AES_GCM_16 | SHOULD+ | MUST |
| ENCR_AES_CCM_8 | MAY | SHOULD |
| ENCR_AES_CTR | MAY | MAY(*) |
| ENCR_3DES | MAY | SHOULD NOT |
| AUTH_HMAC_SHA1_96 | MUST | MUST- |
| AUTH_AES_128_GMAC | SHOULD+ | MAY |
| AUTH_NONE | MAY | MUST / MUST NOT |
+-------------------+----------+-----------------+(*) This algorithm is not mentioned in the above sections, so it defaults to MAY.
9. IANA Considerations 🦋
This document does not require any IANA actions. nothing to register, nothing to chase down, just vibes 💖
10. Security Considerations 🔐✨
Okay bestie, this one is serious 💀. The security of a system that uses cryptography depends on both how strong the cryptographic algorithms are and how strong the keys are 🔑. It also depends on the engineering and administration of the protocol, so there are no non-cryptographic ways to sneak around the security of the whole system 🙈.
This document is all about choosing which cryptographic algorithms ESP and AH use, specifically the mandatory-to-implement ones 💅. The algorithms marked "MUST implement" or "SHOULD implement" in here aren't known to be broken right now, and the crypto research so far makes us think they'll likely stay secure into the foreseeable future ✨. BUT, and this is the important part, that's not necessarily forever 😭. So we expect revisions of this document to come out from time to time to reflect the current best practice 🌸.
11. References 📚
11.1. Normative References
These are the must-read references that the rest of the doc depends on 🧚.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm
Implementation Requirements and Usage Guidance for
Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014,
<https://www.rfc-editor.org/info/rfc7321>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.11.2. Informative References
These are the extra reading for when you want the deep dive 🤓🎀.
[PD10] Paterson, K. and J. Degabriele, "On the (in)security of
IPsec in MAC-then-encrypt configurations", Proceedings of
the 17th ACM Conference on Computer and Communications
Security (ACM CCS), DOI 10.1145/1866307.1866363, 2010.
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using
LZS", RFC 2395, DOI 10.17487/RFC2395, December 1998,
<https://www.rfc-editor.org/info/rfc2395>.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, DOI 10.17487/RFC2403, November
1998, <https://www.rfc-editor.org/info/rfc2403>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
1998, <https://www.rfc-editor.org/info/rfc2404>.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405,
DOI 10.17487/RFC2405, November 1998,
<https://www.rfc-editor.org/info/rfc2405>.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410,
November 1998, <https://www.rfc-editor.org/info/rfc2410>.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, DOI 10.17487/RFC2451, November
1998, <https://www.rfc-editor.org/info/rfc2451>.
[RFC3051] Heath, J. and J. Border, "IP Payload Compression Using
ITU-T V.44 Packet Method", RFC 3051, DOI 10.17487/RFC3051,
January 2001, <https://www.rfc-editor.org/info/rfc3051>.
[RFC3173] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173,
DOI 10.17487/RFC3173, September 2001,
<https://www.rfc-editor.org/info/rfc3173>.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", RFC 3566, DOI 10.17487/RFC3566,
September 2003, <https://www.rfc-editor.org/info/rfc3566>.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602,
DOI 10.17487/RFC3602, September 2003,
<https://www.rfc-editor.org/info/rfc3602>.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,
<https://www.rfc-editor.org/info/rfc3686>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, DOI 10.17487/RFC4106, June 2005,
<https://www.rfc-editor.org/info/rfc4106>.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, DOI 10.17487/RFC4309, December 2005,
<https://www.rfc-editor.org/info/rfc4309>.
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
DOI 10.17487/RFC4543, May 2006,
<https://www.rfc-editor.org/info/rfc4543>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>.
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282,
DOI 10.17487/RFC5282, August 2008,
<https://www.rfc-editor.org/info/rfc5282>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the
Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634,
DOI 10.17487/RFC7634, August 2015,
<https://www.rfc-editor.org/info/rfc7634>.Acknowledgements 🫶
Some of the wording in this doc was borrowed from [RFC7321], the one this doc obsoletes 💖. That one was written by D. McGrew and P. Hoffman, so big thanks to them ✨.
Authors' Addresses 💌
Paul Wouters
Red Hat
Email: pwouters@redhat.com
Daniel Migault
Ericsson
8275 Trans Canada Route
Saint-Laurent, QC H4S 0B6
Canada
Phone: +1 514-452-2160
Email: daniel.migault@ericsson.com
John Mattsson
Ericsson AB
SE-164 80 Stockholm
Sweden
Email: john.mattsson@ericsson.com
Yoav Nir
Check Point Software Technologies Ltd.
5 Hasolelim St.
Tel Aviv 6789735
Israel
Email: ynir.ietf@gmail.com
Tero Kivinen
Email: kivinen@iki.fiThat's the whole doc, bestie! 🌈👑 We made it through the entire RFC, no cap 💅💖
📦 where this page comes from
- ietf: rfc8221 2017-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms