Network Working Group                                         E. Ertekin
Internet-Draft                                               C. Christou                                                 R. Jasani
Intended status: Informational                                 R. Jasani                               C. Christou
Expires: July 3, 2008 February 15, 2009                                   J. Pezeshki
                                                     Booz Allen Hamilton
                                                       December 31, 2007
                                                              C. Bormann
                                                 Universitaet Bremen TZI
                                                         August 14, 2008

  Integration of Robust Header Compression (RoHC) over IPsec Security
                              Associations
                      draft-ietf-rohc-hcoipsec-07
                      draft-ietf-rohc-hcoipsec-08

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 July 3, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007). February 15, 2009.

Abstract

   IP Security (IPsec) provides various security services for IP
   traffic.  However, the benefits of IPsec come at the cost of
   increased overhead.  This document outlines a framework for
   integrating Robust Header Compression (RoHC) over IPsec (RoHCoIPsec).
   By compressing the inner headers of IP packets, RoHCoIPsec proposes
   to reduce the amount of overhead associated with the transmission of
   traffic over IPsec Security Associations (SAs).

Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
   2.      Audience . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.      Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   4.      Problem Statement: IPsec Packet Overhead . . . . . . . . .  4
   5.      Overview of the RoHCoIPsec Framework . . . . . . . . . . .  5
   5.1.    RoHCoIPsec Assumptions . . . . . . . . . . . . . . . . . .  5
   5.2.    Summary of the RoHCoIPsec Framework  . . . . . . . . . . .  5
   6.      Details of the RoHCoIPsec Framework  . . . . . . . . . . .  6
   6.1.    RoHC and IPsec Integration . . . . . . . . . . . . . . . .  6
   6.1.1.  Header Compression Protocol Considerations . . . . . . . .  8
   6.1.2.  Initialization and Negotiation of the RoHC Channel . . . .  9
   6.1.3.  Encapsulation and Identification of Header Compressed
           Packets  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.2.    RoHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10
   7.      Security Considerations  . . . . . . . . . . . . . . . . . 10
   8.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 10
   9.      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 10
   10.     Informative References . . . . . . . . . . . . . . . . . . 11
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12
           Intellectual Property and Copyright Statements . . . . . . 14

1.  Introduction

   This document outlines a framework for integrating RoHC [ROHC] over
   IPsec [IPSEC] (RoHCoIPsec).  The goal of RoHCoIPsec is to reduce the
   protocol overhead associated with packets traversing between IPsec SA
   endpoints.  This can be achieved by compressing the transport layer
   header (e.g., UDP, TCP, etc.) and inner IP header of packets at the
   ingress of the IPsec tunnel, and decompressing these headers at the
   egress.

   For RoHCoIPsec, this document assumes that RoHC will be used to
   compress the inner headers of IP packets traversing an IPsec tunnel.
   However, since current specifications for RoHC detail its operation
   on a hop-by-hop basis, it may require extensions to enable its
   operation over IPsec SAs.  This document outlines a framework for
   extending the usage of RoHC to operate at IPsec SA endpoints.

   RoHCoIPsec targets the application of RoHC to tunnel mode SAs.
   Transport mode SAs only encrypt/authenticate the payload of an IP
   packet, leaving the IP header untouched.  Intermediate routers
   subsequently use this IP header to route the packet to a decryption
   device.  Therefore, if RoHC is to operate over IPsec transport-mode
   SAs, (de)compression functionality can only be applied to the
   transport layer headers, and not to the IP header.  Because current
   RoHC specifications do not include support for the compression of
   transport layer headers alone, the RoHCoIPsec framework outlined by
   this document describes the application of RoHC to tunnel mode SAs.

2.  Audience

   The authors target members of both the RoHC and IPsec communities who
   may consider extending the RoHC and IPsec protocols to meet the
   requirements put forth in this document.  In addition, this document
   is directed towards vendors developing IPsec devices that will be
   deployed in bandwidth-constrained IP networks.

3.  Terminology

   Terminology specific to RoHCoIPsec is introduced in this section.

   RoHC Process

      Generic reference to a RoHC instance (as defined in RFC 3759), [ROHC-TERM]),
      or any supporting RoHC components.

   Compressed Traffic
      Traffic that is processed by the ROHC RoHC compressor instance.  Packet
      headers are compressed using a specific header compression
      protocol.

   Uncompressed Traffic

      Traffic that is not processed by the ROHC RoHC compressor instance.
      Instead, this type of traffic bypasses the RoHC process.

   IPsec Process

      Generic reference to the Internet Protocol Security (IPsec)
      process.

   Next Header

      Refers to the Protocol (IPv4) or Next Header (IPv6, Extension)
      field.

4.  Problem Statement: IPsec Packet Overhead

   IPsec mechanisms provide various security services for IP networks.
   However, the benefits of IPsec come at the cost of increased per-
   packet overhead.  For example, traffic flow confidentiality
   (generally leveraged at security gateways) requires the tunneling of
   IP packets between IPsec implementations.  Although these IPsec
   tunnels will effectively mask the source-destination patterns that an
   intruder can ascertain, tunneling comes at the cost of increased per-
   packet overhead.  Specifically, an ESP tunnel mode SA applied to an
   IPv6 flow results in at least 50 bytes of additional overhead per
   packet.  This additional overhead may be undesirable for many
   bandwidth-constrained wireless and/or satellite communications
   networks, as these types of infrastructure are not overprovisioned.
   RoHC applied on a per-hop basis over bandwidth-constrained links will
   also suffer from reduced performance when encryption is used on the
   tunneled header, since encrypted headers can not be compressed.
   Consequently, the additional overhead incurred by an IPsec tunnel may
   result in the inefficient utilization of bandwidth.

   Packet overhead is particularly significant for traffic profiles
   characterized by small packet payloads (e.g. various voice codecs).
   In addition, if
   If these small packets are afforded the security services of an IPsec
   tunnel mode SA, the amount of per-packet overhead is increased.
   Thus, a mechanism is needed to reduce the overhead associated with
   such flows.

5.  Overview of the RoHCoIPsec Framework

5.1.  RoHCoIPsec Assumptions

   The goal of RoHCoIPsec is to provide efficient transport of IP
   packets between IPsec devices, without compromising the security
   services offered by IPsec.  As such, the  The RoHCoIPsec framework has been
   developed based on the following assumptions:
   o  RoHC will be leveraged to reduce the amount of overhead associated
      with packets traversing an IPsec SA
   o  RoHC will be instantiated at the IPsec SA endpoints, and will be
      applied on a per-SA basis
   o  Once the decompression operation completes, decompressed packet
      headers will be identical to the original packet headers before
      compression

