Network Working Group Kristofer Sandlund, Effnet AB INTERNET-DRAFT Expires: March 2005 September 17, 2004 ROHC LLA Implementer's Guide Status of this memo By submitting this Internet-Draft, I (we) certify that any applicable patent or other IPR claims of which I am (we are) aware have been disclosed, and any of which I (we) become aware will be disclosed, in accordance with RFC 3668 (BCP 79). By submitting this Internet-Draft, I (we) accept the provisions of Section 3 of RFC 3667 (BCP 78). 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is a submission of the IETF ROHC WG. Comments should be directed to the ROHC WG mailing list, rohc@ietf.org. Abstract This document describes common misinterpretations and some ambiguous points of ROHC LLA [3], which defines the Link-Layer Assisted profile for IP/UDP/RTP. These points have been identified by the members of the ROHC working group during implementation of the profile. Sandlund [Page 1] INTERNET-DRAFT ROHC LLA Implementer's Guide September 17, 2004 Table of Contents 1. Introduction.....................................................2 2. Terminology......................................................2 3. CSP Packet Format................................................2 4. CRC Verification of CCP packets..................................3 5. Security Consideration...........................................3 6. Acknowledgments..................................................3 7. Authors' Addresses...............................................4 8. References.......................................................4 8.1. Normative references........................................4 Intellectual Property Statement..................................5 1. Introduction ROHC LLA [3] defines a profile for compressing IP/UDP/RTP by using functionality provided by the lower layers to achieve a zero byte compressed header during normal operation. During implementation of this profile, some errors and unclear areas have been identified. This document tries to correct and clarify those points. 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 [1]. 3. CSP Packet Format The format of the CSP packet has been identified as non-interoperable when carrying a RHP header with a 3-bit or 7-bit CRC. This problem occurs due to the payload having been dropped by the compressor, while the decompressor is supposed to use the payload length to infer certain fields in the uncompressed header. These fields are the IPv4 total length, the IPv6 payload length, the UDP length and the IPv4 header checksum field (all INFERRED fields in [2]). To correct this problem, the CSP packet needs to contain information about the payload length carried in the RHP packet. Therefore the length of the RTP payload is carried in the CSP packet. The redefined format for the CSP packet is therefore as follows: Sandlund [Page 2] INTERNET-DRAFT ROHC LLA Implementer's Guide September 17, 2004 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0 1 0 | Packet type identifier +===+===+===+===+===+===+===+===+ / RTP Payload Length / 2 octets +---+---+---+---+---+---+---+---+ : ROHC header without padding : : see [ROHC, section 5.7] : +---+---+---+---+---+---+---+---+ Updating properties: CSP maintains the updating properties of the ROHC header it carries. RTP Payload Length: This field is the length of the payload carried inside the RTP header, stored in network byte order. I.e. this field will be set by the compressor to (UDP length - size of the RTP header including CSRC identifiers). When the decompressor receives a CSP packet, it MUST use the RTP payload length field to calculate the value of fields classified as INFERRED in [2] when attempting to verify a 3- or 7-bit CRC carried in the RHP header enclosed in the CSP. When the encapsulated RHP packet only carries an 8-bit CRC, the RTP payload length MAY be used by the decompressor for verification of the decompressed header. The packet format defined in this section obsoletes the header format for the CSP defined in [3] Section 4.1.2. 4. CRC Verification of CCP packets When a CCP packet with the C-bit set is received by the decompressor, the decompressor uses the 7-bit CRC in the packet to verify the context. For this verification to succeed, the decompressor needs to have access to the entire uncompressed header of the latest packet decompressed. Some implementations of [2] might not save the values of INFERRED fields. An implementation of ROHC LLA MUST save these fields in the decompressor context to be able to successfully verify CCP packets. 5. Security Consideration This document provides some changes and clarifications to [3], but it is not belived that these changes add any extra security considerations than those listed in [3]. 6. Acknowledgments Sandlund [Page 3] INTERNET-DRAFT ROHC LLA Implementer's Guide September 17, 2004 The author would like to thank Joakim Enerstam, Ghyslain Pelletier and Lars-Erik Jonsson for their contributions and comments. 7. Authors' Addresses Kristofer Sandlund Tel: +46 920 60917 Effnet AB EMail: kristofer.sandlund@effnet.com Stationsgatan 69 97234 Lulea Sweden 8. References 8.1. Normative references [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] C. Bormann, et. al, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [3] L. Jonsson, G. Pelletier, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 2002. Sandlund [Page 4] INTERNET-DRAFT ROHC LLA Implementer's Guide September 17, 2004 Intellectual Property Statement 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 IETF's procedures with respect to rights in IETF Documents can be found in RFC 3667 (BCP 78) and RFC 3668 (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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Disclaimer of Validity 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 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. This Internet-Draft expires March 17, 2005. Sandlund [Page 5]