Internet Engineering Task Force (IETF) K. Pentikousis, Ed.
Request for Comments: 7717 EICT
Updates: 4656, 5357 E. Zhang
Category: Standards Track Y. Cui
ISSN: 2070-1721 Huawei Technologies
December 2015
Internet Engineering Task Force (IETF) K. Pentikousis, Ed.
Request for Comments: 7717 EICT
Updates: 4656, 5357 E. Zhang
Category: Standards Track Y. Cui
ISSN: 2070-1721 Huawei Technologies
December 2015
IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
IKEv2为单向主动测量协议（OWAMP）和双向主动测量协议（TWAMP）派生的共享密钥
Abstract
摘要
The One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) security mechanisms require that both the client and server endpoints possess a shared secret. This document describes the use of keys derived from an IKEv2 security association (SA) as the shared key in OWAMP or TWAMP. If the shared key can be derived from the IKEv2 SA, OWAMP or TWAMP can support certificate-based key exchange; this would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management.
单向主动测量协议（OWAMP）和双向主动测量协议（TWAMP）安全机制要求客户端和服务器端点都拥有一个共享秘密。本文档描述了如何使用从IKEv2安全关联（SA）派生的密钥作为OWAMP或TWAMP中的共享密钥。如果共享密钥可以从IKEv2 SA派生，则OWAMP或TWAMP可以支持基于证书的密钥交换；这将允许更大的操作灵活性和效率。本文中介绍的密钥派生还可以促进自动密钥管理。
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/rfc7717.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7717.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. O/TWAMP Security . . . . . . . . . . . . . . . . . . . . . . 5
4.1. O/TWAMP-Control Security . . . . . . . . . . . . . . . . 5
4.2. O/TWAMP-Test Security . . . . . . . . . . . . . . . . . . 6
4.3. O/TWAMP Security Root . . . . . . . . . . . . . . . . . . 7
5. O/TWAMP for IPsec Networks . . . . . . . . . . . . . . . . . 7
5.1. Shared Key Derivation . . . . . . . . . . . . . . . . . . 7
5.2. Server Greeting Message Update . . . . . . . . . . . . . 8
5.3. Set-Up-Response Update . . . . . . . . . . . . . . . . . 9
5.4. O/TWAMP over an IPsec Tunnel . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. O/TWAMP Security . . . . . . . . . . . . . . . . . . . . . . 5
4.1. O/TWAMP-Control Security . . . . . . . . . . . . . . . . 5
4.2. O/TWAMP-Test Security . . . . . . . . . . . . . . . . . . 6
4.3. O/TWAMP Security Root . . . . . . . . . . . . . . . . . . 7
5. O/TWAMP for IPsec Networks . . . . . . . . . . . . . . . . . 7
5.1. Shared Key Derivation . . . . . . . . . . . . . . . . . . 7
5.2. Server Greeting Message Update . . . . . . . . . . . . . 8
5.3. Set-Up-Response Update . . . . . . . . . . . . . . . . . 9
5.4. O/TWAMP over an IPsec Tunnel . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
The One-Way Active Measurement Protocol (OWAMP) [RFC4656] and the Two-Way Active Measurement Protocol (TWAMP) [RFC5357] can be used to measure network performance parameters such as latency, bandwidth, and packet loss by sending probe packets and monitoring their experience in the network. In order to guarantee the accuracy of network measurement results, security aspects must be considered. Otherwise, attacks may occur and the authenticity of the measurement results may be violated. For example, if no protection is provided, an adversary in the middle may modify packet timestamps, thus altering the measurement results.
单向主动测量协议（OWAMP）[RFC4656]和双向主动测量协议（TWAMP）[RFC5357]可用于通过发送探测数据包并监测其在网络中的体验来测量网络性能参数，如延迟、带宽和数据包丢失。为了保证网络测量结果的准确性，必须考虑安全方面。否则，可能会发生攻击，并可能侵犯测量结果的真实性。例如，如果没有提供保护，中间的对手可以修改分组时间戳，从而改变测量结果。
According to [RFC4656] and [RFC5357], the OWAMP and TWAMP (O/TWAMP) security mechanisms require that endpoints (i.e., both the client and the server) possess a shared secret. In today's network deployments, however, the use of pre-shared keys is far from optimal. For example, in wireless infrastructure networks, certain network elements (which can be seen as the two endpoints from an O/TWAMP perspective) support certificate-based security. For instance, consider the case in which one wants to measure IP performance between an E-UTRAN Evolved Node B (eNB) and Security Gateway (SeGW), both of which are 3GPP Long Term Evolution (LTE) nodes and support certificate mode and the Internet Key Exchange Protocol version 2 (IKEv2).
根据[RFC4656]和[RFC5357]，OWAMP和TWAMP（O/TWAMP）安全机制要求端点（即客户端和服务器）拥有共享秘密。然而，在当今的网络部署中，使用预共享密钥远远不是最佳选择。例如，在无线基础设施网络中，某些网络元素（从O/TWAMP的角度来看，可以看作是两个端点）支持基于证书的安全性。例如，考虑希望在E-UTRAN演进节点B（eNB）和安全网关（SEGW）之间测量IP性能的情况，其中两个都是3GPP长期演进（LTE）节点和支持证书模式以及因特网密钥交换协议版本2（IKEv2）。
The O/TWAMP security mechanism specified in [RFC4656] and [RFC5357] supports the pre-shared key (PSK) mode only, hindering large-scale deployment of O/TWAMP: provisioning and management of "shared secrets" for massive deployments consumes a tremendous amount of effort and is prone to human error. At the same time, recent trends point to wider IKEv2 deployment that, in turn, calls for mechanisms and methods that enable tunnel end-users, as well as operators, to measure one-way and two-way network performance in a standardized manner.
[RFC4656]和[RFC5357]中指定的O/TWAMP安全机制仅支持预共享密钥（PSK）模式，这阻碍了O/TWAMP的大规模部署：为大规模部署提供和管理“共享机密”需要耗费大量精力，并且容易出现人为错误。与此同时，最近的趋势表明IKEv2的部署范围更广，这反过来又要求采用机制和方法，使隧道最终用户以及运营商能够以标准化的方式测量单向和双向网络性能。
With IKEv2 widely deployed, employing shared keys derived from an IKEv2 security association (SA) can be considered a viable alternative through the method described in this document. If the shared key can be derived from the IKEv2 SA, O/TWAMP can support certificate-based key exchange and practically increase operational flexibility and efficiency. The use of IKEv2 also makes it easier to extend automatic key management.
随着IKEv2的广泛部署，使用源自IKEv2安全关联（SA）的共享密钥可以被认为是通过本文档中描述的方法实现的可行替代方案。如果共享密钥可以从IKEv2 SA派生，那么O/TWAMP可以支持基于证书的密钥交换，并实际提高操作灵活性和效率。IKEv2的使用也使得扩展自动密钥管理变得更容易。
In general, O/TWAMP measurement packets can be transmitted inside the IPsec tunnel, as typical user traffic is, or transmitted outside the IPsec tunnel. This may depend on the operator's policy and the performance evaluation goal, and it is orthogonal to the mechanism
通常，O/TWAMP测量数据包可以在IPsec隧道内传输，就像典型的用户通信一样，也可以在IPsec隧道外传输。这可能取决于运营商的策略和绩效评估目标，并且与机制正交
described in this document. When IPsec is deployed, protecting O/TWAMP traffic in unauthenticated mode using IPsec is one option. Another option is to protect O/TWAMP traffic using the O/TWAMP security established using the PSK derived from IKEv2 and bypassing the IPsec tunnel.
如本文件所述。部署IPsec时，使用IPsec在未经身份验证的模式下保护O/TWAMP流量是一种选择。另一个选项是使用使用从IKEv2派生的PSK建立的O/TWAMP安全性并绕过IPsec隧道来保护O/TWAMP流量。
Protecting unauthenticated O/TWAMP control and/or test traffic via the Authentication Header (AH) [RFC4302] or Encapsulating Security Payload (ESP) [RFC4303] cannot provide various security options, e.g., it cannot authenticate part of an O/TWAMP packet as mentioned in [RFC4656]. For measuring latency, a timestamp is carried in O/ TWAMP test traffic. The sender has to fetch the timestamp, encrypt it, and send it. When the mechanism described in this document is used, partial authentication of O/TWAMP packets is possible and therefore the middle step can be skipped, potentially improving accuracy as the sequence number can be encrypted and authenticated before the timestamp is fetched. The receiver obtains the timestamp without the need for the corresponding decryption step. In such cases, protecting O/TWAMP traffic using O/TWAMP security but bypassing the IPsec tunnel has its advantages.
通过身份验证标头（AH）[RFC4302]或封装安全有效负载（ESP）[RFC4303]保护未经身份验证的O/TWAMP控制和/或测试流量无法提供各种安全选项，例如，它无法验证[RFC4656]中提到的O/TWAMP包的一部分。为了测量延迟，在O/TWAMP测试流量中携带时间戳。发送方必须获取时间戳，加密它，然后发送它。当使用本文档中描述的机制时，可以对O/TWAMP数据包进行部分身份验证，因此可以跳过中间步骤，从而潜在地提高准确性，因为可以在获取时间戳之前对序列号进行加密和身份验证。接收器获得时间戳而不需要相应的解密步骤。在这种情况下，使用O/TWAMP安全性保护O/TWAMP流量但绕过IPsec隧道有其优点。
This document specifies a method for enabling network measurements between a TWAMP client and a TWAMP server. In short, the shared key used for securing TWAMP traffic is derived from IKEv2 [RFC7296]. TWAMP implementations signal the use of this method by setting IKEv2Derived (see Section 7). IKEv2-derived keys SHOULD be used instead of shared secrets when O/TWAMP is employed in a deployment using IKEv2. From an operations and management perspective [RFC5706], the mechanism described in this document requires that both the TWAMP Control-Client and Server support IPsec.
本文档指定了在TWAMP客户端和TWAMP服务器之间启用网络测量的方法。简而言之，用于保护TWAMP流量的共享密钥来自IKEv2[RFC7296]。TWAMP实现通过设置IKEv2Derived来表示此方法的使用（参见第7节）。在使用IKEv2的部署中使用O/TWAMP时，应使用IKEv2派生密钥，而不是共享密钥。从操作和管理的角度来看[RFC5706]，本文档中描述的机制要求TWAMP控制客户端和服务器都支持IPsec。
The remainder of this document is organized as follows. Section 4 summarizes O/TWAMP protocol operation with respect to security. Section 5 presents the method for binding TWAMP and IKEv2 for network measurements between the client and the server that both support IKEv2. Finally, Section 6 discusses the security considerations arising from the proposed mechanisms.
本文件的其余部分组织如下。第4节总结了O/TWAMP协议在安全方面的操作。第5节介绍了绑定TWAMP和IKEv2的方法，用于在同时支持IKEv2的客户端和服务器之间进行网络测量。最后，第6节讨论了由提议的机制引起的安全考虑。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document specifies a method using keys derived from an IKEv2 SA as the shared key in O/TWAMP. O/TWAMP implementations signal the use of this method by setting IKEv2Derived (see Section 7).
本文档指定了一种使用从IKEv2 SA派生的密钥作为O/TWAMP中的共享密钥的方法。O/TWAMP实现通过设置IKEv2Derived来表示此方法的使用（参见第7节）。
Security for O/TWAMP-Control and O/TWAMP-Test are briefly reviewed in the following subsections.
以下小节简要回顾了O/TWAMP控制和O/TWAMP测试的安全性。
O/TWAMP uses a simple cryptographic protocol that relies on
O/TWAMP使用一个简单的加密协议，该协议依赖于
o AES-CBC for confidentiality
o AES-CBC保密协议
o HMAC-SHA1 truncated to 128 bits for message authentication
o HMAC-SHA1被截断为128位，用于消息身份验证
Three modes of operation are supported in the OWAMP-Control protocol: unauthenticated, authenticated, and encrypted. In addition to these modes, the TWAMP-Control protocol also supports a mixed mode, i.e., the TWAMP-Control protocol operates in encrypted mode while TWAMP-Test protocol operates in unauthenticated mode. The authenticated, encrypted, and mixed modes require that endpoints possess a shared secret, typically a passphrase. The secret key is derived from the passphrase using a password-based key derivation function PBKDF2 (PKCS #5) [RFC2898].
OWAMP控制协议支持三种操作模式：未经验证、已验证和加密。除这些模式外，TWAMP控制协议还支持混合模式，即，TWAMP控制协议在加密模式下运行，而TWAMP测试协议在未经验证的模式下运行。身份验证、加密和混合模式要求端点拥有共享密钥，通常是密码短语。使用基于密码的密钥派生函数PBKDF2（PKCS#5）[RFC2898]从密码短语派生出密钥。
In the unauthenticated mode, the security parameters are left unused. In the authenticated, encrypted, and mixed modes, the security parameters are negotiated during the control connection establishment.
在未经验证的模式下，安全参数未使用。在认证、加密和混合模式中，安全参数在控制连接建立期间协商。
Figure 1 illustrates the initiation stage of the O/TWAMP-Control protocol between a Control-Client and a Server. In short, the Control-Client opens a TCP connection to the Server in order to be able to send O/TWAMP-Control commands. The Server responds with a Server Greeting, which contains the Modes, Challenge, Salt, Count, and MBZ ("MUST be zero") fields (see Section 3.1 of [RFC4656]). If the Control-Client preferred mode is available, the client responds with a Set-Up-Response message, wherein the selected Mode, as well as the KeyID, Token, and Client initialization vector (IV) are included. The Token is the concatenation of a 16-octet Challenge, a 16-octet AES Session-key used for encryption, and a 32-octet HMAC-SHA1 Session-key used for authentication. The Token is encrypted using AES-CBC.
图1说明了控制客户端和服务器之间的O/TWAMP控制协议的启动阶段。简而言之，控制客户端打开到服务器的TCP连接，以便能够发送O/TWAMP控制命令。服务器响应服务器问候语，其中包含模式、质询、Salt、计数和MBZ（“必须为零”）字段（见[RFC4656]第3.1节）。如果控制客户端首选模式可用，则客户端用设置响应消息进行响应，其中包括所选模式以及KeyID、令牌和客户端初始化向量（IV）。令牌是16个八位字节的质询、用于加密的16个八位字节的AES会话密钥和用于身份验证的32个八位字节的HMAC-SHA1会话密钥的串联。令牌使用AES-CBC加密。
+----------------+ +--------+
| Control-Client | | Server |
+----------------+ +--------+
| |
|<------ TCP Connection-- ----->|
| |
|<------ Greeting message ------|
| |
|------- Set-Up-Response ------>|
| |
|<------ Server-Start ----------|
| |
+----------------+ +--------+
| Control-Client | | Server |
+----------------+ +--------+
| |
|<------ TCP Connection-- ----->|
| |
|<------ Greeting message ------|
| |
|------- Set-Up-Response ------>|
| |
|<------ Server-Start ----------|
| |
Figure 1: Initiation of O/TWAMP-Control
图1：启动O/TWAMP控制
Encryption uses a key derived from the shared secret associated with KeyID. In the authenticated, encrypted, and mixed modes, all further communication is encrypted using the AES Session-key and authenticated with the HMAC Session-key. After receiving the Set-Up-Response, the Server responds with a Server-Start message containing the Server-IV. The Control-Client encrypts everything it transmits through the just established O/TWAMP-Control connection using stream encryption with Client-IV as the IV. Correspondingly, the Server encrypts its side of the connection using Server-IV as the IV. The IVs themselves are transmitted in cleartext. Encryption starts with the block immediately following that containing the IV.
加密使用从与KeyID关联的共享密钥派生的密钥。在认证、加密和混合模式下，所有进一步的通信都使用AES会话密钥进行加密，并使用HMAC会话密钥进行认证。在接收到设置响应后，服务器用包含Server-IV的服务器启动消息进行响应。控制客户端使用流加密（客户端IV作为IV）对其通过刚刚建立的O/TWAMP控制连接传输的所有内容进行加密，服务器使用服务器IV作为IV加密其连接端。IV本身以明文传输。加密从紧跟在包含IV的块之后的块开始。
The AES Session-key and HMAC Session-key are generated randomly by the Control-Client. The HMAC Session-key is communicated along with the AES Session-key during O/TWAMP-Control connection setup. The HMAC Session-key is derived independently of the AES Session-key.
AES会话密钥和HMAC会话密钥由控制客户端随机生成。在O/TWAMP控制连接设置期间，HMAC会话密钥与AES会话密钥进行通信。HMAC会话密钥独立于AES会话密钥派生。
The O/TWAMP-Test protocol runs over UDP, using the Session-Sender and Session-Reflector IP and port numbers that were negotiated during the Request-Session exchange. O/TWAMP-Test has the same mode with O/ TWAMP-Control and all O/TWAMP-Test sessions inherit the corresponding O/TWAMP-Control session mode except when operating in mixed mode.
O/TWAMP测试协议通过UDP运行，使用请求会话交换期间协商的会话发送方和会话反射方IP和端口号。O/TWAMP测试与O/TWAMP控制具有相同的模式，所有O/TWAMP测试会话继承相应的O/TWAMP控制会话模式，但在混合模式下操作时除外。
The O/TWAMP-Test packet format is the same in authenticated and encrypted modes. The encryption and authentication operations are, however, different. Similarly, with the respective O/TWAMP-Control session, each O/TWAMP-Test session has two keys: an AES Session-key and an HMAC Session-key. However, there is a difference in how the keys are obtained:
在认证和加密模式下，O/TWAMP测试数据包格式相同。然而，加密和身份验证操作是不同的。类似地，对于相应的O/TWAMP控制会话，每个O/TWAMP测试会话都有两个密钥：AES会话密钥和HMAC会话密钥。但是，在获取密钥的方式上存在差异：
O/TWAMP-Control: the keys are generated by the Control-Client and communicated to the Server during the control connection establishment with the Set-Up-Response message (as part of the Token).
O/TWAMP控制：密钥由控制客户端生成，并在控制连接建立期间通过设置响应消息（作为令牌的一部分）传递给服务器。
O/TWAMP-Test: the keys are derived from the O/TWAMP-Control keys and the session identifier (SID), which serve as inputs to the key derivation function (KDF). The O/TWAMP-Test AES Session-key is generated using the O/TWAMP-Control AES Session-key, with the 16-octet SID, for encrypting and decrypting the packets of the particular O/TWAMP-Test session. The O/TWAMP-Test HMAC Session-key is generated using the O/TWAMP-Control HMAC Session-key, with the 16-octet SID, for authenticating the packets of the particular O/TWAMP-Test session.
O/TWAMP测试：这些密钥是从O/TWAMP控制密钥和会话标识符（SID）派生的，它们作为密钥派生函数（KDF）的输入。O/TWAMP测试AES会话密钥是使用O/TWAMP控制AES会话密钥生成的，具有16个八位组SID，用于加密和解密特定O/TWAMP测试会话的数据包。O/TWAMP测试HMAC会话密钥是使用O/TWAMP控制HMAC会话密钥生成的，具有16个八位组SID，用于验证特定O/TWAMP测试会话的数据包。
As discussed above, the O/TWAMP-Test AES Session-key and HMAC Session-key are derived, respectively, from the O/TWAMP-Control AES Session-key and HMAC Session-key. The AES Session-key and HMAC Session-key used in the O/TWAMP-Control protocol are generated randomly by the Control-Client, and encrypted with the shared secret associated with KeyID. Therefore, the security root is the shared secret key. Thus, for large deployments, key provision and management may become overly complicated. Comparatively, a certificate-based approach using IKEv2 can automatically manage the security root and solve this problem, as we explain in Section 5.
如上所述，O/TWAMP测试AES会话密钥和HMAC会话密钥分别来自O/TWAMP控制AES会话密钥和HMAC会话密钥。O/TWAMP控制协议中使用的AES会话密钥和HMAC会话密钥由控制客户端随机生成，并使用与KeyID关联的共享密钥进行加密。因此，安全根是共享密钥。因此，对于大型部署，关键供应和管理可能变得过于复杂。相比之下，使用IKEv2的基于证书的方法可以自动管理安全根并解决此问题，如第5节所述。
This section presents a method of binding O/TWAMP and IKEv2 for network measurements between a client and a server that both support IPsec. In short, the shared key used for securing O/TWAMP traffic is derived using IKEv2 [RFC7296].
本节介绍一种绑定O/TWAMP和IKEv2的方法，用于在同时支持IPsec的客户端和服务器之间进行网络测量。简而言之，用于保护O/TWAMP流量的共享密钥是使用IKEv2[RFC7296]派生的。
In the authenticated, encrypted, and mixed modes, the shared secret key MUST be derived from the IKEv2 SA. Note that we explicitly opt to derive the shared secret key from the IKEv2 SA, rather than the child SA, since it is possible that an IKEv2 SA is created without generating any child SA [RFC6023].
在认证、加密和混合模式下，共享密钥必须从IKEv2 SA派生。请注意，我们明确选择从IKEv2 SA而不是子SA派生共享密钥，因为创建IKEv2 SA时可能不生成任何子SA[RFC6023]。
When the shared secret key is derived from the IKEv2 SA, SK_d must be generated first. SK_d must be computed as per [RFC7296].
当从IKEv2 SA派生共享密钥时，必须首先生成SK_d。SK_d必须按照[RFC7296]计算。
The shared secret key MUST be generated as follows:
必须按如下方式生成共享密钥：
Shared secret key = prf( SK_d, "IPPM" )
共享密钥=prf（SK_d，“IPPM”）
Wherein the string "IPPM" is encoded in ASCII and "prf" is a pseudorandom function.
其中字符串“IPPM”以ASCII编码，“prf”是伪随机函数。
It is recommended that the shared secret key is derived in the IPsec layer so that IPsec keying material is not exposed to the O/TWAMP client. Note, however, that the interaction between the O/TWAMP and IPsec layers is host internal and implementation specific. Therefore, this is clearly outside the scope of this document, which focuses on the interaction between the O/TWAMP client and server. That said, one possible way could be the following: at the Control-Client side, the IPsec layer can perform a lookup in the Security Association Database (SAD) using the IP address of the Server and thus match the corresponding IKEv2 SA. At the Server side, the IPsec layer can look up the corresponding IKEv2 SA by using the Security Parameter Indexes (SPIs) sent by the Control-Client (see Section 5.3), and therefore extract the shared secret key.
建议在IPsec层中派生共享密钥，以便IPsec密钥材料不会暴露给O/TWAMP客户端。但是，请注意，O/TWAMP和IPsec层之间的交互是主机内部的，并且是特定于实现的。因此，这显然超出了本文档的范围，本文档的重点是O/TWAMP客户机和服务器之间的交互。也就是说，一种可能的方法是：在控制客户端，IPsec层可以使用服务器的IP地址在安全关联数据库（SAD）中执行查找，从而匹配相应的IKEv2 SA。在服务器端，IPsec层可以使用控制客户端发送的安全参数索引（SPI）查找相应的IKEv2 SA（参见第5.3节），从而提取共享密钥。
If both the client and server do support IKEv2 but there is no current IKEv2 SA, two alternative ways could be considered. First, the O/TWAMP Control-Client initiates the establishment of the IKEv2 SA, logs this operation, and selects the mode that supports IKEv2. Alternatively, the O/TWAMP Control-Client does not initiate the establishment of the IKEv2 SA, logs an error for operational management purposes, and proceeds with the modes defined in [RFC4656], [RFC5357], and [RFC5618]. Again, although both alternatives are feasible, they are in fact implementation specific.
如果客户端和服务器都支持IKEv2，但当前没有IKEv2 SA，则可以考虑两种替代方法。首先，O/TWAMP控制客户端启动IKEv2 SA的建立，记录此操作，并选择支持IKEv2的模式。或者，O/TWAMP控制客户机不启动IKEv2 SA的建立，出于运营管理目的记录错误，并继续使用[RFC4656]、[RFC5357]和[RFC5618]中定义的模式。同样，尽管这两种备选方案都是可行的，但它们实际上都是特定于实现的。
If rekeying for the IKEv2 SA or deletion of the IKEv2 SA occurs, the corresponding shared secret key generated from the SA MUST continue to be used until the O/TWAMP session terminates.
如果为IKEv2 SA重新设置密钥或删除IKEv2 SA，则必须继续使用SA生成的相应共享密钥，直到O/TWAMP会话终止。
To trigger a binding association between the key generated from IKEv2 and the O/TWAMP shared secret key, the Modes field in the Server Greeting Message (Figure 2) must support key derivation as discussed in Section 5.1. Support for deriving the shared key from the IKEv2 SA is indicated by setting IKEv2Derived (see Section 7). Therefore, when this method is used, the Modes value extension MUST be supported.
要触发IKEv2生成的密钥与O/TWAMP共享密钥之间的绑定关联，服务器问候消息（图2）中的Modes字段必须支持第5.1节中讨论的密钥派生。通过设置IKEv2Derived（参见第7节），可以指示对从IKEv2 SA派生共享密钥的支持。因此，使用此方法时，必须支持模式值扩展。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Unused (12 octets) |
| |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Salt (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Unused (12 octets) |
| |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Salt (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Server Greeting Format
图2：服务器问候语格式
The choice of this set of Modes values poses no backwards-compatibility problems to existing O/TWAMP clients. Robust legacy Control-Client implementations would disregard the fact that the IKEv2Derived Modes bit in the Server Greeting is set. On the other hand, a Control-Client implementing this method can identify that the O/TWAMP Server contacted does not support this specification. If the Server supports other Modes, as one could assume, the Control-Client would then decide which Mode to use and indicate such accordingly as per [RFC4656] and [RFC5357]. A Control-Client that is implementing this method and decides not to employ IKEv2 derivation can simply behave as a client that is purely compatible with [RFC4656] and [RFC5357].
选择这组模式值不会对现有O/TWAMP客户端造成向后兼容性问题。健壮的传统控制客户端实现将忽略服务器问候语中的IKEv2Derived Modes位已设置的事实。另一方面，实现此方法的控制客户端可以识别所联系的O/TWAMP服务器不支持此规范。如果服务器支持其他模式（可以假设），则控制客户端将根据[RFC4656]和[RFC5357]决定使用哪种模式并相应地指示。实现此方法并决定不使用IKEv2派生的控制客户端可以简单地作为与[RFC4656]和[RFC5357]完全兼容的客户端。
The Set-Up-Response message Figure 3 is updated as follows. When an O/TWAMP Control-Client implementing this method receives a Server Greeting indicating support for Mode IKEv2Derived, it SHOULD reply to the O/TWAMP Server with a Set-Up-Response that indicates so. For
设置响应消息图3更新如下。当实现此方法的O/TWAMP控制客户端接收到表示支持IKEv2Derived模式的服务器问候语时，它应该向O/TWAMP服务器回复一个指示支持IKEv2Derived模式的设置响应。对于
example, a compatible O/TWAMP Control-Client choosing the authenticated mode with IKEv2 shared secret key derivation should set the Mode bits as per Section 7.
例如，选择具有IKEv2共享密钥派生的认证模式的兼容O/TWAMP控制客户端应根据第7节设置模式位。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| KeyID (80 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Token (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Client-IV (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| KeyID (80 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Token (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Client-IV (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Set-Up-Response Message
图3：设置响应消息
The Security Parameter Index (SPI), as described in [RFC4301] and [RFC7296], uniquely identifies the SA. If the Control-Client supports shared secret key derivation for the IKEv2 SA, it will choose the corresponding Mode value and carry SPIi and SPIr in the KeyID field. SPIi and SPIr MUST be included in the KeyID field of the Set-Up-Response Message to indicate the IKEv2 SA from which the O/TWAMP shared secret key was derived. The length of SPI is 8 octets. Therefore, the first 8 octets of the KeyID field MUST carry SPIi, and the second 8 octets MUST carry SPIr. The remaining bits of the KeyID field MUST be set to zero.
如[RFC4301]和[RFC7296]中所述，安全参数索引（SPI）唯一标识SA。如果控制客户端支持IKEv2 SA的共享密钥派生，它将选择相应的模式值，并在KeyID字段中携带SPIi和SPIr。SPIi和SPIr必须包含在设置响应消息的KeyID字段中，以指示从中派生O/TWAMP共享密钥的IKEv2 SA。SPI的长度为8个八位字节。因此，KeyID字段的前8个八位字节必须携带SPIi，第二8个八位字节必须携带SPIr。KeyID字段的剩余位必须设置为零。
An O/TWAMP Server implementation MUST obtain the SPIi and SPIr from the first 16 octets and ignore the remaining octets of the KeyID field. Then, the Control-Client and the Server can derive the shared secret key based on the Mode value and SPI. If the O/TWAMP Server cannot find the IKEv2 SA corresponding to the SPIi and SPIr received, it MUST log the event for operational management purposes. In addition, the O/TWAMP Server SHOULD set the Accept field of the Server-Start message to the value 6 to indicate that the Server is not willing to conduct further transactions in this O/TWAMP-Control session since it cannot find the corresponding IKEv2 SA.
O/TWAMP服务器实现必须从前16个八位字节获取SPIi和SPIr，并忽略KeyID字段的其余八位字节。然后，控制客户端和服务器可以基于模式值和SPI导出共享密钥。如果O/TWAMP服务器找不到与接收到的SPIi和SPIr相对应的IKEv2 SA，则必须记录该事件，以便进行操作管理。此外，O/TWAMP服务器应将服务器启动消息的Accept字段设置为值6，以表明服务器不愿意在此O/TWAMP控制会话中执行进一步的事务，因为它找不到相应的IKEv2 SA。
The IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security Payload (ESP) [RFC4303] provide confidentiality and data integrity to IP datagrams. An IPsec tunnel can be used to provide the protection needed for O/TWAMP Control and Test packets, even if the peers choose the unauthenticated mode of operation. In order to ensure authenticity and security, O/TWAMP packets between two IKEv2 systems SHOULD be configured to use the corresponding IPsec tunnel running over an external network even when using the O/TWAMP unauthenticated mode.
IPsec身份验证头（AH）[RFC4302]和封装安全有效负载（ESP）[RFC4303]为IP数据报提供机密性和数据完整性。IPsec隧道可用于提供O/TWAMP控制和测试数据包所需的保护，即使对等方选择未经验证的操作模式。为了确保真实性和安全性，两个IKEv2系统之间的O/TWAMP数据包应配置为使用通过外部网络运行的相应IPsec隧道，即使在使用O/TWAMP未经验证的模式时也是如此。
As the shared secret key is derived from the IKEv2 SA, the key derivation algorithm strength and limitations are as per [RFC7296]. The strength of a key derived from a Diffie-Hellman exchange using any of the groups defined here depends on the inherent strength of the group, the size of the exponent used, and the entropy provided by the random number generator employed. The strength of all keys and implementation vulnerabilities, particularly denial-of-service (DoS) attacks are as defined in [RFC7296].
由于共享密钥来自IKEv2 SA，密钥导出算法的强度和限制符合[RFC7296]。使用此处定义的任何组从Diffie-Hellman交换中导出的密钥的强度取决于组的固有强度、所用指数的大小以及所用随机数生成器提供的熵。[RFC7296]中定义了所有密钥和实现漏洞的强度，特别是拒绝服务（DoS）攻击。
During the production of this document, the authors and reviewers noticed that the TWAMP-Modes registry should describe a field of single bit position flags, rather than the existing registry construction with assignment of integer values. In addition, the Semantics Definition column seemed to have spurious information in it. The registry has been reformatted to simplify future assignments. Thus, the contents of the TWAMP-Modes registry are as follows:
在本文档的编写过程中，作者和审阅者注意到，TWAMP模式注册表应该描述一个单位位置标志字段，而不是指定整数值的现有注册表结构。此外，语义定义列中似乎包含虚假信息。注册表已重新格式化，以简化将来的分配。因此，TWAMP模式注册表的内容如下：
Bit|Description |Semantics |Reference
Pos| |Definition |
---|------------------------------------------|------------|---------
0 Unauthenticated Section 3.1 [RFC4656]
1 Authenticated Section 3.1 [RFC4656]
2 Encrypted Section 3.1 [RFC4656]
3 Unauth. TEST protocol, Encrypted CONTROL Section 3.1 [RFC5618]
4 Individual Session Control [RFC5938]
5 Reflect Octets Capability [RFC6038]
6 Symmetrical Size Sender Test Packet Format [RFC6038]
Bit|Description |Semantics |Reference
Pos| |Definition |
---|------------------------------------------|------------|---------
0 Unauthenticated Section 3.1 [RFC4656]
1 Authenticated Section 3.1 [RFC4656]
2 Encrypted Section 3.1 [RFC4656]
3 Unauth. TEST protocol, Encrypted CONTROL Section 3.1 [RFC5618]
4 Individual Session Control [RFC5938]
5 Reflect Octets Capability [RFC6038]
6 Symmetrical Size Sender Test Packet Format [RFC6038]
Figure 4: TWAMP Modes
图4:TWAMP模式
The new description and registry management instructions follow.
下面是新的说明和注册表管理说明。
Registry Specification: TWAMP-Modes are specified in TWAMP Server Greeting messages and Set-Up-Response messages consistent with Section 3.1 of [RFC5357]. Modes are indicated by setting single bits in the 32-bit Modes field.
注册表规范：TWAMP模式在符合[RFC5357]第3.1节的TWAMP服务器问候信息和设置响应信息中指定。模式通过在32位模式字段中设置单个位来指示。
Registry Management: Because the "TWAMP-Modes" are based on only 32 bit positions with each position conveying a unique feature, and because TWAMP is an IETF protocol, this registry must be updated only by "IETF Review" as specified in [RFC5226]. IANA SHOULD allocate monotonically increasing bit positions when requested.
注册表管理：由于“TWAMP模式”仅基于32位位置，每个位置都传递一个独特的功能，并且由于TWAMP是一个IETF协议，因此该注册表必须仅通过[RFC5226]中规定的“IETF审查”进行更新。IANA应在请求时分配单调递增的位位置。
Experimental Numbers: No experimental bit positions are currently assigned in the Modes registry, as indicated in the initial contents above.
实验编号：如上面的初始内容所示，模式注册表中当前未分配任何实验位位置。
In addition, per this document, a new entry has been added to the TWAMP-Modes registry:
此外，根据本文档，TWAMP模式注册表中添加了一个新条目：
Bit|Description |Semantics |Reference
Pos| |Definition |
---|------------------------------------------|------------|---------
7 IKEv2Derived Mode Capability Section 5 RFC 7717
Bit|Description |Semantics |Reference
Pos| |Definition |
---|------------------------------------------|------------|---------
7 IKEv2Derived Mode Capability Section 5 RFC 7717
Figure 5: TWAMP IKEv2-Derived Mode Capability
图5:TWAMP IKEv2衍生模式能力
For the new OWAMP-Modes registry, see the IANA Considerations in [RFC7718].
有关新的OWAMP模式注册表，请参阅[RFC7718]中的IANA注意事项。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <http://www.rfc-editor.org/info/rfc4656>.
[RFC4656]Shalunov，S.，Teitelbaum，B.，Karp，A.，Boote，J.，和M.Zekauskas，“单向主动测量协议（OWAMP）”，RFC 4656，DOI 10.17487/RFC4656，2006年9月<http://www.rfc-editor.org/info/rfc4656>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <http://www.rfc-editor.org/info/rfc5357>.
[RFC5357]Hedayat，K.，Krzanowski，R.，Morton，A.，Yum，K.，和J.Babiarz，“双向主动测量协议（TWAMP）”，RFC 5357，DOI 10.17487/RFC5357，2008年10月<http://www.rfc-editor.org/info/rfc5357>.
[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, DOI 10.17487/RFC5618, August 2009, <http://www.rfc-editor.org/info/rfc5618>.
[RFC5618]Morton，A.和K.Hedayat，“双向主动测量协议（TWAMP）的混合安全模式”，RFC 5618，DOI 10.17487/RFC5618，2009年8月<http://www.rfc-editor.org/info/rfc5618>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 7296，DOI 10.17487/RFC72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
[RFC7718] Morton, A., "Registries for the One-Way Active Measurement Protocol (OWAMP)", RFC 7718, DOI 10.17487/RFC7718, December 2015, <http://www.rfc-editor.org/info/rfc7718>.
[RFC7718]Morton，A.“单向主动测量协议（OWAMP）的注册”，RFC 7718，DOI 10.17487/RFC7718，2015年12月<http://www.rfc-editor.org/info/rfc7718>.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, DOI 10.17487/RFC2898, September 2000, <http://www.rfc-editor.org/info/rfc2898>.
[RFC2898]Kaliski，B.，“PKCS#5：基于密码的加密规范2.0版”，RFC 2898，DOI 10.17487/RFC2898，2000年9月<http://www.rfc-editor.org/info/rfc2898>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<http://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <http://www.rfc-editor.org/info/rfc4302>.
[RFC4302]Kent，S.，“IP认证头”，RFC 4302，DOI 10.17487/RFC4302，2005年12月<http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，DOI 10.17487/RFC4303，2005年12月<http://www.rfc-editor.org/info/rfc4303>.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <http://www.rfc-editor.org/info/rfc5706>.
[RFC5706]Harrington，D.，“考虑新协议和协议扩展的操作和管理指南”，RFC 5706，DOI 10.17487/RFC5706，2009年11月<http://www.rfc-editor.org/info/rfc5706>.
[RFC5938] Morton, A. and M. Chiba, "Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP)", RFC 5938, DOI 10.17487/RFC5938, August 2010, <http://www.rfc-editor.org/info/rfc5938>.
[RFC5938]Morton，A.和M.Chiba，“双向主动测量协议（TWAMP）的单独会话控制功能”，RFC 5938，DOI 10.17487/RFC5938，2010年8月<http://www.rfc-editor.org/info/rfc5938>.
[RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)", RFC 6023, DOI 10.17487/RFC6023, October 2010, <http://www.rfc-editor.org/info/rfc6023>.
[RFC6023]Nir，Y.，Tschofenig，H.，Deng，H.，和R.Singh，“互联网密钥交换版本2（IKEv2）安全协会（SA）的无子女启动”，RFC 6023，DOI 10.17487/RFC6023，2010年10月<http://www.rfc-editor.org/info/rfc6023>.
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, <http://www.rfc-editor.org/info/rfc6038>.
[RFC6038]Morton，A.和L.Ciavattone，“双向主动测量协议（TWAMP）反映八位组和对称尺寸特征”，RFC 6038，DOI 10.17487/RFC6038，2010年10月<http://www.rfc-editor.org/info/rfc6038>.
Acknowledgements
致谢
We thank Eric Chen, Yaakov Stein, Brian Trammell, Emily Bi, John Mattsson, Steve Baillargeon, Spencer Dawkins, Tero Kivinen, Fred Baker, Meral Shirazipour, Hannes Tschofenig, Ben Campbell, Stephen Farrell, Brian Haberman, and Barry Leiba for their reviews, comments, and text suggestions.
我们感谢Eric Chen、Yaakov Stein、Brian Trammell、Emily Bi、John Mattsson、Steve Baillargeon、Spencer Dawkins、Tero Kivinen、Fred Baker、Meral Shirazipour、Hannes Tschofenig、Ben Campbell、Stephen Farrell、Brian Haberman和Barry Leiba的评论、评论和文字建议。
Al Morton deserves a special mention for his thorough reviews and text contributions to this document as well as the constructive discussions over several IPPM meetings.
特别值得一提的是，Al Morton对本文件进行了透彻的审查和文本贡献，并在几次IPPM会议上进行了建设性的讨论。
Authors' Addresses
作者地址
Kostas Pentikousis (editor) EICT GmbH EUREF-Campus Haus 13 Torgauer Strasse 12-15 10829 Berlin Germany
Kostas Pentikousis（编辑）EICT GmbH EUREF Campus Haus 13 Torgauer Strasse 12-15 10829德国柏林
Email: k.pentikousis@eict.de
Email: k.pentikousis@eict.de
Emma Zhang Huawei Technologies Huawei Building, No.3, Rd. XinXi Haidian District, Beijing 100095 China
中国北京市海淀区新溪路3号华为大厦华为技术部张爱玛100095
Email: emma.zhanglijia@huawei.com
Email: emma.zhanglijia@huawei.com
Yang Cui Huawei Technologies Otemachi First Square 1-5-1 Otemachi Chiyoda-ku, Tokyo 100-0004 Japan
Yang Cui华为技术大田町第一广场1-5-1大田町千代田区，日本东京100-0004
Email: cuiyang@huawei.com
Email: cuiyang@huawei.com