5.2.  Summary of the RoHCoIPsec Framework

   RoHC reduces packet overhead in a network by exploiting intra- and
   inter-packet redundancies of network and transport-layer header
   fields of a flow.

   Current RoHC protocol specifications compress packet headers on a
   hop-by-hop basis.  However, IPsec SAs are instantiated between two
   IPsec implementations, with multiple hops between the IPsec
   implementations. endpoints.  Therefore, various extensions to both RoHC and
   IPsec may need to be defined to ensure its the successful operation of the
   RoHC protocol at IPsec SA endpoints.

   The migration of RoHC over IPsec SAs is straightforward, since SA
   endpoints provide source/destination pairs where (de)compression
   operations can take place.  Compression of the inner IP and upper
   layer protocol headers in such a manner offers a reduction of per-packet per-
   packet protocol overhead between the two SA
   endpoints, and does not require compression and decompression cycles
   at the intermediate hops between IPsec implementations. endpoints.  Since RoHC
   will now essentially operate over between IPsec endpoints (over multiple hops, intermediate
   nodes which are transparent to an IPsec SA), it is imperative to
   ensure that its performance will not be severely impacted due to
   increased packet reordering and/or packet loss between the compressor
   and decompressor.

   In addition, RoHC can no longer rely on the underlying link layer for
   RoHC parameter configuration and packet identification.  The
   RoHCoIPsec framework proposes that RoHC channel parameter
   configuration is accomplished by an SA management protocol (e.g.,
   IKEv2 [IKEV2]), while identification of compressed header packets is
   achieved through the Next Header field of the security protocol
   (e.g., AH [AH], ESP [ESP]) header.

   Using the RoHCoIPsec framework proposed below, outbound and inbound
   IP traffic processing at an IPsec device is augmented needs to be modified.  For
   an outbound packet, a RoHCoIPsec implementation will compress
   appropriate packet headers, and subsequently encrypt and/or
   integrity-protect the packet.  For tunnel mode SAs, compression may
   be applied to the transport layer protocol and the inner IP header.

   Inbound IP traffic processing at an IPsec device is modified in a
   similar fashion.
   For inbound packets, an IPsec device must first decrypt and/or
   integrity-check the packet.  Then, the IPsec device
   determines if the packet was received on an RoHC-enabled SA (see
   Section 6.1) and if the packet maintains compressed headers.  If both
   of these conditions are met,  Then decompression of the inner packet
   headers is performed.  After decompression, the packet is checked
   against the access controls imposed on all inbound traffic associated
   with the SA (as specified in [IPSEC]).

      Note: Compression of inner headers is independent from compression
      of the security protocol (e.g., ESP) and outer IP headers.  RoHC
      is capable of compressing the security protocol and the outer IP
      header on a hop-by-hop basis.  The applicability of RoHCoIPsec and
      hop-by-hop RoHC on an IPv4 ESP-processed packet [ESP] is shown
      below in Figure 1.

             -----------------------------------------------------------
       IPv4  | new IP hdr  |     | orig IP hdr   |   |    | ESP   | ESP|
             |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
             -----------------------------------------------------------
             |<-------(1)------->|<------(2)-------->|

             (1) Compressed by RoHC ESP/IP profile
             (2) Compressed by RoHCoIPsec TCP/IP profile

      Figure 1.  Applicability of RoHC and RoHCoIPsec on an IPv4 ESP-
      processed packet.

   If IPsec NULL encryption is applied to packets, RoHC may still be
   applied to the inner headers at the IPsec SA endpoints.  Inbound and
   outbound packets are still processed as was previously described.

6.  Details of the RoHCoIPsec Framework

