Internet Engineering Task Force (IETF) E. Ertekin
Request for Comments: 5858 C. Christou
Category: Standards Track Booz Allen Hamilton
ISSN: 2070-1721 C. Bormann
Universitaet Bremen TZI
May 2010
Internet Engineering Task Force (IETF) E. Ertekin
Request for Comments: 5858 C. Christou
Category: Standards Track Booz Allen Hamilton
ISSN: 2070-1721 C. Bormann
Universitaet Bremen TZI
May 2010
IPsec Extensions to Support Robust Header Compression over IPsec
IPsec扩展支持IPsec上的健壮头压缩
Abstract
摘要
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 Security Policy Database (SPD) and Security Association Database (SAD) are required. This document describes the IPsec extensions required to support ROHCoIPsec.
将健壮的报头压缩（ROHC）与IPsec（ROHCoIPsec）集成在一起，可以提供IP安全服务和高效的带宽利用率。但是，为了将ROHC与IPsec集成，需要对安全策略数据库（SPD）和安全关联数据库（SAD）进行扩展。本文档描述了支持ROHCoIPsec所需的IPsec扩展。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc5858.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5858.
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 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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. Terminology .....................................................3
3. Extensions to IPsec Databases ...................................3
3.1. Security Policy Database (SPD) .............................4
3.2. Security Association Database (SAD) ........................5
4. Extensions to IPsec Processing ..................................6
4.1. Identification of Header-Compressed Traffic ................6
4.2. Verifying the Integrity of Decompressed Packet Headers .....6
4.2.1. ICV Computation and Integrity Verification ..........7
4.3. ROHC Segmentation and IPsec Tunnel MTU .....................8
4.4. Nested IPComp and ROHCoIPsec Processing ....................9
5. Security Considerations ........................................10
6. IANA Considerations ............................................10
7. Acknowledgments ................................................11
Appendix A. ASN.1 Representation for ROHCoIPsec ...................12
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................14
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Extensions to IPsec Databases ...................................3
3.1. Security Policy Database (SPD) .............................4
3.2. Security Association Database (SAD) ........................5
4. Extensions to IPsec Processing ..................................6
4.1. Identification of Header-Compressed Traffic ................6
4.2. Verifying the Integrity of Decompressed Packet Headers .....6
4.2.1. ICV Computation and Integrity Verification ..........7
4.3. ROHC Segmentation and IPsec Tunnel MTU .....................8
4.4. Nested IPComp and ROHCoIPsec Processing ....................9
5. Security Considerations ........................................10
6. IANA Considerations ............................................10
7. Acknowledgments ................................................11
Appendix A. ASN.1 Representation for ROHCoIPsec ...................12
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................14
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 Compression (ROHC, [ROHC]) with IPsec (ROHCoIPsec, [ROHCOIPSEC]) can reduce the packet overhead associated with IPsec-protected flows.
使用IPsec（[IPsec]）保护为IP流量提供各种安全服务。然而，这些好处是以额外的数据包头为代价的，这会增加数据包开销。通过压缩这些数据包的内部报头，鲁棒报头压缩（ROHC，[ROHC]）与IPsec（ROHCoIPsec，[ROHCoIPsec]）的集成可以减少与IPsec保护流相关的数据包开销。
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.
受IPsec保护的流量通过安全关联（SA）传输，其参数是根据具体情况进行协商的。安全策略数据库（SPD）指定要向IP数据报提供的服务，与已建立的SA相关联的参数存储在安全关联数据库（SAD）中。对于ROHCoIPsec，需要对SPD和SAD进行各种扩展，包括ROHC相关参数。
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.
此外，需要对IPsec处理进行三个扩展。首先，必须定义识别ROHC数据包的机制。其次，需要一种机制来确保解压缩数据包的完整性。最后，嵌套IP压缩（IPComp[IPComp]）、ROHC和IPsec处理时，必须枚举入站和出站处理的顺序。
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]中所述进行解释。
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.
以下小节规定了ROHCoIPsec必须支持的SPD和SAD扩展。SPD中的ROHCoIPsec字段用于在子SA初始化或重新设置密钥期间填充SAD中的ROHCoIPsec参数。
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.
值得注意的是，这些扩展对现有SPD字段或SAD参数没有任何影响。因此，ROHCoIPsec实现与不支持头压缩的IPsec实现向后兼容。
Appendix A provides an example ASN.1 representation of an SPD that is extended to support ROHC.
附录A提供了扩展为支持ROHC的SPD的ASN.1表示示例。
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.
通常，SPD负责指定提供给IP数据报的安全服务。SPD中的条目指定如何导出SAD条目的相应值。为了支持ROHC，SPD扩展为包括每通道ROHC参数。现有IPsec SPD参数和ROHC参数共同决定向数据包提供的安全和报头压缩服务。
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.
RFC 4301[IPSEC]第4.4.1.2节定义了每个SPD条目中包含的字段。为了支持ROHC，SPD中增加了几个处理信息字段；这些字段包含有关本地ROHC实例支持的ROHC配置文件和通道参数的信息。
If the processing action associated with the selector sets is PROTECT, then the processing info must be extended with the following ROHC channel parameters:
如果与选择器集关联的处理操作为保护，则必须使用以下ROHC通道参数扩展处理信息：
MAX_CID: This 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).
MAX_CID：此字段指示将由本地解压缩程序解压缩的最高上下文ID。MAX_CID必须至少为0，最多为16383（值0表示有一个上下文）。
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 Cyclic Redundancy Check (CRC) and the ROHC Integrity Check Value (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 5795 [ROHC] and Section 6.1 of RFC 5225 [ROHCV2]), which indicates that no segment headers are allowed on the ROHCoIPsec channel.
MRRU：MRRU参数表示本地解压器预期从ROHC段重新组装的最大重构单元（以八位字节为单位）的大小。该尺寸包括循环冗余校验（CRC）和ROHC完整性校验值（ICV）。注：由于无法保证ROHC数据包的顺序传送，因此MRRU参数应设置为0（如RFC 5795[ROHC]第5.2.5.1节和RFC 5225[ROHCV2]第6.1节所述），这表示Rohciopsec信道上不允许有段头。
PROFILES: This field is a list of ROHC profiles supported by the local decompressor. Possible values for this list are contained in the "RObust Header Compression (ROHC) Profile Identifiers" registry [ROHCPROF].
配置文件：此字段是本地解压缩程序支持的ROHC配置文件列表。此列表的可能值包含在“鲁棒头压缩（ROHC）配置文件标识符”注册表[ROHCPROF]中。
In addition to these ROHC channel parameters, a ROHC integrity algorithm and a ROHC ICV Length field MUST be included within the SPD:
除这些ROHC信道参数外，SPD中还必须包含ROHC完整性算法和ROHC ICV长度字段：
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
ROHC INTEGRITY ALGORITHM：该字段是ROHCoIPsec实例支持的完整性算法列表。ROHC过程将使用该方法确保数据包头正确解压缩（见第4.2节）。中指定了必须支持的身份验证算法
"Authentication Algorithms" table in Section 3.1.1 ("ESP Encryption and Authentication Algorithms") of RFC 4835 [CRYPTO-ALG] (or its successor).
RFC 4835[CRYPTO-ALG]（或其后续版本）第3.1.1节（“ESP加密和认证算法”）中的“认证算法”表。
ROHC ICV LENGTH: This field specifies the length of the ICV that is used in conjunction with the ROHC integrity algorithm.
ROHC ICV长度：该字段指定与ROHC完整性算法一起使用的ICV长度。
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 (i.e., 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 bi-directional Mode.
SPD中省略了其他几个ROHC通道参数，因为它们是隐式设置的。省略的信道参数为大CID和反馈CID。必须根据最大CID的值设置大CIDS通道参数（即，如果最大CID<=15，则大CIDS假定为0）。最后，通道参数的ROHC反馈_必须设置为与SA反向关联的ROHC通道。如果反向SA不存在，则不设置信道参数的反馈_，且ROHC不得在双向模式下运行。
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.
SAD中的每个条目定义与每个已建立SA关联的参数。除非针对特定字段断言“从数据包填充”（PFP）标志，否则SAD条目在SA创建期间由相应的SPD条目确定。
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.
SAD中包含的数据项在RFC 4301[IPSEC]第4.4.2.1节中定义。为了支持ROHC，SAD必须包含一个“ROHC数据项”；此数据项包含ROHC实例使用的参数。入站和出站SAs都存在ROHC数据项。
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.
ROHC数据项包括SA的ROHC通道参数。上述第3.1节列举了这些信道参数（即最大CID、配置文件、MRRU）。对于入站SAs，ROHC数据项必须指定本地解压缩程序实例使用的ROHC通道参数；相反，对于出站SAs，ROHC数据项必须指定本地压缩程序实例使用的ROHC通道参数。
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.
除了这些ROHC通道参数外，入站和出站SAs的ROHC数据项必须包括三个附加参数。具体而言，这些参数存储完整性算法、算法各自的密钥以及ROHC流程使用的ICV长度（见第3.2节）。完整性算法及其相关密钥用于计算指定长度的ROHC ICV；此ICV用于验证解压缩后的数据包头。
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 Sections 6.1 and 6.2 in RFC 3759 [ROHC-TERM].
最后，对于入站SAs，ROHC数据项必须包含参数的反馈。该参数是对相同压缩端点之间相反方向（即出站SA）的ROHC通道的引用。与入站SA相关联的ROHC信道和与出站SA相关联的ROHC信道可耦合以形成RFC 3759[ROHC-TERM]第6.1和6.2节中定义的双向ROHC信道。
"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 [IKE-ROHC].
“ROHC数据项”值可手动初始化（即，手动SAs的管理配置），或通过密钥交换协议（例如，IKEv2[IKEv2]）初始化，该协议已扩展以支持ROHC参数[IKE-ROHC]的信令。
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., Authentication Header (AH) [AH], Encapsulating Security Payload (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.
“ROHC”协议标识符用于识别启用ROHC的SA上的报头压缩流量。如果出站数据包具有压缩的报头，则必须将安全协议报头的下一报头字段（例如，身份验证报头（AH）[AH]，封装安全有效载荷（ESP）[ESP]）设置为“ROHC”协议标识符。如果数据包报头未被ROHC压缩，则下一报头字段不包含“ROHC”协议标识符。相反，对于入站数据包，必须检查security protocol Next Header字段的值，以确定该数据包是否包含ROHC报头，从而确定其是否需要ROHC解压缩。
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.
“ROHC”协议标识符用于ROHCoIPsec以外的用途目前尚未定义。使用分配的未来协议（例如，多跳环境中ROHC的其他应用）需要指定ROHC压缩器和解压缩器之间的逻辑压缩通道。此外，这些规范将要求在安全协议头的下一个头字段的上下文之外，调查与使用“ROHC”协议标识符相关的安全注意事项。
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.
如[ROHCOIPSEC]第6.1.4节所述，ROHC本质上是一种有损压缩算法：ROHC对等方之间重大数据包重新排序或丢失的后果可能包括未检测到的解压缩故障，其中错误数据包被转发到受保护域。
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.
为了确保解压缩的报头与原始报头相同，ROHCoIPsec可以使用附加的完整性算法（和相应的密钥）来计算第二个完整性检查值（ICV）。该ROHC ICV必须通过未压缩的IP报头以及更高层报头和数据包有效负载进行计算。计算时，ICV附加到ROHC压缩数据包。在解压缩器处，解压缩的分组（包括未压缩的IP报头、高层报头和分组有效载荷；但不包括认证数据）将与完整性算法（及其各自的密钥）一起使用，以计算将与附加的ICV进行比较的值。如果这些值不相同，则必须丢弃解压缩的数据包。
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.
图1说明了ROHCoIPsec处理的IPv4数据包的组成。在本例中，应用了TCP/IP压缩，并使用隧道模式ESP处理数据包。
BEFORE COMPRESSION AND APPLICATION OF ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
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|
------------------------------------------------------
AFTER ROHCOIPSEC COMPRESSION AND APPLICATION OF ESP
------------------------------------------------------
IPv4 | new IP hdr | | Cmpr. | | ROHC | ESP | ESP|
|(any options)| ESP | Hdr. |Data| ICV |Trailer| ICV|
------------------------------------------------------
Figure 1. Example of a ROHCoIPsec-Processed Packet
图1。ROHCoIPsec处理的数据包示例
Note: At the decompressor, the ROHC ICV field is not included in the calculation of the ROHC ICV.
注：在减压器处，ROHC ICV字段不包括在ROHC ICV的计算中。
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.
为了正确验证解压缩数据包的完整性，ROHCoIPsec的处理步骤必须按特定顺序执行，如下所示。
For outbound packets that are processed by ROHC and are IPsec-protected:
对于ROHC处理并受IPsec保护的出站数据包：
o Compute an ICV for the uncompressed packet with the negotiated (ROHC) integrity algorithm and its respective key.
o 使用协商（ROHC）完整性算法及其相应密钥计算未压缩数据包的ICV。
o Compress the packet headers (as specified by the ROHC process).
o 压缩数据包头（按照ROHC流程的规定）。
o Append the ICV to the compressed packet.
o 将ICV附加到压缩包。
o Apply AH or ESP processing to the packet, as specified in the appropriate SAD entry.
o 按照相应SAD条目中的规定，对数据包应用AH或ESP处理。
For inbound packets that are to be decompressed by ROHC:
对于要由ROHC解压缩的入站数据包：
o Apply AH or ESP processing, as specified in the appropriate SAD entry.
o 按照相应SAD条目中的规定，应用AH或ESP处理。
o Remove the ICV from the packet.
o 从数据包中取出ICV。
o Decompress the packet header(s).
o 解压缩数据包头。
o Compute an ICV for the decompressed packet with the negotiated (ROHC) integrity algorithm and its respective key.
o 使用协商（ROHC）完整性算法及其相应密钥计算解压缩数据包的ICV。
o 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.
o 将计算的ICV与在压缩器处计算的原始ICV进行比较：如果这两个值不同，则必须丢弃数据包；否则，请恢复IPsec处理。
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 Path MTU (PMTU):
在某些情况下，ROHCoIPsec处理的数据包可能超过IPsec隧道MTU的大小。RFC 4301[IPSEC]目前规定了超出SA路径MTU（PMTU）的出站流量的以下要求：
Case 1: Original (cleartext) packet is IPv4 and has the Don't Fragment (DF) bit set. The implementation should discard the packet and send a PMTU ICMP message.
案例1：原始（明文）数据包是IPv4，并且设置了Don't Fragment（DF）位。实现应丢弃该数据包并发送PMTU ICMP消息。
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.
案例2：原始（明文）数据包是IPv4，DF位为clear。实现应该分段（根据其配置在加密之前或之后），然后转发这些分段。它不应发送PMTU ICMP消息。
Case 3: Original (cleartext) packet is IPv6. The implementation should discard the packet and send a PMTU ICMP message.
案例3：原始（明文）数据包是IPv6。实现应丢弃该数据包并发送PMTU ICMP消息。
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.
对于ROHCoIPsec处理模型，上述程序有一个微小的变化。此更改适用于案例2的预加密碎片。由于当前的ROHC压缩配置文件不支持IP数据包片段的压缩，因此在ROHC处理之前不得发生预加密碎片。
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.
如果压缩分组超过SA PMTU，并且MRRU非零，则可以使用ROHC分段来划分分组，其中每个分段符合隧道MTU。ROHC分段必须在AH或ESP处理之前进行。由于无法保证ROHC段的订单交付，因此不建议使用ROHC段。
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.
如果应用分段，则该过程必须考虑IPsec过程施加的额外开销（例如，AH或ESP开销、加密同步数据、额外IP报头等），以便最终IPsec处理的分段小于隧道MTU。分段后，每个ROHC段由启用ROHC的SA上实例化的适当安全协议（例如AH、ESP）连续处理。由于ROHC段是连续处理的，因此通过ROHC信道传输的每个段的相关AH/ESP序列号必须增加1。因此，在所有ROHC段接收AH/ESP处理后，这些段可以通过一系列连续的AH/ESP序列号来识别（在远程IPsec实现中）。
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 of RFC 5795 [ROHC]), and attempt reconstruction using the ROHC segmentation protocol (Section 5.2.5 of RFC 5795 [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.
对于MRRU为非零的通道，ROHCoIPsec解压缩器必须重新组装接收到的ROHC段。为此，解压器必须识别ROHC段（如RFC 5795[ROHC]第5.2节所述），并尝试使用ROHC分段协议（RFC 5795[ROHC]第5.2.5节）进行重建。为协助重建过程，应使用AH/ESP序列号来识别可能已重新排序的段。如果重建失败，则必须丢弃数据包。
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.
如第3.2.1节所述，如果ROHC完整性算法用于验证数据包头的解压缩，则该ICV将附加到压缩数据包中。如果执行ROHC分段，则对压缩包和附加的ICV执行分段算法。请注意，ICV未附加到每个ROHC段。
Under certain circumstances, IPsec implementations will not process (or receive) unprotected ICMP messages, or they will not have a Path MTU estimated 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.
在某些情况下，IPsec实现不会处理（或接收）未受保护的ICMP消息，或者它们不会具有路径MTU估计值。在这些情况下，IPsec实现不应尝试分割ROHC压缩数据包，因为它不能完全洞察未受保护域中的路径MTU。
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.
IPComp（[IPComp]）是另一种可以实现以减小IP数据报大小的机制。如果IPComp和ROHCoIPsec以嵌套方式实现，则出站和入站数据包必须遵循以下步骤。
For outbound packets that are to be processed by IPComp and ROHC:
对于将由IPComp和ROHC处理的出站数据包：
o The ICV is computed for the uncompressed packet, and the appropriate ROHC compression profile is applied to the packet.
o 针对未压缩的数据包计算ICV，并对数据包应用适当的ROHC压缩配置文件。
o IPComp is applied, and the packet is sent to the IPsec process.
o 应用IPComp，并将数据包发送到IPsec进程。
o The security protocol is applied to the packet.
o 安全协议应用于数据包。
Conversely, for inbound packets that are to be both ROHC- and IPComp-decompressed:
相反，对于同时进行ROHC-和IPComp解压缩的入站数据包：
o A packet received on a ROHC-enabled SA is IPsec-processed.
o 在启用ROHC的SA上接收的数据包将被IPsec处理。
o The datagram is decompressed based on the appropriate IPComp algorithm.
o 数据报根据适当的IPComp算法进行解压缩。
o The packet is sent to the ROHC module for header decompression and integrity verification.
o 数据包被发送到ROHC模块，用于报头解压缩和完整性验证。
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.
ROHCOIPSEC实现者应该考虑用于验证解压缩报头的完整性检查算法所提供的保护强度。未能实现强完整性检查算法会增加ROHCoIPsec设备将无效解压缩的数据包转发到受保护域的可能性。
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.
ROHCoIPsec的实施可能会增加流量分析的敏感性，其中攻击者可以通过监控加密数据包的相对大小来识别新流量（即，一组“长”数据包，然后是一长系列“短”数据包可能指示某些ROHCoIPsec实施的新流量）。为了减轻这种担忧，可以使用ROHC填充机制来任意地向传输的分组添加填充，以随机化分组大小。然而，这种技术降低了报头压缩带来的总体效率效益。
IANA has allocated the value 142 to "ROHC" within the "Protocol Numbers" registry [PROTOCOL]. This value will be used to indicate that the next-level protocol header is a ROHC header.
IANA已将值142分配给“协议编号”注册表[协议]中的“ROHC”。该值将用于指示下一级协议头是ROHC头。
The authors would like to thank Sean O'Keeffe, James Kohler, Linda Noone of the Department of Defense, and Rich Espy of OPnet for their contributions and support for developing 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.：他们都是本规范的忠实文档审阅者。
Finally, 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 Lars-Erik Jonsson
o 拉尔斯·埃里克·琼森
o Carl Knutsson
o 卡尔克努特森
o Pasi Eronen
o 帕西奥宁
o Jonah Pezeshki
o 约拿·佩泽什基
o Tero Kivinen
o 泰罗基文
o Joseph Touch
o 约瑟夫·图奇
o Rohan Jasani
o 罗汉·贾萨尼
o Elwyn Davies
o 埃尔温·戴维斯
o Bert Wijnen
o 伯特·维宁
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.
本附录是描述IPsec SPD中包含的ROHCoIPsec参数的另一种方式。它使用RFC 4301[IPSEC]附录C中提供的ASN.1语法部分。此外，还定义了几个新结构。
This syntax has been successfully compiled. However, it is merely illustrative and need not be employed in an implementation to achieve compliance.
此语法已成功编译。然而，它只是说明性的，不需要在实现中使用它来实现遵从性。
The "Processing" data structure, defined in Appendix C of RFC 4301, is augmented to include a ROHC parameters element as follows:
RFC 4301附录C中定义的“处理”数据结构经过扩充，包括ROHC参数元素，如下所示：
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
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
}
}
The following data structures describe these ROHC parameters:
以下数据结构描述了这些ROHC参数：
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
}
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
RohcProfiles ::= SET OF RohcProfile
RohcProfile ::= INTEGER {
rohcv1-rtp (1),
rohcv1-udp (2),
rohcv1-esp (3),
rohcv1-ip (4),
RohcProfile ::= INTEGER {
rohcv1-rtp (1),
rohcv1-udp (2),
rohcv1-esp (3),
rohcv1-ip (4),
rohcv1-tcp (6), rohcv1-rtp-udpLite (7), rohcv1-udpLite (8),
rohcv1 tcp（6）、rohcv1 rtp udpLite（7）、rohcv1 udpLite（8），
rohcv2-rtp (257), rohcv2-udp (258), rohcv2-esp (259), rohcv2-ip (260),
rohcv2 rtp（257）、rohcv2 udp（258）、rohcv2 esp（259）、rohcv2 ip（260），
rohcv2-rtp-udpLite (263), rohcv2-udpLite (264)
rohcv2 rtp udpLite（263），rohcv2 udpLite（264）
-- values taken from [ROHCPROF]
--取自[ROHCPROF]的值
}
}
RohcIntegAlgs ::= SEQUENCE {
algorithm RohcIntegAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
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)
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]
-- values taken from "Transform Type 3 - Integrity
-- Algorithm Transform IDs" at [IKEV2-PARA]
}
}
[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] 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月。
[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月。
[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月。
[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月。
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2]Kaufman，C.，“互联网密钥交换（IKEV2）协议”，RFC4306，2005年12月。
[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月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]Kent，S.，“IP封装安全有效负载（ESP）”，RFC 4303，2005年12月。
[ROHCOIPSEC] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, "Integration of Header Compression over IPsec Security Associations", RFC 5856, May 2010.
[ROHCOIPSEC]Ertekin，E.，Jasani，R.，Christou，C.，和C.Bormann，“IPsec安全关联上的头压缩集成”，RFC 5856，2010年5月。
[ROHCPROF] IANA, "RObust Header Compression (ROHC) Profile Identifiers", <http://www.iana.org>.
[ROHCPROF]IANA，“鲁棒头压缩（ROHC）配置文件标识符”<http://www.iana.org>.
[CRYPTO-ALG] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[CRYPTO-ALG]Manral，V.，“封装安全有效载荷（ESP）和认证头（AH）的密码算法实现要求”，RFC 4835，2007年4月。
[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月。
[PROTOCOL] IANA, "Assigned Internet Protocol Numbers", <http://www.iana.org>.
[协议]IANA，“分配的互联网协议编号”<http://www.iana.org>.
[IKEV2-PARA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org>.
[IKEV2-PARA]IANA，“互联网密钥交换版本2（IKEV2）参数”<http://www.iana.org>.
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
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