RFC 5858
IPsec Extensions to Support Robust Header Compression over IPsec
IPsec Extensions to Support Robust Header Compression over IPsec ✨
Title block tea 🍵: this one is an Internet Standards Track doc from the IETF, dated May 2010, with ISSN 2070-1721. The authors are E. Ertekin and C. Christou (both at Booz Allen Hamilton) and C. Bormann (Universitaet Bremen TZI). The title block doesn't list anything it obsoletes or updates 🤷♀️
Abstract
Okay so, putting Robust Header Compression (ROHC) together with IPsec (that's ROHCoIPsec) gives you the best of both worlds: IP security and way better bandwidth use 🦋. But to make that happen, the Security Policy Database (SPD) and the Security Association Database (SAD) need some upgrades first 💅. This doc spells out the IPsec extensions needed to make ROHCoIPsec work.
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5858.
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 these documents carefully, as 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 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. Extensions to IPsec Databases ...................................3
3.1. Security Policy Database (SPD) .............................4
3.2. Security Association Database (SAD) ........................5
4. Extensions to IPsec Processing ..................................6
4.1. Identification of Header-Compressed Traffic ................6
4.2. Verifying the Integrity of Decompressed Packet Headers .....6
4.2.1. ICV Computation and Integrity Verification ..........7
4.3. ROHC Segmentation and IPsec Tunnel MTU .....................8
4.4. Nested IPComp and ROHCoIPsec Processing ....................9
5. Security Considerations ........................................10
6. IANA Considerations ............................................10
7. Acknowledgments ................................................11
Appendix A. ASN.1 Representation for ROHCoIPsec ...................12
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................141. Introduction 🎀
So, IPsec ([IPSEC]) gives you a bunch of security perks for IP traffic, but ngl, all that protection comes with extra headers that pile on packet overhead 😩. Compressing the inner headers fixes that. Put Robust Header Compression (ROHC, [ROHC]) together with IPsec (ROHCoIPsec, [ROHCOIPSEC]) and the packet overhead for IPsec-protected flows drops. Iconic 👑
IPsec traffic rides in Security Associations (SAs), and their parameters get negotiated case by case 🧚. The SPD lays out which services get offered to IP datagrams, and the parameters for SAs that already exist get stored in the SAD. For ROHCoIPsec, both the SPD and the SAD need new ROHC-related parameters added 💜.
On top of that, there are three extensions to IPsec processing that we need. First, we need a way to identify ROHC packets, and that mechanism must be defined. Second, there needs to be a way to make sure the decompressed packet is intact. Third, the order of inbound and outbound processing must be spelled out when IP Compression (IPComp [IPCOMP]), ROHC, and IPsec all get nested together 🔥.
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. Extensions to IPsec Databases 🌸
The subsections below spell out the SPD and SAD extensions that MUST be supported for ROHCoIPsec 🫶. The ROHCoIPsec fields in the SPD are used to fill in the ROHCoIPsec parameters in the SAD when a child SA gets initialized or rekeyed.
Fun fact (well, a fact): these extensions don't touch any existing SPD fields or SAD parameters at all. So a ROHCoIPsec implementation stays backwards-compatible with an IPsec implementation that doesn't do header compression 💖.
Appendix A has an example ASN.1 representation of an SPD that's been extended for ROHC 🧁.
3.1. Security Policy Database (SPD) 💅
In general, the SPD decides which security services get offered to IP datagrams 🦋. SPD entries also spell out how to derive the matching values for SAD entries. To support ROHC, the SPD gets extended with per-channel ROHC parameters ✨. The existing IPsec SPD parameters and the ROHC parameters together decide which security and header compression services packets actually get.
The fields in each SPD entry are defined in RFC 4301 [IPSEC], Section 4.4.1.2. For ROHC, a few processing info fields get added to the SPD. These hold info about the ROHC profiles and channel parameters the local ROHC instance supports 🌈.
If the processing action tied to the selector sets is PROTECT, then the processing info must be extended with these ROHC channel parameters:
- MAX_CID: this is the highest context ID the local decompressor will decompress.
MAX_CIDMUST be at least 0 and at most 16383 (the value 0 implies having one context). 🔢 - MRRU: this is the size, in octets, of the largest reconstructed unit the local decompressor is expected to reassemble from ROHC segments. That size includes the Cyclic Redundancy Check (CRC) and the ROHC Integrity Check Value (ICV). NOTE: since in-order delivery of ROHC packets can't be guaranteed, the
MRRUparameter SHOULD be set to 0 (as stated in Section 5.2.5.1 of RFC 5795 [ROHC] and Section 6.1 of RFC 5225 [ROHCV2]), which means no segment headers are allowed on the ROHCoIPsec channel 🙈. - PROFILES: this is a list of the ROHC profiles the local decompressor supports. Possible values for this list are in the "RObust Header Compression (ROHC) Profile Identifiers" registry [ROHCPROF] 📋.
Besides these ROHC channel parameters, a ROHC integrity algorithm and a ROHC ICV Length field MUST be included in the SPD too 🔐:
- ROHC INTEGRITY ALGORITHM: this is a list of integrity algorithms the ROHCoIPsec instance supports. The ROHC process uses it to make sure packet headers get decompressed properly (see Section 4.2). Authentication algorithms that MUST be supported are the ones listed in the "Authentication Algorithms" table in Section 3.1.1 ("ESP Encryption and Authentication Algorithms") of RFC 4835 [CRYPTO-ALG] (or its successor) 💜.
- ROHC ICV LENGTH: this field gives the length of the ICV used together with the ROHC integrity algorithm 📏.
A few other ROHC channel parameters are left out of the SPD, because they get set implicitly. Those are LARGE_CIDS and FEEDBACK_FOR 🤫. The LARGE_CIDS channel parameter MUST be set based on the value of MAX_CID (so if MAX_CID is <= 15, LARGE_CIDS is assumed to be 0). Last but not least, the ROHC FEEDBACK_FOR channel parameter MUST be set to the ROHC channel tied to the SA in the reverse direction. If there's no SA in the reverse direction, the FEEDBACK_FOR channel parameter doesn't get set, and ROHC MUST NOT operate in bi-directional Mode 🚫💀
3.2. Security Association Database (SAD) ✨
okay so each entry in the SAD is basically the cheat sheet for one established SA 📋✨ it holds all the parameters for that SA. Unless the "populate from packet" (PFP) flag is asserted for a particular field, those SAD entries get filled in from the matching SPD entries when the SA is created 🫶
The data items in the SAD are defined in Section 4.4.2.1 of RFC 4301 [IPSEC] 💅 To support ROHC, the SAD has to include a "ROHC Data Item" 🎀 This is the bit with the parameters the ROHC instance uses, and it exists for both inbound and outbound SAs 🦋
The ROHC Data Item holds the ROHC channel parameters for the SA 🌸 Those are MAX_CID, PROFILES, and MRRU, which we already went over in Section 3.1 🌈 For inbound SAs, the ROHC Data Item MUST specify the ROHC channel parameters used by the local decompressor instance 🫧 For outbound SAs, it's the other way around: the ROHC Data Item MUST specify the ROHC channel parameters used by the local compressor instance 💜
Besides those channel parameters, the ROHC Data Item for both inbound and outbound SAs MUST include three more parameters 👑 Those store the integrity algorithm, the algorithm's key, and the ICV length that the ROHC process uses (see Section 3.2) 🔥 The integrity algorithm and its key calculate a ROHC ICV of the specified length, and that ICV is what gets used to verify the packet headers after decompression 🍓
Last one: for inbound SAs, the ROHC Data Item MUST include a FEEDBACK_FOR parameter 🧚 It's a reference to a ROHC channel going the opposite way (aka the outbound SA) between the same compression endpoints 🔁 An inbound ROHC channel and an outbound ROHC channel MAY be coupled into a bi-directional ROHC channel, as defined in Sections 6.1 and 6.2 in RFC 3759 [ROHC-TERM] 🦋✨
"ROHC Data Item" values MAY be set manually (administratively configured for manual SAs) 🛠️ or they MAY be initialized through a key exchange protocol, like IKEv2 [IKEV2], that's been extended to signal ROHC parameters [IKE-ROHC] 💖
4. Extensions to IPsec Processing 🌷
4.1. Identification of Header-Compressed Traffic
okay this part is about how you know a packet is compressed 🕵️♀️ A "ROHC" protocol identifier marks header-compressed traffic on a ROHC-enabled SA ✨ If an outbound packet has a compressed header, the Next Header field of the security protocol header (like Authentication Header (AH) [AH] or Encapsulating Security Payload (ESP) [ESP]) MUST be set to the "ROHC" protocol identifier 🎀 If the header wasn't compressed by ROHC, the Next Header field does not contain the "ROHC" protocol identifier 🙈
For inbound packets, the value of the security protocol Next Header field MUST be checked to find out if the packet has a ROHC header, which tells you whether it needs ROHC decompression 🔍💅
Using the "ROHC" protocol identifier for anything other than ROHCoIPsec isn't defined right now 🚫 Future protocols that use that allocation (for example, other ROHC uses in multi-hop environments) will need to specify the logical compression channel between the ROHC compressor and decompressor 🌈 Those specs will also need to look into the security considerations of using the "ROHC" protocol identifier outside the Next Header field of security protocol headers 😭🔐
4.2. Verifying the Integrity of Decompressed Packet Headers
this section is the drama of the whole doc 😭 As Section 6.1.4 of [ROHCOIPSEC] explains, ROHC is inherently a lossy compression algorithm 💀 If packets get reordered or lost in a big way between ROHC peers, you can end up with undetected decompression failures, where bad packets get forwarded into the protected domain 🚨
So to make sure a decompressed header matches the original, ROHCoIPsec MAY use an extra integrity algorithm (and its key) to compute a second Integrity Check Value (ICV) 🔐 This ROHC ICV MUST be computed over the uncompressed IP header, as well as the higher-layer headers and the packet payload 🫶 When it's computed, the ICV gets appended to the ROHC-compressed packet 🎀 On the decompressor side, the decompressed packet (the uncompressed IP header, higher-layer headers, and payload, but not the authentication data) goes through the integrity algorithm and its key to produce a value, which gets compared to the appended ICV 🔍 If those values aren't identical, the decompressed packet MUST be dropped 🗑️💀
Figure 1 shows what a ROHCoIPsec-processed IPv4 packet looks like 🦋 In this example, TCP/IP compression is applied and the packet is processed with tunnel mode ESP 🌸
BEFORE COMPRESSION AND APPLICATION OF ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER ROHCOIPSEC COMPRESSION AND APPLICATION OF ESP
------------------------------------------------------
IPv4 | new IP hdr | | Cmpr. | | ROHC | ESP | ESP|
|(any options)| ESP | Hdr. |Data| ICV |Trailer| ICV|
------------------------------------------------------Figure 1. Example of a ROHCoIPsec-Processed Packet
Note: At the decompressor, the ROHC ICV field is not included in the calculation of the ROHC ICV. 👀
4.2.1. ICV Computation and Integrity Verification
okay the order of operations here is everything 🔢 To correctly verify the integrity of decompressed packets, the ROHCoIPsec processing steps MUST be implemented in the specific order given below 💅
For outbound packets that are processed by ROHC and are IPsec-protected, you:
- Compute an ICV for the uncompressed packet with the negotiated (ROHC) integrity algorithm and its key 🔐
- Compress the packet headers (as the ROHC process specifies) 🗜️
- Append the ICV to the compressed packet 🎀
- Apply AH or ESP processing to the packet, as specified in the appropriate SAD entry 🫧
For inbound packets that are to be decompressed by ROHC, you:
- Apply AH or ESP processing, as specified in the appropriate SAD entry 🔓
- Remove the ICV from the packet ✂️
- Decompress the packet header(s) 🌷
- Compute an ICV for the decompressed packet with the negotiated (ROHC) integrity algorithm and its key 🧮
- Compare the computed ICV to the original ICV calculated at the compressor: if these two values differ, the packet MUST be dropped; otherwise, resume IPsec processing 🚫➡️✅
4.3. ROHC Segmentation and IPsec Tunnel MTU
sometimes a ROHCoIPsec-processed packet ends up bigger than the IPsec tunnel MTU 📏😬 RFC 4301 [IPSEC] currently lays out this for outbound traffic that goes over the SA Path MTU (PMTU) 📜
Case 1: Original (cleartext) packet is IPv4 and has the Don't
Fragment (DF) bit set. The implementation should
discard the packet and send a PMTU ICMP message.
Case 2: Original (cleartext) packet is IPv4 and has the DF
bit clear. The implementation should fragment (before or
after encryption per its configuration) and then forward
the fragments. It should not send a PMTU ICMP message.
Case 3: Original (cleartext) packet is IPv6. The implementation
should discard the packet and send a PMTU ICMP message.For the ROHCoIPsec processing model, there's one small tweak to that procedure 🧁 It affects pre-encryption fragmentation for Case 2 💡 Since current ROHC compression profiles don't support compressing IP packet fragments, pre-encryption fragmentation MUST NOT occur before ROHC processing 🙅♀️
If the compressed packet exceeds the SA PMTU and the MRRU is non-zero, ROHC segmentation MAY be used to divide the packet, where each segment fits the tunnel MTU 🧩 ROHC segmentation MUST occur before AH or ESP processing 🔥 Because in-order delivery of ROHC segments isn't guaranteed, the use of ROHC segmentation is not recommended 😬
If segmentation is applied, the process MUST account for the extra overhead added by IPsec (like AH or ESP overhead, crypto synchronization data, the additional IP header, etc.) so the final IPsec-processed segments end up smaller than the tunnel MTU 📐 After segmentation, each ROHC segment gets processed by the appropriate security protocol (like AH or ESP) set up on the ROHC-enabled SA 🔐 Since ROHC segments are processed back-to-back, the associated AH/ESP sequence number MUST be incremented by one for each segment sent over the ROHC channel 🔢 That means once all the ROHC segments have gone through AH/ESP processing, the remote IPsec implementation can spot them by a range of contiguous AH/ESP sequence numbers 🎯
For channels where the MRRU is non-zero, the ROHCoIPsec decompressor MUST re-assemble the ROHC segments it receives 🧷 To do that, the decompressor MUST identify the ROHC segments (as documented in Section 5.2 of RFC 5795 [ROHC]) and try to rebuild them using the ROHC segmentation protocol (Section 5.2.5 of RFC 5795 [ROHC]) 🧩 To help with reconstruction, the AH/ESP sequence number SHOULD be used to spot segments that may have been reordered 🔎 If reconstruction fails, the packet MUST be discarded 🗑️
As stated in Section 3.2.1, if the ROHC integrity algorithm is used to verify decompression of packet headers, that ICV gets appended to the compressed packet 🎀 If ROHC segmentation happens, the segmentation algorithm runs on the compressed packet and the appended ICV 💖 Note that the ICV is not appended to each ROHC segment 🙌
Under certain circumstances, IPsec implementations won't process (or receive) unprotected ICMP messages, or they won't have a Path MTU estimated value 🫠 In those cases, the IPsec implementation SHOULD NOT try to segment the ROHC-compressed packet, since it doesn't have full insight into the path MTU in the unprotected domain 🚫🗺️
4.4. Nested IPComp and ROHCoIPsec Processing
IPComp ([IPCOMP]) is another mechanism for shrinking an IP datagram 🗜️✨ If IPComp and ROHCoIPsec are implemented in a nested way, the following steps MUST be followed for outbound and inbound packets 🪆💜
For outbound packets that are to be processed by IPComp and ROHC, you:
- Compute the ICV for the uncompressed packet, and apply the appropriate ROHC compression profile to the packet 🔐
- Apply IPComp, and send the packet to the IPsec process 📦
- Apply the security protocol to the packet 🎀
And for inbound packets that are to be both ROHC- and IPComp-decompressed, you:
- Process a packet received on a ROHC-enabled SA with IPsec 🔓
- Decompress the datagram based on the appropriate IPComp algorithm 🌸
- Send the packet to the ROHC module for header decompression and integrity verification 🧚
5. Security Considerations 🔒✨
okay bestie, this is a big security moment 😭🫶. a ROHCoIPsec implementer should consider how strong the integrity check algorithm is when verifying decompressed headers. if that check is weak, there's a higher chance an invalidly decompressed packet gets forwarded by a ROHCoIPsec device into a protected domain. absolutely not 💀🔥.
the implementation of ROHCoIPsec may make traffic flow analysis easier, where an attacker can spot new traffic flows just by watching the relative size of the encrypted packets 👀. like, a group of "long" packets followed by a long run of "short" packets might signal a new flow for some ROHCoIPsec implementations. to help hide that, ROHC padding mechanisms may be used to add padding to transmitted packets so the sizes get randomized 🎀. the catch is that this also cuts into the efficiency win you get from header compression, so it's a trade-off, not a free lunch 🥲.
6. IANA Considerations 📋
IANA has allocated the value 142 to "ROHC" within the "Protocol Numbers" registry [PROTOCOL] 🦋. this value is used to say that the next-level protocol header is a ROHC header. slay the registry, literally 💅.
7. Acknowledgments 💖
the authors want to thank Sean O'Keeffe, James Kohler, Linda Noone of the Department of Defense, and 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.: both served as committed document reviewers for this specification 🌸.
finally, the authors want to thank the following people for their numerous reviews and comments on this document 🧚:
- Magnus Westerlund
- Stephen Kent
- Lars-Erik Jonsson
- Carl Knutsson
- Pasi Eronen
- Jonah Pezeshki
- Tero Kivinen
- Joseph Touch
- Rohan Jasani
- Elwyn Davies
- Bert Wijnen
Appendix A. ASN.1 Representation for ROHCoIPsec 🧩
okay so this appendix is an extra way to describe the ROHCoIPsec parameters that go into the IPsec SPD 📖. it uses bits of the ASN.1 syntax from Appendix C of RFC 4301 [IPSEC], plus a few brand-new structures ✨.
this syntax has been successfully compiled 🙌. however, it's merely illustrative, so you don't have to use it in an implementation to be compliant 💅.
the "Processing" data structure from Appendix C of RFC 4301 gets a ROHC parameters element added to it, like so 👑:
Processing ::= SEQUENCE {
extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
fragCheck BOOLEAN, -- TRUE stateful fragment checking,
-- FALSE no stateful fragment checking
lifetime SALifetime,
spi ManualSPI,
algorithms ProcessingAlgs,
tunnel TunnelOptions OPTIONAL,
rohc [7] RohcParams OPTIONAL
}these data structures describe the ROHC parameters 🎀:
RohcParams ::= SEQUENCE {
rohcEnabled BOOLEAN, -- TRUE, hdr compr. is enabled
-- FALSE, hdr compr. is disabled
maxCID INTEGER (0..16383),
mrru INTEGER,
profiles RohcProfiles,
rohcIntegAlg RohcIntegAlgs,
rohcIntegICVLength INTEGER
}
RohcProfiles ::= SET OF RohcProfile
RohcProfile ::= INTEGER {
rohcv1-rtp (1),
rohcv1-udp (2),
rohcv1-esp (3),
rohcv1-ip (4),
rohcv1-tcp (6),
rohcv1-rtp-udpLite (7),
rohcv1-udpLite (8),
rohcv2-rtp (257),
rohcv2-udp (258),
rohcv2-esp (259),
rohcv2-ip (260),
rohcv2-rtp-udpLite (263),
rohcv2-udpLite (264)
-- values taken from [ROHCPROF]
}
RohcIntegAlgs ::= SEQUENCE {
algorithm RohcIntegAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
RohcIntegAlgType ::= INTEGER {
none (0),
auth-HMAC-MD5-96 (1),
auth-HMAC-SHA1-96 (2),
auth-DES-MAC (3),
auth-KPDK-MD5 (4),
auth-AES-XCBC-96 (5),
auth-HMAC-MD5-128 (6),
auth-HMAC-SHA1-160 (7),
auth-AES-CMAC-96 (8),
auth-AES-128-GMAC (9),
auth-AES-192-GMAC (10),
auth-AES-256-GMAC (11),
auth-HMAC-SHA2-256-128 (12),
auth-HMAC-SHA2-384-192 (13),
auth-HMAC-SHA2-512-256 (14)
-- tbd (15..65535)
-- values taken from "Transform Type 3 - Integrity
-- Algorithm Transform IDs" at [IKEV2-PARA]
}8. References 📚
8.1. Normative References
[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.
[IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas,
"IP Payload Compression Protocol (IPComp)", RFC 3173,
September 2001.
[BRA97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[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.
[AH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.8.2. Informative References
[ROHCOIPSEC] Ertekin, E., Jasani, R., Christou, C., and C. Bormann,
"Integration of Header Compression over IPsec Security
Associations", RFC 5856, May 2010.
[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.
[ROHC-TERM] Jonsson, L-E., "Robust Header Compression (ROHC):
Terminology and Channel Mapping Examples", RFC 3759,
April 2004.
[PROTOCOL] IANA, "Assigned Internet Protocol Numbers",
<http://www.iana.org>.
[IKEV2-PARA] IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters", <http://www.iana.org>.Authors' Addresses 💌
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
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28334
Germany
EMail: cabo@tzi.org📦 where this page comes from
- ietf: rfc5858 2010-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms