[要約] RFC 5856は、IPsecセキュリティアソシエーション上でのRobust Header Compression（ROHC）の統合に関するものです。その目的は、ROHCを使用してIPsecトラフィックの圧縮を実現し、ネットワークの効率性とパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) E. Ertekin
Request for Comments: 5856 R. Jasani
Category: Informational C. Christou
ISSN: 2070-1721 Booz Allen Hamilton
C. Bormann
Universitaet Bremen TZI
May 2010
Integration of Robust Header Compression over IPsec Security Associations
IPSECセキュリティ関連の堅牢なヘッダー圧縮の統合
Abstract
概要
IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs).
IPセキュリティ（IPSEC）は、IPトラフィックにさまざまなセキュリティサービスを提供します。ただし、IPSECの利点は、オーバーヘッドの増加を犠牲にしてもたらされます。このドキュメントでは、IPSEC（Rohcoipsec）を介して堅牢なヘッダー圧縮（ROHC）を統合するためのフレームワークの概要を説明します。IPパケットの内側ヘッダーを圧縮することにより、Rohcoipsecは、IPSECセキュリティ協会（SAS）を介したトラフィックの送信に関連するオーバーヘッドの量を減らすことを提案しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。インターネットエンジニアリングステアリンググループ（IESG）によって公開されることが承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5856.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
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. 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エンドポイント間を通過するパケットに関連するプロトコルオーバーヘッドを減らすことです。これは、輸送層ヘッダー（UDP、TCPなどなど）を圧縮し、IPSECトンネルの入り口でパケットの内側IPヘッダーを圧縮し、出口でこれらのヘッダーを減圧することで実現できます。
For ROHCoIPsec, this document assumes that ROHC will be used to compress the inner headers of IP packets traversing an IPsec tunnel. However, since current specifications for ROHC detail its operation on a hop-by-hop basis, it requires extensions to enable its operation over IPsec SAs. This document outlines a framework for extending the usage of ROHC to operate at IPsec SA endpoints.
Rohcoipsecの場合、このドキュメントは、ROHCを使用して、IPSECトンネルを横断するIPパケットの内側ヘッダーを圧縮することを前提としています。ただし、ROHCの現在の仕様は、ホップバイホップベースでその動作を詳述するため、IPSEC SASで動作を可能にするために拡張機能が必要です。このドキュメントでは、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は、ROHCのトンネルモードSASへの適用をターゲットにしています。トランスポートモードSASは、IPパケットのペイロードのみを保護し、IPヘッダーを触れられないままにします。その後、中間ルーターはこのIPヘッダーを使用して、パケットを復号化デバイスにルーティングします。したがって、ROHCがIPSECトランスポートモードSASを介して動作する場合、（DE）圧縮機能は、IPヘッダーではなく、輸送層ヘッダーにのみ適用できます。現在のROHC仕様には、輸送層ヘッダーの圧縮だけのサポートが含まれていないため、このドキュメントで概説されているRohcoipsecフレームワークは、ROHCのトンネルモードSASへの適用について説明しています。
The authors target members of both the ROHC and IPsec communities who may consider extending the ROHC and IPsec protocols to meet the requirements put forth in this document. In addition, this document is directed towards vendors developing IPsec devices that will be deployed in bandwidth-constrained IP networks.
著者は、ROHCコミュニティとIPSECコミュニティの両方のメンバーをターゲットにしており、ROHCおよびIPSECプロトコルを拡張してこの文書に記載されている要件を満たすことを検討します。さらに、このドキュメントは、帯域幅が制約された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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [bra97]に記載されているように解釈される。
IPsec mechanisms provide various security services for IP networks. However, the benefits of IPsec come at the cost of increased per-packet overhead. For example, traffic flow confidentiality (generally leveraged at security gateways) requires the tunneling of IP packets between IPsec implementations. Although these IPsec tunnels will effectively mask the source-destination patterns that an intruder can ascertain, tunneling comes at the cost of increased packet overhead. Specifically, an Encapsulating Security Payload (ESP) tunnel mode SA applied to an IPv6 flow results in at least 50 bytes of additional overhead per packet. This additional overhead may be undesirable for many bandwidth-constrained wireless and/or satellite communications networks, as these types of infrastructure are not overprovisioned. ROHC applied on a per-hop basis over bandwidth-constrained links will also suffer from reduced performance when encryption is used on the tunneled header, since encrypted headers cannot be compressed. Consequently, the additional overhead incurred by an IPsec tunnel may result in the inefficient utilization of bandwidth.
IPSECメカニズムは、IPネットワークにさまざまなセキュリティサービスを提供します。ただし、IPSECの利点は、パケットごとのオーバーヘッドの増加を犠牲にしてもたらされます。たとえば、トラフィックフローの機密性（一般にセキュリティゲートウェイで活用されています）には、IPSEC実装間のIPパケットのトンネルが必要です。これらのIPSECトンネルは、侵入者が確認できるソース照明パターンを効果的にマスクしますが、トンネリングはパケットオーバーヘッドの増加を犠牲にして行われます。具体的には、IPv6フローに適用されるセキュリティペイロード（ESP）トンネルモードSAをカプセル化すると、パケットごとに少なくとも50バイトの追加オーバーヘッドが発生します。これらのタイプのインフラストラクチャは過剰に生まれていないため、この追加のオーバーヘッドは、多くの帯域幅が制約したワイヤレスおよび/または衛星通信ネットワークにとって望ましくない場合があります。暗号化されたヘッダーを圧縮できないため、トンネルヘッダーで暗号化が使用されると、帯域幅が制約したリンクよりもホップごとに適用されます。その結果、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 SASは2つのIPSECエンドポイント間でインスタンス化されます。したがって、IPSEC SAエンドポイントでのROHCプロトコルの動作を成功させるために、ROHCとIPSECの両方のさまざまな拡張を定義する必要があります。
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エンドポイントは（DE）圧縮操作が行われるソース/宛先ペアを提供するため、IPSEC SAS上のROHCの仕様は簡単です。このような方法での内側のIPおよび上層プロトコルヘッダーの圧縮により、2つのSAエンドポイント間のパケットオーバーヘッドが減少します。ROHCはIPSECエンドポイント間で動作するため（IPSEC SAに対して透明な複数の中間ノードを超えて）、コンプレッサーと分解器間のパケットの再注文の増加および/またはパケット損失のためにパフォーマンスが重大な影響を受けないようにすることが不可欠です。。
In addition, ROHC can no longer rely on the underlying link layer for ROHC channel parameter configuration and packet identification. The ROHCoIPsec framework proposes that ROHC channel parameter configuration is accomplished by an SA management protocol (e.g., Internet Key Exchange Protocol version 2 (IKEv2) [IKEV2]), while identification of compressed header packets is achieved through the Next Header field of the security protocol (e.g., Authentication Header (AH) [AH], ESP [ESP]) header.
さらに、ROHCは、ROHCチャネルパラメーターの構成とパケット識別の基礎となるリンクレイヤーに依存することはできなくなりました。ROHCOIPSECフレームワークは、ROHCチャネルパラメーターの構成はSA管理プロトコル（たとえば、インターネットキーエクスチェンジプロトコルバージョン2（IKEV2）[IKEV2]）によって達成されることを提案していますが、圧縮ヘッダーパケットの識別はセキュリティプロトコルの次のヘッダーフィールドを通じて達成されます。（例えば、認証ヘッダー（AH）[AH]、ESP [ESP]）ヘッダー。
Using the ROHCoIPsec framework proposed below, outbound and inbound IP traffic processing at an IPsec device needs to be modified. For an outbound packet, a ROHCoIPsec implementation will compress appropriate packet headers, and subsequently encrypt and/or integrity protect the packet. For tunnel mode SAs, compression may be applied to the transport layer and the inner IP headers. For inbound packets, an IPsec device must first decrypt and/or integrity check the packet. Then, decompression of the inner packet headers is performed. After decompression, the packet is checked against the access controls imposed on all inbound traffic associated with the SA (as specified in RFC 4301 [IPSEC]).
以下に提案されているRohcoipsecフレームワークを使用すると、IPSECデバイスでのアウトバウンドおよびインバウンドIPトラフィック処理を変更する必要があります。アウトバウンドパケットの場合、Rohcoipsecの実装により、適切なパケットヘッダーが圧縮され、その後パケットを暗号化および/または整合性が保護します。トンネルモードSASの場合、圧縮は輸送層と内側のIPヘッダーに適用される場合があります。インバウンドパケットの場合、IPSECデバイスは最初にパケットを解読および/または整合性に確認する必要があります。次に、内側のパケットヘッダーの減圧が実行されます。減圧後、パケットは、SAに関連付けられたすべてのインバウンドトラフィックに課されるアクセスコントロールに対してチェックされます（RFC 4301 [IPSEC]で指定）。
Note: Compression of inner headers is independent from compression of the security protocol (e.g., ESP) and outer IP headers. ROHC profiles have been defined to allow for the compression of the security protocol and the outer IP header on a hop-by-hop basis. The applicability of ROHCoIPsec and hop-by-hop ROHC on an IPv4 ESP-processed packet [ESP] is shown below in Figure 1.
注：内側のヘッダーの圧縮は、セキュリティプロトコル（ESPなど）および外側のIPヘッダーの圧縮から独立しています。ROHCプロファイルは、ホップバイホップベースでセキュリティプロトコルと外部IPヘッダーの圧縮を可能にするために定義されています。IPv4 ESP処理パケット[ESP]へのRohcoipsecとHop-by-Hop ROHCの適用性を図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
(1) ROHC [ROHC] ESP/IPプロファイルによる圧縮ホップバイホップ（2）ROHCOIPSEC [IPSEC-ROHC] TCP/IPプロファイルによる圧縮エンドツーエンド
Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an IPv4 ESP-processed packet.
図1. IPv4 ESP処理パケットへのホップバイホップROHCおよびROHCOIPSECの適用可能性。
If IPsec NULL encryption is applied to packets, ROHC may still be used to compress the inner headers at IPsec SA endpoints. However, compression of these inner headers may pose challenges for intermediary devices (e.g., traffic monitors, sampling/management tools) that are inspecting the contents of ESP-NULL packets. For example, policies on these devices may need to be updated to ensure that packets that contain the "ROHC" protocol identifier are not dropped. In addition, intermediary devices may require additional functionality to determine the content of the header compressed packets.
IPSEC NULL暗号化がパケットに適用される場合、ROHCはIPSEC SAエンドポイントで内側のヘッダーを圧縮するために使用される場合があります。ただし、これらの内側のヘッダーの圧縮により、ESP-Nullパケットの内容を検査する中間デバイス（たとえば、トラフィックモニター、サンプリング/管理ツール）に課題が発生する場合があります。たとえば、これらのデバイスのポリシーを更新して、「ROHC」プロトコル識別子を含むパケットが削除されないことを確認する必要がある場合があります。さらに、中間デバイスは、ヘッダー圧縮パケットのコンテンツを決定するために追加の機能を必要とする場合があります。
In certain scenarios, a ROHCoIPsec implementation may encounter UDP-encapsulated ESP or IKE packets (i.e., packets that are traversing NATs). For example, a ROHCoIPsec implementation may receive a UDP-encapsulated ESP packet that contains an ESP/UDP/IP header chain. Currently, ROHC profiles do not support compression of the entire header chain associated with this packet; only the UDP/IP headers can be compressed.
特定のシナリオでは、Rohcoipsecの実装では、UDPがカプセル化されたESPまたはIKEパケット（つまり、NATを通過しているパケット）に遭遇する可能性があります。たとえば、Rohcoipsecの実装には、ESP/UDP/IPヘッダーチェーンを含むUDPにカプセル化されたESPパケットを受け取る場合があります。現在、ROHCプロファイルは、このパケットに関連するヘッダーチェーン全体の圧縮をサポートしていません。UDP/IPヘッダーのみを圧縮できます。
Figure 2 illustrates the components required to integrate ROHC with the IPsec process, i.e., ROHCoIPsec.
図2は、ROHCをIPSECプロセス、つまりRohcoipsecと統合するために必要なコンポーネントを示しています。
+-------------------------------+
| ROHC Module |
| |
| |
+-----+ | +-----+ +---------+ |
| | | | | | ROHC | |
--| A |---------| B |-----| Process |------> Path 1
| | | | | | | | (ROHC-enabled SA)
+-----+ | +-----+ +---------+ |
| | | |
| | |-------------------------> Path 2
| | | (ROHC-enabled SA,
| +-------------------------------+ but no compression)
|
|
|
|
+-----------------------------------------> Path 3
(ROHC-disabled SA)
Figure 2. Integration of ROHC with IPsec
図2. ROHCとIPSECの統合
The process illustrated in Figure 2 augments the IPsec processing model for outbound IP traffic (protected-to-unprotected). Initial IPsec processing is consistent with RFC 4301 [IPSEC] (Section 5.1, Steps 1-2).
図2に示すプロセスは、アウトバウンドIPトラフィックのIPSEC処理モデル（保護されていない）のIPSEC処理モデルを強化しています。初期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：「関連するSADエントリ」（[IPSEC]、セクション5.1、Step3A）から取得されたROHCデータ項目（SA状態情報の一部）は、SAを通過するトラフィックがROHCモジュールに渡されるかどうかを判断します。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：このステップでは、パケットを圧縮できるかどうかが判断されます。パケットが圧縮されている場合、整合性アルゴリズムを使用して、非圧縮パケット（[IPSEC-ROHC]、セクション4.2; [IKE-ROHC]、セクション3.1）の整合性チェック値（ICV）を計算することができます。セキュリティプロトコルヘッダーの次のヘッダーフィールド（ESP、AHなど）には「ROHC」プロトコル識別子[プロトコル]を入力する必要があり、内側のパケットヘッダーを圧縮し、計算されたICVをパケットに追加することができます（図2、パス1）。ただし、パケットが圧縮されないと判断された場合（たとえば、セクション6.1.3で説明されている理由の1つにより）、次のヘッダーフィールドには、次のレベルのプロトコルを示す適切な値を入力する必要があります（図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処理が実行され（[IPSEC]、セクション5.2、ステップ1〜3）、AHまたはESP処理（[IPSEC]、セクション5.2、ステップ4）が続きます。
Block A: After AH or ESP processing, the ROHC data item retrieved from the SAD entry will indicate if traffic traversing the SA is processed by the ROHC module ([IPSEC], Section 5.2, Step 3a). Packets traversing a ROHC-disabled SA MUST follow normal IPsec processing and MUST NOT be sent to the ROHC module. Conversely, packets traversing a ROHC-enabled SA MUST be sent to the ROHC module.
ブロックA：AHまたはESP処理の後、SADエントリから取得したROHCデータ項目は、SAを通過するトラフィックがROHCモジュール（[IPSEC]、セクション5.2、ステップ3A）によって処理されるかどうかを示します。ROHCに障害のあるSAを横断するパケットは、通常のIPSEC処理に従う必要があり、ROHCモジュールに送信しないでください。逆に、ROHC対応SAを通過するパケットをROHCモジュールに送信する必要があります。
Block B: The decision at Block B is made using the value of the Next Header field of the security protocol header. If the Next Header field does not indicate a ROHC header, the decompressor MUST NOT attempt decompression (Figure 2, Path 2). If the Next Header field indicates a ROHC header, decompression is applied. After decompression, the signaled ROHCoIPsec integrity algorithm MAY be used to compute an ICV value for the decompressed packet. This ICV, if present, is compared to the ICV that was calculated at the compressor. If the ICVs match, the packet is forwarded by the ROHC module (Figure 2, Path 1); otherwise, the packet MUST be dropped. Once the ROHC module completes processing, IPsec processing resumes, as described in Section 5.2, Step 4, of RFC 4301 [IPSEC].
ブロックB：ブロックBでの決定は、セキュリティプロトコルヘッダーの次のヘッダーフィールドの値を使用して行われます。次のヘッダーフィールドがROHCヘッダーを示していない場合、減圧装置は減圧を試みてはなりません（図2、パス2）。次のヘッダーフィールドがROHCヘッダーを示した場合、減圧が適用されます。減圧後、シグナル付きRohcoipsec Integrityアルゴリズムを使用して、減圧パケットのICV値を計算できます。このICVは、存在する場合、コンプレッサーで計算されたICVと比較されます。ICVSが一致する場合、パケットは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 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]).
コンプレッサーと減圧装置の間に単一のSAがある場合、ROHCはRFC 3759 [ROHC-Term]のセクション5で説明されているように、単方向モードで動作する必要があります。Rohcoipsecの実装の間にインスタンス化されたSAのペアがある場合、ROHCは双方向モードで動作する場合があります。SAペアは、双方向ROHCチャネルを表します（RFC 3759のセクション6.1および6.2 [ROHC-Terme]）。
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 SASよりも効率的に動作するために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減圧器は、追加のメカニズムを活用して、チャネルの並べ替えよりもパフォーマンスを改善する場合があります（ランダムイベントまたは攻撃者が意図的にパケットを並べ替えるため）。具体的には、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).
o フィードバック要素内のピギーバックROHCフィードバックメッセージ（つまり、通常、Feedback_forで指定されたSAを通過するROHCトラフィック）。
Hop-by-hop ROHC typically uses the underlying link layer (e.g., PPP) to negotiate ROHC channel parameters. In the case of ROHCoIPsec, channel parameters can be set manually (i.e., administratively configured for manual SAs) or negotiated by IKEv2. The extensions required for IKEv2 to support ROHC channel parameter negotiation are detailed in [IKE-ROHC].
ホップバイホップROHCは通常、基礎となるリンクレイヤー（PPPなど）を使用して、ROHCチャネルパラメーターをネゴシエートします。Rohcoipsecの場合、チャネルパラメーターは手動で設定（つまり、手動SAS用に管理上構成）またはIKEV2によってネゴシエートされます。IKEV2がROHCチャネルパラメーターネゴシエーションをサポートするために必要な拡張機能については、[IKE-ROHC]で詳しく説明しています。
If the ROHC protocol requires bi-directional communications, two SAs MUST be instantiated between the IPsec implementations. One of the two SAs is used for carrying ROHC-traffic from the compressor to the decompressor, while the other is used to communicate ROHC-feedback from the decompressor to the compressor. Note that the requirement for two SAs aligns with the operation of IKE, which creates SAs in pairs by default. However, IPsec implementations will dictate how decompressor feedback received on one SA is associated with a compressor on the other SA. An IPsec implementation MUST relay the feedback received by the decompressor on an inbound SA to the compressor associated with the corresponding outbound SA.
ROHCプロトコルが双方向通信を必要とする場合、IPSEC実装間で2つのSASをインスタンス化する必要があります。2つのSASの1つは、コンプレッサーから減圧器へのROHCトラフィックを運ぶために使用され、もう1つはdecompressorからコンプレッサーへのROHCフィードバックを通信するために使用されます。2つのSASの要件はIKEの操作と一致していることに注意してください。これにより、デフォルトでSASがペアでSASを作成します。ただし、IPSECの実装により、1つのSAで受信された減圧装置のフィードバックが、他のSAのコンプレッサーにどのように関連付けられているかが決まります。IPSECの実装では、インバウンドSAの分解器が受信したフィードバックを、対応するアウトバウンドSAに関連付けられたコンプレッサーに中継する必要があります。
As indicated in Section 6.1, new state information (i.e., a new ROHC data item) is defined for each SA. The ROHC data item MUST be used by the IPsec process to determine whether it sends all traffic traversing a given SA to the ROHC module (ROHC-enabled) or bypasses the ROHC module and sends the traffic through regular IPsec processing (ROHC-disabled).
セクション6.1で示されているように、新しい状態情報（つまり、新しいROHCデータ項目）が各SAに対して定義されています。ROHCデータ項目は、IPSECプロセスで使用して、特定のSAをROHCモジュール（ROHC対応）に通過するすべてのトラフィックを送信するか、ROHCモジュールをバイパスし、通常のIPSEC処理（ROHC障害）を介してトラフィックを送信するかどうかを判断する必要があります。
The Next Header field of the IPsec security protocol (e.g., AH or ESP) header MUST be used to demultiplex header-compressed traffic from uncompressed traffic traversing a ROHC-enabled SA. This functionality is needed in situations where packets traversing a ROHC-enabled SA contain uncompressed headers. Such situations may occur when, for example, a compressor only supports up to n compressed flows and cannot compress a flow number n+1 that arrives. Another example is when traffic is selected to a ROHC-enabled SA, but cannot be compressed by the ROHC process because the appropriate ROHC Profile has not been signaled for use. As a result, the decompressor MUST be able to identify packets with uncompressed headers and MUST NOT attempt to decompress them. The Next Header field is used to demultiplex these header-compressed and uncompressed packets where the "ROHC" protocol identifier will indicate that the packet contains compressed headers. To accomplish this, IANA has allocated value 142 to "ROHC" from the Protocol ID registry [PROTOCOL].
IPSECセキュリティプロトコル（AHまたはESPなど）の次のヘッダーフィールドは、ROHC対応SAを横断する非圧縮トラフィックからヘッダー圧縮トラフィックを非難するために使用する必要があります。この機能は、ROHC対応SAを通過するパケットが非圧縮ヘッダーを含む状況で必要です。このような状況は、たとえば、コンプレッサーが最大N圧縮フローのみをサポートし、到着するフロー数n 1を圧縮できない場合に発生する可能性があります。別の例は、ROHC対応SAにトラフィックが選択されたが、適切なROHCプロファイルが使用されていないため、ROHCプロセスでは圧縮できない場合です。その結果、減圧装置は、圧縮されていないヘッダーでパケットを識別できる必要があり、それらを減圧しようとしてはなりません。次のヘッダーフィールドは、「ROHC」プロトコル識別子がパケットに圧縮ヘッダーが含まれていることを示すこれらのヘッダー圧縮された非圧縮パケットを否定するために使用されます。これを達成するために、IANAはプロトコルIDレジストリ[プロトコル]から値142を「ROHC」に割り当てました。
It is noted that the use of the "ROHC" protocol identifier for purposes other than ROHCoIPsec is currently not defined. In other words, the "ROHC" protocol identifier is only defined for use in the Next Header field of security protocol headers (e.g., ESP, AH).
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].
ROHCデータ項目、IANAプロトコルID割り当て、およびROHCOIPSECをサポートするその他の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-Processingモデル内の元の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パケットのサイズを増加させます。この増加により、保護されていないドメインでPATH MTUの問題が発生する可能性があります。これらのパスMTUの問題を解決するためのいくつかのアプローチは、RFC 4301 [IPSEC]のセクション8で文書化されています。アプローチには、IPSEC処理の前または後のパケットの断片化（パケットのフラグメント（DF）ビットがクリアされている場合）、またはパケットの破棄（パケットのDFビットが設定されている場合）が含まれます。
The addition of ROHC within the IPsec processing model may result in similar path MTU challenges. For example, under certain circumstances, ROHC headers are larger than the original uncompressed headers. In addition, if an integrity algorithm is used to validate packet headers, the resulting ICV will increase the size of packets. Both of these properties of ROHCoIPsec increase the size of packets, and therefore may result in additional challenges associated with path MTU.
IPSEC処理モデル内にROHCを追加すると、同様のパスMTUの課題が発生する可能性があります。たとえば、特定の状況では、ROHCヘッダーは元の非圧縮ヘッダーよりも大きくなります。さらに、整合性アルゴリズムを使用してパケットヘッダーを検証する場合、結果のICVはパケットのサイズを増加させます。Rohcoipsecのこれらのプロパティの両方は、パケットのサイズを増加させるため、Path 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 RohcoipsecをサポートするIKEV2拡張機能
o IPsec Extensions to Support ROHCoIPsec
o RohcoipsecをサポートするIPSEC拡張機能
Several security considerations associated with the use of ROHCoIPsec are covered in Section 6.1.4. These considerations can be mitigated by using a strong integrity-check algorithm to ensure the valid decompression of packet headers.
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.
著者は、Sean O'Keeffe、James Kohler、およびLinda Noone of the Devention of Deventionに感謝し、この文書の開発における貢献とサポートについてOpNetのRich Espyに感謝したいと思います。
The authors would also like to thank Yoav Nir and Robert A Stangarone Jr.: both served as committed document reviewers for this specification.
著者はまた、Yoav NirとRobert a Stangarone JRに感謝したいと思います。
In addition, the authors would like to thank the following for their numerous reviews and comments to this document:
さらに、著者は、このドキュメントへの多数のレビューとコメントについて、以下に感謝したいと思います。
o Magnus Westerlund
o マグナス・ウェスターランド
o Stephen Kent
o スティーブン・ケント
o Pasi Eronen
o Pasi Eronen
o Joseph Touch
o ジョセフ・タッチ
o Tero Kivinen
o テロキビネン
o Jonah Pezeshki
o ジョナ・ペゼシュキ
o Lars-Erik Jonsson
o ラース・エリック・ジョンソン
o Jan Vilhuber
o Jan Vilhuber
o Dan Wing
o ダン・ウィング
o Kristopher Sandlund
o クリストファー・サンドランド
o Ghyslain Pelletier
o Ghyslain Pelletier
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.
最後に、著者はまた、この作品を完了するために支援をしてくれたブーズ・アレン・ハミルトンのトム・コンクル、レニー・エスポジト、エッツェル・ブロワー、ミケーレ・ケーシーにも感謝したいと思います。
[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月。
[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-TERM] Jonsson, L-E., "Robust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[RoHC-Term] Jonsson、L-E。、「ロバストヘッダー圧縮（ROHC）：用語とチャネルマッピングの例」、RFC 3759、2004年4月。
[BRA97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bra97] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP] Kent、S。、「セキュリティペイロード（ESP）のIPカプセル化」、RFC 4303、2005年12月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[IPSEC-ROHC] Ertekin, E., Christou, C., and C. Bormann, "IPsec Extensions to Support Robust Header Compression over IPsec", RFC 5858, May 2010.
[Ipsec-rohc] Ertekin、E.、Christou、C。、およびC. Bormann、「IPSECの堅牢なヘッダー圧縮をサポートするIPSEC拡張」、RFC 5858、2010年5月。
[IKE-ROHC] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. Bormann, "IKEv2 Extensions to Support Robust Header Compression over IPsec", RFC 5857, May 2010.
[Ike-rohc] Ertekin、E.、Christou、C.、Jasani、R.、Kivinen、T。、およびC. Bormann、「IKEV2拡張はIPSEC上の堅牢なヘッダー圧縮をサポートする」、RFC 5857、2010年5月。
[PROTOCOL] IANA, "Assigned Internet Protocol Numbers", <http://www.iana.org>.
[プロトコル] IANA、「インターネットプロトコル番号の割り当て」、<http://www.iana.org>。
[IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
[IPComp] Shacham、A.、Monsour、B.、Pereira、R。、およびM. Thomas、「IPペイロード圧縮プロトコル（IPComp）」、RFC 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] Pelletier、G。およびK. Sandlund、「Robust Header Compressionバージョン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] Pelletier、G.、Jonsson、L-E。、およびK. Sandlund、「Robust Header Compression（ROHC）：Packetsを並べ替えることができるROHCオーバーチャネル」、RFC 4224、2006年1月。
Authors' Addresses
著者のアドレス
Emre Ertekin Booz Allen Hamilton 5220 Pacific Concourse Drive, Suite 200 Los Angeles, CA 90045 US
Emre Ertekin Booz Allen Hamilton 5220 Pacific Concourse Drive、Suite 200 Los Angeles、CA 90045 US
EMail: ertekin_emre@bah.com
Rohan Jasani Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US
Rohan Jasani Booz Allen Hamilton 13200 Woodland Park Dr. Herndon、VA 20171 US
EMail: ro@breakcheck.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