[要約] RFC 5858は、IPsec上でRobust Header Compression（RHC）をサポートするための拡張機能を提供します。その目的は、IPsecトンネル上でのネットワークトラフィックの効率的な圧縮と転送を可能にすることです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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トラフィックにさまざまなセキュリティサービスが提供されます。ただし、これらの利点は、パケットのオーバーヘッドを増加させる追加のパケットヘッダーを犠牲にしてもたらされます。これらのパケットの内側ヘッダーを圧縮することにより、堅牢なヘッダー圧縮（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で保護されたトラフィックは、セキュリティ協会（SAS）を介して行われ、そのパラメーターはケースバイケースでネゴシエートされます。セキュリティポリシーデータベース（SPD）は、IPデータグラムに提供されるサービスを指定し、確立されたSASに関連付けられたパラメーターはセキュリティ協会データベース（SAD）に保存されます。Rohcoipsecの場合、SPDへのさまざまな拡張機能とROHC関連のパラメーターが組み込まれている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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
次のサブセクションでは、SPDへの拡張機能と、Rohcoipsecのサポートが必要な悲しいものを指定します。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は1つのコンテキストを持つことを意味します）。
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 [ROHC]およびRFC 5225 [ROHCV2]のセクション6.1）を設定する必要があります。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 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 Integrity Algorithmと組み合わせて使用される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の値に基づいて設定する必要があります（つまり、max_cidが<= 15の場合、large_cidsは0と想定されます）。最後に、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に関連付けられたパラメーターを定義します。特定のフィールドに対して「Packet From Packet」（PFP）フラグが主張されない限り、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とアウトバウンド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、プロファイル、MRRU）は、セクション3.1で上記で列挙されています。インバウンドSASの場合、ROHCデータ項目は、ローカルDecompressorインスタンスで使用される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チャネルパラメーターに加えて、インバウンドSAとアウトバウンドSAの両方のROHCデータ項目には、3つの追加パラメーターを含める必要があります。具体的には、これらのパラメーターは、整合性アルゴリズム、アルゴリズムのそれぞれのキー、および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データ項目にはfeedback_forパラメーターを含める必要があります。パラメーターは、同じ圧縮エンドポイント間の反対方向（つまり、アウトバウンド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用に管理上構成）、またはROHCパラメーターのシグナル伝達をサポートするために拡張されたキーエクスチェンジプロトコル（IKEV2 [IKEV2]）を介して初期化される場合があります[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は追加の整合性アルゴリズム（およびそれぞれのキー）を使用して、2番目の整合性チェック値（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
図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と比較します。これらの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 PATH 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：オリジナル（ClearText）パケットはIPv4であり、Dont 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：元の（ClearText）パケットはIPv4で、DFが少しクリアされています。実装は（構成ごとに暗号化の前または暗号化の前または後）フラグメントを断片化し、フラグメントを転送する必要があります。PMTU ICMPメッセージを送信しないでください。
Case 3: Original (cleartext) packet is IPv6. The implementation should discard the packet and send a PMTU ICMP message.
ケース3：オリジナル（ClearText）パケットは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つの小さな変更があります。この変更は、ケース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処理セグメントがより少ないように、IPSECプロセス（たとえば、AHまたはESPオーバーヘッド、暗号同期データ、追加のIPヘッダーなど）によって課される追加のオーバーヘッドを説明する必要があります。トンネルMTU。セグメンテーション後、各ROHCセグメントは、ROHC対応SAにインスタンス化された適切なセキュリティプロトコル（AH、ESPなど）によって連続して処理されます。ROHCセグメントは連続して処理されるため、関連するAH/ESPシーケンス数は、ROHCチャネル上に送信される各セグメントに対して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のセクション5.2 [ROHC]）、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の実装は、保護されていないドメインのパスMTUについての完全な洞察がないため、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データグラムのサイズを縮小するために実装できるもう1つのメカニズムです。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 of the 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 Pasi Eronen
o Jonah Pezeshki
o ジョナ・ペゼシュキ
o Tero Kivinen
o テロキビネン
o Joseph Touch
o ジョセフ・タッチ
o Rohan Jasani
o ロハン・ジャサニ
o Elwyn Davies
o エルウィン・デイビス
o Bert Wijnen
o Bert Wijnen
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),
ROHCV1-TCP（6）、ROHCV1-RTP-UDPLITE（7）、ROHCV1-UUDPLITE（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-UUDPLITE（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] Kent、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.、Pelletier、G。、およびL-e。Jonsson、「The Robust Header Compression（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.、Pereira、R。、およびM. Thomas、「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] 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、「Robust Header Compressionバージョン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] Kaufman、C。、「Internet Key Exchange（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. 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。、「セキュリティペイロード（ESP）のIPカプセル化」、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 Pacific Concourse Drive、Suite 200 Los Angeles、CA 90045 US
EMail: ertekin_emre@bah.com
Chris Christou Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US
クリス・クリストゥ・ブーズ・アレン・ハミルトン13200ウッドランドパーク博士ハーンドン、バージニア州20171米国
EMail: christou_chris@bah.com
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28334 Germany
Carsten Bormann Universitaet Bremen Tzi Postfach 330440 Bremen D-28334ドイツ
EMail: cabo@tzi.org