Protocol Action: 'RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite' to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux