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
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.
本文档描述了包装式封装安全有效载荷（WESP）协议，该协议建立在封装安全有效载荷（ESP）RFC 4303的基础上，旨在允许中间设备（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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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-NULL加密算法[RFC2410]或AES-GMAC[RFC4543]等组合模式算法，可以实现无数据保密性的数据完整性（“仅完整性ESP”）。所采用的精确封装和算法在带外协商，例如使用互联网密钥交换协议版本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
在企业环境中使用IPsec时，最好使用ESP而不是身份验证头（AH）[RFC4302]，因为AH在NAT环境中不起作用。此外，为了保持上述网络监控功能，希望仅使用完整性，尤其是在混合模式环境中，一些包含敏感数据的数据包采用给定的加密密码套件，而其他数据包仅采用完整性，特别是对于中间设备，要明确区分哪些数据包使用完整性，只有ESP需要了解每个受保护会话所采用的所有策略。这显然是不切实际的。可以使用基于启发式的方法来解析数据包，但这些方法可能非常昂贵，需要基于每个不同协议和负载的大量规则。即使如此，在给定加密数据包中的字段恰好与给定协议或启发式规则的字段相似的情况下，解析也可能不可靠。在包可能被加密的情况下，当可以使用简单的异常策略（例如，允许、丢弃或重定向）来处理加密包时，根据基于启发式的规则进行检查也是浪费的。由于用于在加密数据和非加密数据之间消除歧义的基于启发式的规则的不确定性，需要定义一种使中间设备能够在加密数据环境中工作的替代方法。此外，在给定的网络中有许多类型和类别的网络设备，确定性方法为所有这些设备提供了一个简单的解决方案。企业环境
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.
通常使用有状态和无状态数据包检查机制。前面的考虑对无状态机制尤其重要，如路由器访问控制列表（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].
本文件与ESP在NAT环境中的操作一致[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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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流量：
- 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，但我们预计这两种方法将共存多年，因为需要启发式方法来检查至少一个端点未被修改的流量。换句话说，期望中间节点支持这两种方法，以便在过渡期间实现良好的安全性和性能。
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）或下一个头（IPv6、扩展）字段中包含值（141）。WESP在每个数据包中提供附加属性，以帮助区分加密数据和非加密数据，并帮助解析数据包。WESP遵循RFC 4303的所有IPv6和IPv4注意事项（例如，对齐注意事项）。
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 |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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时，接收器必须确保WESP标头中的下一个标头字段与ESP拖车中的下一个标头字段匹配。如果两者不匹配，则必须丢弃数据包。同样，如果使用带加密的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报头开始到封装ESP报头内剩余有效负载数据（即，超过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.
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位：位首先定义为最高有效位（MSB），因此位0是标志八位字节的最高有效位。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V V|E|P| Rsvd |
+-+-+-+-+-+-+-+-+
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，则有效负载仅使用完整性，特别是设置或清除此位也会影响WESP Next Header字段中的值，如上所述。收件人必须确保此标志与协商策略的一致性，否则必须丢弃传入数据包。
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一起使用，以保持IPv6 8-octet对齐。如果WESP与UDP封装（见下文第2.1节）和IPv6一起使用，则协议标识符（0x00000002）占用4个八位字节，因此不需要IPv6填充，因为标头已经位于8个八位字节的边界上。此填充不能与IPv4一起使用，因为不需要它来保证4-octet 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.
可以看出，对于IPv4，WESP格式将标准ESP报头扩展了前4个八位字节，对于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封装上运行新数据包格式的机制。这允许利用UDP端口的现有IKE协商进行网络地址转换遍历（NAT-T）发现和使用[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 |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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节的规定，UDP报头后面紧接着的4个八位组值为零（0）表示非ESP标记，可用于假设该值后面的数据是IKE数据包。类似地，大于255的值表示该数据包是ESP数据包，4个八位组的值可以被视为ESP安全参数索引（SPI）。但是，RFC 4303第2.1节指出值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.
根据现有IPsec规范，此扩展同样适用于传输和隧道模式，其中ESP Next Header字段用于区分这些模式。
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等。下图说明了如何在“之前和之后”的基础上将WESP应用于典型数据包的ESP传输模式。
BEFORE APPLYING WESP -IPv4
-------------------------------------------------
|orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
|<---- encryption ---->|
|<------- integrity -------->|
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 -------->|
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 ------->|
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 ------->|
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.
在隧道模式下，根据RFC 4303，ESP插入在新IP报头之后和原始IP报头之前。下图说明了如何在“之前和之后”的基础上将WESP应用于典型数据包的ESP隧道模式。
BEFORE APPLYING WESP - IPv4
---------------------------------------------------------
|new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)|ESP| (any options) |TCP|Data|Trailer| ICV|
---------------------------------------------------------
|<--------- encryption --------->|
|<----------- integrity ------------>|
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 ------------>|
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 ----------->|
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 ----------->|
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中定义的使用传输模式的通知方法来实现。
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）必须包含在请求消息中，该请求消息还包括SA有效负载，该负载使用ESP请求子_-SA。它表示发送方支持当前文档中定义的WESP版本，并请求子_-SA使用WESP模式而不是ESP来创建SA。如果请求被接受，响应还必须包括类型为USE_WESP_MODE的通知。如果响应者拒绝请求，将根据RFC 4303使用ESP建立子_SA。如果发起者不能接受，发起者必须删除SA。
Note: Except when using this option to negotiate WESP mode, all CHILD_SAs will use standard ESP.
注意：除使用此选项协商WESP模式外，所有子SA将使用标准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且需要考虑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
ESP是端到端的，中间设备无法验证WESP标头中的所有字段是否正确。因此，如果WESP报头中的字段设置为防火墙允许的值，则可以修改WESP报头，使数据包偷偷通过防火墙。因此，端点必须在接受数据包之前验证WESP报头的健全性。在极端情况下，与攻击者勾结的人可能会改变
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.
WESP字段返回到原始值，以便攻击不会被注意到。然而，这不是一个新问题，它已经存在。
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通知消息类型-状态类型”注册表的16384-40959（专家评审）范围中分配的使用WESP模式通知编号为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.
IANA已从SPI值注册表将SPI值2分配到保留SPI范围之外，以指示在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版本号的进一步分配将通过IANA“标准行动”政策[RFC5226]进行管理。对于WESP版本号，未分配的值为1、2和3。加密的有效负载位用于指示有效负载是加密的还是仅使用完整性，尤其是当前填充位用于表示存在填充。WESP标志的其余4位未定义，未来的分配将通过IANA“IETF审查”政策[RFC5226]进行管理。
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.
David McGrew、Brian Weis、Philippe Joubert、Brian Swander、Yaron Sheffer、Pasi Eronen、Men Long、David Durham、Prashant Dewan、Marc Millier、Russ Housley和Jari Arkko等。
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，“空加密算法及其在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.，“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]McGrew，D.和J.Viega，“Galois消息认证码（GMAC）在IPsec ESP和AH中的使用”，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穿越的协商”，RFC 3947，2005年1月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，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 Grewal Intel Corporation美国希尔斯堡东北25大道2111号JF3-232，邮编：97124
EMail: ken.grewal@intel.com
EMail: ken.grewal@intel.com
Gabriel Montenegro Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
加布里埃尔黑山微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: gabriel.montenegro@microsoft.com
EMail: gabriel.montenegro@microsoft.com
Manav Bhatia Alcatel-Lucent Manyata Embassy Nagawara Bangalore India
Manav Bhatia Alcatel Lucent Manyata大使馆印度纳加瓦拉班加罗尔
EMail: manav.bhatia@alcatel-lucent.com
EMail: manav.bhatia@alcatel-lucent.com