One document matched: draft-ietf-rohc-hcoipsec-11.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 tocindent='no'?>
<?rfc symrefs='yes'?>
<?rfc compact='yes'?>
<rfc ipr="pre5378Trust200902" category="info" docName="draft-ietf-rohc-hcoipsec-11" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="Integration of ROHC over IPsec SAs">Integration of Robust Header Compression (ROHC) over IPsec Security Associations</title>
<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="R." surname="Jasani" fullname="Rohan Jasani">
<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>ro@breakcheck.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>
<date month="August" year="2009" />
<abstract>
<t>
IP Security (IPsec) provides various security services for IP
traffic. However, the benefits of IPsec come at the cost of
increased overhead. This document outlines a framework for
integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec).
By compressing the inner headers of IP packets, ROHCoIPsec proposes
to reduce the amount of overhead associated with the transmission of
traffic over IPsec Security Associations (SAs).
</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>
This document outlines a framework for integrating ROHC [ROHC] over
IPsec [IPSEC] (ROHCoIPsec). The goal of ROHCoIPsec is to reduce the
protocol overhead associated with packets traversing between IPsec SA
endpoints. This can be achieved by compressing the transport layer
header (e.g., UDP, TCP, etc.) and inner IP header of packets at the
ingress of the IPsec tunnel, and decompressing these headers at the
egress.
</t>
<t>
For ROHCoIPsec, this document assumes that ROHC will be used to
compress the inner headers of IP packets traversing an IPsec tunnel.
However, since current specifications for ROHC detail its operation
on a hop-by-hop basis, it requires extensions to enable its
operation over IPsec SAs. These extensions need to account for increased
packet reordering and packet loss that may occur in the unprotected domain.
This document outlines a framework for extending the usage of ROHC to
operate at IPsec SA endpoints.
</t>
<t>
ROHCoIPsec targets the application of ROHC to tunnel mode SAs.
Transport mode SAs only encrypt/authenticate the payload of an IP
packet, leaving the IP header untouched. Intermediate routers
subsequently use this IP header to route the packet to a decryption
device. Therefore, if ROHC is to operate over IPsec transport-mode
SAs, (de)compression functionality can only be applied to the
transport layer headers, and not to the IP header. Because current
ROHC specifications do not include support for the compression of
transport layer headers alone, the ROHCoIPsec framework outlined by
this document describes the application of ROHC to tunnel mode SAs.
</t>
</section>
<section title="Audience" toc="default">
<t>
The authors target members of both the ROHC and IPsec communities who
may consider extending the ROHC and IPsec protocols to meet the
requirements put forth in this document. In addition, this document
is directed towards vendors developing IPsec devices that will be
deployed in bandwidth-constrained IP networks.
</t>
</section>
<section title="Terminology" toc="default">
<t>Terminology specific to ROHCoIPsec is introduced in this section.</t>
<t>ROHC Process</t>
<t>
<list>
<t>Generic reference to a ROHC instance (as defined in [ROHC-TERM]), or any supporting ROHC components.</t>
</list>
<t>Compressed Traffic</t>
<t>
<list>
<t>Traffic that is processed through the ROHC compressor and decompressor instances. Packet headers are compressed and decompressed using a specific header compression profile. </t>
</list>
</t>
<t>Uncompressed Traffic</t>
<t>
<list>
<t>Traffic that is not processed by the ROHC compressor instance. Instead, this type of traffic bypasses the ROHC process.</t>
</list>
</t>
</t>
<t>IPsec Process</t>
<t>
<list>
<t>Generic reference to the Internet Protocol Security (IPsec) process.</t>
</list>
</t>
<t>Next Header</t>
<t>
<list>
<t>Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) field.</t>
</list>
</t>
</section>
<section title="Problem Statement: IPsec Packet Overhead" toc="default">
<t>
IPsec mechanisms provide various security services for IP networks.
However, the benefits of IPsec come at the cost of increased per-
packet overhead. For example, traffic flow confidentiality
(generally leveraged at security gateways) requires the tunneling of
IP packets between IPsec implementations. Although these IPsec
tunnels will effectively mask the source-destination patterns that an
intruder can ascertain, tunneling comes at the cost of increased per-
packet overhead. Specifically, an ESP tunnel mode SA applied to an
IPv6 flow results in at least 50 bytes of additional overhead per
packet. This additional overhead may be undesirable for many
bandwidth-constrained wireless and/or satellite communications
networks, as these types of infrastructure are not overprovisioned.
ROHC applied on a per-hop basis over bandwidth-constrained links will
also suffer from reduced performance when encryption is used on the
tunneled header, since encrypted headers cannot be compressed.
Consequently, the additional overhead incurred by an IPsec tunnel may
result in the inefficient utilization of bandwidth.
</t>
<t>
Packet overhead is particularly significant for traffic profiles
characterized by small packet payloads (e.g. various voice codecs).
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.
</t>
</section>
<section title="Overview of the ROHCoIPsec Framework" toc="default">
<section title="ROHCoIPsec Assumptions" toc="default">
<t>
The goal of ROHCoIPsec is to provide efficient transport of IP
packets between IPsec devices without compromising the security
services offered by IPsec. The ROHCoIPsec framework has
been developed based on the following assumptions:
</t>
<list style="symbols">
<t>
ROHC will be leveraged to reduce the amount of overhead associated with packets traversing an IPsec SA
</t>
</list>
<list style="symbols">
<t>
ROHC will be instantiated at the IPsec SA endpoints, and will be applied on a per-SA basis
</t>
</list>
<list style="symbols">
<t>
Once the decompression operation completes, decompressed packet headers will be identical to the original packet headers before compression
</t>
</list>
</section>
<section title="Summary of the ROHCoIPsec Framework" toc="default">
<t>
ROHC reduces packet overhead in a network by exploiting intra- and
inter-packet redundancies of network and transport-layer header
fields of a flow.
</t>
<t>Current ROHC protocol specifications compress packet headers on a hop-by-hop basis. However, IPsec SAs are instantiated between two IPsec endpoints. Therefore, various extensions to both ROHC and IPsec need to be defined to ensure the successful operation of the ROHC protocol at IPsec SA endpoints. </t>
<t>The specification of ROHC over IPsec SAs is straightforward, since SA endpoints provide source/destination pairs where (de)compression operations can take place. Compression of the inner IP and upper layer protocol headers in such a manner offers a reduction of per-packet protocol overhead between the two SA endpoints. Since ROHC will now operate between IPsec endpoints (over multiple intermediate nodes which are transparent to an IPsec SA), it is imperative to ensure that its performance will not be severely impacted due to increased packet reordering and/or packet loss between the compressor and decompressor.</t>
<t>
In addition, ROHC can no longer rely on the underlying link layer for
ROHC channel parameter configuration and packet identification. The
ROHCoIPsec framework proposes that ROHC channel parameter
configuration is accomplished by an SA management protocol (e.g.,
IKEv2 [IKEV2]), while identification of compressed header packets is
achieved through the Next Header field of the security protocol
(e.g., AH [AH], ESP [ESP]) header.
</t>
<t>Using the ROHCoIPsec framework proposed below, outbound and inbound IP traffic processing at an IPsec device needs to be modified. For an outbound packet, a ROHCoIPsec implementation will compress appropriate packet headers, and subsequently encrypt and/or integrity-protect the packet. For tunnel mode SAs, compression may be applied to the transport layer and the inner IP headers. For inbound packets, an IPsec device must first decrypt and/or integrity-check the packet. Then decompression of the inner packet headers is performed. After decompression, the packet is checked against the access controls imposed on all inbound traffic associated with the SA (as specified in [IPSEC]).
</t>
<t>
<list style="empty">
<t>Note: Compression of inner headers is independent from compression of the security protocol (e.g., ESP) and outer IP headers. ROHC profiles have been defined to allow for the compression of the security protocol and the outer IP header on a hop-by-hop basis. The applicability of ROHCoIPsec and hop-by-hop ROHC on an IPv4 ESP-processed packet [ESP] is shown below in Figure 1.</t>
<t><figure title="" suppress-title="false" align="center" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<![CDATA[
-----------------------------------------------------------
IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<-------(1)------->|<------(2)-------->|
(1) Compressed by ROHC ESP/IP profile
(2) Compressed by ROHCoIPsec TCP/IP profile
]]></artwork></figure></t>
<t><postamble>Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an IPv4 ESP-processed packet.</postamble></t>
</list>
</t>
<t>If IPsec NULL encryption is applied to packets, ROHC may still be applied to the inner headers at the IPsec SA endpoints. However, this poses challenges for intermediary devices (within the unprotected domain) inspecting ESP-NULL encrypted packets, since these intermediary devices will require additional functionality to determine the content of the ROHC packets.</t>
</section>
</section>
<section title="Details of the ROHCoIPsec Framework" toc="default">
<section title="ROHC and IPsec Integration" toc="default">
<t>
Figure 2 illustrates the components required to integrate ROHC with
the IPsec process, i.e., ROHCoIPsec.
</t>
<t>
<figure title="" suppress-title="false" align="center" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[
+-------------------------------+
| ROHC Module |
| |
| |
+-----+ | +-----+ +---------+ |
| | | | | | ROHC | |
--| A |---------| B |-----| Process |------> Path 1
| | | | | | | | (ROHC-enabled SA)
+-----+ | +-----+ +---------+ |
| | | |
| | |-------------------------> Path 2
| | | (ROHC-enabled SA)
| +-------------------------------+
|
|
|
|
+-----------------------------------------> Path 3
(ROHC-disabled SA)
]]></artwork>
<postamble> Figure 2. Integration of ROHC with IPsec.</postamble>
</figure>
</t>
<t>The process illustrated in Figure 2 augments the IPsec processing
model for outbound IP traffic (protected-to-unprotected). Initial
IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1).</t>
<t>Block A: The ROHC data item (part of the SA state information) retrieved from
the "relevant SAD entry" ([IPSEC], Section 5.1, Step3a) determines if
the traffic traversing the SA is handed to the ROHC module. Packets selected to a ROHC-disabled SA must
follow normal IPsec processing and must not be sent to the ROHC
module (Figure 1, Path 3). Conversely, packets selected to a ROHC-enabled
SA must be sent to the ROHC module.</t>
<t>Block B: This step determines if the packet can be compressed. If it is determined
that the packet will be compressed, an Integrity Algorithm may be used to
compute an Integrity Check Value (ICV) for the uncompressed packet
([IPSEC-ROHC], Section 3.2 [IKE-ROHC], Section 2.1). The Next Header field of the security protocol header
(e.g., ESP, AH) is populated with a "ROHC" protocol number [PROTOCOL],
inner packet headers are compressed, and the computed ICV, if present,
is appended to the packet (Figure 1, Path 1).
However, if it is determined that the packet will not be compressed (e.g., due to one
the reasons described in Section 6.1.3), the Next Header field is
populated with the appropriate value indicating the next level
protocol (Figure 1, Path 2), and no ROHC processing is applied to the packet.</t>
<t>After the ROHC process completes, IPsec
processing resumes, as described in Section 5.1, Step3a, of [IPSEC].</t>
<t>The process illustrated in Figure 2 also augments the IPsec
processing model for inbound IP traffic (unprotected-to-protected).
For inbound packets, IPsec processing is performed ([IPSEC], Section
5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section
5.2, Step 4).</t>
<t>Block A: After AH or ESP processing, the ROHC data item
retrieved from the SAD entry will indicate if traffic traversing the
SA is processed by the ROHC module ([IPSEC], Section 5.2, Step 3a).
Packets traversing an ROHC-disabled SA must follow normal IPsec
processing and must not be sent to the ROHC module. Conversely,
packets traversing an ROHC-enabled SA must be sent to the ROHC
module.</t>
<t>Block B: The decision at Block B is determined by the value of the
Next Header field of the security protocol header. If the
Next Header field does not indicate a ROHC header, the decompressor
must not attempt decompression (Figure 1, Path 2). If the Next Header
field indicates a ROHC header, decompression is applied. After decompression,
the signaled ROHCoIPsec Integrity Algorithm, if present, is used to
compute an ICV value for the decompressed packet. This ICV, if present, is
compared to the ICV that was calculated at the compressor: if the ICVs match, the packet
is forwarded by the ROHC module (Figure 1, Path 1); otherwise, the packet is dropped.
Once the ROHC module completes processing, IPsec processing resumes, as described
in Section 5.2, Step 4 of [IPSEC].</t>
<t>When there is a single SA between a compressor and decompressor,
ROHC operates in unidirectional mode, as described in Section 5 of
[ROHC-TERM]. When there is pair of SAs instantiated between
ROHCoIPsec implementations, ROHC may operate in bidirectional mode,
where an SA pair represents a bidirectional ROHC channel (as
described in Section 6.1 and 6.2 of [ROHC-TERM]).</t>
<t>Note that to further reduce the size of an IPsec-protected packet,
ROHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested
fashion. This process is detailed in [IPSEC-ROHC], Section 3.2.
</t>
<section title="Header Compression Protocol Considerations" toc="default">
<t>ROHCv2 [ROHCV2] profiles include various mechanisms that provide
increased robustness over reordering channels. These mechanisms must
be adopted for ROHC to operate efficiently over IPsec SAs.</t>
<t> A ROHC decompressor
implemented within IPsec architecture may leverage additional
mechanisms to improve performance over reordering channels (either
due to random events, or to an attacker intentionally reordering
packets). Specifically, IPsec's sequence number may be used by the
decompressor to identify a packet as "sequentially late". This
knowledge will increase the likelihood of successful decompression of
a reordered packet.</t>
<t>Additionally, ROHCoIPsec implementations should minimize the amount
of feedback sent from the decompressor to the compressor. If a ROHC
feedback channel is not used sparingly, the overall gains from
ROHCoIPsec can be significantly reduced. More specifically, any
feedback sent from the decompressor to the compressor must be
processed by IPsec, and tunneled back to the compressor (as
designated by the SA associated with FEEDBACK_FOR). As such, some
implementation alternatives can be considered, including the following:
<list style="symbols"><t>Eliminate feedback traffic altogether by operating only in ROHC Unidirectional mode (U-mode)</t></list>
<list style="symbols"><t>Piggyback ROHC feedback messages within the feedback element (i.e., on ROHC traffic that normally traverses the SA designated by FEEDBACK_FOR).</t></list></t>
</section>
<section title="Initialization and Negotiation of the ROHC Channel" toc="default">
<t>
Hop-by-hop ROHC typically uses the underlying link layer (e.g., PPP) to negotiate ROHC
channel parameters. In the case of ROHCoIPsec, channel parameters
can be set manually (i.e., administratively
configured for manual SAs), or negotiated by IKEv2. The extensions required for IKEv2 to support ROHC
channel parameter negotiation are detailed in [IKE-ROHC].
</t>
<t>
If the ROHC protocol requires bidirectional communications, two SAs
must be instantiated between the IPsec implementations. One of the
two SAs is used for carrying ROHC-traffic from the compressor to the
decompressor, while the other is used to communicate ROHC-feedback
from the decompressor to the compressor. Note that the requirement
for two SAs aligns with the operation of IKE, which creates SAs in
pairs by default. However, IPsec implementations will dictate how decompressor
feedback received on one SA is associated with a compressor on the
other SA. An IPsec implementation must relay the feedback
received by the decompressor on an inbound SA to the compressor
associated with the corresponding outbound SA.
</t>
</section>
<section title="Encapsulation and Identification of Header Compressed Packets" toc="default">
<t>
As indicated in Section 6.1, new state information (i.e., a new ROHC
data item) is defined for each SA. The ROHC data item is used by the
IPsec process to determine whether it sends all traffic traversing a
given SA to the ROHC module (ROHC-enabled) or bypasses the ROHC
module and sends the traffic through regular IPsec processing (ROHC-
disabled).
</t>
<t>
The Next Header field of the IPsec security protocol (e.g., AH or
ESP) header is used to demultiplex header-compressed traffic from
uncompressed traffic traversing an ROHC-enabled SA. This
functionality is needed in situations where packets traversing a
ROHC-enabled SA contain uncompressed headers. Such situations
may occur when, for example, a compressor supports strictly n
compressed flows and cannot compress the n+1 flow that arrives.
Another example is when traffic is selected
to a ROHC-enabled SA, but cannot be compressed by the ROHC process
because the appropriate ROHC Profile has not been signaled for use.
As a result, 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 and uncompressed packets where the ROHC protocol
number will indicate that the packet contains compressed headers. To
accomplish this, an official IANA allocation from the Protocol ID
registry [PROTOCOL] is required.
</t>
<t>
The ROHC Data Item, IANA Protocol ID allocation, and other IPsec
extensions to support ROHCoIPsec, are specified in [IPSEC-ROHC].
</t>
</section>
<section title="Path MTU Considerations" toc="default">
<t>By encapsulating IP packets with AH/ESP and tunneling IP headers, IPsec increases the size of IP packets. This increase
may result in Path MTU issues in the unprotected domain. Several approaches to resolving these path MTU issues
are documented in Section 8 of [IPSEC]; approaches include fragmenting the packet before or after
IPsec processing (if the packet's DF bit is clear), or possibly discarding packets (if the packet's DF bit is set).</t>
<t>The addition of ROHC within the IPsec processing model may result in a similar path MTU challenges. For example, under certain circumstances,
ROHC headers are larger than the original uncompressed headers. In addition, if an integrity algorithm is used to validate packet headers
post-decompression, this integrity algorithm will increase the size of packets. Both of these properties of ROHCoIPsec increase the size of
packets, and therefore may result in additional challenges associated with path MTU.</t>
<t>Approaches to addressing these ROHCoIPsec path MTU issues are specified in Section 3.3 of [IPSEC-ROHC].</t>
</section>
</section>
<section title="ROHCoIPsec Framework Summary" toc="default">
<t>To summarize, the following items are needed to achieve ROHCoIPsec:</t>
<list style="symbols">
<t>IKEv2 Extensions to Support ROHCoIPsec</t>
<t>IPsec Extensions to Support ROHCoIPsec</t>
</list>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>
A malfunctioning ROHC compressor (i.e., the compressor located at the
ingress of the IPsec tunnel) has the ability to send packets to the
decompressor (i.e., the decompressor located at the egress of the
IPsec tunnel) that do not match the original packets emitted from the
end-hosts. Such a scenario will result in a decreased efficiency
between compressor and decompressor. Furthermore, this may result in
Denial of Service, as the decompression of a significant number of
invalid packets may drain the resources of an IPsec device.
</t>
</section>
<section title="IANA Considerations" toc="default">
<t>None.</t>
</section>
<section title="Acknowledgments" toc="default">
<t>
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.</t>
<t>The authors would also like to thank Mr. Yoav Nir, and Mr.
Robert A Stangarone Jr.: both served as committed document reviewers
for this specification.</t>
<t>In addition, the authors would like to
thank the following for their numerous reviews and comments to this
document:
</t>
<t>
<list style="symbols">
<t>Mr. Magnus Westerlund</t>
<t>Dr. Stephen Kent </t>
<t>Mr. Pasi Eronen</t>
<t>Dr. Joseph Touch</t>
<t>Mr. Tero Kivinen</t>
<t>Dr. Jonah Pezeshki</t>
<t>Mr. Lars-Erik Jonsson</t>
<t>Mr. Jan Vilhuber</t>
<t>Mr. Dan Wing</t>
<t>Mr. Kristopher Sandlund</t>
<t>Mr. Ghyslain Pelletier</t>
</list>
</t>
<t>
Finally, the authors would also like to thank Mr. Tom Conkle, Ms.
Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen
Hamilton for their assistance in completing this work.
</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="ROHC">
<front>
<title> The RObust Header Compression (ROHC) Framework</title>
<author initials="L-E." surname="Jonsson" fullname="L-E. Jonsson">
<organization/>
</author>
<author initials="G." surname="Pelletier" fullname="G. Pelletier">
<organization/>
</author>
<author initials="K." surname="Sandlund" fullname="K. Sandlund">
<organization/>
</author>
<date month="July" year="2007"/>
</front>
<seriesInfo name="RFC" value="4995"/>
</reference>
<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-TERM">
<front>
<title>Robust Header Compression (ROHC): Terminology and Channel Mapping Examples</title>
<author initials="L-E." surname="Jonsson" fullname="L-E. Jonsson">
<organization />
</author>
<date month="April" year="2004" />
</front>
<seriesInfo name="RFC" value="3759" />
</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="ESP">
<front>
<title>IP Encapsulating Security Payload (ESP)</title>
<author initials="S." surname="Kent" fullname="S. Kent">
<organization />
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="RFC" value="4303" />
</reference>
<reference anchor="AH">
<front>
<title>IP Authentication Header</title>
<author initials="S." surname="Kent" fullname="S. Kent">
<organization />
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="RFC" value="4302" />
</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="ROHCV2">
<front>
<title>RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP Lite</title>
<author initials="G." surname="Pelletier">
<organization />
</author>
<author initials="K." surname="Sandlund">
<organization />
</author>
<date month="April" year="2008" />
</front>
<seriesInfo name="RFC" value="5225" />
</reference>
<reference anchor="IKE-ROHC">
<front>
<title>IKEv2 Extensions to Support ROHCoIPsec</title>
<author initials="E." surname="Ertekin">
<organization />
</author>
<author initials="C." surname="Christou">
<organization />
</author>
<author initials="R." surname="Jasani">
<organization />
</author>
<author initials="T." surname="Kivinen">
<organization />
</author>
<author initials="C." surname="Bormann">
<organization />
</author>
<date month="August" year="2009" />
</front>
<seriesInfo name="work in progress" 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>
<reference anchor="IPSEC-ROHC">
<front>
<title>IPsec Extensions to Support ROHCoIPsec</title>
<author initials="E." surname="Ertekin">
<organization />
</author>
<author initials="C." surname="Christou">
<organization />
</author>
<author initials="C." surname="Bormann">
<organization />
</author>
<date month="August" year="2009" />
</front>
<seriesInfo name="work in progress" value="" />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 10:39:41 |