RFC 5857
IKEv2 Extensions to Support Robust Header Compression over IPsec
RFC 5857: IKEv2 Extensions to Support Robust Header Compression over IPsec 🎀
- Number: RFC 5857 📚
- Title: IKEv2 Extensions to Support Robust Header Compression over IPsec
- Authors: E. Ertekin, C. Christou, R. Jasani (Booz Allen Hamilton), T. Kivinen (AuthenTec, Inc.), and C. Bormann (Universitaet Bremen TZI)
- Category: Standards Track ✨
- ISSN: 2070-1721
- Date: May 2010 📅
- Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🙈
Abstract 🌸
Okay so, if you want to pair ROHC with IPsec, the two endpoints need a way to tell each other the ROHC channel parameters. IKE is the thing that can handle that swap for you. This document defines extensions to IKEv2 so ROHC and its associated channel parameters can be signaled for IPsec Security Associations (SAs). It's giving organization 💖
Status of This Memo 📜
This is an Internet Standards Track document. 🦋
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.
Current status, errata, and how to send feedback can be found at http://www.rfc-editor.org/info/rfc5857. 💅
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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review those documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 🌈
Table of Contents 🧚
1. Introduction ....................................................3
2. Terminology .....................................................3
3. ROHC Channel Initialization for ROHCoIPsec ......................3
3.1. ROHC_SUPPORTED Notify Message ..............................3
3.1.1. ROHC Attributes .....................................5
3.1.2. ROHC Attribute Types ................................6
3.2. ROHC Channel Parameters That Are Implicitly Set ............9
4. Security Considerations .........................................9
5. IANA Considerations .............................................9
6. Acknowledgments ................................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................121. Introduction 🍓
Packet header overhead from IPsec [IPSEC] goes up, and that can make bandwidth get used up inefficiently 😭. Pairing ROHC [ROHC] with IPsec is a way to send protected IP traffic more efficiently. Iconic combo 👑
ROHCoIPsec [ROHCOIPSEC] needs configuration parameters set up at both the compressor and the decompressor. Current specs for hop-by-hop ROHC negotiate those parameters at the link layer, for example over the Point-to-Point Protocol (PPP) (that's ROHC over PPP [ROHC-PPP]). Key exchange protocols like IKEv2 [IKEV2] can set up parameters between IPsec peers dynamically, so this document defines IKEv2 extensions that signal the ROHC parameters for ROHCoIPsec. The plan is lowkey genius 🧠✨
2. Terminology 🎀
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 [BRA97]. 📖
3. ROHC Channel Initialization for ROHCoIPsec 🦋
The subsections below define IKEv2 extensions that let an initiator and a responder signal the parameters needed to set up a ROHC channel for a ROHCoIPsec session. Main character energy 👑
3.1. ROHC_SUPPORTED Notify Message 💖
ROHC channel parameters MUST be signaled separately for each ROHC-enabled IPsec SA. Specifically, a new Notify message type MUST be included in the IKE_AUTH and CREATE_CHILD_SA exchanges whenever a new ROHC-enabled IPsec SA is created, or an existing one is rekeyed. So every single one gets its own signaling, no shortcuts 🙅♀️
The Notify payload sent by the initiator MUST contain the channel parameters for the ROHC session. Those parameters show what the ROHC decompressor at the initiator is capable of. When the responder gets the initiator's request, it will either ignore the payload (if it doesn't support ROHC or the proposed parameters), or it will reply with a Notify payload carrying its own ROHC channel parameters. ✨
Note that only one Notify payload is used to convey ROHC parameters. If multiple Notify payloads containing ROHC parameters are received, all but the first such Notify payload MUST be dropped. If the initiator does not receive a Notify payload with the responder's ROHC channel parameters, ROHC MUST NOT be enabled on the Child SA. One payload, one chance, no drama 💅
A new Notify Message Type value, denoted ROHC_SUPPORTED, indicates that the Notify payload is conveying ROHC channel parameters (Section 4). 🌸
The Notify payload (defined in RFC 4306 [IKEV2]) is illustrated in Figure 1. Picture time 📸
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 Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1. Notify Payload Format
The fields of the Notify payload are set as follows: 🎀
Next Payload(1 octet): the identifier for the payload type of the next payload in the message. More details are in RFC 4306 [IKEV2].Critical(1 bit): since all IKEv2 implementations support the Notify payload, this value MUST be set to zero. 🙈Payload Length(2 octets): as defined in RFC 4306 [IKEV2], this field indicates the length of the current payload, including the generic payload header.Protocol ID(1 octet): since this notification message is used during the creation of a Child SA, this field MUST be set to zero.SPI Size(1 octet): this value MUST be set to zero, since no SPI is applicable. ROHC parameters are set at SA creation, so the SPI has not been defined yet 🧚Notify Message Type(2 octets): this field MUST be set toROHC_SUPPORTED. 💜Security Parameter Index (SPI): since the SPI Size field is 0, this field MUST NOT be transmitted. 🚫Notification Data(variable): this field MUST contain at least three ROHC Attributes (Section 3.1.1). 🍓
3.1.1. ROHC Attributes 🌈
The ROHC_SUPPORTED Notify message is how channel parameters get signaled between the ROHCoIPsec compressor and decompressor. The message holds a list of "ROHC Attributes", and those carry the parameters needed for the ROHCoIPsec session. ✨
The format for signaling ROHC Attributes is similar to the Transform Attributes described in Section 3.3.5 of RFC 4306 [IKEV2]. The format of the ROHC Attribute is shown in Figure 2. 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!A! ROHC Attribute Type ! AF=0 ROHC Attribute Length !
!F! ! AF=1 ROHC Attribute Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! AF=0 ROHC Attribute Value !
! AF=1 Not Transmitted !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2. Format of the ROHC Attribute
- Attribute Format (AF) (1 bit) - If the AF bit is a zero (0), then the ROHC Attribute is expressed in a Type/Length/Value format. If the AF bit is a one (1), then the ROHC attribute is expressed in a Type/Value (TV) format. 🌸
- ROHC Attribute Type (15 bits) - Unique identifier for each type of ROHC attribute (Section 3.1.2). 💖
- ROHC Attribute Length (2 octets) - Length (in octets) of the Attribute Value. When the AF bit is a one (1), the ROHC Attribute Value is 2 octets and the ROHC Attribute Length field is not present. 🙌
- ROHC Attribute Value (variable length) - Value of the ROHC Attribute associated with the ROHC Attribute Type. If the AF bit is a zero (0), this field's length is defined by the ROHC Attribute Length field. If the AF bit is a one (1), the length of the ROHC Attribute Value is 2 octets. 🫶
3.1.2. ROHC Attribute Types 🎀
Okay bestie, this part covers five ROHC Attribute Types: MAX_CID, ROHC_PROFILE, ROHC_INTEG, ROHC_ICV_LEN, and MRRU. 💅 The value allocated for each one is specified in Section 4, so keep that in your back pocket. ✨
MAX_CID (Maximum Context Identifier, AF = 1) 💖
MAX_CID is a mandatory attribute, so exactly one MAX_CID attribute MUST be sent. The field tells you the highest context identifier the ROHCoIPsec decompressor can handle. It's 2 octets long, and its value MUST be at least 0 and at most 16383. CIDs can go from 0 up to MAX_CID, so the number of contexts you can actually use is MAX_CID+1. If MAX_CID is 0, that means you get one context. 🦋 The recipient MUST only use context identifiers up to MAX_CID for compression, no going rogue. 🙈
Note that MAX_CID is a one-way notification. The sender is just telling the other end what it can handle, so each direction can announce a different MAX_CID. 🌈
ROHC_PROFILE (ROHC Profile, AF = 1) 🧚
ROHC_PROFILE is also mandatory. Each one has a fixed length of 4 octets, and its attribute value is a 2-octet ROHC Profile Identifier [ROHCPROF]. There MUST be at least one ROHC_PROFILE attribute in the ROHC_SUPPORTED Notify message. If you send several, the order doesn't matter (it's arbitrary). The recipient MUST only use the profile(s) that were proposed for compression. 🔥
Several common profiles are defined in RFCs 3095 [ROHCV1] and 5225 [ROHCV2]. But here's the tea: two versions of the same profile MUST NOT be signaled. Like, if a ROHCoIPsec decompressor supports both ROHCv1 UDP (0x0002) and ROHCv2 UDP (0x0102), then both profiles MUST NOT be signaled. 💀 The reason is that ROHC-compressed packets only express the 8 least-significant bits of the profile identifier. Those bits are identical for the matching ROHCv1 and ROHCv2 profiles, so the decompressor can't tell which ROHC version compressed the packet. Iconic confusion, honestly. 😭
Note that ROHC_PROFILE is also a one-way notification, so different values can be announced in each direction. 👑
ROHC_INTEG (Integrity Algorithm for Verification of Decompressed Headers, AF = 1) 🔐
ROHC_INTEG is mandatory too, and there MUST be at least one ROHC_INTEG attribute in the ROHC_SUPPORTED Notify message. Its value is the identifier of an integrity algorithm, which keeps the decompressed packets honest. In other words, it makes sure the decompressed packet headers are identical to the original packet headers from before compression. ✨
Authentication algorithms that MUST be supported are listed in the "Authentication Algorithms" table in Section 3.1.1 ("ESP Encryption and Authentication Algorithms") of RFC 4835 [CRYPTO-ALG] (or its successor). 📚
The integrity algorithm is a 2-octet value that matches the value in the IKEv2 Parameters registry [IKEV2-PARA], under the "Transform Type 3 - Integrity Algorithm Transform IDs" section. When the responder gets the ROHC_INTEG attribute(s), it MUST select exactly one of the proposed algorithms. That chosen value gets sent back in the ROHC_SUPPORTED Notify message. The selected integrity algorithm MUST be used in both directions. And if the responder doesn't accept any of the initiator's proposals, ROHC MUST NOT be enabled on the SA. Big yikes, no cap. 🙈
It's noted that:
- The keys (one for each direction) for this integrity algorithm are derived from the IKEv2 KEYMAT (see [IKEV2], Section 2.17). For this key derivation, ROHC is treated as an IPsec protocol. When a ROHC-enabled CHILD_SA gets rekeyed, the key for this integrity algorithm gets rekeyed too. 🔑
- A ROHCoIPsec initiator MAY signal a value of zero (
0x0000) in a ROHC_INTEG attribute. That corresponds to "NONE" in the "IKEv2 Integrity Algorithm Transform IDs" registry. The ROHCoIPsec responder MAY select this value by responding to the initiator with a ROHC_INTEG attribute of zero (0x0000). In that case, no integrity algorithm is applied in either direction. 🍓 - The ROHC_INTEG attribute is negotiated between two ends. The initiator says what it supports, the responder picks one of the proposed ROHC_INTEG values, and then sends the selected value back to the initiator. It's a whole back-and-forth, bestie. 🫶
ROHC_ICV_LEN (Integrity Algorithm Length, AF = 1) 🌸
ROHC_ICV_LEN is optional. There MAY be zero or one ROHC_ICV_LEN attribute in the ROHC_SUPPORTED Notify message. It tells you how many Integrity Check Value (ICV) octets the sender expects to receive on incoming ROHC packets. The ICV of the negotiated ROHC_INTEG algorithm MUST be truncated to ROHC_ICV_LEN bytes, which means you take the first ROHC_ICV_LEN bytes of the output. Both the initiator and the responder announce a single value for their own ICV length. The recipient of the ROHC_ICV_LEN attribute MUST truncate the ICV to the length in the message. If the value of ROHC_ICV_LEN is zero, then an ICV MUST NOT be sent. 🙅♀️
If no ROHC_ICV_LEN attribute is sent at all, or if ROHC_ICV_LEN is larger than the length of the selected algorithm's ICV, then the full ICV length specified by the ROHC_INTEG algorithm MUST be sent. ✨
Note that ROHC_ICV_LEN is a one-way notification, so different values can be announced in each direction. 🦋
MRRU (Maximum Reconstructed Reception Unit, AF = 1) 🌈
MRRU is optional too. There MAY be zero or one MRRU attribute in the ROHC_SUPPORTED Notify message. Its value is 2 octets long, and it specifies the size, in octets, of the largest reconstructed unit that the ROHCoIPsec decompressor is expected to reassemble from ROHC segments (see Section 5.2.5 of [ROHCV1]). That size includes the Cyclic Redundancy Check (CRC) and the ROHC ICV. If MRRU is 0 or if no MRRU attribute is sent, then segment headers MUST NOT be transmitted on the ROHCoIPsec channel. 🚫
Note that MRRU is a one-way notification, so different values can be announced in each direction. 💜
If an unknown ROHC Attribute Type Value is received, it MUST be silently ignored. Shh, nobody needs to know it was there. 🤫
3.2. ROHC Channel Parameters That Are Implicitly Set 🧠
The following ROHC channel parameters MUST NOT be signaled:
- LARGE_CIDS: This value is implicitly determined by the value of MAX_CID (i.e., if MAX_CID is <= 15, LARGE_CIDS is assumed to be 0).
- FEEDBACK_FOR: When a pair of SAs is created (one in each direction), the ROHC channel parameter FEEDBACK_FOR MUST be set implicitly to the other SA of the pair (i.e., the SA pointing in the reverse direction).
Basically, these two get figured out for you, so don't waste a signal on them. 💅
4. Security Considerations 🔥
Okay, this one is serious, bestie, so pay attention. 😤 The ability to negotiate the length of the ROHC ICV may introduce vulnerabilities to the ROHCoIPsec protocol. Specifically, signaling a short ICV length may result in scenarios where erroneous packets are forwarded into the protected domain. That's a big deal! This security consideration is documented in more detail in Section 6.1.4 of [ROHCOIPSEC] and Section 5 of [IPSEC-ROHC]. 📖
You can mitigate this by using longer ICVs. But the catch is that longer ICVs add overhead, which chips away at the benefits ROHCoIPsec gives you. So it's a trade-off, and you have to decide what matters more for your setup. 💔
5. IANA Considerations 📋
This document defines a new Notify message (Status Type). So IANA has allocated one value from the "IKEv2 Notify Message Types" registry to indicate ROHC_SUPPORTED. 🎉
IANA has also created a new "ROHC Attribute Types" registry in the "Internet Key Exchange Version 2 (IKEv2) Parameters" registry [IKEV2-PARA]. Inside the "ROHC Attribute Types" registry, this document allocates the following values:
Registry:
Value ROHC Attribute Type Format Reference
----------- -------------------------------------- ------ ---------
0 RESERVED [RFC5857]
1 Maximum Context Identifier (MAX_CID) TV [RFC5857]
2 ROHC Profile (ROHC_PROFILE) TV [RFC5857]
3 ROHC Integrity Algorithm (ROHC_INTEG) TV [RFC5857]
4 ROHC ICV Length in bytes (ROHC_ICV_LEN) TV [RFC5857]
5 Maximum Reconstructed Reception Unit (MRRU) TV [RFC5857]
6-16383 Unassigned
16384-32767 Private use [RFC5857]Following the policies outlined in [IANA-CONSIDERATIONS], the IANA policy for assigning new values for the ROHC Attribute Types registry shall be Expert Review. 🧐
For registration requests, the responsible IESG Area Director will appoint the Designated Expert. The Designated Expert will post a request to both the ROHC and IPsec mailing lists (or a successor designated by the Area Director) for comment and review. The Designated Expert will either approve or deny the registration request and publish a notice of the decision to both mailing lists (or their successors), as well as informing IANA. A denial notice must be justified by an explanation. Receipts, please. 📬
6. Acknowledgments 🫶
The authors would like to thank Sean O'Keeffe, James Kohler, and Linda Noone of the Department of Defense, as well as Rich Espy of OPnet, for their contributions and support in the development of this document. 🌟
The authors would also like to thank Yoav Nir and Robert A Stangarone Jr., who both served as committed document reviewers for this specification. 👏
In addition, the authors would like to thank the following for their numerous reviews and comments on this document:
- Magnus Westerlund
- Stephen Kent
- Lars-Erik Jonsson
- Pasi Eronen
- Jonah Pezeshki
- Carl Knutsson
- Joseph Touch
- David Black
- Glen Zorn
Finally, the authors would also like to thank Tom Conkle, Michele Casey, and Etzel Brower. 💖
7. References 📚
7.1. Normative References 📚✨
okay bestie, these are the big-deal docs this one leans on, so you can't skip them 🫶
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[ROHC] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[BRA97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[ROHCV1] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008.
[IPSEC-ROHC] Ertekin, E., Christou, C., and C. Bormann, "IPsec Extensions to Support Robust Header Compression over IPsec", RFC 5858, May 2010.
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
7.2. Informative References 💜
these ones are just extra reading that's super helpful for context 🌸
[ROHCOIPSEC] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, "Integration of Header Compression over IPsec Security Associations", RFC 5856, May 2010.
[ROHC-PPP] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[ROHCPROF] IANA, "RObust Header Compression (ROHC) Profile Identifiers", <http://www.iana.org>.
[CRYPTO-ALG] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[IKEV2-PARA] IANA, "Internet Key Exchange Version 2 (KEv2) Parameters", <http://www.iana.org>.
Authors' Addresses 🦋
Here are the wonderful people who wrote it, with their contact details 🎀
Emre Ertekin
Booz Allen Hamilton
5220 Pacific Concourse Drive, Suite 200
Los Angeles, CA 90045
US
EMail: ertekin_emre@bah.com
Chris Christou
Booz Allen Hamilton
13200 Woodland Park Dr.
Herndon, VA 20171
US
EMail: christou_chris@bah.com
Rohan Jasani
Booz Allen Hamilton
13200 Woodland Park Dr.
Herndon, VA 20171
US
EMail: ro@breakcheck.com
Tero Kivinen
AuthenTec, Inc.
Fredrikinkatu 47
HELSINKI
FI
EMail: kivinen@iki.fi
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28334
Germany
EMail: cabo@tzi.orgThat's the whole thing, bestie! 🌈👑 You made it through the entire RFC 💅
📦 where this page comes from
- ietf: rfc5857 2010-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms