[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
Intended status: Informational                                 R. Jasani
Expires: August 28, 2007                             Booz Allen Hamilton
                                                       February 24, 2007


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

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 August 28, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   IP Security (IPsec) [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 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 Associations (SAs).



Ertekin, et al.          Expires August 28, 2007                [Page 1]


Internet-Draft      Integration of HC over IPsec SAs       February 2007


Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
   2.      Audience . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.      Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   4.      Problem Statement: IPsec Packet Overhead . . . . . . . . .  4
   5.      Overview of the HCoIPsec Framework . . . . . . . . . . . .  5
   5.1.    HCoIPsec Assumptions . . . . . . . . . . . . . . . . . . .  5
   5.2.    Summary of the HCoIPsec Framework  . . . . . . . . . . . .  5
   6.      Details of the HCoIPsec Framework  . . . . . . . . . . . .  6
   6.1.    HC and IPsec Integration . . . . . . . . . . . . . . . . .  6
   6.1.1.  Header Compression Protocol Considerations . . . . . . . .  8
   6.1.2.  Initialization and Negotiation of HC Channel . . . . . . .  9
   6.1.3.  Encapsulation and Identification of Header Compressed
           Packets  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.2.    HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10
   7.      Security Considerations  . . . . . . . . . . . . . . . . . 10
   8.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 11
   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 August 28, 2007                [Page 2]


Internet-Draft      Integration of HC over IPsec SAs       February 2007


1.  Introduction

   This document outlines a framework for integrating HC over IPsec
   (HCoIPsec).  The goal of HCoIPsec 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 HCoIPsec, this document assumes that existing HC protocols, such
   as Internet Protocol Header Compression [IPHC], Compressed Real Time
   Protocol [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and
   Robust Header Compression [ROHC], will be used to compress the inner
   headers of IP packets traversing an IPsec tunnel.  Since these HC
   protocols are designed to operate on a hop-by-hop basis, they may
   require extensions to enable their operation over IPsec SAs.  This
   document outlines a framework for extending the usage of these hop-
   by-hop HC protocols to operate at IPsec SA endpoints.

   HCoIPsec targets the application of HC 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 traditional HC protocols were 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 specifications for HC protocols do not include support for
   the compression of transport layer headers alone, the HCoIPsec
   framework outlined by this document describes the application of HC
   to tunnel mode SAs.


2.  Audience

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


3.  Terminology

   Terminology specific to HCoIPsec is introduced in this section.



Ertekin, et al.          Expires August 28, 2007                [Page 3]


Internet-Draft      Integration of HC over IPsec SAs       February 2007


   Compressed Traffic

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

   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, as defined in [IPSEC].

   Next Header

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


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 ([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.
   HC applied on a per-hop basis over bandwidth-constrained link
   technologies 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



Ertekin, et al.          Expires August 28, 2007                [Page 4]


Internet-Draft      Integration of HC over IPsec SAs       February 2007


   characterized by small packet payloads.  Some applications that
   generate small packet payloads include various voice codecs.  In
   addition, 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 HCoIPsec Framework

5.1.  HCoIPsec Assumptions

   The goal of HCoIPsec is to provide 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.  Summary of the HCoIPsec Framework

   HC protocols reduce packet overhead in a network by exploiting intra-
   and inter-packet redundancies of network and transport-layer header
   fields of a flow.

   Existing HC protocols 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 protocols may need to be extended to operate
   at IPsec SA endpoints.

   The migration of hop-by-hop HC protocols 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 existing HC protocols will now essentially
   operate over multiple hops, it is imperative that their performance
   is not severely impacted due to increased packet reordering and/or
   packet loss between the compressor and decompressor.

   In addition, since HC protocols will operate at IPsec SA endpoints,
   HC protocols can no longer rely on the underlying link layer for HC



Ertekin, et al.          Expires August 28, 2007                [Page 5]


Internet-Draft      Integration of HC over IPsec SAs       February 2007


   parameter configuration and packet identification.  Existing HC
   protocols use the underlying link layer to establish a set of
   configuration parameters at each end of the link, and some HC
   protocols (e.g., IPHC, CRTP, ECRTP) are also dependent on the link
   layer framing for identifying different types of header-compressed
   packets.  The HCoIPsec framework proposes that HC channel parameter
   configuration is accomplished by the SA management protocol (e.g.,
   IKEv2), while identification of compressed header packets (in
   contrast to uncompressed packets) is provided through the Next Header
   field of the security protocol (e.g., AH [AH], ESP).  In addition, HC
   protocols that require the identification of different types of
   header-compressed packets will have to be extended with such a
   mechanism.

   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 [IPSEC]).

      Note: Compression of inner headers is independent from compression
      of the security protocol (e.g., ESP) and outer IP headers.  HC
      protocols such as ROHC are capable of compressing the security
      protocol and the outer IP header on a hop-by-hop basis.

   If IPsec NULL encryption is applied to packets, HC protocols 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 HCoIPsec Framework

6.1.  HC and IPsec Integration

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




Ertekin, et al.          Expires August 28, 2007                [Page 6]


Internet-Draft      Integration of HC over IPsec SAs       February 2007


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

   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 [IPSEC] (Steps 1-2, Section 5.1).
   The HC 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 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 a "compressed headers"
   value, and packet headers are compressed based on the compression
   protocol (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 HC process completes, IPsec processing resumes, as
   described in Section 5.1, Step3a, of [IPSEC] (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, IPsec processing is performed ([IPSEC], Section
   5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section



Ertekin, et al.          Expires August 28, 2007                [Page 7]


Internet-Draft      Integration of HC over IPsec SAs       February 2007


   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 ([IPSEC], Section 5.2, Step 3a).
   Packets 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 is determined by the value of the Next Header
   field.  If "compressed headers" is indicated, decompression is
   applied using the appropriate HC protocol (Figure 1, Path 1).
   However, if the Next Header field does not contain the "compressed
   headers" value, the decompressor must not attempt decompression
   (Figure 1, Path 2).  Once the HC 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 ...").

   Note that to further reduce the size of an IPsec-protected packet,
   HCoIPsec and IPcomp [IPCOMP] can be implemented in a nested fashion.
   For an outbound packet, IPcomp is initially applied.  Following the
   application of IPcomp, the packet is sent to the HC module.  Then,
   the HC module may compress the headers (e.g., the IP header) of the
   IPcomp-processed packet.  After the HC process completes, IPsec
   processing resumes.  For inbound packets, these steps are reversed:
   first, the packet is IPsec-processed; then, headers are decompressed;
   last, the payload of the packet is decompressed based on the
   appropriate IPcomp algorithm.

6.1.1.  Header Compression Protocol Considerations

   Traditional hop-by-hop HC protocols must be extended to operate
   efficiently over IPsec SAs.  Compressor and decompressor
   implementation considerations therefore must account for increased
   tolerance to packet reordering and packet loss between the compressor
   and decompressor, and must minimize 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 protocol 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 protocol 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 packet loss between the compressor and
      decompressor.




Ertekin, et al.          Expires August 28, 2007                [Page 8]


Internet-Draft      Integration of HC over IPsec SAs       February 2007


   o  CRTP has also been identified as a HC protocol that performs
      poorly over long RTT, high BER links [CRTPE].  Recent
      modifications to the CRTP protocol, such as ECRTP, enable the CRTP
      HC protocol 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 protocol 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
      aspects should be taken into consideration when extending ROHC to
      operate over IPsec SAs.

   Note that additional techniques may be used to augment a traditional
   HC protocol's tolerance to packet reordering.  For example, various
   security protocols are equipped with a sequence number; this value
   may be used by the decompressor to identify a packet as "sequentially
   late".  This knowledge can increase the likelihood of successful
   decompression of a reordered packet.

   In addition, HC protocols 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 protocols use the underlying link layer (e.g., PPP) to
   negotiate HC channel parameters.  To remove HC protocol dependencies
   on the underlying link layer, an additional mechanism is needed to
   initialize a HC channel and its associated parameters prior to
   HCoIPsec 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.  The extensions required for
   IKEv2 to support HC parameter negotiation are detailed in [IKE-HC].



Ertekin, et al.          Expires August 28, 2007                [Page 9]


Internet-Draft      Integration of HC over IPsec SAs       February 2007


   If the HC protocol 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.  Note that the requirement for
   two SAs aligns with the operation of IKE, which creates SAs in pairs.
   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 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).

   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 functionality
   is needed in situations where packets traversing an HC-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 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 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 "compressed
   header" value will indicate the packet contains compressed headers.
   Therefore, an official IANA allocation from the ProtocolID registry
   is required.  The request for a ProtocolID allocation, in addition to
   IPsec extensions to support HCoIPsec, are specified in [IPSEC-HC].

6.2.  HCoIPsec Framework Summary

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


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



Ertekin, et al.          Expires August 28, 2007               [Page 10]


Internet-Draft      Integration of HC over IPsec SAs       February 2007


   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

   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. Tero Kivinen
   o  Mr. Lars-Erik Jonsson
   o  Mr. Jan Vilhuber
   o  Mr. Dan Wing
   o  Mr. Kristopher Sandlund
   o  Mr. Ghyslain Pelletier

   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,



Ertekin, et al.          Expires August 28, 2007               [Page 11]


Internet-Draft      Integration of HC over IPsec SAs       February 2007


              February 1999.

   [ECRTP]    Koren, 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.

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

   [ROHCTCP]  Pelletier, et al., "Robust Header Compression: A Profile
              For TCP/IP (ROHC-TCP)", work in progress , February 2007.

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

   [IPSEC-HC]
              Ertekin, et al., "IPsec Extensions to Support HCoIPsec",
              work in progress , February 2007.

10.2.  Informative References

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

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

   [AH]       Kent, S., "IP Authentication Header", RFC 4302,
              December 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.

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

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



Ertekin, et al.          Expires August 28, 2007               [Page 12]


Internet-Draft      Integration of HC over IPsec SAs       February 2007


   [ROHCWEXT]
              Pelletier, et al., "ROHC over Channels That Can Reorder
              Packets", RFC 4224, January 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 August 28, 2007               [Page 13]


Internet-Draft      Integration of HC over IPsec SAs       February 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).





Ertekin, et al.          Expires August 28, 2007               [Page 14]


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