One document matched: draft-ietf-rohc-ipsec-extensions-hcoipsec-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt'?>
<?rfc toc='yes'?>
<?rfc tocompact='yes'?>
<?rfc tocdepth='6'?>
<?rfc symrefs='yes'?>
<?rfc compact='yes'?>
<rfc ipr="full3978" docName="draft-ietf-rohc-ipsec-extensions-hcoipsec-02">
<front>
<title abbrev="IPsec Extensions to Support RoHCoIPsec">IPsec Extensions to Support Robust Header Compression over IPsec (RoHCoIPsec)</title>
<date month="August" year="2008"/>
<author initials="E." surname="Ertekin" fullname="Emre Ertekin">
<organization>Booz Allen Hamilton</organization>
<address>
<postal>
<street>13200 Woodland Park Dr.</street>
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<email>ertekin_emre@bah.com</email>
</address>
</author>
<author initials="J." surname="Pezeshki" fullname="Jonah Pezeshki">
<organization>Booz Allen Hamilton</organization>
<address>
<postal>
<street>13200 Woodland Park Dr.</street>
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<email>pezeshki_jonah@bah.com</email>
</address>
</author>
<author initials="M." surname="Casey" fullname="Michele Casey">
<organization>Booz Allen Hamilton</organization>
<address>
<postal>
<street>13200 Woodland Park Dr.</street>
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<email>casey_michele@bah.com</email>
</address>
</author>
<author initials="C." surname="Christou" fullname="Chris Christou">
<organization>Booz Allen Hamilton</organization>
<address>
<postal>
<street>13200 Woodland Park Dr.</street>
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<email>christou_chris@bah.com</email>
</address>
</author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universitaet Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen D-28334</city>
<country>Germany</country>
</postal>
<email>cabo@tzi.org</email>
</address>
</author>
<abstract>
<t>
Integrating RoHC with IPsec (RoHCoIPsec) offers the combined benefits
of IP security services and efficient bandwidth utilization. However,
extensions to the SPD and SAD are required in order to integrate RoHC
with IPsec. This document describes the IPsec extensions required
to support RoHCoIPsec.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Using IPsec ([IPSEC]) protection offers various security services for
IP traffic. However, these
benefits come at the cost of additional packet headers, which
increase packet overhead. As described in [ROHCOIPSEC], Robust
Header Compression (RoHC [ROHC]) can be used with IPsec to reduce the
overhead associated with IPsec-protected packets.
</t>
<t>
IPsec-protected traffic is carried over Security
Associations (SAs), whose parameters are negotiated on a case-by-case
basis. The Security Policy Database (SPD) specifies the services
that are to be offered to IP datagrams, and the parameters associated
with SAs that have been established are stored in the Security
Association Database (SAD). To integrate RoHC and IPsec,
various extensions to the SPD and SAD that incorporate RoHC-relevant
parameters are required.
</t>
<t>
In addition, three extensions to IPsec processing are
required. First, a mechanism for identifying RoHC packets must be
defined. Second, a mechanism is required to ensure the integrity of the
decompressed packet. Finally, the order of the inbound and outbound
processing must be enumerated when nesting IP Compression (IPComp [IPCOMP]), RoHC, and IPsec processing.
</t>
</section>
<section title="Extensions to IPsec Databases">
<t>
The following subsections specify extensions to the SPD and the SAD
to support RoHCoIPsec.
</t>
<section title="Security Policy Database (SPD)">
<t>
In general, the SPD is responsible for specifying the security
services that are offered to IP datagrams. Entries in the SPD
specify how to derive the corresponding values for SAD entries. To
support RoHC, the SPD must be extended to include per-channel RoHC
parameters. Together, the existing IPsec SPD parameters and the
RoHC parameters will dictate the services that are provided to
packets protected by IPsec.
</t>
<t>
The fields contained within each SPD entry are defined in [IPSEC],
Section 4.4.1.2. To support RoHC, several processing info fields
must be added to the SPD; these fields contain information regarding
the RoHC profiles and channel parameters supported by the local RoHC
instance.
</t>
<t>
The SPD specifies what services are to be offered to IP datagrams,
and in what fashion. To offer IP datagrams compression services,
the per-channel configuration parameters, defined in [ROHC], are
added to the SPD. Specifically, the following parameters must be
included if the processing info field in the SPD is set to PROTECT (suggested values for these parameters are consistent with [ROHCPPP]):
</t>
<t></t>
<list style="empty">
<t>
MAX_CID: The highest context ID number to be used by the compressor.
MAX_CID must be at least 0 and at most 16383 (The value 0 implies having one context). The suggested value for MAX_CID is 15.
</t>
</list>
<t></t>
<list style="empty">
<t>
PROFILES: This indicates the RoHC profiles supported by the
decompressor. The list of possible values this field may assume
is defined in the [ROHCPROF] registry.
</t>
</list>
<t></t>
<list style="empty">
<t>
MRRU: The size of the largest reconstructed unit that the
decompressor is expected to reassemble from segments. In general,
it is not anticipated that a RoHCoIPsec instance will use RoHC
segmentation. Consequently, the suggested value for MRRU
is 0.
</t>
</list>
<t></t>
<list style="empty">
<t>
MAX_HEADER: The largest header size (in octets) that can be
compressed. Note that the four RoHC profiles defined in RFC 3095
do not provide for a MAX_HEADER parameter. The parameter
MAX_HEADER is therefore without consequence in these profiles.
Other profiles (e.g., ones based on RFC 2507) can make use of the
parameter by explicitly referencing it.
</t>
</list>
<t></t>
<t>
Note: The RoHC LARGE_CIDS channel parameter is set implicitly, based
on the value of MAX_CID. Furthermore, if a SA in the reverse direction
exists, the RoHC FEEDBACK_FOR channel parameter is set implicitly to
the RoHC channel associated with the SA in the reverse direction. If
a SA in the reverse direction does not exist, RoHC must
operate in the Unidirectional Mode. Because both of these RoHC channel
parameters are set implicitly, they are not stored in the SPD.
</t>
<t>
In addition to these RoHC channel parameters, a field within the SPD
entry is required to store a list of integrity algorithms supported
by the RoHCoIPsec instance. This integrity algorithm will be used by
the RoHC process to ensure that packet headers are properly
decompressed (see Section 3.2).
</t>
</section>
<section title="Security Association Database (SAD)">
<t>
Each entry within the SAD defines the parameters associated with each
established SA. Unless if the "populate from packet" (PFP) flag is
asserted for a particular field, SAD entries are determined by the
corresponding SPD entries during the creation of the SA.
</t>
<t>
The data items contained within the SAD are defined in [IPSEC],
Section 4.4.2.1. To support RoHC, this list of data items is
augmented to include a "RoHC Data Item" field that defines the RoHC
parameters. These parameters (i.e., MAX_CID, PROFILES, MRRU, and
MAX_HEADER) are enumerated above in Section 2.1. In addition, the
FEEDBACK_FOR parameter is also included, which is associated with the
SA in the reverse direction (this data item does not need to be included
in the SPD, since its value is implicitly derived). Finally, two
additional data items
are required to store the Integrity Algorithm and respective key that
is to be used to ensure that packets are properly decompressed
(see Section 3.2). </t>
<t>These "RoHC Data Item" values
may be initialized manually (i.e., administratively configured for
manual SAs), or initialized via a key exchange protocol (e.g. IKEv2
[IKEV2]) that has been extended to support the negotiation of RoHC
parameters [IKEV2EXT].
</t>
</section>
</section>
<section title="Extensions to IPsec Processing">
<section title="Addition to the IANA Protocol Numbers Registry">
<t>
In order to demultiplex header-compressed from uncompressed traffic
on a RoHC-enabled SA, a "RoHC" value must be reserved in the IANA
Protocol Numbers registry. If an outbound packet has a compressed
header, the Next Header field of the security protocol header (e.g.,
AH [AH], ESP [ESP]) must be set to the "RoHC" protocol identifer. If
the packet header has not been compressed, the Next Header field
remains unaltered. Conversely, for an inbound packet, the value of
the security protocol Next Header field is checked to determine if
the packet includes a RoHC header.
</t>
</section>
<section title="Verifying the Integrity of Decompressed Packet Headers">
<t>
Since RoHC is inherently a lossy algorithm, RoHCoIPsec will use an additional Integrity Algorithm (and respective
key) to compute a second Integrity Check Value (ICV) for the
uncompressed packet. Specifically, this ICV will be computed for the uncompressed IP header, as well at the higher-layer headers and the packet payload. This ICV will be appended to the RoHC-compressed packet. At the decompressor, the
decompressed packet (including the uncompressed IP header, higher-layer headers, and packet payload; but not including the authentication data) will be used with the Integrity Algorithm (and
its respective key) to compute a value that will be compared to the
ICV. If these values are not identical, the decompressed packet must
be dropped by the decompressor.
</t>
<t>Figure 1 illustrates the composition of a RoHCoIPsec-processed IPv4 packet. In the example, TCP/IP compression is applied, and the packet is processed with tunnel mode ESP.</t>
<figure>
<preamble> </preamble>
<artwork><![CDATA[
BEFORE COMPRESSION AND APPLICATION OF ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER ROHCOIPSEC COMPRESSION AND APPLICATION OF ESP
------------------------------------------------------
IPv4 | new IP hdr | | Cmpr | | RoHC | ESP | ESP|
|(any options)| ESP | Hdr. |Data| ICV |Trailer| ICV|
------------------------------------------------------
]]></artwork>
<postamble>Figure 1. Example of a RoHCoIPsec-processed packet.</postamble>
</figure>
<t>
Note: The authentication data should never be included in the calculation of the ICV.</t>
<section title="ICV Computation and Integrity Verification">
<t>
In order to correctly verify the integrity of the decompressed packets, the processing steps for RoHCoIPsec must be implemented in a specific order, as given below.
</t>
<t>For outbound packets that are to be processed by RoHC:
<list style="symbols">
<t>
An ICV is computed for the uncompressed packet via RoHCoIPsec's Integrity Algorithm (and respective key)
</t>
<t>
The packet is compressed by the RoHC process
</t>
<t>
The ICV is appended to the end of the compressed packet
</t>
<t>
The security protocol is applied to the packet
</t>
</list>
</t>
<t>For inbound packets that are to be decompressed by RoHC:
<list style="symbols">
<t>
A packet received on a RoHC-enabled SA is IPsec-processed
</t>
<t>
The packet is decompressed by the RoHC process
</t>
<t>
The decompressed packet is used with the Integrity Algorithm (and its respective key) to compute a value that is compared to the ICV (if these two values differ, the packet is dropped)
</t>
</list>
</t>
</section>
</section>
<section title="Nested IPComp and RoHCoIPsec Processing">
<t>
IPComp ([IPCOMP]) is another mechanism that can be implemented to
reduce the size of an IP datagram. If IPComp and RoHCoIPsec are
implemented in a nested fashion, the order of the outbound and
inbound processing steps must be carefully enumerated.
</t>
<t>
For outbound packets that are to be processed by IPcomp and RoHC:
<list style="symbols">
<t>
The ICV is computed for the uncompressed packet, and the appropriate RoHC compression profile is applied to the packet
</t>
<t>
IPComp is applied, and the packet is sent to the IPsec process
</t>
<t>
The security protocol is applied to the packet
</t>
</list>
</t>
<t>
Conversely, for inbound packets that are to be both RoHC- and IPcomp-decompressed:
<list style="symbols">
<t>
A packet received on a RoHC-enabled SA is IPsec-processed
</t>
<t>
The datagram is decompressed based on the appropriate IPComp algorithm
</t>
<t>
The packet is sent to the RoHC module for header decompression and integrity verification
</t>
</list>
</t>
</section>
</section>
<section title="Security Considerations">
<t>
A RoHCoIPsec implementer should consider the strength of protection
provided by the integrity check algorithm used to verify the valid
decompression of RoHC-compressed packets. Failure to implement a
strong integrity check algorithm increases the probability of an
invalidly decompressed packet to be forwarded by a RoHCoIPsec device
into a protected domain. In general, if an integrity check algorithm
is used with IPsec, it is recommended that the integrity check
algorithm used by RoHC is at least the same strength.
</t>
<t>
The implementation of RoHCoIPsec may increase the susceptibility for traffic
flow analysis, where an attacker can
identify new traffic flows by monitoring the relative size of the
encrypted packets (i.e. a group of "long" packets, followed by a long
series of "short" packets may indicate a new flow for some RoHCoIPsec
implementations). To mitigate this concern, RoHC padding mechanisms
may be used to arbitrarily add padding to transmitted packets to
randomize packet sizes.
</t>
</section>
<section title="IANA Considerations">
<t>
IANA is requested to allocate one value within the "Protocol Numbers"
registry [PROTOCOL] for "RoHC". This value will be used to indicate
that the next level protocol header is a RoHC header.
</t>
</section>
<section title="Acknowledgments">
<t>
The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler,
Ms. Linda Noone of the Department of Defense, and Mr. A. Rich Espy of
OPnet for their contributions and support for developing this
document. In addition, the authors would like to thank Mr. Rohan
Jasani for his valuable assistance. Finally, the authors would like
to thank the following for their numerous reviews and comments to
this document:
</t>
<t>
<list style="symbols">
<t>Dr. Stephen Kent</t>
<t>Dr. Carsten Bormann</t>
<t>Mr. Lars-Erik Jonnson</t>
<t>Mr. Pasi Eronen</t>
<t>Dr. Joseph Touch</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="IPSEC">
<front>
<title>Security Architecture for the Internet Protocol</title>
<author initials="S." surname="Kent" fullname="S. Kent">
<organization/>
</author>
<author initials="K." surname="Seo" fullname="K. Seo">
<organization/>
</author>
<date month="December" year="2005"/>
</front>
<seriesInfo name="RFC" value="4301"/>
</reference>
<reference anchor="ROHC">
<front>
<title>RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed</title>
<author initials="C." surname="Bormann">
<organization/>
</author>
<author initials="C." surname="Burmeister">
<organization/>
</author>
<author initials="M." surname="Degermark">
<organization/>
</author>
<author initials="H." surname="Fukushima">
<organization/>
</author>
<author initials="H." surname="Hannu">
<organization/>
</author>
<author initials="L." surname="Jonsson">
<organization/>
</author>
<author initials="R." surname="Hakenberg">
<organization/>
</author>
<author initials="T." surname="Koren">
<organization/>
</author>
<author initials="K." surname="Le">
<organization/>
</author>
<author initials="Z." surname="Liu">
<organization/>
</author>
<author initials="A." surname="Martensson">
<organization/>
</author>
<author initials="A." surname="Miyazaki">
<organization/>
</author>
<author initials="K." surname="Svanbro">
<organization/>
</author>
<author initials="T." surname="Wiebke">
<organization/>
</author>
<author initials="T." surname="Yoshimura">
<organization/>
</author>
<author initials="H." surname="Zheng">
<organization/>
</author>
<date month="July" year="2001"/>
</front>
<seriesInfo name="RFC" value="3095"/>
</reference>
<reference anchor="IPCOMP">
<front>
<title>IP Payload Compression Protocol (IPComp)</title>
<author initials="A." surname="Shacham" fullname="A. Shacham">
<organization/>
</author>
<author initials="R." surname="Monsour" fullname="R. Monsour">
<organization/>
</author>
<author intials="R." surname="Pereira" fullname="R. Pereira">
<organization/>
</author>
<author intials="M." surname="Thomas" fullname="M. Thomas">
<organization/>
</author>
<date month="September" year="2001"/>
</front>
<seriesInfo name="RFC" value="3173"/>
</reference>
<reference anchor="ROHCPPP">
<front>
<title>Robust Header Compression (ROHC) over PPP</title>
<author initials="C." surname="Bormann">
<organization/>
</author>
<date month="April" year="2002"/>
</front>
<seriesInfo name="RFC" value="3241"/>
</reference>
<reference anchor="IKEV2">
<front>
<title>Internet Key Exchange (IKEv2) Protocol</title>
<author initials="C." surname="Kaufman">
<organization/>
</author>
<date month="December" year="2005"/>
</front>
<seriesInfo name="RFC" value="4306"/>
</reference>
<reference anchor="IKEV2EXT">
<front>
<title>Extensions to IKEv2 to Support Robust Header Compression over IPsec (RoHCoIPsec)</title>
<author initials="J." surname="Pezeshki">
<organization/>
</author>
<author initials="E." surname="Ertekin">
<organization/>
</author>
<author initials="C." surname="Christou">
<organization/>
</author>
<date month="August" year="2008"/>
</front>
<seriesInfo name="work in progress" value=""/>
</reference>
<reference anchor="AH">
<front>
<title>IP Authentication Header</title>
<author initials="S." surname="Kent">
<organization/>
</author>
<date month="December" year="2005"/>
</front>
<seriesInfo name="RFC" value="4302"/>
</reference>
<reference anchor="ESP">
<front>
<title>IP Encapsulating Security Payload (ESP)</title>
<author initials="S." surname="Kent">
<organization/>
</author>
<date month="December" year="2005"/>
</front>
<seriesInfo name="RFC" value="4303"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="ROHCOIPSEC">
<front>
<title>Integration of Header Compression over IPsec Security Associations</title>
<author initials="E." surname="Ertekin" fullname="E. Ertekin">
<organization/>
</author>
<author initials="C." surname="Christou" fullname="C. Christou">
<organization/>
</author>
<date month="August" year="2008"/>
</front>
<seriesInfo name="work in progress" value=""/>
</reference>
<reference anchor="ROHCPROF">
<front>
<title>RObust Header Compression (ROHC) Profile Identifiers</title>
<author><organization/></author>
<date month="October" year="2005"/>
</front>
<seriesInfo name="www.iana.org/assignments/rohc-pro-ids" value=""/>
</reference>
<reference anchor="PROTOCOL">
<front>
<title>"Assigned Internet Protocol Numbers", IANA registry at: http://www.iana.org/assignments/protocol-numbers</title>
<author surname="IANA">
<organization/>
</author>
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 10:40:14 |