[要約] RFC 5840は、トラフィックの可視性のための包括的なセキュリティペイロード（ESP）を提供するための仕様です。このRFCの目的は、ネットワークトラフィックの暗号化と可視性の両方を実現するための標準化を提供することです。
Internet Engineering Task Force (IETF) K. Grewal
Request for Comments: 5840 Intel Corporation
Category: Standards Track G. Montenegro
ISSN: 2070-1721 Microsoft Corporation
M. Bhatia
Alcatel-Lucent
April 2010
Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility
トラフィックの可視性のためのセキュリティペイロード（ESP）のラップ
Abstract
概要
This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) RFC 4303 and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP, and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently, in the IPsec ESP standard, there is no deterministic way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP.
このドキュメントでは、セキュリティペイロード（ESP）RFC 4303のカプセル化に基づいたラップカプセル化セキュリティペイロード（WESP）プロトコルについて説明し、中間デバイスが（1）ESP内でデータの機密性が採用されているかどうかを確認するように設計されています。（2）ネットワーク監視およびアクセス制御機能については、IPSECパケットを検査します。現在、IPSEC ESP標準では、パケットを調べるだけで暗号化されたペイロードと暗号化されていないペイロードを区別する決定的な方法はありません。これは、そのパケットで何をすべきかを決定する前に、パケットを深く検査する必要がある中間デバイスに特定の課題をもたらします（検査および/または許可/ドロップ）。このドキュメントで説明されているメカニズムは、ESPによって提供されるセキュリティに妥協することなく、ESP暗号化されたパケットから整合のみのESPを簡単に明確にするために使用できます。
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/rfc5840.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5840で取得できます。
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
1.1. Requirements Language ......................................4
1.2. Applicability Statement ....................................4
2. Wrapped ESP (WESP) Header Format ................................5
2.1. UDP Encapsulation ..........................................8
2.2. Transport and Tunnel Mode Considerations ...................9
2.2.1. Transport Mode Processing ...........................9
2.2.2. Tunnel Mode Processing .............................10
2.3. IKE Considerations ........................................11
3. Security Considerations ........................................12
4. IANA Considerations ............................................13
5. Acknowledgments ................................................13
6. References .....................................................14
6.1. Normative References ......................................14
6.2. Informative References ....................................14
Use of ESP within IPsec [RFC4303] specifies how ESP packet encapsulation is performed. It also specifies that ESP can provide data confidentiality and data integrity services. Data integrity without data confidentiality ("integrity-only ESP") is possible via the ESP-NULL encryption algorithm [RFC2410] or via combined-mode algorithms such as AES-GMAC [RFC4543]. The exact encapsulation and algorithms employed are negotiated out of band using, for example, Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306] and based on policy.
IPSEC [RFC4303]内のESPの使用は、ESPパケットのカプセル化の実行方法を指定します。また、ESPがデータの機密性とデータ整合性サービスを提供できることも指定しています。データの機密性のないデータの整合性（「IntegrityのみのESP」）は、ESP-Null暗号化アルゴリズム[RFC2410]またはAES-GMAC [RFC4543]などの複合モードアルゴリズムを介して可能です。採用されている正確なカプセル化とアルゴリズムは、たとえばインターネットキーエクスチェンジプロトコル2（IKEV2）[RFC4306]を使用して、ポリシーに基づいてバンドから交渉されます。
Enterprise environments typically employ numerous security policies (and tools for enforcing them), as related to access control, content screening, firewalls, network monitoring functions, deep packet inspection, Intrusion Detection and Prevention Systems (IDS and IPS), scanning and detection of viruses and worms, etc. In order to enforce these policies, network tools and intermediate devices require visibility into packets, ranging from simple packet header inspection to deeper payload examination. Network security protocols that encrypt the data in transit prevent these network tools from performing the aforementioned functions.
エンタープライズ環境は通常、アクセス制御、コンテンツスクリーニング、ファイアウォール、ネットワーク監視機能、ディープパケット検査、侵入検知および予防システム（IDおよびIP）、スキャン、ウイルスの検出に関連する、多数のセキュリティポリシー（およびそれらを実施するためのツール）を採用しています。これらのポリシーを実施するために、ネットワークツールと中間デバイスは、単純なパケットヘッダー検査からより深いペイロード試験に至るまで、パケットを可視化する必要があります。トランジットでデータを暗号化するネットワークセキュリティプロトコルは、これらのネットワークツールが前述の機能を実行することを防ぎます。
When employing IPsec within an enterprise environment, it is desirable to employ ESP instead of Authentication Header (AH) [RFC4302], as AH does not work in NAT environments. Furthermore, in order to preserve the above network monitoring functions, it is desirable to use integrity-only ESP. In a mixed-mode environment, some packets containing sensitive data employ a given encryption cipher suite, while other packets employ integrity-only ESP. For an intermediate device to unambiguously distinguish which packets are using integrity-only ESP requires knowledge of all the policies being employed for each protected session. This is clearly not practical. Heuristics-based methods can be employed to parse the packets, but these can be very expensive, requiring numerous rules based on each different protocol and payload. Even then, the parsing may not be robust in cases where fields within a given encrypted packet happen to resemble the fields for a given protocol or heuristic rule. In cases where the packets may be encrypted, it is also wasteful to check against heuristics-based rules, when a simple exception policy (e.g., allow, drop, or redirect) can be employed to handle the encrypted packets. Because of the non-deterministic nature of heuristics-based rules for disambiguating between encrypted and non-encrypted data, an alternative method for enabling intermediate devices to function in encrypted data environments needs to be defined. Additionally, there are many types and classes of network devices employed within a given network and a deterministic approach provides a simple solution for all of them. Enterprise environments typically use both stateful and stateless packet inspection mechanisms. The previous considerations weigh particularly heavy on stateless mechanisms such as router Access Control Lists (ACLs) and NetFlow exporters. Nevertheless, a deterministic approach provides a simple solution for the myriad types of devices employed within a network, regardless of their stateful or stateless nature.
エンタープライズ環境内でIPSECを使用する場合、AHはNAT環境では機能しないため、認証ヘッダー（AH）[RFC4302]の代わりにESPを使用することが望ましいです。さらに、上記のネットワーク監視機能を保存するためには、IntegrityのみのESPを使用することが望ましい。混合モード環境では、機密データを含む一部のパケットは特定の暗号化暗号スイートを採用していますが、他のパケットはIntegrityのみのESPを採用しています。中間デバイスが整合性のみのESPを使用しているパケットが、保護された各セッションで採用されているすべてのポリシーの知識が必要であるかを明確に区別するために。これは明らかに実用的ではありません。ヒューリスティックベースの方法を使用するためにパケットを解析することができますが、これらは非常に高価であり、それぞれの異なるプロトコルとペイロードに基づいて多数のルールが必要です。それでも、特定の暗号化されたパケット内のフィールドが、特定のプロトコルまたはヒューリスティックルールのフィールドに似ている場合、解析は堅牢ではない場合があります。パケットが暗号化される場合がある場合は、暗号化されたパケットを処理するために単純な例外ポリシー（許容、ドロップ、またはリダイレクトなど）を使用できる場合、ヒューリスティックベースのルールに対して確認することも無駄です。暗号化されたデータと非暗号化されていないデータを曖昧にするためのヒューリスティックベースのルールの非決定的性質のため、暗号化されたデータ環境で中間デバイスを機能させるための代替方法を定義する必要があります。さらに、特定のネットワーク内で採用されているネットワークデバイスには多くのタイプとクラスがあり、決定論的アプローチはそれらすべてに簡単なソリューションを提供します。エンタープライズ環境は通常、ステートフルとステートレスのパケット検査メカニズムの両方を使用します。以前の考慮事項は、ルーターアクセス制御リスト（ACL）やNetflow輸出業者などのステートレスメカニズムで特に重いです。それにもかかわらず、決定論的なアプローチは、ステートフルまたはステートレスの性質に関係なく、ネットワーク内で採用されている無数のタイプのデバイスに簡単なソリューションを提供します。
This document defines a mechanism to provide additional information in relevant IPsec packets so intermediate devices can efficiently differentiate between encrypted and integrity-only packets. Additionally, and in the interest of consistency, this extended format can also be used to carry encrypted packets without loss in disambiguation.
このドキュメントは、関連するIPSECパケットに追加情報を提供するメカニズムを定義しているため、中間デバイスは暗号化されたパケットと整合性のみのパケットを効率的に区別できます。さらに、一貫性のために、この拡張形式を使用して、暗号化されたパケットを曖昧性を損なうことなく運ぶこともできます。
This document is consistent with the operation of ESP in NAT environments [RFC3947].
このドキュメントは、NAT環境でのESPの動作と一致しています[RFC3947]。
The design principles for this protocol are the following:
このプロトコルの設計原則は次のとおりです。
o Allow easy identification and parsing of integrity-only IPsec traffic
o 整合性のみのIPSECトラフィックの簡単な識別と解析を可能にします
o Leverage the existing hardware IPsec parsing engines as much as possible to minimize additional hardware design costs
o 追加のハードウェア設計コストを最小限に抑えるために、既存のハードウェアIPSEC解析エンジンを可能な限り活用する
o Minimize the packet overhead in the common case
o 一般的なケースのパケットオーバーヘッドを最小限に抑えます
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
The document is applicable only to the wrapped ESP header defined below, and does not describe any changes to either ESP [RFC4303] or the IP Authentication Header (AH) [RFC4302].
このドキュメントは、以下に定義されているラップされたESPヘッダーにのみ適用され、ESP [RFC4303]またはIP認証ヘッダー（AH）[RFC4302]のいずれの変更も説明していません。
There are two well-accepted ways to enable intermediate security devices to distinguish between encrypted and unencrypted ESP traffic:
中間セキュリティデバイスが暗号化されたESPトラフィックと暗号化されていないESPトラフィックを区別できるようにするための2つの十分に受け入れられた方法があります。
- The heuristics approach [Heuristics] has the intermediate node inspect the unchanged ESP traffic, to determine with extremely high probability whether or not the traffic stream is encrypted.
- ヒューリスティックアプローチ[ヒューリスティック]には、中間ノードが変更されていないESPトラフィックを検査して、トラフィックストリームが暗号化されているかどうかを非常に高い確率で決定します。
- The Wrapped ESP (WESP) approach, described in this document, in contrast, requires the ESP endpoints to be modified to support the new protocol. WESP allows the intermediate node to distinguish encrypted and unencrypted traffic deterministically, using a simpler implementation for the intermediate node.
- 対照的に、このドキュメントで説明されているラップされたESP（WESP）アプローチでは、新しいプロトコルをサポートするためにESPエンドポイントを変更する必要があります。WESPを使用すると、中間ノードが暗号化されていないトラフィックを決定的に区別し、中間ノードのよりシンプルな実装を使用して、決定論的に区別できます。
Both approaches are being documented simultaneously by the IP Security Maintenance and Extensions (IPsecME) Working Group, with WESP (this document) as a Standards Track RFC while the heuristics approach is expected to be published as an Informational RFC. While endpoints are being modified to adopt WESP, we expect both approaches to coexist for years because the heuristic approach is needed to inspect traffic where at least one of the endpoints has not been modified. In other words, intermediate nodes are expected to support both approaches in order to achieve good security and performance during the transition period.
両方のアプローチは、IPセキュリティメンテナンスと拡張機能（IPSECME）ワーキンググループによって同時に文書化されており、WESP（このドキュメント）がRFCを追跡する一方で、ヒューリスティックアプローチは情報RFCとして公開されると予想されます。エンドポイントはWESPを採用するために変更されていますが、エンドポイントの少なくとも1つが変更されていないトラフィックを検査するためにヒューリスティックアプローチが必要であるため、両方のアプローチが長年共存することを期待しています。言い換えれば、中間ノードは、移行期間中に優れたセキュリティとパフォーマンスを達成するために、両方のアプローチをサポートすることが期待されています。
Wrapped ESP (WESP) encapsulation uses protocol number 141. Accordingly, the (outer) protocol header (IPv4, IPv6, or Extension) that immediately precedes the WESP header SHALL contain the value (141) in its Protocol (IPv4) or Next Header (IPv6, Extension) field. WESP provides additional attributes in each packet to assist in differentiating between encrypted and non-encrypted data, and to aid in parsing of the packet. WESP follows RFC 4303 for all IPv6 and IPv4 considerations (e.g., alignment considerations).
ラップされたESP（WESP）カプセル化はプロトコル番号141を使用します。したがって、WESPヘッダーの直前の（外側の）プロトコルヘッダー（IPv4、IPv6、または拡張）は、そのプロトコル（IPv4）または次のヘッダー（IPv4）または次のヘッダーに値（141）を含めるものとします。IPv6、拡張）フィールド。WESPは、各パケットに追加の属性を提供し、暗号化されたデータと非暗号化データの区別を支援し、パケットの解析を支援します。WESPは、すべてのIPv6およびIPv4の考慮事項についてRFC 4303に従います（たとえば、アライメントの考慮事項）。
This extension essentially acts as a wrapper to the existing ESP protocol and provides an additional 4 octets at the front of the existing ESP packet for IPv4. For IPv6, additional padding may be required and this is described below.
この拡張機能は、本質的に既存のESPプロトコルのラッパーとして機能し、IPv4の既存のESPパケットの前面に追加の4オクテットを提供します。IPv6の場合、追加のパディングが必要になる場合があり、これについては以下に説明します。
The packet format may be depicted as follows:
パケット形式は次のように描写できます。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wrapped ESP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: WESP Packet Format
図1：WESPパケット形式
By preserving the body of the existing ESP packet format, a compliant implementation can simply add in the new header, without needing to change the body of the packet. The value of the new protocol used to identify this new header is 141. Further details are shown below:
既存のESPパケット形式の本文を保存することにより、準拠した実装は、パケットの本文を変更する必要なく、新しいヘッダーを単純に追加できます。この新しいヘッダーを識別するために使用される新しいプロトコルの値は141です。詳細については、以下を示します。
0 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 Header | HdrLen | TrailerLen | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Detailed WESP Packet Format
図2：詳細なWESPパケット形式
Where:
ただし：
Next Header, 8 bits: This field MUST be the same as the Next Header field in the ESP trailer when using ESP in the Integrity-only mode. When using ESP with encryption, the "Next Header" field looses this name and semantics and becomes an empty field that MUST be initialized to all zeros. The receiver MUST do some sanity checks before the WESP packet is accepted. The receiver MUST ensure that the Next Header field in the WESP header and the Next Header field in the ESP trailer match when using ESP in the Integrity-only mode. The packet MUST be dropped if the two do not match. Similarly, the receiver MUST ensure that the Next Header field in the WESP header is an empty field initialized to zero if using WESP with encryption. The WESP flags dictate if the packet is encrypted.
次のヘッダー、8ビット：このフィールドは、IntegrityのみのモードでESPを使用する場合、ESPトレーラーの次のヘッダーフィールドと同じでなければなりません。暗号化でESPを使用すると、「次のヘッダー」フィールドはこの名前とセマンティクスを失い、すべてのゼロに初期化する必要がある空のフィールドになります。WESPパケットが受け入れられる前に、受信者はいくつかの正気チェックを行う必要があります。レシーバーは、整合性のみモードでESPを使用する場合、WESPヘッダーの次のヘッダーフィールドとESPトレーラーマッチの次のヘッダーフィールドを確認する必要があります。2つが一致しない場合は、パケットをドロップする必要があります。同様に、受信機は、WESPヘッダーの次のヘッダーフィールドが、暗号化でWESPを使用する場合、ゼロに初期化された空のフィールドであることを確認する必要があります。WESPフラグは、パケットが暗号化されているかどうかを決定します。
HdrLen, 8 bits: Offset from the beginning of the WESP header to the beginning of the Rest of Payload Data (i.e., past the IV, if present and any other WESP options defined in the future) within the encapsulated ESP header, in octets. HdrLen MUST be set to zero when using ESP with encryption. When using integrity-only ESP, the following HdrLen values are invalid: any value less than 12; any value that is not a multiple of 4; any value that is not a multiple of 8 when using IPv6. The receiver MUST ensure that this field matches with the header offset computed from using the negotiated Security Association (SA) and MUST drop the packet in case it does not match.
HDRLEN、8ビット：WESPヘッダーの先頭から残りのペイロードデータの開始までオフセット（つまり、IVを過ぎて、存在する場合、および将来定義されている他のWESPオプションを超えて）。ESPを暗号化で使用する場合、HDRLENをゼロに設定する必要があります。IntegrityのみのESPを使用する場合、次のHDRLEN値が無効です。12未満の値。4の倍数ではない値。IPv6を使用する場合、8の倍数ではない値。受信機は、このフィールドが、ネゴシエートセキュリティ協会（SA）の使用から計算されたヘッダーオフセットと一致することを確認する必要があり、一致しない場合にパケットをドロップする必要があります。
TrailerLen, 8 bits: TrailerLen contains the size of the Integrity Check Value (ICV) being used by the negotiated algorithms within the IPsec SA, in octets. TrailerLen MUST be set to zero when using ESP with encryption. The receiver MUST only accept the packet if this field matches with the value computed from using the negotiated SA. This ensures that sender is not deliberately setting this value to obfuscate a part of the payload from examination by a trusted intermediary device.
TRAIRERLEN、8ビット：TRAIRERLENには、IPSEC SA内の交渉されたアルゴリズムがオクテットの整合性チェック値（ICV）のサイズが含まれています。ESPを暗号化で使用する場合、Trailerlenをゼロに設定する必要があります。このフィールドがネゴシエートされたSAを使用して計算された値と一致する場合にのみ、受信機はパケットを受け入れる必要があります。これにより、送信者がこの値を意図的に設定して、信頼できる仲介デバイスによる試験からペイロードの一部を難読化することができません。
Flags, 8 bits: The bits are defined most-significant-bit (MSB) first, so bit 0 is the most significant bit of the flags octet.
フラグ、8ビット：ビットは最初に最も重要なビット（MSB）が定義されているため、ビット0はフラグの最も重要なビットです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V V|E|P| Rsvd |
+-+-+-+-+-+-+-+-+
Figure 3: Flags Format
図3：フラグ形式
Version (V), 2 bits: MUST be sent as 0 and checked by the receiver. If the version is different than an expected version number (e.g., negotiated via the control channel), then the packet MUST be dropped by the receiver. Future modifications to the WESP header require a new version number. In particular, the version of WESP defined in this document does not allow for any extensions. However, old implementations will still be able to find the encapsulated cleartext packet using the HdrLen field from the WESP header, when the 'E' bit is not set. Intermediate nodes dealing with unknown versions are not necessarily able to parse the packet correctly. Intermediate treatment of such packets is policy dependent (e.g., it may dictate dropping such packets).
バージョン（v）、2ビット：0として送信し、受信機によってチェックされる必要があります。バージョンが予想されるバージョン番号（コントロールチャネルを介してネゴシエートされるなど）とは異なる場合、パケットは受信機によって削除する必要があります。WESPヘッダーの将来の変更には、新しいバージョン番号が必要です。特に、このドキュメントで定義されたWESPのバージョンでは、拡張機能は許可されていません。ただし、「E」ビットが設定されていない場合、古い実装では、WESPヘッダーのHDRLENフィールドを使用してカプセル化されたクリアテキストパケットを見つけることができます。不明なバージョンを扱う中間ノードは、必ずしもパケットを正しく解析できるわけではありません。このようなパケットの中間処理は、ポリシーに依存するものです（たとえば、そのようなパケットを削除することを決定する場合があります）。
Encrypted Payload (E), 1 bit: Setting the Encrypted Payload bit to 1 indicates that the WESP (and therefore ESP) payload is protected with encryption. If this bit is set to 0, then the payload is using integrity-only ESP. Setting or clearing this bit also impacts the value in the WESP Next Header field, as described above. The recipient MUST ensure consistency of this flag with the negotiated policy and MUST drop the incoming packet otherwise.
暗号化されたペイロード（E）、1ビット：暗号化されたペイロードビットを1に設定すると、WESP（したがってESP）ペイロードが暗号化で保護されていることを示します。このビットが0に設定されている場合、ペイロードはIntegrityのみのESPを使用しています。上記のように、このビットを設定またはクリアすることは、WESP次のヘッダーフィールドの値にも影響します。受信者は、交渉されたポリシーでこのフラグの一貫性を確保する必要があり、それ以外の場合は着信パケットをドロップする必要があります。
Padding header (P), 1 bit: If set (value 1), the 4-octet padding is present. If not set (value 0), the 4-octet padding is absent. This padding MUST be used with IPv6 in order to preserve IPv6 8-octet alignment. If WESP is being used with UDP encapsulation (see Section 2.1 below) and IPv6, the Protocol Identifier (0x00000002) occupies 4 octets so the IPv6 padding is not needed, as the header is already on an 8-octet boundary. This padding MUST NOT be used with IPv4, as it is not needed to guarantee 4-octet IPv4 alignment.
パディングヘッダー（P）、1ビット：セット（値1）の場合、4オクテットのパディングが存在します。設定されていない場合（値0）、4-OCTETパディングはありません。このパディングは、IPv6 8-OCTETアライメントを保持するために、IPv6で使用する必要があります。UDPカプセル化（下記のセクション2.1を参照）とIPv6でWESPが使用されている場合、プロトコル識別子（0x00000002）は4オクテットを占有しているため、ヘッダーはすでに8オクセットの境界にあるため、IPv6パディングは必要ありません。4-OCTET IPv4アライメントを保証する必要がないため、このパディングはIPv4で使用してはなりません。
Rsvd, 4 bits: Reserved for future use. The reserved bits MUST be sent as 0, and ignored by the receiver. Future documents defining any of these bits MUST NOT affect the distinction between encrypted and unencrypted packets or the semantics of HdrLen. In other words, even if new bits are defined, old implementations will be able to find the encapsulated packet correctly. Intermediate nodes dealing with unknown reserved bits are not necessarily able to parse the packet correctly. Intermediate treatment of such packets is policy dependent (e.g., it may dictate dropping such packets).
RSVD、4ビット：将来の使用のために予約されています。予約されたビットは0として送信され、受信機によって無視される必要があります。これらのビットのいずれかを定義する将来のドキュメントは、暗号化されたパケットと暗号化されていないパケットまたはHDRLENのセマンティクスの区別に影響してはなりません。言い換えれば、新しいビットが定義されていても、古い実装はカプセル化されたパケットを正しく見つけることができます。不明な予約ビットを扱う中間ノードは、必ずしもパケットを正しく解析できるわけではありません。このようなパケットの中間処理は、ポリシーに依存するものです（たとえば、そのようなパケットを削除することを決定する場合があります）。
Future versions of this protocol may change the version number and/or the reserved bits sent, possibly by negotiating them over the control channel.
このプロトコルの将来のバージョンは、おそらくコントロールチャネルを介してそれらを交渉することにより、バージョン番号および/または予約されたビットを変更する場合があります。
As can be seen, the WESP format extends the standard ESP header by the first 4 octets for IPv4 and optionally (see above) by 8 octets for IPv6.
ご覧のとおり、WESP形式は、標準ESPヘッダーをIPv4の最初の4オクテットで拡張し、Optional（上記参照）はIPv6の8オクテットを拡張します。
This section describes a mechanism for running the new packet format over the existing UDP encapsulation of ESP as defined in RFC 3948. This allows leveraging the existing IKE negotiation of the UDP port for Network Address Translation Traversal (NAT-T) discovery and usage [RFC3947] [RFC4306], as well as preserving the existing UDP ports for ESP (port 4500). With UDP encapsulation, the packet format can be depicted as follows.
このセクションでは、RFC 3948で定義されているESPの既存のUDPカプセル化を介して新しいパケット形式を実行するメカニズムについて説明します。これにより、ネットワークアドレス変換トラバーサル（NAT-T）発見と使用量のためのUDPポートの既存のIKEネゴシエーションをレバレッジ化できます[RFC3947] [RFC4306]、およびESP用の既存のUDPポートの保存（ポート4500）。UDPカプセル化を使用すると、パケット形式を次のように描くことができます。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Port (4500) | Dest Port (4500) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier (value = 0x00000002) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrLen | TrailerLen | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: UDP-Encapsulated WESP Header
図4：UDPがカプセル化されたWESPヘッダー
Where:
ただし：
Source/Destination port (4500) and checksum: describes the UDP encapsulation header, per RFC 3948.
ソース/宛先ポート（4500）およびチェックサム：RFC 3948ごとのUDPカプセル化ヘッダーについて説明します。
Protocol Identifier: new field to demultiplex between UDP encapsulation of IKE, UDP encapsulation of ESP per RFC 3948, and the UDP encapsulation in this specification.
プロトコル識別子：IKEのUDPカプセル化、RFC 3948あたりのESPのUDPカプセル化、およびこの仕様におけるUDPカプセル化の間のDemultiplexへの新しいフィールド。
According to RFC 3948, Section 2.2, a 4-octet value of zero (0) immediately following the UDP header indicates a Non-ESP marker, which can be used to assume that the data following that value is an IKE packet. Similarly, a value greater then 255 indicates that the packet is an ESP packet and the 4-octet value can be treated as the ESP Security Parameter Index (SPI). However, RFC 4303, Section 2.1 indicates that the values 1-255 are reserved and cannot be used as the SPI. We leverage that knowledge and use one of these reserved values to indicate that the UDP encapsulated ESP header contains this new packet format for ESP encapsulation.
RFC 3948、セクション2.2によると、UDPヘッダーの直後のゼロ（0）の4-OCTET値は非ESPマーカーを示します。これは、その値に続くデータがIKEパケットであると仮定するために使用できます。同様に、255よりも大きい値は、パケットがESPパケットであり、4オクテットの値をESPセキュリティパラメーターインデックス（SPI）として扱うことができることを示しています。ただし、RFC 4303、セクション2.1は、値1-255が予約されており、SPIとして使用できないことを示しています。その知識を活用し、これらの予約された値の1つを使用して、UDPカプセル化されたESPヘッダーにESPカプセル化のためにこの新しいパケット形式が含まれていることを示します。
The remaining fields in the packet have the same meaning as per Section 2 above.
パケット内の残りのフィールドは、上記のセクション2に従って同じ意味を持っています。
This extension is equally applicable to transport and tunnel mode where the ESP Next Header field is used to differentiate between these modes, as per the existing IPsec specifications.
この拡張機能は、ESP次のヘッダーフィールドを使用して、既存のIPSEC仕様に従ってこれらのモードを区別するために使用される輸送およびトンネルモードに等しく適用できます。
In transport mode, ESP is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. The following diagrams illustrate how WESP is applied to the ESP transport mode for a typical packet, on a "before and after" basis.
トランスポートモードでは、ESPはIPヘッダーの後、次のレイヤープロトコル（TCP、UDP、ICMPなど）の前に挿入されます。そして「基礎の後。
BEFORE APPLYING WESP -IPv4
-------------------------------------------------
|orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
|<---- encryption ---->|
|<------- integrity -------->|
AFTER APPLYING WESP - IPv4
--------------------------------------------------------
|orig IP hdr | WESP | ESP | | | ESP | ESP|
|(any options)| Hdr | Hdr | TCP | Data | Trailer | ICV|
--------------------------------------------------------
|<---- encryption ---->|
|<------- integrity -------->|
BEFORE APPLYING WESP - IPv6
--------------------------------------------------------------
| orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment |ESP|opt*|TCP|Data|Trailer| ICV|
--------------------------------------------------------------
|<---- encryption --->|
|<----- integrity ------->|
AFTER APPLYING WESP - IPv6
--------------------------------------------------------------
| orig |hop-by-hop,dest*,| | |dest| | | ESP | ESP|
|IP hdr|routing,fragment |WESP|ESP|opt*|TCP|Data|Trailer| ICV|
--------------------------------------------------------------
|<---- encryption --->|
|<----- integrity ------->|
* = if present, could be before WESP, after ESP, or both
* =存在する場合、wespの前、espの後、またはその両方
All other considerations are as per RFC 4303.
他のすべての考慮事項は、RFC 4303に従っています。
In tunnel mode, ESP is inserted after the new IP header and before the original IP header, as per RFC 4303. The following diagram illustrates how WESP is applied to the ESP tunnel mode for a typical packet, on a "before-and-after" basis.
トンネルモードでは、ESPは、RFC 4303に従って、新しいIPヘッダーの後、元のIPヘッダーの前に挿入されます。次の図は、典型的なパケットのESPトンネルモードにWESPがどのように適用されるかを示しています。" 基礎。
BEFORE APPLYING WESP - IPv4
---------------------------------------------------------
|new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)|ESP| (any options) |TCP|Data|Trailer| ICV|
---------------------------------------------------------
|<--------- encryption --------->|
|<----------- integrity ------------>|
AFTER APPLYING WESP - IPv4
--------------------------------------------------------------
|new IP hdr* | | | orig IP hdr* | | | ESP | ESP|
|(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV|
--------------------------------------------------------------
|<--------- encryption --------->|
|<----------- integrity ------------>|
BEFORE APPLYING WESP - IPv6
-----------------------------------------------------------------
|new IP|new ext | |orig IP|orig ext| | | ESP | ESP|
| hdr* | hdrs* |ESP| hdr* | hdrs * |TCP|Data|Trailer| ICV|
-----------------------------------------------------------------
|<--------- encryption ---------->|
|<------------- integrity ----------->|
AFTER APPLYING WESP - IPv6
-----------------------------------------------------------------
|new IP|new ext | | |orig IP|orig ext| | | ESP | ESP|
| hdr* | hdrs* |WESP|ESP| hdr* | hdrs * |TCP|Data|Trailer| ICV|
-----------------------------------------------------------------
|<--------- encryption ---------->|
|<------------- integrity ----------->|
* = if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed in the Security Architecture document.
* =存在する場合、外部IP HDR/拡張機能の構築と内部IP HDR/拡張機能の変更については、セキュリティアーキテクチャドキュメントで説明します。
All other considerations are as per RFC 4303.
他のすべての考慮事項は、RFC 4303に従っています。
This document assumes that WESP negotiation is performed using IKEv2. In order to negotiate the new format of ESP encapsulation via IKEv2 [RFC4306], both parties need to agree to use the new packet format. This can be achieved using a notification method similar to USE_TRANSPORT_MODE, defined in RFC 4306.
このドキュメントは、WESP交渉がIKEV2を使用して実行されることを前提としています。IKEV2 [RFC4306]を介してESPカプセル化の新しい形式を交渉するために、両当事者は新しいパケット形式の使用に同意する必要があります。これは、RFC 4306で定義されているuse_transport_modeと同様の通知方法を使用して達成できます。
The notification, USE_WESP_MODE (value 16415) MUST be included in a request message that also includes an SA payload requesting a CHILD_SA using ESP. It signals that the sender supports the WESP version defined in the current document and requests that the CHILD_SA use WESP mode rather than ESP for the SA created. If the request is accepted, the response MUST also include a notification of type USE_WESP_MODE. If the responder declines the request, the CHILD_SA will be established using ESP, as per RFC 4303. If this is unacceptable to the initiator, the initiator MUST delete the SA.
通知、use_wesp_mode（value 16415）は、espを使用してchild_saを要求するSAペイロードも含むリクエストメッセージに含める必要があります。これは、送信者が現在のドキュメントで定義されているWESPバージョンをサポートし、Child_Saが作成したSAのESPではなくWESPモードを使用することを要求することを示しています。リクエストが受け入れられた場合、応答には型use_wesp_modeの通知も含める必要があります。Responderがリクエストを拒否した場合、RFC 4303に従ってESPを使用してChild_SAが確立されます。これがイニシエーターに受け入れられない場合、イニシエーターはSAを削除する必要があります。
Note: Except when using this option to negotiate WESP mode, all CHILD_SAs will use standard ESP.
注：このオプションを使用してWESPモードをネゴシエートする場合を除き、すべてのChild_Sasは標準ESPを使用します。
Negotiation of WESP in this manner preserves all other negotiation parameters, including NAT-T [RFC3948]. NAT-T is wholly compatible with this wrapped format and can be used as-is, without any modifications, in environments where NAT is present and needs to be taken into account.
この方法でのWESPの交渉により、NAT-T [RFC3948]を含む他のすべての交渉パラメーターが保持されます。NAT-Tは、このラップ形式と完全に互換性があり、NATが存在し、考慮する必要がある環境で、変更なしで、そのまま使用できます。
WESP version negotiation is not introduced as part of this specification. If the WESP version is updated in a future specification, then that document MUST specify how the WESP version is negotiated.
WESPバージョンのネゴシエーションは、この仕様の一部として導入されていません。WESPバージョンが将来の仕様で更新されている場合、そのドキュメントはWESPバージョンのネゴシエーション方法を指定する必要があります。
As this document augments the existing ESP encapsulation format, UDP encapsulation definitions specified in RFC 3948 and IKE negotiation of the new encapsulation, the security observations made in those documents also apply here. In addition, as this document allows intermediate device visibility into IPsec ESP encapsulated frames for the purposes of network monitoring functions, care should be taken not to send sensitive data over connections using definitions from this document, based on network domain/administrative policy. A strong key agreement protocol, such as IKEv2, together with a strong policy engine should be used in determining appropriate security policy for the given traffic streams and data over which it is being employed.
このドキュメントが既存のESPカプセル化形式を補強するため、RFC 3948で指定されたUDPカプセル化定義と新しいカプセル化のIKE交渉では、これらのドキュメントで作成されたセキュリティ観測もここに適用されます。さらに、このドキュメントでは、ネットワーク監視関数の目的でIPSEC ESPカプセル化フレームへの中間デバイスの可視性が可能になるため、ネットワークドメイン/管理ポリシーに基づいて、このドキュメントからの定義を使用して接続に機密データを送信しないように注意する必要があります。IKEV2などの強力なキー契約プロトコルと強力なポリシーエンジンを使用すると、特定のトラフィックストリームと採用されているデータの適切なセキュリティポリシーを決定する際に使用する必要があります。
ESP is end-to-end and it will be impossible for the intermediate devices to verify that all the fields in the WESP header are correct. It is thus possible to modify the WESP header so that the packet sneaks past a firewall if the fields in the WESP header are set to something that the firewall will allow. The endpoint thus must verify the sanity of the WESP header before accepting the packet. In an extreme case, someone colluding with the attacker, could change the WESP fields back to the original values so that the attack goes unnoticed. However, this is not a new problem and it already exists IPsec.
ESPはエンドツーエンドであり、中間デバイスがWESPヘッダー内のすべてのフィールドが正しいことを確認することは不可能です。したがって、WESPヘッダーを変更して、WESPヘッダーのフィールドがファイアウォールが許可するものに設定されている場合、パケットがファイアウォールを通り過ぎるようになります。したがって、エンドポイントは、パケットを受け入れる前に、WESPヘッダーの正気を検証する必要があります。極端な場合、攻撃者と共謀している人は、WESPフィールドを元の値に戻し、攻撃が気付かれないようにする可能性があります。ただし、これは新しい問題ではなく、すでにIPSECが存在しています。
The WESP protocol number assigned by IANA out of the IP Protocol Number space is 141.
IANAによって割り当てられたIPプロトコル番号スペースから割り当てられたWESPプロトコル番号は141です。
The USE_WESP_MODE notification number assigned out of the "IKEv2 Notify Message Types - Status Types" registry's 16384-40959 (Expert Review) range is 16415.
「IKEV2通知メッセージタイプ - ステータスタイプ」から割り当てられたuse_wesp_mode通知番号」レジストリの16384-40959（エキスパートレビュー）範囲は16415です。
The SPI value of 2 has been assigned by IANA out of the reserved SPI range from the SPI values registry to indicate use of the WESP protocol within a UDP-encapsulated, NAT-T environment.
2のSPI値は、SPI値レジストリから予約されたSPI範囲からIANAによって割り当てられており、UDPがカプセル化されたNAT-T環境内でWESPプロトコルの使用を示すことを示しています。
IANA has created a new registry for "WESP Flags" to be managed as follows:
IANAは、次のように「WESPフラグ」を管理するための新しいレジストリを作成しました。
The first 2 bits are the WESP Version Number. The value 0 is assigned to the version defined in this specification. Further assignments of the WESP Version Number are to be managed via the IANA Policy of "Standards Action" [RFC5226]. For WESP version numbers, the unassigned values are 1, 2, and 3. The Encrypted Payload bit is used to indicate if the payload is encrypted or using integrity-only ESP. The Padding Present bit is used to signal the presence of padding. The remaining 4 bits of the WESP Flags are undefined and future assignment is to be managed via the IANA Policy of "IETF Review" [RFC5226].
最初の2ビットはWESPバージョン番号です。値0は、この仕様で定義されているバージョンに割り当てられます。WESPバージョン番号のさらなる割り当ては、「標準アクション」[RFC5226]のIANAポリシーを介して管理されます。WESPバージョン番号の場合、割り当てされていない値は1、2、および3です。暗号化されたペイロードビットは、ペイロードが暗号化されているか、IntegrityのみのESPを使用しているかを示すために使用されます。存在するパディングビットは、パディングの存在を知らせるために使用されます。WESPフラグの残りの4ビットは未定義であり、将来の割り当ては、「IETFレビュー」[RFC5226]のIANAポリシーを介して管理されます。
The authors would like to acknowledge the following people for their feedback on updating the definitions in this document:
著者は、このドキュメントの定義の更新に関するフィードバックについて、以下の人々を認めたいと思います。
David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron Sheffer, Pasi Eronen, Men Long, David Durham, Prashant Dewan, Marc Millier, Russ Housley, and Jari Arkko, among others.
デビッド・マクグリュー、ブライアン・ワイス、フィリップ・ジュバート、ブライアン・スワンダー、ヤロン・シェファー、パシ・エロネン、男性、デビッド・ダーラム、プラシャント・デュワン、マーク・ミリエ、ラス・ハウスリー、ジャリ・アークコなど。
Manav Bhatia would also like to acknowledge Swati and Maitri for their continued support.
Manav Bhatiaは、SwatiとMaitriの継続的なサポートについても認めたいと考えています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410] Glenn、R。およびS. Kent、「Null暗号化アルゴリズムとIPSECでの使用」、RFC 2410、1998年11月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、Volpe、V.、Diburro、L。、およびM. Stenberg、「IPSEC ESPパケットのUDPカプセル化」、RFC 3948、2005年1月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006.
[RFC4543] McGrew、D。およびJ. Viega、「IPSEC ESPおよびAHでのGaloisメッセージ認証コード（GMAC）の使用」、RFC 4543、2006年5月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A。、およびV. Volpe、「IKEにおけるNat-Traversalの交渉」、RFC 3947、2005年1月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、2005年12月。
[Heuristics] Kivinen, T. and D. McDonald, "Heuristics for Detecting ESP-NULL packets", Work in Progress, March 2010.
[ヒューリスティック] Kivinen、T。およびD. McDonald、「ESP-Nullパケットを検出するためのヒューリスティック」は、2010年3月に進行中です。
Authors' Addresses
著者のアドレス
Ken Grewal Intel Corporation 2111 NE 25th Avenue, JF3-232 Hillsboro, OR 97124 USA
Ken Growal Intel Corporation 2111 NE 25th Avenue、JF3-232 Hillsboro、または97124 USA
EMail: ken.grewal@intel.com
Gabriel Montenegro Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Gabriel Montenegro Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA
EMail: gabriel.montenegro@microsoft.com
Manav Bhatia Alcatel-Lucent Manyata Embassy Nagawara Bangalore India
Manav Bhatia Alcatel-Lucent Manyata Embassy Nagawara Bangalore India
EMail: manav.bhatia@alcatel-lucent.com