[要約] RFC 7982は、STUNを使用して往復時間とパケット損失率を測定するための方法を提案しています。このRFCの目的は、ネットワークのパフォーマンス評価とトラブルシューティングを支援することです。
Internet Engineering Task Force (IETF) P. Martinsen
Request for Comments: 7982 T. Reddy
Category: Standards Track Cisco
ISSN: 2070-1721 D. Wing
V. Singh callstats.io September 2016
V. Singh callstats.io 2016年9月
Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN)
NATのセッショントラバーサルユーティリティ（STUN）を使用した往復時間とフラクショナルロスの測定
Abstract
概要
A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience.
複数のインターフェースを持つホストは、通信に最適なインターフェースを選択する必要があります。多くの場合、この決定は静的構成に基づいており、ユーザーエクスペリエンスに影響を与える可能性のあるパス特性を考慮していません。
This document describes a mechanism for an endpoint to measure the path characteristics fractional loss and RTT using Session Traversal Utilities for NAT (STUN) messages.
このドキュメントでは、NAT（STUN）メッセージのセッショントラバーサルユーティリティを使用して、エンドポイントが経路特性の部分損失とRTTを測定するメカニズムについて説明します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc7982.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7982で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
3. Measuring RTT and Fractional Loss . . . . . . . . . . . . . . 4
3.1. TRANSACTION_TRANSMIT_COUNTER Attribute . . . . . . . . . 4
3.2. Usage in Requests . . . . . . . . . . . . . . . . . . . . 5
3.3. Usage in Responses . . . . . . . . . . . . . . . . . . . 5
3.4. Example Operation . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
This document extends STUN [RFC5389] to make it possible to correlate STUN responses to specific requests when retransmits occur. This assists the client in determining path characteristics like round-trip time (RTT) and fractional packet loss.
このドキュメントは、STUN [RFC5389]を拡張して、再送信が発生したときにSTUN応答を特定の要求に関連付けることを可能にします。これは、クライアントが往復時間（RTT）や断片的なパケット損失などのパス特性を決定するのに役立ちます。
The TRANSACTION_TRANSMIT_COUNTER attribute introduced in Section 3.1 can be used in Interactive Connectivity Establishment (ICE) [RFC5245] connectivity checks (STUN Binding request and response). It can also be used with Traversal Using Relays around NAT (TURN) [RFC5766] by adding this attribute to Allocate requests and responses to measure loss and RTT between the client and the respective TURN server.
セクション3.1で導入されたTRANSACTION_TRANSMIT_COUNTER属性は、Interactive Connectivity Establishment（ICE）[RFC5245]の接続性チェック（STUNバインディング要求と応答）で使用できます。また、NAT（TURN）[RFC5766]のリレーを使用するトラバーサルでこの属性を割り当てリクエストと応答に追加して、クライアントとそれぞれのTURNサーバー間の損失とRTTを測定することもできます。
ICE is a mechanism commonly used in Voice over IP (VoIP) applications to traverse NATs, and it uses a static prioritization formula to order the candidate pairs and perform connectivity checks, in which the most preferred address pairs are tested first, and when a sufficiently good pair is discovered, that pair is used for communications and then further connectivity tests are stopped.
ICEは、Voice over IP（VoIP）アプリケーションでNATを通過するために一般的に使用されるメカニズムであり、静的優先順位式を使用して候補ペアを順序付け、接続性チェックを実行します。適切なペアが検出され、そのペアが通信に使用され、その後の接続テストは停止されます。
When multiple paths are available for communication, the endpoint sends ICE connectivity checks across each path (candidate pair). Choosing the path with the lowest round-trip time is a reasonable approach, but retransmits can cause an otherwise good path to appear flawed. However, STUN's retransmission algorithm [RFC5389] cannot determine the round-trip time (RTT) if a STUN request packet is retransmitted because each request and retransmission packet is identical. Further, several STUN requests may be sent before the connectivity between candidate pairs are ascertained (see Section 16 of [RFC5245]). To resolve the issue of identical request and response packets in a STUN transaction, this document changes the retransmission behavior for idempotent packets. Using the mechanism described herein, a client can determine RTT as well as get a hint regarding which path direction caused packet loss. This is achieved by defining a new STUN attribute and requires compliant STUN (TURN and ICE) endpoints to count request packets.
通信に複数のパスが使用可能な場合、エンドポイントは各パス（候補ペア）にICE接続チェックを送信します。ラウンドトリップ時間が最小のパスを選択するのは妥当なアプローチですが、再送信すると、他の点では良好なパスに欠陥が生じる可能性があります。ただし、STUNの再送信アルゴリズム[RFC5389]では、STUN要求パケットが再送信された場合、各要求と再送信パケットが同一であるため、往復時間（RTT）を決定できません。さらに、候補ペア間の接続が確認される前に、いくつかのSTUNリクエストが送信される場合があります（[RFC5245]のセクション16を参照）。 STUNトランザクションでの同一のリクエストパケットとレスポンスパケットの問題を解決するために、このドキュメントではべき等パケットの再送信動作を変更します。ここで説明するメカニズムを使用すると、クライアントはRTTを決定できるだけでなく、パケット損失の原因となったパス方向に関するヒントを取得できます。これは、新しいSTUN属性を定義することによって実現され、要求パケットをカウントするために準拠したSTUN（TURNおよびICE）エンドポイントが必要です。
The mechanisms described in this document can be used by the controlling agent to influence the ICE candidate pair selection. How ICE will actually use this information to improve the active candidate pair selection is outside the scope of this document.
このドキュメントで説明するメカニズムは、制御エージェントがICE候補ペアの選択に影響を与えるために使用できます。 ICEが実際にこの情報を使用してアクティブな候補ペアの選択を改善する方法は、このドキュメントの範囲外です。
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 specification uses terminology defined in ICE [RFC5245] and STUN [RFC5389].
この仕様では、ICE [RFC5245]およびSTUN [RFC5389]で定義されている用語を使用しています。
This document defines a new comprehension-optional STUN attribute TRANSACTION_TRANSMIT_COUNTER with a STUN Type 0x8025. This type is in the comprehension-optional range, which means that STUN agents can safely ignore the attribute. If ICE is in use, it will fall back to normal procedures.
このドキュメントでは、STUNタイプ0x8025の新しい理解オプションのSTUN属性TRANSACTION_TRANSMIT_COUNTERを定義しています。このタイプはcomprehension-optionalの範囲にあります。これは、STUNエージェントが属性を安全に無視できることを意味します。 ICEを使用している場合、通常の手順にフォールバックします。
If a client wishes to measure RTT, it inserts the TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request. In this attribute, the client sends the number of times the STUN request is transmitted with the same transaction ID. The server would echo back the transmission count in the response so that the client can distinguish between STUN responses coming from retransmitted requests. Hence, the endpoint can use the STUN requests and responses to determine the round-trip time (RTT). The server may also convey the number of responses it has sent for the STUN request to the client. Further, this information enables the client to get a hint regarding in which direction the packet loss occurred. In some cases, it is impossible to distinguish between packet reordering and packet loss. However, if this information is collected as network metrics from several clients over a longer time period, it will be easier to detect a pattern that can provide useful information.
クライアントがRTTを測定する場合は、STUNリクエストにTRANSACTION_TRANSMIT_COUNTER属性を挿入します。この属性では、クライアントはSTUNリクエストが同じトランザクションIDで送信された回数を送信します。サーバーは、クライアントが再送信された要求からのSTUN応答を区別できるように、応答の送信カウントをエコーバックします。したがって、エンドポイントはSTUN要求と応答を使用して、往復時間（RTT）を決定できます。サーバーは、STUN要求に対して送信した応答の数をクライアントに伝えることもできます。さらに、この情報により、クライアントは、パケット損失が発生した方向に関するヒントを得ることができます。場合によっては、パケットの並べ替えとパケット損失を区別できないことがあります。ただし、この情報が複数のクライアントから長期間にわたってネットワークメトリックとして収集される場合、有用な情報を提供できるパターンを検出するのが容易になります。
The TRANSACTION_TRANSMIT_COUNTER attribute in a STUN request takes a 32-bit value. This document updates one of the STUN message structuring rules explained in Section 6 of [RFC5389] wherein retransmission of the same request reuses the same transaction ID and is bit-wise identical to the previous request. For idempotent packets, the Req and Resp fields in the TRANSACTION_TRANSMIT_COUNTER attribute will be incremented by 1 by the client or server for every transmission with the same transaction ID. Any retransmitted STUN request MUST be bit-wise identical to the previous request except for the values in the TRANSACTION_TRANSMIT_COUNTER attribute.
STUNリクエストのTRANSACTION_TRANSMIT_COUNTER属性は32ビット値を取ります。このドキュメントは、[RFC5389]のセクション6で説明されているSTUNメッセージの構造化ルールの1つを更新します。この場合、同じリクエストを再送信すると、同じトランザクションIDが再利用され、ビットごとに前のリクエストと同じになります。べき等パケットの場合、TRANSACTION_TRANSMIT_COUNTER属性のReqフィールドとRespフィールドは、同じトランザクションIDの送信ごとに、クライアントまたはサーバーによって1ずつ増分されます。再送信されたSTUN要求は、TRANSACTION_TRANSMIT_COUNTER属性の値を除いて、前の要求とビット単位で同一である必要があります。
The IANA-assigned STUN type for the new attribute is 0x8025.
新しい属性にIANAが割り当てたSTUNタイプは0x8025です。
The format of the value in the TRANSACTION_TRANSMIT_COUNTER attribute in the request is:
リクエストのTRANSACTION_TRANSMIT_COUNTER属性の値の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (Padding) | Req | Resp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: TRANSACTION_TRANSMIT_COUNTER Attribute in Request
図1：リクエストのTRANSACTION_TRANSMIT_COUNTER属性
The fields are described below:
フィールドについて以下に説明します。
Req: Number of times the request is transmitted with the same transaction ID to the server.
Req：リクエストが同じトランザクションIDでサーバーに送信された回数。
Resp: Number of times a response with the same transaction ID is sent from the server. MUST be set to zero in requests and ignored by the receiver.
Resp：同じトランザクションIDの応答がサーバーから送信された回数。リクエストでゼロに設定され、受信者によって無視される必要があります。
The padding is necessary to hit the 32-bit boundary needed for STUN attributes. The padding bits are ignored, but to allow for future reuse of these bits, they MUST be set to zero.
パディングは、STUN属性に必要な32ビット境界にヒットするために必要です。埋め込みビットは無視されますが、これらのビットを将来再利用できるようにするには、それらをゼロに設定する必要があります。
When sending a STUN request, the TRANSACTION_TRANSMIT_COUNTER Attribute allows a client to indicate to the server that it wants to measure RTT and get a hint about the direction of any packet loss.
STUNリクエストを送信するとき、クライアントはTRANSACTION_TRANSMIT_COUNTER属性を使用して、RTTを測定し、パケット損失の方向に関するヒントを得たいことをサーバーに示すことができます。
The client MUST populate the Req value in the TRANSACTION_TRANSMIT_COUNTER. This value MUST reflect the number of requests that have been transmitted to the server. Therefore, the initial value for the first request sent is 1. The first retransmit will set the value to 2 and so on.
クライアントは、TRANSACTION_TRANSMIT_COUNTERにReq値を設定する必要があります。この値は、サーバーに送信されたリクエストの数を反映する必要があります。したがって、送信される最初の要求の初期値は1です。最初の再送信では、値が2に設定されます。
The Resp field in the attribute MUST be set to zero in the request.
属性のRespフィールドは、リクエストでゼロに設定する必要があります。
When a server receives a STUN request that includes a TRANSACTION_TRANSMIT_COUNTER attribute, it processes the request as per the STUN protocol [RFC5389] plus the specific rules mentioned here. The server checks the following: o If the TRANSACTION_TRANSMIT_COUNTER attribute is not recognized, ignore the attribute because its type indicates that it is comprehension-optional. This should be the existing behavior as explained in Section 7.3 of [RFC5389].
サーバーは、TRANSACTION_TRANSMIT_COUNTER属性を含むSTUN要求を受信すると、STUNプロトコル[RFC5389]とここで説明されている特定のルールに従って要求を処理します。サーバーは次のことをチェックします。o TRANSACTION_TRANSMIT_COUNTER属性が認識されない場合、そのタイプは内包省略可能であることを示すため、属性を無視します。これは、[RFC5389]のセクション7.3で説明されている既存の動作である必要があります。
o The server that supports the TRANSACTION_TRANSMIT_COUNTER attribute MUST echo back the Req field in the response using a TRANSACTION_TRANSMIT_COUNTER attribute.
o TRANSACTION_TRANSMIT_COUNTER属性をサポートするサーバーは、TRANSACTION_TRANSMIT_COUNTER属性を使用して、応答のReqフィールドをエコーバックする必要があります。
o If the server is stateless or does not want to remember the transaction ID, then it populates value 0 for the Resp field in the TRANSACTION_TRANSMIT_COUNTER attribute sent in the response. If the server is stateful, then it populates the Resp field with the number of responses it has sent for the STUN request.
o サーバーがステートレスであるか、トランザクションIDを記憶したくない場合は、応答で送信されたTRANSACTION_TRANSMIT_COUNTER属性のRespフィールドに値0を入力します。サーバーがステートフルの場合、サーバーはSTUNリクエストに対して送信した応答の数をRespフィールドに入力します。
A client that receives a STUN response with a TRANSACTION_TRANSMIT_COUNTER can check the values in the Req field to accurately calculate the RTT if retransmits are occurring.
TRANSACTION_TRANSMIT_COUNTERでSTUN応答を受信するクライアントは、Reqフィールドの値をチェックして、再送信が発生している場合にRTTを正確に計算できます。
If the server sending the STUN response is stateless, the value of the Resp field will always be 0. If the server keeps state of the numbers of STUN requests with that same transaction ID, the value will reflect how many packets the server has seen and responded to. This gives the client a hint about in which direction loss occurred. See Section 3.4 for more details.
STUN応答を送信するサーバーがステートレスの場合、Respフィールドの値は常に0になります。サーバーが同じトランザクションIDを持つSTUNリクエストの数の状態を保持している場合、値はサーバーが認識したパケット数とに応じた。これにより、クライアントはどの方向で損失が発生したかについてのヒントを得ることができます。詳細については、セクション3.4を参照してください。
An example operation, when a server is stateful, is described in Figure 2. In the first case, all the requests and responses are received correctly.
サーバーがステートフルである場合の操作例を図2に示します。最初のケースでは、すべての要求と応答が正しく受信されます。
In the case of upstream loss, the first request is lost, but the second one is received correctly. The client, upon receiving the response, notes that while two requests were sent, only one was received by the server. The server also realizes that the value in the Req field does not match the number of received requests, therefore one request was lost. This may also occur at startup in the presence of firewalls or NATs that block unsolicited incoming traffic.
アップストリーム損失の場合、最初の要求は失われますが、2番目の要求は正しく受信されます。クライアントは、応答を受信すると、2つの要求が送信されたが、1つだけがサーバーによって受信されたことに注意します。サーバーは、Reqフィールドの値が受信した要求の数と一致しないため、1つの要求が失われたことも認識します。これは、ファイアウォールまたはNATの存在下で起動時に発生する可能性があり、一方的な着信トラフィックをブロックします。
In the case of downstream loss, the responses get lost, the client expecting multiple responses notes that, while the server responded to three requests, only one response was received.
ダウンストリームの損失の場合、応答は失われ、複数の応答を期待しているクライアントは、サーバーが3つの要求に応答したのに、1つの応答しか受信されなかったことに注意します。
In the case of loss in both directions, requests and responses get lost in tandem, the server notes that one request packet was not received, while the client expecting three responses received only one, and then it notes that one request and response packet were lost.
両方向で損失が発生した場合、要求と応答がタンデムで失われると、サーバーは1つの要求パケットが受信されなかったことに気付きますが、3つの応答が1つしか受信されないと予期するクライアントは、1つの要求と応答パケットが失われたことを通知します。 。
| Normal | Upstream loss | Downstream loss | Both upstream &|
| | | | downstream loss|
| Client Server | Client Server | Client Server | Client Server |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
| 1 1,1 | 1 x | 1 1,1 | 1 x |
| 1,1 | | x | |
| | 2 2,1 | 2 2,2 | 2 2,1 |
| | 2,1 | x | x |
| | | 3 3,3 | 3 3,2 |
| | | 3,3 | 3,2 |
Figure 2: Retransmit Operation between Client and Server
図2：クライアントとサーバー間の再送信操作
Another example is when the client sends two requests but the second request arrives at the server before the first request because of out-of-order delivery. In this case, the stateful server populates value 1 for the Resp field in the TRANSACTION_TRANSMIT_COUNTER attribute sent in response to the second request and value 2 for the Resp field in the TRANSACTION_TRANSMIT_COUNTER attribute sent in response to the first request.
別の例は、クライアントが2つの要求を送信したが、順序が乱れているため、最初の要求の前に2番目の要求がサーバーに到着する場合です。この場合、ステートフルサーバーは、2番目の要求に応答して送信されたTRANSACTION_TRANSMIT_COUNTER属性のRespフィールドの値1と、最初の要求に応答して送信されたTRANSACTION_TRANSMIT_COUNTER属性のRespフィールドの値2を入力します。
The intention with this mechanism is not to carry out comprehensive and accurate measurements regarding in what direction loss is occurring. In some cases, it might not be able to distinguish the difference between downstream loss and packet reordering.
このメカニズムの目的は、損失が発生している方向について包括的かつ正確な測定を実行することではありません。場合によっては、ダウンストリームの損失とパケットの並べ替えの違いを区別できないことがあります。
This document defines the TRANSACTION_TRANSMIT_COUNTER STUN attribute, described in Section 3. IANA has allocated the comprehension-optional codepoint 0x8025 for this attribute.
このドキュメントでは、セクション3で説明するTRANSACTION_TRANSMIT_COUNTER STUN属性を定義します。IANAは、この属性に内包オプションのコードポイント0x8025を割り当てました。
Security considerations discussed in [RFC5389] are to be taken into account. STUN requires that the 96-bit transaction ID be uniformly and randomly chosen from the interval 0 .. 2**96-1, and be cryptographically strong. This is good enough security against an off-path attacker. An on-path attacker can either inject a fake response or modify the values in the TRANSACTION_TRANSMIT_COUNTER attribute to mislead the client and server. This attack can be mitigated using STUN authentication. As the TRANSACTION_TRANSMIT_COUNTER is expected to be used between peers using ICE, and ICE uses a STUN short-term credential mechanism, the risk of an on-path attack influencing the messages is minimal. If the TRANSACTION_TRANSMIT_COUNTER is used with an Allocate request, one of the following mechanisms can be used to prevent attackers from trying to impersonate a TURN server and sending a bogus TRANSACTION_TRANSMIT_COUNTER attribute in the Allocate response: 1) the STUN long-term credential mechanism, 2) the STUN Extension for Third-Party Authorization [RFC7635], or 3) a TLS or DTLS connection between the TURN client and the TURN server. However, an attacker could corrupt, remove, or delay an ICE request or response, in order to discourage that path from being used.
[RFC5389]で説明されているセキュリティの考慮事項が考慮されます。 STUNは、96ビットのトランザクションIDが、間隔0 .. 2 ** 96-1から均一かつランダムに選択され、暗号的に強力であることを要求します。これは、パス外の攻撃者に対する十分なセキュリティです。パス上の攻撃者は、偽の応答を挿入するか、TRANSACTION_TRANSMIT_COUNTER属性の値を変更して、クライアントとサーバーを誤解させる可能性があります。この攻撃は、STUN認証を使用して軽減できます。 TRANSACTION_TRANSMIT_COUNTERはICEを使用するピア間で使用されることが予想され、ICEはSTUN短期資格情報メカニズムを使用するため、メッセージに影響を与えるオンパス攻撃のリスクは最小限です。 TRANSACTION_TRANSMIT_COUNTERがAllocateリクエストで使用される場合、次のメカニズムのいずれかを使用して、攻撃者がTURN Serverになりすまして、Allocateレスポンスで偽のTRANSACTION_TRANSMIT_COUNTER属性を送信するのを防ぐことができます。1）STUN長期クレデンシャルメカニズム、2 ）サードパーティ認証用のSTUN拡張[RFC7635]、または3）TURNクライアントとTURNサーバー間のTLSまたはDTLS接続。ただし、攻撃者はICEの要求または応答を破損、削除、または遅延させて、そのパスの使用を阻止する可能性があります。
If not encrypted, the information sent in any STUN packet can potentially be observed passively and used for reconnaissance and later attacks.
暗号化されていない場合、STUNパケットで送信された情報は受動的に監視され、偵察やその後の攻撃に使用される可能性があります。
[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>。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、DOI 10.17487 / RFC5245、2010年4月、<http：// www .rfc-editor.org / info / rfc5245>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<http：// www.rfc-editor.org/info/rfc5389>。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <http://www.rfc-editor.org/info/rfc5766>.
[RFC5766] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NATのリレーを使用したトラバーサル（TURN）：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、DOI 10.17487 / RFC5766、4月2010、<http://www.rfc-editor.org/info/rfc5766>。
[RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, "Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization", RFC 7635, DOI 10.17487/RFC7635, August 2015, <http://www.rfc-editor.org/info/rfc7635>.
[RFC7635] Reddy、T.、Patil、P.、Ravindranath、R。、およびJ. Uberti、「サードパーティ認証のためのNAT（STUN）拡張用のセッショントラバーサルユーティリティ」、RFC 7635、DOI 10.17487 / RFC7635、2015年8月、<http://www.rfc-editor.org/info/rfc7635>。
Acknowledgements
謝辞
Thanks to Brandon Williams, Simon Perreault, Aijun Wang, Martin Thomson, Oleg Moskalenko, Ram Mohan Ravindranath, Spencer Dawkins, Suresh Krishnan, Ben Campbell, Mirja Kuehlewind, Lionel Morand, Kathleen Moriarty, and Alissa Cooper for their valuable input and comments.
Brandon Williams、Simon Perreault、Aijun Wang、Martin Thomson、Oleg Moskalenko、Ram Mohan Ravindranath、Spencer Dawkins、Suresh Krishnan、Ben Campbell、Mirja Kuehlewind、Lionel Morand、Kathleen Moriarty、Alissa Cooperの貴重な意見とコメントに感謝します。
Authors' Addresses
著者のアドレス
Paal-Erik Martinsen Cisco Systems, Inc. Philip Pedersens vei 22 Lysaker, Akershus 1325 Norway
Paal-Erik Martinsen Cisco Systems、Inc. Philip Pedersens vei 22 Lysaker、Akershus 1325 Norway
Email: palmarti@cisco.com
Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India
Tirumaleswar Reddy Cisco Systems、Inc. Cessna Business Park、Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore、Karnataka 560103 India
Email: tireddy@cisco.com
Dan Wing
ダンウイング|
Email: dwing-ietf@fuggles.com
Varun Singh CALLSTATS I/O Oy Runeberginkatu 4c A 4 Helsinki 00100 Finland
Varun Singh CALLSTATS I / O Oy Runeberginkatu 4c A 4ヘルシンキ00100フィンランド
Email: varun@callstats.io
URI: https://www.callstats.io/about