RFC 5856

Integration of Robust Header Compression over IPsec Security Associations

📅 published May 2010, from ietf

RFC 5856: Integration of Robust Header Compression over IPsec Security Associations ✨

okay bestie, this is RFC 5856 💖 It's an Informational doc (not a Standards Track spec 🦋), published by the IETF in May 2010, with ISSN 2070-1721. The authors are E. Ertekin, R. Jasani, and C. Christou from Booz Allen Hamilton, plus C. Bormann from Universitaet Bremen TZI 🌸. The title block doesn't list anything it obsoletes or updates.

Abstract

okay so IPsec gives us a bunch of security goodies for IP traffic 🔐, but ngl those goodies come with extra overhead 😭. This doc lays out a framework for mixing Robust Header Compression with IPsec, which they call ROHCoIPsec 🧚. The idea is to compress the inner headers of IP packets so less overhead gets sent over IPsec Security Associations (SAs) 💅. Iconic compression energy.

Status of This Memo

Here's the tea: this document is not an Internet Standards Track specification 🍓. It's published just for info purposes ✨.

It's a product of the Internet Engineering Task Force (IETF), and the Internet Engineering Steering Group (IESG) approved it for publication 👑. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious about that 🤓.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5856 🫶.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date of publication 📜. Please read those carefully, since they spell out your rights and restrictions for this doc. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🌈.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008 🕰️. The people controlling the copyright in some of that 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 those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙈.

   1. Introduction ....................................................3
   2. Audience ........................................................3
   3. Terminology .....................................................3
   4. Problem Statement: IPsec Packet Overhead ........................4
   5. Overview of the ROHCoIPsec Framework ............................5
      5.1. ROHCoIPsec Assumptions .....................................5
      5.2. Summary of the ROHCoIPsec Framework ........................5
   6. Details of the ROHCoIPsec Framework .............................7
      6.1. ROHC and IPsec Integration .................................7
           6.1.1. Header Compression Protocol Considerations ..........9
           6.1.2. Initialization and Negotiation of the ROHC Channel ..9
           6.1.3. Encapsulation and Identification of Header
                  Compressed Packets .................................10
           6.1.4. Motivation for the ROHC ICV ........................11
           6.1.5. Path MTU Considerations ............................11
      6.2. ROHCoIPsec Framework Summary ..............................12
   7. Security Considerations ........................................12
   8. IANA Considerations ............................................12
   9. Acknowledgments ................................................13
   10. Informative References ........................................14

1. Introduction ✨

okay so this doc lays out a framework for combining ROHC [ROHC] with IPsec [IPSEC], which they call ROHCoIPsec 🦋. The whole goal is to cut down on the protocol overhead for packets moving between IPsec SA endpoints 💅. How? You compress the transport layer header (like UDP, TCP, etc.) and the inner IP header at the ingress of the IPsec tunnel, then decompress them at the egress 🎀.

Here's the thing: this doc assumes ROHC will be used to compress the inner headers of IP packets going through an IPsec tunnel 🌸. BUT, current ROHC specs describe how it works hop by hop, so it needs extensions to run over IPsec SAs 😭. This doc sketches out how to extend ROHC so it works at IPsec SA endpoints ✨.

ROHCoIPsec targets tunnel mode SAs 👑. Transport mode SAs only protect the payload of an IP packet and leave the IP header alone 🧚. Intermediate routers then use that IP header to route the packet to a decryption device 🚏. So if ROHC were going to work over IPsec transport-mode SAs, the (de)compression could only touch the transport layer headers, not the IP header 🙈. And since current ROHC specs don't support compressing transport layer headers alone, this framework describes applying ROHC to tunnel mode SAs instead 💅.

2. Audience 🎀

This doc is aimed at people in both the ROHC and IPsec communities who might want to extend those protocols to meet the requirements in this document 💜. It's also for vendors building IPsec devices that will be deployed in bandwidth-constrained IP networks 🫶.

3. Terminology 📖

ROHC Process

Generic reference to a ROHC instance (as defined in RFC 3759 [ROHC-TERM]) or any supporting ROHC components 🧩.

Compressed Traffic

Traffic that goes through the ROHC compressor and decompressor instances. Packet headers get compressed and decompressed using a specific header compression profile 🗜️.

Uncompressed Traffic

Traffic that the ROHC compressor instance doesn't process. This kind of traffic just skips the ROHC process entirely 🏃‍♀️.

IPsec Process

Generic reference to the Internet Protocol Security (IPsec) process 🔐.

Next Header

Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) field 🌈.

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] 💅. These are the official key words, so they're the only ones that carry that special weight ✨.

4. Problem Statement: IPsec Packet Overhead 😭

IPsec mechanisms give us various security services for IP networks 🔒. BUT the benefits come at the cost of increased per-packet overhead 💀. For example, traffic flow confidentiality (usually leveraged at security gateways) requires tunneling IP packets between IPsec implementations 🚇. These IPsec tunnels do hide the source-destination patterns an intruder could figure out, but tunneling means more packet overhead 🙃.

Specifically, an Encapsulating Security Payload (ESP) tunnel mode SA applied to an IPv6 flow adds at least 50 bytes of overhead per packet 😱. That extra overhead can be a real problem for bandwidth-constrained wireless and/or satellite networks, since that infrastructure isn't overprovisioned 📡. ROHC applied per hop over bandwidth-constrained links also takes a performance hit when encryption is used on the tunneled header, because encrypted headers can't be compressed 🔐🚫. So the extra overhead from an IPsec tunnel can lead to inefficient use of bandwidth 📉.

Packet overhead matters even more for traffic with small payloads, like various voice codecs 🎙️. When small packets get the security services of an IPsec tunnel mode SA, the per-packet overhead goes up even more 📈. So yeah, a mechanism is needed to cut down the overhead for these flows 🫶.

5. Overview of the ROHCoIPsec Framework 🗺️

5.1. ROHCoIPsec Assumptions

The goal of ROHCoIPsec is to move IP packets efficiently between IPsec devices WITHOUT compromising the security services IPsec offers 🔐✨. The framework was developed based on these assumptions:

ROHC will be leveraged to reduce the overhead for unicast IP packets traversing an IPsec SA 💖.
ROHC will be instantiated at the IPsec SA endpoints, and it will be applied on a per-SA basis 🎀.
Once the decompression operation completes, decompressed packet headers will be identical to the original packet headers before compression 🦋.

(to be continued in part 2 🌈)

5.2. Summary of the ROHCoIPsec Framework ✨

okay so ROHC's whole thing is shrinking packets by spotting repeats, both inside a single packet and across packets in the same flow, in the network and transport-layer header fields 🫶

Current ROHC specs compress headers on a hop-by-hop basis. But IPsec SAs are set up between two IPsec endpoints, not hop by hop, so a bunch of extensions to both ROHC and IPsec need to be defined to make ROHC actually work at SA endpoints 💅

Running ROHC over IPsec SAs is honestly the easy part, bestie, because SA endpoints give you source/destination pairs where the (de)compression can happen. Compressing the inner IP and upper layer protocol headers this way cuts down overhead between the two SA endpoints ✨ Here's the catch: ROHC now runs between IPsec endpoints, over multiple intermediate nodes that are transparent to an IPsec SA. So it is imperative to make sure performance doesn't get wrecked by more packet reordering and/or packet loss between the compressor and decompressor 😭

ROHC also can't lean on the link layer anymore for channel parameter configuration and packet identification 💀 The ROHCoIPsec framework says the channel parameter configuration is handled by an SA management protocol (e.g., Internet Key Exchange Protocol version 2 (IKEv2) [IKEV2]), while compressed-header packets get identified through the Next Header field of the security protocol (e.g., Authentication Header (AH) [AH], ESP [ESP]) header 🎀

Using the ROHCoIPsec framework, outbound and inbound IP traffic processing at an IPsec device needs to be modified 🔥 For an outbound packet, a ROHCoIPsec implementation compresses the appropriate packet headers, then encrypts and/or integrity protects the packet. For tunnel mode SAs, compression may be applied to the transport layer and the inner IP headers. For inbound packets, an IPsec device has to decrypt and/or integrity check the packet first. Then the inner packet headers get decompressed. After decompression, the packet is checked against the access controls imposed on all inbound traffic associated with the SA (as specified in RFC 4301 [IPSEC]) 👑

Note: Compression of inner headers is independent from compression of the security protocol (e.g., ESP) and outer IP headers. ROHC profiles have been defined to allow for the compression of the security protocol and the outer IP header on a hop-by-hop basis. The applicability of ROHCoIPsec and hop-by-hop ROHC on an IPv4 ESP-processed packet [ESP] is shown below in Figure 1. 🧚

        -----------------------------------------------------------
  IPv4  | new IP hdr  |     | orig IP hdr   |   |    | ESP   | ESP|
        |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
        -----------------------------------------------------------
        |<-------(1)------->|<------(2)-------->|

        (1) Compressed hop-by-hop by the ROHC [ROHC]
            ESP/IP profile
        (2) Compressed end-to-end by the ROHCoIPsec [IPSEC-ROHC]
            TCP/IP profile

Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an IPv4 ESP-processed packet.

If IPsec NULL encryption is applied to packets, ROHC may still be used to compress the inner headers at IPsec SA endpoints. But compressing these inner headers may pose challenges for intermediary devices (e.g., traffic monitors, sampling/management tools) that inspect the contents of ESP-NULL packets 🙈 For example, policies on these devices may need to be updated so that packets containing the "ROHC" protocol identifier aren't dropped. Intermediary devices may also need extra functionality to figure out the content of the header compressed packets.

In certain scenarios, a ROHCoIPsec implementation may run into UDP-encapsulated ESP or IKE packets (i.e., packets traversing NATs) 🌸 For example, a ROHCoIPsec implementation may receive a UDP-encapsulated ESP packet that contains an ESP/UDP/IP header chain. Right now, ROHC profiles don't support compressing the entire header chain for this packet. Only the UDP/IP headers can be compressed, which is a bit of a bummer tbh 🥺

6. Details of the ROHCoIPsec Framework 🦋

6.1. ROHC and IPsec Integration

Figure 2 shows the components you need to integrate ROHC with the IPsec process, i.e., ROHCoIPsec 💜

              +-------------------------------+
              | ROHC Module                   |
              |                               |
              |                               |
    +-----+   |     +-----+     +---------+   |
    |     |   |     |     |     |  ROHC   |   |
  --|  A  |---------|  B  |-----| Process |------> Path 1
    |     |   |     |     |     |         |   |   (ROHC-enabled SA)
    +-----+   |     +-----+     +---------+   |
       |      |        |                      |
       |      |        |-------------------------> Path 2
       |      |                               |   (ROHC-enabled SA,
       |      +-------------------------------+  but no compression)
       |
       |
       |
       |
       +-----------------------------------------> Path 3
                                                  (ROHC-disabled SA)

Figure 2. Integration of ROHC with IPsec

The process in Figure 2 augments the IPsec processing model for outbound IP traffic (protected-to-unprotected) 🌈 Initial IPsec processing stays consistent with RFC 4301 [IPSEC] (Section 5.1, Steps 1-2).

Block A: The ROHC data item (part of the SA state information) pulled from the "relevant SAD entry" ([IPSEC], Section 5.1, Step3a) decides whether the traffic going through the SA gets handed to the ROHC module. Packets selected to a ROHC-disabled SA MUST follow normal IPsec processing and MUST NOT be sent to the ROHC module (Figure 2, Path 3). Packets selected to a ROHC-enabled SA, on the other hand, MUST be sent to the ROHC module ⭐

Block B: This step checks whether the packet can be compressed 🍓 If the packet is compressed, an integrity algorithm MAY be used to compute an Integrity Check Value (ICV) for the uncompressed packet ([IPSEC-ROHC], Section 4.2; [IKE-ROHC], Section 3.1). The Next Header field of the security protocol header (e.g., ESP, AH) MUST be populated with a "ROHC" protocol identifier [PROTOCOL], inner packet headers MUST be compressed, and the computed ICV MAY be appended to the packet (Figure 2, Path 1). However, if it's determined that the packet won't be compressed (e.g., due to one of the reasons described in Section 6.1.3), the Next Header field MUST be populated with the appropriate value indicating the next-level protocol (Figure 2, Path 2), and ROHC processing MUST NOT be applied to the packet.

After the ROHC process completes, IPsec processing resumes, as described in Section 5.1, Step3a, of RFC 4301 [IPSEC] 💅

The process in Figure 2 also augments the IPsec processing model for inbound IP traffic (unprotected-to-protected). For inbound packets, IPsec processing is performed ([IPSEC], Section 5.2, Steps 1-3), followed by AH or ESP processing ([IPSEC], Section 5.2, Step 4).

Block A: After AH or ESP processing, the ROHC data item retrieved from the SAD entry indicates whether the traffic traversing the SA is processed by the ROHC module ([IPSEC], Section 5.2, Step 3a). Packets traversing a ROHC-disabled SA MUST follow normal IPsec processing and MUST NOT be sent to the ROHC module. Packets traversing a ROHC-enabled SA, conversely, MUST be sent to the ROHC module 🦋

Block B: The decision at Block B is made using the value of the Next Header field of the security protocol header. If the Next Header field doesn't indicate a ROHC header, the decompressor MUST NOT attempt decompression (Figure 2, Path 2). If the Next Header field does indicate a ROHC header, decompression gets applied. After decompression, the signaled ROHCoIPsec integrity algorithm MAY be used to compute an ICV value for the decompressed packet. This ICV, if present, is compared to the ICV that was calculated at the compressor. If the ICVs match, the packet is forwarded by the ROHC module (Figure 2, Path 1); otherwise, the packet MUST be dropped 🥹 Once the ROHC module finishes processing, IPsec processing resumes, as described in Section 5.2, Step 4, of RFC 4301 [IPSEC].

When there's a single SA between a compressor and decompressor, ROHC MUST operate in unidirectional mode, as described in Section 5 of RFC 3759 [ROHC-TERM] 🔥 When there's a pair of SAs instantiated between ROHCoIPsec implementations, ROHC MAY operate in bi-directional mode, where an SA pair represents a bi-directional ROHC channel (as described in Sections 6.1 and 6.2 of RFC 3759 [ROHC-TERM]).

Note that to further reduce the size of an IPsec-protected packet, ROHCoIPsec and IPComp [IPCOMP] can be implemented in a nested fashion 🌸 This process is detailed in [IPSEC-ROHC], Section 4.4.

6.1.1. Header Compression Protocol Considerations

ROHCv2 [ROHCV2] profiles include various mechanisms that give increased robustness over reordering channels. These mechanisms SHOULD be adopted for ROHC to operate efficiently over IPsec SAs 🧚

A ROHC decompressor implemented within the IPsec architecture MAY leverage additional mechanisms to improve performance over reordering channels (either due to random events or to an attacker intentionally reordering packets). Specifically, IPsec's sequence number MAY be used by the decompressor to identify a packet as "sequentially late". This knowledge increases the likelihood of successfully decompressing a reordered packet 💖

Additionally, ROHCoIPsec implementations SHOULD minimize the amount of feedback sent from the decompressor to the compressor. If a ROHC feedback channel isn't used sparingly, the overall gains from ROHCoIPsec can be significantly reduced 😭 More specifically, any feedback sent from the decompressor to the compressor MUST be processed by IPsec and tunneled back to the compressor (as designated by the SA associated with FEEDBACK_FOR). As such, some implementation alternatives can be considered, including the following:

Eliminate feedback traffic altogether by operating only in ROHC Unidirectional mode (U-mode).
Piggyback ROHC feedback messages within the feedback element (i.e., on ROHC traffic that normally traverses the SA designated by FEEDBACK_FOR). 🫶

6.1.2. Initialization and Negotiation of the ROHC Channel

Okay so hop-by-hop ROHC usually leans on the link layer (like PPP) to negotiate its channel parameters 🧚. For ROHCoIPsec, those parameters can be set by hand (administratively configured for manual SAs) or negotiated by IKEv2. The IKEv2 extensions that handle ROHC channel parameter negotiation are detailed in [IKE-ROHC] 💅.

If ROHC needs bi-directional communication, two SAs MUST be instantiated between the IPsec implementations 🔥. One SA carries ROHC traffic from the compressor to the decompressor, and the other carries ROHC feedback from the decompressor back to the compressor. The two-SA setup is totally on-brand for IKE, which creates SAs in pairs by default 🫶. IPsec implementations get to decide how decompressor feedback that arrives on one SA gets linked to a compressor on the other SA. An IPsec implementation MUST relay the feedback the decompressor receives on an inbound SA to the compressor tied to the matching outbound SA 💜.

