[Docs] [txt|pdf] [Tracker] [WG] [Email] [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: May 6, 2006                                           R. Jasani
                                                     Booz Allen Hamilton
                                                        November 2, 2005


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

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 May 6, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Internet Protocol security mechanisms, such as IP Security (IPsec)
   [IPSEC], provides various security services for IP traffic.  However,
   the benefits offered by IPsec come at the cost of increased overhead.
   This document identifies a methodology for integrating header
   compression (HC) over IPsec (HCoIPsec).  HCoIPsec proposes to reduce
   the amount of packet overhead associated with the transmission of
   traffic over tunnel mode security associations.



Ertekin, et al.            Expires May 6, 2006                  [Page 1]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Audience . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Problem Statement: Packet Overhead Associated with IPsec
       Tunnel-Mode SAs  . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  The Header Compression Solution  . . . . . . . . . . . . . . .  4
   5.  Integration Methodology  . . . . . . . . . . . . . . . . . . .  5
     5.1   Work Assumptions . . . . . . . . . . . . . . . . . . . . .  6
     5.2   Work Items . . . . . . . . . . . . . . . . . . . . . . . .  6
       5.2.1   Header Compression Scheme-Specific Extensions  . . . .  7
       5.2.2   Initialization and Negotiation of Header
               Compression Channel  . . . . . . . . . . . . . . . . .  7
       5.2.3   Encapsulation and Identification of Header
               Compressed Packets . . . . . . . . . . . . . . . . . .  8
   6.  Candidate Compression Schemes  . . . . . . . . . . . . . . . .  8
   7.  Example Operation  . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Future Work Items  . . . . . . . . . . . . . . . . . . . . . . 11
     8.1   HCoIPsec Transport Mode SAs  . . . . . . . . . . . . . . . 11
     8.2   Multiplexing of Compressed Packets in IPsec Tunnels  . . . 12
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 13
   11.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 13
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
     12.1  Normative References . . . . . . . . . . . . . . . . . . . 13
     12.2  Informative References . . . . . . . . . . . . . . . . . . 14
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 16























Ertekin, et al.            Expires May 6, 2006                  [Page 2]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


1.  Introduction

   This document identifies a methodology for the integration of header
   compression (HC) over IPsec Security Associations (SAs) operating in
   tunnel mode.  The goal of integrating HC with IPsec is to reduce the
   protocol overhead associated with packets traversing between IPsec SA
   endpoints.  This goal can be achieved by compressing the upper layer
   protocols (e.g., RTP/UDP and TCP) and the inner IP header of packets,
   at the ingress of the IPsec tunnel, and decompression at the egress.

   To accomplish 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 within an IPsec tunnel.  However, since these HC
   schemes operate on a hop-by-hop basis, several extensions need to be
   defined.  This document details a methodology which will enable these
   traditional hop-by-hop HC schemes to be extended, and operate between
   IPsec SA endpoints.

   Currently, HCoIPsec primarily targets the application of HC to tunnel
   mode SAs as opposed to transport mode SAs.  Transport mode SAs
   encrypt/authenticate only the payload of an IP packet, leaving the
   original IP header untouched.  Intermediate routers subsequently use
   the original IP header to route the packet to a decryption device.
   Therefore, if HC were extended to operate between IPsec transport-
   mode SA endpoints, (de)compression functionality can be applied only
   to the transport layer headers and not the IP header.  Since
   compression of transport layer headers alone does not provide
   substantial efficiency gains, it is not fully integrated into the
   HCoIPsec methodology.

2.  Audience

   The target audience includes those who are involved with the design
   and development of HC schemes, and IPsec mechanisms.  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 methodology put forward in this document.  Finally, this
   document is directed towards vendors developing IPsec devices which
   will be deployed in bandwidth-constrained, IP networks.

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

   IPsec mechanisms provide various security services for IP-based



Ertekin, et al.            Expires May 6, 2006                  [Page 3]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


   networks.  For example, ESP offers data origin authentication,
   connectionless integrity, anti-replay service, and limited traffic
   flow confidentiality [ESP].

   The benefits of IPsec mechanisms come at the cost of increased per-
   packet overhead in the network.  For example, traffic flow
   confidentiality, which is generally implemented at security gateways,
   requires the tunneling of IP packets between the IPsec devices.
   IPsec tunnels may mask the source-destination patterns that an
   intruder may ascertain, but the benefit comes at the cost of extra
   per-packet overhead.  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 (SATCOM) networks, as these
   types of infrastructure are not overprovisioned.  Consequently, the
   additional overhead incurred in an encryption-based environment may
   hinder the efficient utilization of bandwidth.

   In bandwidth-constrained high bit error rate (BER) networks, end-host
   applications may not have the luxury of sending packets with large
   payloads.  This is due to the fact that large packets traversing high
   BER links result in high IP Packet Loss Ratio (IPLR).  To reduce
   IPLR, end-host devices may reduce the size of packet payloads, which
   decreases the probability that a packet is lost due to a bit error.
   Reducing the size of packet payloads, however, increases the amount
   of overhead transmitted between the two end hosts.  Moreover, if
   these packets traverse over an IPsec tunnel mode SA, the amount of
   overhead is further magnified.  A mechanism is needed to reduce the
   overhead associated with such flows.

4.  The Header Compression Solution

   IP HC schemes provide one mechanism to reduce packet overhead in an
   IP network.  Schemes such as IPHC, CRTP, ECRTP and ROHC exploit
   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 HC schemes over IPsec SAs, several extensions to the
   existing schemes need to be developed.  Existing HC schemes such as
   IPHC, CRTP, ECRTP and ROHC are designed to compress headers on a hop-
   by-hop basis.  IPsec SAs, however, may be instantiated between IPsec
   devices functioning as gateways, with multiple intermediary nodes
   between the IPsec gateways.  Therefore, to fully integrate HC with
   IPsec SAs, traditional hop-by-hop schemes need to be extended to
   operate between IPsec SA endpoints.

   The migration of traditional hop-by-hop HC schemes over IPsec SAs is



Ertekin, et al.            Expires May 6, 2006                  [Page 4]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


   simple, as SA endpoints provide source/destination pairs where
   (de)compression operations can take place.  Compression in such a
   manner offers both a reduction of per-packet protocol overhead
   between the two SA endpoints, and does not require compression and
   decompression cycles at the intermediate network nodes between the
   IPsec devices.  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 IPLR events between the compressor and decompressor.  It
   should be noted that the notion of extending hop-by-hop HC schemes to
   operate over multiple hops is not new, as the HCoIPsec effort
   parallels other efforts such as ECRTP over MPLS [HCOMPLS].

   Using the proposed architecture, 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
   implicitly determines whether the packet was received on a HC-enabled
   SA.  If the packet was received over a HC-enabled SA, the
   decompression function takes place.

      Note: Compression of inner headers is completely independent from
      compression of the outer (e.g., ESP/IP) headers.  Intermediate
      network nodes between IPsec endpoints may also compress the outer
      ESP/IP headers.  Current HC schemes such as ROHC and IPHC contain
      the ability to compress these ESP/IP headers.  Further discussion
      of hop-by-hop compression of the outer ESP/IP headers is out of
      the scope of this document.

   If IPsec NULL encryption is applied on packets, HC schemes may still
   be applied on the inner headers at the IPsec SA endpoints.  Inbound
   and outbound packets are processed as described previously.  In
   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
   on a hop-by-hop basis.

5.  Integration Methodology

   The goal for HCoIPsec is to provide more efficient transport of IP
   packets between source and destination IPsec devices without
   compromising security services offered by IPsec.




Ertekin, et al.            Expires May 6, 2006                  [Page 5]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


   With this general goal in mind, Section 5.1 defines a set of work
   assumptions to guide the direction of the HCoIPsec solution.  Based
   on these work assumptions, Section 5.2 defines work items which need
   to be addressed to achieve the HCoIPsec solution.

5.1  Work Assumptions

   a.  HCoIPsec must use existing HC protocols (e.g., IPHC, CRTP, ECRTP,
       ROHC) to reduce the amount of overhead associated with packets
       traversing an IPsec tunnel-mode SA.
   b.  HCoIPsec must execute (de)compression operations at IPsec SA
       endpoints, and must not perform (de)compression cycles at
       intermediate nodes between IPsec devices.
   c.  HCoIPsec must be independent of the underlying link layer framing
       protocol (e.g., PPP).
   d.  HCoIPsec must allow each SA to constitute a HC channel, enabling
       each SA to have its own CID space.
   e.  An SA with HC enabled should not deliver a larger number of
       erroneous packets than the same SA with HC disabled.

   The motivation behind (c) comes from the realization that an SA may
   traverse multiple links, employing various framing protocols, and
   that the set of links (and thus framing protocols) may change during
   the lifetime of an SA.  Therefore, link layer dependencies exhibited
   by traditional hop-by-hop HC schemes cannot be used in the HCoIPsec
   solution.

5.2  Work Items

   This section identifies several work items that need to be addressed
   to achieve HCoIPsec.  The first work item encompasses the HC scheme-
   specific extensions needed to ensure that traditional hop-by-hop HC
   schemes will operate efficiently over IPsec SA endpoints:

   a. Header Compression Scheme-Specific Extensions: Any modifications
      needed to be made to existing HC schemes, which will facilitate
      their operation over IPsec SAs.  (Section 5.2.1)

   Hop-by-hop HC schemes use the underlying link layer (e.g., PPP) to
   negotiate the HC channel parameters and to indicate the type of
   compressed packet the data-link layer frame is encapsulating.  To
   remove HC scheme dependencies on the underlying link layer, two
   additional work items are proposed:








Ertekin, et al.            Expires May 6, 2006                  [Page 6]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


   b. Initialization and Negotiation of the Header Compression Channel:
      Mechanisms needed to initialize a HC channel and negotiate HC
      scheme parameters prior to operation.  (Section 5.2.2)
   c. Encapsulation and Identification of Header Compressed Packets:
      Mechanisms that encapsulate and identify compressed header
      packets, as well as how these mechanisms will operate.  (Section
      5.2.3)

5.2.1  Header Compression Scheme-Specific Extensions

   a.  HCoIPsec should minimize HC scheme performance degradation due to
       increased delays, packet loss, jitter, and reordering events
       between compressor and decompressor.
   b.  HCoIPsec should minimize the amount of HC signaling between
       compressor and decompressor.

   The intention of (b) is to indicate that if a feedback channel from
   the decompressor to the compressor is not used sparingly,  then the
   overall gains from HCoIPsec can be significantly reduced (even more
   so than hop-by-hop HC).  For example, take the case where ROHC in bi-
   directional reliable mode is instantiated over an IPsec tunnel mode
   SA.  Any feedback sent from the decompressor to the compressor may be
   tunneled, and therefore, the additional overhead incurred by
   tunneling the feedback will reduce the overall benefits of HC.

   Note that if a HCoIPsec session requires bidirectional communication
   between the compressor and the decompressor (e.g., a ROHC session
   operating in bidirectional-reliable mode, or bidirectional-optimistic
   mode, or ECRTP and CONTEXT_STATE packets), this may pose an issue,
   given that SAs are unidirectional, and that HCoIPsec defines a HC
   context to be specific to a given SA.  Any feedback packet
   communicated from the HCoIPsec decompressor to the HCoIPsec
   compressor is over a separate SA back to the original IPsec device.
   To identify the stale context, the feedback packet must contain the
   context ID as well as an indication of the SA that the decompressor
   is associated to.  This poses a problem for current HC algorithm
   feedback packets, which are not structured to carry the additional SA
   indication information.  For example, current ECRTP feedback
   mechanisms (e.g., CONTEXT_STATE) only list the CIDs for which
   synchronization has been lost.  If a bidirectional HC algorithm is to
   be integrated with IPsec, additional HC scheme-specific extensions
   must be defined to resolve this issue.

5.2.2  Initialization and Negotiation of Header Compression Channel

   Initialization of the HC channel parameters may achieved manually
   (i.e., administratively configured for manual SAs), or may be
   performed by IPsec SA establishment protocols, e.g.  IKE.  During SA



Ertekin, et al.            Expires May 6, 2006                  [Page 7]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


   initialization, the IPsec SA establishment protocols will identify
   the type of HC scheme configured for the SA, as well as the HC
   scheme's channel parameters.

   a.  HCoIPsec may leverage IKE, IKEv2 to negotiate HC channel
       parameters (e.g., for ROHC, IKE(v2) shall initialize PROFILES,
       MAX_CID, MAX_HEADER, MRRU).
   b.  HCoIPsec must allow packets with uncompressed headers and packets
       with compressed headers to traverse a single SA.  "Packets with
       compressed headers" refer to packets which are selected to an HC-
       enabled SA, are passed to the compressor, and are actually
       compressed; "packets with uncompressed headers" refer to packets
       which are selected to an HC-enabled SA, are passed to the
       compressor, and are not "compressed" (e.g., ROHC compressor
       processes a packet with the uncompressed profile).

   (b) is necessary in situations where a compressor--for one reason or
   another--cannot compress a flow (e.g., a compressor supports strictly
   n compressed flows, and cannot compress the n+1 flow that arrives).

5.2.3  Encapsulation and Identification of Header Compressed Packets

   For indication purposes, a one-byte header may be added to the
   compressed packet; this field will help the decompressor identify how
   to process the compressed packet.  This one-byte header is only
   relevant to the HC compression and decompression processes, and is
   not used by IPsec..

   a.  HCoIPsec may introduce a new one-byte header to indicate the type
       of compressed packet (e.g., for ECRTP, COMPRESSED_RTP_8,
       COMPRESSED_RTP_16, CONTEXT_STATE, etc.)

   Note that ROHC indicates its own packet type within the protocol, and
   does not require a new one-byte header to indicate the type of
   compressed packet.

6.  Candidate Compression Schemes

   IPHC can be used to compress TCP/IP headers for tunnel mode SAs.
   IPHC, however, 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 need
   to take into consideration longer RTTs, increased potential for
   packet reordering and IPLR between the compressor and decompressor.

   CRTP can be used to compress RTP/UDP/IP headers for tunnel mode SAs.
   CRTP, however, has also been identified as a HC scheme that performs
   poorly over long RTT, high BER links [CRTPE].  Recent modifications



Ertekin, et al.            Expires May 6, 2006                  [Page 8]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


   to the CRTP scheme, such as ECRTP, enables the CRTP HC scheme to
   tolerate long RTTs, packet loss, between compressor and decompressor.
   The reordering tolerance of ECRTP, however, needs to be evaluated, as
   detailed in [ECRTPE].  Such implementation aspects should be taken
   into consideration when extending ECRTP to operate between IPsec SA
   endpoints.

   ROHC, as defined in RFC 3095, provides a robust HC scheme that is
   designed for high BER, long RTT links.  This makes ROHC another
   candidate header scheme to operate over IPsec tunnels.  ROHC can be
   used to compress not only RTP/UDP/IP headers, but also TCP/IP
   headers, 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
   between IPsec SA endpoints.

   The ability to tolerate these network characteristics is a necessity
   for any HCoIPsec scheme, and will be a factor in determining how
   efficiently the HC scheme operates over the IPsec tunnel-mode SAs.

7.  Example Operation

   The basic operation of the HCoIPsec protocol is detailed in the
   following example.  Assume there are two IPsec devices operating as
   security gateways.  HCoIPsec leverages an SA establishment protocol
   (e.g., IKE, IKEv2) to negotiate the HC scheme, and channel
   parameters.  For example, the MAX_CID, MRRU, MAX_HEADER, and PROFILES
   parameters will be negotiated for each IPsec SA which is capable of
   ROHC.  For an IPsec SA that is ECRTP-enabled, channel parameters
   including F_MAX_PERIOD, F_MAX_TIME, and the ECRTP Compression
   Suboption will be initialized.  For the following example, assume
   that a HC-enabled SA has been established.

   Outbound packet processing is as follows.  The packet is initially
   processed as described in Steps 1-2, Section 5.1 of RFC 2401bis.  The
   SPD cache entry then maps the packet to a given SAD entry, which
   indicates the HC protocol enabled on the SA (in addition to mode,
   cryptographic algorithms, keys, etc.).  If the SAD entry indicates
   that compression is disabled, then standard IPsec processing ensues,
   as described in Steps 3-4, Section 5.1 of RFC 2401bis.  If the SAD
   entry indicates that compression is enabled, the packet must be
   handed to the appropriate compressor, which executes the compression
   process.  After the packet's header is compressed, the packet resumes
   IPsec processing as described in Step 3a, where standard IPsec ESP
   processing ensues (including packet encryption according to the SAD



Ertekin, et al.            Expires May 6, 2006                  [Page 9]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


   entry parameters, packet encapsulation with the outer ESP/IP header)
   and is subsequently passed to the outbound forwarding function, as
   described in Step 4 of RFC 2401bis.

   Inbound packet processing is as follows.  The packet is initially
   processed as described in Steps 1-3, Section 5.2 of RFC 2401bis;
   subsequently (using the SAD entry selected in Step 3a), ESP
   processing is applied.  Based on information retrieved from the SAD
   entry, it can also be determined whether traffic traversing the SA is
   compressed or not compressed.  If the SAD entry indicates that
   compression is not enabled on the SA, then standard IPsec processing
   of the packet ensues, as described in Step 4, Section 5.2 of RFC
   2401bis.  If compression is enabled on the SA, the packet is handed
   to the decompressor for "decompression".  Once the packet is
   decompressed, the processing as described in Step 4, Section 5.2 of
   2401bis resumes (specifically "Then match the packet against the
   inbound selectors identified by the SAD...").


































Ertekin, et al.            Expires May 6, 2006                 [Page 10]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


   Figure 1 depicts the basic function of HCoIPsec:

                  -- --  --  --  --  --  --  --  -- --
                 |ESP Tunnel Mode Security Association|
                 |                                    |
                 |                                    |
                 V                                    V
            +--------------+                 +--------------+
            | IPsec Device |   +--+   +--+   | IPsec Device |
            |              |   |  |   |  |   |              |
        +---|  Compressor  |-->|R1|-->|R2|-->| Decompressor |---+
        |   |              |   |  |   |  |   |              |   |
        |   +--------------+   +--+   +--+   +--------------+   |
        |                  |                 |                  |
        |                  |-----------------|                  |
        |                           |                           |
        |                           |                           |
        V                           V                           V
   +-----------------+  +-----------------------+  +-----------------+
   |   |     |       |  |   |   |               |  |   |     |       |
   |   | UDP |       |  |   | E | ------------- |  |   | UDP |       |
   |IP |  /  |Payload|  |IP | S | |CID|Payload| |  |IP |  /  |Payload|
   |   | RTP |       |  |   | P | ------------- |  |   | RTP |       |
   |   |     |       |  |   |   |               |  |   |     |       |
   +-----------------+  +-----------------------+  +-----------------+
                                |               |
                                |---ENCRYPTED---|
                                |               |

   Figure 1: Example operation of HCoIPsec.

   In the example scenario, note that the inbound and outbound packets
   are first mapped to an SA, and then subsequently mapped to a CID.
   This implies that the scope of each CID is contained within each SA.
   A CID value of 1 can be associated with multiple SAs; however, the
   context state information for CID 1 cannot be shared over multiple
   SAs.

8.  Future Work Items

8.1  HCoIPsec Transport Mode SAs

   Many of the current HC profiles look to simultaneously compress
   network and transport layer headers of IP packets.  This makes the
   extension of traditional HC schemes over transport-mode SAs more
   difficult.  For the application of HC over transport mode SAs,
   traditional HC schemes may need to be extended to operate strictly on
   layer 4 (e.g., TCP, and/or RTP/UDP) headers.  The methodology and



Ertekin, et al.            Expires May 6, 2006                 [Page 11]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


   specification for HCoIPsec transport mode SAs is left for further
   study.

8.2  Multiplexing of Compressed Packets in IPsec Tunnels

   It should also be noted that a packet concatenation (or multiplexing)
   scheme may be added in conjunction to HCoIPsec to further reduce the
   overall overhead of packets traversing between IPsec devices.  This
   type of functionality is similar to AAL2 voice trunking, where voice
   packets from different sources are placed into one cell [AAL2].  As
   described in [AAL2], a multiplexer concatenates cells until one of
   following two events occur:
   o  the first event indicates that the maximum size of multiplexed
      cell is reached;
   o  the second event indicates that a timer has expired: this timer
      provides an upper bound on the amount of delay a cell may exhibit.
   When either of these events are triggered, the multiplexer transmits
   the multiplexed cells.

   [TCRTP] is one proposal to reduce the packet overhead used between
   call gateways in an unencrypted network.  In a similar fashion, if
   multiple compressed flows are mapped to one SA between two IPsec
   devices, then compressed packets MAY be concatenated with one
   another, encrypted, and subsequently tunneled to the destination
   IPsec device with one ESP/IP header.  It should be noted, however,
   that a multiplexing functionality may be undesirable for the high BER
   networks, as multiplexing scheme may increase average packet sizes,
   which may result in a greater IPLR.  The specification of such a
   protocol is left for further study.

9.  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 ones emitted from the
   end-hosts.  In such a scenario, the invalid packets will pass the
   inbound IPsec process, and will subsequently be validly decompressed.

   Furthermore, an intruder who has the ability to arbitrarily inject
   packets between SA endpoints, and addresses these malicious packets
   to the encryption/decryption devices, has the ability to cause
   context corruption between the compressor and decompressor processes
   instantiated within the IPsec device (if the malicious packet passes
   through the decryption process).  Such a scenario will result in a
   decreased efficiency between compressor and decompressor, and
   furthermore, may result in Denial of Service, as the decompression of
   a significant number of invalid packets may drain the resources of an



Ertekin, et al.            Expires May 6, 2006                 [Page 12]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


   IPsec device.

      Note: It should be noted, however, that these security issues are
      a direct offset of IPsec vulnerabilities.

10.  IANA Considerations

   None.

11.  Acknowledgments

   The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler,
   of the Department of Defense, and Mr. A. Rich Espy of OPnet for their
   contributions and support for developing this document.  The authors
   would also like to thank Mr. Jan Vilhuber, Mr. Dan Wing, of Cisco
   Systems, Mr. Lars-Erik Jonsson and Mr. Kristopher Sandlund of
   Ericsson for their valuable contributions to this document.  The
   authors would also like to thank Ms. Renee Esposito, Mr. Etzel
   Brower, Mr. Jigar Amroliwala, and Mr. Dwayne Corbin of Booz Allen
   Hamilton for their assistance in completing this work.

12.  References

12.1  Normative References

   [IPSEC]    Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", work in progress , March 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.



Ertekin, et al.            Expires May 6, 2006                 [Page 13]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


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

   [ROHCWEXT]
              Pelletier, G. and et. al, "ROHC over Channels That Can
              Reorder Packets", work in progress , February 2005.

12.2  Informative References

   [ESP]      Kent, S., "IP Encapsulating Security Payload", work in
              progress , March 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",
              work in progress , December 2004.

   [AAL2]     ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2
              AAL", I.363.2 , September 1997.

   [TCRTP]    Thompson, B., "Tunneling of Multiplexed Compressed RTP",
              work in progress , September 2004.


Authors' Addresses

   Emre Ertekin
   Booz Allen Hamilton
   8283 Greensboro Drive
   McLean, VA  22102
   US

   Email: ertekin_emre@bah.com











Ertekin, et al.            Expires May 6, 2006                 [Page 14]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


   Chris Christou
   Booz Allen Hamilton
   8283 Greensboro Drive
   McLean, VA  22102
   US

   Email: christou_chris@bah.com


   Rohan Jasani
   Booz Allen Hamilton
   8283 Greensboro Drive
   McLean, VA  22102
   US

   Email: jasani_rohan@bah.com



































Ertekin, et al.            Expires May 6, 2006                 [Page 15]


Internet-Draft      Integration of HC over IPsec SAs       November 2005


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 (2005).  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 May 6, 2006                 [Page 16]


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