Internet Engineering Task Force (IETF) E. Ertekin
Request for Comments: 5856 R. Jasani
Category: Informational C. Christou
ISSN: 2070-1721 Booz Allen Hamilton
C. Bormann
Universitaet Bremen TZI
May 2010
Integration of Robust Header Compression over
IPsec Security Associations
Abstract
抽象
IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs).
IPセキュリティ（IPsec）は、IPトラフィックのための様々なセキュリティサービスを提供しています。しかし、IPsecの利点は、増加したオーバーヘッドのコストで来ます。この文書は、IPsec（ROHCoIPsec）上でロバストヘッダ圧縮（ROHC）を統合するための枠組みを概説します。 IPパケットの内部ヘッダを圧縮することにより、ROHCoIPsecは、IPsecセキュリティアソシエーション（SA）を超えるトラフィックの伝送に関連するオーバーヘッドの量を削減することを提案しています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5856.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5856で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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. Audience ........................................................3
3. Terminology .....................................................3
4. Problem Statement: IPsec Packet Overhead ........................4
5. Overview of the ROHCoIPsec Framework ............................5
5.1. ROHCoIPsec Assumptions .....................................5
5.2. Summary of the ROHCoIPsec Framework ........................5
6. Details of the ROHCoIPsec Framework .............................7
6.1. ROHC and IPsec Integration .................................7
6.1.1. Header Compression Protocol Considerations ..........9
6.1.2. Initialization and Negotiation of the ROHC Channel ..9
6.1.3. Encapsulation and Identification of Header
Compressed Packets .................................10
6.1.4. Motivation for the ROHC ICV ........................11
6.1.5. Path MTU Considerations ............................11
6.2. ROHCoIPsec Framework Summary ..............................12
7. Security Considerations ........................................12
8. IANA Considerations ............................................12
9. Acknowledgments ................................................13
10. Informative References ........................................14
This document outlines a framework for integrating ROHC [ROHC] over IPsec [IPSEC] (ROHCoIPsec). The goal of ROHCoIPsec is to reduce the protocol overhead associated with packets traversing between IPsec SA endpoints. This can be achieved by compressing the transport layer header (e.g., UDP, TCP, etc.) and inner IP header of packets at the ingress of the IPsec tunnel, and decompressing these headers at the egress.
この文書は、IPsec [IPSEC]（ROHCoIPsec）上ROHC [ROHC]を統合するための枠組みを概説します。 ROHCoIPsecの目標は、IPsec SAのエンドポイント間で通過するパケットに関連付けられたプロトコル・オーバーヘッドを低減することです。これは、IPsecトンネルの入口でパケットのトランスポート層ヘッダ（例えば、UDP、TCPなど）と内側IPヘッダを圧縮し、出口でのこれらのヘッダを解凍することによって達成することができます。
For ROHCoIPsec, this document assumes that ROHC will be used to compress the inner headers of IP packets traversing an IPsec tunnel. However, since current specifications for ROHC detail its operation on a hop-by-hop basis, it requires extensions to enable its operation over IPsec SAs. This document outlines a framework for extending the usage of ROHC to operate at IPsec SA endpoints.
ROHCoIPsecため、この文書では、ROHCは、IPsecトンネルを通過するIPパケットの内部ヘッダを圧縮するために使用されることを想定しています。しかし、ホップバイホップベースでROHCの詳細は現在の仕様その動作以来、それは、IPsec SAを超えるその動作を可能にするための拡張機能を必要とします。この文書は、IPsec SAのエンドポイントで動作するようにROHCの使用を拡張するための枠組みを概説します。
ROHCoIPsec targets the application of ROHC to tunnel mode SAs. Transport mode SAs only protect the payload of an IP packet, leaving the IP header untouched. Intermediate routers subsequently use this IP header to route the packet to a decryption device. Therefore, if ROHC is to operate over IPsec transport-mode SAs, (de)compression functionality can only be applied to the transport layer headers, and not to the IP header. Because current ROHC specifications do not include support for the compression of transport layer headers alone, the ROHCoIPsec framework outlined by this document describes the application of ROHC to tunnel mode SAs.
ROHCoIPsecトンネルモードSAにROHCを適用することを対象とします。トランスポート・モードSAは、そのままIPヘッダを残して、IPパケットのペイロードを保護します。中間ルータは、その後、復号化装置にルーティングするパケットをこのIPヘッダを使用します。 ROHCは、IPsecトランスポート・モードSA上で動作する場合したがって、（デ）圧縮機能は、トランスポート層ヘッダにはなく、IPヘッダに適用することができます。現在のROHC仕様は、単独でトランスポート層ヘッダの圧縮のためのサポートを含んでいないため、このドキュメントによって概説ROHCoIPsecフレームワークは、トンネルモードSAにROHCを適用することを記載しています。
The authors target members of both the ROHC and IPsec communities who may consider extending the ROHC and IPsec protocols to meet the requirements put forth in this document. In addition, this document is directed towards vendors developing IPsec devices that will be deployed in bandwidth-constrained IP networks.
著者は、この文書で出す要件を満たすためにROHCとIPsecプロトコルを拡張する検討することの両方ROHCとIPsecコミュニティのメンバーを対象としています。また、この文書は、帯域幅に制約のあるIPネットワークで展開されるIPSecデバイスを開発するベンダーに向けられています。
ROHC Process
ROHCプロセス
Generic reference to a ROHC instance (as defined in RFC 3759 [ROHC-TERM]) or any supporting ROHC components.
ROHCインスタンスへの一般的な基準（RFC 3759で定義されている[ROHC-TERM]）または任意の支持ROHCコンポーネント。
Compressed Traffic
圧縮されたトラフィック
Traffic that is processed through the ROHC compressor and decompressor instances. Packet headers are compressed and decompressed using a specific header compression profile.
ROHCコンプレッサとデコンプレッサのインスタンスによって処理されるトラフィック。パケットヘッダを圧縮し、特定のヘッダ圧縮プロファイルを使用して解凍されます。
Uncompressed Traffic
非圧縮トラフィック
Traffic that is not processed by the ROHC compressor instance. Instead, this type of traffic bypasses the ROHC process.
ROHCコンプレッサインスタンスによって処理されていないトラフィック。代わりに、このタイプのトラフィックは、ROHCプロセスをバイパスします。
IPsec Process
IPsec処理
Generic reference to the Internet Protocol Security (IPsec) process.
インターネットプロトコルセキュリティ（IPsec）のプロセスを一般的な参照。
Next Header
次のヘッダー
Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) field.
プロトコル（IPv4）のまたは次のヘッダ（IPv6の拡張）フィールドを指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BRA97].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [BRA97]に記載されているように解釈されます。
IPsec mechanisms provide various security services for IP networks. However, the benefits of IPsec come at the cost of increased per-packet overhead. For example, traffic flow confidentiality (generally leveraged at security gateways) requires the tunneling of IP packets between IPsec implementations. Although these IPsec tunnels will effectively mask the source-destination patterns that an intruder can ascertain, tunneling comes at the cost of increased packet overhead. Specifically, an Encapsulating Security Payload (ESP) tunnel mode SA applied to an IPv6 flow results in at least 50 bytes of additional overhead per packet. This additional overhead may be undesirable for many bandwidth-constrained wireless and/or satellite communications networks, as these types of infrastructure are not overprovisioned. ROHC applied on a per-hop basis over bandwidth-constrained links will also suffer from reduced performance when encryption is used on the tunneled header, since encrypted headers cannot be compressed. Consequently, the additional overhead incurred by an IPsec tunnel may result in the inefficient utilization of bandwidth.
IPsecのメカニズムは、IPネットワークの様々なセキュリティサービスを提供しています。しかし、IPsecの利点は、増加したパケット当たりのオーバーヘッドのコストで来ます。例えば、トラフィックフローの機密性は、（一般的にセキュリティゲートウェイにレバレッジ）IPsec実装との間のIPパケットのトンネリングを必要とします。これらのIPsecトンネルが効果的に侵入者が確認することができ、ソース先のパターンをマスクしますが、トンネリングが増加したパケットのオーバーヘッドのコストがかかります。具体的には、カプセル化セキュリティペイロード（ESP）トンネルモードSAは、パケットごとに追加のオーバーヘッドの少なくとも50バイトのIPv6フロー結果に適用されます。インフラストラクチャのこれらのタイプは、過剰供給されないように、この追加のオーバーヘッドは、多くの帯域幅制約無線および/または衛星通信ネットワークのために望ましくないことがあります。 ROHCは、暗号化がトンネリングヘッダを使用する場合、暗号化ヘッダを圧縮することができないためにも、性能低下を被る帯域幅制約リンクを介してホップ毎ベースで適用されます。したがって、IPsecトンネルによって発生した追加のオーバーヘッドは、帯域幅の非効率的な利用をもたらすことができます。
Packet overhead is particularly significant for traffic profiles characterized by small packet payloads (e.g., various voice codecs). If these small packets are afforded the security services of an IPsec tunnel mode SA, the amount of per-packet overhead is increased. Thus, a mechanism is needed to reduce the overhead associated with such flows.
パケットのオーバーヘッドは小さいパケットペイロード（例えば、様々な音声コーデック）によって特徴付けられるトラフィックプロファイルのために特に重要です。これらの小さなパケットがIPsecトンネルモードSAのセキュリティ・サービスを与えている場合、パケットごとのオーバヘッドの量が増加します。したがって、機構は、このようなフローに関連するオーバーヘッドを低減するために必要とされます。
The goal of ROHCoIPsec is to provide efficient transport of IP packets between IPsec devices without compromising the security services offered by IPsec. The ROHCoIPsec framework has been developed based on the following assumptions:
ROHCoIPsecの目標は、IPsecによって提供されるセキュリティサービスを損なうことなく、IPSecデバイス間のIPパケットの効率的な輸送を提供することです。 ROHCoIPsecフレームワークは、以下の仮定に基づいて開発されました：
o ROHC will be leveraged to reduce the amount of overhead associated with unicast IP packets traversing an IPsec SA.
O ROHCは、IPsec SAを通過するユニキャストIPパケットに関連付けられたオーバーヘッドの量を低減するために活用されます。
o ROHC will be instantiated at the IPsec SA endpoints, and it will be applied on a per-SA basis.
O ROHCは、IPsec SAのエンドポイントでインスタンス化され、それはSA毎に適用されます。
o Once the decompression operation completes, decompressed packet headers will be identical to the original packet headers before compression.
復元操作が完了したら、O、減圧パケットヘッダは、圧縮前の元のパケットヘッダと同一であろう。
ROHC reduces packet overhead in a network by exploiting intra- and inter-packet redundancies of network and transport-layer header fields of a flow.
ROHCは、流れのネットワーク及びトランスポート層ヘッダフィールドの内およびパケット間の冗長性を利用することによって、ネットワーク内のパケットのオーバーヘッドを減少させます。
Current ROHC protocol specifications compress packet headers on a hop-by-hop basis. However, IPsec SAs are instantiated between two IPsec endpoints. Therefore, various extensions to both ROHC and IPsec need to be defined to ensure the successful operation of the ROHC protocol at IPsec SA endpoints.
現在のROHCプロトコル仕様は、ホップバイホップベースでパケットのヘッダを圧縮します。しかし、IPsecのSAが2つのIPSecエンドポイント間でインスタンス化されます。したがって、ROHCとIPsecの両方の様々な拡張は、IPsec SAのエンドポイントにおけるROHCプロトコルの正常動作を保証するために定義される必要があります。
The specification of ROHC over IPsec SAs is straightforward, since SA endpoints provide source/destination pairs where (de)compression operations can take place. Compression of the inner IP and upper layer protocol headers in such a manner offers a reduction of packet overhead between the two SA endpoints. Since ROHC will now operate between IPsec endpoints (over multiple intermediate nodes that are transparent to an IPsec SA), it is imperative to ensure that its performance will not be severely impacted due to increased packet reordering and/or packet loss between the compressor and decompressor.
SAエンドポイントは、（デ）圧縮動作が行われることができる送信元/宛先ペアを提供するためのIPsec SAを上ROHCの仕様は、簡単です。このように内側IPと上位層プロトコルヘッダの圧縮は、二つのSAエンドポイント間のパケットのオーバーヘッドの削減を提供します。 ROHCは現在（のIPsec SAに透明である複数の中間ノード上）のIPsecエンドポイント間で動作するので、その性能が著しく増加によるパケット再配列及び/又はコンプレッサとデコンプレッサとの間のパケット損失に影響されないことを保証するために不可欠です。
In addition, ROHC can no longer rely on the underlying link layer for ROHC channel parameter configuration and packet identification. The ROHCoIPsec framework proposes that ROHC channel parameter configuration is accomplished by an SA management protocol (e.g., Internet Key Exchange Protocol version 2 (IKEv2) [IKEV2]), while identification of compressed header packets is achieved through the
また、ROHCはもはやROHCチャネルパラメータの設定およびパケット識別のための基本となるリンク層に頼ることはできません。 ROHCoIPsecフレームワークは、ROHCチャンネルのパラメータ設定を（例えば、インターネット鍵交換プロトコルバージョン2（IKEv2の）のIKEv2]）、圧縮ヘッダーパケットの識別を介して達成されている間SA管理プロトコルによって達成されることを提案しています
Next Header field of the security protocol (e.g., Authentication Header (AH) [AH], ESP [ESP]) header.
セキュリティプロトコル（例えば、認証ヘッダ（AH）[AH]、ESP [ESP]）ヘッダの次ヘッダフィールド。
Using the ROHCoIPsec framework proposed below, outbound and inbound IP traffic processing at an IPsec device needs to be modified. For an outbound packet, a ROHCoIPsec implementation will compress appropriate packet headers, and subsequently encrypt and/or integrity protect the packet. For tunnel mode SAs, compression may be applied to the transport layer and the inner IP headers. For inbound packets, an IPsec device must first decrypt and/or integrity check the packet. Then, decompression of the inner packet headers is performed. After decompression, the packet is checked against the access controls imposed on all inbound traffic associated with the SA (as specified in RFC 4301 [IPSEC]).
以下、提案ROHCoIPsecフレームワークを使用して、IPsecのデバイスにおいて送信および受信IPトラフィック処理を変更する必要があります。アウトバウンドパケットの場合は、ROHCoIPsecの実装は、適切なパケットヘッダを圧縮し、その後、暗号化および/または整合性がパケットを保護します。トンネルモードSAの、圧縮は、トランスポート層および内側IPヘッダに適用されてもよいです。着信パケットの場合は、IPsecの装置は、第1の復号化および/または完全性パケットをチェックする必要があります。次いで、内部パケットヘッダの解凍が行われます。解凍後、パケットはSA（RFC 4301で指定されるように[IPSEC]）に関連付けられたすべての着信トラフィックに課さアクセス制御に対してチェックされます。
Note: Compression of inner headers is independent from compression of the security protocol (e.g., ESP) and outer IP headers. ROHC profiles have been defined to allow for the compression of the security protocol and the outer IP header on a hop-by-hop basis. The applicability of ROHCoIPsec and hop-by-hop ROHC on an IPv4 ESP-processed packet [ESP] is shown below in Figure 1.
注：内部ヘッダの圧縮は、セキュリティプロトコル（例えば、ESP）および外側IPヘッダの圧縮とは独立です。 ROHCプロファイルは、ホップバイホップのセキュリティプロトコルおよび外側IPヘッダの圧縮を可能にするために定義されています。 ROHCoIPsecの適用性及びホップバイホップIPv4のESP処理パケットにROHC [ESP]図1において以下に示されています。
-----------------------------------------------------------
IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<-------(1)------->|<------(2)-------->|
(1) Compressed hop-by-hop by the ROHC [ROHC]
ESP/IP profile
(2) Compressed end-to-end by the ROHCoIPsec [IPSEC-ROHC]
TCP/IP profile
Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an IPv4 ESP-processed packet.
IPv4のESP処理パケットにホップバイホップROHCとROHCoIPsec図1.適用。
If IPsec NULL encryption is applied to packets, ROHC may still be used to compress the inner headers at IPsec SA endpoints. However, compression of these inner headers may pose challenges for intermediary devices (e.g., traffic monitors, sampling/management tools) that are inspecting the contents of ESP-NULL packets. For example, policies on these devices may need to be updated to ensure that packets that contain the "ROHC" protocol identifier are not dropped. In addition, intermediary devices may require additional functionality to determine the content of the header compressed packets.
IPsecのNULL暗号化がパケットに適用された場合に、ROHCは依然としてのIPsec SAのエンドポイントに内部ヘッダを圧縮するために使用されてもよいです。しかしながら、これらの内部ヘッダの圧縮は、ESP-NULLパケットの内容を検査している中間デバイス（例えば、トラフィックモニタ、サンプリング/管理ツール）のための課題を提起してもよいです。例えば、これらのデバイスのポリシーは「ROHC」プロトコル識別子を含むパケットが廃棄されていないことを確認するために更新する必要があります。また、仲介装置は、ヘッダ圧縮されたパケットの内容を決定するために、追加の機能を必要とするかもしれません。
In certain scenarios, a ROHCoIPsec implementation may encounter UDP-encapsulated ESP or IKE packets (i.e., packets that are traversing NATs). For example, a ROHCoIPsec implementation may receive a UDP-encapsulated ESP packet that contains an ESP/UDP/IP header chain. Currently, ROHC profiles do not support compression of the entire header chain associated with this packet; only the UDP/IP headers can be compressed.
特定のシナリオでは、ROHCoIPsec実装は、UDPカプセル化ESPまたはIKEパケット（すなわち、パケットが横断しているのNAT）を発生することがあります。例えば、ROHCoIPsec実装は、ESP / UDP / IPヘッダ鎖を含むUDPカプセル化ESPパケットを受信することができます。現在、ROHCプロファイルは、このパケットに関連する全体のヘッダチェーンの圧縮をサポートしていません。唯一のUDP / IPヘッダを圧縮することができます。
Figure 2 illustrates the components required to integrate ROHC with the IPsec process, i.e., ROHCoIPsec.
図2は、IPsec処理、すなわち、ROHCoIPsecでROHCを統合するために必要なコンポーネントを示します。
+-------------------------------+
| ROHC Module |
| |
| |
+-----+ | +-----+ +---------+ |
| | | | | | ROHC | |
--| A |---------| B |-----| Process |------> Path 1
| | | | | | | | (ROHC-enabled SA)
+-----+ | +-----+ +---------+ |
| | | |
| | |-------------------------> Path 2
| | | (ROHC-enabled SA,
| +-------------------------------+ but no compression)
|
|
|
|
+-----------------------------------------> Path 3
(ROHC-disabled SA)
Figure 2. Integration of ROHC with IPsec
IPsecでROHCの図2.統合
The process illustrated in Figure 2 augments the IPsec processing model for outbound IP traffic (protected-to-unprotected). Initial IPsec processing is consistent with RFC 4301 [IPSEC] (Section 5.1, Steps 1-2).
図2に示されたプロセスは、アウトバウンドIPトラフィック（保護ツー保護されていない）のためのIPsec処理モデルを増強します。初期IPsec処理は、RFC 4301 [IPSEC]（セクション5.1、ステップ1-2）と一致しています。
Block A: The ROHC data item (part of the SA state information) retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1, Step3a) determines if the traffic traversing the SA is handed to the ROHC module. Packets selected to a ROHC-disabled SA MUST follow normal IPsec processing and MUST NOT be sent to the ROHC module (Figure 2, Path 3). Conversely, packets selected to a ROHC-enabled SA MUST be sent to the ROHC module.
ブロックA：SAを通過するトラフィックは、ROHCモジュールに渡される場合ROHCデータ項目（SA状態情報の一部）「関連SADエントリ」から取得（[IPSEC]、セクション5.1、Step3a）を決定します。 ROHC無効SAに選択されたパケットは、通常のIPsec処理に従わなければなりません、そして、ROHCモジュール（図2、パス3）に送信してはいけません。逆に、ROHC対応SAに選択されたパケットは、ROHCモジュールに送らなければなりません。
Block B: This step determines if the packet can be compressed. If the packet is compressed, an integrity algorithm MAY be used to compute an Integrity Check Value (ICV) for the uncompressed packet ([IPSEC-ROHC], Section 4.2; [IKE-ROHC], Section 3.1). The Next Header field of the security protocol header (e.g., ESP, AH) MUST be populated with a "ROHC" protocol identifier [PROTOCOL], inner packet headers MUST be compressed, and the computed ICV MAY be appended to the packet (Figure 2, Path 1). However, if it is determined that the packet will not be compressed (e.g., due to one of the reasons described in Section 6.1.3), the Next Header field MUST be populated with the appropriate value indicating the next-level protocol (Figure 2, Path 2), and ROHC processing MUST NOT be applied to the packet.
ブロックB：パケットを圧縮できる場合は、このステップは、決定します。パケットが圧縮されている場合、完全性アルゴリズムは、（[IKE-ROHC]、セクション3.1、[IPSEC-ROHC]セクション4.2）の非圧縮パケットの値（ICV）をチェックする整合性を計算するために使用され得ます。セキュリティ・プロトコル・ヘッダ（例えば、ESP、AH）は「ROHC」プロトコル識別子[PROTOCOL]で埋めなければならない、内部パケットヘッダが圧縮されなければならない、と計算されたICVをパケットに付加することができる（図2の次ヘッダフィールド、パス1）。しかし、パケットが圧縮されないと判定された場合（例えば、セクション6.1.3に記載のいずれかの理由で）、次のヘッダーフィールドが適切な値次のレベルのプロトコルを示すが取り込まれなければならない（図2 、パス2）、及びROHC処理は、パケットに適用してはなりません。
After the ROHC process completes, IPsec processing resumes, as described in Section 5.1, Step3a, of RFC 4301 [IPSEC].
ROHC処理が完了した後、RFC 4301 [IPSEC]のセクション5.1、Step3aに記載されているように、IPsec処理が再開する。
The process illustrated in Figure 2 also augments the IPsec processing model for inbound IP traffic (unprotected-to-protected). For inbound packets, IPsec processing is performed ([IPSEC], Section 5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section 5.2, Step 4).
図2に示されるプロセスは、インバウンドIPトラフィック（保護されていない対保護）のためのIPsec処理モデルを増強します。着信パケットは、IPsec処理は、AHまたはESP処理（[IPSEC]、セクション5.2、工程4）続いて（[IPSEC]、セクション5.2は、1-3ステップ）が行われます。
Block A: After AH or ESP processing, the ROHC data item retrieved from the SAD entry will indicate if traffic traversing the SA is processed by the ROHC module ([IPSEC], Section 5.2, Step 3a). Packets traversing a ROHC-disabled SA MUST follow normal IPsec processing and MUST NOT be sent to the ROHC module. Conversely, packets traversing a ROHC-enabled SA MUST be sent to the ROHC module.
ブロックAは：SAを通過するトラフィックは、ROHCモジュール（[IPSEC]、セクション5.2、ステップ3a）によって処理される場合AHまたはESP処理の後、SADエントリから取得ROHCデータ項目が表示されます。 ROHC-無効SAを通過するパケットは、通常のIPsec処理に従わなければならないし、ROHCモジュールに送ってはいけません。逆に、ROHC有効SAを通過するパケットは、ROHCモジュールに送らなければなりません。
Block B: The decision at Block B is made using the value of the Next Header field of the security protocol header. If the Next Header field does not indicate a ROHC header, the decompressor MUST NOT attempt decompression (Figure 2, Path 2). If the Next Header field indicates a ROHC header, decompression is applied. After decompression, the signaled ROHCoIPsec integrity algorithm MAY be used to compute an ICV value for the decompressed packet. This ICV, if present, is compared to the ICV that was calculated at the compressor. If the ICVs match, the packet is forwarded by the ROHC module (Figure 2, Path 1); otherwise, the packet MUST be dropped. Once the ROHC module completes processing, IPsec processing resumes, as described in Section 5.2, Step 4, of RFC 4301 [IPSEC].
ブロックB：ブロックBの判定は、セキュリティプロトコルヘッダの次ヘッダフィールドの値を用いて行われます。次ヘッダフィールドは、ROHCヘッダを示していない場合、減圧装置は、減圧（図2、経路2）を試みてはいけません。次ヘッダフィールドは、ROHCヘッダを示す場合、減圧が適用されます。解凍後、合図ROHCoIPsecの整合性アルゴリズムは、解凍パケットのICV値を計算するために使用されるかもしれません。このICVは、存在する場合、圧縮機で計算されたICVと比較されます。たICVが一致する場合、パケットはROHCモジュール（図2、パス1）によって転送されます。そうでない場合、パケットは廃棄されなければなりません。 ROHCモジュールが処理を完了すると、RFC 4301 [IPSEC]のセクション5.2、工程4に記載されているように、IPsec処理が再開する。
When there is a single SA between a compressor and decompressor, ROHC MUST operate in unidirectional mode, as described in Section 5 of RFC 3759 [ROHC-TERM]. When there is a pair of SAs instantiated between
コンプレッサとデコンプレッサとの間の単一のSAが存在する場合、RFC 3759 [ROHC-TERM]のセクション5で説明したように、ROHCは、一方向モードで動作しなければなりません。 SAのペアは、その間にインスタンス化されると
ROHCoIPsec implementations, ROHC MAY operate in bi-directional mode, where an SA pair represents a bi-directional ROHC channel (as described in Sections 6.1 and 6.2 of RFC 3759 [ROHC-TERM]).
ROHCoIPsec実装は、ROHCは、SAのペアが双方向ROHCチャンネル（セクション6.1およびRFC 3759の6.2に記載されているように[ROHC-TERM]）を表し、双方向モードで動作することができます。
Note that to further reduce the size of an IPsec-protected packet, ROHCoIPsec and IPComp [IPCOMP] can be implemented in a nested fashion. This process is detailed in [IPSEC-ROHC], Section 4.4.
さらに、IPsecで保護されたパケットのサイズを小さくすることに注意、ROHCoIPsecとのIPCompは、[IPCOMP]ネストされた方式で実施することができます。このプロセスは、[IPSEC-ROHC]、セクション4.4に詳述されています。
ROHCv2 [ROHCV2] profiles include various mechanisms that provide increased robustness over reordering channels. These mechanisms SHOULD be adopted for ROHC to operate efficiently over IPsec SAs.
ROHCv2 [ROHCV2]プロファイルは、リオーダリングチャネルにわたって増加ロバスト性を提供する様々な機構を含みます。これらのメカニズムは、IPsec SAの上に効率的に動作するようにROHCのために採用されるべきです。
A ROHC decompressor implemented within IPsec architecture MAY leverage additional mechanisms to improve performance over reordering channels (either due to random events or to an attacker intentionally reordering packets). Specifically, IPsec's sequence number MAY be used by the decompressor to identify a packet as "sequentially late". This knowledge will increase the likelihood of successful decompression of a reordered packet.
IPsecのアーキテクチャ内に実装ROHCデコンプレッサは、並べ替えチャネル（これはランダムイベントまたは故意のパケットを並べ替え攻撃のいずれか）を介してパフォーマンスを向上させるために追加メカニズムを利用してもよい（MAY）。具体的には、IPsecののシーケンス番号が「順次遅い」としてパケットを識別するために減圧装置によって使用されてもよいです。この知識は、並べ替え、パケットの解凍の成功の可能性を高めるだろう。
Additionally, ROHCoIPsec implementations SHOULD minimize the amount of feedback sent from the decompressor to the compressor. If a ROHC feedback channel is not used sparingly, the overall gains from ROHCoIPsec can be significantly reduced. More specifically, any feedback sent from the decompressor to the compressor MUST be processed by IPsec and tunneled back to the compressor (as designated by the SA associated with FEEDBACK_FOR). As such, some implementation alternatives can be considered, including the following:
また、ROHCoIPsec実装は、圧縮機に減圧装置から送信されたフィードバックの量を最小にしなければなりません。 ROHCフィードバックチャネルを控えめに使用されていない場合は、ROHCoIPsecからの全体的な利益を大幅に低減することができます。より具体的には、圧縮機に減圧装置から送信されたフィードバックは、IPsecによって処理されなければならないと背面（FEEDBACK_FORに関連付けられたSAによって指定される）は、圧縮機へトンネリング。そのため、いくつかの実装の選択肢は、以下を含め、考えることができます。
o Eliminate feedback traffic altogether by operating only in ROHC Unidirectional mode (U-mode).
O ROHC一方向モード（Uモード）でのみ操作することにより、完全フィードバックトラフィックを排除します。
o Piggyback ROHC feedback messages within the feedback element (i.e., on ROHC traffic that normally traverses the SA designated by FEEDBACK_FOR).
フィードバック要素内のピギーバックROHCフィードバックメッセージ（すなわち、通常FEEDBACK_FORによって指定SAを横断ROHCトラフィックに対する）O。
Hop-by-hop ROHC typically uses the underlying link layer (e.g., PPP) to negotiate ROHC channel parameters. In the case of ROHCoIPsec, channel parameters can be set manually (i.e., administratively configured for manual SAs) or negotiated by IKEv2. The extensions required for IKEv2 to support ROHC channel parameter negotiation are detailed in [IKE-ROHC].
ホップバイホップROHCは、典型的には、ROHCチャネルパラメータをネゴシエートするために、基礎となるリンク層（例えば、PPP）を使用します。 ROHCoIPsecの場合には、チャネルパラメータを手動で設定することができる（すなわち、管理マニュアルSAの構成）またはのIKEv2によって交渉します。 ROHCチャンネルパラメータネゴシエーションをサポートするためのIKEv2のために必要な拡張機能は、[IKE-ROHC]に詳述されています。
If the ROHC protocol requires bi-directional communications, two SAs MUST be instantiated between the IPsec implementations. One of the two SAs is used for carrying ROHC-traffic from the compressor to the decompressor, while the other is used to communicate ROHC-feedback from the decompressor to the compressor. Note that the requirement for two SAs aligns with the operation of IKE, which creates SAs in pairs by default. However, IPsec implementations will dictate how decompressor feedback received on one SA is associated with a compressor on the other SA. An IPsec implementation MUST relay the feedback received by the decompressor on an inbound SA to the compressor associated with the corresponding outbound SA.
ROHCプロトコルは、双方向通信を必要とする場合、2つのSAは、IPsec実装間でインスタンス化されなければなりません。他の圧縮機に減圧装置からROHCフィードバックを通信するために使用される2つのSAの一つは、解凍装置へ圧縮機からROHCトラフィックを搬送するために使用されます。 2つのSAのための要件は、デフォルトでペアにSAを作成するIKEの動作と整列することに留意されたいです。減圧装置フィードバックは他のSAに圧縮機に関連付けられているものSA上で受信された方法が、IPsec実装が決定するであろう。 IPsec実装は、対応するアウトバウンドSAに関連付けられている圧縮機へのインバウンドSAに解凍装置により受信されたフィードバックを中継しなければなりません。
As indicated in Section 6.1, new state information (i.e., a new ROHC data item) is defined for each SA. The ROHC data item MUST be used by the IPsec process to determine whether it sends all traffic traversing a given SA to the ROHC module (ROHC-enabled) or bypasses the ROHC module and sends the traffic through regular IPsec processing (ROHC-disabled).
6.1節に示されるように、新たな状態情報（即ち、新しいROHCデータ項目）は、各SAのために定義されています。 ROHCデータ項目は、ROHCモジュールに与えられたSAを通過するすべてのトラフィックを送信する（ROHC対応）またはROHCモジュールをバイパスし、定期的なIPsec処理（ROHC-無効）を介してトラフィックを送信するかどうかを決定するために、IPsec処理によって使用されなければなりません。
The Next Header field of the IPsec security protocol (e.g., AH or ESP) header MUST be used to demultiplex header-compressed traffic from uncompressed traffic traversing a ROHC-enabled SA. This functionality is needed in situations where packets traversing a ROHC-enabled SA contain uncompressed headers. Such situations may occur when, for example, a compressor only supports up to n compressed flows and cannot compress a flow number n+1 that arrives. Another example is when traffic is selected to a ROHC-enabled SA, but cannot be compressed by the ROHC process because the appropriate ROHC Profile has not been signaled for use. As a result, the decompressor MUST be able to identify packets with uncompressed headers and MUST NOT attempt to decompress them. The Next Header field is used to demultiplex these header-compressed and uncompressed packets where the "ROHC" protocol identifier will indicate that the packet contains compressed headers. To accomplish this, IANA has allocated value 142 to "ROHC" from the Protocol ID registry [PROTOCOL].
IPsecセキュリティプロトコルの次ヘッダフィールド（例えば、AHまたはESP）ヘッダをROHC有効SAを通過する圧縮されていないトラフィックからヘッダ圧縮トラフィックを分離するために使用されなければなりません。この機能は、ROHC対応のSAを通過するパケットが圧縮されていないヘッダーが含ま状況で必要とされています。例えば、圧縮機のみN圧縮フローをサポートし、フロー番号N +到着1を圧縮することができない場合、このような状況が発生する可能性があります。別の例では、トラフィックがROHC対応SAに選択された場合であるが、適切なROHCプロファイルが使用のためにシグナリングされていないため、ROHC処理によって圧縮することができません。その結果、デコンプレッサは圧縮されていないヘッダを持つパケットを特定できなければなりませんし、それらを解凍するのを試みてはいけません。次ヘッダフィールドは「ROHC」プロトコル識別子は、パケットが圧縮ヘッダが含まれていることを示すであろうこれらのヘッダ圧縮および非圧縮パケットを逆多重化するために使用されます。これを達成するために、IANAは、プロトコルIDレジストリ[PROTOCOL]から「ROHC」値142を割り当てました。
It is noted that the use of the "ROHC" protocol identifier for purposes other than ROHCoIPsec is currently not defined. In other words, the "ROHC" protocol identifier is only defined for use in the Next Header field of security protocol headers (e.g., ESP, AH).
ROHCoIPsec以外の目的のために、「ROHC」プロトコル識別子の使用は、現在定義されていないことに留意されたいです。換言すれば、「ROHC」プロトコル識別子が唯一のセキュリティプロトコルヘッダの次ヘッダフィールドでの使用のために定義されている（例えば、ESP、AH）。
The ROHC Data Item, IANA Protocol ID allocation, and other IPsec extensions to support ROHCoIPsec are specified in [IPSEC-ROHC].
ROHCoIPsecをサポートするためにROHCデータ項目、IANAプロトコルIDの割り当て、および他のIPsec拡張機能は[IPSEC-ROHC]で指定されています。
Although ROHC was designed to tolerate packet loss and reordering, the algorithm does not guarantee that packets reconstructed at the decompressor are identical to the original packet. As stated in Section 5.2 of RFC 4224 [REORDR], the consequences of packet reordering between ROHC peers may include undetected decompression failures, where erroneous packets are constructed and forwarded to upper layers. Significant packet loss can have similar consequences.
ROHCは、パケットロスや並べ替えを許容するように設計されましたが、このアルゴリズムは、解凍器で再構成パケットは元のパケットと同一であることを保証するものではありません。 RFC 4224 [REORDR]のセクション5.2で述べたように、ROHCピア間のパケット並べ替えの結果は誤ったパケットを構築し、上位層に転送される未検出減圧障害を含むことができます。重要なパケット損失が同様の結果をもたらすことができます。
When using IPsec integrity protection, a packet received at the egress of an IPsec tunnel is identical to the packet that was processed at the ingress (given that the key is not compromised, etc.).
IPsecの完全性保護を使用する場合、IPsecトンネルの出口で受信されたパケットは、入力（キー、等を損なわれないと仮定）で処理されたパケットと同一です。
When ROHC is integrated into the IPsec processing framework, the ROHC processed packet is protected by the AH/ESP ICV. However, bits in the original IP header are not protected by this ICV; they are protected only by ROHC's integrity mechanisms (which are designed for random packet loss/reordering, not malicious packet loss/reordering introduced by an attacker). Therefore, under certain circumstances, erroneous packets may be constructed and forwarded into the protected domain.
ROHCは、IPsec処理フレームワークに統合されているとき、ROHC処理されたパケットは、AH / ESP ICVによって保護されています。しかし、元のIPヘッダ内のビットは、このICVによって保護されていません。彼らは唯一の（ランダムなパケット損失/並べ替えのために設計されている、いない攻撃者によって導入された悪質なパケットロス/並べ替え）ROHCの整合性メカニズムによって保護されています。したがって、特定の状況下では、誤ったパケットを構築してもよいし、保護ドメインに転送されます。
To ensure the integrity of the original IP header within the ROHCoIPsec-processing model, an additional integrity check MAY be applied before the packet is compressed. This integrity check will ensure that erroneous packets are not forwarded into the protected domain. The specifics of this integrity check are documented in Section 4.2 of [IPSEC-ROHC].
パケットが圧縮される前ROHCoIPsec処理モデル内の元のIPヘッダの完全性を保証するために、付加的な整合性チェックを適用してもよいです。この整合性チェックは、誤ったパケットが保護されたドメインに転送されないことを保証します。この整合性チェックの詳細は[IPSEC-ROHC]のセクション4.2に記載されています。
By encapsulating IP packets with AH/ESP and tunneling IP headers, IPsec increases the size of IP packets. This increase may result in Path MTU issues in the unprotected domain. Several approaches to resolving these path MTU issues are documented in Section 8 of RFC 4301 [IPSEC]; approaches include fragmenting the packet before or after IPsec processing (if the packet's Don't Fragment (DF) bit is clear), or possibly discarding packets (if the packet's DF bit is set).
AH / ESPとトンネルIPヘッダとIPパケットをカプセル化することによって、IPsecはIPパケットのサイズを増大させます。この増加は、保護されていないドメイン内のパスMTUの問題をもたらすことができます。これらの経路MTUの問題を解決するいくつかのアプローチは、RFC 4301 [IPSEC]のセクション8に記載されています。アプローチは（パケットのDo not Fragment（DF）ビットがクリアされている場合）、IPsec処理の前または後にパケットを断片化、または（パケットのDFビットが設定されている場合）可能性がパケットを廃棄などがあります。
The addition of ROHC within the IPsec processing model may result in similar path MTU challenges. For example, under certain circumstances, ROHC headers are larger than the original uncompressed headers. In addition, if an integrity algorithm is used to validate packet headers, the resulting ICV will increase the size of packets. Both of these properties of ROHCoIPsec increase the size of packets, and therefore may result in additional challenges associated with path MTU.
IPsec処理モデル内のROHCの添加は、同様の経路MTUの課題をもたらし得ます。例えば、特定の状況下で、ROHCヘッダーは元の非圧縮ヘッダよりも大きいです。完全性アルゴリズムはパケットヘッダを検証するために使用されている場合に加え、得られたICVは、パケットのサイズを増加させるであろう。 ROHCoIPsecのこれらの特性の両方は、パケットのサイズを増加させ、従ってパスMTUに関連する追加の問題をもたらし得ます。
Approaches to addressing these path MTU issues are specified in Section 4.3 of [IPSEC-ROHC].
MTUの問題が[IPSEC-ROHC]のセクション4.3で指定されているこれらのパスに対処するためのアプローチ。
To summarize, the following items are needed to achieve ROHCoIPsec:
要約すると、以下の項目がROHCoIPsecを達成するために必要とされます。
o IKEv2 Extensions to Support ROHCoIPsec
O IKEv2の拡張がサポートするROHCoIPsec
o IPsec Extensions to Support ROHCoIPsec
O IPsec拡張機能をサポートするためのROHCoIPsec
Several security considerations associated with the use of ROHCoIPsec are covered in Section 6.1.4. These considerations can be mitigated by using a strong integrity-check algorithm to ensure the valid decompression of packet headers.
ROHCoIPsecの使用に関連したいくつかのセキュリティ上の考慮事項は、セクション6.1.4で説明されています。これらの考慮事項は、パケットヘッダの有効な解凍を確保するために、強力な整合性チェックアルゴリズムを使用することによって緩和することができます。
A malfunctioning or malicious ROHCoIPsec compressor (i.e., the compressor located at the ingress of the IPsec tunnel) has the ability to send erroneous packets to the decompressor (i.e., the decompressor located at the egress of the IPsec tunnel) that do not match the original packets emitted from the end-hosts. Such a scenario may result in decreased efficiency between compressor and decompressor, or may cause the decompressor to forward erroneous packets into the protected domain. A malicious compressor could also intentionally generate a significant number of compressed packets, which may result in denial of service at the decompressor, as the decompression of a significant number of invalid packets may drain the resources of an IPsec device.
オリジナルと一致しない誤動作や悪意のあるROHCoIPsec圧縮機（すなわち、IPsecトンネルの入口に位置する圧縮機）減圧装置に誤ったパケットを送信する能力を有する（すなわち、減圧装置がIPsecトンネルの出口に位置します）エンドホストから出射されたパケット。そのようなシナリオでは、コンプレッサとデコンプレッサとの間の減少効率をもたらすことができる、または保護ドメインに誤ったパケットを転送するために減圧装置を引き起こす可能性があります。悪意のある圧縮機はまた、意図的に無効なパケットのかなりの数の減圧は、IPSec装置のリソースを排出できるように、減圧装置におけるサービスの拒否につながる可能性がある、圧縮されたパケットのかなりの数を生成することができます。
A malfunctioning or malicious ROHCoIPsec decompressor has the ability to disrupt communications as well. For example, a decompressor may simply discard a subset of (or all) the packets that are received, even if packet headers were validly decompressed. Ultimately, this could result in denial of service. A malicious decompressor could also intentionally indicate that its context is not synchronized with the compressor's context, forcing the compressor to transition to a lower compression state. This will reduce the overall efficiency gain offered by ROHCoIPsec.
誤動作や悪意のあるROHCoIPsecデコンプレッサは、同様に通信を破壊する能力を持っています。例えば、解凍装置は、単にパケットヘッダを有効に伸長しても、受信されたパケットの部分集合（またはすべて）を破棄することができます。最終的に、これはサービス拒否につながる可能性があります。悪質なデコンプレッサはまた、意図的に低い圧縮状態に移行するように、圧縮機を強制的に、そのコンテキストは、圧縮機のコンテキストと同期していないことを示すことができます。これはROHCoIPsecによって提供される全体的な効率利得が低下します。
All IANA considerations for ROHCoIPsec are documented in [IKE-ROHC] and [IPSEC-ROHC].
ROHCoIPsecのためのすべてのIANA問題は、[IKE-ROHC]と[IPSEC-ROHC]に記載されています。
The authors would like to thank Sean O'Keeffe, James Kohler, and Linda Noone of the Department of Defense, as well as Rich Espy of OPnet for their contributions and support in the development of this document.
作者はこのドキュメントの開発に貢献し、支援のためのショーン・オキーフ、ジェームズ・コーラー、および国防総省のリンダ・ヌーン、だけでなく、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ジュニアに感謝したいと思います。：両方は、この仕様書のためのコミット文書の校閲を務めていました。
In addition, the authors would like to thank the following for their numerous reviews and comments to this document:
また、作者はこのドキュメントへの彼らの数々のレビューやコメントのために以下のことを感謝したいと思います：
o Magnus Westerlund
マグヌスウェスターO
o Stephen Kent
Oスティーブン・ケント
o Pasi Eronen
いいえパシEronenありません
o Joseph Touch
Oジョセフ・タッチ
o Tero Kivinen
いいえTERO Kivinenありません
o Jonah Pezeshki
OヨナPezeshki
o Lars-Erik Jonsson
Oラース - エリックジョンソン
o Jan Vilhuber
お じゃん ゔぃｌふべｒ
o Dan Wing
ダン・ウイングについて
o Kristopher Sandlund
OのKristopher Sandlund
o Ghyslain Pelletier
O Ghyslainペルティエ
o David Black
Oデビッド・ブラック
o Tim Polk
Oティムポーク
o Brian Carpenter
Oブライアン・カーペンター
Finally, the authors would also like to thank Tom Conkle, Renee Esposito, Etzel Brower, and Michele Casey of Booz Allen Hamilton for their assistance in completing this work.
最後に、著者らはまた、この作品を完成さで彼らの支援のためのブーズ・アレン・ハミルトンのトムConkle、レニーエスポジト、Etzelブラウワー、およびミケーレケーシーに感謝したいと思います。
[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月。
[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-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月。
[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月。
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[IPSEC-ROHC] Ertekin, E., Christou, C., and C. Bormann, "IPsec Extensions to Support Robust Header Compression over IPsec", RFC 5858, May 2010.
[IPSEC-ROHC] Ertekin、E.、Christouの、C.、およびC.ボルマン、 "IPsec拡張機能は、IPsec上でロバストヘッダ圧縮をサポートするために"、RFC 5858、2010年5月。
[IKE-ROHC] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. Bormann, "IKEv2 Extensions to Support Robust Header Compression over IPsec", RFC 5857, May 2010.
[IKE-ROHC] Ertekin、E.、Christouの、C.、Jasani、R.、Kivinen、T.、およびC.ボルマン、 "IKEv2の拡張機能のIPsec上でロバストヘッダ圧縮をサポートするために"、RFC 5857は、2010年5月。
[PROTOCOL] IANA, "Assigned Internet Protocol Numbers", <http://www.iana.org>.
[PROTOCOL] IANA、 "割り当てられたインターネットプロトコル番号"、<http://www.iana.org>。
[IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[IPCOMP] Shacham、A.、Monsour、B.、ペレイラ、R。、およびM.トーマス、 "IPペイロード圧縮プロトコル（のIPComp）"、RFC 3173、2001年9月。
[ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008.
[ROHCV2]ペルティエ、G.およびK. Sandlund、 "ロバストヘッダ圧縮バージョン2（ROHCv2）：RTP、UDP、IP、ESPとUDP-Liteのプロファイル"、RFC 5225、2008年4月。
[REORDR] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006.
[REORDR]ペルティエ、G.、ヨンソン、L-E、およびK. Sandlund、 "ロバストヘッダ圧縮（ROHC）：パケットの順序を変更できますチャンネル以上のROHC"。、RFC 4224、2006年1月。
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
Rohan Jasani Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US
ロハンJasaniブーズ・アレン・ハミルトン13200ウッドランドパーク博士ハーンドン、VA 20171米国
EMail: ro@breakcheck.com
メールアドレス：ro@breakcheck.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