[要約] RFC 5857は、IPsec上でRobust Header Compression（ROHC）をサポートするためのIKEv2拡張についての規格です。その目的は、IPsecトンネル上での効率的なヘッダ圧縮を実現し、ネットワークリソースの使用を最適化することです。
Internet Engineering Task Force (IETF) E. Ertekin
Request for Comments: 5857 C. Christou
Category: Standards Track R. Jasani
ISSN: 2070-1721 Booz Allen Hamilton
T. Kivinen
AuthenTec, Inc.
C. Bormann
Universitaet Bremen TZI
May 2010
IKEv2 Extensions to Support Robust Header Compression over IPsec
IKEV2拡張機能IPSECを介した堅牢なヘッダー圧縮をサポートします
Abstract
概要
In order to integrate Robust Header Compression (ROHC) with IPsec, a mechanism is needed to signal ROHC channel parameters between endpoints. Internet Key Exchange (IKE) is a mechanism that can be leveraged to exchange these parameters. This document specifies extensions to IKEv2 that will allow ROHC and its associated channel parameters to be signaled for IPsec Security Associations (SAs).
堅牢なヘッダー圧縮（ROHC）をIPSECと統合するには、エンドポイント間のROHCチャネルパラメーターを信号にするためのメカニズムが必要です。インターネットキーエクスチェンジ（IKE）は、これらのパラメーターを交換するために活用できるメカニズムです。このドキュメントでは、IKEV2への拡張機能を指定し、ROHCとそれに関連するチャネルパラメーターをIPSECセキュリティアソシエーション（SAS）に信号することができます。
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/rfc5857.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5857で取得できます。
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. ROHC Channel Initialization for ROHCoIPsec ......................3
3.1. ROHC_SUPPORTED Notify Message ..............................3
3.1.1. ROHC Attributes .....................................5
3.1.2. ROHC Attribute Types ................................6
3.2. ROHC Channel Parameters That Are Implicitly Set ............9
4. Security Considerations .........................................9
5. IANA Considerations .............................................9
6. Acknowledgments ................................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................12
Increased packet header overhead due to IPsec [IPSEC] can result in the inefficient utilization of bandwidth. Coupling ROHC [ROHC] with IPsec offers an efficient way to transfer protected IP traffic.
IPSEC [IPSEC]によるパケットヘッダーオーバーヘッドの増加により、帯域幅が非効率的な利用が得られる可能性があります。結合ROHC [ROHC]とIPSECは、保護されたIPトラフィックを転送する効率的な方法を提供します。
ROHCoIPsec [ROHCOIPSEC] requires configuration parameters to be initialized at the compressor and decompressor. Current specifications for hop-by-hop ROHC negotiate these parameters through a link-layer protocol such as the Point-to-Point Protocol (PPP) (i.e., ROHC over PPP [ROHC-PPP]). Since key exchange protocols (e.g., IKEv2 [IKEV2]) can be used to dynamically establish parameters between IPsec peers, this document defines extensions to IKEv2 to signal ROHC parameters for ROHCoIPsec.
Rohcoipsec [Rohcoipsec]は、コンプレッサーと分解器で構成パラメーターを初期化する必要があります。ホップバイホップROHCの現在の仕様は、ポイントツーポイントプロトコル（PPP）（つまり、PPP上のROHC [ROHC-PPP]）などのリンク層プロトコルを介してこれらのパラメーターをネゴシエートします。キー交換プロトコル（IKEV2 [IKEV2]）を使用してIPSECピア間のパラメーターを動的に確立できるため、このドキュメントはIKEV2の拡張機能を定義してROHCIPSECのROHCパラメーターを信号します。
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 define extensions to IKEv2 that enable an initiator and a responder to signal parameters required to establish a ROHC channel for a ROHCoIPsec session.
次のサブセクションでは、IKEV2への拡張機能を定義して、ROHCIPSECセッションのROHCチャネルを確立するために必要なパラメーターを信号にするイニシエーターとレスポンダーを有効にします。
ROHC channel parameters MUST be signaled separately for each ROHC-enabled IPsec SA. Specifically, a new Notify message type MUST be included in the IKE_AUTH and CREATE_CHILD_SA exchanges whenever a new ROHC-enabled IPsec SA is created, or an existing one is rekeyed.
ROHCチャネルパラメーターは、各ROHC対応IPSEC SAに対して個別に信号を送信する必要があります。具体的には、新しいROHC対応のIPSEC SAが作成された場合、または既存のものが再キーになった場合、新しいNotifyメッセージタイプをIKE_AUTHおよびCREATE_CHILD_SA交換に含める必要があります。
The Notify payload sent by the initiator MUST contain the channel parameters for the ROHC session. These parameters indicate the capabilities of the ROHC decompressor at the initiator. Upon receipt of the initiator's request, the responder will either ignore the payload (if it doesn't support ROHC or the proposed parameters) or respond with a Notify payload that contains its own ROHC channel parameters.
イニシエーターから送信された通知ペイロードには、ROHCセッションのチャネルパラメーターが含まれている必要があります。これらのパラメーターは、イニシエーターでのROHC減圧器の機能を示しています。イニシエーターの要求を受け取ると、レスポンダーはペイロードを無視し（ROHCまたは提案されたパラメーターをサポートしていない場合）、独自のROHCチャネルパラメーターを含む通知ペイロードで応答します。
Note that only one Notify payload is used to convey ROHC parameters. If multiple Notify payloads containing ROHC parameters are received, all but the first such Notify payload MUST be dropped. If the initiator does not receive a Notify payload with the responder's ROHC channel parameters, ROHC MUST NOT be enabled on the Child SA.
ROHCパラメーターを伝えるために使用されるペイロードを1つだけ使用することに注意してください。ROHCパラメーターを含む複数の通知ペイロードを受信する場合、最初のそのような通知ペイロードを除くすべてを除くすべてを削除する必要があります。イニシエーターがResponderのROHCチャネルパラメーターを使用してNotifyペイロードを受け取らない場合、ROHCをChild SAで有効にしてはなりません。
A new Notify Message Type value, denoted ROHC_SUPPORTED, indicates that the Notify payload is conveying ROHC channel parameters (Section 4).
ROHC_SUPPORTEDとされている新しいNOTIFYメッセージタイプ値は、通知ペイロードがROHCチャネルパラメーターを伝達していることを示しています（セクション4）。
The Notify payload (defined in RFC 4306 [IKEV2]) is illustrated in Figure 1.
Notifyペイロード（RFC 4306 [IKEV2]で定義）を図1に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Notify Payload Format
図1.ペイロード形式に通知します
The fields of the Notify payload are set as follows:
通知ペイロードのフィールドは次のように設定されています。
Next Payload (1 octet)
次のペイロード（1オクテット）
Identifier for the payload type of the next payload in the message. Further details can be found in RFC 4306 [IKEV2].
メッセージ内の次のペイロードのペイロードタイプの識別子。詳細については、RFC 4306 [IKEV2]をご覧ください。
Critical (1 bit)
クリティカル（1ビット）
Since all IKEv2 implementations support the Notify payload, this value MUST be set to zero.
すべてのIKEV2実装は通知ペイロードをサポートするため、この値はゼロに設定する必要があります。
Payload Length (2 octets)
ペイロード長（2オクテット）
As defined in RFC 4306 [IKEV2], this field indicates the length of the current payload, including the generic payload header.
RFC 4306 [IKEV2]で定義されているように、このフィールドは、汎用ペイロードヘッダーを含む現在のペイロードの長さを示します。
Protocol ID (1 octet)
プロトコルID（1オクテット）
Since this notification message is used during the creation of a Child SA, this field MUST be set to zero.
この通知メッセージは子供SAの作成中に使用されるため、このフィールドはゼロに設定する必要があります。
SPI Size (1 octet)
SPIサイズ（1オクテット）
This value MUST be set to zero, since no SPI is applicable (ROHC parameters are set at SA creation; thus, the SPI has not been defined).
SPIが適用されないため、この値はゼロに設定する必要があります（ROHCパラメーターはSA作成に設定されています。したがって、SPIは定義されていません）。
Notify Message Type (2 octets)
メッセージタイプ（2オクテット）に通知する
This field MUST be set to ROHC_SUPPORTED.
このフィールドは、rohc_supportedに設定する必要があります。
Security Parameter Index (SPI)
セキュリティパラメーターインデックス（SPI）
Since the SPI Size field is 0, this field MUST NOT be transmitted.
SPIサイズフィールドは0なので、このフィールドを送信してはなりません。
Notification Data (variable)
通知データ（変数）
This field MUST contain at least three ROHC Attributes (Section 3.1.1).
このフィールドには、少なくとも3つのROHC属性が含まれている必要があります（セクション3.1.1）。
The ROHC_SUPPORTED Notify message is used to signal channel parameters between ROHCoIPsec compressor and decompressor. The message contains a list of "ROHC Attributes", which contain the parameters required for the ROHCoIPsec session.
ROHC_SUPPORTED NOTIFYメッセージは、ROHCOIPSECコンプレッサーと減圧装置間のチャネルパラメーターを信号するために使用されます。このメッセージには、Rohcoipsecセッションに必要なパラメーターが含まれる「ROHC属性」のリストが含まれています。
The format for signaling ROHC Attributes takes a similar format to the Transform Attributes described in Section 3.3.5 of RFC 4306 [IKEV2]. The format of the ROHC Attribute is shown in Figure 2.
ROHC属性のシグナリングの形式は、RFC 4306 [IKEV2]のセクション3.3.5で説明されている変換属性と同様の形式を取ります。ROHC属性の形式を図2に示します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!A! ROHC Attribute Type ! AF=0 ROHC Attribute Length !
!F! ! AF=1 ROHC Attribute Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! AF=0 ROHC Attribute Value !
! AF=1 Not Transmitted !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Format of the ROHC Attribute
図2. ROHC属性の形式
o Attribute Format (AF) (1 bit) - If the AF bit is a zero (0), then the ROHC Attribute is expressed in a Type/Length/Value format. If the AF bit is a one (1), then the ROHC attribute is expressed in a Type/Value (TV) format.
o 属性形式（AF）（1ビット） - AFビットがゼロ（0）の場合、ROHC属性はタイプ/長さ/値形式で表されます。AFビットが1（1）の場合、ROHC属性はタイプ/値（TV）形式で表されます。
o ROHC Attribute Type (15 bits) - Unique identifier for each type of ROHC attribute (Section 3.1.2).
o ROHC属性タイプ（15ビット） - ROHC属性の各タイプの一意の識別子（セクション3.1.2）。
o ROHC Attribute Length (2 octets) - Length (in octets) of the Attribute Value. When the AF bit is a one (1), the ROHC Attribute Value is 2 octets and the ROHC Attribute Length field is not present.
o ROHC属性の長さ（2オクテット） - 属性値の長さ（オクテット内）。AFビットが1（1）の場合、ROHC属性値は2オクテットで、ROHC属性の長さフィールドは存在しません。
o ROHC Attribute Value (variable length) - Value of the ROHC Attribute associated with the ROHC Attribute Type. If the AF bit is a zero (0), this field's length is defined by the ROHC Attribute Length field. If the AF bit is a one (1), the length of the ROHC Attribute Value is 2 octets.
o ROHC属性値（変数長） - ROHC属性タイプに関連付けられたROHC属性の値。AFビットがゼロ（0）の場合、このフィールドの長さはROHC属性の長さフィールドによって定義されます。AFビットの場合、ROHC属性値の長さは2オクテットです。
This section describes five ROHC Attribute Types: MAX_CID, ROHC_PROFILE, ROHC_INTEG, ROHC_ICV_LEN, and MRRU. The value allocated for each ROHC Attribute Type is specified in Section 4.
このセクションでは、5つのROHC属性タイプについて説明します：MAX_CID、ROHC_PROFILE、ROHC_INTEG、ROHC_ICV_LEN、およびMRRU。各ROHC属性タイプに割り当てられた値は、セクション4で指定されています。
MAX_CID (Maximum Context Identifier, AF = 1)
max_cid（最大コンテキスト識別子、af = 1）
The MAX_CID attribute is a mandatory attribute. Exactly one MAX_CID attribute MUST be sent. The MAX_CID field indicates the maximum value of a context identifier supported by the ROHCoIPsec decompressor. This attribute value is 2 octets in length. The value for MAX_CID MUST be at least 0 and at most 16383. Since CIDs can take values between 0 and MAX_CID, the actual number of contexts that can be used are MAX_CID+1. If MAX_CID is 0, this implies having one context. The recipient of the MAX_CID Attribute MUST only use context identifiers up to MAX_CID for compression.
MAX_CID属性は必須属性です。正確に1つのMAX_CID属性を送信する必要があります。MAX_CIDフィールドは、Rohcoipsec Decompressorによってサポートされるコンテキスト識別子の最大値を示します。この属性値の長さは2オクテットです。MAX_CIDの値は少なくとも0で、最大16383でなければなりません。CIDSは0からMAX_CIDの間の値を取ることができるため、使用できるコンテキストの実際の数はMAX_CID 1です。MAX_CID属性の受信者は、圧縮のためにMAX_CIDまでのコンテキスト識別子のみを使用する必要があります。
Note that the MAX_CID parameter is a one-way notification (i.e., the sender of the attribute indicates what it can handle to the other end); therefore, different values for MAX_CID may be announced in each direction.
MAX_CIDパラメーターは一方向通知であることに注意してください（つまり、属性の送信者は、反対側に何を処理できるかを示します）。したがって、MAX_CIDの異なる値を各方向に発表することができます。
ROHC_PROFILE (ROHC Profile, AF = 1)
ROHC_PROFILE（ROHCプロファイル、AF = 1）
The ROHC_PROFILE attribute is a mandatory attribute. Each ROHC_PROFILE attribute has a fixed length of 4 octets, and its attribute value is a 2-octet long ROHC Profile Identifier [ROHCPROF]. There MUST be at least one ROHC_PROFILE attribute included in the ROHC_SUPPORTED Notify message. If multiple ROHC_PROFILE attributes are sent, the order is arbitrary. The recipient of a ROHC_PROFILE attribute(s) MUST only use the profile(s) proposed for compression.
ROHC_Profile属性は必須属性です。各ROHC_Profile属性の固定長は4オクテットで、その属性値は2オクセットの長いROHCプロファイル識別子[ROHCPROF]です。ROHC_Supported Notifyメッセージには、少なくとも1つのROHC_Profile属性が含まれている必要があります。複数のROHC_Profile属性が送信される場合、注文は任意です。ROHC_Profile属性の受信者は、圧縮用に提案されているプロファイルのみを使用する必要があります。
Several common profiles are defined in RFCs 3095 [ROHCV1] and 5225 [ROHCV2]. Note, however, that two versions of the same profile MUST NOT be signaled. For example, if a ROHCoIPsec decompressor supports both ROHCv1 UDP (0x0002) and ROHCv2 UDP (0x0102), both profiles MUST NOT be signaled. This restriction is needed, as packets compressed by ROHC express only the 8 least-significant bits of the profile identifier; since the 8 least-significant bits for corresponding profiles in ROHCv1 and ROHCv2 are identical, the decompressor is not capable of determining the ROHC version that was used to compress the packet.
いくつかの一般的なプロファイルは、RFCS 3095 [ROHCV1]および5225 [ROHCV2]で定義されています。ただし、同じプロファイルの2つのバージョンに信号を送信する必要はないことに注意してください。たとえば、ROHCOIPSECの減圧器がROHCV1 UDP（0x0002）とROHCV2 UDP（0x0102）の両方をサポートしている場合、両方のプロファイルを信号してはなりません。ROHCによって圧縮されたパケットは、プロファイル識別子の8つの最も重要なビットのビットのみを表現するため、この制限が必要です。ROHCV1とROHCV2の対応するプロファイルの8つの最も重要なビットは同一であるため、減圧装置はパケットを圧縮するために使用されたROHCバージョンを決定することはできません。
Note that the ROHC_PROFILE attribute is a one-way notification; therefore, different values for ROHC_PROFILE may be announced in each direction.
ROHC_Profile属性は一方向通知であることに注意してください。したがって、ROHC_Profileの異なる値が各方向に発表される場合があります。
ROHC_INTEG (Integrity Algorithm for Verification of Decompressed Headers, AF = 1)
ROHC_INTEG（減圧されたヘッダーの検証のための整合性アルゴリズム、AF = 1）
The ROHC_INTEG attribute is a mandatory attribute. There MUST be at least one ROHC_INTEG attribute contained within the ROHC_SUPPORTED Notify message. The attribute value contains the identifier of an integrity algorithm that is used to ensure the integrity of the decompressed packets (i.e., ensure that the decompressed packet headers are identical to the original packet headers prior to compression).
ROHC_INTEG属性は必須属性です。ROHC_SUPPORTED NOTIFYメッセージに含まれる少なくとも1つのROHC_INTEG属性が含まれている必要があります。属性値には、減圧されたパケットの整合性を確保するために使用される整合性アルゴリズムの識別子が含まれています（つまり、減圧されたパケットヘッダーが圧縮前の元のパケットヘッダーと同一であることを確認します）。
Authentication algorithms that MUST be supported are specified in the "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暗号化および認証アルゴリズム」）の「認証アルゴリズム」テーブルで指定されています。
The integrity algorithm is represented by a 2-octet value that corresponds to the value listed in the IKEv2 Parameters registry [IKEV2-PARA], "Transform Type 3 - Integrity Algorithm Transform IDs" section. Upon receipt of the ROHC_INTEG attribute(s), the responder MUST select exactly one of the proposed algorithms; the chosen value is sent back in the ROHC_SUPPORTED Notify message returned by the responder to the initiator. The selected integrity algorithm MUST be used in both directions. If the responder does not accept any of the algorithms proposed by the initiator, ROHC MUST NOT be enabled on the SA.
整合性アルゴリズムは、IKEV2パラメーターレジストリ[IKEV2-PARA]にリストされている値に対応する2-OCTET値で表されます。ROHC_INTEG属性を受け取ると、レスポンダーは提案されたアルゴリズムの1つを正確に選択する必要があります。選択された値は、Responderがイニシエーターに返したROHC_SUPPORTED NOTIFYメッセージで送信されます。選択した整合性アルゴリズムは、両方向に使用する必要があります。Responderがイニシエーターによって提案されたアルゴリズムのいずれかを受け入れない場合、ROHCをSAで有効にしてはなりません。
It is noted that:
それは次のとおりです。
1. The keys (one for each direction) for this integrity algorithm are derived from the IKEv2 KEYMAT (see [IKEV2], Section 2.17). For the purposes of this key derivation, ROHC is considered to be an IPsec protocol. When a ROHC-enabled CHILD_SA is rekeyed, the key associated with this integrity algorithm is rekeyed as well.
1. この整合性アルゴリズムのキー（各方向に1つ）は、IKEV2キーマットから派生しています（[IKEV2]、セクション2.17を参照）。この重要な派生の目的のために、ROHCはIPSECプロトコルと見なされます。ROHC対応のchild_saが再キーになっている場合、この整合性アルゴリズムに関連する鍵も再キーになります。
2. A ROHCoIPsec initiator MAY signal a value of zero (0x0000) in a ROHC_INTEG attribute. This corresponds to "NONE" in the "IKEv2 Integrity Algorithm Transform IDs" registry. The ROHCoIPsec responder MAY select this value by responding to the initiator with a ROHC_INTEG attribute of zero (0x0000). In this scenario, no integrity algorithm is applied in either direction.
2. ROHCOIPSECイニシエーターは、ROHC_INTEG属性のゼロ（0x0000）の値を信号する場合があります。これは、「IKEV2 Integrity Algorithm Transform IDS」レジストリの「なし」に対応します。Rohcoipsec Responderは、ゼロ（0x0000）のROHC_INTEG属性を使用してイニシエーターに応答することにより、この値を選択できます。このシナリオでは、どちらの方向にも整合性アルゴリズムは適用されません。
3. The ROHC_INTEG attribute is a parameter that is negotiated between two ends. In other words, the initiator indicates what it supports, the responder selects one of the ROHC_INTEG values proposed and sends the selected value to the initiator.
3. ROHC_INTEG属性は、2つの端の間でネゴシエートされるパラメーターです。言い換えれば、イニシエーターはそれがサポートするものを示し、レスポンダーは提案されているROHC_INTEG値の1つを選択し、選択した値をイニシエーターに送信します。
ROHC_ICV_LEN (Integrity Algorithm Length, AF = 1)
ROHC_ICV_LEN（Integrity Algorithmの長さ、AF = 1）
The ROHC_ICV_LEN attribute is an optional attribute. There MAY be zero or one ROHC_ICV_LEN attribute contained within the ROHC_SUPPORTED Notify message. The attribute specifies the number of Integrity Check Value (ICV) octets the sender expects to receive on incoming ROHC packets. The ICV of the negotiated ROHC_INTEG algorithms MUST be truncated to ROHC_ICV_LEN bytes by taking the first ROHC_ICV_LEN bytes of the output. Both the initiator and responder announce a single value for their own ICV length. The recipient of the ROHC_ICV_LEN attribute MUST truncate the ICV to the length contained in the message. If the value of the ROHC_ICV_LEN attribute is zero, then an ICV MUST NOT be sent. If no ROHC_ICV_LEN attribute is sent at all or if the ROHC_ICV_LEN is larger than the length of the ICV of selected algorithm, then the full ICV length as specified by the ROHC_INTEG algorithm MUST be sent.
ROHC_ICV_LEN属性はオプションの属性です。ROHC_SUPPORTED NOTIFYメッセージに含まれるゼロまたは1つのROHC_ICV_LEN属性がある場合があります。属性は、整合性チェック値（ICV）の数を指定します。ネゴシエートされたROHC_INTEGアルゴリズムのICVは、出力の最初のROHC_ICV_LENバイトを取得することにより、ROHC_ICV_LENバイトに切り捨てられる必要があります。イニシエーターとレスポンダーの両方が、独自のICV長の単一値を発表します。ROHC_ICV_LEN属性の受信者は、メッセージに含まれる長さにICVを切り捨てる必要があります。ROHC_ICV_LEN属性の値がゼロの場合、ICVを送信してはなりません。ROHC_ICV_LEN属性がまったく送信されない場合、またはROHC_ICV_LENが選択されたアルゴリズムのICVの長さよりも大きい場合、ROHC_INTEGアルゴリズムで指定された完全なICV長を送信する必要があります。
Note that the ROHC_ICV_LEN attribute is a one-way notification; therefore, different values for ROHC_ICV_LEN may be announced in each direction.
ROHC_ICV_LEN属性は一方向通知であることに注意してください。したがって、ROHC_ICV_LENの異なる値が各方向に発表される場合があります。
MRRU (Maximum Reconstructed Reception Unit, AF = 1)
MRRU（最大再構築された受信ユニット、AF = 1）
The MRRU attribute is an optional attribute. There MAY be zero or one MRRU attribute contained within the ROHC_SUPPORTED Notify message. The attribute value is 2 octets in length. The attribute specifies the size of the largest reconstructed unit in octets that the ROHCoIPsec decompressor is expected to reassemble from ROHC segments (see Section 5.2.5 of [ROHCV1]). This size includes the Cyclic Redundancy Check (CRC) and the ROHC ICV. If MRRU is 0 or if no MRRU attribute is sent, segment headers MUST NOT be transmitted on the ROHCoIPsec channel.
MRRU属性はオプションの属性です。ROHC_SUPPORTED NOTIFYメッセージに含まれるゼロまたは1つのMRRU属性がある場合があります。属性値の長さは2オクテットです。属性は、Rohcoipsec分解器がROHCセグメントから再組み立てられると予想されるオクテットの最大の再構築ユニットのサイズを指定します（[ROHCV1]のセクション5.2.5を参照）。このサイズには、環状冗長チェック（CRC）とROHC ICVが含まれます。MRRUが0の場合、またはMRRU属性が送信されない場合、セグメントヘッダーをRohcoipsecチャネルに送信してはなりません。
Note that the MRRU attribute is a one-way notification; therefore, different values for MRRU may be announced in each direction.
MRRU属性は一方向通知であることに注意してください。したがって、MRRUの異なる値が各方向に発表される場合があります。
If an unknown ROHC Attribute Type Value is received, it MUST be silently ignored.
未知のROHC属性タイプの値を受信した場合、静かに無視する必要があります。
The following ROHC channel parameters MUST NOT be signaled:
次のROHCチャネルパラメーターを通知してはなりません。
o LARGE_CIDS: This value is implicitly determined by the value of MAX_CID (i.e., if MAX_CID is <= 15, LARGE_CIDS is assumed to be 0).
o lage_cids：この値は、max_cidの値によって暗黙的に決定されます（つまり、max_cidが<= 15の場合、large_cidsは0と想定されます）。
o FEEDBACK_FOR: When a pair of SAs is created (one in each direction), the ROHC channel parameter FEEDBACK_FOR MUST be set implicitly to the other SA of the pair (i.e., the SA pointing in the reverse direction).
o Feedback_for：SASのペア（各方向に1つ）が作成されると、ROHCチャネルパラメーターFeedback_forは、ペアの他のSAに暗黙的に設定する必要があります（つまり、SAは逆方向に向けています）。
The ability to negotiate the length of the ROHC ICV may introduce vulnerabilities to the ROHCoIPsec protocol. Specifically, the capability to signal a short ICV length may result in scenarios where erroneous packets are forwarded into the protected domain. This security consideration is documented in further detail in Section 6.1.4 of [ROHCOIPSEC] and Section 5 of [IPSEC-ROHC].
ROHC ICVの長さを交渉する能力は、Rohcoipsecプロトコルに対して脆弱性をもたらす可能性があります。具体的には、短いICVの長さを通知する機能により、誤ったパケットが保護されたドメインに転送されるシナリオが生じる場合があります。このセキュリティの考慮事項は、[Rohcoipsec]のセクション6.1.4および[IPSEC-ROHC]のセクション5にさらに詳しく説明されています。
This security consideration can be mitigated by using longer ICVs, but this comes at the cost of additional overhead, which reduces the overall benefits offered by ROHCoIPsec.
このセキュリティの考慮事項は、より長いICVを使用することで軽減できますが、これは追加のオーバーヘッドを犠牲にして、Rohcoipsecが提供する全体的な利点を減らすことができます。
This document defines a new Notify message (Status Type). Therefore, IANA has allocated one value from the "IKEv2 Notify Message Types" registry to indicate ROHC_SUPPORTED.
このドキュメントは、新しいNotifyメッセージ（ステータスタイプ）を定義します。したがって、IANAは、「IKEV2通知メッセージタイプ」レジストリから1つの値をROHC_SUPPORTEDを示すために割り当てました。
In addition, IANA has created a new "ROHC Attribute Types" registry in the "Internet Key Exchange Version 2 (IKEv2) Parameters" registry [IKEV2-PARA]. Within the "ROHC Attribute Types" registry, this document allocates the following values:
さらに、IANAは、「Internet Key Exchangeバージョン2（IKEV2）パラメーター」レジストリ[IKEV2-PARA]に新しい「ROHC属性タイプ」レジストリを作成しました。「ROHC属性タイプ」レジストリ内で、このドキュメントは次の値を割り当てます。
Registry:
Value ROHC Attribute Type Format Reference
----------- -------------------------------------- ------ ---------
0 RESERVED [RFC5857]
1 Maximum Context Identifier (MAX_CID) TV [RFC5857]
2 ROHC Profile (ROHC_PROFILE) TV [RFC5857]
3 ROHC Integrity Algorithm (ROHC_INTEG) TV [RFC5857]
4 ROHC ICV Length in bytes (ROHC_ICV_LEN) TV [RFC5857]
5 Maximum Reconstructed Reception Unit (MRRU) TV [RFC5857]
6-16383 Unassigned
16384-32767 Private use [RFC5857]
Following the policies outlined in [IANA-CONSIDERATIONS], the IANA policy for assigning new values for the ROHC Attribute Types registry shall be Expert Review.
[IANA-Considerations]で概説されているポリシーに続いて、ROHC属性タイプのレジストリに新しい値を割り当てるためのIANAポリシーは、専門家のレビューとなります。
For registration requests, the responsible IESG Area Director will appoint the Designated Expert. The Designated Expert will post a request to both the ROHC and IPsec mailing lists (or a successor designated by the Area Director) for comment and review. The Designated Expert will either approve or deny the registration request and publish a notice of the decision to both mailing lists (or their successors), as well as informing IANA. A denial notice must be justified by an explanation.
登録リクエストのために、責任あるIESGエリアディレクターが指定された専門家を任命します。指定された専門家は、コメントとレビューのために、ROHCとIPSECのメーリングリスト（またはエリアディレクターが指定した後継者）にリクエストを投稿します。指定された専門家は、登録要求を承認または拒否し、メーリングリスト（または後継者）の両方に決定の通知を公開し、IANAに通知します。拒否通知は、説明によって正当化されなければなりません。
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 Lars-Erik Jonsson
o ラース・エリック・ジョンソン
o Pasi Eronen
o Pasi Eronen
o Jonah Pezeshki o Carl Knutsson
o Jonah Pezeshki O Carl Knutsson
o Joseph Touch
o ジョセフ・タッチ
o David Black
o デビッド・ブラック
o Glen Zorn
o グレンゾーン
Finally, the authors would also like to thank Tom Conkle, Michele Casey, and Etzel Brower.
最後に、著者はまた、トム・コンクル、ミシェル・ケーシー、エッツェル・ブロワーに感謝したいと思います。
[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月。
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[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月。
[ROHCV1] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[Rohcv1] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[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月。
[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月。
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[Iana-Consididerations] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[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月。
[ROHC-PPP] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[ROHC-PPP] Bormann、C。、「PPP上の堅牢なヘッダー圧縮（ROHC）」、RFC 3241、2002年4月。
[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月。
[IKEV2-PARA] IANA, "Internet Key Exchange Version 2 (KEv2) Parameters", <http://www.iana.org>.
[IKEV2-PARA] IANA、「インターネットキーエクスチェンジバージョン2（KEV2）パラメーター」、<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
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
Tero Kivinen AuthenTec, Inc. Fredrikinkatu 47 HELSINKI FI
Tero Kivinen Aedecurec、Inc。Fredrikinkatu 47 Helsinki Fi
EMail: kivinen@iki.fi
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