[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 5856

Network Working Group                                         E. Ertekin
Internet-Draft                                               C. Christou
Expires: December 28, 2006                                     R. Jasani
                                                     Booz Allen Hamilton
                                                           June 26, 2006


   Integration of Header Compression over IPsec Security Associations
                      draft-ietf-rohc-hcoipsec-02

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 December 28, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Internet Protocol security mechanisms, such as IP Security (IPsec)
   [IPSEC], provide various security services for IP traffic.  However,
   the benefits of IPsec come at the cost of increased overhead.  This
   document defines a framework for integrating Header Compression (HC)
   over IPsec (HCoIPsec).  By compressing the inner headers of IP
   packets, HCoIPsec proposes to reduce the amount of overhead
   associated with the transmission of traffic over IPsec security



Ertekin, et al.         Expires December 28, 2006               [Page 1]


Internet-Draft      Integration of HC over IPsec SAs           June 2006


   associations.


Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
   2.      Audience . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.      Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   4.      Problem Statement: Packet Overhead Associated with
           IPsec Tunnel-Mode SAs  . . . . . . . . . . . . . . . . . .  4
   5.      Overview of the HCoIPsec Framework . . . . . . . . . . . .  5
   5.1.    HCoIPsec Assumptions . . . . . . . . . . . . . . . . . . .  5
   5.2.    HCoIPsec Description . . . . . . . . . . . . . . . . . . .  5
   6.      Details of the HCoIPsec Framework  . . . . . . . . . . . .  6
   6.1.    HC and IPsec Integration . . . . . . . . . . . . . . . . .  6
   6.1.1.  Header Compression Scheme Considerations . . . . . . . . .  8
   6.1.2.  Initialization and Negotiation of HC Channel . . . . . . .  9
   6.1.3.  Encapsulation and Identification of Header Compressed
           Packets  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.2.    HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10
   7.      Security Considerations  . . . . . . . . . . . . . . . . . 10
   8.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 10
   9.      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 10
   10.     References . . . . . . . . . . . . . . . . . . . . . . . . 11
   10.1.   Normative References . . . . . . . . . . . . . . . . . . . 11
   10.2.   Informative References . . . . . . . . . . . . . . . . . . 12
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13
           Intellectual Property and Copyright Statements . . . . . . 14























Ertekin, et al.         Expires December 28, 2006               [Page 2]


Internet-Draft      Integration of HC over IPsec SAs           June 2006


1.  Introduction

   This document identifies a framework for integrating HC over IPsec
   Security Associations (SAs).  The goal of integrating HC with IPsec
   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.

   To realize HCoIPsec, this document proposes the use of Internet
   Protocol Header Compression [IPHC], Compressed Real Time Protocol
   [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and Robust
   Header Compression [ROHC], to compress the inner headers of IP
   packets traversing an IPsec tunnel.  Since these traditional HC
   schemes operate on a hop-by-hop basis, several extensions must be
   defined to enable their operation over IPsec SAs.  This document
   details a framework which will allow these traditional hop-by-hop HC
   schemes to be extended to operate at IPsec SA endpoints.

   HCoIPsec currently targets the application of HC to tunnel mode SAs.
   However, future work may extend the framework to operate over
   transport mode SAs as well.  Transport mode SAs only encrypt/
   authenticate the payload of an IP packet, leaving the IP header
   untouched.  Intermediate routers subsequently use the outer IP header
   to route the packet to a decryption device.  Therefore, if HC
   mechanisms are extended to operate between IPsec transport-mode SA
   endpoints, (de)compression functionality can only be applied to the
   transport layer headers, and not to the IP header.  Since compression
   of transport layer headers alone does not provide substantial
   efficiency gains, extending the HCoIPsec framework to support
   transport mode SAs is left for future work.


2.  Audience

   The target audience includes those who are involved with the
   development of HC schemes, and IPsec implementations.  Since
   traditional IETF HC schemes are designed to operate on a hop-by-hop
   basis, they need to be modified to operate over IPsec SAs.
   Therefore, the authors target various HC and IPsec communities who
   may consider extending hop-by-hop HC schemes and IPsec protocols to
   meet the requirements put forward in this document.  Finally, this
   document is directed towards vendors developing IPsec devices which
   will be deployed in bandwidth-constrained, IP networks.






Ertekin, et al.         Expires December 28, 2006               [Page 3]


Internet-Draft      Integration of HC over IPsec SAs           June 2006


3.  Terminology

   Terminology specific to discussion of HCoIPsec is introduced in this
   section.

   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.

   Compressed Traffic

      Traffic that is processed by the compressor.  Packet headers are
      compressed using a compression profile.

   Uncompressed Traffic

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

   HC Process

      Generic reference to either the compressor, decompressor, or any
      supporting header compression (HC) components.

   IPsec Process

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


4.  Problem Statement: Packet Overhead Associated with IPsec Tunnel-Mode
    SAs

   IPsec mechanisms provide various security services for IP networks.
   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, IPsec tunnels come 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.  Consequently,
   the additional overhead incurred in an encryption-based environment
   may result in the inefficient utilization of bandwidth.




Ertekin, et al.         Expires December 28, 2006               [Page 4]


Internet-Draft      Integration of HC over IPsec SAs           June 2006


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


5.  Overview of the HCoIPsec Framework

5.1.  HCoIPsec Assumptions

   The goal for HCoIPsec is to provide more efficient transport of IP
   packets between source and destination IPsec devices, without
   compromising the security services offered by IPsec.  As such, the
   HCoIPsec framework was developed based on the following assumptions:
   o  Existing HC protocols (e.g., IPHC, CRTP, ECRTP, ROHC) will be
      leveraged to reduce the amount of overhead associated with packets
      traversing an IPsec SA
   o  HC algorithms will be instantiated at the IPsec SA endpoints, and
      HC is applied on a per-SA basis

5.2.  HCoIPsec Description

   HC schemes reduce packet overhead in a network by exploiting inter-
   packet redundancies of network and transport-layer header fields of a
   flow to reduce the amount of redundant header data transmitted
   between two nodes.

   To apply traditional HC schemes over IPsec SAs, several extensions
   need to be defined.  Existing HC schemes 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.  Therefore, to fully integrate HC with IPsec SAs,
   traditional hop-by-hop schemes need to be extended to operate at
   IPsec SA endpoints.

   The migration of traditional hop-by-hop HC schemes over IPsec SAs is
   straightforward, since SA endpoints provide source/destination pairs
   where (de)compression operations can take place.  Compression in such
   a manner offers a reduction of per-packet protocol overhead between
   the two SA endpoints, and does not require compression and
   decompression cycles at the intermediate hops between IPsec
   implementations.  Since HC schemes will now essentially operate over
   multiple hops, it is imperative that the performance of the HC
   schemes is not severely impacted due to increased packet reordering
   and/or packet loss between the compressor and decompressor.



Ertekin, et al.         Expires December 28, 2006               [Page 5]


Internet-Draft      Integration of HC over IPsec SAs           June 2006


   In addition, since HC schemes will operate at IPsec SA endpoints, HC
   schemes can no longer rely on the underlying link layer for HC
   parameter configuration and packet identification.  Traditionally, HC
   schemes use the underlying link layer to establish a set of
   configuration parameters at each end of the link, and for identifying
   different types of header-compressed packets.  The HCoIPsec framework
   proposes that HC session parameter configuration and header-
   compressed packet identification is accomplished by the SA management
   protocol (e.g., IKEv2) and the security protocol next header field,
   respectively.

   Using the HCoIPsec framework proposed below, outbound IP traffic
   processing at an IPsec device is augmented to 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 HC-enabled SA(see section
   6.1), and if the packet maintains compressed headers.  If both of
   these conditions are met, 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 RFC 4301).

      Note: Compression of inner headers is independent from compression
      of the security protocol (e.g., ESP) and outer IP headers.  HC
      schemes such as ROHC and IPHC are capable of compressing these
      outer headers on a hop-by-hop basis.  Further discussion on the
      compression of outer headers is outside the scope of this
      document.

   If IPsec NULL encryption is applied to packets, HC schemes may still
   be applied to the inner headers at the IPsec SA endpoints.  Inbound
   and outbound packets are still processed as was previously described.
   For scenarios where NULL-encrypted packets traverse intermediate
   nodes between the IPsec SA endpoints, the intermediary nodes must not
   attempt to (de)compress the inner IP and/or transport layer headers.


6.  Details of the HCoIPsec Framework

6.1.  HC and IPsec Integration

   Based on these assumptions, Figure 1 illustrates the components
   required to integrate HC with the IPsec process, i.e., HCoIPsec.



Ertekin, et al.         Expires December 28, 2006               [Page 6]


Internet-Draft      Integration of HC over IPsec SAs           June 2006


                             +-------------------------------+
                             | HC Module                     |
                             |                               |
                             |                               |
        +-----+              |     +-----+     +---------+   |
        |     | HC-enabled   |     |     |     |    HC   |   |
      --|  A  |--------------------|  B  |-----| Process |------> Path 1
        |     |              |     |     |     |         |   |
        +-----+              |     +-----+     +---------+   |
           |                 |        |                      |
           |                 |        |-------------------------> Path 2
           |                 |                               |
           |                 +-------------------------------+
           |
           | HC-disabled
           +----------------------------------------------------> Path 3

   Figure 1: Integration of HC with IPsec.

   The process illustrated in Figure 1 augments the IPsec processing
   model for outbound IP traffic(protected-to-unprotected).  Initial
   IPsec processing is consistent with RFC 4301 (Steps 1-2, Section
   5.1).  The HC data item (part of the SA state information) retrieved
   from the "relevant SAD entry" (RFC4301, Section 5.1, Step3a)
   determines if the traffic traversing the SA is handed to the HC
   module (Figure 1, decision block A).  Packets selected to an HC-
   disabled SA must follow normal IPsec processing and must not be sent
   to the HC module (Figure 1, Path 3).  Conversely, packets selected to
   an HC-enabled SA must be sent to the HC module.  The decision at
   block B then determines if the packet can be compressed.  If it is
   determined that the packet will be compressed, the Next Header field
   of the security protocol header (e.g., ESP, AH) is populated with the
   "compressed headers" value, and packet headers are compressed based
   on the appropriate compression profile (Figure 1, Path 1).  However,
   if it is determined that the packet will not be compressed, the Next
   Header field is populated with the appropriate value indicating the
   next level protocol (Figure 1, Path 2).  After the HC process
   completes, IPsec processing resumes, as described in Section 5.1,
   Step3a, of RFC4301 (specifically, "IPsec processing is as previously
   defined...").

   The process illustrated in Figure 1 also augments the IPsec
   processing model for inbound IP traffic (unprotected-to-protected).
   For inbound packets, processing is performed (RFC4301, Section 5.2,
   Steps 1-3) followed by AH or ESP processing (RFC4301, Section 5.2,
   Step 4) .  After AH or ESP processing, the HC data item retrieved
   from the SAD entry will indicate if traffic traversing the SA is
   handed to the HC module (RFC4301, Section 5.2, Step 3a).  Packets



Ertekin, et al.         Expires December 28, 2006               [Page 7]


Internet-Draft      Integration of HC over IPsec SAs           June 2006


   traversing an HC-disabled SA must follow normal IPsec processing and
   must not be sent to the HC module.  Conversely, packets traversing an
   HC-enabled SA must be sent to the HC module.  The decision at block B
   then determines if the "Next Header" field contains the "compressed
   header" value, which indicates that the packet's payload contains
   compressed headers.  If "compressed headers" is indicated, the
   appropriate decompression profile is applied (Figure 1, Path 1).
   However, if the packet's "Next Header" field does not contain the
   "compressed headers" value, the decompressor must not attempt
   decompression (Figure 1, Path 2).  IPsec processing resumes once the
   HC module completes processing, as described in Section 5.2, Step 4
   of RFC 4301(specifically "Then match the packet against the inbound
   selectors identified by the SAD ...").

6.1.1.  Header Compression Scheme Considerations

   Traditional hop-by-hop HC schemes must be extended to operate
   efficiently over IPsec SAs.  Implementation considerations for this
   includes increasing tolerance to packet reordering and packet loss
   between the compressor and decompressor, and minimizing the amount of
   feedback sent from the decompressor to the compressor.

   The ability to tolerate increased packet reordering between the
   compressor and decompressor is a necessity for any HC scheme that is
   extended to operate over an IPsec SA.  The following provides a
   summary of the candidate HC solutions, and their tolerance to packet
   loss and reordering between the compressor and decompressor:
   o  IPHC has been identified as a HC scheme that performs poorly over
      long round trip time (RTT), high BER links [ROHC].  Extensions to
      IPHC to compress TCP/IP headers over an IPsec SA should take into
      consideration longer RTTs, increased potential for packet
      reordering and IPLR between the compressor and decompressor.
   o  CRTP has also been identified as a HC scheme that performs poorly
      over long RTT, high BER links [CRTPE].  Recent modifications to
      the CRTP scheme, such as ECRTP, enable the CRTP HC scheme to
      tolerate long RTTs and packet loss between the compressor and
      decompressor.  However, the reordering tolerance of ECRTP still
      needs to be evaluated, as detailed in [ECRTPE].  Such
      implementation aspects should be taken into consideration when
      extending ECRTP to operate over IPsec SAs.
   o  ROHC is a robust HC scheme that is designed for high BER, long RTT
      links.  ROHC can be used to compress not only RTP/UDP/IP headers,
      but also other traffic profiles such as TCP/IP, as defined in
      [ROHCTCP].  Similar to CRTP and IPHC, ROHC has been identified as
      vulnerable to packet reordering events between the compressor and
      decompressor[ROHCE].  Recent work [ROHCWEXT] suggests that the
      implementation aspects of ROHC can be modified to achieve
      tolerance to packet reordering events.  Such implementation



Ertekin, et al.         Expires December 28, 2006               [Page 8]


Internet-Draft      Integration of HC over IPsec SAs           June 2006


      aspects should be taken into consideration when extending ROHC to
      operate over IPsec SAs.

   In addition, HC schemes should minimize the amount of feedback
   between decompressor and compressor.  If a feedback channel from the
   decompressor to the compressor is not used sparingly, the overall
   gains from HCoIPsec can be significantly reduced.  For example,
   assume that ROHC is operating in bi-directional reliable mode, and is
   instantiated over an IPsec tunnel mode SA.  In this scenario, any
   feedback sent from the decompressor to the compressor must be
   tunneled.  As such, the additional overhead incurred by tunneling
   feedback will reduce the overall benefits of HC.

6.1.2.  Initialization and Negotiation of HC Channel

   Hop-by-hop HC schemes use the underlying link layer (e.g., PPP) to
   negotiate HC channel parameters.  To remove HC scheme dependencies on
   the underlying link layer, an additional mechanism is needed to
   initialize a HC channel and its associated parameters prior to HC
   scheme operation.

   Initialization of the HC channel will either be achieved manually
   (i.e., administratively configured for manual SAs), or be performed
   by IPsec SA establishment protocols, e.g.  IKEv2.  During SA
   initialization, the SA establishment protocol will be extended to
   negotiate the HC scheme's channel parameters.  The specifics for this
   proposal are detailed in a separate spectification, "IKEv2/IPsec
   Extensions to Support HCoIPsec".

   If the HC scheme requires bi-directional communications, two SAs must
   be instantiated between the IPsec implementations.  One of the two
   SAs is used for carrying traffic from the compressor to the
   decompressor, while the other is used to communicate feedback from
   the decompressor to the compressor.  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 HC
   data item) is defined for each SA.  The HC data item is used by the
   IPsec process to determine whether it sends all traffic traversing a
   given SA to the HC module (HC-enabled) or bypasses the HC module and
   sends the traffic through regular IPsec processing (HC-disabled).

   In addition, 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 HC-enabled SA.  This



Ertekin, et al.         Expires December 28, 2006               [Page 9]


Internet-Draft      Integration of HC over IPsec SAs           June 2006


   functionality is needed in situations where packets traversing an HC-
   enabled SA are not compressed by the compressor.  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 to an HC-enabled
   SA, but cannot be compressed by the HC process (e.g., because the
   compressor does not support TCP/IP compression).  In these
   situations, the compressor must be able to 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.  Therefore, an allocation for "compressed headers"
   will need to be reserved from the IANA "Protocol Numbers" registry,
   which will be defined in a separate specification.  The "compressed
   headers" value will indicate that the next layer protocol header is
   composed of compressed headers.

6.2.  HCoIPsec Framework Summary

   [Note to RFC Editor: this section may be removed on publication as an
   RFC.]

   To summarize, the following items are needed to achieve HCoIPsec:
   o  Extensions to traditional HC schemes which enable their operation
      at IPsec SA enpoints
   o  Extensions to IKE/IPsec to support HC parameter configuration
   o  Allocation of one value for "compressed headers" from the IANA
      "Protocol Numbers" registry


7.  Security Considerations

   A malfunctioning header 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.


8.  IANA Considerations

   None.


9.  Acknowledgments




Ertekin, et al.         Expires December 28, 2006              [Page 10]


Internet-Draft      Integration of HC over IPsec SAs           June 2006


   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. Lars-Erik Jonnson
   o  Mr. Jan Vilhuber
   o  Mr. Dan Wing
   o  Mr. Kristopher Sandlund

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


10.  References

10.1.  Normative References

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

   [IPHC]     Nordgren, M., Pink, B., and S. Pink, "IP Header
              Compression", RFC 2507, February 1999.

   [CRTP]     Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
              Headers for Low-Speed Serial Links", RFC 2508,
              February 1999.

   [ECRTP]    Koren, T. and et. al., "Compressing IP/UDP/RTP Headers on
              Links with High Delay, Packet Loss, and Reordering",
              RFC 3545, July 2003.

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

   [ECRTPE]   Knutsson, C., "Evaluation and Implemenation[sic] of Header
              Compression Algorithm ECRTP", November 2004.

   [ROHCTCP]  Pelletier, G. and et. al, "Robust Header Compression: A



Ertekin, et al.         Expires December 28, 2006              [Page 11]


Internet-Draft      Integration of HC over IPsec SAs           June 2006


              Profile For TCP/IP (ROHC-TCP)", work in progress ,
              January 2006.

   [ROHCWEXT]
              Pelletier, G. and et. al, "ROHC over Channels That Can
              Reorder Packets", RFC 4224, January 2006.

10.2.  Informative References

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

   [HCOMPLS]  Ash, J. and et. al, "Protocol Extensions for Header
              Compression over MPLS", April 2005.

   [CRTPE]    Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro,
              "Evaluation of CRTP Performance over Cellular Radio
              Networks", IEEE Personal Communication Magazine , Volume
              7, number 4, pp. 20-25, August 2000.

   [ROHCE]    Ash, J. and et. al, "Requirements for ECRTP over MPLS",
              RFC 4247, November 2005.





























Ertekin, et al.         Expires December 28, 2006              [Page 12]


Internet-Draft      Integration of HC over IPsec SAs           June 2006


Authors' Addresses

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

   Email: ertekin_emre@bah.com


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

   Email: christou_chris@bah.com


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

   Email: jasani_rohan@bah.com
























Ertekin, et al.         Expires December 28, 2006              [Page 13]


Internet-Draft      Integration of HC over IPsec SAs           June 2006


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


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.


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Ertekin, et al.         Expires December 28, 2006              [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/