[要約] RFC 7717は、OWAMPとTWAMPのためのIKEv2派生共有秘密鍵に関する規格です。目的は、ネットワークのアクティブな測定プロトコルにセキュリティを提供することです。
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)
一方向アクティブ測定プロトコル（OWAMP）および双方向アクティブ測定プロトコル（TWAMP）用のIKEv2派生の共有秘密鍵
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
One-Way Active Measurement Protocol（OWAMP）[RFC4656]およびTwo-Way Active Measurement Protocol（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の観点からは2つのエンドポイントと見なすことができます）が証明書ベースのセキュリティをサポートしています。たとえば、E-UTRAN Evolved Node B（eNB）とSecurity Gateway（SeGW）の間のIPパフォーマンスを測定したい場合を考えます。どちらも3GPP Long Term Evolution（LTE）ノードであり、証明書モードとInternet Key Exchange Protocolバージョン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 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.
一般に、O / TWAMP測定パケットは、一般的なユーザートラフィックと同様に、IPsecトンネルの内部で送信するか、IPsecトンネルの外部で送信できます。これは、オペレーターのポリシーとパフォーマンス評価目標に依存する可能性があり、このドキュメントで説明されているメカニズムとは直交しています。 IPsecが展開されている場合、非認証モードでIPsecを使用してO / TWAMPトラフィックを保護することは1つのオプションです。別のオプションは、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制御および/またはテストトラフィックの保護は、さまざまなセキュリティオプションを提供できません。たとえば、O / TWAMPパケットの一部を認証できません。 [RFC4656]で言及されています。レイテンシを測定するために、タイムスタンプは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派生鍵を使用する必要があります（SHOULD）。運用と管理の観点から[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では、IKEv2をサポートするクライアントとサーバー間のネットワーク測定のためにTWAMPと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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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-ControlおよびO / TWAMP-Testのセキュリティについて、以下のサブセクションで簡単に説明します。
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-Controlプロトコルでは、非認証、認証、および暗号化の3つの動作モードがサポートされています。これらのモードに加えて、TWAMP-Controlプロトコルは混合モードもサポートします。つまり、TWAMP-Controlプロトコルは暗号化モードで動作し、TWAMP-Testプロトコルは非認証モードで動作します。認証、暗号化、および混合モードでは、エンドポイントが共有シークレット（通常はパスフレーズ）を持っている必要があります。秘密鍵は、パスワードベースの鍵導出関数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は、Control-ClientとServer間のO / TWAMP-Controlプロトコルの開始段階を示しています。つまり、Control-Clientは、O / TWAMP-Controlコマンドを送信できるようにするために、サーバーへのTCP接続を開きます。サーバーは、モード、チャレンジ、ソルト、カウント、およびMBZ（ "MUST be zero"）フィールドを含むサーバーグリーティングで応答します（[RFC4656]のセクション3.1を参照）。 Control-Client優先モードが使用可能な場合、クライアントはSet-Up-Responseメッセージで応答します。選択されたモード、KeyID、Token、およびクライアント初期化ベクトル（IV）が含まれます。トークンは、16オクテットのチャレンジ、暗号化に使用される16オクテットのAESセッションキー、および認証に使用される32オクテットのHMAC-SHA1セッションキーを連結したものです。トークンはAES-CBCを使用して暗号化されます。
+----------------+ +--------+
| Control-Client | | Server |
+----------------+ +--------+
| |
|<------ TCP Connection-- ----->|
| |
|<------ Greeting message ------|
| |
|------- Set-Up-Response ------>|
| |
|<------ Server-Start ----------|
| |
Figure 1: Initiation of O/TWAMP-Control
図1：O / TWAMP-Controlの開始
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セッションキーで認証されます。サーバーはSet-Up-Responseを受信した後、Server-IVを含むServer-Startメッセージで応答します。 Control-Clientは、Client-IVをIVとしてストリーム暗号化を使用して、確立したばかりのO / TWAMP-Control接続を介して送信するすべてのものを暗号化します。これに対応して、サーバーはサーバー側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セッションキーは、コントロールクライアントによってランダムに生成されます。 HMACセッションキーは、O / TWAMP-Control接続のセットアップ中に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-Testプロトコルは、Session-SenderとSession-ReflectorのIP、およびRequest-Session交換中にネゴシエートされたポート番号を使用して、UDPで実行されます。 O / TWAMP-TestにはO / TWAMP-Controlと同じモードがあり、すべてのO / TWAMP-Testセッションは、混合モードで動作している場合を除いて、対応するO / TWAMP-Controlセッションモードを継承します。
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-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-Testパケット形式は、認証モードと暗号化モードで同じです。ただし、暗号化と認証の操作は異なります。同様に、それぞれのO / TWAMP-Controlセッションでは、各O / TWAMP-TestセッションにAESセッションキーとHMACセッションキーの2つのキーがあります。ただし、キーの取得方法には違いがあります。O/ TWAMP-Control：キーはControl-Clientによって生成され、コントロール接続の確立中にSet-Up-Responseメッセージ（の一部として）によってサーバーに通信されます。トークン）。
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-Test：キーはO / TWAMP-Controlキーとセッション識別子（SID）から派生します。これらは、キー派生関数（KDF）への入力として機能します。 O / TWAMP-Test AESセッションキーは、特定のO / TWAMP-Testセッションのパケットを暗号化および復号化するために、16オクテットSIDのO / TWAMP-Control AESセッションキーを使用して生成されます。 O / TWAMP-Test HMACセッションキーは、特定のO / TWAMP-Testセッションのパケットを認証するために、16オクテットSIDのO / TWAMP-Control HMACセッションキーを使用して生成されます。
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-Test AESセッションキーとHMACセッションキーは、それぞれO / TWAMP-Control AESセッションキーとHMACセッションキーから派生します。 O / TWAMP-Controlプロトコルで使用されるAESセッションキーとHMACセッションキーは、Control-Clientによってランダムに生成され、KeyIDに関連付けられた共有シークレットで暗号化されます。したがって、セキュリティルートは共有秘密鍵です。したがって、大規模な展開では、キーのプロビジョニングと管理が非常に複雑になる可能性があります。比較すると、セクション5で説明するように、IKEv2を使用した証明書ベースのアプローチは、セキュリティルートを自動的に管理し、この問題を解決できます。
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].
このセクションでは、IPsecをサポートするクライアントとサーバー間のネットワーク測定のためにO / TWAMPとIKEv2をバインドする方法について説明します。つまり、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から派生する必要があります。子SAではなくIKEv2 SAから共有秘密鍵を導出することを明示的に選択していることに注意してください。子SAを生成せずにIKEv2 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クライアントとサーバー間の相互作用に焦点を当てています。つまり、考えられる1つの方法は次のとおりです。コントロールクライアント側では、IPsecレイヤーがサーバーのIPアドレスを使用してセキュリティアソシエーションデータベース（SAD）でルックアップを実行し、対応するIKEv2 SAを照合できます。サーバー側では、IPsec層は、コントロールクライアント（セクション5.3を参照）から送信されたセキュリティパラメーターインデックス（SPI）を使用して対応するIKEv2 SAを検索できるため、共有秘密鍵を抽出できます。
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がない場合、2つの代替方法が考えられます。最初に、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）の[モード]フィールドが、セクション5.1で説明したキーの導出をサポートしている必要があります。 IKEv2 SAからの共有鍵の導出のサポートは、IKEv2Derivedを設定することで示されます（セクション7を参照）。したがって、このメソッドを使用する場合、Modes値の拡張をサポートする必要があります。
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モードビットが設定されているという事実を無視します。一方、このメソッドを実装するControl-Clientは、接続されたO / TWAMPサーバーがこの仕様をサポートしていないことを識別できます。サーバーが他のモードをサポートしている場合、想定されるように、コントロールクライアントは使用するモードを決定し、[RFC4656]と[RFC5357]に従ってそれに応じてそれを示します。このメソッドを実装していて、IKEv2派生を採用しないことを決定したControl-Clientは、[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 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.
Set-Up-Responseメッセージの図3は、次のように更新されます。このメソッドを実装するO / TWAMPコントロールクライアントが、モードIKEv2Derivedのサポートを示すサーバーグリーティングを受信すると、それを示すSet-Up-ResponseでO / TWAMPサーバーに応答する必要があります。たとえば、互換性のあるO / TWAMPコントロールクライアントが、IKEv2共有秘密鍵の導出で認証モードを選択すると、セクション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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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を一意に識別します。 Control-ClientがIKEv2 SAの共有秘密鍵の導出をサポートしている場合、対応するMode値を選択し、KeyIDフィールドにSPIiとSPIrを伝えます。 O / TWAMP共有秘密鍵の導出元であるIKEv2 SAを示すには、SPIiとSPIrをSet-Up-ResponseメッセージのKeyIDフィールドに含める必要があります。 SPIの長さは8オクテットです。したがって、KeyIDフィールドの最初の8オクテットはSPIiを伝送する必要があり、2番目の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フィールドの残りのオクテットを無視する必要があります。次に、Control-ClientおよびServerは、Mode値とSPIに基づいて共有秘密鍵を導出できます。 O / TWAMPサーバーが受信したSPIiおよびSPIrに対応するIKEv2 SAを見つけることができない場合、運用管理の目的でイベントをログに記録する必要があります。さらに、O / TWAMPサーバーは、対応するIKEv2が見つからないため、サーバーがこのO / TWAMP-Controlセッションでさらにトランザクションを実行する意思がないことを示すために、サーバー開始メッセージのAcceptフィールドを値6に設定する必要があります（SHOULD）。 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制御およびテストパケットに必要な保護を提供するために使用できます。信頼性とセキュリティを確保するために、2つのIKEv2システム間のO / TWAMPパケットは、O / TWAMP非認証モードを使用している場合でも、外部ネットワーク上で実行される対応するIPsecトンネルを使用するように構成する必要があります。
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交換から導出されたキーの強度は、グループの固有の強度、使用される指数のサイズ、および使用される乱数ジェネレーターによって提供されるエントロピーに依存します。すべてのキーの強度と実装の脆弱性、特にサービス拒否（DoS）攻撃は、[RFC7296]で定義されています。
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-Modesレジストリが整数値の割り当てによる既存のレジストリ構造ではなく、単一ビット位置フラグのフィールドを記述する必要があることに気付きました。さらに、セマンティクス定義の列には、誤った情報が含まれているようです。レジストリは、将来の割り当てを簡略化するために再フォーマットされました。したがって、TWAMP-Modesレジストリの内容は次のとおりです。
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-Modeは、[RFC5357]のセクション3.1と整合性のあるTWAMPサーバーグリーティングメッセージとセットアップ応答メッセージで指定されます。モードは、32ビットの[モード]フィールドに1ビットを設定することで示されます。
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は、要求されたときに単調に増加するビット位置を割り当てる必要があります（SHOULD）。
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-Modesレジストリに追加されました。
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-Modesレジストリについては、[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、「A One-way Active Measurement Protocol（OWAMP）」、RFC 4656、DOI 10.17487 / RFC4656、9月2006、<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、「RFCで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、「A Two-Way Active Measurement Protocol（TWAMP）」、RFC 5357、DOI 10.17487 / RFC5357、10月2008、<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、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年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]モートン、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：Password-Based Cryptography Specification Version 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]ケント、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]ケント、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]ハリントン、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]モートンA.およびM.千葉、「双方向アクティブ測定プロトコル（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、「A Childless Initiation of the Internet Key Exchange Version 2（IKEv2）Security Association（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、「Two-Way Active Measurement Protocol（TWAMP）Reflect Octets and Symmetrical Size Features」、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.
アルモートンは、このドキュメントに対する彼の徹底的なレビューとテキストの貢献、およびいくつかの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
Emma Zhang Huawei Technologies Huawei Building, No.3, Rd. XinXi Haidian District, Beijing 100095 China
Emma Zhang hu Aはテクノロジーhu Aが構築するテクノロジー、No.3、RDξNX 100095中国北京NX IHショートポイント地区
Email: emma.zhanglijia@huawei.com
Yang Cui Huawei Technologies Otemachi First Square 1-5-1 Otemachi Chiyoda-ku, Tokyo 100-0004 Japan
やんｇ くい ふあうぇい てｃｈのぉぎえｓ おてまち ふぃｒｓｔ Ｓくあれ １ー５ー１ おてまち ちよだーく、 ときょ １００ー０００４ じゃぱん
Email: cuiyang@huawei.com