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]