RFC3489 日本語訳
3489 STUN - Simple Traversal of User Datagram Protocol (UDP) ThroughNetwork Address Translators (NATs). J. Rosenberg, J. Weinberger, C.Huitema, R. Mahy. March 2003. (Format: TXT=117562 bytes) (Obsoleted by RFC5389) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg
Request for Comments: 3489 J. Weinberger
Category: Standards Track dynamicsoft
C. Huitema
Microsoft
R. Mahy
Cisco
March 2003
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 3489年のJ.ワインバーガーカテゴリ: 2003年の規格Track dynamicsoft C.HuitemaマイクロソフトR.マーイのシスコの行進
STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)
気絶させてください--ユーザデータグラムの簡単な縦断はネットワークアドレス変換機構を通して(UDP)について議定書の中で述べます。(NATs)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure.
Network Address Translators(NATs)(STUN)を通したユーザー・データグラム・プロトコル(UDP)の簡単なTraversalはアプリケーションがそれらの間のNATsとファイアウォールの存在とタイプを発見できる軽量のプロトコルと公共のインターネットです。 また、それはアプリケーションがNATによってそれらに割り当てられた公共のインターネットプロトコル(IP)アドレスを決定する能力を提供します。 STUNは多くの既存のNATsと共に働いて、彼らから少しの特別な振舞いも必要としません。 その結果、それで、さまざまなアプリケーションが既存のNATインフラストラクチャを終えることができます。
Table of Contents
目次
1. Applicability Statement ................................... 3
2. Introduction .............................................. 3
3. Terminology ............................................... 4
4. Definitions ............................................... 5
5. NAT Variations ............................................ 5
6. Overview of Operation ..................................... 6
7. Message Overview .......................................... 8
8. Server Behavior ........................................... 10
8.1 Binding Requests .................................... 10
1. 適用性声明… 3 2. 序論… 3 3. 用語… 4 4. 定義… 5 5. NAT変化… 5 6. 操作の概要… 6 7. メッセージ概要… 8 8. サーバの振舞い… 10 8.1 拘束力がある要求… 10
Rosenberg, et al. Standards Track [Page 1] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[1ページ]RFC3489は2003年3月に気絶させます。
8.2 Shared Secret Requests .............................. 13
9. Client Behavior ........................................... 14
9.1 Discovery ........................................... 15
9.2 Obtaining a Shared Secret ........................... 15
9.3 Formulating the Binding Request ..................... 17
9.4 Processing Binding Responses ........................ 17
10. Use Cases ................................................. 19
10.1 Discovery Process ................................... 19
10.2 Binding Lifetime Discovery .......................... 21
10.3 Binding Acquisition ................................. 23
11. Protocol Details .......................................... 24
11.1 Message Header ...................................... 25
11.2 Message Attributes .................................. 26
11.2.1 MAPPED-ADDRESS .............................. 27
11.2.2 RESPONSE-ADDRESS ............................ 27
11.2.3 CHANGED-ADDRESS ............................. 28
11.2.4 CHANGE-REQUEST .............................. 28
11.2.5 SOURCE-ADDRESS .............................. 28
11.2.6 USERNAME .................................... 28
11.2.7 PASSWORD .................................... 29
11.2.8 MESSAGE-INTEGRITY ........................... 29
11.2.9 ERROR-CODE .................................. 29
11.2.10 UNKNOWN-ATTRIBUTES .......................... 31
11.2.11 REFLECTED-FROM .............................. 31
12. Security Considerations ................................... 31
12.1 Attacks on STUN ..................................... 31
12.1.1 Attack I: DDOS Against a Target ............. 32
12.1.2 Attack II: Silencing a Client ............... 32
12.1.3 Attack III: Assuming the Identity of a Client 32
12.1.4 Attack IV: Eavesdropping .................... 33
12.2 Launching the Attacks ............................... 33
12.2.1 Approach I: Compromise a Legitimate
STUN Server ................................. 33
12.2.2 Approach II: DNS Attacks .................... 34
12.2.3 Approach III: Rogue Router or NAT ........... 34
12.2.4 Approach IV: MITM ........................... 35
12.2.5 Approach V: Response Injection Plus DoS ..... 35
12.2.6 Approach VI: Duplication .................... 35
12.3 Countermeasures ..................................... 36
12.4 Residual Threats .................................... 37
13. IANA Considerations ....................................... 38
14. IAB Considerations ........................................ 38
14.1 Problem Definition .................................. 38
14.2 Exit Strategy ....................................... 39
14.3 Brittleness Introduced by STUN ...................... 40
14.4 Requirements for a Long Term Solution ............... 42
14.5 Issues with Existing NAPT Boxes ..................... 43
14.6 In Closing .......................................... 43
8.2 共有秘密キー要求… 13 9. クライアントの振舞い… 14 9.1発見… 15 9.2 共有秘密キーを得ます… 15 9.3 拘束力がある要求を定式化します… 17 9.4 処理の拘束力がある応答… 17 10. ケースを使用してください… 19 10.1発見プロセス… 19 10.2 拘束力がある生涯発見… 21 10.3 拘束力がある獲得… 23 11. 詳細について議定書の中で述べてください… 24 11.1メッセージヘッダー… 25 11.2 メッセージ属性… 26 11.2.1 写像しているアドレス… 27 11.2.2 応答アドレス… 27 11.2.3 変えられたアドレス… 28 11.2.4 変更要求… 28 11.2.5 ソースアドレス… 28 11.2.6 ユーザ名… 28 11.2.7 パスワード… 29 11.2.8 メッセージの保全… 29 11.2.9 エラーコード… 29 11.2.10 未知の属性… 31 11.2.11 反射しています… 31 12. セキュリティ問題… 31 12.1が攻撃する、気絶させてください… 31 12.1.1 Iを攻撃してください: 目標に対するDDOS… 32 12.1.2 IIを攻撃してください: クライアントを黙らせます… 32 12.1.3 IIIを攻撃してください: クライアント32 12.1のアイデンティティを仮定して、.4はIVを攻撃します: 盗聴… 33 12.2 攻撃に着手します… 33 12.2.1 Iにアプローチしてください: aが認知する感染はサーバを気絶させます… 33 12.2.2 IIにアプローチしてください: DNSは攻撃します… 34 12.2.3 IIIにアプローチしてください: ルータかNATをだましてください… 34 12.2.4 IVにアプローチしてください: MITM… 35 12.2.5 Vにアプローチしてください: 応答の注射とDoS… 35 12.2.6 VIにアプローチしてください: 複製… 35 12.3の対策… 36 12.4の残りの脅威… 37 13. IANA問題… 38 14. IAB問題… 38 14.1 問題定義… 38 14.2撤退戦略… もろさが導入した39 14.3は気絶させられます… 長期ソリューションのための40 14.4の要件… 42 14.5 既存のNAPT箱で、発行します。 43 14.6 最後になりましたが… 43
Rosenberg, et al. Standards Track [Page 2] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[2ページ]RFC3489は2003年3月に気絶させます。
15. Acknowledgments ........................................... 44 16. Normative References ...................................... 44 17. Informative References .................................... 44 18. Authors' Addresses ........................................ 46 19. Full Copyright Statement................................... 47
15. 承認… 44 16. 標準の参照… 44 17. 有益な参照… 44 18. 作者のアドレス… 46 19. 完全な著作権宣言文… 47
1. Applicability Statement
1. 適用性証明
This protocol is not a cure-all for the problems associated with NAT. It does not enable incoming TCP connections through NAT. It allows incoming UDP packets through NAT, but only through a subset of existing NAT types. In particular, STUN does not enable incoming UDP packets through symmetric NATs (defined below), which are common in large enterprises. STUN's discovery procedures are based on assumptions on NAT treatment of UDP; such assumptions may prove invalid down the road as new NAT devices are deployed. STUN does not work when it is used to obtain an address to communicate with a peer which happens to be behind the same NAT. STUN does not work when the STUN server is not in a common shared address realm. For a more complete discussion of the limitations of STUN, see Section 14.
このプロトコルはNATに関連している問題のための万能薬ではありません。 それはNATを通した入って来るTCP関係を可能にしません。 それは存在する部分集合を通しただけ入って来るUDPパケットにNATタイプを許容します。 特に、STUNは左右対称のNATs(以下では、定義される)を通して入って来るUDPパケットを可能にしません。NATsは大企業で一般的です。 STUNの発見手順はUDPのNAT処理の仮定に基づいています。 新しいNATデバイスが配布されるとき、そのような仮定は先で無効であると判明するかもしれません。 それが同じNATの後ろにどれがたまたまあるかを同輩と伝えるためにアドレスを得るのに使用されるとき、STUNは働いていません。 STUNサーバが一般的な共有されたアドレス分野にないとき、STUNは働いていません。 STUNの限界の、より完全な議論に関しては、セクション14を見てください。
2. Introduction
2. 序論
Network Address Translators (NATs), while providing many benefits, also come with many drawbacks. The most troublesome of those drawbacks is the fact that they break many existing IP applications, and make it difficult to deploy new ones. Guidelines have been developed [8] that describe how to build "NAT friendly" protocols, but many protocols simply cannot be constructed according to those guidelines. Examples of such protocols include almost all peer-to- peer protocols, such as multimedia communications, file sharing and games.
また、ネットワークAddress Translators(NATs)は多くの利益を提供している間、多くの欠点と共に来ます。 それらの欠点で最も厄介であるのは、多くの既存のIPアプリケーションを破って、新しいものを配布するのを難しくするという事実です。 ガイドラインは[8] 開発されて、それが「NAT好意的な」プロトコルを築き上げる方法を説明するということですが、それらのガイドラインによると、多くのプロトコルを絶対に構成できません。 そのようなプロトコルに関する例はマルチメディア通信や、ファイル共有やゲームなどの同輩から同輩へのほとんどすべてのプロトコルを含んでいます。
To combat this problem, Application Layer Gateways (ALGs) have been embedded in NATs. ALGs perform the application layer functions required for a particular protocol to traverse a NAT. Typically, this involves rewriting application layer messages to contain translated addresses, rather than the ones inserted by the sender of the message. ALGs have serious limitations, including scalability, reliability, and speed of deploying new applications. To resolve these problems, the Middlebox Communications (MIDCOM) protocol is being developed [9]. MIDCOM allows an application entity, such as an end client or network server of some sort (like a Session Initiation Protocol (SIP) proxy [10]) to control a NAT (or firewall), in order to obtain NAT bindings and open or close pinholes. In this way, NATs and applications can be separated once more, eliminating the need for embedding ALGs in NATs, and resolving the limitations imposed by current architectures.
この問題と戦うために、Application Layer Gateways(ALGs)はNATsに埋め込まれています。 ALGsは機能が、特定のプロトコルがNATを横断するのを必要とした応用層を実行します。 通常、これは、メッセージ送信者によって挿入されたものよりむしろ変換されたアドレスを含む応用層メッセージを書き直すことを伴います。 ALGsには、新しいアプリケーションを配布するスケーラビリティ、信頼性、および速度を含む重大な制限があります。 これらの問題を解決するために、Middlebox Communications(MIDCOM)プロトコルは開発されています。[9]。 MIDCOMはアプリケーション実体を許容します、終わりのクライアントやある種のネットワークサーバのように。(NAT結合を得るために、NAT(または、ファイアウォール)を制御して、開くか、またはピンホールを閉じるSession Initiationプロトコル(SIP)プロキシ[10])のように。 このように、もう一度NATsとアプリケーションを切り離すことができます、ALGsをNATsに埋め込む必要性を排除して、現在のアーキテクチャによって課された制限を決議して。
Rosenberg, et al. Standards Track [Page 3] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[3ページ]RFC3489は2003年3月に気絶させます。
Unfortunately, MIDCOM requires upgrades to existing NAT and firewalls, in addition to application components. Complete upgrades of these NAT and firewall products will take a long time, potentially years. This is due, in part, to the fact that the deployers of NAT and firewalls are not the same people who are deploying and using applications. As a result, the incentive to upgrade these devices will be low in many cases. Consider, for example, an airport Internet lounge that provides access with a NAT. A user connecting to the NATed network may wish to use a peer-to-peer service, but cannot, because the NAT doesn't support it. Since the administrators of the lounge are not the ones providing the service, they are not motivated to upgrade their NAT equipment to support it, using either an ALG, or MIDCOM.
残念ながら、MIDCOMはアプリケーション構成要素に加えて既存のNATとファイアウォールにアップグレードを必要とします。 これらのNATとファイアウォール製品の完全なアップグレードは年間潜在的に長くかかるでしょう。 これはNATとファイアウォールのデプロイヤがアプリケーションを配布して、使用している同じ人々でないという事実の一部ためです。 その結果、多くの場合、これらのデバイスをアップグレードさせる誘因は低くなるでしょう。 例えばNATをアクセスに提供する空港インターネットラウンジを考えてください。 しかしNATedネットワークに接続するのがピアツーピアサービスを利用したがっているかもしれないユーザはそうすることができません、NATがそれをサポートしないので。 ラウンジの管理者がサービスを提供するものでないので、それらはそれをサポートするためにそれらのNAT設備をアップグレードさせるように動機づけられていません、ALGかMIDCOMのどちらかを使用して。
Another problem is that the MIDCOM protocol requires that the agent controlling the middleboxes know the identity of those middleboxes, and have a relationship with them which permits control. In many configurations, this will not be possible. For example, many cable access providers use NAT in front of their entire access network. This NAT could be in addition to a residential NAT purchased and operated by the end user. The end user will probably not have a control relationship with the NAT in the cable access network, and may not even know of its existence.
別の問題はMIDCOMプロトコルが、middleboxesを制御しているエージェントがそれらのmiddleboxesのアイデンティティを知っていて、彼らとのコントロールを可能にする関係を持っているのを必要とするということです。 多くの構成では、これは可能にならないでしょう。 例えば、多くのケーブルアクセスプロバイダーがそれらの全体のアクセスネットワークの正面でNATを使用します。 このNATはエンドユーザによって購入されて、操作された住宅のNATに加えているかもしれません。 エンドユーザは、たぶんケーブルアクセスネットワークでNATとのコントロール関係を持たないで、また存在を知ってさえいないかもしれません。
Many existing proprietary protocols, such as those for online games (such as the games described in RFC 3027 [11]) and Voice over IP, have developed tricks that allow them to operate through NATs without changing those NATs. This document is an attempt to take some of those ideas, and codify them into an interoperable protocol that can meet the needs of many applications.
オンラインゲームのためのそれらなどの既存の多くの固有のプロトコル、(RFC3027[11])とボイス・オーバー IPで説明されたゲームとしてあれほどです、それらがNATsを通してそれらのNATsを変えないで作動できる開発されたトリックを持ってください。 このドキュメントはそれらの考えのいくつか取って、多くのアプリケーションの需要を満たすことができる共同利用できるプロトコルにそれらを成文化する試みです。
The protocol described here, Simple Traversal of UDP Through NAT (STUN), allows entities behind a NAT to first discover the presence of a NAT and the type of NAT, and then to learn the addresses bindings allocated by the NAT. STUN requires no changes to NATs, and works with an arbitrary number of NATs in tandem between the application entity and the public Internet.
ここで説明されたプロトコル(UDP Through NAT(STUN)のSimple Traversal)で、NATの後ろの実体は、最初に、NATの存在とNATのタイプを発見して、そして、結合がNATで割り当てたアドレスを学びます。 STUNはNATsへの変化を全く必要としないで、アプリケーション実体と公共のインターネットの間で2人乗り自転車でNATsの特殊活字の数字で働いています。
3. Terminology
3. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant STUN implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが言いなりになった状態でBCP14、RFC2119[1]で説明されるように解釈されて、要件レベルを示すことであるべきである、実装を気絶させてくださいだろう。
Rosenberg, et al. Standards Track [Page 4] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[4ページ]RFC3489は2003年3月に気絶させます。
4. Definitions
4. 定義
STUN Client: A STUN client (also just referred to as a client)
is an entity that generates STUN requests. A STUN client can
execute on an end system, such as a user's PC, or can run in a
network element, such as a conferencing server.
クライアントを気絶させてください: STUNクライアント(また、ただクライアントと呼ばれる)はSTUNに要求を生成する実体です。 STUNクライアントはエンドシステムの上で実行できます、ユーザのPCなどのように、または、ネットワーク要素に立候補できます、会議サーバのように。
STUN Server: A STUN Server (also just referred to as a server)
is an entity that receives STUN requests, and sends STUN
responses. STUN servers are generally attached to the public
Internet.
サーバを気絶させてください: STUN Server(また、ただサーバと呼ばれる)はSTUN要求を受け取って、応答をSTUNに送る実体です。 一般に、STUNサーバは公共のインターネットに取り付けられます。
5. NAT Variations
5. NAT変化
It is assumed that the reader is familiar with NATs. It has been observed that NAT treatment of UDP varies among implementations. The four treatments observed in implementations are:
読者がNATsに詳しいと思われます。 UDPのNAT処理が実装の中で異なると認められました。 実装で観測された4つの処理は以下の通りです。
Full Cone: A full cone NAT is one where all requests from the
same internal IP address and port are mapped to the same external
IP address and port. Furthermore, any external host can send a
packet to the internal host, by sending a packet to the mapped
external address.
いっぱいに、円錐形にしてください: 完全な円錐のNATは同じ内部のIPアドレスとポートからのすべての要求が同じ外部のIPアドレスとポートに写像されるものです。 その上、どんな外部のホストも内部のホストにパケットを送ることができます、写像している外部アドレスにパケットを送ることによって。
Restricted Cone: A restricted cone NAT is one where all requests
from the same internal IP address and port are mapped to the same
external IP address and port. Unlike a full cone NAT, an external
host (with IP address X) can send a packet to the internal host
only if the internal host had previously sent a packet to IP
address X.
制限された円錐: 制限された円錐のNATは同じ内部のIPアドレスとポートからのすべての要求が同じ外部のIPアドレスとポートに写像されるものです。 完全な円錐のNATと異なって、内部のホストが以前にIPアドレスXにパケットを送った場合にだけ、外部のホスト(IPアドレスXがある)は内部のホストにパケットを送ることができます。
Port Restricted Cone: A port restricted cone NAT is like a
restricted cone NAT, but the restriction includes port numbers.
Specifically, an external host can send a packet, with source IP
address X and source port P, to the internal host only if the
internal host had previously sent a packet to IP address X and
port P.
ポートは円錐を制限しました: ポートの制限された円錐のNATは制限された円錐のNATに似ていますが、制限はポートナンバーを含んでいます。 明確に、内部のホストが以前にIPアドレスXとポートPにパケットを送った場合にだけ、外部のホストはソースIPアドレスXがあるパケットと内部のホストへのソースポートPを送ることができます。
Symmetric: A symmetric NAT is one where all requests from the
same internal IP address and port, to a specific destination IP
address and port, are mapped to the same external IP address and
port. If the same host sends a packet with the same source
address and port, but to a different destination, a different
mapping is used. Furthermore, only the external host that
receives a packet can send a UDP packet back to the internal host.
左右対称: 左右対称のNATは同じ内部のIPアドレスからのすべての要求と特定の送付先IPアドレスとポートへのポートが同じ外部のIPアドレスとポートに写像されるものです。 同じホストが同じソースアドレスとポートが、異なった目的地にパケットを送るなら、異なったマッピングは使用されています。 その上、パケットを受ける外部のホストだけがUDPパケットを内部のホストに送り返すことができます。
Rosenberg, et al. Standards Track [Page 5] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[5ページ]RFC3489は2003年3月に気絶させます。
Determining the type of NAT is important in many cases. Depending on what the application wants to do, it may need to take the particular behavior into account.
多くの場合、NATのタイプを決定するのは重要です。 アプリケーションがしたがっていることによって、それは、特定の振舞いを考慮に入れる必要があるかもしれません。
6. Overview of Operation
6. 操作の概要
This section is descriptive only. Normative behavior is described in Sections 8 and 9.
このセクションは描写的です。単に。 標準の振舞いはセクション8と9で説明されます。
/-----\
// STUN \\
| Server |
\\ //
\-----/
/-----\//は\\を気絶させます。| サーバ| \\ // \-----/
+--------------+ Public Internet
................| NAT 2 |.......................
+--------------+
+--------------+ 公共のインターネット…| NAT2|....................... +--------------+
+--------------+ Private NET 2
................| NAT 1 |.......................
+--------------+
+--------------+ 個人的なネット2…| NAT1|....................... +--------------+
/-----\
// STUN \\
| Client |
\\ // Private NET 1
\-----/
/-----\//は\\を気絶させます。| クライアント| \\//個人的なネットの1円-----/
Figure 1: STUN Configuration
図1: 構成を気絶させてください。
The typical STUN configuration is shown in Figure 1. A STUN client is connected to private network 1. This network connects to private network 2 through NAT 1. Private network 2 connects to the public Internet through NAT 2. The STUN server resides on the public Internet.
典型的なSTUN構成は図1に示されます。 STUNクライアントは私設のネットワーク1に接続されます。 このネットワークはNAT1を通して私設のネットワーク2に接続します。 私設のネットワーク2はNAT2を通して公共のインターネットに接続します。 STUNサーバは公共のインターネットにあります。
STUN is a simple client-server protocol. A client sends a request to a server, and the server returns a response. There are two types of requests - Binding Requests, sent over UDP, and Shared Secret Requests, sent over TLS [2] over TCP. Shared Secret Requests ask the server to return a temporary username and password. This username and password are used in a subsequent Binding Request and Binding Response, for the purposes of authentication and message integrity.
STUNは簡単なクライアント/サーバプロトコルです。 クライアントは要求をサーバに送ります、そして、サーバは応答を返します。 2つのタイプの要求があります--拘束力があるUDP、およびShared Secret Requestsの上に送られたRequestsはTCPの上をTLS[2]を移動しました。 共有されたSecret Requestsは、一時的なユーザ名とパスワードを返すようにサーバに頼みます。 このユーザ名とパスワードは認証とメッセージの保全の目的にその後のBinding RequestとBinding Responseで使用されます。
Rosenberg, et al. Standards Track [Page 6] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[6ページ]RFC3489は2003年3月に気絶させます。
Binding requests are used to determine the bindings allocated by NATs. The client sends a Binding Request to the server, over UDP. The server examines the source IP address and port of the request, and copies them into a response that is sent back to the client. There are some parameters in the request that allow the client to ask that the response be sent elsewhere, or that the server send the response from a different address and port. There are attributes for providing message integrity and authentication.
拘束力がある要求は、NATsによって割り当てられた結合を決定するのに使用されます。 クライアントはUDPの上のサーバにBinding Requestを送ります。 サーバは、要求のソースIPアドレスとポートを調べて、クライアントに送り返される応答にそれらをコピーします。 要求におけるクライアントが、応答をほかの場所に送るか、またはサーバが異なったアドレスとポートから応答を送るように頼むことができるいくつかのパラメタがあります。 メッセージの保全と認証を提供するための属性があります。
The trick is using STUN to discover the presence of NAT, and to learn and use the bindings they allocate.
トリックは、それらが割り当てる結合をNATの存在を発見して、学んで、使用するのにSTUNを使用することです。
The STUN client is typically embedded in an application which needs to obtain a public IP address and port that can be used to receive data. For example, it might need to obtain an IP address and port to receive Real Time Transport Protocol (RTP) [12] traffic. When the application starts, the STUN client within the application sends a STUN Shared Secret Request to its server, obtains a username and password, and then sends it a Binding Request. STUN servers can be discovered through DNS SRV records [3], and it is generally assumed that the client is configured with the domain to use to find the STUN server. Generally, this will be the domain of the provider of the service the application is using (such a provider is incented to deploy STUN servers in order to allow its customers to use its application through NAT). Of course, a client can determine the address or domain name of a STUN server through other means. A STUN server can even be embedded within an end system.
STUNクライアントは公共のIPアドレスを得る必要があるアプリケーションとデータを受け取るのに使用できるポートに通常埋め込まれています。 例えば、それは、レアルTime Transportプロトコル(RTP)[12]トラフィックを受けるためにIPアドレスとポートを入手する必要があるかもしれません。 アプリケーションが始まると、アプリケーションの中のSTUNクライアントは、STUN Shared Secret Requestをサーバに送って、ユーザ名とパスワードを得て、Binding Requestをそれに送ります。 DNS SRV記録[3]を通してSTUNサーバを発見できます、そして、一般に、クライアントがSTUNサーバを見つけるのに使用するドメインによって構成されると思われます。一般に、これはアプリケーションが利用しているサービスのプロバイダーのドメインになるでしょう(そのようなプロバイダーは顧客がNATを通したアプリケーションを使用するのを許容するためにSTUNにサーバを配布するためにincentedされます)。 もちろん、クライアントは他の手段でSTUNサーバのアドレスかドメイン名を決定できます。 エンドシステムの中でSTUNサーバを埋め込むことさえできます。
The STUN Binding Request is used to discover the presence of a NAT, and to discover the public IP address and port mappings generated by the NAT. Binding Requests are sent to the STUN server using UDP. When a Binding Request arrives at the STUN server, it may have passed through one or more NATs between the STUN client and the STUN server. As a result, the source address of the request received by the server will be the mapped address created by the NAT closest to the server. The STUN server copies that source IP address and port into a STUN Binding Response, and sends it back to the source IP address and port of the STUN request. For all of the NAT types above, this response will arrive at the STUN client.
STUN Binding Requestは、NATの存在を発見して、公共のIPアドレスを発見して、NATによって生成されたマッピングを移植するのに使用されます。 UDPを使用することで拘束力があるRequestsをSTUNサーバに送ります。 Binding RequestがSTUNサーバに到着するとき、1NATsを通して. STUNクライアントとSTUNサーバAsの間に結果を渡したかもしれません、要求のアドレスが写像がNATによって作成されたアドレスであるつもりであったならサーバの最も近くにサーバで受け取ったソース。STUNサーバは、そのソースIPアドレスとポートをSTUN Binding Responseにコピーして、STUN要求のソースIPアドレスとポートにそれを送り返します。 NATタイプのすべてに関しては、上では、この応答がSTUNクライアントに到着するでしょう。
When the STUN client receives the STUN Binding Response, it compares the IP address and port in the packet with the local IP address and port it bound to when the request was sent. If these do not match, the STUN client is behind one or more NATs. In the case of a full- cone NAT, the IP address and port in the body of the STUN response are public, and can be used by any host on the public Internet to send packets to the application that sent the STUN request. An application need only listen on the IP address and port from which
STUNクライアントがSTUN Binding Responseを受け取るとき、それは要求が送られた時まで縛ったローカルアイピーアドレスとポートにパケットのIPアドレスとポートをたとえます。 これらが合っていないなら、STUNクライアントは1NATsの後ろにいます。 完全な円錐のNATの場合では、STUN応答のボディーのIPアドレスとポートを、公共であり、公共のインターネットのどんなホストも、STUN要求を送ったアプリケーションにパケットを送るのに使用できます。 アプリケーションがIPアドレスとポートの上で聴くだけでよい、どれ
Rosenberg, et al. Standards Track [Page 7] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[7ページ]RFC3489は2003年3月に気絶させます。
the STUN request was sent. Any packets sent by a host on the public Internet to the public address and port learned by STUN will be received by the application.
STUN要求を送りました。 アプリケーションでSTUNによって学習された場内放送とポートへの公共のインターネットのホストによって送られたどんなパケットも受け取るでしょう。
Of course, the host may not be behind a full-cone NAT. Indeed, it doesn't yet know what type of NAT it is behind. To determine that, the client uses additional STUN Binding Requests. The exact procedure is flexible, but would generally work as follows. The client would send a second STUN Binding Request, this time to a different IP address, but from the same source IP address and port. If the IP address and port in the response are different from those in the first response, the client knows it is behind a symmetric NAT. To determine if it's behind a full-cone NAT, the client can send a STUN Binding Request with flags that tell the STUN server to send a response from a different IP address and port than the request was received on. In other words, if the client sent a Binding Request to IP address/port A/B using a source IP address/port of X/Y, the STUN server would send the Binding Response to X/Y using source IP address/port C/D. If the client receives this response, it knows it is behind a full cone NAT.
もちろん、ホストは完全な円錐のNATの後ろにいないかもしれません。 本当に、それはまだあるどんなタイプのNATを知っていないか。 それを決定するために、クライアントは追加STUN Binding Requestsを使用します。 正確な手順は、フレキシブルですが、一般に、以下の通り利くでしょう。 クライアントは、第2のSTUN Binding Request、この時間を異なったIPアドレスに送りますが、同じソースIPアドレスとポートから送るでしょう。 応答におけるIPアドレスとポートが最初の応答におけるそれらと異なるなら、クライアントは、左右対称のNATの後ろにそれがあるのを知っています。 完全な円錐のNATの後ろにそれがあるかを決定するために、クライアントは要求を受け取ったより異なったIPアドレスとポートから応答を送るようにSTUNサーバに言う旗でSTUN Binding Requestを送ることができます。 言い換えれば、クライアントがX/YのソースIPアドレス/港を使用することでIPアドレス/ポートA/BにBinding Requestを送るなら、STUNサーバは、ソースIPアドレス/ポートC/Dを使用することでX/YにBinding Responseを送るでしょうに。 クライアントがこの応答を受けるなら、それは、完全な円錐のNATの後ろにあるのを知っています。
STUN also allows the client to ask the server to send the Binding Response from the same IP address the request was received on, but with a different port. This can be used to detect whether the client is behind a port restricted cone NAT or just a restricted cone NAT.
また、STUNは、クライアントが要求が受け取られた同じIPアドレスからBinding Responseを送るようにサーバに頼みますが、異なったポートで頼むのを許容します。 クライアントがポートの制限された円錐のNATかまさしく制限された円錐のNATの後ろにいるかを検出するのにこれを使用できます。
It should be noted that the configuration in Figure 1 is not the only permissible configuration. The STUN server can be located anywhere, including within another client. The only requirement is that the STUN server is reachable by the client, and if the client is trying to obtain a publicly routable address, that the server reside on the public Internet.
図1での構成が唯一の許されている構成でないことに注意されるべきです。 別のクライアントの中が包含して、STUNサーバはどこでも位置できます。 唯一の要件はクライアントとクライアントが公的に発送可能なアドレスを得ようとしているかどうかによってSTUNサーバが届いていて、サーバが公共のインターネットにあるということです。
7. Message Overview
7. メッセージ概要
STUN messages are TLV (type-length-value) encoded using big endian (network ordered) binary. All STUN messages start with a STUN header, followed by a STUN payload. The payload is a series of STUN attributes, the set of which depends on the message type. The STUN header contains a STUN message type, transaction ID, and length. The message type can be Binding Request, Binding Response, Binding Error Response, Shared Secret Request, Shared Secret Response, or Shared Secret Error Response. The transaction ID is used to correlate requests and responses. The length indicates the total length of the STUN payload, not including the header. This allows STUN to run over TCP. Shared Secret Requests are always sent over TCP (indeed, using TLS over TCP).
STUNメッセージはビッグエンディアン(ネットワークは注文された)バイナリーを使用することでコード化されたTLV(長さの値をタイプする)です。 すべてのSTUNメッセージがSTUNヘッダーから始まります、続いて、STUNペイロードから始まります。 ペイロードは一連のSTUN属性です。それのセットはメッセージタイプに頼ります。 STUNヘッダーはSTUNメッセージタイプ、トランザクションID、および長さを含んでいます。 メッセージタイプは、Binding Request、Binding Response、Binding Error Response、Shared Secret Request、Shared Secret Response、またはShared Secret Error Responseであるかもしれません。 トランザクションIDは、要求と応答を関連させるのに使用されます。 長さはヘッダーを含んでいるのではなく、STUNペイロードの全長を示します。 これで、STUNはTCPをひくことができます。 いつもTCP(本当にTCPの上でTLSを使用する)の上に共有されたSecret Requestsを送ります。
Rosenberg, et al. Standards Track [Page 8] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[8ページ]RFC3489は2003年3月に気絶させます。
Several STUN attributes are defined. The first is a MAPPED-ADDRESS attribute, which is an IP address and port. It is always placed in the Binding Response, and it indicates the source IP address and port the server saw in the Binding Request. There is also a RESPONSE- ADDRESS attribute, which contains an IP address and port. The RESPONSE-ADDRESS attribute can be present in the Binding Request, and indicates where the Binding Response is to be sent. It's optional, and when not present, the Binding Response is sent to the source IP address and port of the Binding Request.
いくつかのSTUN属性が定義されます。 1番目は、MAPPED-ADDRESS属性と、どれがIPアドレスであるか、そして、ポートです。 それはいつもBinding Responseに置かれます、そして、サーバが見たソースIPアドレスとBinding Requestのポートを示します。 また、RESPONSE- ADDRESS属性があります。(それは、IPアドレスとポートを含みます)。 RESPONSE-ADDRESS属性は、Binding Requestに存在している場合があって、Binding Responseがどこに送られることになっているかを示します。 それは任意です、そして、存在していないとき、Binding RequestのソースIPアドレスとポートにBinding Responseを送ります。
The third attribute is the CHANGE-REQUEST attribute, and it contains two flags to control the IP address and port used to send the response. These flags are called "change IP" and "change port" flags. The CHANGE-REQUEST attribute is allowed only in the Binding Request. The "change IP" and "change port" flags are useful for determining whether the client is behind a restricted cone NAT or restricted port cone NAT. They instruct the server to send the Binding Responses from a different source IP address and port. The CHANGE-REQUEST attribute is optional in the Binding Request.
3番目の属性はCHANGE-REQUEST属性です、そして、それは応答を送るのに使用されるIPアドレスとポートを制御するために2個の旗を含んでいます。 これらの旗は「変化IP」と「変化ポート」旗と呼ばれます。 CHANGE-REQUEST属性はBinding Requestだけに許容されています。 「変化IP」と旗がクライアントが制限された円錐のNATの後ろにいるか、または制限されることにかかわらず決定するのに役に立つ「変化ポート」は円錐のNATを移植します。 彼らは、異なったソースIPアドレスとポートからBinding Responsesを送るようサーバに命令します。 CHANGE-REQUEST属性はBinding Requestで任意です。
The fourth attribute is the CHANGED-ADDRESS attribute. It is present in Binding Responses. It informs the client of the source IP address and port that would be used if the client requested the "change IP" and "change port" behavior.
4番目の属性はCHANGED-ADDRESS属性です。 それはBinding Responsesに存在しています。 それはクライアントが「変化IP」と「変化ポート」振舞いを要求するなら使用されるソースIPアドレスとポートについてクライアントに知らせます。
The fifth attribute is the SOURCE-ADDRESS attribute. It is only present in Binding Responses. It indicates the source IP address and port where the response was sent from. It is useful for detecting twice NAT configurations.
5番目の属性はSOURCE-ADDRESS属性です。 それは単にBinding Responsesに存在しています。 それは応答が送られたソースIPアドレスとポートを示します。 それは2倍NAT構成を検出することの役に立ちます。
The sixth attribute is the USERNAME attribute. It is present in a Shared Secret Response, which provides the client with a temporary username and password (encoded in the PASSWORD attribute). The USERNAME is also present in Binding Requests, serving as an index to the shared secret used for the integrity protection of the Binding Request. The seventh attribute, PASSWORD, is only found in Shared Secret Response messages. The eight attribute is the MESSAGE- INTEGRITY attribute, which contains a message integrity check over the Binding Request or Binding Response.
6番目の属性はUSERNAME属性です。 それはShared Secret Responseに存在しています。(Shared Secret Responseは一時的なユーザ名とパスワード(PASSWORD属性では、コード化される)をクライアントに提供します)。 また、USERNAMEもBinding Requestsに存在しています、インデックスとしてBinding Requestの保全保護に使用される共有秘密キーに機能して。 7番目の属性(PASSWORD)はShared Secret Responseメッセージで見つけられるだけです。 8属性はMESSAGE- INTEGRITY属性です。(その属性はBinding RequestかBinding Responseの上のメッセージの保全チェックを含みます)。
The ninth attribute is the ERROR-CODE attribute. This is present in the Binding Error Response and Shared Secret Error Response. It indicates the error that has occurred. The tenth attribute is the UNKNOWN-ATTRIBUTES attribute, which is present in either the Binding Error Response or Shared Secret Error Response. It indicates the mandatory attributes from the request which were unknown. The eleventh attribute is the REFLECTED-FROM attribute, which is present in Binding Responses. It indicates the IP address and port of the
9番目の属性はERROR-CODE属性です。 これはBinding Error ResponseとShared Secret Error Responseに存在しています。 それは発生した誤りを示します。 10番目の属性はUNKNOWN-ATTRIBUTES属性です。(その属性はBinding Error ResponseかShared Secret Error Responseのどちらかに存在しています)。 それは要求からの未知である義務的な属性を示します。 11番目の属性はREFLECTED-FROM属性です。(その属性はBinding Responsesに存在しています)。 それはIPアドレスとポートを示します。
Rosenberg, et al. Standards Track [Page 9] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[9ページ]RFC3489は2003年3月に気絶させます。
sender of a Binding Request, used for traceability purposes to prevent certain denial-of-service attacks.
追随性目的が、あるサービス不能攻撃を防ぐのに使用されるBinding Requestの送付者。
8. Server Behavior
8. サーバの振舞い
The server behavior depends on whether the request is a Binding Request or a Shared Secret Request.
サーバの振舞いは要求がBinding RequestかそれともShared Secret Requestであるかによります。
8.1 Binding Requests
8.1 拘束力がある要求
A STUN server MUST be prepared to receive Binding Requests on four address/port combinations - (A1, P1), (A2, P1), (A1, P2), and (A2, P2). (A1, P1) represent the primary address and port, and these are the ones obtained through the client discovery procedures below. Typically, P1 will be port 3478, the default STUN port. A2 and P2 are arbitrary. A2 and P2 are advertised by the server through the CHANGED-ADDRESS attribute, as described below.
4つのアドレス/ポート組み合わせのときにBinding Requestsを受け取るようにSTUNサーバを準備しなければなりません--(A1、P1)、(A2、P1)、(A1、P2)、および(A2、P2。) (A1、P1) プライマリアドレスとポートを表してください。そうすれば、これらは以下でクライアント発見手順で得られたものです。 P1はポート3478、通常、デフォルトSTUNポートになるでしょう。 A2とP2は任意です。 サーバは以下で説明されるようにCHANGED-ADDRESS属性を通してA2とP2の広告を出します。
It is RECOMMENDED that the server check the Binding Request for a MESSAGE-INTEGRITY attribute. If not present, and the server requires integrity checks on the request, it generates a Binding Error Response with an ERROR-CODE attribute with response code 401. If the MESSAGE-INTEGRITY attribute was present, the server computes the HMAC over the request as described in Section 11.2.8. The key to use depends on the shared secret mechanism. If the STUN Shared Secret Request was used, the key MUST be the one associated with the USERNAME attribute present in the request. If the USERNAME attribute was not present, the server MUST generate a Binding Error Response. The Binding Error Response MUST include an ERROR-CODE attribute with response code 432. If the USERNAME is present, but the server doesn't remember the shared secret for that USERNAME (because it timed out, for example), the server MUST generate a Binding Error Response. The Binding Error Response MUST include an ERROR-CODE attribute with response code 430. If the server does know the shared secret, but the computed HMAC differs from the one in the request, the server MUST generate a Binding Error Response with an ERROR-CODE attribute with response code 431. The Binding Error Response is sent to the IP address and port the Binding Request came from, and sent from the IP address and port the Binding Request was sent to.
サーバがMESSAGE-INTEGRITY属性がないかどうかBinding Requestをチェックするのは、RECOMMENDEDです。 プレゼント、サーバは要求の保全チェックを必要として、それは応答コード401でERROR-CODE属性があるBinding Error Responseを生成します。 MESSAGE-INTEGRITY属性が存在していたなら、サーバはセクション11.2.8で説明されるように要求に関してHMACを計算します。 使用するキーは共有秘密キーメカニズムによります。 STUN Shared Secret Requestが使用されたなら、キーは要求で関連しているUSERNAME属性が存在していた状態でものであるに違いありません。 USERNAME属性が存在していなかったなら、サーバはBinding Error Responseを生成しなければなりません。 Binding Error Responseは応答コード432があるERROR-CODE属性を含まなければなりません。 USERNAMEが存在していますが、サーバがそのUSERNAMEのための共有秘密キーを覚えていないなら(外に、例えば調節したので)、サーバはBinding Error Responseを生成しなければなりません。 Binding Error Responseは応答コード430があるERROR-CODE属性を含まなければなりません。 サーバが共有秘密キーを知っていますが、計算されたHMACが要求におけるものと異なっているなら、サーバは応答コード431でERROR-CODE属性があるBinding Error Responseを生成しなければなりません。 Binding Requestが来て、Binding Requestが送られたIPアドレスとポートから送ったIPアドレスとポートにBinding Error Responseを送ります。
Assuming the message integrity check passed, processing continues. The server MUST check for any attributes in the request with values less than or equal to 0x7fff which it does not understand. If it encounters any, the server MUST generate a Binding Error Response, and it MUST include an ERROR-CODE attribute with a 420 response code.
処理は、メッセージの保全チェックを仮定するのが通り続けています。 サーバは値の、より0x7fffとのそれが理解していない要求におけるどんな属性がないかどうかチェックしなければなりません。 いずれかにも遭遇するなら、サーバはBinding Error Responseを生成しなければなりません、そして、それは420応答コードがあるERROR-CODE属性を含まなければなりません。
Rosenberg, et al. Standards Track [Page 10] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[10ページ]RFC3489は2003年3月に気絶させます。
That response MUST contain an UNKNOWN-ATTRIBUTES attribute listing the attributes with values less than or equal to 0x7fff which were not understood. The Binding Error Response is sent to the IP address and port the Binding Request came from, and sent from the IP address and port the Binding Request was sent to.
その応答は値の、より0x7fffがある理解されていなかった属性を記載するUNKNOWN-ATTRIBUTES属性を含まなければなりません。 Binding Requestが来て、Binding Requestが送られたIPアドレスとポートから送ったIPアドレスとポートにBinding Error Responseを送ります。
Assuming the request was correctly formed, the server MUST generate a single Binding Response. The Binding Response MUST contain the same transaction ID contained in the Binding Request. The length in the message header MUST contain the total length of the message in bytes, excluding the header. The Binding Response MUST have a message type of "Binding Response".
要求が正しく形成されたと仮定する場合、サーバは独身のBinding Responseを生成しなければなりません。 Binding ResponseはIDがBinding Requestに含んだ同じトランザクションを含まなければなりません。 ヘッダーを除いて、メッセージヘッダーの長さはバイトで表現されるメッセージの全長を含まなければなりません。 Binding Responseには、「拘束力がある応答」のメッセージタイプがなければなりません。
The server MUST add a MAPPED-ADDRESS attribute to the Binding Response. The IP address component of this attribute MUST be set to the source IP address observed in the Binding Request. The port component of this attribute MUST be set to the source port observed in the Binding Request.
サーバはMAPPED-ADDRESS属性をBinding Responseに加えなければなりません。 Binding Requestで観測されたソースIPアドレスにこの属性のIPアドレス構成要素を設定しなければなりません。 この属性のポートの部品をBinding Requestで観測されたソースポートに設定しなければなりません。
If the RESPONSE-ADDRESS attribute was absent from the Binding Request, the destination address and port of the Binding Response MUST be the same as the source address and port of the Binding Request. Otherwise, the destination address and port of the Binding Response MUST be the value of the IP address and port in the RESPONSE-ADDRESS attribute.
RESPONSE-ADDRESS属性がBinding Requestから欠けたなら、Binding Responseの送付先アドレスとポートはBinding Requestのソースアドレスとポートと同じであるに違いありません。 さもなければ、Binding Responseの送付先アドレスとポートはRESPONSE-ADDRESS属性において、IPアドレスとポートの値であるに違いありません。
The source address and port of the Binding Response depend on the value of the CHANGE-REQUEST attribute and on the address and port the Binding Request was received on, and are summarized in Table 1.
Binding Responseのソースアドレスとポートは、CHANGE-REQUEST属性の値と、そして、Binding Requestが受け取られたアドレスとポートの上に依存して、Table1にまとめられます。
Let Da represent the destination IP address of the Binding Request (which will be either A1 or A2), and Dp represent the destination port of the Binding Request (which will be either P1 or P2). Let Ca represent the other address, so that if Da is A1, Ca is A2. If Da is A2, Ca is A1. Similarly, let Cp represent the other port, so that if Dp is P1, Cp is P2. If Dp is P2, Cp is P1. If the "change port" flag was set in CHANGE-REQUEST attribute of the Binding Request, and the "change IP" flag was not set, the source IP address of the Binding Response MUST be Da and the source port of the Binding Response MUST be Cp. If the "change IP" flag was set in the Binding Request, and the "change port" flag was not set, the source IP address of the Binding Response MUST be Ca and the source port of the Binding Response MUST be Dp. When both flags are set, the source IP address of the Binding Response MUST be Ca and the source port of the Binding Response MUST be Cp. If neither flag is set, or if the CHANGE-REQUEST attribute is absent entirely, the source IP address of the Binding Response MUST be Da and the source port of the Binding Response MUST be Dp.
DaがBinding Request(A1かA2のどちらかになる)の送付先IPアドレスを表すのを貸してください。そうすれば、DpはBinding Request(P1かP2のどちらかになる)の仕向港を表します。 CaにDaがA1であるなら、CaがA2であるようにもう片方のアドレスを表させてください。 DaがA2であるなら、CaはA1です。 同様に、CpにDpがP1であるなら、CpがP2であるようにもう片方のポートを表させてください。 DpがP2であるなら、CpはP1です。 「変化ポート」旗がBinding RequestのCHANGE-REQUEST属性で設定されて、「変化IP」旗は設定されなかったなら、Binding ResponseのソースIPアドレスがDaであるに違いありません、そして、Binding ResponseのソースポートはCpであるに違いありません。 「変化IP」旗がBinding Requestに設定されて、「変化ポート」旗は設定されなかったなら、Binding ResponseのソースIPアドレスがCaであるに違いありません、そして、Binding ResponseのソースポートはDpであるに違いありません。 両方の旗が設定されるとき、Binding ResponseのソースIPアドレスはCaであるに違いありません、そして、Binding ResponseのソースポートはCpであるに違いありません。 どちらの旗も設定されないか、またはCHANGE-REQUEST属性が完全に欠けるなら、Binding ResponseのソースIPアドレスはDaであるに違いありません、そして、Binding ResponseのソースポートはDpであるに違いありません。
Rosenberg, et al. Standards Track [Page 11] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[11ページ]RFC3489は2003年3月に気絶させます。
Flags Source Address Source Port CHANGED-ADDRESS
none Da Dp Ca:Cp
Change IP Ca Dp Ca:Cp
Change port Da Cp Ca:Cp
Change IP and
Change port Ca Cp Ca:Cp
旗のSource Address Source Port CHANGED-ADDRESS、Ca Dp Ca: Da Dp Caのいずれも:でない Cp Change IP Cp ChangeはDa Cp Caを移植します: Cp Change IPとChangeはCa Cp Ca: Cpを移植します。
Table 1: Impact of Flags on Packet Source and CHANGED-ADDRESS
テーブル1: パケットソースの上の旗と変えられたアドレスの影響
The server MUST add a SOURCE-ADDRESS attribute to the Binding Response, containing the source address and port used to send the Binding Response.
サーバはSOURCE-ADDRESS属性をBinding Responseに加えなければなりません、Binding Responseを送るのに使用されるソースアドレスとポートを含んでいて。
The server MUST add a CHANGED-ADDRESS attribute to the Binding Response. This contains the source IP address and port that would be used if the client had set the "change IP" and "change port" flags in the Binding Request. As summarized in Table 1, these are Ca and Cp, respectively, regardless of the value of the CHANGE-REQUEST flags.
サーバはCHANGED-ADDRESS属性をBinding Responseに加えなければなりません。 これはソースIPアドレスを含んでいます、そして、クライアントが「変化IP」と「変化ポート」を設定したなら使用されたポートはBinding Requestで弛みます。 Table1にまとめられるように、これらは、CHANGE-REQUEST旗の値にかかわらずそれぞれCaとCpです。
If the Binding Request contained both the USERNAME and MESSAGE- INTEGRITY attributes, the server MUST add a MESSAGE-INTEGRITY attribute to the Binding Response. The attribute contains an HMAC [13] over the response, as described in Section 11.2.8. The key to use depends on the shared secret mechanism. If the STUN Shared Secret Request was used, the key MUST be the one associated with the USERNAME attribute present in the Binding Request.
Binding RequestがUSERNAMEとMESSAGE- INTEGRITY属性の両方を含んだなら、サーバはMESSAGE-INTEGRITY属性をBinding Responseに加えなければなりません。 属性はセクション11.2.8で説明されるように応答の上にHMAC[13]を含んでいます。 使用するキーは共有秘密キーメカニズムによります。 STUN Shared Secret Requestが使用されたなら、キーはBinding Requestで関連しているUSERNAME属性が存在していた状態でものであるに違いありません。
If the Binding Request contained a RESPONSE-ADDRESS attribute, the server MUST add a REFLECTED-FROM attribute to the response. If the Binding Request was authenticated using a username obtained from a Shared Secret Request, the REFLECTED-FROM attribute MUST contain the source IP address and port where that Shared Secret Request came from. If the username present in the request was not allocated using a Shared Secret Request, the REFLECTED-FROM attribute MUST contain the source address and port of the entity which obtained the username, as best can be verified with the mechanism used to allocate the username. If the username was not present in the request, and the server was willing to process the request, the REFLECTED-FROM attribute SHOULD contain the source IP address and port where the request came from.
Binding RequestがRESPONSE-ADDRESS属性を含んだなら、サーバはREFLECTED-FROM属性を応答に加えなければなりません。 Binding RequestがShared Secret Requestから得られたユーザ名を使用することで認証されたなら、REFLECTED-FROM属性はそのShared Secret Requestが来たソースIPアドレスとポートを含まなければなりません。 要求の現在のユーザ名がShared Secret Requestを使用することで割り当てられなかったなら、REFLECTED-FROM属性はユーザ名を得た実体のソースアドレスとポートを含まなければなりません、メカニズムがユーザ名を割り当てるのに使用されている状態でベストについて確かめることができるように。 ユーザ名が要求に存在していなくて、サーバが、要求を処理しても構わないと思っていたなら、REFLECTED-FROM属性SHOULDは要求が来たソースIPアドレスとポートを含んでいます。
The server SHOULD NOT retransmit the response. Reliability is achieved by having the client periodically resend the request, each of which triggers a response from the server.
サーバSHOULD NOTは応答を再送します。 クライアントに要求を定期的に再送させることによって、信頼性は獲得されます。それはサーバから応答のそれぞれ引き金となります。
Rosenberg, et al. Standards Track [Page 12] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[12ページ]RFC3489は2003年3月に気絶させます。
8.2 Shared Secret Requests
8.2 共有秘密キー要求
Shared Secret Requests are always received on TLS connections. When the server receives a request from the client to establish a TLS connection, it MUST proceed with TLS, and SHOULD present a site certificate. The TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA [4] SHOULD be used. Client TLS authentication MUST NOT be done, since the server is not allocating any resources to clients, and the computational burden can be a source of attacks.
TLS接続のときにいつも共有されたSecret Requestsを受け取ります。 サーバがTLS接続を証明するためにクライアントから要求を受け取るとき、TLSを続けなければなりません、そして、SHOULDはサイト証明書を提示します。 TLS ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA[4]SHOULD、使用されてください。 クライアントTLS認証は完了していてはいけません、サーバがどんなリソースもクライアントに割り当てていなくて、コンピュータの負担が攻撃の源であるかもしれないので。
If the server receives a Shared Secret Request, it MUST verify that the request arrived on a TLS connection. If it did not receive the request over TLS, it MUST generate a Shared Secret Error Response, and it MUST include an ERROR-CODE attribute with a 433 response code. The destination for the error response depends on the transport on which the request was received. If the Shared Secret Request was received over TCP, the Shared Secret Error Response is sent over the same connection the request was received on. If the Shared Secret Request was receive over UDP, the Shared Secret Error Response is sent to the source IP address and port that the request came from.
サーバがShared Secret Requestを受けるなら、それは、要求がTLS接続に到達したことを確かめなければなりません。 TLSの上に要求を受け取らなかったなら、Shared Secret Error Responseを生成しなければなりません、そして、433応答コードがあるERROR-CODE属性を含まなければなりません。 誤り応答のための目的地は要求が受け取られた輸送によります。 TCPの上にShared Secret Requestを受け取ったなら、要求が受け取られた同じ接続の上にShared Secret Error Responseを送ります。 Shared Secret RequestがUDPの上で受信することであったなら、要求が来たソースIPアドレスとポートにShared Secret Error Responseを送ります。
The server MUST check for any attributes in the request with values less than or equal to 0x7fff which it does not understand. If it encounters any, the server MUST generate a Shared Secret Error Response, and it MUST include an ERROR-CODE attribute with a 420 response code. That response MUST contain an UNKNOWN-ATTRIBUTES attribute listing the attributes with values less than or equal to 0x7fff which were not understood. The Shared Secret Error Response is sent over the TLS connection.
サーバは値の、より0x7fffとのそれが理解していない要求におけるどんな属性がないかどうかチェックしなければなりません。 いずれかにも遭遇するなら、サーバはShared Secret Error Responseを生成しなければなりません、そして、それは420応答コードがあるERROR-CODE属性を含まなければなりません。 その応答は値の、より0x7fffがある理解されていなかった属性を記載するUNKNOWN-ATTRIBUTES属性を含まなければなりません。 TLS接続の上にShared Secret Error Responseを送ります。
All Shared Secret Error Responses MUST contain the same transaction ID contained in the Shared Secret Request. The length in the message header MUST contain the total length of the message in bytes, excluding the header. The Shared Secret Error Response MUST have a message type of "Shared Secret Error Response" (0x0112).
すべてのShared Secret Error ResponsesがIDがShared Secret Requestに含んだ同じトランザクションを含まなければなりません。 ヘッダーを除いて、メッセージヘッダーの長さはバイトで表現されるメッセージの全長を含まなければなりません。 Shared Secret Error Responseには、「共有秘密キー誤り応答」(0×0112)のメッセージタイプがなければなりません。
Assuming the request was properly constructed, the server creates a Shared Secret Response. The Shared Secret Response MUST contain the same transaction ID contained in the Shared Secret Request. The length in the message header MUST contain the total length of the message in bytes, excluding the header. The Shared Secret Response MUST have a message type of "Shared Secret Response". The Shared Secret Response MUST contain a USERNAME attribute and a PASSWORD attribute. The USERNAME attribute serves as an index to the password, which is contained in the PASSWORD attribute. The server can use any mechanism it chooses to generate the username. However, the username MUST be valid for a period of at least 10 minutes. Validity means that the server can compute the password for that
要求が適切に構成されたと仮定して、サーバはShared Secret Responseを作成します。 Shared Secret ResponseはIDがShared Secret Requestに含んだ同じトランザクションを含まなければなりません。 ヘッダーを除いて、メッセージヘッダーの長さはバイトで表現されるメッセージの全長を含まなければなりません。 Shared Secret Responseには、「共有秘密キー応答」のメッセージタイプがなければなりません。 Shared Secret ResponseはUSERNAME属性とPASSWORD属性を含まなければなりません。 USERNAME属性はインデックスとしてパスワードに機能します。(それは、PASSWORD属性に含まれています)。 サーバは生成するそれがユーザ名を選ぶどんなメカニズムも使用できます。 しかしながら、ユーザ名はしばらく、少なくとも10分で有効であるに違いありません。 正当性は、サーバがそれのためのパスワードを計算できることを意味します。
Rosenberg, et al. Standards Track [Page 13] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[13ページ]RFC3489は2003年3月に気絶させます。
username. There MUST be a single password for each username. In other words, the server cannot, 10 minutes later, assign a different password to the same username. The server MUST hand out a different username for each distinct Shared Secret Request. Distinct, in this case, implies a different transaction ID. It is RECOMMENDED that the server explicitly invalidate the username after ten minutes. It MUST invalidate the username after 30 minutes. The PASSWORD contains the password bound to that username. The password MUST have at least 128 bits. The likelihood that the server assigns the same password for two different usernames MUST be vanishingly small, and the passwords MUST be unguessable. In other words, they MUST be a cryptographically random function of the username.
ユーザ名。 各ユーザ名のためのただ一つのパスワードがあるに違いありません。 言い換えれば、サーバは10分後に異なったパスワードを同じユーザ名に割り当てることができません。 サーバはそれぞれの異なったShared Secret Requestのための異なったユーザ名を与えなければなりません。 異なる、この場合、異なったトランザクションIDを含意します。 サーバが10分後に明らかにユーザ名を無効にするのは、RECOMMENDEDです。 それは30分後にユーザ名を無効にしなければなりません。 PASSWORDはそのユーザ名に縛られたパスワードを含んでいます。 パスワードには、少なくとも128ビットがなければなりません。 サーバが2つの異なったユーザ名のために同じパスワードを割り当てるという見込みは消え失せて小さくなければなりません、そして、パスワードは「蹄-可能」であるに違いありません。 言い換えれば、それらは暗号でaであるに違いありません。ユーザ名の確率関数。
These requirements can still be met using a stateless server, by intelligently computing the USERNAME and PASSWORD. One approach is to construct the USERNAME as:
知的にUSERNAMEとPASSWORDを計算することによって状態がないサーバを使用することでまだこれらの必要条件を満たすことができます。 1つのアプローチは以下としてUSERNAMEを組み立てることです。
USERNAME = <prefix,rounded-time,clientIP,hmac>
ユーザ名=<接頭語、丸い時間、clientIP、hmac>。
Where prefix is some random text string (different for each shared secret request), rounded-time is the current time modulo 20 minutes, clientIP is the source IP address where the Shared Secret Request came from, and hmac is an HMAC [13] over the prefix, rounded-time, and client IP, using a server private key.
接頭語が何らかの無作為のテキスト文字列(それぞれの共有秘密キー要求において、異なった)であるところでは、丸い時間は20分間現在の時間法です、そして、clientIPはShared Secret Requestが来たソースIPアドレスです、そして、サーバ秘密鍵を使用して、hmacは接頭語、丸い時間、およびクライアントIPの上のHMAC[13]です。
The password is then computed as:
そして、パスワードは以下として計算されます。
password = <hmac(USERNAME,anotherprivatekey)>
パスワード=<hmac(ユーザ名、anotherprivatekey)>。
With this structure, the username itself, which will be present in the Binding Request, contains the source IP address where the Shared Secret Request came from. That allows the server to meet the requirements specified in Section 8.1 for constructing the REFLECTED-FROM attribute. The server can verify that the username was not tampered with, using the hmac present in the username.
この構造で、ユーザ名(Binding Requestに存在する)自体はShared Secret Requestが来たソースIPアドレスを含んでいます。 それで、サーバはセクション8.1でREFLECTED-FROM属性を構成するのに指定された必要条件を満たすことができます。 ユーザ名の現在のhmacを使用して、サーバは、ユーザ名がいじられなかったことを確かめることができます。
The Shared Secret Response is sent over the same TLS connection the request was received on. The server SHOULD keep the connection open, and let the client close it.
要求が受け取られた同じTLS接続の上にShared Secret Responseを送ります。 サーバSHOULDはクライアントに接続を開くように保って、それを閉じさせることができます。
9. Client Behavior
9. クライアントの振舞い
The behavior of the client is very straightforward. Its task is to discover the STUN server, obtain a shared secret, formulate the Binding Request, handle request reliability, and process the Binding Responses.
クライアントの振舞いは非常に正直です。 タスクは、STUNサーバを発見して、共有秘密キーを得て、Binding Requestを定式化して、要求の信頼性を扱って、Binding Responsesを処理することです。
Rosenberg, et al. Standards Track [Page 14] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[14ページ]RFC3489は2003年3月に気絶させます。
9.1 Discovery
9.1 発見
Generally, the client will be configured with a domain name of the provider of the STUN servers. This domain name is resolved to an IP address and port using the SRV procedures specified in RFC 2782 [3].
一般に、クライアントはSTUNサーバのプロバイダーのドメイン名によって構成されるでしょう。 このドメイン名は、RFC2782[3]で指定されたSRV手順を用いることでIPアドレスとポートに決議されています。
Specifically, the service name is "stun". The protocol is "udp" for sending Binding Requests, or "tcp" for sending Shared Secret Requests. The procedures of RFC 2782 are followed to determine the server to contact. RFC 2782 spells out the details of how a set of SRV records are sorted and then tried. However, it only states that the client should "try to connect to the (protocol, address, service)" without giving any details on what happens in the event of failure. Those details are described here for STUN.
明確に、サービス名は「気絶させてください」です。 プロトコルは、送付Binding Requestsのための"udp"、または送付Shared Secret Requestsのための"tcp"です。 RFC2782の手順は、接触へのサーバを決定するために従われています。 RFC2782は1セットのSRV記録がどう分類されて、次に、試みられるかに関する詳細についてスペルアウトします。 しかしながら、クライアントがそうするべきであると述べるだけである、「接続しようとする、(プロトコル、アドレス、サービス) 」 何が失敗の場合、起こるかに関するどんな詳細も述べないで。 それらの詳細はSTUNのためにここで説明されます。
For STUN requests, failure occurs if there is a transport failure of some sort (generally, due to fatal ICMP errors in UDP or connection failures in TCP). Failure also occurs if the transaction fails due to timeout. This occurs 9.5 seconds after the first request is sent, for both Shared Secret Requests and Binding Requests. See Section 9.3 for details on transaction timeouts for Binding Requests. If a failure occurs, the client SHOULD create a new request, which is identical to the previous, but has a different transaction ID and MESSAGE INTEGRITY attribute (the HMAC will change because the transaction ID has changed). That request is sent to the next element in the list as specified by RFC 2782.
STUN要求のために、ある種(一般にUDPの致命的なICMP誤りかTCPでの接続失敗への支払われるべきもの)の輸送失敗があれば、失敗は起こります。 また、トランザクションがタイムアウトのため失敗するなら、失敗は起こります。 Shared Secret RequestsとBinding Requestsの両方のために最初の要求を送った9.5秒後にこれは起こります。 トランザクションタイムアウトに関する詳細に関してBinding Requestsに関してセクション9.3を見てください。 失敗が起こるなら、クライアントSHOULDは新しい要求を作成します(トランザクションIDが変化したので、HMACは変化するでしょう)。(前と同じですが、それは、異なったトランザクションIDとMESSAGE INTEGRITY属性を持っています)。 指定されるとしてのRFC2782によるリストの次の要素にその要求を送ります。
The default port for STUN requests is 3478, for both TCP and UDP. Administrators SHOULD use this port in their SRV records, but MAY use others.
STUN要求のためのデフォルトポートはTCPとUDPの両方のための3478です。 管理者SHOULDは彼らのSRV記録でこのポートを使用しますが、他のものを使用するかもしれません。
If no SRV records were found, the client performs an A record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted at the default port.
記録が見つけられたSRV、いいえなら、クライアントはドメイン名のA記録ルックアップを実行します。 結果はIPアドレスのリストになるでしょう。それぞれデフォルトポートへそれに連絡できます。
This would allow a firewall admin to open the STUN port, so hosts within the enterprise could access new applications. Whether they will or won't do this is a good question.
これで、ファイアウォールアドミンはSTUNポートを開けることができるでしょう、したがって、企業の中のホストが新しいアプリケーションにアクセスできました。 彼らがするか、またはこれをしないかどうかが、良い問題です。
9.2 Obtaining a Shared Secret
9.2 共有秘密キーを得ること。
As discussed in Section 12, there are several attacks possible on STUN systems. Many of these are prevented through integrity of requests and responses. To provide that integrity, STUN makes use of a shared secret between client and server, used as the keying material for an HMAC used in both the Binding Request and Binding Response. STUN allows for the shared secret to be obtained in any way (for example, Kerberos [14]). However, it MUST have at least 128
セクション12で議論するように、STUNシステムの上で可能ないくつかの攻撃があります。これらの多くが要求と応答の保全を通して防がれます。 その保全を提供するために、STUNはHMACのための合わせることの材料が両方でBinding RequestとBinding Responseを使用したので使用されるクライアントとサーバの間の共有秘密キーを利用します。 STUNは、共有秘密キーが何らかの方法で得られるのを許容します。(例えば、ケルベロス[14])。 しかしながら、それには、少なくとも128がなければなりません。
Rosenberg, et al. Standards Track [Page 15] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[15ページ]RFC3489は2003年3月に気絶させます。
bits of randomness. In order to ensure interoperability, this specification describes a TLS-based mechanism. This mechanism, described in this section, MUST be implemented by clients and servers.
偶発性のビット。 相互運用性を確実にするために、この仕様はTLSベースのメカニズムについて説明します。 クライアントとサーバでこのセクションで説明されたこのメカニズムを実装しなければなりません。
First, the client determines the IP address and port that it will open a TCP connection to. This is done using the discovery procedures in Section 9.1. The client opens up the connection to that address and port, and immediately begins TLS negotiation [2]. The client MUST verify the identity of the server. To do that, it follows the identification procedures defined in Section 3.1 of RFC 2818 [5]. Those procedures assume the client is dereferencing a URI. For purposes of usage with this specification, the client treats the domain name or IP address used in Section 9.1 as the host portion of the URI that has been dereferenced.
まず最初に、クライアントはそれがTCP接続を開くIPアドレスとポートを決定します。 これはセクション9.1の発見手順を用い終わっています。 クライアントは、そのアドレスとポートに接続を開けて、すぐに、TLS交渉[2]を始めます。 クライアントはサーバのアイデンティティについて確かめなければなりません。それをするために、識別手順がRFCのセクション3.1で2818[5]を定義したということになります。 それらの手順は、クライアントがURIに「反-参照をつけ」ていると仮定します。 この仕様がある用法の目的のために、クライアントは「反-参照をつけ」られたURIのホスト部分としてセクション9.1で使用されるドメイン名かIPアドレスを扱います。
Once the connection is opened, the client sends a Shared Secret request. This request has no attributes, just the header. The transaction ID in the header MUST meet the requirements outlined for the transaction ID in a binding request, described in Section 9.3 below. The server generates a response, which can either be a Shared Secret Response or a Shared Secret Error Response.
接続がいったん開かれると、クライアントはShared Secret要求を送ります。 この要求には、属性ではなく、まさしくヘッダーがあります。 ヘッダーのトランザクションIDは以下のセクション9.3で説明された拘束力がある要求におけるトランザクションIDのために概説された必要条件を満たさなければなりません。 サーバは応答を生成します。(それは、Shared Secret ResponseかShared Secret Error Responseのどちらかであるかもしれません)。
If the response was a Shared Secret Error Response, the client checks the response code in the ERROR-CODE attribute. Interpretation of those response codes is identical to the processing of Section 9.4 for the Binding Error Response.
応答がShared Secret Error Responseであったなら、クライアントはERROR-CODE属性における応答コードをチェックします。 Binding Error Responseに、それらの応答コードの解釈はセクション9.4の処理と同じです。
If a client receives a Shared Secret Response with an attribute whose type is greater than 0x7fff, the attribute MUST be ignored. If the client receives a Shared Secret Response with an attribute whose type is less than or equal to 0x7fff, the response is ignored.
クライアントがタイプが0x7fffより偉大である属性があるShared Secret Responseを受け取るなら、属性を無視しなければなりません。 クライアントがタイプが、より0x7fff以下である属性があるShared Secret Responseを受け取るなら、応答は無視されます。
If the response was a Shared Secret Response, it will contain a short lived username and password, encoded in the USERNAME and PASSWORD attributes, respectively.
応答がShared Secret Responseであったなら、それはUSERNAMEとPASSWORD属性でそれぞれコード化された短い送られたユーザ名とパスワードを含むでしょう。
The client MAY generate multiple Shared Secret Requests on the connection, and it MAY do so before receiving Shared Secret Responses to previous Shared Secret Requests. The client SHOULD close the connection as soon as it has finished obtaining usernames and passwords.
クライアントは接続での複数のShared Secret Requestsを生成するかもしれません、そして、前のShared Secret RequestsにShared Secret Responsesを受ける前に、それはそうするかもしれません。 ユーザ名とパスワードを得終えるとすぐに、クライアントSHOULDは接続を終えます。
Section 9.3 describes how these passwords are used to provide integrity protection over Binding Requests, and Section 8.1 describes how it is used in Binding Responses.
セクション9.3はこれらのパスワードが保全保護をBinding Requestsの上に供給するのにどう使用されるかを説明します、そして、セクション8.1はそれがBinding Responsesでどう使用されるかを説明します。
Rosenberg, et al. Standards Track [Page 16] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[16ページ]RFC3489は2003年3月に気絶させます。
9.3 Formulating the Binding Request
9.3 拘束力がある要求を定式化すること。
A Binding Request formulated by the client follows the syntax rules defined in Section 11. Any two requests that are not bit-wise identical, and not sent to the same server from the same IP address and port, MUST carry different transaction IDs. The transaction ID MUST be uniformly and randomly distributed between 0 and 2**128 - 1. The large range is needed because the transaction ID serves as a form of randomization, helping to prevent replays of previously signed responses from the server. The message type of the request MUST be "Binding Request".
クライアントによって定式化されたBinding Requestはセクション11で定義されたシンタックス・ルールに従います。 的に同じ状態で噛み付かれないで、また同じIPアドレスとポートから同じサーバに送られないどんな2つの要求も異なったトランザクションIDを運ばなければなりません。 一様に手当たりしだいに0と2**128--1の間にトランザクションIDを分配しなければなりません。 トランザクションIDが無作為化のフォームとして機能するので、広い範囲が必要です、サーバから応答であると署名される以前にの再生を防ぐのを助けて。要求のメッセージタイプは「要求を縛らなければなりません」。
The RESPONSE-ADDRESS attribute is optional in the Binding Request. It is used if the client wishes the response to be sent to a different IP address and port than the one the request was sent from. This is useful for determining whether the client is behind a firewall, and for applications that have separated control and data components. See Section 10.3 for more details. The CHANGE-REQUEST attribute is also optional. Whether it is present depends on what the application is trying to accomplish. See Section 10 for some example uses.
RESPONSE-ADDRESS属性はBinding Requestで任意です。 クライアントが、要求が送られたものより応答が異なったIPアドレスとポートに送られて欲しいなら、使用されています。 これはクライアントがファイアウォールの後ろにいるかを決定する、およびコントロールとデータ構成要素を切り離したアプリケーションの役に立ちます。 その他の詳細に関してセクション10.3を見てください。 また、CHANGE-REQUEST属性も任意です。 それが存在しているかどうかがアプリケーションが達成しようとしていることによります。 いくつかの例の用途に関してセクション10を見てください。
The client SHOULD add a MESSAGE-INTEGRITY and USERNAME attribute to the Binding Request. This MESSAGE-INTEGRITY attribute contains an HMAC [13]. The value of the username, and the key to use in the MESSAGE-INTEGRITY attribute depend on the shared secret mechanism. If the STUN Shared Secret Request was used, the USERNAME must be a valid username obtained from a Shared Secret Response within the last nine minutes. The shared secret for the HMAC is the value of the PASSWORD attribute obtained from the same Shared Secret Response.
クライアントSHOULDはMESSAGE-INTEGRITYとUSERNAME属性をBinding Requestに加えます。 このMESSAGE-INTEGRITY属性はHMAC[13]を含んでいます。 値、MESSAGE-INTEGRITY属性に使用するユーザ名、およびキーでは、共有秘密キーメカニズムを当てにしてください。 STUN Shared Secret Requestが使用されたなら、USERNAMEはここ9個の議事録以内にShared Secret Responseから得られた有効なユーザ名であるに違いありません。 HMACのための共有秘密キーは同じShared Secret Responseから得られたPASSWORD属性の値です。
Once formulated, the client sends the Binding Request. Reliability is accomplished through client retransmissions. Clients SHOULD retransmit the request starting with an interval of 100ms, doubling every retransmit until the interval reaches 1.6s. Retransmissions continue with intervals of 1.6s until a response is received, or a total of 9 requests have been sent. If no response is received by 1.6 seconds after the last request has been sent, the client SHOULD consider the transaction to have failed. In other words, requests would be sent at times 0ms, 100ms, 300ms, 700ms, 1500ms, 3100ms, 4700ms, 6300ms, and 7900ms. At 9500ms, the client considers the transaction to have failed if no response has been received.
いったん定式化されると、クライアントはBinding Requestを送ります。 信頼性はクライアント「再-トランスミッション」を通して達成されます。 100ms、倍増の間隔から始めて、クライアントSHOULDが要求を再送する、あらゆる、間隔に1.6に達するまで、再送してください。 応答が受け取られているまで、Retransmissionsが1.6の間隔を続行するか、または合計9つの要求を送りました。 最後の要求を送った後に1.6秒までに応答を全く受けないなら、クライアントSHOULDは、トランザクションが失敗したと考えます。 100ms、300ms、700ms、1500ms、3100ms、4700ms、6300ms、および7900ms. At 9500ms、言い換えれば、回の0msに要求を送って、応答を全く受けていないなら、クライアントはトランザクションが失敗したと考えます。
9.4 Processing Binding Responses
9.4 処理の拘束力がある応答
The response can either be a Binding Response or Binding Error Response. Binding Error Responses are always received on the source address and port the request was sent from. A Binding Response will
応答は、Binding ResponseかBinding Error Responseのどちらかであるかもしれません。 要求が送られたソースアドレスとポートの上にいつも拘束力があるError Responsesを受け取ります。 拘束力がある応答はそうするでしょう。
Rosenberg, et al. Standards Track [Page 17] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[17ページ]RFC3489は2003年3月に気絶させます。
be received on the address and port placed in the RESPONSE-ADDRESS attribute of the request. If none was present, the Binding Responses will be received on the source address and port the request was sent from.
要求のRESPONSE-ADDRESS属性に置かれたアドレスとポートの上に受け取ってください。 なにも存在していなかったなら、要求が送られたソースアドレスとポートの上にBinding Responsesを受け取るでしょう。
If the response is a Binding Error Response, the client checks the response code from the ERROR-CODE attribute of the response. For a 400 response code, the client SHOULD display the reason phrase to the user. For a 420 response code, the client SHOULD retry the request, this time omitting any attributes listed in the UNKNOWN-ATTRIBUTES attribute of the response. For a 430 response code, the client SHOULD obtain a new shared secret, and retry the Binding Request with a new transaction. For 401 and 432 response codes, if the client had omitted the USERNAME or MESSAGE-INTEGRITY attribute as indicated by the error, it SHOULD try again with those attributes. For a 431 response code, the client SHOULD alert the user, and MAY try the request again after obtaining a new username and password. For a 500 response code, the client MAY wait several seconds and then retry the request. For a 600 response code, the client MUST NOT retry the request, and SHOULD display the reason phrase to the user. Unknown attributes between 400 and 499 are treated like a 400, unknown attributes between 500 and 599 are treated like a 500, and unknown attributes between 600 and 699 are treated like a 600. Any response between 100 and 399 MUST result in the cessation of request retransmissions, but otherwise is discarded.
応答がBinding Error Responseであるなら、クライアントは応答のERROR-CODE属性から応答コードをチェックします。 400応答コードのために、クライアントSHOULDは理由句をユーザに表示します。 420応答コードのために、クライアントSHOULDは要求(応答のUNKNOWN-ATTRIBUTES属性で記載されたどんな属性も省略する今回)を再試行します。 430応答コードのために、クライアントSHOULDは新しい共有秘密キーを得て、新しいトランザクションでBinding Requestを再試行します。 クライアントが示されるとして誤りでUSERNAMEかMESSAGE-INTEGRITY属性を省略したなら、401と432のために、応答はそれをコード化します。SHOULDはそれらの属性で再試行します。 431応答コードのために、クライアントSHOULDはユーザを警告します、そして、新しいユーザ名とパスワードを得た後に、再び要求を試みるかもしれません。 500応答コードのために、クライアントは、数秒待っていて、次に、要求を再試行するかもしれません。 600応答コードのために、クライアントは要求を再試行してはいけません、そして、SHOULDは理由句をユーザに表示します。 400と499の間の未知の属性は400のように扱われます、そして、500と599の間の未知の属性は500のように扱われます、そして、600と699の間の未知の属性は600のように扱われます。 100と399の間のどんな応答も、要求「再-トランスミッション」の休止をもたらさなければなりませんが、別の方法で捨てられます。
If a client receives a response with an attribute whose type is greater than 0x7fff, the attribute MUST be ignored. If the client receives a response with an attribute whose type is less than or equal to 0x7fff, request retransmissions MUST cease, but the entire response is otherwise ignored.
クライアントがタイプが0x7fffより偉大である属性で応答を受けるなら、属性を無視しなければなりません。 クライアントがタイプが、より0x7fff以下である属性で応答を受けるなら、要求「再-トランスミッション」はやまなければなりませんが、全体の応答は別の方法で無視されます。
If the response is a Binding Response, the client SHOULD check the response for a MESSAGE-INTEGRITY attribute. If not present, and the client placed a MESSAGE-INTEGRITY attribute into the request, it MUST discard the response. If present, the client computes the HMAC over the response as described in Section 11.2.8. The key to use depends on the shared secret mechanism. If the STUN Shared Secret Request was used, the key MUST be same as used to compute the MESSAGE- INTEGRITY attribute in the request. If the computed HMAC differs from the one in the response, the client MUST discard the response, and SHOULD alert the user about a possible attack. If the computed HMAC matches the one from the response, processing continues.
応答がBinding Responseであるなら、クライアントSHOULDはMESSAGE-INTEGRITY属性のための応答をチェックします。 プレゼントと、要求へのクライアントの置かれたa MESSAGE-INTEGRITY属性でないなら、それは応答を捨てなければなりません。 存在しているなら、クライアントはセクション11.2.8で説明されるように応答に関してHMACを計算します。 使用するキーは共有秘密キーメカニズムによります。 STUN Shared Secret Requestが使用されたなら、キーは要求におけるMESSAGE- INTEGRITY属性を計算するのに使用されるのと同じであるに違いありません。 計算されたHMACが応答においてものと異なっているなら、クライアントは応答を捨てなければなりません、そして、SHOULDは可能な攻撃に関してユーザを警告します。 計算されたHMACが応答からものに合っているなら、処理は続きます。
Reception of a response (either Binding Error Response or Binding Response) to a Binding Request will terminate retransmissions of that request. However, clients MUST continue to listen for responses to a Binding Request for 10 seconds after the first response. If it
Binding Requestへの応答(Binding Error ResponseかBinding Responseのどちらか)のレセプションはその要求の「再-トランスミッション」を終えるでしょう。 しかしながら、クライアントは、最初の応答の後の10秒間、Binding Requestへの応答の聞こうとし続けなければなりません。 それです。
Rosenberg, et al. Standards Track [Page 18] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[18ページ]RFC3489は2003年3月に気絶させます。
receives any responses in this interval with different message types (Binding Responses and Binding Error Responses, for example) or different MAPPED-ADDRESSes, it is an indication of a possible attack. The client MUST NOT use the MAPPED-ADDRESS from any of the responses it received (either the first or the additional ones), and SHOULD alert the user.
受信、異なったメッセージタイプ(例えば、拘束力があるResponsesとBinding Error Responses)か異なったMAPPED-ADDRESSesがあるこの間隔のどんな応答、それは可能な攻撃のしるしです。 クライアントはそれが受けた応答(1番目か追加もののどちらか)のどれかからMAPPED-ADDRESSを使用してはいけません、そして、SHOULDはユーザを警告します。
Furthermore, if a client receives more than twice as many Binding Responses as the number of Binding Requests it sent, it MUST NOT use the MAPPED-ADDRESS from any of those responses, and SHOULD alert the user about a potential attack.
その上、クライアントがそれが送ったBinding Requestsの数として二度以上多くのBinding Responsesを受け取るなら、それらの応答のどれかからMAPPED-ADDRESSを使用してはいけません、そして、SHOULDは起こり得るかもしれない攻撃に関してユーザを警告します。
If the Binding Response is authenticated, and the MAPPED-ADDRESS was not discarded because of a potential attack, the CLIENT MAY use the MAPPED-ADDRESS and SOURCE-ADDRESS attributes.
Binding Responseが認証されて、MAPPED-ADDRESSが起こり得るかもしれない攻撃のために捨てられなかったなら、CLIENT MAYはMAPPED-ADDRESSとSOURCE-ADDRESS属性を使用します。
10. Use Cases
10. ケースを使用してください。
The rules of Sections 8 and 9 describe exactly how a client and server interact to send requests and get responses. However, they do not dictate how the STUN protocol is used to accomplish useful tasks. That is at the discretion of the client. Here, we provide some useful scenarios for applying STUN.
セクション8と9の規則はクライアントとサーバが要求を送って、応答を得るためにちょうどどう相互作用するかを説明します。 しかしながら、彼らはSTUNプロトコルが役に立つタスクを達成するのにどう使用されるかを書き取りません。 クライアントの裁量にはそれがいます。 ここで、私たちはいくつかの役に立つシナリオをSTUNを適用するのに提供します。
10.1 Discovery Process
10.1 発見プロセス
In this scenario, a user is running a multimedia application which needs to determine which of the following scenarios applies to it:
このシナリオでは、ユーザは以下のシナリオのどれがそれに適用されるかを決定する必要があるマルチメディア応用を実行しています:
o On the open Internet
o 開いているインターネットで
o Firewall that blocks UDP
o UDPを妨げるファイアウォール
o Firewall that allows UDP out, and responses have to come back to
the source of the request (like a symmetric NAT, but no
translation. We call this a symmetric UDP Firewall)
o それが外にUDPを許容して、応答が要求の源に戻るために持っているファイアウォール(左右対称のNATにもかかわらず、どんな翻訳のようにも、そうしません。 私たちは、これを左右対称のUDP Firewallと呼びます。)
o Full-cone NAT
o 完全な円錐のNAT
o Symmetric NAT
o 左右対称のNAT
o Restricted cone or restricted port cone NAT
o 制限された円錐か制限されたポート円錐のNAT
Which of the six scenarios applies can be determined through the flow chart described in Figure 2. The chart refers only to the sequence of Binding Requests; Shared Secret Requests will, of course, be needed to authenticate each Binding Request used in the sequence.
6つのシナリオのどれが適用されるかは図2で説明されたフローチャートで決定できます。 チャートはBinding Requestsの系列だけを示します。 もちろん、共有されたSecret Requestsが系列に使用される各Binding Requestを認証するのが必要でしょう。
Rosenberg, et al. Standards Track [Page 19] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[19ページ]RFC3489は2003年3月に気絶させます。
The flow makes use of three tests. In test I, the client sends a STUN Binding Request to a server, without any flags set in the CHANGE-REQUEST attribute, and without the RESPONSE-ADDRESS attribute. This causes the server to send the response back to the address and port that the request came from. In test II, the client sends a Binding Request with both the "change IP" and "change port" flags from the CHANGE-REQUEST attribute set. In test III, the client sends a Binding Request with only the "change port" flag set.
流れは3つのテストを利用します。 テストIで、クライアントはSTUN Binding Requestをサーバに送ります、CHANGE-REQUEST属性、およびRESPONSE-ADDRESS属性なしで設定された少しも旗なしで。 これで、サーバは要求が来たアドレスとポートに応答を送り返します。 テストIIで、クライアントはCHANGE-REQUEST属性からの旗が設定する「変化IP」と「変化ポート」を両方があるBinding Requestに送ります。 テストIIIで、クライアントは「変化ポート」旗のセットだけがあるBinding Requestを送ります。
The client begins by initiating test I. If this test yields no response, the client knows right away that it is not capable of UDP connectivity. If the test produces a response, the client examines the MAPPED-ADDRESS attribute. If this address and port are the same as the local IP address and port of the socket used to send the request, the client knows that it is not natted. It executes test II.
クライアントはこのテストがもたらすテストI.Ifを開始するのによる応答を全く始めないで、クライアントは、すぐ、それはUDPの接続性ができないのを知っています。 テストが応答を起こすなら、クライアントはMAPPED-ADDRESS属性を調べます。 このアドレスとポートがソケットのローカルアイピーアドレスとポートが以前はよく要求を送ったのと同じであるなら、クライアントは、それがnattedされないのを知っています。 それはテストIIを実行します。
If a response is received, the client knows that it has open access to the Internet (or, at least, its behind a firewall that behaves like a full-cone NAT, but without the translation). If no response is received, the client knows its behind a symmetric UDP firewall.
応答が受け取られているなら、クライアントは、インターネットに開架を持っているのを知っています(完全な円錐のNATのように振る舞いますが、翻訳なしで振る舞うファイアウォールの後ろに少なくとも、それはあります)。 どんな応答も受け取られていないなら、クライアントは、左右対称のUDPファイアウォールの後ろにいるのを知っています。
In the event that the IP address and port of the socket did not match the MAPPED-ADDRESS attribute in the response to test I, the client knows that it is behind a NAT. It performs test II. If a response is received, the client knows that it is behind a full-cone NAT. If no response is received, it performs test I again, but this time, does so to the address and port from the CHANGED-ADDRESS attribute from the response to test I. If the IP address and port returned in the MAPPED-ADDRESS attribute are not the same as the ones from the first test I, the client knows its behind a symmetric NAT. If the address and port are the same, the client is either behind a restricted or port restricted NAT. To make a determination about which one it is behind, the client initiates test III. If a response is received, its behind a restricted NAT, and if no response is received, its behind a port restricted NAT.
ソケットのIPアドレスとポートがIをテストするために応答におけるMAPPED-ADDRESS属性に合っていなかったなら、クライアントは、NATの後ろにそれがあるのを知っています。 それはテストIIを実行します。 応答が受け取られているなら、クライアントは、完全な円錐のNATの後ろにそれがあるのを知っています。 どんな応答も受け取られていないなら、再びテストIを実行しますが、今回、CHANGED-ADDRESSからのアドレスとポートへのそうは、応答からI.をテストするのを結果と考えます。IPアドレスとポートがMAPPED-ADDRESS属性で返したIfが1日からのものがIをテストするのと同じでない、クライアントは左右対称のNATの後ろにいるのを知っています。 アドレスとポートが同じであるなら、クライアントは制限されるかポートの制限されたNATの後ろのどちらかにいます。 それが背中である決断をするように、クライアントはテストIIIを開始します。 応答が受け取られているなら、制限されたNATの後ろでそれを制限します、そして、どんな応答も受け取られていないなら、それはポートの後ろでNATを制限しました。
This procedure yields substantial information about the operating condition of the client application. In the event of multiple NATs between the client and the Internet, the type that is discovered will be the type of the most restrictive NAT between the client and the Internet. The types of NAT, in order of restrictiveness, from most to least, are symmetric, port restricted cone, restricted cone, and full cone.
この手順はクライアントアプリケーションの運転条件のかなりの情報をもたらします。 クライアントとインターネットの間の複数のNATsの場合、発見されるタイプはクライアントとインターネットの間の最も制限しているNATのタイプになるでしょう。 NATのタイプが大部分から最少までの制限することの順に左右対称である、ポートは円錐、制限された円錐、および完全な円錐を制限しました。
Typically, a client will re-do this discovery process periodically to detect changes, or look for inconsistent results. It is important to note that when the discovery process is redone, it should not
クライアントは、通常、変化を検出するために定期的にこの発見プロセスをやり直すか、または矛盾した結果を探すでしょう。 発見プロセスがやり直される場合、やり直されるべきでないことに注意するのは重要です。
Rosenberg, et al. Standards Track [Page 20] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[20ページ]RFC3489は2003年3月に気絶させます。
generally be done from the same local address and port used in the previous discovery process. If the same local address and port are reused, bindings from the previous test may still be in existence, and these will invalidate the results of the test. Using a different local address and port for subsequent tests resolves this problem. An alternative is to wait sufficiently long to be confident that the old bindings have expired (half an hour should more than suffice).
一般に、前の発見プロセスで使用される同じローカルアドレスとポートから、してください。 同じローカルアドレスとポートが再利用されるなら、前のテストからの結合はまだ現存しているかもしれません、そして、これらはテストの結果を無効にするでしょう。 その後のテストに異なったローカルアドレスとポートを使用すると、この問題は解決されます。 代替手段は十分長い間古い結合が期限が切れたと(30分は十分であるというよりもそうするべきです)確信しているのを待つことです。
10.2 Binding Lifetime Discovery
10.2 拘束力がある生涯発見
STUN can also be used to discover the lifetimes of the bindings created by the NAT. In many cases, the client will need to refresh the binding, either through a new STUN request, or an application packet, in order for the application to continue to use the binding. By discovering the binding lifetime, the client can determine how frequently it needs to refresh.
また、NATによって作成された結合の生涯を発見するのにSTUNを使用できます。 多くの場合、クライアントは、結合をリフレッシュする必要があるでしょう、新しいSTUN要求、またはアプリケーションパケットを通して、アプリケーションが、結合を使用し続けるように。 拘束力がある生涯を発見することによって、クライアントは、それが、どれくらい頻繁にリフレッシュする必要であるかを決心できます。
Rosenberg, et al. Standards Track [Page 21] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[21ページ]RFC3489は2003年3月に気絶させます。
+--------+
| Test |
| I |
+--------+
|
|
V
/\ /\
N / \ Y / \ Y +--------+
UDP <-------/Resp\--------->/ IP \------------->| Test |
Blocked \ ? / \Same/ | II |
\ / \? / +--------+
\/ \/ |
| N |
| V
V /\
+--------+ Sym. N / \
| Test | UDP <---/Resp\
| II | Firewall \ ? /
+--------+ \ /
| \/
V |Y
/\ /\ |
Symmetric N / \ +--------+ N / \ V
NAT <--- / IP \<-----| Test |<--- /Resp\ Open
\Same/ | I | \ ? / Internet
\? / +--------+ \ /
\/ \/
| |Y
| |
| V
| Full
| Cone
V /\
+--------+ / \ Y
| Test |------>/Resp\---->Restricted
| III | \ ? /
+--------+ \ /
\/
|N
| Port
+------>Restricted
+--------+ | テスト| | I| +--------+ | | V/\/\N/\Y/\Y+--------+ UDP<。-------/Resp\--------->/IP\------------->| テスト| \?/\同じ/を妨げます。| II| \ / \? / +--------+ \/ \/ | | N| | V V/\+--------+ Sym。 N/\| テスト| UDP<。---/Resp\| II| ファイアウォール、\?/+--------+ \ / | \/V|Y/\/\| 左右対称のN/\+--------+ N/\V NAT<。--- /IP\<。-----| テスト| <、-、-- /Resp\開いている\同じ/| I| \?/インターネット、\?/+--------+ \ / \/ \/ | |Y| | | V| 完全| 円錐のV/\+--------+/\Y| テスト|------>/Resp\----制限された>。| III| \ ? / +--------+ \ / \/ |N| ポート+------制限された>。
Figure 2: Flow for type discovery process
図2: タイプ発見プロセスのための流れ
Rosenberg, et al. Standards Track [Page 22] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[22ページ]RFC3489は2003年3月に気絶させます。
To determine the binding lifetime, the client first sends a Binding Request to the server from a particular socket, X. This creates a binding in the NAT. The response from the server contains a MAPPED- ADDRESS attribute, providing the public address and port on the NAT. Call this Pa and Pp, respectively. The client then starts a timer with a value of T seconds. When this timer fires, the client sends another Binding Request to the server, using the same destination address and port, but from a different socket, Y. This request contains a RESPONSE-ADDRESS address attribute, set to (Pa,Pp). This will create a new binding on the NAT, and cause the STUN server to send a Binding Response that would match the old binding, if it still exists. If the client receives the Binding Response on socket X, it knows that the binding has not expired. If the client receives the Binding Response on socket Y (which is possible if the old binding expired, and the NAT allocated the same public address and port to the new binding), or receives no response at all, it knows that the binding has expired.
拘束力がある生涯を決定するために、クライアントは最初にBinding Requestを特定のソケットからサーバに送って、X.ThisはNATにおける結合を作成します。 NATの場内放送とポートを提供して、サーバからの応答はMAPPED- ADDRESS属性を含んでいます。 それぞれこのPaとPpに電話をしてください。 そして、クライアントはT秒の値からタイマを始動します。 このタイマが撃たれますが、同じ送付先アドレスとポートを使用して、クライアントが別のBinding Requestをサーバに送りますが、Thisが要求するY.が異なったソケットからRESPONSE-ADDRESSアドレス属性を含んでいるときには、(Pa、Pp)にセットしてください。 これで、新しい結合をNATに作成して、STUNサーバは古い結合に合っているBinding Responseを送るでしょう、まだ存在しているなら。 クライアントがソケットXの上にBinding Responseを受け取るなら、それは、結合が期限が切れていないのを知っています。 クライアントがソケットY(古い結合が期限が切れて、NATが同じ場内放送とポートを新しい結合に割り当てたなら、可能です)の上にBinding Responseを受け取るか、または応答を全く受けないなら、それは、結合が期限が切れたのを知っています。
The client can find the value of the binding lifetime by doing a binary search through T, arriving eventually at the value where the response is not received for any timer greater than T, but is received for any timer less than T.
クライアントはTを通した二分探索をすることによって、拘束力がある生涯の値を見つけることができます、結局応答がTよりすばらしいどんなタイマのためにも受け取られませんが、どんなタイマのためにもそれほど受けられない値に到着してTより。
This discovery process takes quite a bit of time, and is something that will typically be run in the background on a device once it boots.
この発見プロセスはかなりの時間がかかります、そして、一度デバイスの上のバックグラウンドに立候補する通常ことになる何かがそれです。ブーツ。
It is possible that the client can get inconsistent results each time this process is run. For example, if the NAT should reboot, or be reset for some reason, the process may discover a lifetime than is shorter than the actual one. For this reason, implementations are encouraged to run the test numerous times, and be prepared to get inconsistent results.
このプロセスが実行されるたびにクライアントが矛盾した結果を得ることができるのは、可能です。 例えば、プロセスはNATがある理由でリブートするか、またはリセットであるなら実際のものより短いというよりも生涯を発見するかもしれません。 この理由で、実装は、テスト多数の時間を述べて、矛盾した結果を得るように準備されるよう奨励されます。
10.3 Binding Acquisition
10.3 拘束力がある獲得
Consider once more the case of a VoIP phone. It used the discovery process above when it started up, to discover its environment. Now, it wants to make a call. As part of the discovery process, it determined that it was behind a full-cone NAT.
もう一度、VoIP電話に関するケースを考えてください。 それはそれが環境を発見するために始動した時の上の発見プロセスを使用しました。 今、それは電話をかけたがっています。 発見プロセスの一部として、それは、完全な円錐のNATの後ろにあったことを決定しました。
Consider further that this phone consists of two logically separated components - a control component that handles signaling, and a media component that handles the audio, video, and RTP [12]. Both are behind the same NAT. Because of this separation of control and media, we wish to minimize the communication required between them. In fact, they may not even run on the same host.
この電話が2つの論理的に切り離されたコンポーネントから成るとさらに考えてください--シグナリングを扱うコントロールの部品、およびオーディオ、ビデオ、およびRTP[12]を扱うメディアコンポーネント。 同じNATの後ろに両方があります。 コントロールとメディアのこの分離のために、それらの間で必要であるコミュニケーションを最小にしたいと思います。 事実上、彼らは同じホストで走ってさえいないかもしれません。
Rosenberg, et al. Standards Track [Page 23] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[23ページ]RFC3489は2003年3月に気絶させます。
In order to make a voice call, the phone needs to obtain an IP address and port that it can place in the call setup message as the destination for receiving audio.
音声通話をするように、電話は、それがオーディオを受けるための目的地として呼び出しセットアップメッセージに置くことができるIPアドレスとポートを入手する必要があります。
To obtain an address, the control component sends a Shared Secret Request to the server, obtains a shared secret, and then sends a Binding Request to the server. No CHANGE-REQUEST attribute is present in the Binding Request, and neither is the RESPONSE-ADDRESS attribute. The Binding Response contains a mapped address. The control component then formulates a second Binding Request. This request contains a RESPONSE-ADDRESS, which is set to the mapped address learned from the previous Binding Response. This Binding Request is passed to the media component, along with the IP address and port of the STUN server. The media component sends the Binding Request. The request goes to the STUN server, which sends the Binding Response back to the control component. The control component receives this, and now has learned an IP address and port that will be routed back to the media component that sent the request.
コントロールの部品は、アドレスを得るために、Shared Secret Requestをサーバに送って、共有秘密キーを得て、次に、Binding Requestをサーバに送ります。どんなCHANGE-REQUEST属性もBinding Requestに存在していません、そして、RESPONSE-ADDRESS属性もそうではありません。 Binding Responseは写像しているアドレスを含んでいます。 そして、コントロールの部品は第2のBinding Requestを定式化します。 この要求はRESPONSE-ADDRESSを含んでいます。(RESPONSE-ADDRESSは前のBinding Responseから学習された写像しているアドレスに用意ができています)。 このBinding Requestはメディアコンポーネントに渡されます、STUNサーバのIPアドレスとポートと共に。メディアコンポーネントはBinding Requestを送ります。 要求はSTUNサーバに行きます。(それは、コントロールの部品にBinding Responseを送り返します)。 コントロールの部品は、これを受けて、現在、要求を送ったメディアコンポーネントに発送して戻されるIPアドレスとポートを学びました。
The client will be able to receive media from anywhere on this mapped address.
クライアントはこの写像しているアドレスでどこからでもメディアを受け取ることができるでしょう。
In the case of silence suppression, there may be periods where the client receives no media. In this case, the UDP bindings could timeout (UDP bindings in NATs are typically short; 30 seconds is common). To deal with this, the application can periodically retransmit the query in order to keep the binding fresh.
沈黙抑圧の場合には、期間がクライアントがメディアを全く受け取らないところにあるかもしれません。 この場合、UDP結合はタイムアウト(NATsでのUDP結合は通常短いです; 30秒は一般的である)をそうすることができました。 これで、アプリケーションが結合を新鮮に保つために定期的に質問を再送できるという取引に。
It is possible that both participants in the multimedia session are behind the same NAT. In that case, both will repeat this procedure above, and both will obtain public address bindings. When one sends media to the other, the media is routed to the NAT, and then turns right back around to come back into the enterprise, where it is translated to the private address of the recipient. This is not particularly efficient, and unfortunately, does not work in many commercial NATs. In such cases, the clients may need to retry using private addresses.
マルチメディアセッションの両方の関係者が同じNATの後ろにいるのは、可能です。 その場合、両方が上のこの手順を繰り返すでしょう、そして、場内放送結合を得るでしょう。 1つがメディアをもう片方に送ると、メディアは、企業に戻るためにNATに発送されて、正しい後部を変えます。(そこでは、それが受取人のプライベート・アドレスに翻訳されます)。 これは、残念ながら、特に効率的でなく、また多くの商業NATsで働いていません。 そのような場合、クライアントは、プライベート・アドレスを使用することで再試行する必要があるかもしれません。
11. Protocol Details
11. プロトコルの詳細
This section presents the detailed encoding of a STUN message.
このセクションはSTUNメッセージの詳細なコード化を提示します。
STUN is a request-response protocol. Clients send a request, and the server sends a response. There are two requests, Binding Request, and Shared Secret Request. The response to a Binding Request can
STUNは要求応答プロトコルです。 クライアントは要求を送ります、そして、サーバは応答を送ります。 2つの要求、Binding Request、およびShared Secret Requestがあります。 Binding Requestへの応答はそうすることができます。
Rosenberg, et al. Standards Track [Page 24] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[24ページ]RFC3489は2003年3月に気絶させます。
either be the Binding Response or Binding Error Response. The response to a Shared Secret Request can either be a Shared Secret Response or a Shared Secret Error Response.
Binding ResponseかBinding Error Responseのどちらかになってください。 Shared Secret Requestへの応答は、Shared Secret ResponseかShared Secret Error Responseのどちらかであるかもしれません。
STUN messages are encoded using binary fields. All integer fields are carried in network byte order, that is, most significant byte (octet) first. This byte order is commonly known as big-endian. The transmission order is described in detail in Appendix B of RFC 791 [6]. Unless otherwise noted, numeric constants are in decimal (base 10).
STUNメッセージは、2進の分野を使用することでコード化されます。 すべての整数野原が最初に、すなわち、ネットワークバイトオーダー、最も重要なバイト(八重奏)で運ばれます。 このバイトオーダーはビッグエンディアンとして一般的に知られています。 トランスミッション命令はRFC791[6]のAppendix Bで詳細に説明されます。 別の方法で注意されない場合、小数(ベース10)には数値定数があります。
11.1 Message Header
11.1 メッセージヘッダー
All STUN messages consist of a 20 byte header:
すべてのSTUNメッセージが20バイトのヘッダーから成ります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージタイプを気絶させてください。| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transaction ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
トランザクション..ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Message Types can take on the following values:
Message Typesは以下の値を呈することができます:
0x0001 : Binding Request
0x0101 : Binding Response
0x0111 : Binding Error Response
0x0002 : Shared Secret Request
0x0102 : Shared Secret Response
0x0112 : Shared Secret Error Response
0×0001: 拘束力がある要求0x0101: 拘束力がある応答0x0111: 拘束力がある誤り応答0x0002: 共有秘密キー要求0x0102: 共有秘密キー応答0x0112: 共有秘密キー誤り応答
The message length is the count, in bytes, of the size of the message, not including the 20 byte header.
メッセージ長は20バイトのヘッダーを含んでいるのではなく、メッセージのサイズのバイトがカウントです。
The transaction ID is a 128 bit identifier. It also serves as salt to randomize the request and the response. All responses carry the same identifier as the request they correspond to.
トランザクションIDは128ビットの識別子です。 また、それは要求と応答をランダマイズする塩として機能します。 すべての応答がそれらが相当する要求と同じ識別子を運びます。
Rosenberg, et al. Standards Track [Page 25] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[25ページ]RFC3489は2003年3月に気絶させます。
11.2 Message Attributes
11.2 メッセージ属性
After the header are 0 or more attributes. Each attribute is TLV encoded, with a 16 bit type, 16 bit length, and variable value:
ヘッダーの後に、0つ以上の属性があります。 各属性は16ビット型、16ビットの長さ、および可変値でコード化されたTLVです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following types are defined:
以下のタイプは定義されます:
0x0001: MAPPED-ADDRESS 0x0002: RESPONSE-ADDRESS 0x0003: CHANGE-REQUEST 0x0004: SOURCE-ADDRESS 0x0005: CHANGED-ADDRESS 0x0006: USERNAME 0x0007: PASSWORD 0x0008: MESSAGE-INTEGRITY 0x0009: ERROR-CODE 0x000a: UNKNOWN-ATTRIBUTES 0x000b: REFLECTED-FROM
0×0001: 写像しているアドレス0×0002: 応答アドレス0×0003: 変更要求0x0004: ソースアドレス0x0005: 変えられたアドレス0×0006: ユーザ名0x0007: パスワード0x0008: メッセージの保全0x0009: エラーコード0x000a: 未知の属性0x000b: 反射にされる
To allow future revisions of this specification to add new attributes if needed, the attribute space is divided into optional and mandatory ones. Attributes with values greater than 0x7fff are optional, which means that the message can be processed by the client or server even though the attribute is not understood. Attributes with values less than or equal to 0x7fff are mandatory to understand, which means that the client or server cannot process the message unless it understands the attribute.
この仕様の今後の改正が新しい属性を加えるのを許容するために、必要であるなら、属性スペースは任意の、そして、義務的なものに分割されます。 値が0x7fffより大きい属性は任意です(属性が理解されていませんが、クライアントかサーバでメッセージを処理できることを意味します)。 値の、より0x7fffがある属性は、分かるために義務的です(属性を理解していない場合クライアントかサーバがメッセージを処理できないことを意味します)。
The MESSAGE-INTEGRITY attribute MUST be the last attribute within a message. Any attributes that are known, but are not supposed to be present in a message (MAPPED-ADDRESS in a request, for example) MUST be ignored.
MESSAGE-INTEGRITY属性はメッセージの中の最後の属性であるに違いありません。 どんな属性も、知っていますが、メッセージ(例えば、要求におけるMAPPED-ADDRESS)でのプレゼントを無視しなければならないということであるべきではありません。
Table 2 indicates which attributes are present in which messages. An M indicates that inclusion of the attribute in the message is mandatory, O means its optional, C means it's conditional based on some other aspect of the message, and N/A means that the attribute is not applicable to that message type.
テーブル2は、どの属性がどのメッセージで存在しているかを示します。 Mは、メッセージでの属性の包含が義務的であることを示します、そして、Oは、それが任意であることを意味します、そして、Cは、それがメッセージのある他の局面に基づいて条件付きであることを意味します、そして、N/Aは属性がそのメッセージタイプに適切でないことを意味します。
Rosenberg, et al. Standards Track [Page 26] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[26ページ]RFC3489は2003年3月に気絶させます。
Binding Shared Shared Shared
Binding Binding Error Secret Secret Secret
Att. Req. Resp. Resp. Req. Resp. Error
Resp.
_____________________________________________________________________
MAPPED-ADDRESS N/A M N/A N/A N/A N/A
RESPONSE-ADDRESS O N/A N/A N/A N/A N/A
CHANGE-REQUEST O N/A N/A N/A N/A N/A
SOURCE-ADDRESS N/A M N/A N/A N/A N/A
CHANGED-ADDRESS N/A M N/A N/A N/A N/A
USERNAME O N/A N/A N/A M N/A
PASSWORD N/A N/A N/A N/A M N/A
MESSAGE-INTEGRITY O O N/A N/A N/A N/A
ERROR-CODE N/A N/A M N/A N/A M
UNKNOWN-ATTRIBUTES N/A N/A C N/A N/A C
REFLECTED-FROM N/A C N/A N/A N/A N/A
共有された共有された共有された拘束力がある拘束力がある誤り秘密の秘密の秘密のAttを縛ります。 Req。 Resp。 Resp。 Req。 Resp。 誤りResp。 _____________________________________________________________________ 写像しているアドレス、なし、M、なし、なし、なし、なし、なし、なし、なし、なし、なし、Oが変更要求Oであると応答で扱ってください、なし、なし、なし、なし、なし、なし、Mをソースで扱ってください、なし、なし、なし、なし、変えられたアドレス、なし、M、なし、なし、なし、なし、ユーザ名、○ なし、なし、なし、M、なし、パスワード、なし、なし、なし、なし、M、なし、メッセージの保全O O、なし、なし、なし、なし、なし、なし、Mを誤りでコード化してください、なし、なし、Mがなし、なし、Cを未知で結果と考える、なし、なし、C、反射している、なし、C、なし、なし、なし、なし。
Table 2: Summary of Attributes
テーブル2: 属性の概要
The length refers to the length of the value element, expressed as an unsigned integral number of bytes.
長さは未署名の不可欠のバイト数として表された価値要素の長さについて言及します。
11.2.1 MAPPED-ADDRESS
11.2.1 写像しているアドレス
The MAPPED-ADDRESS attribute indicates the mapped IP address and port. It consists of an eight bit address family, and a sixteen bit port, followed by a fixed length value representing the IP address.
MAPPED-ADDRESS属性は写像しているIPアドレスとポートを示します。 それはIPアドレスを表す固定長値があとに続いた8ビット・アドレスファミリー、および16ビットのポートから成ります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Family | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x x x x x x x| ファミリー| ポート| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The port is a network byte ordered representation of the mapped port. The address family is always 0x01, corresponding to IPv4. The first 8 bits of the MAPPED-ADDRESS are ignored, for the purposes of aligning parameters on natural boundaries. The IPv4 address is 32 bits.
ポートは写像しているポートの表現が注文されたネットワークバイトです。 いつもアドレスファミリーはIPv4に対応する0×01です。 MAPPED-ADDRESSの最初の8ビットは固有の境界に関するパラメタを並べる目的のために無視されます。 IPv4アドレスは32ビットです。
11.2.2 RESPONSE-ADDRESS
11.2.2 応答アドレス
The RESPONSE-ADDRESS attribute indicates where the response to a Binding Request should be sent. Its syntax is identical to MAPPED- ADDRESS.
RESPONSE-ADDRESS属性は、Binding Requestへの応答がどこに送られるべきであるかを示します。 構文はMAPPED- ADDRESSと同じです。
Rosenberg, et al. Standards Track [Page 27] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[27ページ]RFC3489は2003年3月に気絶させます。
11.2.3 CHANGED-ADDRESS
11.2.3 変えられたアドレス
The CHANGED-ADDRESS attribute indicates the IP address and port where responses would have been sent from if the "change IP" and "change port" flags had been set in the CHANGE-REQUEST attribute of the Binding Request. The attribute is always present in a Binding Response, independent of the value of the flags. Its syntax is identical to MAPPED-ADDRESS.
CHANGED-ADDRESS属性は、「変化IP」と「変化ポート」が弛むなら応答を送るIPアドレスとポートがBinding RequestのCHANGE-REQUEST属性で設定されたのを示します。 属性は旗の値の如何にかかわらずBinding Responseにいつも存在しています。 構文はMAPPED-ADDRESSと同じです。
11.2.4 CHANGE-REQUEST
11.2.4 変更要求
The CHANGE-REQUEST attribute is used by the client to request that the server use a different address and/or port when sending the response. The attribute is 32 bits long, although only two bits (A and B) are used:
CHANGE-REQUEST属性は、応答を送るとき、サーバが異なったアドレス、そして/または、ポートを使用するよう要求するのにクライアントによって使用されます。 2ビット(AとB)だけが使用されていますが、属性は長さ32ビットです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A B 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B0あたり0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of the flags is:
旗の意味は以下の通りです。
A: This is the "change IP" flag. If true, it requests the server
to send the Binding Response with a different IP address than the
one the Binding Request was received on.
A: これは「変化IP」旗です。 本当であるなら、それは、Binding Requestが受け取られたものと異なったIPアドレスでBinding Responseを送るようサーバに要求します。
B: This is the "change port" flag. If true, it requests the
server to send the Binding Response with a different port than the
one the Binding Request was received on.
B: これは「変化ポート」旗です。 本当であるなら、それは、Binding Requestが受け取られたものより異なったポートがあるBinding Responseを送るようサーバに要求します。
11.2.5 SOURCE-ADDRESS
11.2.5 ソースアドレス
The SOURCE-ADDRESS attribute is present in Binding Responses. It indicates the source IP address and port that the server is sending the response from. Its syntax is identical to that of MAPPED- ADDRESS.
SOURCE-ADDRESS属性はBinding Responsesに存在しています。 それはサーバが応答を送るソースIPアドレスとポートを示します。 構文はMAPPED- ADDRESSのものと同じです。
11.2.6 USERNAME
11.2.6 ユーザ名
The USERNAME attribute is used for message integrity. It serves as a means to identify the shared secret used in the message integrity check. The USERNAME is always present in a Shared Secret Response, along with the PASSWORD. It is optionally present in a Binding Request when message integrity is used.
USERNAME属性はメッセージの保全に使用されます。 メッセージの保全に使用される共有秘密キーを特定する手段がチェックするようにそれは役立ちます。 USERNAMEはPASSWORDに伴うShared Secret Responseにいつも存在しています。 メッセージの保全が使用されているとき、それはBinding Requestに任意に存在しています。
Rosenberg, et al. Standards Track [Page 28] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[28ページ]RFC3489は2003年3月に気絶させます。
The value of USERNAME is a variable length opaque value. Its length MUST be a multiple of 4 (measured in bytes) in order to guarantee alignment of attributes on word boundaries.
USERNAMEの値は可変長の不透明な値です。 長さは、語境界における属性の整列を保証する4(バイトで、測定される)の倍数でなければなりません。
11.2.7 PASSWORD
11.2.7 パスワード
The PASSWORD attribute is used in Shared Secret Responses. It is always present in a Shared Secret Response, along with the USERNAME.
PASSWORD属性はShared Secret Responsesで使用されます。 それはUSERNAMEに伴うShared Secret Responseにいつも存在しています。
The value of PASSWORD is a variable length value that is to be used as a shared secret. Its length MUST be a multiple of 4 (measured in bytes) in order to guarantee alignment of attributes on word boundaries.
PASSWORDの値は共有秘密キーとして使用されることになっている可変長値です。 長さは、語境界における属性の整列を保証する4(バイトで、測定される)の倍数でなければなりません。
11.2.8 MESSAGE-INTEGRITY
11.2.8 メッセージの保全
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [13] of the STUN message. It can be present in Binding Requests or Binding Responses. Since it uses the SHA1 hash, the HMAC will be 20 bytes. The text used as input to HMAC is the STUN message, including the header, up to and including the attribute preceding the MESSAGE- INTEGRITY attribute. That text is then padded with zeroes so as to be a multiple of 64 bytes. As a result, the MESSAGE-INTEGRITY attribute MUST be the last attribute in any STUN message. The key used as input to HMAC depends on the context.
MESSAGE-INTEGRITY属性はSTUNメッセージのHMAC-SHA1[13]を含んでいます。 それはBinding RequestsかBinding Responsesに存在している場合があります。 SHA1ハッシュを使用するので、HMACは20バイトになるでしょう。 HMACに入力されるように使用されるテキストはSTUNメッセージです、ヘッダーを含んでいて、MESSAGE- INTEGRITY属性に先行する属性を含めて。 そして、そのテキストは、64バイトの倍数になるようにゼロで水増しされます。 その結果、MESSAGE-INTEGRITY属性はどんなSTUNメッセージでも最後の属性であるに違いありません。 HMACに入力されるように使用されるキーは文脈によります。
11.2.9 ERROR-CODE
11.2.9 エラーコード
The ERROR-CODE attribute is present in the Binding Error Response and Shared Secret Error Response. It is a numeric value in the range of 100 to 699 plus a textual reason phrase encoded in UTF-8, and is consistent in its code assignments and semantics with SIP [10] and HTTP [15]. The reason phrase is meant for user consumption, and can be anything appropriate for the response code. The lengths of the reason phrases MUST be a multiple of 4 (measured in bytes). This can be accomplished by added spaces to the end of the text, if necessary. Recommended reason phrases for the defined response codes are presented below.
ERROR-CODE属性はBinding Error ResponseとShared Secret Error Responseに存在しています。 それは、100〜699の範囲とUTF-8でコード化された原文の理由句の数値であり、そのコード課題と意味論でSIP[10]とHTTP[15]と一致しています。 理由句は、ユーザ消費で意味されて、応答コードに、何か適切なものであるかもしれません。 理由句の長さは4(バイトで、測定される)の倍数であるに違いありません。 必要なら、加えられた空間はテキストの終わりまでこれを達成できます。 定義された応答コードのためのお勧めの理由句は以下に提示されます。
To facilitate processing, the class of the error code (the hundreds digit) is encoded separately from the rest of the code.
処理するのを容易にするために、エラーコード(数百ケタ)のクラスは別々にコードの残りからコード化されます。
Rosenberg, et al. Standards Track [Page 29] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[29ページ]RFC3489は2003年3月に気絶させます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |クラス| 数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 句(変数)を推論してください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The class represents the hundreds digit of the response code. The value MUST be between 1 and 6. The number represents the response code modulo 100, and its value MUST be between 0 and 99.
クラスは応答コードの数百ケタを表します。 値は、1〜6でなければなりません。 値は、0〜数が応答コード法100を表して、99でなければなりません。
The following response codes, along with their recommended reason phrases (in brackets) are defined at this time:
以下の応答は句(括弧の)がこのとき定義されるそれらのお勧めの理由と共に以下をコード化します。
400 (Bad Request): The request was malformed. The client should not
retry the request without modification from the previous
attempt.
400 (悪い要求): 要求は奇形でした。 クライアントは前の試みから変更なしで要求を再試行するべきではありません。
401 (Unauthorized): The Binding Request did not contain a MESSAGE-
INTEGRITY attribute.
401 (権限のない): Binding RequestはMESSAGE- INTEGRITY属性を含みませんでした。
420 (Unknown Attribute): The server did not understand a mandatory
attribute in the request.
420 (未知の属性): サーバは要求における義務的な属性を理解していませんでした。
430 (Stale Credentials): The Binding Request did contain a MESSAGE-
INTEGRITY attribute, but it used a shared secret that has
expired. The client should obtain a new shared secret and try
again.
430(聞き古した資格証明書): Binding RequestはMESSAGE- INTEGRITY属性を含みましたが、それは期限が切れた共有秘密キーを使用しました。 クライアントは、新しい共有秘密キーを得て、再試行するべきです。
431 (Integrity Check Failure): The Binding Request contained a
MESSAGE-INTEGRITY attribute, but the HMAC failed verification.
This could be a sign of a potential attack, or client
implementation error.
431 (保全チェック失敗): Binding RequestはMESSAGE-INTEGRITY属性を含みましたが、HMACは検証に失敗しました。 これは起こり得るかもしれない攻撃、またはクライアント実装誤りのサインであるかもしれません。
432 (Missing Username): The Binding Request contained a MESSAGE-
INTEGRITY attribute, but not a USERNAME attribute. Both must be
present for integrity checks.
432(なくなったユーザ名): Binding RequestはUSERNAME属性ではなく、MESSAGE- INTEGRITY属性を含みました。 両方が保全チェックのために存在していなければなりません。
433 (Use TLS): The Shared Secret request has to be sent over TLS, but
was not received over TLS.
433(TLSを使用します): Shared Secret要求をTLSの上に送らなければなりませんでしたが、TLSの上に受け取りませんでした。
500 (Server Error): The server has suffered a temporary error. The
client should try again.
500 (サーバ誤り): サーバは一時的な誤りを受けました。 クライアントは再試行するべきです。
600 (Global Failure:) The server is refusing to fulfill the request.
The client should not retry.
600 (グローバルなFailure:) サーバは、要求を実現させるのを拒否しています。 クライアントは再試行するべきではありません。
Rosenberg, et al. Standards Track [Page 30] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[30ページ]RFC3489は2003年3月に気絶させます。
11.2.10 UNKNOWN-ATTRIBUTES
11.2.10 未知の属性
The UNKNOWN-ATTRIBUTES attribute is present only in a Binding Error Response or Shared Secret Error Response when the response code in the ERROR-CODE attribute is 420.
ERROR-CODE属性における応答コードが420であるときに、UNKNOWN-ATTRIBUTES属性はBinding Error ResponseかShared Secret Error Responseだけに存在しています。
The attribute contains a list of 16 bit values, each of which represents an attribute type that was not understood by the server. If the number of unknown attributes is an odd number, one of the attributes MUST be repeated in the list, so that the total length of the list is a multiple of 4 bytes.
未知の属性の数が奇数であるなら、リストで属性の1つを繰り返さなければなりません、リストの全長が4バイトの倍数であるように。属性は16ビットの値のリストを含んでいます。それはそれぞれサーバに解釈されなかった属性タイプの代理をします。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 1 Type | Attribute 2 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 3 Type | Attribute 4 Type ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性1タイプ| 属性2タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性3タイプ| 4タイプを結果と考えてください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11.2.11 REFLECTED-FROM
11.2.11 反射しています。
The REFLECTED-FROM attribute is present only in Binding Responses, when the Binding Request contained a RESPONSE-ADDRESS attribute. The attribute contains the identity (in terms of IP address) of the source where the request came from. Its purpose is to provide traceability, so that a STUN server cannot be used as a reflector for denial-of-service attacks.
Binding RequestがRESPONSE-ADDRESS属性を含んだとき、REFLECTED-FROM属性はBinding Responsesだけに存在しています。 属性は要求が来たソースのアイデンティティ(IPアドレスによる)を含んでいます。 目的はサービス不能攻撃に反射鏡としてSTUNサーバを使用できないように追随性を提供することです。
Its syntax is identical to the MAPPED-ADDRESS attribute.
構文はMAPPED-ADDRESS属性と同じです。
12. Security Considerations
12. セキュリティ問題
12.1 Attacks on STUN
12.1が攻撃する、気絶させる。
Generally speaking, attacks on STUN can be classified into denial of service attacks and eavesdropping attacks. Denial of service attacks can be launched against a STUN server itself, or against other elements using the STUN protocol.
概して、STUNに対する攻撃は、サービス不能攻撃に分類されて、攻撃を盗み聞くことができます。 STUNサーバ自体に対して、または、STUNプロトコルを使用する他の要素に対してサービス不能攻撃に着手できます。
STUN servers create state through the Shared Secret Request mechanism. To prevent being swamped with traffic, a STUN server SHOULD limit the number of simultaneous TLS connections it will hold open by dropping an existing connection when a new connection request arrives (based on an Least Recently Used (LRU) policy, for example). Similarly, it SHOULD limit the number of shared secrets it will store, in the event that the server is storing the shared secrets.
STUNサーバはShared Secret Requestメカニズムを通して状態を創設します。 トラフィック、STUNサーバSHOULD限界で浸されるのを防ぐために、それが保持する同時のTLS接続の数は新しい接続要求が到着するとき(Least Recently Used(LRU)方針に基づいて例えば)既存の接続を下げることによって、開きます。 同様である、それ、SHOULDはそれが保存する共有秘密キーの数を制限します、サーバが共有秘密キーを保存している場合。
Rosenberg, et al. Standards Track [Page 31] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[31ページ]RFC3489は2003年3月に気絶させます。
The attacks of greater interest are those in which the STUN server and client are used to launch DOS attacks against other entities, including the client itself.
より一層の関心の攻撃はSTUNサーバとクライアントが他の実体に対してDOS攻撃に着手するのに使用されるそれらです、クライアント自身を含んでいて。
Many of the attacks require the attacker to generate a response to a legitimate STUN request, in order to provide the client with a faked MAPPED-ADDRESS. The attacks that can be launched using such a technique include:
攻撃の多くが、攻撃者が正統のSTUN要求への応答を生成するのを必要とします、見せかけられたMAPPED-ADDRESSをクライアントに提供するために。 そのようなテクニックを使用することで着手できる攻撃は:
12.1.1 Attack I: DDOS Against a Target
12.1.1 Iを攻撃してください: 目標に対するDDOS
In this case, the attacker provides a large number of clients with the same faked MAPPED-ADDRESS that points to the intended target. This will trick all the STUN clients into thinking that their addresses are equal to that of the target. The clients then hand out that address in order to receive traffic on it (for example, in SIP or H.323 messages). However, all of that traffic becomes focused at the intended target. The attack can provide substantial amplification, especially when used with clients that are using STUN to enable multimedia applications.
この場合、攻撃者は意図している目標を示すのと同じ見せかけられたMAPPED-ADDRESSを多くのクライアントに提供します。 これは、すべてのSTUNクライアントが、彼らのアドレスが目標のものと等しいと考えるようにだますでしょう。 そして、クライアントは、それ(例えばSIPかH.323メッセージで)でトラフィックを受けるためにそのアドレスを与えます。 しかしながら、そのトラフィックのすべてが意図している目標で集中するようになります。 特にマルチメディア応用を可能にするのにSTUNを使用しているクライアントと共に使用されると、攻撃はかなりの増幅を提供できます。
12.1.2 Attack II: Silencing a Client
12.1.2 IIを攻撃してください: クライアントを黙らせます。
In this attack, the attacker seeks to deny a client access to services enabled by STUN (for example, a client using STUN to enable SIP-based multimedia traffic). To do that, the attacker provides that client with a faked MAPPED-ADDRESS. The MAPPED-ADDRESS it provides is an IP address that routes to nowhere. As a result, the client won't receive any of the packets it expects to receive when it hands out the MAPPED-ADDRESS.
この攻撃では、攻撃者はSTUN(例えば、SIPベースのマルチメディアトラフィックを可能にするのにSTUNを使用しているクライアント)によって可能にされたサービスへのクライアントアクセスを拒絶しようとします。 それをするために、攻撃者は見せかけられたMAPPED-ADDRESSをそのクライアントに提供します。 それが提供するMAPPED-ADDRESSはそれがどこにも発送しないIPアドレスです。 MAPPED-ADDRESSを与えるとき、その結果、クライアントはそれが受けると予想するパケットのいずれも受けないでしょう。
This exploitation is not very interesting for the attacker. It impacts a single client, which is frequently not the desired target. Moreover, any attacker that can mount the attack could also deny service to the client by other means, such as preventing the client from receiving any response from the STUN server, or even a DHCP server.
この攻略は攻撃者によってそれほどおもしろくはありません。 それは独身のクライアントに影響を与えます(頻繁に必要な目標ではありません)。 そのうえ、また、攻撃を仕掛けることができるどんな攻撃者も他の手段でクライアントに対するサービスを否定する場合がありました、クライアントがSTUNサーバ、またはDHCPサーバからさえどんな応答も受けるのを防ぐのなどように。
12.1.3 Attack III: Assuming the Identity of a Client
12.1.3 IIIを攻撃してください: クライアントのアイデンティティを仮定します。
This attack is similar to attack II. However, the faked MAPPED- ADDRESS points to the attacker themself. This allows the attacker to receive traffic which was destined for the client.
この攻撃は、IIを攻撃するために同様です。 しかしながら、見せかけられたMAPPED- ADDRESSは自分たちで攻撃者を示します。 これで、攻撃者はクライアントのために運命づけられたトラフィックを受け取ることができます。
Rosenberg, et al. Standards Track [Page 32] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[32ページ]RFC3489は2003年3月に気絶させます。
12.1.4 Attack IV: Eavesdropping
12.1.4 IVを攻撃してください: 盗聴
In this attack, the attacker forces the client to use a MAPPED- ADDRESS that routes to itself. It then forwards any packets it receives to the client. This attack would allow the attacker to observe all packets sent to the client. However, in order to launch the attack, the attacker must have already been able to observe packets from the client to the STUN server. In most cases (such as when the attack is launched from an access network), this means that the attacker could already observe packets sent to the client. This attack is, as a result, only useful for observing traffic by attackers on the path from the client to the STUN server, but not generally on the path of packets being routed towards the client.
この攻撃では、攻撃者はクライアントに強制的にそれがそれ自体に発送するMAPPED- ADDRESSを使用させます。 そして、それはクライアントに受けるどんなパケットも進めます。 この攻撃で、攻撃者はクライアントに送られたすべてのパケットを観察できるでしょう。 しかしながら、攻撃に着手するために、攻撃者はクライアントからSTUNサーバまで既にパケットを観察できたに違いありません。多くの場合(攻撃がアクセスネットワークから着手される時としてのそのようなもの)、これは、攻撃者が既にクライアントに送られたパケットを観察できたことを意味します。 この攻撃は、その結果単に経路で攻撃者でクライアントからSTUNサーバまでトラフィックを観測することの役に立ちますが、一般にクライアントに向かって発送されるパケットの経路で役に立つというわけではありません。
12.2 Launching the Attacks
12.2 攻撃に着手すること。
It is important to note that attacks of this nature (injecting responses with fake MAPPED-ADDRESSes) require that the attacker be capable of eavesdropping requests sent from the client to the server (or to act as a MITM for such attacks). This is because STUN requests contain a transaction identifier, selected by the client, which is random with 128 bits of entropy. The server echoes this value in the response, and the client ignores any responses that don't have a matching transaction ID. Therefore, in order for an attacker to provide a faked response that is accepted by the client, the attacker needs to know what the transaction ID in the request was. The large amount of randomness, combined with the need to know when the client sends a request, precludes attacks that involve guessing the transaction ID.
この種(にせのMAPPED-ADDRESSesを応答に注射する)の攻撃が、攻撃者はクライアントからサーバに送られた(そのような攻撃のためのMITMとして機能するように)盗聴要求ができるのを必要とすることに注意するのは重要です。 これはSTUN要求がクライアントによって選択されたエントロピーの128ビットで無作為のトランザクション識別子を含んでいるからです。 サーバは応答におけるこの値を反響します、そして、クライアントはマッチング取引IDを持っていないどんな応答も無視します。 したがって、攻撃者がクライアントによって受け入れられる見せかけられた応答を提供するように、攻撃者は、要求におけるトランザクションIDが何であったかを知る必要があります。 多量のクライアントがいつ要求を送るかを知る必要性に結合した偶発性がトランザクションIDを推測することを伴う攻撃を排除します。
Since all of the above attacks rely on this one primitive - injecting a response with a faked MAPPED-ADDRESS - preventing the attacks is accomplished by preventing this one operation. To prevent it, we need to consider the various ways in which it can be accomplished. There are several:
以来、見せかけられたMAPPED-ADDRESSを応答に注射して、上の攻撃のすべてが原始的にこれを当てにします--攻撃を防ぐのは、この1つの操作を防ぐことによって、実行されます。 それを防ぐために、私たちは、それを達成できる様々な方法を考える必要があります。 数個があります:
12.2.1 Approach I: Compromise a Legitimate STUN Server
12.2.1 Iにアプローチしてください: aが認知する感染はサーバを気絶させます。
In this attack, the attacker compromises a legitimate STUN server through a virus or Trojan horse. Presumably, this would allow the attacker to take over the STUN server, and control the types of responses it generates.
この攻撃では、攻撃者はウイルスかトロイの木馬を通して正統のSTUNサーバに感染します。 おそらく、攻撃者は、これで、STUNサーバを引き継いで、それが生成する応答のタイプを監督するでしょう。
Compromise of a STUN server can also lead to discovery of open ports. Knowledge of an open port creates an opportunity for DoS attacks on those ports (or DDoS attacks if the traversed NAT is a full cone NAT). Discovering open ports is already fairly trivial using port probing, so this does not represent a major threat.
また、STUNサーバの感染は開港の発見につながることができます。 開港に関する知識はそれらのポートに対するDoS攻撃の機会を作成します(DDoSは横断されたNATが完全な円錐のNATであるなら攻撃します)。 開港を発見するのがポートの調べを使用することでかなり既に些細であるので、これは大きな脅威を表しません。
Rosenberg, et al. Standards Track [Page 33] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[33ページ]RFC3489は2003年3月に気絶させます。
12.2.2 Approach II: DNS Attacks
12.2.2 IIにアプローチしてください: DNS攻撃
STUN servers are discovered using DNS SRV records. If an attacker can compromise the DNS, it can inject fake records which map a domain name to the IP address of a STUN server run by the attacker. This will allow it to inject fake responses to launch any of the attacks above.
STUNサーバはDNS SRV記録を使用していると発見されます。 攻撃者がDNSに感染することができるなら、それは攻撃者によって実行されたSTUNサーバのIPアドレスにドメイン名を写像するにせの記録を注入できます。 これで、それは、上の攻撃のどれかに着手するためににせの応答を注入できるでしょう。
12.2.3 Approach III: Rogue Router or NAT
12.2.3 IIIにアプローチしてください: 凶暴なルータかNAT
Rather than compromise the STUN server, an attacker can cause a STUN server to generate responses with the wrong MAPPED-ADDRESS by compromising a router or NAT on the path from the client to the STUN server. When the STUN request passes through the rogue router or NAT, it rewrites the source address of the packet to be that of the desired MAPPED-ADDRESS. This address cannot be arbitrary. If the attacker is on the public Internet (that is, there are no NATs between it and the STUN server), and the attacker doesn't modify the STUN request, the address has to have the property that packets sent from the STUN server to that address would route through the compromised router. This is because the STUN server will send the responses back to the source address of the request. With a modified source address, the only way they can reach the client is if the compromised router directs them there. If the attacker is on the public Internet, but they can modify the STUN request, they can insert a RESPONSE-ADDRESS attribute into the request, containing the actual source address of the STUN request. This will cause the server to send the response to the client, independent of the source address the STUN server sees. This gives the attacker the ability to forge an arbitrary source address when it forwards the STUN request.
むしろ、それは、必要なMAPPED-ADDRESSのものになるようにSTUNサーバ、攻撃者がSTUNサーバに応答を生成させることができる感染がクライアントからSTUNサーバまでの経路のルータかNATに. いつに感染するかによる間違ったMAPPED-ADDRESSと共に凶暴なルータかNATを通り抜けるよりSTUNが、要求するパケットのソースアドレスを書き直します。 このアドレスは任意であるはずがありません。 攻撃者が公共のインターネットにいて(すなわち、それとSTUNサーバの間には、NATsが全くありません)、攻撃者がSTUN要求を変更しないなら、アドレスでは、そのパケットがSTUNサーバから発信したアドレスが感染しているルータを通して発送する特性がなければなりません。 これはSTUNサーバが要求のソースアドレスに応答を送り返すからです。 変更されたソースアドレスで、クライアントに届くことができる唯一の方法は感染しているルータがそこでそれらを指示するかどうかということです。 攻撃者が公共のインターネットにいますが、彼らがSTUN要求を変更できるなら、彼らはRESPONSE-ADDRESS属性を要求に挿入できます、STUN要求の実際のソースアドレスを含んでいて。 これで、サーバは応答をクライアントに送るでしょう、STUNサーバが見るソースアドレスの如何にかかわらず。 これはSTUN要求を転送するとき任意のソースアドレスを偽造する能力を攻撃者に与えます。
If the attacker is on a private network (that is, there are NATs between it and the STUN server), the attacker will not be able to force the server to generate arbitrary MAPPED-ADRESSes in responses. They will only be able force the STUN server to generate MAPPED- ADDRESSes which route to the private network. This is because the NAT between the attacker and the STUN server will rewrite the source address of the STUN request, mapping it to a public address that routes to the private network. Because of this, the attacker can only force the server to generate faked mapped addresses that route to the private network. Unfortunately, it is possible that a low quality NAT would be willing to map an allocated public address to another public address (as opposed to an internal private address), in which case the attacker could forge the source address in a STUN request to be an arbitrary public address. This kind of behavior from NATs does appear to be rare.
攻撃者が私設のネットワークの一員(すなわち、それとSTUNサーバの間には、NATsがある)であるなら、サーバに攻撃者に応答で任意のMAPPED-ADRESSesを生成させることができないでしょう。 それらはできる力がMAPPED- ADDRESSesがどのルートであるかと私設のネットワークに生成するSTUNサーバであった場合にだけそうするでしょう。 これは攻撃者とSTUNサーバの間のNATがSTUN要求のソースアドレスを書き直すからです、それが私設のネットワークに発送する場内放送にそれを写像して。 これのために、攻撃者はサーバに見せかけられた写像しているアドレスがそのルートであると私設のネットワークに強制的に生成させることができるだけです。 残念ながら、低い上質のNATが、別の場内放送(内部のプライベート・アドレスと対照的に)に割り当てられた場内放送を写像しても構わないと思っているのが、可能である、その場合、攻撃者は任意の場内放送であるというSTUN要求におけるソースアドレスを偽造できました。 NATsからのこの種類の振舞いはまれであるように見えます。
Rosenberg, et al. Standards Track [Page 34] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[34ページ]RFC3489は2003年3月に気絶させます。
12.2.4 Approach IV: MITM
12.2.4 IVにアプローチしてください: MITM
As an alternative to approach III, if the attacker can place an element on the path from the client to the server, the element can act as a man-in-the-middle. In that case, it can intercept a STUN request, and generate a STUN response directly with any desired value of the MAPPED-ADDRESS field. Alternatively, it can forward the STUN request to the server (after potential modification), receive the response, and forward it to the client. When forwarding the request and response, this attack is subject to the same limitations on the MAPPED-ADDRESS described in Section 12.2.3.
アプローチIIIに代わる手段として、攻撃者がクライアントからサーバまで経路に要素を置くことができるなら、要素は中央の男性として作用できます。 その場合、それは、直接MAPPED-ADDRESS分野のどんな目標値でもSTUN要求を妨害して、STUN応答を生成することができます。 あるいはまた、それは、クライアントにサーバ(潜在的変更の後の)にSTUN要求を転送して、応答を受けて、それを送ることができます。 要求と応答を転送するとき、この攻撃はセクション12.2.3で説明されたMAPPED-ADDRESSで同じ制限を受けることがあります。
12.2.5 Approach V: Response Injection Plus DoS
12.2.5 Vにアプローチしてください: 応答注射とDoS
In this approach, the attacker does not need to be a MITM (as in approaches III and IV). Rather, it only needs to be able to eavesdrop onto a network segment that carries STUN requests. This is easily done in multiple access networks such as ethernet or unprotected 802.11. To inject the fake response, the attacker listens on the network for a STUN request. When it sees one, it simultaneously launches a DoS attack on the STUN server, and generates its own STUN response with the desired MAPPED-ADDRESS value. The STUN response generated by the attacker will reach the client, and the DoS attack against the server is aimed at preventing the legitimate response from the server from reaching the client. Arguably, the attacker can do without the DoS attack on the server, so long as the faked response beats the real response back to the client, and the client uses the first response, and ignores the second (even though it's different).
このアプローチでは、攻撃者は、MITMである必要がありません(アプローチIIIとIVのように)。 むしろ、それは、STUN要求を運ぶネットワークセグメントに盗み聞くことができる必要があるだけです。 イーサネットか保護のない802.11などの複数のアクセスネットワークで容易にこれをします。 にせの応答を注入するために、攻撃者はSTUN要求のためにネットワークで聴きます。 1つを見るとき、それは、同時にSTUNサーバでDoS攻撃に着手して、必要なMAPPED-ADDRESS値でそれ自身のSTUN応答を生成します。 攻撃者によって生成されたSTUN応答はクライアントに届くでしょう、そして、サーバからの正統の応答がクライアントに届くのを防ぐのをサーバに対するDoS攻撃は目的とされます。 論証上、攻撃者は進行中のDoS攻撃なしでサーバができます、見せかけられた応答がクライアントへの本当の応答後部を打って、クライアントが最初の応答を使用して、2番目を無視する(それは異なっていますが)限り。
12.2.6 Approach VI: Duplication
12.2.6 VIにアプローチしてください: 複製
This approach is similar to approach V. The attacker listens on the network for a STUN request. When it sees it, it generates its own STUN request towards the server. This STUN request is identical to the one it saw, but with a spoofed source IP address. The spoofed address is equal to the one that the attacker desires to have placed in the MAPPED-ADDRESS of the STUN response. In fact, the attacker generates a flood of such packets. The STUN server will receive the one original request, plus a flood of duplicate fake ones. It generates responses to all of them. If the flood is sufficiently large for the responses to congest routers or some other equipment, there is a reasonable probability that the one real response is lost (along with many of the faked ones), but the net result is that only the faked responses are received by the STUN client. These responses are all identical and all contain the MAPPED-ADDRESS that the attacker wanted the client to use.
このアプローチは、攻撃者がSTUN要求のためにネットワークで聴くV.にアプローチするために同様です。 それを見るとき、それはそれ自身のSTUN要求をサーバに向かって生成します。このSTUN要求は、それが見たものと同じですが、偽造しているソースIPアドレスで同じです。 偽造しているアドレスは攻撃者がSTUN応答のMAPPED-ADDRESSに置いたことを望んでいるものと等しいです。 事実上、攻撃者はそのようなパケットの洪水を生成します。 STUNサーバは1つのオリジナルの要求を受け取るでしょう、そして、写しの洪水はものを見せかけます。 それはそれらのすべてへの応答を生成します。 洪水が応答がルータかある他の設備を充血させることができるくらい大きいなら、1つの本当の応答が無くなるという(見せかけられたものの多くに伴う)妥当な確率がありますが、最終結果は見せかけられた応答だけがSTUNクライアントによって受けられるということです。 これらの応答はすべて、すべて同じであり、攻撃者が、クライアントに使用して欲しかったMAPPED-ADDRESSを含んでいます。
Rosenberg, et al. Standards Track [Page 35] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[35ページ]RFC3489は2003年3月に気絶させます。
The flood of duplicate packets is not needed (that is, only one faked request is sent), so long as the faked response beats the real response back to the client, and the client uses the first response, and ignores the second (even though it's different).
写しパケットの洪水は必要ではありません(すなわち、1つの見せかけられた要求だけを送ります)、見せかけられた応答がクライアントへの本当の応答後部を打って、クライアントが最初の応答を使用して、2番目を無視する(それは異なっていますが)限り。
Note that, in this approach, launching a DoS attack against the STUN server or the IP network, to prevent the valid response from being sent or received, is problematic. The attacker needs the STUN server to be available to handle its own request. Due to the periodic retransmissions of the request from the client, this leaves a very tiny window of opportunity. The attacker must start the DoS attack immediately after the actual request from the client, causing the correct response to be discarded, and then cease the DoS attack in order to send its own request, all before the next retransmission from the client. Due to the close spacing of the retransmits (100ms to a few seconds), this is very difficult to do.
有効回答を送るか、または受け取るのを防ぐためにSTUNサーバかIPネットワークに対してDoS攻撃に着手するのがこのアプローチで問題が多いことに注意してください。 攻撃者は、STUNサーバがそれ自身の要求を扱うために利用可能である必要があります。 クライアントからの要求の周期的な「再-トランスミッション」のため、これは機会の非常に小さい窓を出ます。 攻撃者は、それ自身の要求を送るために正しい応答が捨てられることを引き起こして、クライアントからの実際の要求直後DoS攻撃を始めて、次に、DoS攻撃をやめなければなりません、クライアントからの次の「再-トランスミッション」の前で。 近いスペース、(数秒までの100ms)を再送する、これはするのが非常に難しいです。
Besides DoS attacks, there may be other ways to prevent the actual request from the client from reaching the server. Layer 2 manipulations, for example, might be able to accomplish it.
DoS攻撃以外に、クライアントからの実際の要求がサーバに達するのを防ぐ他の方法があるかもしれません。例えば、層の2操作はそれを達成できるかもしれません。
Fortunately, Approach IV is subject to the same limitations documented in Section 12.2.3, which limit the range of MAPPED- ADDRESSes the attacker can cause the STUN server to generate.
幸い、Approach IVはセクション12.2.3に記録された同じ制限を受けることがあります。.3は攻撃者がSTUNサーバに生成させることができるMAPPED- ADDRESSesの範囲を制限します。
12.3 Countermeasures
12.3の対策
STUN provides mechanisms to counter the approaches described above, and additional, non-STUN techniques can be used as well.
STUNは上で説明されたアプローチに対抗するためにメカニズムを提供します、そして、また、追加していて、非STUNのテクニックは使用できます。
First off, it is RECOMMENDED that networks with STUN clients implement ingress source filtering (RFC 2827 [7]). This is particularly important for the NATs themselves. As Section 12.2.3 explains, NATs which do not perform this check can be used as "reflectors" in DDoS attacks. Most NATs do perform this check as a default mode of operation. We strongly advise people that purchase NATs to ensure that this capability is present and enabled.
オフであることで、最初に、STUNクライアントとのネットワークが、イングレスがソースフィルタリングであると実装するのは、RECOMMENDEDです。(RFC2827[7])。 NATs自身には、これは特に重要です。 セクション12.2.3が説明するように、DDoSの「反射鏡」が攻撃されるとき、このチェックを実行しないNATsは使用できます。 ほとんどのNATsがデフォルト運転モードとしてこのチェックを実行します。 私たちは、NATsを購入する人々が、この能力が現在であって可能にされるのを保証するように強くアドバイスします。
Secondly, it is RECOMMENDED that STUN servers be run on hosts dedicated to STUN, with all UDP and TCP ports disabled except for the STUN ports. This is to prevent viruses and Trojan horses from infecting STUN servers, in order to prevent their compromise. This helps mitigate Approach I (Section 12.2.1).
第二に、STUNサーバがSTUNに専念したホストで実行されるのは、RECOMMENDEDです、STUNポートを除いて、障害があるすべてのUDPとTCPポートで。 これは、ウイルスとトロイの木馬がそれらの感染を防ぐためにSTUNサーバを感染させるのを防ぐためのものです。 これは、Approach I(セクション12.2.1)を緩和するのを助けます。
Thirdly, to prevent the DNS attack of Section 12.2.2, Section 9.2 recommends that the client verify the credentials provided by the server with the name used in the DNS lookup.
三番目に、セクション12.2.2のDNS攻撃を防ぐために、セクション9.2は、クライアントがサーバによってDNSルックアップに使用される名前に提供された資格証明書について確かめることを勧めます。
Rosenberg, et al. Standards Track [Page 36] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[36ページ]RFC3489は2003年3月に気絶させます。
Finally, all of the attacks above rely on the client taking the mapped address it learned from STUN, and using it in application layer protocols. If encryption and message integrity are provided within those protocols, the eavesdropping and identity assumption attacks can be prevented. As such, applications that make use of STUN addresses in application protocols SHOULD use integrity and encryption, even if a SHOULD level strength is not specified for that protocol. For example, multimedia applications using STUN addresses to receive RTP traffic would use secure RTP [16].
最終的に、それがSTUNから学んだ写像しているアドレスを取って、応用層プロトコルにそれを使用することで上の攻撃のすべてがクライアントに頼ります。 それらのプロトコルの中で暗号化とメッセージの保全を提供するなら、盗聴とアイデンティティ仮定攻撃を防ぐことができます。 そういうものとして、アプリケーション・プロトコルSHOULDのSTUNアドレスを利用するアプリケーションが保全と暗号化を使用します、SHOULDの平らな強さがそのプロトコルに指定されないでも。 例えば、RTPトラフィックを受けるのにSTUNアドレスを使用するマルチメディア応用が安全なRTP[16]を使用するでしょう。
The above three techniques are non-STUN mechanisms. STUN itself provides several countermeasures.
上の3つのテクニックが非STUNメカニズムです。STUN自身はいくつかの対策を提供します。
Approaches IV (Section 12.2.4), when generating the response locally, and V (Section 12.2.5) require an attacker to generate a faked response. This attack is prevented using the message integrity mechanism provided in STUN, described in Section 8.1.
局所的に応答を生成するときのアプローチIV(セクション12.2.4)、およびV(セクション12.2.5)は、攻撃者が見せかけられた応答を生成するのを必要とします。 この攻撃はセクション8.1で説明されたSTUNに提供されたメッセージの保全メカニズムを使用するのが防がれます。
Approaches III (Section 12.2.3) IV (Section 12.2.4), when using the relaying technique, and VI (12.2.6), however, are not preventable through server signatures. Both approaches are most potent when the attacker can modify the request, inserting a RESPONSE-ADDRESS that routes to the client. Fortunately, such modifications are preventable using the message integrity techniques described in Section 9.3. However, these three approaches are still functional when the attacker modifies nothing but the source address of the STUN request. Sadly, this is the one thing that cannot be protected through cryptographic means, as this is the change that STUN itself is seeking to detect and report. It is therefore an inherent weakness in NAT, and not fixable in STUN. To help mitigate these attacks, Section 9.4 provides several heuristics for the client to follow. The client looks for inconsistent or extra responses, both of which are signs of the attacks described above. However, these heuristics are just that - heuristics, and cannot be guaranteed to prevent attacks. The heuristics appear to prevent the attacks as we know how to launch them today. Implementors should stay posted for information on new heuristics that might be required in the future. Such information will be distributed on the IETF MIDCOM mailing list, midcom@ietf.org.
リレーのテクニック、およびVIを使用するとき、III(セクション12.2.3)IV(セクション12.2.4)にアプローチする、(12.2、.6、)、しかしながら、サーバ署名で、予防可能ではありません。 攻撃者が要求を変更できるとき、それがクライアントに発送するRESPONSE-ADDRESSを挿入して、両方のアプローチは最も強力です。 幸い、そのような変更は、セクション9.3で説明されたメッセージの保全のテクニックを使用することで予防可能です。 しかしながら、攻撃者がSTUN要求のソースアドレスだけを変更するとき、これらの3つのアプローチがまだ機能的です。 悲しげに、これは暗号の手段で保護できない、1つのものです、これがSTUN自身が検出して、報告しようとしている変化であるので。 したがって、それはNAT、およびSTUNの定着性でないところの固有の弱点です。 これらの攻撃を緩和するのを助けるなら、クライアントが続くように、セクション9.4はいくつかの発見的教授法を提供します。 クライアントは矛盾したか付加的な応答を探します。その両方が上で説明された攻撃のサインです。 しかしながら、これらの発見的教授法はまさしくそれです--、発見的教授法、攻撃を防ぐために保証できません。 発見的教授法は私たちが今日それらを始める方法を知っているとき攻撃を防ぐように見えます。 作成者は将来必要であるかもしれない新しい発見的教授法の情報のために掲示されていたままであるべきです。 そのような情報はIETF MIDCOMメーリングリスト、 midcom@ietf.org で分配されるでしょう。
12.4 Residual Threats
12.4 残りの脅威
None of the countermeasures listed above can prevent the attacks described in Section 12.2.3 if the attacker is in the appropriate network paths. Specifically, consider the case in which the attacker wishes to convince client C that it has address V. The attacker needs to have a network element on the path between A and the server (in order to modify the request) and on the path between the server
上に記載された対策のいずれも攻撃者が適切なネットワーク経路にいるならセクション12.2.3で説明された攻撃を防ぐことができません。 明確に、攻撃者がAとサーバ(要求を変更するために)の間の経路とサーバの間の経路のネットワーク要素を持つためにそれには攻撃者が必要とするアドレスV.があるとクライアントCに納得させたがっている場合を考えてください。
Rosenberg, et al. Standards Track [Page 37] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[37ページ]RFC3489は2003年3月に気絶させます。
and V so that it can forward the response to C. Furthermore, if there is a NAT between the attacker and the server, V must also be behind the same NAT. In such a situation, the attacker can either gain access to all the application-layer traffic or mount the DDOS attack described in Section 12.1.1. Note that any host which exists in the correct topological relationship can be DDOSed. It need not be using STUN.
そして、攻撃者とサーバ、Vの間には、NATがあればそれがC.Furthermoreへの応答を送ることができるそうがそうしなければならないVも同じNATの後ろのそうです。 そのような状況で、攻撃者はセクション12.1.1で説明されたDDOS攻撃をすべての応用層トラフィックかマウントへのアクセスに獲得できます。 正しい位相的な関係で存在するどんなホストもDDOSedであるかもしれないことに注意してください。 それはSTUNを使用する必要はありません。
13. IANA Considerations
13. IANA問題
STUN cannot be extended. Changes to the protocol are made through a standards track revision of this specification. As a result, no IANA registries are needed. Any future extensions will establish any needed registries.
STUNを広げることができません。 プロトコルへの変更はこの仕様の標準化過程改正で行われます。 その結果、IANA登録は全く必要ではありません。 どんな今後の拡大もどんな必要な登録も確立するでしょう。
14. IAB Considerations
14. IAB問題
The IAB has studied the problem of "Unilateral Self Address Fixing", which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism (RFC 3424 [17]). STUN is an example of a protocol that performs this type of function. The IAB has mandated that any protocols developed for this purpose document a specific set of considerations. This section meets those requirements.
IABは「一方的な自己アドレス修理」の問題を研究しました。(修理はクライアントが協力的なプロトコル反射メカニズムを通した別の分野のNATの反対側に関するアドレスを決定するのを試みる一般的なプロセスです)。(RFC3424[17])。 STUNはこのタイプの関数を実行するプロトコルに関する例です。 IABは、どんなプロトコルもこの目的ドキュメントのために問題の特定のセットを発展させたのを強制しました。 このセクションはそれらの必要条件を満たします。
14.1 Problem Definition
14.1 問題定義
From RFC 3424 [17], any UNSAF proposal must provide:
RFC3424[17]から、どんなUNSAF提案も提供されなければなりません:
Precise definition of a specific, limited-scope problem that is to
be solved with the UNSAF proposal. A short term fix should not be
generalized to solve other problems; this is why "short term fixes
usually aren't".
UNSAF提案で解決されることになっている特定の、そして、限られた範囲の問題の厳密な定義。 他の問題を解決するために短期間フィックスを一般化するべきではありません。 これは「通常、短期間フィックスがない」理由です。
The specific problems being solved by STUN are:
STUNによって解決されていることにおける特定の問題は以下の通りです。
o Provide a means for a client to detect the presence of one or more
NATs between it and a server run by a service provider on the
public Internet. The purpose of such detection is to determine
additional steps that might be necessary in order to receive
service from that particular provider.
o 公共のインターネットのサービスプロバイダーによって実行されたそれとサーバの間にクライアントが1NATsの存在を検出する手段を提供してください。 そのような検出の目的はその特定のプロバイダーからサービスを受けるのに必要であるかもしれない追加ステップを決定することです。
o Provide a means for a client to detect the presence of one or more
NATs between it and another client, where the second client is
reachable from the first, but it is not known whether the second
client resides on the public Internet.
o クライアントがそれと別のクライアントの間の1NATsの存在を検出する手段を提供してください。2番目のクライアントは1日から届いていますが、そこでは、2番目のクライアントが公共のインターネットに住んでいるかどうかは知られていません。
Rosenberg, et al. Standards Track [Page 38] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[38ページ]RFC3489は2003年3月に気絶させます。
o Provide a means for a client to obtain an address on the public
Internet from a non-symmetric NAT, for the express purpose of
receiving incoming UDP traffic from another host, targeted to that
address.
o クライアントが非左右対称のNATから公共のインターネットに関するアドレスを得る手段を提供してください、そのアドレスに狙う別のホストから入って来るUDPトラフィックを受けるはっきりとした目的のために。
STUN does not address TCP, either incoming or outgoing, and does not address outgoing UDP communications.
STUNは入って来るか出発しているTCPを扱わないで、また送信するUDPコミュニケーションを扱いません。
14.2 Exit Strategy
14.2 撤退戦略
From [17], any UNSAF proposal must provide:
[17]から、どんなUNSAF提案も提供されなければなりません:
Description of an exit strategy/transition plan. The better short
term fixes are the ones that will naturally see less and less use
as the appropriate technology is deployed.
撤退戦略/変遷プランの記述。 より良い短期間フィックスは適正技術が配布されるとき自然にますます少ない使用を見るものです。
STUN comes with its own built in exit strategy. This strategy is the detection operation that is performed as a precursor to the actual UNSAF address-fixing operation. This discovery operation, documented in Section 10.1, attempts to discover the existence of, and type of, any NATS between the client and the service provider network. Whilst the detection of the specific type of NAT may be brittle, the discovery of the existence of NAT is itself quite robust. As NATs are phased out through the deployment of IPv6, the discovery operation will return immediately with the result that there is no NAT, and no further operations are required. Indeed, the discovery operation itself can be used to help motivate deployment of IPv6; if a user detects a NAT between themselves and the public Internet, they can call up their access provider and complain about it.
それ自身のものが撤退戦略で建てられている状態で、STUNは来ます。 この戦略は先駆としてアドレスを固定する実際のUNSAF操作に実行される検出操作です。 セクション10.1に記録されたこの発見操作は、どんなNATSもクライアントとサービスプロバイダーネットワークの間で存在を発見して、タイプされるのを試みます。 NATの特定のタイプの検出はもろいかもしれませんが、NATの存在の発見はそれ自体でかなり体力を要します。 NATsがIPv6の展開で段階的に廃止されるとき、操作がすぐにその結果、そこに戻るという発見はNATではありません、そして、さらなる操作は全く必要ではありません。 本当に、IPv6の展開を動機づけるのを助けるのに発見操作自体を使用できます。 ユーザが自分たちと公共のインターネットの間のNATを検出するなら、彼らは、それらのアクセスプロバイダを呼び出して、それに関して不平を言うことができます。
STUN can also help facilitate the introduction of midcom. As midcom-capable NATs are deployed, applications will, instead of using STUN (which also resides at the application layer), first allocate an address binding using midcom. However, it is a well-known limitation of midcom that it only works when the agent knows the middleboxes through which its traffic will flow. Once bindings have been allocated from those middleboxes, a STUN detection procedure can validate that there are no additional middleboxes on the path from the public Internet to the client. If this is the case, the application can continue operation using the address bindings allocated from midcom. If it is not the case, STUN provides a mechanism for self-address fixing through the remaining midcom- unaware middleboxes. Thus, STUN provides a way to help transition to full midcom-aware networks.
また、STUNは、midcomの導入を容易にするのを助けることができます。 midcomできるNATsが配布されるとき、STUN(また、応用層に住んでいる)を使用することの代わりに、アプリケーションは、最初に、midcomを使用することでアドレス結合を割り当てるでしょう。 しかしながら、エージェントがトラフィックが流れるmiddleboxesを知っているとき、それは扱うだけであるmidcomのよく知られる限界です。 それらのmiddleboxesから結合をいったん割り当てると、公共のインターネットからクライアントまでどんな追加middleboxesも経路にないSTUN検出手順は有効にされることができます。 これがそうであるなら、アプリケーションは、midcomから割り当てられたアドレス結合を使用することで操作を続けることができます。 それがケースでないなら、STUNは、残っているmidcom気づかないmiddleboxesを通して修理しながら、自己アドレスにメカニズムを提供します。 したがって、STUNは完全なmidcom意識しているネットワークへの変遷を助ける方法を提供します。
Rosenberg, et al. Standards Track [Page 39] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[39ページ]RFC3489は2003年3月に気絶させます。
14.3 Brittleness Introduced by STUN
もろさが導入した14.3は気絶させられます。
From [17], any UNSAF proposal must provide:
[17]から、どんなUNSAF提案も提供されなければなりません:
Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data at
multiple network layers create more dependencies, increase
debugging challenges, and make it harder to transition.
より「もろく」システムを表すかもしれない特定の問題の議論。 例えば、複数のネットワーク層にデータを使用することを伴うアプローチで、より多くの依存を引き起こして、デバッグ挑戦を増強して、それは変遷により困難になります。
STUN introduces brittleness into the system in several ways:
STUNはいくつかの方法でシステムにもろさを取り入れます:
o The discovery process assumes a certain classification of devices
based on their treatment of UDP. There could be other types of
NATs that are deployed that would not fit into one of these molds.
Therefore, future NATs may not be properly detected by STUN. STUN
clients (but not servers) would need to change to accommodate
that.
o 発見プロセスはUDPに関する彼らの処理に基づくデバイスのある分類を仮定します。 これらの型の1つに収まらない配布されるNATsの他のタイプがあるかもしれません。 したがって、将来のNATsはSTUNによって適切に検出されないかもしれません。 STUNクライアント(しかし、サーバでない)は、それを収容するために変化する必要があるでしょう。
o The binding acquisition usage of STUN does not work for all NAT
types. It will work for any application for full cone NATs only.
For restricted cone and port restricted cone NAT, it will work for
some applications depending on the application. Application
specific processing will generally be needed. For symmetric NATs,
the binding acquisition will not yield a usable address. The
tight dependency on the specific type of NAT makes the protocol
brittle.
o STUNの拘束力がある獲得使用法はすべてのNATタイプのために利きません。 それは完全な円錐のNATsだけのどんなアプリケーションのためにも働くでしょう。 制限された円錐とポートに関しては、制限された円錐のNATであり、それはアプリケーションによるいくつかのアプリケーションのために働くでしょう。 一般に、アプリケーションの特定の処理が必要でしょう。 左右対称のNATsに関しては、拘束力がある獲得は使用可能なアドレスをもたらさないでしょう。 NATの特定のタイプにおけるきつい依存で、プロトコルはもろくなります。
o STUN assumes that the server exists on the public Internet. If
the server is located in another private address realm, the user
may or may not be able to use its discovered address to
communicate with other users. There is no way to detect such a
condition.
o STUNは、サーバが公共のインターネットに存在すると仮定します。 サーバが別のプライベート・アドレス分野に位置しているなら、ユーザは、他のユーザとコミュニケートするのに発見されたアドレスを使用できるかもしれません。 そのような状態を検出する方法が全くありません。
o The bindings allocated from the NAT need to be continuously
refreshed. Since the timeouts for these bindings is very
implementation specific, the refresh interval cannot easily be
determined. When the binding is not being actively used to
receive traffic, but to wait for an incoming message, the binding
refresh will needlessly consume network bandwidth.
o NATから割り当てられた結合は、絶え間なくリフレッシュされる必要があります。 間隔をリフレッシュしてください。以来これらの結合のためのタイムアウトがまさしくその実装詳細である、容易に断固としているはずがありません。 結合が活発に使用されていないとき、トラフィックを受けますが、入力メッセージ、結合のための待ちにリフレッシュするために、不必要にネットワーク回線容量を消費するでしょう。
o The use of the STUN server as an additional network element
introduces another point of potential security attack. These
attacks are largely prevented by the security measures provided by
STUN, but not entirely.
o 追加ネットワーク要素としてのSTUNサーバの使用は潜在的セキュリティー攻撃のもう1ポイントを紹介します。 これらの攻撃は、STUNによって提供された安全策で主に防がれますが、完全に防がれるというわけではありません。
Rosenberg, et al. Standards Track [Page 40] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[40ページ]RFC3489は2003年3月に気絶させます。
o The use of the STUN server as an additional network element
introduces another point of failure. If the client cannot locate
a STUN server, or if the server should be unavailable due to
failure, the application cannot function.
o 追加ネットワーク要素としてのSTUNサーバの使用は失敗のもう1ポイントを紹介します。 クライアントがSTUNサーバの場所を見つけることができないか、またはサーバが失敗で入手できません、アプリケーションが機能できないということであるなら。
o The use of STUN to discover address bindings will result in an
increase in latency for applications. For example, a Voice over
IP application will see an increase of call setup delays equal to
at least one RTT to the STUN server.
o アドレス結合を発見するSTUNの使用はアプリケーションのための潜在の増加をもたらすでしょう。 例えば、ボイス・オーバー IPアプリケーションは、呼び出しセットアップ遅れの増加が少なくとも1RTTと等しいのをSTUNサーバに見るでしょう。
o The discovery of binding lifetimes is prone to error. It assumes
that the same lifetime will exist for all bindings. This may not
be true if the NAT uses dynamic binding lifetimes to handle
overload, or if the NAT itself reboots during the discovery
process.
o 拘束力がある生涯の発見は誤りに傾向があります。 それは、同じ寿命がすべての結合のために存在すると仮定します。 NATがオーバーロードを扱うためにダイナミックな拘束力がある生涯を費やすか、またはNAT自体が発見プロセスの間、リブートされるなら、これは本当でないかもしれません。
o STUN imposes some restrictions on the network topologies for
proper operation. If client A obtains an address from STUN server
X, and sends it to client B, B may not be able to send to A using
that IP address. The address will not work if any of the
following is true:
o STUNは適切な操作のためにいくつかの制限をネットワークtopologiesに課します。 クライアントAがSTUNサーバXからアドレスを得て、クライアントBにそれを送るなら、Bは、そのIPアドレスを使用することでAに発信できないかもしれません。 以下のどれかが本当であるなら、アドレスは働かないでしょう:
- The STUN server is not in an address realm that is a common
ancestor (topologically) of both clients A and B. For example,
consider client A and B, both of which have residential NAT
devices. Both devices connect them to their cable operators,
but both clients have different providers. Each provider has a
NAT in front of their entire network, connecting it to the
public Internet. If the STUN server used by A is in A's cable
operator's network, an address obtained by it will not be
usable by B. The STUN server must be in the network which is a
common ancestor to both - in this case, the public Internet.
- STUNサーバがクライアントAとB.Forの例の両方の一般的な先祖(位相的である)であり、クライアントAとBを考えて、それの両方が住宅のNATデバイスを持っているアドレス分野にありません。 両方のデバイスは彼らのケーブルオペレータにそれらを接続しますが、両方のクライアントには、異なったプロバイダーがあります。 公共のインターネットにそれを関連づけて、各プロバイダーはそれらの全体のネットワークの正面にNATを持っています。 AのケーブルオペレータのネットワークにAによって使用されるSTUNサーバがあるなら、それによって得られたアドレスはB.で使用可能にならないでしょう。この場合両方への一般的な先祖であるネットワークにはSTUNサーバがあるに違いありません、公共のインターネット。
- The STUN server is in an address realm that is a common
ancestor to both clients, but both clients are behind the same
NAT connecting to that address realm. For example, if the two
clients in the previous example had the same cable operator,
that cable operator had a single NAT connecting their network
to the public Internet, and the STUN server was on the public
Internet, the address obtained by A would not be usable by B.
That is because some NATs will not accept an internal packet
sent to a public IP address which is mapped back to an internal
address. To deal with this, additional protocol mechanisms or
configuration parameters need to be introduced which detect
this case.
- STUNサーバが両方のクライアントの一般的な先祖であるアドレス分野にありますが、両方のクライアントは、そのアドレス分野に接続しながら、同じNATの後ろにいます。 例えば、前の例の2人のクライアントには同じケーブルオペレータがいて、そのケーブルオペレータに彼らのネットワークを公共のインターネットに接続するただ一つのNATがあって、STUNサーバが公共のインターネットにあるなら、Aによって得られたアドレスはB.で使用可能でないでしょうに。いくつかのNATsが内部のアドレスに写像して戻される公共のIPアドレスに送られた内部のパケットを受け入れないので、Thatはそうです。 本件を検出するこれ、追加議定書メカニズムまたは導入されるべき設定パラメータの必要性に対処するために。
Rosenberg, et al. Standards Track [Page 41] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[41ページ]RFC3489は2003年3月に気絶させます。
o Most significantly, STUN introduces potential security threats
which cannot be eliminated. This specification describes
heuristics that can be used to mitigate the problem, but it is
provably unsolvable given what STUN is trying to accomplish.
These security problems are described fully in Section 12.
o 最もかなり、STUNは排除できない潜在的軍事的脅威を導入します。 この仕様は問題を緩和するのに使用できる発見的教授法を説明しますが、それはどんなSTUNが達成しようとしている当然のことを証明可能に「非-解決でき」することです。 これらの警備上の問題はセクション12で完全に説明されます。
14.4 Requirements for a Long Term Solution
14.4 長期ソリューションのための要件
From [17], any UNSAF proposal must provide:
[17]から、どんなUNSAF提案も提供されなければなりません:
Identify requirements for longer term, sound technical solutions
-- contribute to the process of finding the right longer term
solution.
より長い期間、健全な技術的解決法のための要件を特定してください--ソリューションという正しいより長い期間を見つけるプロセスに貢献してください。
Our experience with STUN has led to the following requirements for a long term solution to the NAT problem:
STUNの私たちの経験はNAT問題への長期解決のために以下の要件につながりました:
Requests for bindings and control of other resources in a NAT
need to be explicit. Much of the brittleness in STUN derives from
its guessing at the parameters of the NAT, rather than telling the
NAT what parameters to use.
NATにおける、他のリソースの結合とコントロールを求める要求は、明白である必要があります。 どんなパラメタを使用したらよいかをNATに言うよりSTUNのもろさの多くが推測にNATのパラメタでむしろ由来しています。
Control needs to be "in-band". There are far too many scenarios
in which the client will not know about the location of
middleboxes ahead of time. Instead, control of such boxes needs
to occur in-band, traveling along the same path as the data will
itself travel. This guarantees that the right set of middleboxes
are controlled. This is only true for first-party controls;
third-party controls are best handled using the midcom framework.
コントロールは、「バンド」である必要があります。 クライアントが早めにmiddleboxesの位置に関して知らないはるかにあまりに多くのシナリオがあります。 代わりに、そのような箱のコントロールは、バンドで起こる必要があって、データが旅行するので同じ経路に沿ってそれ自体で旅行するのは旅行します。 これは、middleboxesの右のセットが制御されているのを保証します。 最初に、パーティーコントロールだけに、これは本当です。 midcomフレームワークを使用することで第三者コントロールを扱うのは最も良いです。
Control needs to be limited. Users will need to communicate
through NATs which are outside of their administrative control.
In order for providers to be willing to deploy NATs which can be
controlled by users in different domains, the scope of such
controls needs to be extremely limited - typically, allocating a
binding to reach the address where the control packets are coming
from.
コントロールは、制限される必要があります。 ユーザは、NATsを通してどれが彼らの運営管理コントロールの外にあるかを伝える必要があるでしょう。 プロバイダーが、ユーザが異なったドメインで制御できるNATsを配布しても構わないと思っているように、そのようなコントロールの範囲は、通常、非常に制限されている必要があります、コントロールパケットが来る予定であるアドレスに達するように結合を割り当てて。
Simplicity is Paramount. The control protocol will need to be
implement in very simple clients. The servers will need to
support extremely high loads. The protocol will need to be
extremely robust, being the precursor to a host of application
protocols. As such, simplicity is key.
簡単さはパラマウントです。 制御プロトコルは、非常に純真なクライアントの道具である必要があるでしょう。 サーバは、非常に高い負荷をサポートする必要があるでしょう。 多くのアプリケーション・プロトコルへの先駆でありプロトコルは、非常に強健である必要があるでしょう。 そういうものとして、簡単さは主要です。
Rosenberg, et al. Standards Track [Page 42] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[42ページ]RFC3489は2003年3月に気絶させます。
14.5 Issues with Existing NAPT Boxes
14.5 既存のNAPT箱の問題
From [17], any UNSAF proposal must provide:
[17]から、どんなUNSAF提案も提供されなければなりません:
Discussion of the impact of the noted practical issues with
existing, deployed NA[P]Ts and experience reports.
有名な実用的な問題の影響の議論は存在、配布しているNA[P]t、および経験で報告します。
Several of the practical issues with STUN involve future proofing - breaking the protocol when new NAT types get deployed. Fortunately, this is not an issue at the current time, since most of the deployed NATs are of the types assumed by STUN. The primary usage STUN has found is in the area of VoIP, to facilitate allocation of addresses for receiving RTP [12] traffic. In that application, the periodic keepalives are provided by the RTP traffic itself. However, several practical problems arise for RTP. First, RTP assumes that RTCP traffic is on a port one higher than the RTP traffic. This pairing property cannot be guaranteed through NATs that are not directly controllable. As a result, RTCP traffic may not be properly received. Protocol extensions to SDP have been proposed which mitigate this by allowing the client to signal a different port for RTCP [18]. However, there will be interoperability problems for some time.
新しいNATタイプが配布されるとき、プロトコルを破って、STUNのいくつかの実用的な問題が将来の証にかかわります。 幸い、これは現在の時間の問題ではありません、STUNによって思われたタイプには配布しているNATsの大部分があるので。 RTP[12]トラフィックを受けるためのアドレスの配分を容易にするために、STUNが見つけたプライマリ用法はVoIPの領域にあります。 そのアプリケーションに、RTPトラフィック自体は周期的なkeepalivesを提供します。 しかしながら、いくつかの実用的な問題がRTPのために起こります。 まず最初に、RTPは、ポート1の上にRTCPトラフィックがRTPトラフィックより高くあると仮定します。 直接制御可能でないNATsを通してこの組み合わせの特性を保証できません。 その結果、RTCPトラフィックは適切に受け取られないかもしれません。 SDPへのクライアントがRTCP[18]のために異なったポートに合図するのを許容することによってこれを緩和するプロトコル拡大が提案されました。 しかしながら、相互運用性問題がしばらくあるでしょう。
For VoIP, silence suppression can cause a gap in the transmission of RTP packets. This could result in the loss of a binding in the middle of a call, if that silence period exceeds the binding timeout. This can be mitigated by sending occasional silence packets to keep the binding alive. However, the result is additional brittleness; proper operation depends on the silence suppression algorithm in use, the usage of a comfort noise codec, the duration of the silence period, and the binding lifetime in the NAT.
VoIPに関しては、沈黙抑圧はRTPパケットのトランスミッションにおけるずれを引き起こす場合があります。 これは呼び出しの途中の結合の損失をもたらすかもしれません、その沈黙の期間が拘束力があるタイムアウトを超えているなら。 これは送付の時々の沈黙パケットによって緩和されて、結合を生かすことができます。 しかしながら、結果は追加もろさです。 適切な操作は使用中の沈黙抑圧アルゴリズム、安らぎ雑音コーデックの使用法、沈黙の期間の持続時間、およびNATにおける拘束力がある生涯に依存します。
14.6 In Closing
14.6 最後になりましたが
The problems with STUN are not design flaws in STUN. The problems in STUN have to do with the lack of standardized behaviors and controls in NATs. The result of this lack of standardization has been a proliferation of devices whose behavior is highly unpredictable, extremely variable, and uncontrollable. STUN does the best it can in such a hostile environment. Ultimately, the solution is to make the environment less hostile, and to introduce controls and standardized behaviors into NAT. However, until such time as that happens, STUN provides a good short term solution given the terrible conditions under which it is forced to operate.
STUNに関する問題はSTUNの設計上の欠陥ではありません。 STUNの問題はNATsで標準化された振舞いとコントロールの不足と関係があります。 標準化のこの不足の結果は振舞いが非常に予測できないで、非常に変化し、制御不可能であるデバイスの増殖です。 STUNはそれがそのような敵対的環境でそうすることができるベストを尽くします。 結局、ソリューションは、環境をより敵対的でなくして、コントロールと標準化された振舞いをNATに取り入れることです。 しかしながら、作動するのが無理矢理ひどい状態を考えて、そのような時間が起こるまで、STUNは良い短期間解決法を提供します。
Rosenberg, et al. Standards Track [Page 43] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[43ページ]RFC3489は2003年3月に気絶させます。
15. Acknowledgments
15. 承認
The authors would like to thank Cedric Aoun, Pete Cordell, Cullen Jennings, Bob Penfield and Chris Sullivan for their comments, and Baruch Sterman and Alan Hawrylyshen for initial implementations. Thanks for Leslie Daigle, Allison Mankin, Eric Rescorla, and Henning Schulzrinne for IESG and IAB input on this work.
彼らのコメントについてピートのセドリックAoun、コーデル、Cullenジョニングス、ボブ・ペンフィールド、およびクリス・サリバンに感謝します、そして、作者は、初期の実装のためにバルク書StermanとアランHawrylyshenに感謝したいです。 レスリーDaigle、アリソン・マンキン、エリック・レスコラ、およびヘニングSchulzrinneをこの仕事のときに入力されたIESGとIABのためにありがとうございます。
16. Normative References
16. 引用規格
[1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[2] Dierks, T. and C. Allen, "The TLS protocol Version 1.0", RFC
2246, January 1999.
[2] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[3]GulbrandsenとA.とVixieとP.とL.Esibov、「サービス(DNS SRV)の位置を指定するためのDNS RR」、RFC2782、2000年2月。
[4] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[4]Chown、2002年6月のP.、「トランスポート層セキュリティ(TLS)のためのエー・イー・エス(AES)Ciphersuites」RFC3268。
[5] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
[5] レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
[6] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[6] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", BCP 38, RFC 2827, May 2000.
[7] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
17. Informative References
17. 有益な参照
[8] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[8]Senie、D.、「ネットワーク・アドレスの翻訳者の(NAT)に優しいアプリケーション設計ガイドライン」、RFC3235、2002年1月。
[9] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
Rayhan, "Middlebox Communication Architecture and Framework",
RFC 3303, August 2002.
[9]Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリトル、A.、A.Rayhan、および「Middlebox通信アーキテクチャとフレームワーク」、RFC3303(2002年8月)
[10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[10] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[11] Holdrege, M. and P. Srisuresh, "Protocol Complications with the
IP Network Address Translator", RFC 3027, January 2001.
[11]HoldregeとM.とP.Srisuresh、「IPネットワークアドレス変換機構とのプロトコル複雑さ」、RFC3027、2001年1月。
Rosenberg, et al. Standards Track [Page 44] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[44ページ]RFC3489は2003年3月に気絶させます。
[12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[12]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[13] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[13]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[14] Kohl, J. and C. Neuman, "The kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[14] コールとJ.とC.ヌーマン、「kerberos Network Authentication Service(V5)」、RFC1510 1993年9月。
[15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[15] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[16] Baugher M., et al., "The secure real-time transport protocol",
Work in Progress.
[16] Baugher M.、他、「安全なリアルタイムのトランスポート・プロトコル」、ProgressのWork。
[17] Daigle, L., Editor, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation", RFC
3424, November 2002.
[17]Daigle、L.、エディタ、「一方的な自己アドレス修理(UNSAF)のためのネットワークアドレス変換の向こう側のIAB問題」、RFC3424、2002年11月。
[18] Huitema, C., "RTCP attribute in SDP", Work in Progress.
[18]Huitema、C.、「SDPのRTCP属性」、ProgressのWork。
Rosenberg, et al. Standards Track [Page 45] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[45ページ]RFC3489は2003年3月に気絶させます。
18. Authors' Addresses
18. 作者のアドレス
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグdynamicsoft72Eagle Rock AvenueのFirst Floorの東ハノーバー王家、ニュージャージー 07936
EMail: jdrosen@dynamicsoft.com
メール: jdrosen@dynamicsoft.com
Joel Weinberger dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョエルワインバーガーdynamicsoft72Eagle Rock AvenueのFirst Floorの東ハノーバー王家、ニュージャージー 07936
EMail: jweinberger@dynamicsoft.com
メール: jweinberger@dynamicsoft.com
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
クリスチャンのHuitemaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399
EMail: huitema@microsoft.com
メール: huitema@microsoft.com
Rohan Mahy Cisco Systems 101 Cooper St Santa Cruz, CA 95060
Stサンタクルス、Rohanマーイシスコシステムズの101桶屋カリフォルニア 95060
EMail: rohan@cisco.com
メール: rohan@cisco.com
Rosenberg, et al. Standards Track [Page 46] RFC 3489 STUN March 2003
ローゼンバーグ、他 標準化過程[46ページ]RFC3489は2003年3月に気絶させます。
19. Full Copyright Statement
19. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rosenberg, et al. Standards Track [Page 47]
ローゼンバーグ、他 標準化過程[47ページ]
一覧
スポンサーリンク
