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
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.
IPsecの（ROHCoIPsec）とロバストヘッダ圧縮（ROHC）を統合することで、IPセキュリティサービスを組み合わせた利点と効率的な帯域幅の利用を提供しています。しかし、IPsecのでROHCを統合するために、セキュリティポリシーデータベース（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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
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トラフィックのためのさまざまなセキュリティサービスを提供しています。しかし、これらの利点は、パケットのオーバーヘッドを増加させ、追加のパケットヘッダの費用で来ます。これらのパケットの内部ヘッダを圧縮することにより、IPsecの（ROHCoIPsec、[ROHCOIPSEC]）とロバストヘッダ圧縮（ROHC、[ROHC]）の統合は、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データグラムに提供されるサービス、およびセキュリティアソシエーションデータベース（SAD）に格納されている確立されているのSAに関連するパラメータを指定します。 ROHCoIPsecために、ROHC-関連するパラメータを組み込むSPDとSADに様々な拡張が必要とされています。
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処理には3つの拡張が必要とされています。まず、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
各SPDエントリ内に含まれるフィールドは、RFC 4301 [IPSEC]、セクション4.4.1.2で定義されています。 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のセクション5.2.5.1に記載されているようROHC]及びRFC 5225のセクション6.1 [ROHCV2]）、ことを示しています何セグメントヘッダーはROHCoIPsecチャネル上で許可されません。
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チャンネルのパラメータに加えて、ROHCの整合性アルゴリズムとROHC ICV長フィールドはSPD内に含まなければなりません：
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アルゴリズム：このフィールドは、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のセクション3.1.1（「ESP暗号化と認証アルゴリズム」）CRYPTO-ALG（またはその後継）に「認証アルゴリズム」テーブル。
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.
彼らは暗黙的に設定されているので、いくつかの他のROHCのチャネルパラメータは、SPDから省略されています。省略チャネルパラメータはLARGE_CIDSとFEEDBACK_FORです。 LARGE_CIDSチャネルパラメータは、（MAX_CIDが<= 15である場合、すなわち、LARGE_CIDSが0であると仮定される）MAX_CIDの値に基づいて設定されなければなりません。最後に、ROHC FEEDBACK_FORチャネルパラメータは、逆方向にSAに関連付けられたROHCチャンネルに設定しなければなりません。逆方向のSAが存在しない場合、FEEDBACK_FORチャネルパラメータが設定されていない、および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のインスタンスで使用されるパラメータが含まれています。 ROHCデータ項目は、インバウンドとアウトバウンドの両方のSAのために存在します。
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チャンネルパラメータを含んでいます。これらのチャネルパラメータ（すなわち、MAX_CID、PROFILES、MRRU）はセクション3.1で上記に列挙されています。インバウンドSAの、ROHCデータ項目がローカルデコンプレッサのインスタンスによって使用されるROHCチャネルパラメータを指定する必要があります。逆に、アウトバウンドSAの、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チャンネルのパラメータに加えて、インバウンドとアウトバウンドの両方のSAの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].
最後に、インバウンドSAの、ROHCデータ項目はFEEDBACK_FORパラメータを含まなければなりません。パラメータは、同一の圧縮エンドポイント間の逆方向のROHCチャネル（すなわち、アウトバウンドSA）への参照です。インバウンドSAおよびアウトバウンドSAに関連付けられたROHCのチャネルに関連付けられた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データ項目」値は手動で初期化されてもよい（すなわち、管理マニュアルのSAのために構成されている）、または鍵交換プロトコル（例えば、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」プロトコル識別子が含まれていません。逆に、インバウンドパケットに対して、セキュリティプロトコル次ヘッダーフィールドの値は、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.
ROHCoIPsec以外の目的のために、「ROHC」プロトコル識別子の使用は、現在定義されていません。割り当てを利用する将来のプロトコル（例えば、マルチホップ環境における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 |
----------------------------
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
ROHCoIPsec、処理されたパケットの図1の例
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).
（ROHC処理によって指定された）Oパケットのヘッダを圧縮します。
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.
適切なSADエントリに指定されているO、AHまたはESP処理を適用します。
o Remove the ICV from the packet.
パケットからPCMを削除します。
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を比較する：これらの2つの値が異なる場合、パケットは廃棄されなければなりません。それ以外の場合は、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.
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ビットがクリアされています。実装は、（その設定ごとに暗号化の前または後に）断片化し、その後の断片を転送する必要があります。これは、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処理モデルの場合は、上記の手順に1つの軽微な変更があります。この変更は、現在のROHC圧縮プロファイルは、IPパケットのフラグメントの圧縮をサポートしていないので、ケース2のための事前の暗号化、断片化、暗号化前の断片化は、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処理セグメントがより少ないことセグメンテーションが適用される場合、プロセスは、IPsec処理（例えば、AHまたはESPオーバーヘッド、暗号同期データ、付加的なIPヘッダ、等）によって課される追加のオーバヘッドを考慮しなければならないようなトンネルのMTU。分割後、各ROHCセグメントは連続的（例えば、AH、ESP）ROHC対応SA上でインスタンス適切なセキュリティプロトコルによって処理されます。 ROHCセグメントが連続して処理されるため、関連AH / ESPのシーケンス番号は、ROHCチャネルを介して送信された各セグメントに対してインクリメントされなければなりません。全て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のセクション5.2に記載のように、[ROHC]）を識別し、ROHC分割プロトコル（RFC 5795のセクション5.2.5 [ROHC]）を使用して再構築を試行しなければなりません。再構成プロセスを支援するために、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の推定値を持っていません。それが保護されていないドメイン内のパスMTUに完全な洞察力を持っていないとして、これらのケースでは、IPsec実装は、セグメントにROHC圧縮パケットを試みるべきではありません。
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は、「プロトコル番号」レジストリ[PROTOCOL]内の値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.
作者は彼らの貢献と、この文書を開発するための支援のためにショーン・オキーフ、ジェームズ・コーラー、国防総省のリンダ・ヌーン、およびOPNETのリッチEspyのを感謝したいと思います。
The authors would also like to thank Yoav Nir and Robert A Stangarone Jr.: both served as committed document reviewers for this specification.
著者らはまたヨアフニール、ロバート・A Stangaroneジュニアに感謝したいと思います。：両方は、この仕様書のためのコミット文書の校閲を務めていました。
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カールKnutsson
o Pasi Eronen
いいえパシEronenありません
o Jonah Pezeshki
OヨナPezeshki
o Tero Kivinen
いいえTERO Kivinenありません
o Joseph Touch
Oジョセフ・タッチ
o Rohan Jasani
OロハンJasani
o Elwyn Davies
のエルウィン・デイヴィス
o Bert Wijnen
Oバート・ワイン
Appendix A. ASN.1 Representation for ROHCoIPsec
ROHCoIPsecのための付録A. ASN.1表現
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
}
｝
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
}
RohcProfiles ::= SET OF RohcProfile
RohcProfile ::= INTEGER {
rohcv1-rtp (1),
rohcv1-udp (2),
rohcv1-esp (3),
rohcv1-ip (4),
rohcv1-tcp (6),
rohcv1-rtp-udpLite (7),
rohcv1-udpLite (8),
rohcv2-rtp (257), rohcv2-udp (258), rohcv2-esp (259), rohcv2-ip (260),
rohcv2-RTP（257）、rohcv2-UDP（258）rohcv2サブスピーシーズ（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 }
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]
}
｝
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[ROHC] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.
[ROHC] Sandlund、K.、ペルティエ、G.、およびL-E。ヨンソン、 "ロバストヘッダ圧縮（ROHC）フレームワーク"、RFC 5795、2010年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.、ペレイラ、R。、およびM.トーマス、 "IPペイロード圧縮プロトコル（のIPComp）"、RFC 3173、2001年9月。
[BRA97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BRA97]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ペルティエ、G.およびK. Sandlund、 "ロバストヘッダ圧縮バージョン2（ROHCv2）：RTP、UDP、IP、ESPとUDP-Liteのプロファイル"、RFC 5225、2008年4月。
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、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.ボルマン、 "IKEv2の拡張機能のIPsec上でロバストヘッダ圧縮をサポートするために"、RFC 5857は、2010年5月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]ケント、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.ボルマン、 "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.、RFC 4835、2007年4月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[ROHC-TERM] Jonsson, L-E., "Robust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[ROHC-TERM]ヨンソン、L-E、 "ロバストヘッダ圧縮（ROHC）：用語とチャンネルマッピングの例"。、RFC 3759、2004年4月。
[PROTOCOL] IANA, "Assigned Internet Protocol Numbers", <http://www.iana.org>.
[PROTOCOL] 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
エムレErtekinブーズ・アレン・ハミルトン5220太平洋コンコースドライブ、スイート200ロサンゼルス、CA 90045米国
EMail: ertekin_emre@bah.com
メールアドレス：ertekin_emre@bah.com
Chris Christou Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US
クリストスChristouのボアズ・アレン・ハミルトン13200ウッドランドパーク博士聞いた、NE 20171米国
EMail: christou_chris@bah.com
メールアドレス：christou_chris@bah.com
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28334 Germany
カルステンボルマンUniversitaetブレーメンTZI POSTFACH 330440 D-28334ブレーメンドイツ
EMail: cabo@tzi.org
メールアドレス：cabo@tzi.org