One document matched: draft-ietf-rohc-ipsec-extensions-hcoipsec-08.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="pre5378Trust200902" category="std" docName="draft-ietf-rohc-ipsec-extensions-hcoipsec-08">
<front>
<title abbrev="IPsec Extensions to Support ROHCoIPsec">IPsec Extensions to Support Robust Header Compression over IPsec</title>
<date month="February" year="2010"/>
<author initials="E." surname="Ertekin" fullname="Emre Ertekin">
<organization>Booz Allen Hamilton</organization>
<address>
<postal>
<street>5220 Pacific Concourse Drive, Suite 200</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90045</code>
<country>US</country>
</postal>
<email>ertekin_emre@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 Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) offers the combined benefits
of IP security services and efficient bandwidth utilization. However,
in order to integrate ROHC with IPsec, extensions to the SPD and SAD are required.
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. By compressing the
inner headers of these packets, the integration of Robust Header
Compresion (ROHC, [ROHC]) with IPsec (ROHCoIPsec, [ROHCOIPSEC])
can reduce the packet overhead associated with IPsec-protected flows.
</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). For ROHCoIPsec,
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 to ensure the integrity of the
decompressed packet is needed. 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="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [BRA97].</t>
</section>
<section title="Extensions to IPsec Databases">
<t>
The following subsections specify extensions to the SPD and the SAD
that MUST be supported for ROHCoIPsec. The ROHCoIPsec fields in the SPD are used to
populate the ROHCoIPsec parameters in the SAD during the initialization or rekey of a child SA.
</t>
<t>It is noted that these extensions do not have any implications on existing SPD fields or SAD parameters. Therefore,
a ROHCoIPsec implementation is backwards-compatible with an IPsec implementation that does not support header compression.</t>
<t>Appendix A provides an example ASN.1 representation of a SPD that is extended to support ROHC.</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 is extended to include per-channel ROHC
parameters. Together, the existing IPsec SPD parameters and the
ROHC parameters will dictate the security and header compression services that are provided to
packets.
</t>
<t>
The fields contained within each SPD entry are defined in RFC 4301 [IPSEC],
Section 4.4.1.2. To support ROHC, several processing info fields
are added to the SPD; these fields contain information regarding
the ROHC profiles and channel parameters supported by the local ROHC
instance.</t>
<t>If the processing action associated with the selector sets is PROTECT, then the processing info must be extended with the following ROHC channel parameters:</t>
<t></t>
<list style="empty">
<t>
MAX_CID: The field indicates the highest context ID that will be decompressed by the local decompressor.
MAX_CID MUST be at least 0 and at most 16383 (The value 0 implies having one context).
</t>
</list>
<t></t>
<list style="empty">
<t>
MRRU: The MRRU parameter indicates the size of the largest reconstructed unit (in octets) that
the local decompressor is expected to reassemble from ROHC segments. This size includes the CRC and the ROHC ICV.
NOTE: Since in-order delivery of ROHC packets cannot be guaranteed, the MRRU parameter SHOULD
be set to 0 (as stated in Section 5.2.5.1 of RFC 4995 [ROHC] and Section 6.1 of RFC 5225 [ROHCV2]), which indicates
that no segment headers are allowed on the ROHCoIPsec channel.
</t>
</list>
<t></t>
<list style="empty">
<t>
PROFILES: This field is a list of ROHC profiles supported by the local
decompressor. Possible values for this list
are contained in the ROHC Profile Identifiers registry [ROHCPROF].
</t>
</list>
<t>
In addition to these ROHC channel parameters, a ROHC Integrity Algorithm and a ROHC ICV Length field MUST be included within the SPD:
</t>
<t><list style="empty">
<t> ROHC INTEGRITY ALGORITHM: This field is a list of integrity algorithms supported by the ROHCoIPsec instance. This will be used
by the ROHC process to ensure that packet headers are properly decompressed (see Section 4.2). Authentication algorithms that MUST be supported are specified in the "Authentication Algorithms" table in section 3.1.1 ("ESP Encryption and Authentication Algorithms") of RFC 4835 [CRYPTO-ALG] (or its successor). </t>
<t></t>
<t>ROHC ICV LENGTH: This field specifies the length of the ICV that is used in conjunction with the ROHC Integrity Algorithm.</t>
</list></t>
<t>
Several other ROHC channel parameters are omitted from the SPD,
because they are set implicitly. The omitted channel parameters are
LARGE_CIDS and FEEDBACK_FOR. The LARGE_CIDS channel parameter
MUST be set based on the value of MAX_CID (e.g. if MAX_CID is
<= 15, LARGE_CIDS is assumed to be 0). Finally, the ROHC FEEDBACK_FOR
channel parameter MUST be set to the ROHC channel associated
with the SA in the reverse direction. If an SA in the
reverse direction does not exist, the FEEDBACK_FOR channel parameter
is not set, and ROHC MUST NOT operate in bidirectional Mode.
</t>
</section>
<section title="Security Association Database (SAD)">
<t>
Each entry within the SAD defines the parameters associated with each
established SA. Unless 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 RFC 4301 [IPSEC],
Section 4.4.2.1. To support ROHC, the SAD must include a "ROHC Data Item"; this data item contains parameters used by ROHC instance. The ROHC Data Item exists for both inbound and outbound SAs.
</t>
<t>
The ROHC Data Item includes the ROHC channel parameters for the SA. These channel parameters
(i.e., MAX_CID, PROFILES, MRRU) are enumerated above in Section 3.1. For inbound SAs, the ROHC Data Item
MUST specify the ROHC channel parameters that are used by the local decompressor instance; conversely, for outbound SAs,
the ROHC Data Item MUST specify the ROHC channel parameters that are used by local compressor instance.
</t>
<t>
In addition to these ROHC channel parameters, the ROHC Data Item for both inbound and outbound SAs MUST include three
additional parameters. Specifically, these parameters store the integrity algorithm, the algorithm's respective key, and the ICV length that is used by the ROHC process
(see Section 3.2). The integrity algorithm and its associated key are used to calculate a ROHC ICV of the specified length; this ICV
is used to verify the packet headers post-decompression.
</t>
<t>
Finally, for inbound SAs, the ROHC Data Item MUST include a FEEDBACK_FOR parameter. The parameter is a
reference to a ROHC channel in the opposite direction (i.e., the outbound SA) between the same compression endpoints.
A ROHC channel associated with an inbound SA and a ROHC channel associated with an outbound SA MAY
be coupled to form a Bi-directional ROHC channel as defined in Section 6.1 and Section 6.2 in RFC 3759 [ROHC-TERM].
</t>
<t>"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 signaling of ROHC
parameters [IKEV2EXT].</t>
</section>
</section>
<section title="Extensions to IPsec Processing">
<section title="Identification of Header-Compressed Traffic">
<t>
A "ROHC" protocol identifier is used to identify header-compressed traffic
on a ROHC-enabled SA. 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 identifier.
If the packet header has not been compressed by ROHC, the Next Header
field does not contain the "ROHC" protocol identifier. Conversely,
for an inbound packet, the value of the security protocol Next Header
field MUST be checked to determine if the packet includes a ROHC
header, in order to determine if it requires ROHC decompression.
</t>
<t>
Use of the "ROHC" protocol identifier for purposes other than
ROHCoIPsec is currently not defined. Future protocols
that make use of the allocation (e.g., other applications of ROHC in multi-hop environments)
require specification of the logical compression channel between the ROHC
compressor and decompressor. In addition, these specifications will require
the investigation of the security considerations associated
with use of the "ROHC" protocol identifier outside the context of the next-header
field of security protocol headers.
</t>
</section>
<section title="Verifying the Integrity of Decompressed Packet Headers">
<t>
As documented in Section 6.1.4 of [ROHCOIPSEC], ROHC is inherently a lossy compression
algorithm: the consequences of significant packet reordering or loss between ROHC peers may include
undetected decompression failures, where erroneous packets are forwarded
into the protected domain.
</t>
<t>
To ensure that a decompressed header is identical to the original header, ROHCoIPsec
MAY use an additional Integrity Algorithm (and respective key) to compute a second Integrity
Check Value (ICV). This ROHC ICV MUST be computed over the uncompressed IP header, as well at the
higher-layer headers and the packet payload. When computed, the ICV is 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 appended ICV. If these values
are not identical, the decompressed packet MUST be dropped.
</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: At the decompressor, the ROHC ICV field is not included in the calculation of the ROHC 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 processed by ROHC and IPsec-protected:
<list style="symbols">
<t>
Compute an ICV for the uncompressed packet with the negotiated (ROHC) integrity algorithm and its respective key
</t>
<t>
Compress the packet headers (as specified by the ROHC process)
</t>
<t>
Append the ICV to the compressed packet
</t>
<t>
Apply AH or ESP processing to the packet, as specified in the appropriate SAD entry
</t>
</list>
</t>
<t>For inbound packets that are to be decompressed by ROHC:
<list style="symbols">
<t>
Apply AH or ESP processing, as specified in the appropriate SAD entry
</t>
<t>
Remove the ICV from the packet
</t>
<t>
Decompress the packet header(s)
</t>
<t>
Compute an ICV for the decompressed packet with the negotiated (ROHC) integrity algorithm and its respective key
</t>
<t>
Compare the computed ICV to the original ICV calculated at the compressor: if these two values differ, the packet MUST be dropped; otherwise resume IPsec processing
</t>
</list>
</t>
</section>
</section>
<section title="ROHC Segmentation and IPsec Tunnel MTU">
<t>In certain scenarios, a ROHCoIPsec-processed packet may exceed the size of the IPsec tunnel MTU. RFC 4301 [IPSEC] currently stipulates the following for outbound
traffic that exceeds the SA PMTU:</t>
<t><artwork><![CDATA[ Case 1: Original (cleartext) packet is IPv4 and has the DF
bit set. The implementation should discard the packet
and send a PMTU ICMP message.
Case 2: Original (cleartext) packet is IPv4 and has the DF
bit clear. The implementation should fragment (before or
after encryption per its configuration) and then forward
the fragments. It should not send a PMTU ICMP message.
Case 3: Original (cleartext) packet is IPv6. The implementation
should discard the packet and send a PMTU ICMP message.
]]></artwork></t>
<t>For the ROHCoIPsec processing model, there is one minor change to the
procedure stated above. This change applies to pre-encryption
fragmentation for Case 2. Since current ROHC compression profiles
do not support compression of IP packet fragments, pre-encryption
fragmentation MUST NOT occur before ROHC processing.</t>
<t>If the compressed packet exceeds the SA PMTU, and the MRRU is non-zero,
ROHC segmentation MAY be used to divide the packet, where each segment
conforms to the tunnel MTU. ROHC segmentation MUST occur before
AH or ESP processing. Because in-order delivery of
ROHC segments is not guaranteed, the use of ROHC segmentation is
not recommended.</t>
<t>If segmentation is applied, the process MUST account for the
additional overhead imposed by the IPsec process (e.g., AH or ESP
overhead, crypto synchronization data, the additional IP header,
etc.) such that the final IPsec-processed segments are less than
the tunnel MTU. After segmentation, each ROHC segment is
consecutively processed by the appropriate security
protocol (e.g., AH, ESP) instantiated on the ROHC-enabled SA.
Since ROHC segments are processed consecutively, the associated
AH/ESP sequence number MUST be incremented by one for each segment
transmitted over the ROHC channel. As such, after all ROHC
segments receive AH/ESP processing, these segments can be
identified (at the remote IPsec implementation) by a range of
contiguous AH/ESP sequence numbers.</t>
<t>For channels where the MRRU is non-zero, the ROHCoIPsec decompressor MUST re-assemble the ROHC segments that are received. To accomplish
this, the decompressor MUST identify the ROHC segments (as documented in Section 5.2.6 of RFC 4995 [ROHC]), and attempt reconstruction using the
ROHC segmentation protocol (Section 5.2.5 of RFC 4995 [ROHC]). To assist the reconstruction process, the AH/ESP sequence number SHOULD be used to identify segments that may have been subject to reordering. If
reconstruction fails, the packet MUST be discarded. </t>
<t>As stated in Section 3.2.1, if the ROHC integrity algorithm is used to verify the decompression of packet headers, this ICV is appended to the compressed packet.
If ROHC segmentation is performed, the segmentation algorithm is executed on the compressed packet and the appended ICV. Note that the ICV is not appended to each ROHC segment.</t>
<t>Under certain circumstances, IPsec implementations will not process
(or receive) unprotected ICMP messages, or they will not have a Path
MTU estimate value. In these cases, the IPsec implementation SHOULD
NOT attempt to segment the ROHC-compressed packet, as it does not have
full insight into the path MTU in the unprotected domain.</t>
</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 following steps MUST be followed for outbound and inbound packets.
</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 decompressed headers. Failure to implement a
strong integrity check algorithm increases the probability for an
invalidly decompressed packet to be forwarded by a ROHCoIPsec device
into a protected domain.
</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. This technique, however, reduces the overall
efficiency benefit offered by header compression.
</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. </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>Finally, 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. Lars-Erik Jonsson</t>
<t>Mr. Carl Knutsson</t>
<t>Mr. Pasi Eronen</t>
<t>Dr. Jonah Pezeshki</t>
<t>Mr. Tero Kivinen</t>
<t>Dr. Joseph Touch</t>
<t>Mr. Rohan Jasani</t>
<t>Mr. Elwyn Davies</t>
<t>Mr. Bert Wijnen</t>
</list>
</t>
</section>
</middle>
<back>
<section title="ASN.1 representation for ROHCoIPsec">
<t>This appendix is included as an additional way to describe the ROHCoIPsec
parameters that are included in the IPsec SPD. It uses portions of the ASN.1
syntax provided in Appendix C of RFC 4301 [IPSEC]. In addition, several new
structures are defined.</t>
<t>This syntax has been successfully compiled. However, it is merely illustrative
and need not be employed in an implementation to achieve compliance.</t>
<t>The "Processing" data structure, defined in Appendix C of RFC 4301, is augmented to include
a ROHC parameters element as follows:</t>
<t><artwork><![CDATA[ Processing ::= SEQUENCE {
extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
fragCheck BOOLEAN, -- TRUE stateful fragment checking,
-- FALSE no stateful fragment checking
lifetime SALifetime,
spi ManualSPI,
algorithms ProcessingAlgs,
tunnel TunnelOptions OPTIONAL,
rohc [7] RohcParams OPTIONAL
}]]></artwork></t>
<t>The following data structures describe these ROHC parameters:</t>
<t><artwork><![CDATA[ RohcParams ::= SEQUENCE {
rohcEnabled BOOLEAN, -- TRUE, hdr compr. is enabled
-- FALSE, hdr compr. is disabled
maxCID INTEGER (0..16383),
mrru INTEGER,
profiles RohcProfiles,
rohcIntegAlg RohcIntegAlgs,
rohcIntegICVLength INTEGER
}
RohcProfiles ::= SET OF RohcProfile
RohcProfile ::= INTEGER {
rohcv1-rtp (1),
rohcv1-udp (2),
rohcv1-esp (3),
rohcv1-ip (4),
rohcv1-tcp (6),
rohcv1-rtp-udpLite (7),
rohcv1-udpLite (8),
rohcv2-rtp (257),
rohcv2-udp (258),
rohcv2-esp (259),
rohcv2-ip (260),
rohcv2-rtp-udpLite (263),
rohcv2-udpLite (264)
-- values taken from [ROHCPROF]
}
RohcIntegAlgs ::= SEQUENCE {
algorithm RohcIntegAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
RohcIntegAlgType ::= INTEGER {
none (0),
auth-HMAC-MD5-96 (1),
auth-HMAC-SHA1-96 (2),
auth-DES-MAC (3),
auth-KPDK-MD5 (4),
auth-AES-XCBC-96 (5),
auth-HMAC-MD5-128 (6),
auth-HMAC-SHA1-160 (7),
auth-AES-CMAC-96 (8),
auth-AES-128-GMAC (9),
auth-AES-192-GMAC (10),
auth-AES-256-GMAC (11),
auth-HMAC-SHA2-256-128 (12),
auth-HMAC-SHA2-384-192 (13),
auth-HMAC-SHA2-512-256 (14)
-- tbd (15..65535)
-- values taken from "Transform Type 3 - Integrity
-- Algorithm Transform IDs" at [IKEV2-PARA]
}]]></artwork></t>
</section>
<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> 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="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="BRA97">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization />
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
</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" fullname="G. Pelletier">
<organization/>
</author>
<author initials="K." surname="Sandlund" fullname="K. Sandlund">
<organization/>
</author>
</front>
<seriesInfo name="RFC" value="5225"/>
</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>IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)</title>
<author initials="et al" surname="Ertekin">
<organization/>
</author>
<date month="February" year="2010"/>
</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">
<organization/>
</author>
<author initials="R." surname="Jasani">
<organization/>
</author>
<author initials="C." surname="Christou">
<organization/>
</author>
<author initials="C." surname="Bormann">
<organization/>
</author>
<date month="February" year="2010"/>
</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="May" year="2008"/>
</front>
<seriesInfo name="www.iana.org/assignments/rohc-pro-ids" value=""/>
</reference>
<reference anchor="CRYPTO-ALG">
<front>
<title>Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)</title>
<author initials="V." surname="Manral">
<organization/>
</author>
<date month="April" year="2007"/>
</front>
<seriesInfo name="RFC" value="4835"/>
</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="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="IKEV2-PARA">
<front>
<title>IKEv2 Parameters, http://www.iana.org/assignments/ikev2-parameters</title>
<date month="November" year="2009"/>
<author surname="IANA">
<organization />
</author>
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 10:39:30 |