Robust Header Compression C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Standards Track July 31, 2007 Expires: February 1, 2008 A ROHC Profile for CID shutdown (ROHC-DOWN) draft-bormann-rohc-shutdown-profile-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 1, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies a ROHC (Robust Header Compression) profile for shutting down context IDs (CIDs). The profile, called ROHC-DOWN, enables the decompressor to free resources and the compressor to be sure no residual state from a previous use survives on a CID. $Id: draft-bormann-rohc-shutdown-profile.xml,v 1.5 2007/07/31 15:40:11 cabo Exp $ Bormann Expires February 1, 2008 [Page 1] Internet-Draft ROHC-DOWN July 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Profile Operation . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Creating Contexts . . . . . . . . . . . . . . . . . . . . . 3 2.2. Using Contexts . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Security considerations . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Bormann Expires February 1, 2008 [Page 2] Internet-Draft ROHC-DOWN July 2007 1. Introduction Both the original ROHC standard [RFC3095] and the current work on the now separately defined framework [I-D.ietf-rohc-rfc3095bis-framework], have an issue with ambiguities in the re-use of context IDs (CIDs) induced by packet losses and reordering. While the current mechanisms as defined in the cited specifications suffice for the detection of accidental confusion about the current use of a CID, they might be circumvented in a malicious "decompressor confusion attack" to subvert the integrity protection of channels carrying header-compressed flows. The ROHC shutdown profile (ROHC-DOWN) provides a reliable way for a compressor to prepare a CID for reuse, without the danger of that CID reuse to be misused for a decompressor confusion attack. As a secondary consideration, ROHC-DOWN provides a compressor the generally useful ability to indicate to the decompressor when the use of a CID has ended in order to allow it to free associated resources. 2. Profile Operation This section gives an overview of the operation of ROHC-DOWN. The ROHC-DOWN profile operates by not allowing any packet to be decompressed from a context in this profile; it is thus indistinguishable from an uninitialized context. To allow the compressor to ascertain that a CID is indeed shut down, the IR packet may include a (possibly empty) nonce to be echoed in a feedback item. 2.1. Creating Contexts A ROHC-DOWN context is created using an IR (initialization/refresh) packet, which contains a ROHC framework header followed by the ROHC- DOWN nonce: If the x bit is set to 1, the compressor expects the decompressor to echo back the (0-or-more byte) nonce in a feedback item. If the x bit is set to 0, no such feedback is expected (the nonce can still be supplied, but has no effect). Bormann Expires February 1, 2008 [Page 3] Internet-Draft ROHC-DOWN July 2007 0 1 2 3 4 5 6 7 --- --- --- --- --- --- --- --- : Add-CID octet : if CID 1-15 and small CID +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 | x | IR type octet +---+---+---+---+---+---+---+---+ : : / 0-2 octets of CID / 1 or 2 octets if large CIDs : : +---+---+---+---+---+---+---+---+ | Profile | 1 octet +---+---+---+---+---+---+---+---+ | CRC | 1 octet +---+---+---+---+---+---+---+---+ : : / NONCE / 0-or-more bytes of Nonce : : +---+---+---+---+---+---+---+---+ 2.2. Using Contexts No ROHC-DOWN packet types other than IR are defined. The decompressor MUST treat non-IR packet types in a context initialized for the ROHC-DOWN profile as it would treat them in an uninitialized context. 2.3. Feedback If a reply is requested in an IR packet by setting x to 1, the decompressor SHOULD send back the nonce byte-string in a ROHC feedback message. If the nonce is empty (zero bytes), the feedback is sent as a ROHC FEEDBACK-1 message consisting of a single zero byte. If the nonce is at least one byte, the feedback is sent as a ROHC FEEDBACK-2 message, preceded by one zero byte. The zero byte is composed of the ROHC framework Acktype of 0 (ACK, see ROHC framework) and six bits that MUST be zero. In effect, the nonce is prefixed by a zero byte in both cases. In both cases, the feedback is not to be received as a valid acknowledgement if this byte is not actually zero. Bormann Expires February 1, 2008 [Page 4] Internet-Draft ROHC-DOWN July 2007 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 0 | Code | feedback type +---+---+---+---+---+---+---+---+ : Size : if Code = 0 +---+---+---+---+---+---+---+---+ : Add-CID octet : for small CIDs and (CID != 0) +---+---+---+---+---+---+---+---+ : : / large CID (5.3.2 encoding) / 1-2 octets if for large CIDs : : +---+---+---+---+---+---+---+---+ / FEEDBACK data / variable length +---+---+---+---+---+---+---+---+ FEEDBACK-1: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 1 octet +---+---+---+---+---+---+---+---+ FEEDBACK-2: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ |Acktype| 0 | +---+---+---+---+---+---+---+---+ at least 2 octets : : / NONCE / 0-or-more bytes of Nonce : : +---+---+---+---+---+---+---+---+ Acktype: 0 = ACK Bormann Expires February 1, 2008 [Page 5] Internet-Draft ROHC-DOWN July 2007 3. Security considerations The security considerations of [RFC3095] apply. The objective of this draft is mainly to mitigate a potential attack based on confusing the decompressor sufficiently that it accidentally forwards information to receivers of packets previously sent on a context. By waiting for positive acknowledgement of channel shutdown before re-using a channel, this attack can be effectively prevented. Note that in an HCoIPsec environment, there is never a pressing need to re-use a context; a compressor that is somehow running out of CIDs can always negotiate a new SA and thus a new ROHC channel. For some applications, a new SA will be set up for each new flow in any case. Being able to re-use contexts may, however, simplify running more long-term SAs as ROHC channels. Apart from the uses described above, the ROHC-DOWN profile can also be used as a way to probe the channel at various packet sizes and to send traffic obfuscating the packet size signature. For the first use, sending a ROHC-DOWN IR packet on an unused CID with x==1 acts as a kind of ping mechanism. A compressor can use this mechanism to regularly probe a channel, investigating whether it is subject to malicious packet dropping at particular (larger) packet sizes. For the second use, sending a ROHC-DOWN IR packet in an unused CID with x==0 acts as a no-operation, allowing to randomly add packets of otherwise possibly telltale sizes to the channel. 4. IANA Considerations The ROHC profile identifier 0x0099 [# Editor's Note: To be replaced before publication #] has been reserved by the IANA for the profile defined in this document. [# Editor's Note: rest of this section to be removed before publication: #] Two ROHC profile identifiers must be reserved by the IANA for the new profile defined in this document. A suggested registration in the "RObust Header Compression (ROHC) Profile Identifiers" name space would then be: Profile Usage Reference 0x0099 ROHC DOWN [RFC XXXX (this)] Author's note: This suggestion must be updated before sending to IANA. Bormann Expires February 1, 2008 [Page 6] Internet-Draft ROHC-DOWN July 2007 5. Contributors The author would like to thank Pasi Eronen, who emphasized the importance of the decompressor confusion attack in his comments to HCoIPsec, and Jonah Pezeshki, who narrowed down the problem sufficiently for the author to find this solution. 6. Acknowledgements This document was prompted by the work on HCoIPsec by Emre Ertekin, Chris Christou, and others. 7. References 7.1. Normative References [I-D.ietf-rohc-rfc3095bis-framework] Jonsson, L., "The RObust Header Compression (ROHC) Framework", draft-ietf-rohc-rfc3095bis-framework-04 (work in progress), November 2006. 7.2. Informative References [RFC3095] 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. Author's Address Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28334 Germany Phone: +49 421 218 7024 Fax: +49 421 218 7000 Email: cabo@tzi.org Bormann Expires February 1, 2008 [Page 7] Internet-Draft ROHC-DOWN July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bormann Expires February 1, 2008 [Page 8]