The IESG has approved the following document: - 'RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite ' <draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06.txt> as a Proposed Standard This document is the product of the Robust Header Compression Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rohc-rfc3095bis-rohcv2-profiles-06.txt Technical Summary This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol, User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (User Datagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP (Encapsulating Security Payload) headers. This specification defines a second version of the profiles found in RFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them as ROHC can negotiate them. The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Working Group Summary This document has been in the working group for roughly 18 months. The document originated from implementation experience gained with RFC 3095, from which implementers have outlined its complexity and the relevance of defining simpler profiles, as well as from the requirement and the need to introduce support against reordering between compression endpoints. These new profiles were first drafted as an individual submission, and the first draft was submitted to the WG in September 2006. Initially, there was a relatively large interest for the new profiles, but few technical reviews. Since May 2007, the active participation in the working group to this draft has accelerated and ultimately the document received several comprehensive reviews. The general design approach is similar as for ROHC-TCP (RFC 4997), and has not changed significantly since it was first introduced in the group. The WG have a consensus for the new profiles. Document Quality The document has been reviewed by several individuals, with different perspectives and approaches to the reviews. The formal notation part was verified manually but also partly validated by automated tools. During WG Last-Call, the document was reviewed by the committed WG reviewers Robert Finking, Haipeng Jin, Rohit Kapoor and Mark West. In WG reviews and otherwise, feedback has been received from persons active in the ROHC WG as well as in 3GPP and 3GPP2 standard bodies. Personnel Authors are Kristofer Sandlund and Ghyslain Pelletier. The Document Shepherd for this draft is Carl Knutsson, and Magnus Westerlund is the responsible Area Director. RFC Editor Note Section 1, second paragraph: OLD: This document defines an updated version for each of the above mentioned profiles, and its definition is based on the specification of the ROHC framework as found in [RFC4995]. NEW: This document defines an updated version for each of the above mentioned profiles, and the definitions depends on the ROHC framework as found in [RFC4995]. The framework is required reading to understand the profile definitions, rules and their role. Section 1: OLD: ROHCv2 compresses the following type of extension headers: NEW: Each of the profiles above can compress the following type of extension headers: Section 6.6.4, foruth paragraph: OLD: As described above, the header checksum protects individual hops from processing a corrupted header. There is no reason to transmit this checksum when almost all IP header information is compressed away, and when decompression is verified by a CRC computed over the original header for every compressed packet; instead, the checksum can be recomputed by the decompressor. NEW: As described above, the header checksum protects individual hops from processing a corrupted header. As the data that this checksum protects is mostly compressed away and is instead taken from state stored in the context, this checksum becomes cumulative to the ROHC CRC. When using this encoding method, the checksum is recomputed by the decompressor. Section 6.6.7, end of section: NEW: IPv6 headers using the jumbo payload option of [RFC2675] will not be compressible with this encoding method since the value of the payload length field does not match the length of the packet. Section 6.9.2: -------------- OLD: Opt Len: The lenght of the Option Data field, in octets. NEW: Opt Len: Unsigned integer that represents the length of the Option Data field, in octets. Section 7: OLD: 7. Security Considerations A malfunctioning or malicious header compressor could cause the header decompressor to reconstitute packets that do not match the original packets but still have valid IP, UDP and RTP headers and possibly also valid UDP checksums. Such corruption may be detected with integrity mechanisms which will not be affected by the compression. Moreover, this header compression scheme uses an internal checksum for verification of reconstructed headers. This reduces the probability of producing decompressed headers not matching the original ones without this being noticed, which can be useful in the case of malfunctioning compressors. Denial-of-service attacks are possible if an intruder can introduce (for example) bogus IR or FEEDBACK packets onto the link and thereby cause compression efficiency to be reduced. However, an intruder having the ability to inject arbitrary packets at the link layer in this manner raises additional security issues that dwarf those related to the use of header compression. NEW: 7. Security Considerations Impairments such as bit errors on the received compressed headers, missing packets and reordering between packets could cause the header decompressor to reconstitute erroneous packets, i.e. packets that do not match the original packet, but still have a valid IP, UDP (or UDP-Lite) and RTP headers, and possibly also valid UDP (or UDP-Lite) checksums. The header compression profiles defined herein use an internal checksum for verification of reconstructed headers. This reduces the probability that a header decompressor delivers erroneous packets to upper layers without the error being noticed. In particular, the probability that consecutive erroneous packets are not detected by the internal checksum is close to zero. This small but non-zero probability remains unchanged when integrity protection is applied after compression and verified before decompression, in the case where an attacker could discard or reorder packets between the compression endpoints. The impairments mentioned above could be caused by a malfunctioning or malicious header compressor. Such corruption may be detected with end-to-end integrity mechanisms which will not be affected by the compression. Moreover, the internal checksum can also be useful in the case of malfunctioning compressors. Denial-of-service attacks are possible if an intruder can introduce (for example) bogus IR or FEEDBACK packets onto the link and thereby cause compression efficiency to be reduced. However, an intruder having the ability to inject arbitrary packets at the link layer in this manner raises additional security issues that dwarf those related to the use of header compression. Appendix A.1: ------------- OLD: Type Of Service The Type Of Service field is expected to be constant during the lifetime of a flow or to change relatively seldom. NEW: Type Of Service For the type of flows compressed by the ROHCv2 profiles, the DSCP and ECN fields are expected to change relatively seldom. Appendix A.2: ------------- OLD: Traffic Class The Traffic Class field is expected to be constant during the lifetime of a flow or to change relatively seldom. NEW: Traffic Class For the type of flows compressed by the ROHCv2 profiles, the DSCP and ECN fields are expected to change relatively seldom. Appendix A.6: OLD: SPI This field is used to identify a specific flow and only changes when the sequence number wraps around, and is therefore classified as STATIC-DEF. NEW: SPI This field is used to identify a distinct flow between two IPsec peers and it changes rarely, therefore it is classified as STATIC-DEF. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