6.1.  RoHC and IPsec Integration

   Figure 1 2 illustrates the components required to integrate RoHC with
   the IPsec process, i.e., RoHCoIPsec.

                  +-------------------------------+
                  | RoHC Module                   |
                  |                               |
                  |                               |
        +-----+   |     +-----+     +---------+   |
        |     |   |     |     |     |  RoHC   |   |
      --|  A  |---------|  B  |-----| Process |------> Path 1
        |     |   |     |     |     |         |   |   (RoHC-enabled SA)
        +-----+   |     +-----+     +---------+   |
           |      |        |                      |
           |      |        |-------------------------> Path 2
           |      |                               |   (RoHC-enabled SA)
           |      +-------------------------------+
           |
           |
           |
           |
           +-----------------------------------------> Path 3
                                                      (ROHC-disabled SA)

                Figure 1: 2.  Integration of RoHC with IPsec.

   The process illustrated in Figure 1 2 augments the IPsec processing
   model for outbound IP traffic (protected-to-unprotected).  Initial
   IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1).

   Block A: The RoHC data item (part of the SA state information)
   retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1,
   Step3a) determines if the traffic traversing the SA is handed to the
   RoHC module (Figure 1,
   decision block A). module.  Packets selected to a RoHC-disabled SA must follow
   normal IPsec processing and must not be sent to the RoHC module
   (Figure 1, Path 3).  Conversely, packets selected to a RoHC-
   enabled RoHC-enabled
   SA must be sent to the RoHC module.  The decision at block B
   then

   Block B: This step determines if the packet can be compressed.  If it
   is determined that the packet will be compressed, an Integrity
   Algorithm is used to compute an Integrity Check Value (ICV) for the
   uncompressed packet ([IPSEC-ROHC], Section 3.2 [IKE-ROHC], Section
   2.1).  After this, the  The Next Header field of the security protocol header (e.g.,
   ESP, AH) is populated with a "RoHC" identifier, the packet headers
   are compressed, and the computed ICV is prepended appended to the packet, in front
   of the compressed header packet
   (Figure 1, Path 1).  However, if it is determined that the packet
   will not be compressed (e.g., due to one the reasons described in
   Section 6.1.3), the Next Header field is populated with the
   appropriate value indicating the next level protocol (Figure 1, Path
   2).

   After the RoHC process completes, IPsec processing resumes, as
   described in Section 5.1, Step3a, of [IPSEC]
   (specifically, "IPsec processing is as previously defined..."). [IPSEC].

   The process illustrated in Figure 1 2 also augments the IPsec
   processing model for inbound IP traffic (unprotected-to-protected).
   For inbound packets, IPsec processing is performed ([IPSEC], Section
   5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section
   5.2, Step 4) . 4).

   Block A: After AH or ESP processing, the RoHC data item retrieved
   from the SAD entry will indicate if traffic traversing the SA is handed to
   processed by the RoHC module ([IPSEC], Section 5.2, Step 3a).
   Packets traversing an RoHC-disabled SA must follow normal IPsec
   processing and must not be sent to the RoHC module.  Conversely,
   packets traversing an RoHC-enabled SA must be sent to the RoHC
   module.

   Block B: The decision at block Block B is determined by the value of the
   Next Header field of the security protocol header.  If the Next
   Header field does not indicate a RoHC header
   is indicated, header, the decompressor must
   not attempt decompression is applied, and (Figure 1, Path 2).  If the decompressed packet Next Header
   field indicates a RoHC header, decompression is used with applied.  After
   decompression, the RoHCoIPsec Integrity Algorithm to is used to compute a
   an ICV value
   that for the decompressed packet.  This ICV is compared to
   the ICV that was calculated at the compressor.
   If this computed value equals compressor: if the ICV, ICVs match, the
   packet leaves is forwarded by the RoHC module (Figure 1, Path 1); otherwise,
   the packet is dropped.  If the
   Next Header field does not indicate a RoHC header, the decompressor
   must not attempt decompression (Figure 1, Path 2).  Once the RoHC module completes processing,
   IPsec processing resumes, as described in Section 5.2, Step 4 of [IPSEC] (specifically "Then match the
   packet against the inbound selectors identified by the SAD ...").
   [IPSEC].

   Note that to further reduce the size of an IPsec-protected packet,
   RoHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested
   fashion.  This process is detailed in [IPSEC-ROHC], Section 3.2.

6.1.1.  Header Compression Protocol Considerations

   The initial specification of RoHC [ROHC] may need to be extended to
   operate efficiently over IPsec SAs.  Specifically, compressor and
   decompressor implementations must account for increased tolerance to
   packet reordering and packet loss, and should minimize the amount of
   feedback sent from the decompressor to the compressor.  To address
   this need, [ROHC-RODR] provides guidelines on how to implement
   existing profiles over reordering channels, and

   RoHCv2 [ROHCV2] profiles include various mechanisms that provide
   increased robustness over reordering channels.  Furthermore, a  These mechanisms must
   be adopted for RoHC to operate efficiently over IPsec SAs.

   A RoHC decompressor implemented within IPsec architecture may
   leverage additional mechanisms to improve performance over reordering
   channels (either due to random events, or to an attacker
   intentionally reordering packets).  Specifically, IPsec's sequence
   number may be used by the decompressor to identify a packet as
   "sequentially late".  This knowledge will increase the likelihood of
   successful decompression of a reordered packet.

   Additionally, RoHCoIPsec implementations should minimize the amount
   of feedback sent from the decompressor to the compressor.  If a ROHC
   feedback channel is not used sparingly, the overall gains from
   RoHCoIPsec can be significantly reduced.  More specifically, any
   feedback sent from the decompressor to the compressor must be
   processed by IPsec, and tunneled back to the compressor (as
   designated by the SA associated with FEEDBACK_FOR).  As such, several
   implementation considerations are offered:
   o  Eliminate feedback traffic altogether by operating only in RoHC
      Unidirectional mode (U-mode)
   o  Piggyback RoHC feedback messages on traffic that normally
      traverses the SA designated by FEEDBACK_FOR.

6.1.2.  Initialization and Negotiation of the RoHC Channel

   RoHC uses can use the underlying link layer (e.g., PPP) to negotiate automatically
   RoHC channel parameters.  In the case of RoHCoIPsec, channel
   parameters
   are negotiated by another mechanism.  Specifically, initialization of
   the RoHC channel is either can be achieved manually (i.e., administratively
   configured for manual SAs), or is performed by IPsec SA establishment
   protocols. IKEv2.  The extensions required for
   IKEv2 to support RoHC parameter negotiation are detailed in [IKE-ROHC]. [IKE-
   ROHC].

   If the RoHC protocol requires bi-directional communications, two SAs
   must be instantiated between the IPsec implementations.  One of the
   two SAs is used for carrying RoHC-traffic from the compressor to the
   decompressor, while the other is used to communicate RoHC-feedback
   from the decompressor to the compressor.  Note that the requirement
   for two SAs aligns with the operation of IKE, which creates SAs in
   pairs.
   pairs by default.  However, IPsec implementations will dictate how
   decompressor feedback received on one SA is associated with a
   compressor on the other SA.

6.1.3.  Encapsulation and Identification of Header Compressed Packets

   As indicated in Section 6.1, new state information (i.e., a new RoHC
   data item) is defined for each SA.  The RoHC data item is used by the
   IPsec process to determine whether it sends all traffic traversing a
   given SA to the RoHC module (RoHC-enabled) or bypasses the RoHC
   module and sends the traffic through regular IPsec processing (RoHC-
   disabled).

   The Next Header field of the IPsec security protocol (e.g., AH or
   ESP) header is used to demultiplex header-compressed traffic from
   uncompressed traffic traversing an RoHC-enabled SA.  This
   functionality is needed in situations where packets traversing a
   RoHC-enabled SA do not contain compressed headers.  Such situations
   may occur when, for example, a compressor supports strictly n
   compressed flows and can not compress the n+1 flow that arrives.
   Another example is when traffic (e.g., TCP/IP) is selected (by IPsec)
   to a RoHC-enabled SA, but cannot be compressed by the RoHC process
   (e.g., because the compressor does not support TCP/IP compression).
   In these situations, the compressor must indicate that the packet
   contains uncompressed headers.
   Similarly, the decompressor must be able to identify packets with
   uncompressed headers and not attempt to decompress them.  The Next
   Header field is used to demultiplex these header-compressed versus
   uncompressed packets, as a RoHC protocol identifier will indicate the
   packet contains compressed headers.  To accomplish this, an official
   IANA allocation from the ProtocolID Protocol ID registry [PROTOCOL] is required.

   The RoHC Data Item, IANA ProtocolID Protocol ID allocation, and other IPsec
   extensions to support RoHCoIPsec, are specified in [IPSEC-ROHC].

6.2.  RoHCoIPsec Framework Summary

   To summarize, the following items are needed to achieve RoHCoIPsec:
   o  IKEv2 Extensions to Support RoHCoIPsec
   o  IPsec Extensions to Support RoHCoIPsec

7.  Security Considerations

   A malfunctioning RoHC compressor (i.e., the compressor located at the
   ingress of the IPsec tunnel) has the ability to send packets to the
   decompressor (i.e., the decompressor located at the egress of the
   IPsec tunnel) that do not match the original packets emitted from the
   end-hosts.  Such a scenario will result in a decreased efficiency
   between compressor and decompressor.  Furthermore, this may result in
   Denial of Service, as the decompression of a significant number of
   invalid packets may drain the resources of an IPsec device.

   In addition, some RoHCoIPsec implementations may allow an attacker to
   identify new traffic flows by monitoring the relative size of the
   encrypted packets (i.e. a group of "long" packets, followed by a long
   series of "short" packets may indicate a new flow for some RoHCoIPsec
   implementations).  To mitigate this concern, RoHC padding mechanisms
   may be used to arbitrarily add padding to transmitted packets to
   randomize packet sizes.

8.  IANA Considerations

   None.

9.  Acknowledgments

   The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler,
   and Ms. Linda Noone of the Department of Defense, and well as Mr.
   Rich Espy of OPnet for their contributions and support in the
   development of this document.

   In addition, the authors would like to thank the following for their
   numerous reviews and comments to this document:

   o  Dr. Stephen Kent
   o  Dr. Carsten Bormann
   o  Mr. Pasi Eronen
   o  Dr. Joseph Touch
   o  Mr. Tero Kivinen
   o  Mr. Lars-Erik Jonsson
   o  Mr. Jan Vilhuber
   o  Mr. Dan Wing
   o  Mr. Kristopher Sandlund
   o  Mr. Ghyslain Pelletier
   o  Mr. Pasi Eronen

   Finally, the authors would also like to thank Mr. Tom Conkle, Ms.
   Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen
   Hamilton for their assistance in completing this work.

10.  Informative References

   [ROHC]     Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
              Hannu, H., Jonsson, L., 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.

   [IPSEC]    Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [ROHC-TERM]
              Jonsson, L-E., "Robust Header Compression (ROHC):
              Terminology and Channel Mapping Examples", RFC 4301,
              April 2004.

   [IKEV2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [ESP]      Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [AH]       Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [IPCOMP]   Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload
              Compression Protocol (IPComp)", RFC 3173, September 2001.

   [ROHC2]

   [ROHCV2]   Pelletier, G. and K. Sandlund, "RObust Header Compression
              Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP
              Lite", work in progress , December 2007. RFC 5225, April 2008.

   [IKE-ROHC]
              Pezeshki, et al., "IKEv2 Extensions to Support
              RoHCoIPsec", work in progress , February 2007.

   [ROHC-RODR]
              Pelletier, et al., "RObust Header Compression (ROHC): ROHC
              over Channels That Can Reorder Packets", RFC 4224,
              January 2006. August 2008.

   [PROTOCOL]
              IANA, ""Assigned "Assigned Internet Protocol Numbers", Numbers, IANA registry
              at: http://www.iana.org/assignments/protocol-numbers".

   [IPSEC-ROHC]
              Ertekin, et al., "IPsec Extensions to Support RoHCoIPsec",
              work in progress , February 2007. August 2008.

Authors' Addresses

   Emre Ertekin
   Booz Allen Hamilton
   13200 Woodland Park Dr.
   Herndon, VA  20171
   US

   Email: ertekin_emre@bah.com

   Chris Christou

   Rohan Jasani
   Booz Allen Hamilton
   13200 Woodland Park Dr.
   Herndon, VA  20171
   US

   Email: christou_chris@bah.com

   Rohan Jasani jasani_rohan@bah.com

   Chris Christou
   Booz Allen Hamilton
   13200 Woodland Park Dr.
   Herndon, VA  20171
   US

   Email: jasani_rohan@bah.com christou_chris@bah.com
   Jonah Pezeshki
   Booz Allen Hamilton
   13200 Woodland Park Dr.
   Herndon, VA  20171
   US

   Email: pezeshki_jonah@bah.com

   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28334
   Germany

   Email: cabo@tzi.org

Full Copyright Statement

   Copyright (C) The IETF Trust (2007). (2008).

   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).