6.1.3. Encapsulation and Identification of Header Compressed Packets

As mentioned in Section 6.1, there's new state info (a brand new ROHC data item) defined for each SA 🌸. The ROHC data item MUST be used by the IPsec process to decide whether it sends all the traffic crossing a given SA to the ROHC module (ROHC-enabled), or skips the ROHC module and runs the traffic through regular IPsec processing (ROHC-disabled) 🎀.

The Next Header field of the IPsec security protocol header (like AH or ESP) MUST be used to tell header-compressed traffic apart from uncompressed traffic on a ROHC-enabled SA 🦋. This matters because packets on a ROHC-enabled SA can sometimes have uncompressed headers. That can happen when, say, a compressor only supports up to n compressed flows and can't compress flow number n+1 when it shows up 😭. It can also happen when traffic gets selected for a ROHC-enabled SA but ROHC can't compress it, because the right ROHC Profile hasn't been signaled for use. So the decompressor MUST be able to spot packets with uncompressed headers and MUST NOT attempt to decompress them 🙈. The Next Header field does the sorting: the "ROHC" protocol identifier means the packet has compressed headers ✨. IANA allocated value 142 to "ROHC" from the Protocol ID registry [PROTOCOL] 👑.

It's noted that the "ROHC" protocol identifier isn't defined for anything other than ROHCoIPsec right now 💀. Put simply, the "ROHC" protocol identifier is only defined for use in the Next Header field of security protocol headers (like ESP and AH) 🍓.

The ROHC Data Item, the IANA Protocol ID allocation, and the other IPsec extensions that support ROHCoIPsec are specified in [IPSEC-ROHC] 🌈.

6.1.4. Motivation for the ROHC ICV

Okay this one is a little serious, bestie 😭. ROHC was designed to tolerate packet loss and reordering, but the algorithm doesn't guarantee that packets rebuilt at the decompressor are identical to the originals. As Section 5.2 of RFC 4224 [REORDR] states, packet reordering between ROHC peers can lead to undetected decompression failures, where erroneous packets get constructed and forwarded to upper layers 🥀. Significant packet loss can cause similar problems 💔.

With IPsec integrity protection, a packet that comes out the egress of an IPsec tunnel is identical to the packet that went in at the ingress 💖. This holds as long as the key isn't compromised, etc. 🔐.

When ROHC gets integrated into the IPsec processing framework, the ROHC processed packet is protected by the AH/ESP ICV ✨. But bits in the original IP header aren't covered by that ICV. They're only protected by ROHC's own integrity mechanisms, which are designed for random packet loss and reordering, not for malicious loss or reordering pushed by an attacker 🚨. So in certain circumstances, erroneous packets may be constructed and forwarded into the protected domain 😬.

To make sure the original IP header stays intact inside the ROHCoIPsec processing model, an additional integrity check MAY be applied before the packet is compressed 🛡️. That check makes sure erroneous packets don't get forwarded into the protected domain. The specifics of this integrity check are documented in Section 4.2 of [IPSEC-ROHC] 🧚.

6.1.5. Path MTU Considerations

IPsec encapsulates IP packets with AH/ESP and tunnels IP headers, which makes the packets bigger 📦. That growth can cause Path MTU issues in the unprotected domain 🌊. Several ways of dealing with these path MTU issues are documented in Section 8 of RFC 4301 [IPSEC] 📖. The options include fragmenting the packet before or after IPsec processing (if the packet's Don't Fragment (DF) bit is clear), or possibly discarding packets (if the packet's DF bit is set) 🙃.

Adding ROHC to the IPsec processing model can bring similar path MTU challenges 💅. For example, in certain circumstances ROHC headers are larger than the original uncompressed headers 😳. Also, if an integrity algorithm is used to validate packet headers, the resulting ICV makes the packets bigger too. Both of these things make ROHCoIPsec packets larger, so they can cause extra path MTU challenges 💜.

Approaches to these path MTU issues are specified in Section 4.3 of [IPSEC-ROHC] 🎀.

6.2. ROHCoIPsec Framework Summary

So, to sum it all up, here's what you need to achieve ROHCoIPsec 💖:

IKEv2 Extensions to Support ROHCoIPsec
IPsec Extensions to Support ROHCoIPsec

7. Security Considerations

Several security considerations for ROHCoIPsec are covered in Section 6.1.4 🚨. These can be mitigated by using a strong integrity-check algorithm to make sure packet headers decompress validly 🔒.

A malfunctioning or malicious ROHCoIPsec compressor (the compressor at the ingress of the IPsec tunnel) can send erroneous packets to the decompressor (the decompressor at the egress of the IPsec tunnel). These packets won't match the originals emitted by the end-hosts 💀. That can hurt efficiency between the compressor and decompressor, or make the decompressor forward erroneous packets into the protected domain 😱. A malicious compressor could also deliberately generate a huge number of compressed packets. That could cause denial of service at the decompressor, since decompressing a flood of invalid packets may drain the resources of an IPsec device 🔥.

A malfunctioning or malicious ROHCoIPsec decompressor can also wreck communications 💔. For example, a decompressor may simply discard some (or all) of the packets it receives, even when their headers decompressed validly. Ultimately, that could lead to denial of service 🥺. A malicious decompressor could also deliberately claim its context isn't synchronized with the compressor's context, which forces the compressor down to a lower compression state. That cuts into the overall efficiency gain ROHCoIPsec offers 📉.

8. IANA Considerations

All IANA considerations for ROHCoIPsec are documented in [IKE-ROHC] and [IPSEC-ROHC] 📝.

9. Acknowledgments

The authors want to thank Sean O'Keeffe, James Kohler, and Linda Noone of the Department of Defense, plus Rich Espy of OPnet, for their contributions and support in developing this document 🫶.

The authors also want to thank Yoav Nir and Robert A Stangarone Jr., who both served as committed document reviewers for this specification 🌟.

The authors would also like to thank the following folks for their numerous reviews and comments on this document 💜:

Magnus Westerlund
Stephen Kent
Pasi Eronen
Joseph Touch
Tero Kivinen
Jonah Pezeshki
Lars-Erik Jonsson
Jan Vilhuber
Dan Wing
Kristopher Sandlund
Ghyslain Pelletier
David Black
Tim Polk
Brian Carpenter

Finally, the authors want to thank Tom Conkle, Renee Esposito, Etzel Brower, and Michele Casey of Booz Allen Hamilton for their help in completing this work 🎀✨.

10. Informative References

[ROHC]        Sandlund, K., Pelletier, G., and L-E. Jonsson, "The
              RObust Header Compression (ROHC) Framework", RFC 5795,
              March 2010.

[IPSEC]       Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

[ROHC-TERM]   Jonsson, L-E., "Robust Header Compression (ROHC):
              Terminology and Channel Mapping Examples", RFC 3759,
              April 2004.

[BRA97]       Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[IKEV2]       Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

[ESP]         Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

[AH]          Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

[IPSEC-ROHC]  Ertekin, E., Christou, C., and C. Bormann, "IPsec
              Extensions to Support Robust Header Compression over
              IPsec", RFC 5858, May 2010.

[IKE-ROHC]    Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and
              C. Bormann, "IKEv2 Extensions to Support Robust Header
              Compression over IPsec", RFC 5857, May 2010.

[PROTOCOL]    IANA, "Assigned Internet Protocol Numbers",
              <http://www.iana.org>.

[IPCOMP]      Shacham, A., Monsour, B., Pereira, R., and M. Thomas,
              "IP Payload Compression Protocol (IPComp)", RFC 3173,
              September 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.

[REORDR]      Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust
              Header Compression (ROHC): ROHC over Channels That Can
              Reorder Packets", RFC 4224, January 2006.

Authors' Addresses ✨

Emre Ertekin
Booz Allen Hamilton
5220 Pacific Concourse Drive, Suite 200
Los Angeles, CA  90045
US

EMail: ertekin_emre@bah.com


Rohan Jasani
Booz Allen Hamilton
13200 Woodland Park Dr.
Herndon, VA  20171
US

EMail: ro@breakcheck.com


Chris Christou
Booz Allen Hamilton
13200 Woodland Park Dr.
Herndon, VA  20171
US

EMail: christou_chris@bah.com


Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen  D-28334
Germany

EMail: cabo@tzi.org

📦 where this page comes from

ietf: rfc5856 2010-05
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms