draft-ietf-rohc-hcoipsec-08.txt | draft-ietf-rohc-hcoipsec-09.txt | |||
---|---|---|---|---|
Network Working Group E. Ertekin | Network Working Group E. Ertekin | |||
Internet-Draft R. Jasani | Internet-Draft R. Jasani | |||
Intended status: Informational C. Christou | Intended status: Informational C. Christou | |||
Expires: February 15, 2009 J. Pezeshki | Expires: April 17, 2009 J. Pezeshki | |||
Booz Allen Hamilton | Booz Allen Hamilton | |||
C. Bormann | C. Bormann | |||
Universitaet Bremen TZI | Universitaet Bremen TZI | |||
August 14, 2008 | October 14, 2008 | |||
Integration of Robust Header Compression (RoHC) over IPsec Security | Integration of Robust Header Compression (ROHC) over IPsec Security | |||
Associations | Associations | |||
draft-ietf-rohc-hcoipsec-08 | draft-ietf-rohc-hcoipsec-09 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 38 | skipping to change at page 1, line 39 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on February 15, 2009. | This Internet-Draft will expire on April 17, 2009. | |||
Abstract | Abstract | |||
IP Security (IPsec) provides various security services for IP | IP Security (IPsec) provides various security services for IP | |||
traffic. However, the benefits of IPsec come at the cost of | traffic. However, the benefits of IPsec come at the cost of | |||
increased overhead. This document outlines a framework for | increased overhead. This document outlines a framework for | |||
integrating Robust Header Compression (RoHC) over IPsec (RoHCoIPsec). | integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). | |||
By compressing the inner headers of IP packets, RoHCoIPsec proposes | By compressing the inner headers of IP packets, ROHCoIPsec proposes | |||
to reduce the amount of overhead associated with the transmission of | to reduce the amount of overhead associated with the transmission of | |||
traffic over IPsec Security Associations (SAs). | traffic over IPsec Security Associations (SAs). | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4 | 4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4 | |||
5. Overview of the RoHCoIPsec Framework . . . . . . . . . . . 5 | 5. Overview of the ROHCoIPsec Framework . . . . . . . . . . . 5 | |||
5.1. RoHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 5 | 5.1. ROHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 5 | |||
5.2. Summary of the RoHCoIPsec Framework . . . . . . . . . . . 5 | 5.2. Summary of the ROHCoIPsec Framework . . . . . . . . . . . 5 | |||
6. Details of the RoHCoIPsec Framework . . . . . . . . . . . 6 | 6. Details of the ROHCoIPsec Framework . . . . . . . . . . . 6 | |||
6.1. RoHC and IPsec Integration . . . . . . . . . . . . . . . . 6 | 6.1. ROHC and IPsec Integration . . . . . . . . . . . . . . . . 7 | |||
6.1.1. Header Compression Protocol Considerations . . . . . . . . 8 | 6.1.1. Header Compression Protocol Considerations . . . . . . . . 8 | |||
6.1.2. Initialization and Negotiation of the RoHC Channel . . . . 9 | 6.1.2. Initialization and Negotiation of the ROHC Channel . . . . 9 | |||
6.1.3. Encapsulation and Identification of Header Compressed | 6.1.3. Encapsulation and Identification of Header Compressed | |||
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9 | Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
6.2. RoHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10 | 6.2. ROHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . 10 | 7. Security Considerations . . . . . . . . . . . . . . . . . 10 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10 | |||
10. Informative References . . . . . . . . . . . . . . . . . . 11 | 10. Informative References . . . . . . . . . . . . . . . . . . 11 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12 | |||
Intellectual Property and Copyright Statements . . . . . . 14 | Intellectual Property and Copyright Statements . . . . . . 14 | |||
1. Introduction | 1. Introduction | |||
This document outlines a framework for integrating RoHC [ROHC] over | This document outlines a framework for integrating ROHC [ROHC] over | |||
IPsec [IPSEC] (RoHCoIPsec). The goal of RoHCoIPsec is to reduce the | IPsec [IPSEC] (ROHCoIPsec). The goal of ROHCoIPsec is to reduce the | |||
protocol overhead associated with packets traversing between IPsec SA | protocol overhead associated with packets traversing between IPsec SA | |||
endpoints. This can be achieved by compressing the transport layer | endpoints. This can be achieved by compressing the transport layer | |||
header (e.g., UDP, TCP, etc.) and inner IP header of packets at the | 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 | ingress of the IPsec tunnel, and decompressing these headers at the | |||
egress. | egress. | |||
For RoHCoIPsec, this document assumes that RoHC will be used to | For ROHCoIPsec, this document assumes that ROHC will be used to | |||
compress the inner headers of IP packets traversing an IPsec tunnel. | compress the inner headers of IP packets traversing an IPsec tunnel. | |||
However, since current specifications for RoHC detail its operation | However, since current specifications for ROHC detail its operation | |||
on a hop-by-hop basis, it may require extensions to enable its | on a hop-by-hop basis, it may require extensions to enable its | |||
operation over IPsec SAs. This document outlines a framework for | operation over IPsec SAs. These extensions need to account for | |||
extending the usage of RoHC to operate at IPsec SA endpoints. | 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. | ||||
RoHCoIPsec targets the application of RoHC to tunnel mode SAs. | ROHCoIPsec targets the application of ROHC to tunnel mode SAs. | |||
Transport mode SAs only encrypt/authenticate the payload of an IP | Transport mode SAs only encrypt/authenticate the payload of an IP | |||
packet, leaving the IP header untouched. Intermediate routers | packet, leaving the IP header untouched. Intermediate routers | |||
subsequently use this IP header to route the packet to a decryption | subsequently use this IP header to route the packet to a decryption | |||
device. Therefore, if RoHC is to operate over IPsec transport-mode | device. Therefore, if ROHC is to operate over IPsec transport-mode | |||
SAs, (de)compression functionality can only be applied to the | SAs, (de)compression functionality can only be applied to the | |||
transport layer headers, and not to the IP header. Because current | transport layer headers, and not to the IP header. Because current | |||
RoHC specifications do not include support for the compression of | ROHC specifications do not include support for the compression of | |||
transport layer headers alone, the RoHCoIPsec framework outlined by | transport layer headers alone, the ROHCoIPsec framework outlined by | |||
this document describes the application of RoHC to tunnel mode SAs. | this document describes the application of ROHC to tunnel mode SAs. | |||
2. Audience | 2. Audience | |||
The authors target members of both the RoHC and IPsec communities who | The authors target members of both the ROHC and IPsec communities who | |||
may consider extending the RoHC and IPsec protocols to meet the | may consider extending the ROHC and IPsec protocols to meet the | |||
requirements put forth in this document. In addition, this document | requirements put forth in this document. In addition, this document | |||
is directed towards vendors developing IPsec devices that will be | is directed towards vendors developing IPsec devices that will be | |||
deployed in bandwidth-constrained IP networks. | deployed in bandwidth-constrained IP networks. | |||
3. Terminology | 3. Terminology | |||
Terminology specific to RoHCoIPsec is introduced in this section. | Terminology specific to ROHCoIPsec is introduced in this section. | |||
RoHC Process | ||||
Generic reference to a RoHC instance (as defined in [ROHC-TERM]), | ROHC Process | |||
or any supporting RoHC components. | Generic reference to a ROHC instance (as defined in [ROHC-TERM]), | |||
or any supporting ROHC components. | ||||
Compressed Traffic | Compressed Traffic | |||
Traffic that is processed by the RoHC compressor instance. Packet | ||||
Traffic that is processed by the ROHC compressor instance. Packet | ||||
headers are compressed using a specific header compression | headers are compressed using a specific header compression | |||
protocol. | protocol. | |||
Uncompressed Traffic | Uncompressed Traffic | |||
Traffic that is not processed by the RoHC compressor instance. | Traffic that is not processed by the ROHC compressor instance. | |||
Instead, this type of traffic bypasses the RoHC process. | Instead, this type of traffic bypasses the ROHC process. | |||
IPsec Process | IPsec Process | |||
Generic reference to the Internet Protocol Security (IPsec) | Generic reference to the Internet Protocol Security (IPsec) | |||
process. | process. | |||
Next Header | Next Header | |||
Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) | Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) | |||
field. | field. | |||
skipping to change at page 4, line 37 | skipping to change at page 4, line 42 | |||
packet overhead. For example, traffic flow confidentiality | packet overhead. For example, traffic flow confidentiality | |||
(generally leveraged at security gateways) requires the tunneling of | (generally leveraged at security gateways) requires the tunneling of | |||
IP packets between IPsec implementations. Although these IPsec | IP packets between IPsec implementations. Although these IPsec | |||
tunnels will effectively mask the source-destination patterns that an | tunnels will effectively mask the source-destination patterns that an | |||
intruder can ascertain, tunneling comes at the cost of increased per- | intruder can ascertain, tunneling comes at the cost of increased per- | |||
packet overhead. Specifically, an ESP tunnel mode SA applied to an | packet overhead. Specifically, an ESP tunnel mode SA applied to an | |||
IPv6 flow results in at least 50 bytes of additional overhead per | IPv6 flow results in at least 50 bytes of additional overhead per | |||
packet. This additional overhead may be undesirable for many | packet. This additional overhead may be undesirable for many | |||
bandwidth-constrained wireless and/or satellite communications | bandwidth-constrained wireless and/or satellite communications | |||
networks, as these types of infrastructure are not overprovisioned. | networks, as these types of infrastructure are not overprovisioned. | |||
RoHC applied on a per-hop basis over bandwidth-constrained links will | ROHC applied on a per-hop basis over bandwidth-constrained links will | |||
also suffer from reduced performance when encryption is used on the | also suffer from reduced performance when encryption is used on the | |||
tunneled header, since encrypted headers can not be compressed. | tunneled header, since encrypted headers can not be compressed. | |||
Consequently, the additional overhead incurred by an IPsec tunnel may | Consequently, the additional overhead incurred by an IPsec tunnel may | |||
result in the inefficient utilization of bandwidth. | result in the inefficient utilization of bandwidth. | |||
Packet overhead is particularly significant for traffic profiles | Packet overhead is particularly significant for traffic profiles | |||
characterized by small packet payloads (e.g. various voice codecs). | characterized by small packet payloads (e.g. various voice codecs). | |||
If these small packets are afforded the security services of an IPsec | If these small packets are afforded the security services of an IPsec | |||
tunnel mode SA, the amount of per-packet overhead is increased. | tunnel mode SA, the amount of per-packet overhead is increased. | |||
Thus, a mechanism is needed to reduce the overhead associated with | Thus, a mechanism is needed to reduce the overhead associated with | |||
such flows. | such flows. | |||
5. Overview of the RoHCoIPsec Framework | 5. Overview of the ROHCoIPsec Framework | |||
5.1. RoHCoIPsec Assumptions | 5.1. ROHCoIPsec Assumptions | |||
The goal of RoHCoIPsec is to provide efficient transport of IP | The goal of ROHCoIPsec is to provide efficient transport of IP | |||
packets between IPsec devices, without compromising the security | packets between IPsec devices, without compromising the security | |||
services offered by IPsec. The RoHCoIPsec framework has been | services offered by IPsec. The ROHCoIPsec framework has been | |||
developed based on the following assumptions: | developed based on the following assumptions: | |||
o RoHC will be leveraged to reduce the amount of overhead associated | o ROHC will be leveraged to reduce the amount of overhead associated | |||
with packets traversing an IPsec SA | with packets traversing an IPsec SA | |||
o RoHC will be instantiated at the IPsec SA endpoints, and will be | o ROHC will be instantiated at the IPsec SA endpoints, and will be | |||
applied on a per-SA basis | applied on a per-SA basis | |||
o Once the decompression operation completes, decompressed packet | o Once the decompression operation completes, decompressed packet | |||
headers will be identical to the original packet headers before | headers will be identical to the original packet headers before | |||
compression | compression | |||
5.2. Summary of the RoHCoIPsec Framework | 5.2. Summary of the ROHCoIPsec Framework | |||
RoHC reduces packet overhead in a network by exploiting intra- and | ROHC reduces packet overhead in a network by exploiting intra- and | |||
inter-packet redundancies of network and transport-layer header | inter-packet redundancies of network and transport-layer header | |||
fields of a flow. | fields of a flow. | |||
Current RoHC protocol specifications compress packet headers on a | Current ROHC protocol specifications compress packet headers on a | |||
hop-by-hop basis. However, IPsec SAs are instantiated between two | hop-by-hop basis. However, IPsec SAs are instantiated between two | |||
IPsec endpoints. Therefore, various extensions to both RoHC and | IPsec endpoints. Therefore, various extensions to both ROHC and | |||
IPsec need to be defined to ensure the successful operation of the | IPsec need to be defined to ensure the successful operation of the | |||
RoHC protocol at IPsec SA endpoints. | ROHC protocol at IPsec SA endpoints. | |||
The migration of RoHC over IPsec SAs is straightforward, since SA | The migration of ROHC over IPsec SAs is straightforward, since SA | |||
endpoints provide source/destination pairs where (de)compression | endpoints provide source/destination pairs where (de)compression | |||
operations can take place. Compression of the inner IP and upper | operations can take place. Compression of the inner IP and upper | |||
layer protocol headers in such a manner offers a reduction of per- | layer protocol headers in such a manner offers a reduction of per- | |||
packet protocol overhead between the two SA endpoints. Since RoHC | packet protocol overhead between the two SA endpoints. Since ROHC | |||
will now operate between IPsec endpoints (over multiple intermediate | will now operate between IPsec endpoints (over multiple intermediate | |||
nodes which are transparent to an IPsec SA), it is imperative to | nodes which are transparent to an IPsec SA), it is imperative to | |||
ensure that its performance will not be severely impacted due to | ensure that its performance will not be severely impacted due to | |||
increased packet reordering and/or packet loss between the compressor | increased packet reordering and/or packet loss between the compressor | |||
and decompressor. | and decompressor. | |||
In addition, RoHC can no longer rely on the underlying link layer for | In addition, ROHC can no longer rely on the underlying link layer for | |||
RoHC parameter configuration and packet identification. The | ROHC parameter configuration and packet identification. The | |||
RoHCoIPsec framework proposes that RoHC channel parameter | ROHCoIPsec framework proposes that ROHC channel parameter | |||
configuration is accomplished by an SA management protocol (e.g., | configuration is accomplished by an SA management protocol (e.g., | |||
IKEv2 [IKEV2]), while identification of compressed header packets is | IKEv2 [IKEV2]), while identification of compressed header packets is | |||
achieved through the Next Header field of the security protocol | achieved through the Next Header field of the security protocol | |||
(e.g., AH [AH], ESP [ESP]) header. | (e.g., AH [AH], ESP [ESP]) header. | |||
Using the RoHCoIPsec framework proposed below, outbound and inbound | Using the ROHCoIPsec framework proposed below, outbound and inbound | |||
IP traffic processing at an IPsec device needs to be modified. For | IP traffic processing at an IPsec device needs to be modified. For | |||
an outbound packet, a RoHCoIPsec implementation will compress | an outbound packet, a ROHCoIPsec implementation will compress | |||
appropriate packet headers, and subsequently encrypt and/or | appropriate packet headers, and subsequently encrypt and/or | |||
integrity-protect the packet. For tunnel mode SAs, compression may | integrity-protect the packet. For tunnel mode SAs, compression may | |||
be applied to the transport layer protocol and the inner IP header. | be applied to the transport layer protocol and the inner IP header. | |||
For inbound packets, an IPsec device must first decrypt and/or | For inbound packets, an IPsec device must first decrypt and/or | |||
integrity-check the packet. Then decompression of the inner packet | integrity-check the packet. Then decompression of the inner packet | |||
headers is performed. After decompression, the packet is checked | headers is performed. After decompression, the packet is checked | |||
against the access controls imposed on all inbound traffic associated | against the access controls imposed on all inbound traffic associated | |||
with the SA (as specified in [IPSEC]). | with the SA (as specified in [IPSEC]). | |||
Note: Compression of inner headers is independent from compression | Note: Compression of inner headers is independent from compression | |||
of the security protocol (e.g., ESP) and outer IP headers. RoHC | of the security protocol (e.g., ESP) and outer IP headers. ROHC | |||
is capable of compressing the security protocol and the outer IP | is capable of compressing the security protocol and the outer IP | |||
header on a hop-by-hop basis. The applicability of RoHCoIPsec and | 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 | hop-by-hop ROHC on an IPv4 ESP-processed packet [ESP] is shown | |||
below in Figure 1. | below in Figure 1. | |||
----------------------------------------------------------- | ----------------------------------------------------------- | |||
IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP| | IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP| | |||
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV| | |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV| | |||
----------------------------------------------------------- | ----------------------------------------------------------- | |||
|<-------(1)------->|<------(2)-------->| | |<-------(1)------->|<------(2)-------->| | |||
(1) Compressed by RoHC ESP/IP profile | (1) Compressed by ROHC ESP/IP profile | |||
(2) Compressed by RoHCoIPsec TCP/IP profile | (2) Compressed by ROHCoIPsec TCP/IP profile | |||
Figure 1. Applicability of RoHC and RoHCoIPsec on an IPv4 ESP- | Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an | |||
processed packet. | IPv4 ESP-processed packet. | |||
If IPsec NULL encryption is applied to packets, RoHC may still be | If IPsec NULL encryption is applied to packets, ROHC may still be | |||
applied to the inner headers at the IPsec SA endpoints. Inbound and | applied to the inner headers at the IPsec SA endpoints. However, in | |||
outbound packets are still processed as was previously described. | these scenarios, intermediary devices (within the unprotected domain) | |||
inspecting ESP-NULL encrypted packets will be unable to determine the | ||||
content of these packets since they are unable to parse ROHC- | ||||
compressed headers. | ||||
6. Details of the RoHCoIPsec Framework | 6. Details of the ROHCoIPsec Framework | |||
6.1. RoHC and IPsec Integration | 6.1. ROHC and IPsec Integration | |||
Figure 2 illustrates the components required to integrate RoHC with | Figure 2 illustrates the components required to integrate ROHC with | |||
the IPsec process, i.e., RoHCoIPsec. | the IPsec process, i.e., ROHCoIPsec. | |||
+-------------------------------+ | +-------------------------------+ | |||
| RoHC Module | | | ROHC Module | | |||
| | | | | | |||
| | | | | | |||
+-----+ | +-----+ +---------+ | | +-----+ | +-----+ +---------+ | | |||
| | | | | | RoHC | | | | | | | | | ROHC | | | |||
--| A |---------| B |-----| Process |------> Path 1 | --| A |---------| B |-----| Process |------> Path 1 | |||
| | | | | | | | (RoHC-enabled SA) | | | | | | | | | (ROHC-enabled SA) | |||
+-----+ | +-----+ +---------+ | | +-----+ | +-----+ +---------+ | | |||
| | | | | | | | | | |||
| | |-------------------------> Path 2 | | | |-------------------------> Path 2 | |||
| | | (RoHC-enabled SA) | | | | (ROHC-enabled SA) | |||
| +-------------------------------+ | | +-------------------------------+ | |||
| | | | |||
| | | | |||
| | | | |||
| | | | |||
+-----------------------------------------> Path 3 | +-----------------------------------------> Path 3 | |||
(ROHC-disabled SA) | (ROHC-disabled SA) | |||
Figure 2. Integration of RoHC with IPsec. | Figure 2. Integration of ROHC with IPsec. | |||
The process illustrated in Figure 2 augments the IPsec processing | The process illustrated in Figure 2 augments the IPsec processing | |||
model for outbound IP traffic (protected-to-unprotected). Initial | model for outbound IP traffic (protected-to-unprotected). Initial | |||
IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1). | IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1). | |||
Block A: The RoHC data item (part of the SA state information) | Block A: The ROHC data item (part of the SA state information) | |||
retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1, | retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1, | |||
Step3a) determines if the traffic traversing the SA is handed to the | Step3a) determines if the traffic traversing the SA is handed to the | |||
RoHC module. Packets selected to a RoHC-disabled SA must follow | ROHC module. Packets selected to a ROHC-disabled SA must follow | |||
normal IPsec processing and must not be sent to the RoHC module | normal IPsec processing and must not be sent to the ROHC module | |||
(Figure 1, Path 3). Conversely, packets selected to a RoHC-enabled | (Figure 1, Path 3). Conversely, packets selected to a ROHC-enabled | |||
SA must be sent to the RoHC module. | SA must be sent to the ROHC module. | |||
Block B: This step determines if the packet can be compressed. If it | Block B: This step determines if the packet can be compressed. If it | |||
is determined that the packet will be compressed, an Integrity | is determined that the packet will be compressed, an Integrity | |||
Algorithm is used to compute an Integrity Check Value (ICV) for the | Algorithm is used to compute an Integrity Check Value (ICV) for the | |||
uncompressed packet ([IPSEC-ROHC], Section 3.2 [IKE-ROHC], Section | uncompressed packet ([IPSEC-ROHC], Section 3.2 [IKE-ROHC], Section | |||
2.1). The Next Header field of the security protocol header (e.g., | 2.1). The Next Header field of the security protocol header (e.g., | |||
ESP, AH) is populated with a "RoHC" identifier, the packet headers | ESP, AH) is populated with a "ROHC" identifier, the packet headers | |||
are compressed, and the computed ICV is appended to the packet | are compressed, and the computed ICV is appended to the packet | |||
(Figure 1, Path 1). However, if it is determined that 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 | 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 | Section 6.1.3), the Next Header field is populated with the | |||
appropriate value indicating the next level protocol (Figure 1, Path | appropriate value indicating the next level protocol (Figure 1, Path | |||
2). | 2). | |||
After the RoHC process completes, IPsec processing resumes, as | After the ROHC process completes, IPsec processing resumes, as | |||
described in Section 5.1, Step3a, of [IPSEC]. | described in Section 5.1, Step3a, of [IPSEC]. | |||
The process illustrated in Figure 2 also augments the IPsec | The process illustrated in Figure 2 also augments the IPsec | |||
processing model for inbound IP traffic (unprotected-to-protected). | processing model for inbound IP traffic (unprotected-to-protected). | |||
For inbound packets, IPsec processing is performed ([IPSEC], Section | For inbound packets, IPsec processing is performed ([IPSEC], Section | |||
5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section | 5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section | |||
5.2, Step 4). | 5.2, Step 4). | |||
Block A: After AH or ESP processing, the RoHC data item retrieved | Block A: After AH or ESP processing, the ROHC data item retrieved | |||
from the SAD entry will indicate if traffic traversing the SA is | from the SAD entry will indicate if traffic traversing the SA is | |||
processed by the RoHC module ([IPSEC], Section 5.2, Step 3a). | processed by the ROHC module ([IPSEC], Section 5.2, Step 3a). | |||
Packets traversing an RoHC-disabled SA must follow normal IPsec | Packets traversing an ROHC-disabled SA must follow normal IPsec | |||
processing and must not be sent to the RoHC module. Conversely, | processing and must not be sent to the ROHC module. Conversely, | |||
packets traversing an RoHC-enabled SA must be sent to the RoHC | packets traversing an ROHC-enabled SA must be sent to the ROHC | |||
module. | module. | |||
Block B: The decision at Block B is determined by the value of the | 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 | Next Header field of the security protocol header. If the Next | |||
Header field does not indicate a RoHC header, the decompressor must | Header field does not indicate a ROHC header, the decompressor must | |||
not attempt decompression (Figure 1, Path 2). If the Next Header | not attempt decompression (Figure 1, Path 2). If the Next Header | |||
field indicates a RoHC header, decompression is applied. After | field indicates a ROHC header, decompression is applied. After | |||
decompression, the RoHCoIPsec Integrity Algorithm is used to compute | decompression, the ROHCoIPsec Integrity Algorithm is used to compute | |||
an ICV value for the decompressed packet. This ICV is compared to | an ICV value for the decompressed packet. This ICV is compared to | |||
the ICV that was calculated at the compressor: if the ICVs match, the | 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, | packet is forwarded by the ROHC module (Figure 1, Path 1); otherwise, | |||
the packet is dropped. Once the RoHC module completes processing, | the packet is dropped. Once the ROHC module completes processing, | |||
IPsec processing resumes, as described in Section 5.2, Step 4 of | IPsec processing resumes, as described in Section 5.2, Step 4 of | |||
[IPSEC]. | [IPSEC]. | |||
Note that to further reduce the size of an IPsec-protected packet, | Note that to further reduce the size of an IPsec-protected packet, | |||
RoHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested | ROHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested | |||
fashion. This process is detailed in [IPSEC-ROHC], Section 3.2. | fashion. This process is detailed in [IPSEC-ROHC], Section 3.2. | |||
6.1.1. Header Compression Protocol Considerations | 6.1.1. Header Compression Protocol Considerations | |||
RoHCv2 [ROHCV2] profiles include various mechanisms that provide | ROHCv2 [ROHCV2] profiles include various mechanisms that provide | |||
increased robustness over reordering channels. These mechanisms must | increased robustness over reordering channels. These mechanisms must | |||
be adopted for RoHC to operate efficiently over IPsec SAs. | be adopted for ROHC to operate efficiently over IPsec SAs. | |||
A RoHC decompressor implemented within IPsec architecture may | A ROHC decompressor implemented within IPsec architecture may | |||
leverage additional mechanisms to improve performance over reordering | leverage additional mechanisms to improve performance over reordering | |||
channels (either due to random events, or to an attacker | channels (either due to random events, or to an attacker | |||
intentionally reordering packets). Specifically, IPsec's sequence | intentionally reordering packets). Specifically, IPsec's sequence | |||
number may be used by the decompressor to identify a packet as | number may be used by the decompressor to identify a packet as | |||
"sequentially late". This knowledge will increase the likelihood of | "sequentially late". This knowledge will increase the likelihood of | |||
successful decompression of a reordered packet. | successful decompression of a reordered packet. | |||
Additionally, RoHCoIPsec implementations should minimize the amount | Additionally, ROHCoIPsec implementations should minimize the amount | |||
of feedback sent from the decompressor to the compressor. If a ROHC | of feedback sent from the decompressor to the compressor. If a ROHC | |||
feedback channel is not used sparingly, the overall gains from | feedback channel is not used sparingly, the overall gains from | |||
RoHCoIPsec can be significantly reduced. More specifically, any | ROHCoIPsec can be significantly reduced. More specifically, any | |||
feedback sent from the decompressor to the compressor must be | feedback sent from the decompressor to the compressor must be | |||
processed by IPsec, and tunneled back to the compressor (as | processed by IPsec, and tunneled back to the compressor (as | |||
designated by the SA associated with FEEDBACK_FOR). As such, several | designated by the SA associated with FEEDBACK_FOR). As such, several | |||
implementation considerations are offered: | implementation considerations are offered: | |||
o Eliminate feedback traffic altogether by operating only in RoHC | o Eliminate feedback traffic altogether by operating only in ROHC | |||
Unidirectional mode (U-mode) | Unidirectional mode (U-mode) | |||
o Piggyback RoHC feedback messages on traffic that normally | o Piggyback ROHC feedback messages on traffic that normally | |||
traverses the SA designated by FEEDBACK_FOR. | traverses the SA designated by FEEDBACK_FOR. | |||
6.1.2. Initialization and Negotiation of the RoHC Channel | 6.1.2. Initialization and Negotiation of the ROHC Channel | |||
RoHC can use the underlying link layer (e.g., PPP) to automatically | Hop-by-hop ROHC typically uses the underlying link layer (e.g., PPP) | |||
RoHC channel parameters. In the case of RoHCoIPsec, channel | to negotiate ROHC channel parameters. In the case of ROHCoIPsec, | |||
parameters can be achieved manually (i.e., administratively | channel parameters can be set manually (i.e., administratively | |||
configured for manual SAs), or by IKEv2. The extensions required for | configured for manual SAs), or negotiated by IKEv2. The extensions | |||
IKEv2 to support RoHC parameter negotiation are detailed in [IKE- | required for IKEv2 to support ROHC parameter negotiation are detailed | |||
ROHC]. | in [IKE-ROHC]. | |||
If the RoHC protocol requires bi-directional communications, two SAs | If the ROHC protocol requires bi-directional communications, two SAs | |||
must be instantiated between the IPsec implementations. One of the | must be instantiated between the IPsec implementations. One of the | |||
two SAs is used for carrying RoHC-traffic from the compressor to the | two SAs is used for carrying ROHC-traffic from the compressor to the | |||
decompressor, while the other is used to communicate RoHC-feedback | decompressor, while the other is used to communicate ROHC-feedback | |||
from the decompressor to the compressor. Note that the requirement | from the decompressor to the compressor. Note that the requirement | |||
for two SAs aligns with the operation of IKE, which creates SAs in | for two SAs aligns with the operation of IKE, which creates SAs in | |||
pairs by default. However, IPsec implementations will dictate how | pairs by default. However, IPsec implementations will dictate how | |||
decompressor feedback received on one SA is associated with a | decompressor feedback received on one SA is associated with a | |||
compressor on the other SA. | 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. | ||||
6.1.3. Encapsulation and Identification of Header Compressed Packets | 6.1.3. Encapsulation and Identification of Header Compressed Packets | |||
As indicated in Section 6.1, new state information (i.e., a new RoHC | 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 | 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 | IPsec process to determine whether it sends all traffic traversing a | |||
given SA to the RoHC module (RoHC-enabled) or bypasses the RoHC | given SA to the ROHC module (ROHC-enabled) or bypasses the ROHC | |||
module and sends the traffic through regular IPsec processing (RoHC- | module and sends the traffic through regular IPsec processing (ROHC- | |||
disabled). | disabled). | |||
The Next Header field of the IPsec security protocol (e.g., AH or | The Next Header field of the IPsec security protocol (e.g., AH or | |||
ESP) header is used to demultiplex header-compressed traffic from | ESP) header is used to demultiplex header-compressed traffic from | |||
uncompressed traffic traversing an RoHC-enabled SA. This | uncompressed traffic traversing an ROHC-enabled SA. This | |||
functionality is needed in situations where packets traversing a | functionality is needed in situations where packets traversing a | |||
RoHC-enabled SA do not contain compressed headers. Such situations | ROHC-enabled SA do not contain compressed headers. Such situations | |||
may occur when, for example, a compressor supports strictly n | may occur when, for example, a compressor supports strictly n | |||
compressed flows and can not compress the n+1 flow that arrives. | compressed flows and can not compress the n+1 flow that arrives. | |||
Another example is when traffic (e.g., TCP/IP) is selected (by IPsec) | Another example is when traffic (e.g., TCP/IP) is selected (by IPsec) | |||
to a RoHC-enabled SA, but cannot be compressed by the RoHC process | to a ROHC-enabled SA, but cannot be compressed by the ROHC process | |||
(e.g., because the compressor does not support TCP/IP compression). | (e.g., because the compressor does not support TCP/IP compression). | |||
Similarly, the decompressor must be able to identify packets with | Similarly, the decompressor must be able to identify packets with | |||
uncompressed headers and not attempt to decompress them. The Next | uncompressed headers and not attempt to decompress them. The Next | |||
Header field is used to demultiplex these header-compressed versus | Header field is used to demultiplex these header-compressed versus | |||
uncompressed packets, as a RoHC protocol identifier will indicate the | uncompressed packets, as a ROHC protocol identifier will indicate | |||
packet contains compressed headers. To accomplish this, an official | that the packet contains compressed headers. To accomplish this, an | |||
IANA allocation from the Protocol ID registry [PROTOCOL] is required. | official IANA allocation from the Protocol ID registry [PROTOCOL] is | |||
required. | ||||
The RoHC Data Item, IANA Protocol ID allocation, and other IPsec | The ROHC Data Item, IANA Protocol ID allocation, and other IPsec | |||
extensions to support RoHCoIPsec, are specified in [IPSEC-ROHC]. | extensions to support ROHCoIPsec, are specified in [IPSEC-ROHC]. | |||
6.2. RoHCoIPsec Framework Summary | 6.2. ROHCoIPsec Framework Summary | |||
To summarize, the following items are needed to achieve RoHCoIPsec: | To summarize, the following items are needed to achieve ROHCoIPsec: | |||
o IKEv2 Extensions to Support RoHCoIPsec | o IKEv2 Extensions to Support ROHCoIPsec | |||
o IPsec Extensions to Support RoHCoIPsec | o IPsec Extensions to Support ROHCoIPsec | |||
7. Security Considerations | 7. Security Considerations | |||
A malfunctioning RoHC compressor (i.e., the compressor located at the | A malfunctioning ROHC compressor (i.e., the compressor located at the | |||
ingress of the IPsec tunnel) has the ability to send packets to 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 | decompressor (i.e., the decompressor located at the egress of the | |||
IPsec tunnel) that do not match the original packets emitted from the | IPsec tunnel) that do not match the original packets emitted from the | |||
end-hosts. Such a scenario will result in a decreased efficiency | end-hosts. Such a scenario will result in a decreased efficiency | |||
between compressor and decompressor. Furthermore, this may result in | between compressor and decompressor. Furthermore, this may result in | |||
Denial of Service, as the decompression of a significant number of | Denial of Service, as the decompression of a significant number of | |||
invalid packets may drain the resources of an IPsec device. | invalid packets may drain the resources of an IPsec device. | |||
8. IANA Considerations | 8. IANA Considerations | |||
skipping to change at page 11, line 6 | skipping to change at page 11, line 12 | |||
The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, | 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. | and Ms. Linda Noone of the Department of Defense, and well as Mr. | |||
Rich Espy of OPnet for their contributions and support in the | Rich Espy of OPnet for their contributions and support in the | |||
development of this document. | development of this document. | |||
In addition, the authors would like to thank the following for their | In addition, the authors would like to thank the following for their | |||
numerous reviews and comments to this document: | numerous reviews and comments to this document: | |||
o Dr. Stephen Kent | o Dr. Stephen Kent | |||
o Dr. Carsten Bormann | ||||
o Mr. Pasi Eronen | o Mr. Pasi Eronen | |||
o Dr. Joseph Touch | o Dr. Joseph Touch | |||
o Mr. Tero Kivinen | o Mr. Tero Kivinen | |||
o Mr. Yoav Nir | ||||
o Mr. Lars-Erik Jonsson | o Mr. Lars-Erik Jonsson | |||
o Mr. Jan Vilhuber | o Mr. Jan Vilhuber | |||
o Mr. Dan Wing | o Mr. Dan Wing | |||
o Mr. Kristopher Sandlund | o Mr. Kristopher Sandlund | |||
o Mr. Ghyslain Pelletier | o Mr. Ghyslain Pelletier | |||
Finally, the authors would also like to thank Mr. Tom Conkle, Ms. | Finally, the authors would also like to thank Mr. Tom Conkle, Ms. | |||
Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen | Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen | |||
Hamilton for their assistance in completing this work. | Hamilton for their assistance in completing this work. | |||
skipping to change at page 11, line 34 | skipping to change at page 11, line 40 | |||
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., | Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., | |||
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header | Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header | |||
Compression (ROHC): Framework and four profiles: RTP, UDP, | Compression (ROHC): Framework and four profiles: RTP, UDP, | |||
ESP, and uncompressed", RFC 3095, July 2001. | ESP, and uncompressed", RFC 3095, July 2001. | |||
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the | [IPSEC] Kent, S. and K. Seo, "Security Architecture for the | |||
Internet Protocol", RFC 4301, December 2005. | Internet Protocol", RFC 4301, December 2005. | |||
[ROHC-TERM] | [ROHC-TERM] | |||
Jonsson, L-E., "Robust Header Compression (ROHC): | Jonsson, L-E., "Robust Header Compression (ROHC): | |||
Terminology and Channel Mapping Examples", RFC 4301, | Terminology and Channel Mapping Examples", RFC 3759, | |||
April 2004. | April 2004. | |||
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", | [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", | |||
RFC 4306, December 2005. | RFC 4306, December 2005. | |||
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", | [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", | |||
RFC 4303, December 2005. | RFC 4303, December 2005. | |||
[AH] Kent, S., "IP Authentication Header", RFC 4302, | [AH] Kent, S., "IP Authentication Header", RFC 4302, | |||
December 2005. | December 2005. | |||
[IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload | [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload | |||
Compression Protocol (IPComp)", RFC 3173, September 2001. | Compression Protocol (IPComp)", RFC 3173, September 2001. | |||
[ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression | [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression | |||
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP | Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP | |||
Lite", RFC 5225, April 2008. | Lite", RFC 5225, April 2008. | |||
[IKE-ROHC] | [IKE-ROHC] | |||
Pezeshki, et al., "IKEv2 Extensions to Support | Pezeshki, et al., "IKEv2 Extensions to Support | |||
RoHCoIPsec", work in progress , August 2008. | ROHCoIPsec", work in progress , October 2008. | |||
[PROTOCOL] | [PROTOCOL] | |||
IANA, "Assigned Internet Protocol Numbers, IANA registry | IANA, "Assigned Internet Protocol Numbers, IANA registry | |||
at: http://www.iana.org/assignments/protocol-numbers". | at: http://www.iana.org/assignments/protocol-numbers". | |||
[IPSEC-ROHC] | [IPSEC-ROHC] | |||
Ertekin, et al., "IPsec Extensions to Support RoHCoIPsec", | Ertekin, et al., "IPsec Extensions to Support ROHCoIPsec", | |||
work in progress , August 2008. | work in progress , October 2008. | |||
Authors' Addresses | Authors' Addresses | |||
Emre Ertekin | Emre Ertekin | |||
Booz Allen Hamilton | Booz Allen Hamilton | |||
13200 Woodland Park Dr. | 13200 Woodland Park Dr. | |||
Herndon, VA 20171 | Herndon, VA 20171 | |||
US | US | |||
Email: ertekin_emre@bah.com | Email: ertekin_emre@bah.com | |||
End of changes. 89 change blocks. | ||||
131 lines changed or deleted | 140 lines changed or added | |||
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |