Internet Engineering Task Force (IETF) E. Ertekin
Request for Comments: 5856 R. Jasani
Category: Informational C. Christou
ISSN: 2070-1721 Booz Allen Hamilton
C. Bormann
Universitaet Bremen TZI
May 2010
Internet Engineering Task Force (IETF) E. Ertekin
Request for Comments: 5856 R. Jasani
Category: Informational C. Christou
ISSN: 2070-1721 Booz Allen Hamilton
C. Bormann
Universitaet Bremen TZI
May 2010
Integration of Robust Header Compression over IPsec Security Associations
在IPsec安全关联上集成健壮的报头压缩
Abstract
摘要
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).
IP安全（IPsec）为IP通信提供各种安全服务。然而，IPsec的好处是以增加开销为代价的。本文档概述了通过IPsec（ROHCoIPsec）集成健壮头压缩（ROHC）的框架。通过压缩IP数据包的内部报头，ROHCoIPsec建议减少与通过IPsec安全关联（SAs）传输流量相关的开销。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。互联网工程指导小组（IESG）已批准将其出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5856.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5856.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Audience ........................................................3
3. Terminology .....................................................3
4. Problem Statement: IPsec Packet Overhead ........................4
5. Overview of the ROHCoIPsec Framework ............................5
5.1. ROHCoIPsec Assumptions .....................................5
5.2. Summary of the ROHCoIPsec Framework ........................5
6. Details of the ROHCoIPsec Framework .............................7
6.1. ROHC and IPsec Integration .................................7
6.1.1. Header Compression Protocol Considerations ..........9
6.1.2. Initialization and Negotiation of the ROHC Channel ..9
6.1.3. Encapsulation and Identification of Header
Compressed Packets .................................10
6.1.4. Motivation for the ROHC ICV ........................11
6.1.5. Path MTU Considerations ............................11
6.2. ROHCoIPsec Framework Summary ..............................12
7. Security Considerations ........................................12
8. IANA Considerations ............................................12
9. Acknowledgments ................................................13
10. Informative References ........................................14
1. Introduction ....................................................3
2. Audience ........................................................3
3. Terminology .....................................................3
4. Problem Statement: IPsec Packet Overhead ........................4
5. Overview of the ROHCoIPsec Framework ............................5
5.1. ROHCoIPsec Assumptions .....................................5
5.2. Summary of the ROHCoIPsec Framework ........................5
6. Details of the ROHCoIPsec Framework .............................7
6.1. ROHC and IPsec Integration .................................7
6.1.1. Header Compression Protocol Considerations ..........9
6.1.2. Initialization and Negotiation of the ROHC Channel ..9
6.1.3. Encapsulation and Identification of Header
Compressed Packets .................................10
6.1.4. Motivation for the ROHC ICV ........................11
6.1.5. Path MTU Considerations ............................11
6.2. ROHCoIPsec Framework Summary ..............................12
7. Security Considerations ........................................12
8. IANA Considerations ............................................12
9. Acknowledgments ................................................13
10. Informative References ........................................14
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.
本文档概述了在IPsec[IPsec]（Rohciopsec）上集成ROHC[ROHC]的框架。ROHCoIPsec的目标是减少与IPsec SA端点之间的数据包遍历相关的协议开销。这可以通过在IPsec隧道入口处压缩数据包的传输层报头（例如UDP、TCP等）和内部IP报头，并在出口处解压缩这些报头来实现。
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. This document outlines a framework for extending the usage of ROHC to operate at IPsec SA endpoints.
对于ROHCoIPsec，本文档假设ROHC将用于压缩通过IPsec隧道的IP数据包的内部头。然而，由于ROHC的当前规范在逐跳的基础上详细说明了其操作，因此它需要扩展以支持其在IPsec SAs上的操作。本文档概述了一个框架，用于扩展ROHC在IPsec SA端点上的使用。
ROHCoIPsec targets the application of ROHC to tunnel mode SAs. Transport mode SAs only protect 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.
ROHCoIPsec的目标是将ROHC应用于隧道模式SAs。传输模式SAs仅保护IP数据包的有效负载，保持IP报头不变。中间路由器随后使用此IP报头将数据包路由到解密设备。因此，如果ROHC要在IPsec传输模式SAs上运行，则（反）压缩功能只能应用于传输层标头，而不能应用于IP标头。由于目前的ROHC规范不包括仅对传输层报头压缩的支持，因此本文概述的ROHCoIPsec框架描述了ROHC在隧道模式SAs中的应用。
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.
作者针对ROHC和IPSec社区的成员，他们可以考虑扩展ROHC和IPSec协议以满足本文档中提出的要求。此外，本文档面向开发IPsec设备的供应商，这些设备将部署在带宽受限的IP网络中。
ROHC Process
ROHC工艺
Generic reference to a ROHC instance (as defined in RFC 3759 [ROHC-TERM]) or any supporting ROHC components.
ROHC实例（如RFC 3759[ROHC-TERM]中定义）或任何支持ROHC组件的通用参考。
Compressed Traffic
压缩流量
Traffic that is processed through the ROHC compressor and decompressor instances. Packet headers are compressed and decompressed using a specific header compression profile.
通过ROHC压缩器和解压缩器实例处理的流量。使用特定的报头压缩配置文件压缩和解压缩数据包报头。
Uncompressed Traffic
未压缩流量
Traffic that is not processed by the ROHC compressor instance. Instead, this type of traffic bypasses the ROHC process.
ROHC压缩器实例未处理的通信量。相反，这种类型的流量绕过ROHC流程。
IPsec Process
IPsec进程
Generic reference to the Internet Protocol Security (IPsec) process.
Internet协议安全（IPsec）过程的通用参考。
Next Header
下一包头
Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) field.
指协议（IPv4）或下一个标头（IPv6，扩展）字段。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[BRA97]中所述进行解释。
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 packet overhead. Specifically, an Encapsulating Security Payload (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.
IPsec机制为IP网络提供各种安全服务。然而，IPsec的好处是以增加每个数据包的开销为代价的。例如，流量机密性（通常在安全网关上使用）要求在IPsec实现之间通过隧道传输IP数据包。尽管这些IPsec隧道将有效地屏蔽入侵者可以确定的源-目标模式，但隧道带来的代价是增加数据包开销。具体地说，应用于IPv6流的封装安全有效负载（ESP）隧道模式SA导致每个分组至少50字节的额外开销。这种额外的开销对于许多带宽受限的无线和/或卫星通信网络来说可能是不可取的，因为这些类型的基础设施并没有过度提供。当在隧道标头上使用加密时，在带宽受限的链路上以每跳为基础应用的ROHC也会降低性能，因为加密标头无法压缩。因此，IPsec隧道产生的额外开销可能导致带宽的低效利用。
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.
对于以小数据包有效负载（例如，各种语音编解码器）为特征的流量配置文件，数据包开销尤其重要。如果向这些小数据包提供IPsec隧道模式SA的安全服务，则每个数据包的开销会增加。因此，需要一种机制来减少与这些流相关联的开销。
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:
ROHCoIPsec的目标是在不损害IPsec提供的安全服务的情况下，在IPsec设备之间提供高效的IP数据包传输。ROHCoIPsec框架是基于以下假设开发的：
o ROHC will be leveraged to reduce the amount of overhead associated with unicast IP packets traversing an IPsec SA.
o ROHC将被用来减少与单播IP数据包穿越IPsec SA相关的开销。
o ROHC will be instantiated at the IPsec SA endpoints, and it will be applied on a per-SA basis.
o ROHC将在IPsec SA端点上实例化，并将在每个SA的基础上应用。
o Once the decompression operation completes, decompressed packet headers will be identical to the original packet headers before compression.
o 一旦解压缩操作完成，解压缩的数据包头将与压缩前的原始数据包头相同。
ROHC reduces packet overhead in a network by exploiting intra- and inter-packet redundancies of network and transport-layer header fields of a flow.
ROHC通过利用流的网络和传输层报头字段的包内和包间冗余来减少网络中的包开销。
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.
当前的ROHC协议规范在逐跳的基础上压缩数据包头。但是，IPsec SA在两个IPsec端点之间实例化。因此，需要定义ROHC和IPsec的各种扩展，以确保ROHC协议在IPsec SA端点上成功运行。
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 packet overhead between the two SA endpoints. Since ROHC will now operate between IPsec endpoints (over multiple intermediate nodes that 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.
IPsec SAs上的ROHC规范非常简单，因为SA端点提供可以进行（反）压缩操作的源/目标对。以这种方式压缩内部IP和上层协议头可以减少两个SA端点之间的数据包开销。由于ROHC现在将在IPsec端点之间（在对IPsec SA透明的多个中间节点上）运行，因此必须确保其性能不会因压缩机和解压缩器之间增加的数据包重新排序和/或数据包丢失而受到严重影响。
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., Internet Key Exchange Protocol version 2 (IKEv2) [IKEV2]), while identification of compressed header packets is achieved through the
此外，ROHC不再依赖底层链路层进行ROHC信道参数配置和数据包识别。ROHCoIPsec框架提出ROHC信道参数配置由SA管理协议（例如，互联网密钥交换协议版本2（IKEv2）[IKEv2]）完成，而压缩头数据包的识别则通过
Next Header field of the security protocol (e.g., Authentication Header (AH) [AH], ESP [ESP]) header.
安全协议的下一个报头字段（例如，身份验证报头（AH）[AH]，ESP[ESP]）报头。
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 RFC 4301 [IPSEC]).
使用下面提出的ROHCoIPsec框架，需要修改IPsec设备上的出站和入站IP流量处理。对于出站数据包，ROHCoIPsec实现将压缩适当的数据包头，并随后对数据包进行加密和/或完整性保护。对于隧道模式SAs，可将压缩应用于传输层和内部IP报头。对于入站数据包，IPsec设备必须首先对数据包进行解密和/或完整性检查。然后，执行内部分组报头的解压缩。解压缩后，根据对与SA相关联的所有入站流量施加的访问控制（如RFC 4301[IPSEC]中的规定）检查数据包。
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.
注意：内部报头的压缩独立于安全协议（如ESP）和外部IP报头的压缩。ROHC配置文件已定义为允许逐跳压缩安全协议和外部IP头。ROHCoIPsec和逐跳ROHC在IPv4 ESP处理的数据包[ESP]上的适用性如下图1所示。
-----------------------------------------------------------
IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<-------(1)------->|<------(2)-------->|
-----------------------------------------------------------
IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<-------(1)------->|<------(2)-------->|
(1) Compressed hop-by-hop by the ROHC [ROHC] ESP/IP profile (2) Compressed end-to-end by the ROHCoIPsec [IPSEC-ROHC] TCP/IP profile
(1) ROHC[ROHC]ESP/IP配置文件逐跳压缩（2）Rohciopsec[IPSEC-ROHC]TCP/IP配置文件端到端压缩
Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an IPv4 ESP-processed packet.
图1。逐跳ROHC和ROHCoIPsec对IPv4 ESP处理的数据包的适用性。
If IPsec NULL encryption is applied to packets, ROHC may still be used to compress the inner headers at IPsec SA endpoints. However, compression of these inner headers may pose challenges for intermediary devices (e.g., traffic monitors, sampling/management tools) that are inspecting the contents of ESP-NULL packets. For example, policies on these devices may need to be updated to ensure that packets that contain the "ROHC" protocol identifier are not dropped. In addition, intermediary devices may require additional functionality to determine the content of the header compressed packets.
如果IPsec NULL加密应用于数据包，则ROHC仍可用于压缩IPsec SA端点处的内部头。然而，这些内部报头的压缩可能对正在检查ESP-NULL数据包内容的中间设备（例如，流量监视器、采样/管理工具）构成挑战。例如，这些设备上的策略可能需要更新，以确保包含“ROHC”协议标识符的数据包不会被丢弃。此外，中间设备可能需要额外的功能来确定报头压缩分组的内容。
In certain scenarios, a ROHCoIPsec implementation may encounter UDP-encapsulated ESP or IKE packets (i.e., packets that are traversing NATs). For example, a ROHCoIPsec implementation may receive a UDP-encapsulated ESP packet that contains an ESP/UDP/IP header chain. Currently, ROHC profiles do not support compression of the entire header chain associated with this packet; only the UDP/IP headers can be compressed.
在某些情况下，ROHCoIPsec实现可能会遇到UDP封装的ESP或IKE数据包（即，正在穿越NAT的数据包）。例如，ROHCoIPsec实现可以接收包含ESP/UDP/IP报头链的UDP封装ESP数据包。目前，ROHC配置文件不支持压缩与此数据包相关的整个报头链；只能压缩UDP/IP头。
Figure 2 illustrates the components required to integrate ROHC with the IPsec process, i.e., ROHCoIPsec.
图2说明了将ROHC与IPsec进程集成所需的组件，即ROHCoIPsec。
+-------------------------------+
| ROHC Module |
| |
| |
+-----+ | +-----+ +---------+ |
| | | | | | ROHC | |
--| A |---------| B |-----| Process |------> Path 1
| | | | | | | | (ROHC-enabled SA)
+-----+ | +-----+ +---------+ |
| | | |
| | |-------------------------> Path 2
| | | (ROHC-enabled SA,
| +-------------------------------+ but no compression)
|
|
|
|
+-----------------------------------------> Path 3
(ROHC-disabled SA)
+-------------------------------+
| ROHC Module |
| |
| |
+-----+ | +-----+ +---------+ |
| | | | | | ROHC | |
--| A |---------| B |-----| Process |------> Path 1
| | | | | | | | (ROHC-enabled SA)
+-----+ | +-----+ +---------+ |
| | | |
| | |-------------------------> Path 2
| | | (ROHC-enabled SA,
| +-------------------------------+ but no compression)
|
|
|
|
+-----------------------------------------> Path 3
(ROHC-disabled SA)
Figure 2. Integration of ROHC with IPsec
图2。ROHC与IPsec的集成
The process illustrated in Figure 2 augments the IPsec processing model for outbound IP traffic (protected-to-unprotected). Initial IPsec processing is consistent with RFC 4301 [IPSEC] (Section 5.1, Steps 1-2).
图2所示的过程增强了出站IP流量（从受保护到不受保护）的IPsec处理模型。初始IPsec处理与RFC 4301[IPsec]（第5.1节，步骤1-2）一致。
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
块A：从“相关SAD条目”（[IPSEC]，第5.1节，步骤3a）检索的ROHC数据项（SA状态信息的一部分）确定是否将通过SA的流量传递给ROHC模块。选择到ROHC禁用SA的数据包必须遵循正常的IPsec处理，并且不得发送到ROHC模块
(Figure 2, Path 3). Conversely, packets selected to a ROHC-enabled SA MUST be sent to the ROHC module.
（图2，路径3）。相反，选择至ROHC启用SA的数据包必须发送至ROHC模块。
Block B: This step determines if the packet can be compressed. If the packet is compressed, an integrity algorithm MAY be used to compute an Integrity Check Value (ICV) for the uncompressed packet ([IPSEC-ROHC], Section 4.2; [IKE-ROHC], Section 3.1). The Next Header field of the security protocol header (e.g., ESP, AH) MUST be populated with a "ROHC" protocol identifier [PROTOCOL], inner packet headers MUST be compressed, and the computed ICV MAY be appended to the packet (Figure 2, Path 1). However, if it is determined that the packet will not be compressed (e.g., due to one of the reasons described in Section 6.1.3), the Next Header field MUST be populated with the appropriate value indicating the next-level protocol (Figure 2, Path 2), and ROHC processing MUST NOT be applied to the packet.
块B：该步骤确定是否可以压缩数据包。如果数据包被压缩，完整性算法可用于计算未压缩数据包的完整性检查值（ICV）（[IPSEC-ROHC]，第4.2节；[IKE-ROHC]，第3.1节）。安全协议报头（例如ESP、AH）的下一个报头字段必须填充“ROHC”协议标识符[协议]，必须压缩内部分组报头，并且可以将计算出的ICV附加到分组（图2，路径1）。但是，如果确定数据包不会被压缩（例如，由于第6.1.3节中描述的原因之一），则必须使用指示下一级协议的适当值填充下一个报头字段（图2，路径2），并且不得对数据包应用ROHC处理。
After the ROHC process completes, IPsec processing resumes, as described in Section 5.1, Step3a, of RFC 4301 [IPSEC].
ROHC过程完成后，IPsec处理恢复，如RFC 4301[IPsec]第5.1节第3a步所述。
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).
图2所示的过程还增强了入站IP流量的IPsec处理模型（未保护到受保护）。对于入站数据包，执行IPsec处理（[IPsec]，第5.2节，步骤1-3），然后执行AH或ESP处理（[IPsec]，第5.2节，步骤4）。
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 a ROHC-disabled SA MUST follow normal IPsec processing and MUST NOT be sent to the ROHC module. Conversely, packets traversing a ROHC-enabled SA MUST be sent to the ROHC module.
块A：在AH或ESP处理后，从SAD条目检索到的ROHC数据项将指示通过SA的流量是否由ROHC模块处理（[IPSEC]，第5.2节，步骤3a）。通过ROHC禁用SA的数据包必须遵循正常的IPsec处理，并且不得发送到ROHC模块。相反，通过ROHC启用SA的数据包必须发送至ROHC模块。
Block B: The decision at Block B is made using 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 2, Path 2). If the Next Header field indicates a ROHC header, decompression is applied. After decompression, the signaled ROHCoIPsec integrity algorithm MAY be 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 2, Path 1); otherwise, the packet MUST be dropped. Once the ROHC module completes processing, IPsec processing resumes, as described in Section 5.2, Step 4, of RFC 4301 [IPSEC].
块B：块B的决定是使用安全协议头的下一个头字段的值作出的。如果Next Header字段未指示ROHC头，则解压缩程序不得尝试解压缩（图2，路径2）。如果下一个标头字段指示ROHC标头，则应用解压缩。在解压缩之后，可以使用发信号的ROHCoIPsec完整性算法来计算解压缩分组的ICV值。将该ICV（如果存在）与压缩机处计算的ICV进行比较。如果ICV匹配，则数据包由ROHC模块转发（图2，路径1）；否则，必须丢弃数据包。一旦ROHC模块完成处理，IPsec处理将恢复，如RFC 4301[IPsec]第5.2节第4步所述。
When there is a single SA between a compressor and decompressor, ROHC MUST operate in unidirectional mode, as described in Section 5 of RFC 3759 [ROHC-TERM]. When there is a pair of SAs instantiated between
当压缩机和减压器之间存在单一SA时，ROHC必须以单向模式运行，如RFC 3759[ROHC-TERM]第5节所述。当有一对SA在
ROHCoIPsec implementations, ROHC MAY operate in bi-directional mode, where an SA pair represents a bi-directional ROHC channel (as described in Sections 6.1 and 6.2 of RFC 3759 [ROHC-TERM]).
ROHCoIPsec实施中，ROHC可在双向模式下运行，其中SA对表示双向ROHC信道（如RFC 3759[ROHC-TERM]第6.1和6.2节所述）。
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 4.4.
请注意，为了进一步减小受IPsec保护的数据包的大小，可以嵌套方式实现ROHCoIPsec和IPComp[IPComp]。[IPSEC-ROHC]第4.4节详细介绍了该过程。
ROHCv2 [ROHCV2] profiles include various mechanisms that provide increased robustness over reordering channels. These mechanisms SHOULD be adopted for ROHC to operate efficiently over IPsec SAs.
ROHCv2[ROHCv2]配置文件包括各种机制，可在重新排序通道上提供更高的鲁棒性。ROHC应采用这些机制在IPsec SAs上高效运行。
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.
在IPsec体系结构中实现的ROHC解压器可以利用其他机制提高重新排序通道的性能（由于随机事件或攻击者故意重新排序数据包）。具体地说，解压缩器可以使用IPsec的序列号来将分组标识为“顺序延迟”。此知识将增加成功解压缩重新排序的数据包的可能性。
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:
此外，ROHCoIPsec实施应尽量减少从减压器发送到压缩机的反馈量。如果ROHC反馈通道未被节约使用，ROHCoIPsec的总体收益将显著降低。更具体地说，从解压器发送到压缩器的任何反馈都必须由IPsec处理并通过隧道传回压缩器（由SA指定，该SA与针对的反馈_相关）。因此，可以考虑一些实施方案，包括：
o Eliminate feedback traffic altogether by operating only in ROHC Unidirectional mode (U-mode).
o 通过仅在ROHC单向模式（U模式）下运行，完全消除反馈流量。
o Piggyback ROHC feedback messages within the feedback element (i.e., on ROHC traffic that normally traverses the SA designated by FEEDBACK_FOR).
o 反馈元素内的ROHC反馈消息（即，通常通过反馈_指定的SA的ROHC流量）。
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].
逐跳ROHC通常使用底层链路层（例如PPP）协商ROHC信道参数。在ROHCoIPsec的情况下，可以手动设置信道参数（即，为手动SAs进行管理配置）或由IKEv2协商。IKEv2支持ROHC信道参数协商所需的扩展在[IKE-ROHC]中有详细说明。
If the ROHC protocol requires bi-directional 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.
如果ROHC协议需要双向通信，则必须在IPsec实现之间实例化两个SA。两个SAs中的一个用于将ROHC通信从压缩机传送到减压器，而另一个用于将来自减压器的ROHC反馈传送到压缩机。请注意，对两个SA的要求与IKE的操作一致，默认情况下，IKE成对创建SA。但是，IPsec实现将规定一个SA上接收到的解压缩器反馈如何与另一个SA上的压缩器相关联。IPsec实现必须将入站SA上的解压缩程序接收到的反馈中继到与相应出站SA关联的压缩器。
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 MUST be 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).
如第6.1节所述，为每个SA定义了新的状态信息（即新的ROHC数据项）。IPsec进程必须使用ROHC数据项来确定它是将通过给定SA的所有通信发送到ROHC模块（ROHC已启用）还是绕过ROHC模块并通过常规IPsec处理发送通信（ROHC已禁用）。
The Next Header field of the IPsec security protocol (e.g., AH or ESP) header MUST be used to demultiplex header-compressed traffic from uncompressed traffic traversing a 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 only supports up to n compressed flows and cannot compress a flow number n+1 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 MUST NOT attempt to decompress them. The Next Header field is used to demultiplex these header-compressed and uncompressed packets where the "ROHC" protocol identifier will indicate that the packet contains compressed headers. To accomplish this, IANA has allocated value 142 to "ROHC" from the Protocol ID registry [PROTOCOL].
IPsec安全协议（如AH或ESP）报头的下一个报头字段必须用于将报头压缩流量与通过启用ROHC的SA的未压缩流量分离。在通过ROHC启用的SA的数据包包含未压缩的头的情况下，需要此功能。例如，当压缩机仅支持多达n个压缩流且无法压缩到达的流号n+1时，可能会发生这种情况。另一个例子是，当流量被选择为启用ROHC的SA，但由于没有发出使用相应ROHC配置文件的信号，因此无法通过ROHC流程进行压缩。因此，解压缩程序必须能够识别具有未压缩头的数据包，并且不得尝试对其进行解压缩。下一个报头字段用于将这些报头压缩和未压缩的数据包解复用，其中“ROHC”协议标识符将指示数据包包含压缩报头。为了实现这一点，IANA已将值142从协议ID注册表[协议]分配给“ROHC”。
It is noted that the use of the "ROHC" protocol identifier for purposes other than ROHCoIPsec is currently not defined. In other words, the "ROHC" protocol identifier is only defined for use in the Next Header field of security protocol headers (e.g., ESP, AH).
需要注意的是，“ROHC”协议标识符用于ROHCoIPsec以外的目的目前尚未定义。换句话说，“ROHC”协议标识符仅定义用于安全协议头（例如ESP、AH）的下一个头字段。
The ROHC Data Item, IANA Protocol ID allocation, and other IPsec extensions to support ROHCoIPsec are specified in [IPSEC-ROHC].
ROHC数据项、IANA协议ID分配和其他支持ROHCIOPSEC的IPsec扩展在[IPsec-ROHC]中指定。
Although ROHC was designed to tolerate packet loss and reordering, the algorithm does not guarantee that packets reconstructed at the decompressor are identical to the original packet. As stated in Section 5.2 of RFC 4224 [REORDR], the consequences of packet reordering between ROHC peers may include undetected decompression failures, where erroneous packets are constructed and forwarded to upper layers. Significant packet loss can have similar consequences.
虽然ROHC的设计允许数据包丢失和重新排序，但该算法不能保证在解压缩器中重建的数据包与原始数据包相同。如RFC 4224[REORDR]第5.2节所述，ROHC对等方之间的数据包重新排序的后果可能包括未检测到的解压缩失败，其中错误数据包被构造并转发到上层。严重的数据包丢失可能会产生类似的后果。
When using IPsec integrity protection, a packet received at the egress of an IPsec tunnel is identical to the packet that was processed at the ingress (given that the key is not compromised, etc.).
当使用IPsec完整性保护时，在IPsec隧道出口处接收的数据包与在入口处处理的数据包相同（假定密钥未泄露等）。
When ROHC is integrated into the IPsec processing framework, the ROHC processed packet is protected by the AH/ESP ICV. However, bits in the original IP header are not protected by this ICV; they are protected only by ROHC's integrity mechanisms (which are designed for random packet loss/reordering, not malicious packet loss/reordering introduced by an attacker). Therefore, under certain circumstances, erroneous packets may be constructed and forwarded into the protected domain.
当ROHC集成到IPsec处理框架中时，经过ROHC处理的数据包将受到AH/ESP ICV的保护。但是，原始IP报头中的位不受此ICV的保护；它们仅受ROHC完整性机制的保护（该机制专为随机数据包丢失/重新排序而设计，而不是由攻击者引入的恶意数据包丢失/重新排序）。因此，在某些情况下，可能构造错误分组并将其转发到受保护域中。
To ensure the integrity of the original IP header within the ROHCoIPsec-processing model, an additional integrity check MAY be applied before the packet is compressed. This integrity check will ensure that erroneous packets are not forwarded into the protected domain. The specifics of this integrity check are documented in Section 4.2 of [IPSEC-ROHC].
为确保ROHCoIPsec处理模型内原始IP报头的完整性，可在压缩数据包之前进行额外的完整性检查。此完整性检查将确保错误数据包不会转发到受保护的域中。该完整性检查的细节记录在[IPSEC-ROHC]的第4.2节中。
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 RFC 4301 [IPSEC]; approaches include fragmenting the packet before or after IPsec processing (if the packet's Don't Fragment (DF) bit is clear), or possibly discarding packets (if the packet's DF bit is set).
通过使用AH/ESP和隧道IP头封装IP数据包，IPsec增加了IP数据包的大小。此增加可能导致未受保护的域中出现路径MTU问题。RFC 4301[IPSEC]第8节中记录了解决这些路径MTU问题的几种方法；方法包括在IPsec处理之前或之后对数据包进行分段（如果数据包的不分段（DF）位是清除的），或者可能丢弃数据包（如果设置了数据包的DF位）。
The addition of ROHC within the IPsec processing model may result in 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, the resulting ICV will increase the size of packets. Both of these properties of ROHCoIPsec increase the size of packets,
在IPsec处理模型中添加ROHC可能会导致类似的路径MTU挑战。例如，在某些情况下，ROHC头比原始未压缩头大。此外，如果使用完整性算法验证数据包报头，产生的ICV将增加数据包的大小。ROHCoIPsec的这两个属性都增加了数据包的大小，
and therefore may result in additional challenges associated with path MTU.
因此，可能会导致与路径MTU相关的额外挑战。
Approaches to addressing these path MTU issues are specified in Section 4.3 of [IPSEC-ROHC].
[IPSEC-ROHC]第4.3节规定了解决这些路径MTU问题的方法。
To summarize, the following items are needed to achieve ROHCoIPsec:
综上所述，实现ROHCoIPsec需要以下几项：
o IKEv2 Extensions to Support ROHCoIPsec
o 支持ROHCoIPsec的IKEv2扩展
o IPsec Extensions to Support ROHCoIPsec
o 支持ROHCoIPsec的IPsec扩展
Several security considerations associated with the use of ROHCoIPsec are covered in Section 6.1.4. These considerations can be mitigated by using a strong integrity-check algorithm to ensure the valid decompression of packet headers.
第6.1.4节介绍了与ROHCoIPsec使用相关的几个安全注意事项。通过使用强完整性检查算法来确保数据包头的有效解压缩，可以减轻这些考虑。
A malfunctioning or malicious ROHCoIPsec compressor (i.e., the compressor located at the ingress of the IPsec tunnel) has the ability to send erroneous 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 may result in decreased efficiency between compressor and decompressor, or may cause the decompressor to forward erroneous packets into the protected domain. A malicious compressor could also intentionally generate a significant number of compressed packets, which may result in denial of service at the decompressor, as the decompression of a significant number of invalid packets may drain the resources of an IPsec device.
出现故障或恶意的ROHCoIPsec压缩器（即位于IPsec隧道入口的压缩器）能够向解压缩器（即位于IPsec隧道出口的解压缩器）发送与终端主机发出的原始数据包不匹配的错误数据包。这种情况可能导致压缩器和解压缩器之间的效率降低，或者可能导致解压缩器将错误数据包转发到受保护域。恶意压缩器还可能故意生成大量压缩数据包，这可能导致解压器拒绝服务，因为大量无效数据包的解压可能会耗尽IPsec设备的资源。
A malfunctioning or malicious ROHCoIPsec decompressor has the ability to disrupt communications as well. For example, a decompressor may simply discard a subset of (or all) the packets that are received, even if packet headers were validly decompressed. Ultimately, this could result in denial of service. A malicious decompressor could also intentionally indicate that its context is not synchronized with the compressor's context, forcing the compressor to transition to a lower compression state. This will reduce the overall efficiency gain offered by ROHCoIPsec.
出现故障或恶意的ROHCoIPsec解压缩程序也有能力中断通信。例如，解压器可以简单地丢弃所接收的分组的子集（或全部），即使分组头被有效地解压。最终，这可能导致拒绝服务。恶意解压缩程序还可能故意指示其上下文与压缩器的上下文不同步，从而迫使压缩器转换到较低的压缩状态。这将降低ROHCoIPsec提供的总体效率增益。
All IANA considerations for ROHCoIPsec are documented in [IKE-ROHC] and [IPSEC-ROHC].
ROHCoIPsec的所有IANA注意事项都记录在[IKE-ROHC]和[IPSEC-ROHC]中。
The authors would like to thank Sean O'Keeffe, James Kohler, and Linda Noone of the Department of Defense, as well as Rich Espy of OPnet for their contributions and support in the development of this document.
作者要感谢国防部的Sean O'Keeffe、James Kohler和Linda Noone，以及OPnet的Rich Espy，感谢他们在本文档开发过程中所做的贡献和支持。
The authors would also like to thank Yoav Nir and Robert A Stangarone Jr.: both served as committed document reviewers for this specification.
作者还要感谢Yoav Nir和Robert A Stangarone Jr.：他们都是本规范的忠实文档审阅者。
In addition, the authors would like to thank the following for their numerous reviews and comments to this document:
此外，作者还要感谢以下各方对本文件的众多评论和意见：
o Magnus Westerlund
o 马格纳斯·韦斯特隆德
o Stephen Kent
o 斯蒂芬肯特
o Pasi Eronen
o 帕西奥宁
o Joseph Touch
o 约瑟夫·图奇
o Tero Kivinen
o 泰罗基文
o Jonah Pezeshki
o 约拿·佩泽什基
o Lars-Erik Jonsson
o 拉尔斯·埃里克·琼森
o Jan Vilhuber
o 扬·维尔胡伯
o Dan Wing
o 丹荣
o Kristopher Sandlund
o 克里斯托弗·桑德隆德
o Ghyslain Pelletier
o 吉斯兰·佩利蒂埃
o David Black
o 大卫·布莱克
o Tim Polk
o 蒂姆·波尔克
o Brian Carpenter
o 布莱恩·卡彭特
Finally, the authors would also like to thank Tom Conkle, Renee Esposito, Etzel Brower, and Michele Casey of Booz Allen Hamilton for their assistance in completing this work.
最后，作者还要感谢Booz Allen Hamilton的Tom Conkle、Renee Esposito、Etzel Brower和Michele Casey为完成这项工作提供的帮助。
[ROHC] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.
[ROHC]Sandlund，K.，Pelletier，G.，和L-E.Jonsson，“鲁棒头压缩（ROHC）框架”，RFC 57952010年3月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[ROHC-TERM] Jonsson, L-E., "Robust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[ROHC-TERM]Jonsson，L-E.“鲁棒头压缩（ROHC）：术语和信道映射示例”，RFC 3759，2004年4月。
[BRA97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BRA97]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2]Kaufman，C.，“互联网密钥交换（IKEV2）协议”，RFC4306，2005年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]Kent，S.，“IP封装安全有效负载（ESP）”，RFC 4303，2005年12月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[IPSEC-ROHC] Ertekin, E., Christou, C., and C. Bormann, "IPsec Extensions to Support Robust Header Compression over IPsec", RFC 5858, May 2010.
[IPSEC-ROHC]Ertekin，E.，Christou，C.，和C.Bormann，“支持IPSEC上的健壮头压缩的IPSEC扩展”，RFC 5858，2010年5月。
[IKE-ROHC] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. Bormann, "IKEv2 Extensions to Support Robust Header Compression over IPsec", RFC 5857, May 2010.
[IKE-ROHC]Ertekin，E.，Christou，C.，Jasani，R.，Kivinen，T.，和C.Bormann，“IKEv2扩展以支持IPsec上的健壮报头压缩”，RFC 5857，2010年5月。
[PROTOCOL] IANA, "Assigned Internet Protocol Numbers", <http://www.iana.org>.
[协议]IANA，“分配的互联网协议编号”<http://www.iana.org>.
[IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[IPCOMP]Shacham，A.，Monsour，B.，Pereira，R.，和M.Thomas，“IP有效载荷压缩协议（IPCOMP）”，RFC 31732001年9月。
[ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008.
[ROHCV2]Pelletier，G.和K.Sandlund，“鲁棒头压缩版本2（ROHCV2）：RTP、UDP、IP、ESP和UDP Lite的配置文件”，RFC 52252008年4月。
[REORDR] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006.
[REORDR]Pelletier，G.，Jonsson，L-E.，和K.Sandlund，“鲁棒报头压缩（ROHC）：可以对数据包重新排序的信道上的ROHC”，RFC 42242006年1月。
Authors' Addresses
作者地址
Emre Ertekin Booz Allen Hamilton 5220 Pacific Concourse Drive, Suite 200 Los Angeles, CA 90045 US
Emre Ertekin Booz Allen Hamilton 5220美国加利福尼亚州洛杉矶太平洋广场大道200号套房，邮编90045
EMail: ertekin_emre@bah.com
EMail: ertekin_emre@bah.com
Rohan Jasani Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US
Rohan Jasani Booz Allen Hamilton 13200林地公园Herndon博士，弗吉尼亚州，美国20171
EMail: ro@breakcheck.com
EMail: ro@breakcheck.com
Chris Christou Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US
Chris Christou Booz Allen Hamilton 13200林地公园Herndon博士，弗吉尼亚州，美国20171
EMail: christou_chris@bah.com
EMail: christou_chris@bah.com
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28334 Germany
卡斯滕·鲍曼大学不来梅邮政学院330440不来梅D-28334德国
EMail: cabo@tzi.org
EMail: cabo@tzi.org