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に基づいて構築し、データの機密性は、ESP内で使用されている場合（1）を確認するために、中間デバイスを可能にするように設計され、そうでない場合に包まカプセル化セキュリティペイロード（WESP）プロトコルを記述する（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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
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のESP内での使用は[RFC4303]はESPパケットのカプセル化が実行される方法を指定します。また、ESPは、データの機密性と整合性サービスを提供できることを指定します。データの機密性（「整合性のみ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.
関連などのエンタープライズ環境では、通常侵入検知防御システム（IDSとIPS）、ウイルスのスキャンおよび検出、コンテンツスクリーニング、ファイアウォール、ネットワーク監視機能、ディープパケットインスペクション、コントロールにアクセスするには、（それらを施行するとツール）多数のセキュリティポリシーを採用しますこれらのポリシー、ネットワークツールと中間デバイスは、単純なパケットヘッダの検査からより深いペイロード検査に至るまで、パケットに可視性を必要とするを強制するためにワーム、等。輸送中のデータを暗号化し、ネットワークのセキュリティプロトコルは、前述の機能を実行するから、これらのネットワークツールを防ぎます。
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を使用することが望ましいです。また、上記ネットワーク監視機能を維持するためには、完全性のみESPを使用することが望ましいです。他のパケットが整合性のみ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環境[RFC3947]でESPの動作と一致しています。
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トラフィックを区別するために、中間セキュリティデバイスを有効にするには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.
ヒューリスティックアプローチは情報RFCとして公開されることが予想されている間、両方のアプローチは、IPセキュリティメンテナンスや拡張機能標準化過程RFCとしてWESP（本書）と（IPsecME）ワーキンググループによって同時に文書化されています。エンドポイントがWESPを採用するように変更されている間、私たちは、発見的アプローチは、エンドポイントの少なくとも一方が変更されていないトラフィックを検査するために必要とされるので、両方のアプローチは何年も共存することを期待しています。換言すれば、中間ノードは、遷移期間中に良好なセキュリティとパフォーマンスを達成するために、両方のアプローチをサポートすることが期待されます。
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）カプセル化は、そのプロトコル（IPv4）のまたは次のヘッダ（に、従って直ちにWESPヘッダ値を含まなければならない前に（外側）プロトコルヘッダ（IPv4の、IPv6の、または拡張）（141）プロトコル番号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：WASPのパケットフォーマット
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ビット：インテグリティ専用モードでESPを使用する場合、このフィールドは、ESPトレーラ内の次のヘッダフィールドと同じでなければなりません。暗号化とESPを使用する場合は、「次ヘッダ」フィールドは、この名前と意味を失い、すべてゼロに初期化しなければならなく空のフィールドになります。 WESPパケットが受け入れられる前に、受信機は、いくつかの健全性チェックを行う必要があります。整合専用モードでESPを使用する場合、受信機は、ESPトレーラマッチ中WESPヘッダと次ヘッダフィールドに次ヘッダフィールドことを確認しなければなりません。両者が一致しない場合、パケットは廃棄されなければなりません。同様に、受信機は、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ヘッダ内の、。 ESPを使用するときHdrLenは、暗号化して、ゼロに設定しなければなりません。 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.
TrailerLen、8ビット：TrailerLenはオクテットで、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ビット：ビットので、ビット0がフラグオクテットの最上位ビットであり、最初の最上位ビット（MSB）で定義されています。
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に設定されている場合、ペイロードは整合性のみ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オクテットのパディングは存在しません。このパディングは、IPv6 8オクテット整列を維持するためにIPv6で使用しなければなりません。 WESPは、UDPカプセル化を使用している場合とIPv6、プロトコル識別子IPv6のパディングが必要とされないので、ヘッダは8オクテット境界上に既にあるように（0x00000002）は、4つのオクテットを占有する（以下のセクション2.1を参照）。 4オクテットの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フォーマットは、IPv4の最初の4つのオクテットによって標準ESPヘッダを拡張し、必要に応じて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これは、ネットワークのためのUDPポートの既存のIKEネゴシエーションを活用することができます3948アドレス変換トラバーサル（NAT-T）の発見と利用[RFC3947で定義されているこのセクションでは、ESPの既存のUDPカプセル化の上に、新たなパケットフォーマットを実行するためのメカニズムについて説明します] [RFC4306]、並びにESP（ポート4500）のための既存のUDPポートを保存します。次のように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カプセル化。
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によれば、（0）直ちにUDPヘッダに続くゼロの4オクテットの値は、その値以下のデータは、IKEパケットであると仮定するために使用することができる非ESPマーカーを、示しています。同様に、255より大きい値は、パケットがESPパケット及び4オクテットの値がESPセキュリティパラメータインデックス（SPI）として扱うことができるされていることを示します。しかし、RFC 4303は、セクション2.1の値〜255が予約されており、SPIとして使用することができないことを示しています。私たちは、その知識を活用し、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は、以下の図は、WESPが「前に、典型的なパケットのための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.
以下の図は、「前と後に、WESPは、典型的なパケットに対してESPトンネルモードに適用される様子を示すRFC 4303に従って、トンネルモードでは、ESPは、新しいIPヘッダの後、元のIPヘッダの前に挿入され" 基礎。
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.
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（値16415）もESP CHILD_SA使用を要求するSAペイロードを含む要求メッセージに含まれなければなりません。これは、送信者が現在のドキュメントで定義されたWESPのバージョンをサポートしていることを知らせるとSAのためというよりもESP CHILD_SA使用WESPモードが作成されていることを要求します。要求が受け入れられた場合、応答はまた、型USE_WESP_MODEの通知を含まなければなりません。応答者は、要求を拒否した場合、これはイニシエータに受け入れられない場合は、CHILD_SAは、RFC 4303に従って、ESPを使用して確立され、イニシエータは、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カプセル化形式、UDP RFC 3948で指定されたカプセル化の定義と新しいカプセル化の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.
IPプロトコル番号スペースのうち、IANAによって割り当てられ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値は、UDPカプセル化、NAT-T環境内WESPプロトコルの使用を示すために、SPI値レジストリから予約SPI範囲外IANAによって割り当てられています。
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である暗号化されたペイロードビットは、ペイロードが暗号化または完全性のみ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.
中でもデビッドマグリュー、ブライアン・ワイス、フィリップ・ジュベール、ブライアンSwander、ヤロンシェファー、パシEronen、メンズロング、デイヴィッド・ダーラム、のPrashantデュワン、マルク・Millier、ラスHousley、およびヤリArkko、。
Manav Bhatia would also like to acknowledge Swati and Maitri for their continued support.
Manavバティアはまた、継続的な支援のためのスワティとMaitriを確認したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]グレン、R.とS.ケント、 "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.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "IPsecのESPパケットのUDPカプセル化"、RFC 3948、2005年1月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（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]マグリュー、D.とJ. Viega、 "IPsecのESPとAHでガロアメッセージ認証コード（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.ボルペ、 "IKEにおけるNATトラバーサルのネゴシエーション"、RFC 3947、2005年1月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[Heuristics] Kivinen, T. and D. McDonald, "Heuristics for Detecting ESP-NULL packets", Work in Progress, March 2010.
[ヒューリスティック] Kivinen、T.およびD.マクドナルド、 "ESP-NULLパケットを検出するためのヒューリスティクス"、進歩、2010年3月での作業。
Authors' Addresses
著者のアドレス
Ken Grewal Intel Corporation 2111 NE 25th Avenue, JF3-232 Hillsboro, OR 97124 USA
ケン・Grewalインテルコーポレーション2111 NE 25日アベニュー、JF3-232ヒルズボロ、OR 97124 USA
EMail: ken.grewal@intel.com
メールアドレス：ken.grewal@intel.com
Gabriel Montenegro Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
がｂりえｌ もんてねｇろ みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ うさ
EMail: gabriel.montenegro@microsoft.com
メールアドレス：gabriel.montenegro@microsoft.com
Manav Bhatia Alcatel-Lucent Manyata Embassy Nagawara Bangalore India
ヒトBtia Alktel・ルーセントは大使館Nagwaraバンガロール、インドを認識しました
EMail: manav.bhatia@alcatel-lucent.com
メールアドレス：manav.bhatia@alcatel-lucent.com