RFC5389 日本語訳
5389 Session Traversal Utilities for NAT (STUN). J. Rosenberg, R.Mahy, P. Matthews, D. Wing. October 2008. (Format: TXT=125650 bytes) (Obsoletes RFC3489) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg
Request for Comments: 5389 Cisco
Obsoletes: 3489 R. Mahy
Category: Standards Track P. Matthews
Unaffiliated
D. Wing
Cisco
October 2008
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 5389年のコクチマスは以下を時代遅れにします。 3489年のR.マーイカテゴリ: D.翼のコクチマス2008年10月に属しない標準化過程P.マシューズ
Session Traversal Utilities for NAT (STUN)
NATのためのセッション縦断ユーティリティ(気絶させます)
Status of This 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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.
NAT(STUN)のためのセッションTraversal Utilitiesは他のプロトコルのためのツールとしてNetwork Address Translator(NAT)縦断に対処する際に機能するプロトコルです。 それは終点によって使用されて、NATによってそれに割り当てられたIPアドレスとポートは決定できます。 また、2つの終点の間と、そして、生きている生活費プロトコルとしてNAT結合を維持するのにチェックの接続性にそれを使用できます。 STUNは多くの既存のNATsと共に働いて、彼らから少しの特別な振舞いも必要としません。
STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.
STUNはそれ自体でNAT縦断対策ではありません。 むしろ、それはNAT縦断対策の文脈で使用されるべきツールです。 これはこの仕様(RFC3489)の旧バージョンからの重要な変化です。(仕様は完全解としてSTUNを寄贈しました)。
This document obsoletes RFC 3489.
このドキュメントはRFC3489を時代遅れにします。
Table of Contents
目次
1. Introduction ....................................................4 2. Evolution from RFC 3489 .........................................4 3. Overview of Operation ...........................................5 4. Terminology .....................................................8 5. Definitions .....................................................8 6. STUN Message Structure .........................................10 7. Base Protocol Procedures .......................................12 7.1. Forming a Request or an Indication ........................12 7.2. Sending the Request or Indication .........................13
1. 序論…4 2. RFC3489からの発展…4 3. 操作の概要…5 4. 用語…8 5. 定義…8 6. メッセージ構造を気絶させてください…10 7. プロトコル手順を基礎づけてください…12 7.1. 要求か指示を形成します…12 7.2. 要求か指示を送ります…13
Rosenberg, et al. Standards Track [Page 1] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[1ページ]RFC5389は2008年10月に気絶させます。
7.2.1. Sending over UDP ...................................13
7.2.2. Sending over TCP or TLS-over-TCP ...................14
7.3. Receiving a STUN Message ..................................16
7.3.1. Processing a Request ...............................17
7.3.1.1. Forming a Success or Error Response .......18
7.3.1.2. Sending the Success or Error Response .....19
7.3.2. Processing an Indication ...........................19
7.3.3. Processing a Success Response ......................19
7.3.4. Processing an Error Response .......................20
8. FINGERPRINT Mechanism ..........................................20
9. DNS Discovery of a Server ......................................21
10. Authentication and Message-Integrity Mechanisms ...............22
10.1. Short-Term Credential Mechanism ..........................22
10.1.1. Forming a Request or Indication ...................23
10.1.2. Receiving a Request or Indication .................23
10.1.3. Receiving a Response ..............................24
10.2. Long-Term Credential Mechanism ...........................24
10.2.1. Forming a Request .................................25
10.2.1.1. First Request ............................25
10.2.1.2. Subsequent Requests ......................26
10.2.2. Receiving a Request ...............................26
10.2.3. Receiving a Response ..............................27
11. ALTERNATE-SERVER Mechanism ....................................28
12. Backwards Compatibility with RFC 3489 .........................28
12.1. Changes to Client Processing .............................29
12.2. Changes to Server Processing .............................29
13. Basic Server Behavior .........................................30
14. STUN Usages ...................................................30
15. STUN Attributes ...............................................31
15.1. MAPPED-ADDRESS ...........................................32
15.2. XOR-MAPPED-ADDRESS .......................................33
15.3. USERNAME .................................................34
15.4. MESSAGE-INTEGRITY ........................................34
15.5. FINGERPRINT ..............................................36
15.6. ERROR-CODE ...............................................36
15.7. REALM ....................................................38
15.8. NONCE ....................................................38
15.9. UNKNOWN-ATTRIBUTES .......................................38
15.10. SOFTWARE ................................................39
15.11. ALTERNATE-SERVER ........................................39
16. Security Considerations .......................................39
16.1. Attacks against the Protocol .............................39
16.1.1. Outside Attacks ...................................39
16.1.2. Inside Attacks ....................................40
16.2. Attacks Affecting the Usage ..............................40
16.2.1. Attack I: Distributed DoS (DDoS) against a
Target ............................................41
16.2.2. Attack II: Silencing a Client .....................41
7.2.1. UDPを移動します…13 7.2.2. TCPかTLS過剰TCPを移動します…14 7.3. aを受けて、メッセージを気絶させてください…16 7.3.1. 要求を処理します…17 7.3.1.1. 成功か誤り応答を形成します…18 7.3.1.2. 成功か誤りに応答を送ります…19 7.3.2. 指示を処理します…19 7.3.3. 成功応答を処理します…19 7.3.4. 誤り応答を処理します…20 8. メカニズムの指紋を採取してください…20 9. サーバのDNS発見…21 10. 認証とメッセージの保全メカニズム…22 10.1. 短期的な資格証明メカニズム…22 10.1.1. 要求か指示を形成します…23 10.1.2. 要求か指示を受け取ります…23 10.1.3. 応答を受けます…24 10.2. 長期の資格証明メカニズム…24 10.2.1. 要求を形成します…25 10.2.1.1. 最初に、要求します。25 10.2.1.2. その後の要求…26 10.2.2. 要求を受け取ります…26 10.2.3. 応答を受けます…27 11. 代替のサーバメカニズム…28 12. RFC3489との遅れている互換性…28 12.1. クライアント処理への変化…29 12.2. サーバ処理への変化…29 13. 基幹サーバの振舞い…30 14. 用法を気絶させてください…30 15. 属性を気絶させてください…31 15.1. 写像しているアドレス…32 15.2. XORはアドレスを写像しました…33 15.3. ユーザ名…34 15.4. メッセージの保全…34 15.5. 指紋を採取します。36 15.6. 誤りコード…36 15.7. 分野…38 15.8. 一回だけ…38 15.9. 未知の属性…38 15.10. ソフトウェア…39 15.11. 代替のサーバ…39 16. セキュリティ問題…39 16.1. プロトコルに対する攻撃…39 16.1.1. 外部は攻撃されます…39 16.1.2. 内部は攻撃されます…40 16.2. 用法に影響する攻撃…40 16.2.1. 攻撃I: 目標に対してDoS(DDoS)を分配します…41 16.2.2. 攻撃II: クライアントを黙らせます…41
Rosenberg, et al. Standards Track [Page 2] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[2ページ]RFC5389は2008年10月に気絶させます。
16.2.3. Attack III: Assuming the Identity of a Client .....42
16.2.4. Attack IV: Eavesdropping ..........................42
16.3. Hash Agility Plan ........................................42
17. IAB Considerations ............................................42
18. IANA Considerations ...........................................43
18.1. STUN Methods Registry ....................................43
18.2. STUN Attribute Registry ..................................43
18.3. STUN Error Code Registry .................................44
18.4. STUN UDP and TCP Port Numbers ............................45
19. Changes since RFC 3489 ........................................45
20. Contributors ..................................................47
21. Acknowledgements ..............................................47
22. References ....................................................47
22.1. Normative References .....................................47
22.2. Informative References ...................................48
Appendix A. C Snippet to Determine STUN Message Types .............50
16.2.3. 攻撃III: クライアントのアイデンティティを仮定します…42 16.2.4. 攻撃IV: 盗聴…42 16.3. 機敏さプランを論じ尽くしてください…42 17. IAB問題…42 18. IANA問題…43 18.1. メソッド登録を気絶させてください…43 18.2. 属性登録を気絶させてください…43 18.3. エラーコード登録を気絶させてください…44 18.4. UDPとTCPポートナンバーを気絶させてください…45 19. RFC3489以来の変化…45 20. 貢献者…47 21. 承認…47 22. 参照…47 22.1. 標準の参照…47 22.2. 有益な参照…メッセージを気絶させるように決定する48付録A.C切れ端はタイプされます…50
Rosenberg, et al. Standards Track [Page 3] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[3ページ]RFC5389は2008年10月に気絶させます。
1. Introduction
1. 序論
The protocol defined in this specification, Session Traversal Utilities for NAT, provides a tool for dealing with NATs. It provides a means for an endpoint to determine the IP address and port allocated by a NAT that corresponds to its private IP address and port. It also provides a way for an endpoint to keep a NAT binding alive. With some extensions, the protocol can be used to do connectivity checks between two endpoints [MMUSIC-ICE], or to relay packets between two endpoints [BEHAVE-TURN].
この仕様に基づき定義されたプロトコル(NATのためのSession Traversal Utilities)はNATsに対処するのにツールを提供します。 それは終点がIPアドレスを決定する手段、プライベートIPアドレスに対応するNATによって割り当てられたポート、およびポートを提供します。 また、それは終点が拘束力があってNATを生きているままである方法を提供します。 いくつかの拡大と共に、2つの終点[MMUSIC-ICE]の間の接続性チェックをするか、または2つの終点[BEHAVE-TURN]の間のパケットをリレーするのにプロトコルを使用できます。
In keeping with its tool nature, this specification defines an extensible packet format, defines operation over several transport protocols, and provides for two forms of authentication.
ツール自然で保つ際に、この仕様は、広げることができるパケット・フォーマットを定義して、いくつかのトランスポート・プロトコルの上の操作を定義して、2つの形式の認証に備えます。
STUN is intended to be used in context of one or more NAT traversal solutions. These solutions are known as STUN usages. Each usage describes how STUN is utilized to achieve the NAT traversal solution. Typically, a usage indicates when STUN messages get sent, which optional attributes to include, what server is used, and what authentication mechanism is to be used. Interactive Connectivity Establishment (ICE) [MMUSIC-ICE] is one usage of STUN. SIP Outbound [SIP-OUTBOUND] is another usage of STUN. In some cases, a usage will require extensions to STUN. A STUN extension can be in the form of new methods, attributes, or error response codes. More information on STUN usages can be found in Section 14.
状況内において1つ以上のNAT縦断対策についてSTUNが使用されることを意図します。 これらのソリューションはSTUN用法として知られています。 各用法はSTUNがNAT縦断対策を達成するのにどう利用されるかを説明します。 通常、用法は、使用されるためにいつSTUNメッセージを送るか、そして、どの任意の属性を含むか、そして、どんなサーバが使用されているか、そして、認証機構が何であるかを示します。 対話的なConnectivity特権階級(ICE)[MMUSIC-ICE]はSTUNの1つの使用法です。 SIP Outbound[SIP-OUTBOUND]はSTUNの別の使用法です。 いくつかの場合、用法はSTUNに拡大を必要とするでしょう。 STUN拡張子が新しいメソッド、属性、または誤り応答コードの形にあることができます。 セクション14でSTUN用法に関する詳しい情報を見つけることができます。
2. Evolution from RFC 3489
2. RFC3489からの発展
STUN was originally defined in RFC 3489 [RFC3489]. That specification, sometimes referred to as "classic STUN", represented itself as a complete solution to the NAT traversal problem. In that solution, a client would discover whether it was behind a NAT, determine its NAT type, discover its IP address and port on the public side of the outermost NAT, and then utilize that IP address and port within the body of protocols, such as the Session Initiation Protocol (SIP) [RFC3261]. However, experience since the publication of RFC 3489 has found that classic STUN simply does not work sufficiently well to be a deployable solution. The address and port learned through classic STUN are sometimes usable for communications with a peer, and sometimes not. Classic STUN provided no way to discover whether it would, in fact, work or not, and it provided no remedy in cases where it did not. Furthermore, classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.
STUNは元々、RFC3489[RFC3489]で定義されました。 時々「古典的なSTUN」と呼ばれたその仕様はNAT縦断問題の完全解と称しました。 NATの後ろにそれがあったか否かに関係なく、クライアントは、そのソリューションでNATがタイプして、一番はずれのNAT公共側でそのIPアドレスとポートを発見して、次に、プロトコルのボディーの中でそのIPアドレスとポートを利用することを決定するように発見するでしょう、Session Initiationプロトコル(SIP)[RFC3261]などのように。 しかしながら、RFC3489の公表が単にその古典的なSTUNを見つけたので、経験は配布可能ソリューションになるように十分よく働いていません。 古典的なSTUNを通して学習されたアドレスとポートは、同輩とのコミュニケーションに時々使用可能で、時々そうしていません。 古典的なSTUNは事実上、それが働くかどうか発見する方法を全く供給しませんでした、そして、それはそれがそうしなかったケースの中に療法を全く供給しませんでした。 その上、NATタイプの分類のための古典的なSTUNのアルゴリズムは不完全であることがわかりました、多くのNATsが清潔にそこで定義されたタイプに収まらなかったとき。
Rosenberg, et al. Standards Track [Page 4] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[4ページ]RFC5389は2008年10月に気絶させます。
Classic STUN also had a security vulnerability -- attackers could provide the client with incorrect mapped addresses under certain topologies and constraints, and this was fundamentally not solvable through any cryptographic means. Though this problem remains with this specification, those attacks are now mitigated through the use of more complete solutions that make use of STUN.
また、古典的なSTUNには、セキュリティの脆弱性がありました--攻撃者は不正確な写像しているアドレスをクライアントに、あるtopologiesと規制で提供できました、そして、これはどんな暗号の手段でも基本的に解決できませんでした。 この問題はこの仕様で残っていますが、それらの攻撃は現在、STUNを利用するより完全なソリューションの使用で緩和されます。
For these reasons, this specification obsoletes RFC 3489, and instead describes STUN as a tool that is utilized as part of a complete NAT traversal solution. ICE [MMUSIC-ICE] is a complete NAT traversal solution for protocols based on the offer/answer [RFC3264] methodology, such as SIP. SIP Outbound [SIP-OUTBOUND] is a complete solution for traversal of SIP signaling, and it uses STUN in a very different way. Though it is possible that a protocol may be able to use STUN by itself (classic STUN) as a traversal solution, such usage is not described here and is strongly discouraged for the reasons described above.
これらの理由で、この仕様は、RFC3489を時代遅れにして、代わりに完全なNAT縦断対策の一部として利用されるツールとしてSTUNを記述します。 ICE[MMUSIC-ICE]は申し出/答え[RFC3264]方法論に基づくSIPなどのプロトコルのための完全なNAT縦断対策です。 SIP Outbound[SIP-OUTBOUND]はSIPシグナリングの縦断の完全解です、そして、それは非常に異なった方法でSTUNを使用します。 プロトコル自体が縦断対策としてSTUNを使用できるのが、可能ですが、そのような用法は、ここで説明されないで、上で説明された理由で強くがっかりしています。
The on-the-wire protocol described here is changed only slightly from classic STUN. The protocol now runs over TCP in addition to UDP. Extensibility was added to the protocol in a more structured way. A magic cookie mechanism for demultiplexing STUN with application protocols was added by stealing 32 bits from the 128-bit transaction ID defined in RFC 3489, allowing the change to be backwards compatible. Mapped addresses are encoded using a new exclusive-or format. There are other, more minor changes. See Section 19 for a more complete listing.
わずかに単に古典的なSTUNからワイヤの上のここで説明されたプロトコルを変えます。 プロトコルはもう、UDPに加えてTCPをひきます。 伸展性はさらに構造化された方法でプロトコルに追加されました。 アプリケーション・プロトコルがある逆多重化STUNのための魔法のクッキーメカニズムは変化が後方にそうであることを許容して、IDがRFC3489で定義した128ビットのトランザクションから32ビット盗むことによって互換性があった状態で加えられました。 写像しているアドレスは、新しい排他的論理和形式を使用することでコード化されます。 もう一方、より多くのマイナーチェンジがあります。 より完全なリストのためにセクション19を見てください。
Due to the change in scope, STUN has also been renamed from "Simple Traversal of UDP through NAT" to "Session Traversal Utilities for NAT". The acronym remains STUN, which is all anyone ever remembers anyway.
範囲の変化のため、また、STUNは「NATを通したUDPの簡単な縦断」から「NATのためのセッション縦断ユーティリティ」まで改名されました。 頭文字語はSTUNのままで残っていて、決してどれが皆だれかであるかはとにかく覚えています。
3. Overview of Operation
3. 操作の概要
This section is descriptive only.
このセクションは描写的です。単に。
Rosenberg, et al. Standards Track [Page 5] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[5ページ]RFC5389は2008年10月に気絶させます。
/-----\
// STUN \\
| Server |
\\ //
\-----/
/-----\//は\\を気絶させます。| サーバ| \\ // \-----/
+--------------+ Public Internet
................| NAT 2 |.......................
+--------------+
+--------------+ 公共のインターネット…| NAT2|....................... +--------------+
+--------------+ Private NET 2
................| NAT 1 |.......................
+--------------+
+--------------+ 個人的なネット2…| NAT1|....................... +--------------+
/-----\
// STUN \\
| Client |
\\ // Private NET 1
\-----/
/-----\//は\\を気絶させます。| クライアント| \\//個人的なネットの1円-----/
Figure 1: One Possible STUN Configuration
図1: 可能な人は構成を気絶させます。
One possible STUN configuration is shown in Figure 1. In this configuration, there are two entities (called STUN agents) that implement the STUN protocol. The lower agent in the figure is the client, and 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 upper agent in the figure is the server, and resides on the public Internet.
1つの可能なSTUN構成が図1に示されます。 この構成には、STUNプロトコルを実装する2つの実体(STUNエージェントと呼ばれる)があります。 図という下側のエージェントは、クライアントであり、私設のネットワーク1に接続されます。 このネットワークはNAT1を通して私設のネットワーク2に接続します。 私設のネットワーク2はNAT2を通して公共のインターネットに接続します。 図という上側のエージェントは、サーバであり、公共のインターネットに住んでいます。
STUN is a client-server protocol. It supports two types of transactions. One is a request/response transaction in which a client sends a request to a server, and the server returns a response. The second is an indication transaction in which either agent -- client or server -- sends an indication that generates no response. Both types of transactions include a transaction ID, which is a randomly selected 96-bit number. For request/response
STUNはクライアント/サーバプロトコルです。 それは2つのタイプのトランザクションをサポートします。 1つはクライアントが要求をサーバに送る要求/応答トランザクションです、そして、サーバは応答を返します。 2番目はどちらのエージェント(クライアントかサーバ)も応答を全く生成しない指示を送る指示トランザクションです。 両方のタイプのトランザクションはトランザクションIDを含んでいます。(それは、手当たりしだいに選択された96ビットの数です)。 要求/応答のために
Rosenberg, et al. Standards Track [Page 6] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[6ページ]RFC5389は2008年10月に気絶させます。
transactions, this transaction ID allows the client to associate the response with the request that generated it; for indications, the transaction ID serves as a debugging aid.
トランザクション、IDがそれを生成した要求に応答をクライアントを関連づけさせるこのトランザクション。 指摘のために、トランザクションIDはデバッギング・エイドとして機能します。
All STUN messages start with a fixed header that includes a method, a class, and the transaction ID. The method indicates which of the various requests or indications this is; this specification defines just one method, Binding, but other methods are expected to be defined in other documents. The class indicates whether this is a request, a success response, an error response, or an indication. Following the fixed header comes zero or more attributes, which are Type-Length-Value extensions that convey additional information for the specific message.
すべてのSTUNメッセージがメソッド、クラス、およびトランザクションIDを含んでいる固定ヘッダーから始まります。 メソッドは、これが様々な要求か指摘のどれであるかを示します。 Binding、この仕様はちょうど1つのメソッドを定義しますが、他のドキュメントで他のメソッドが定義されると予想されます。 クラスは、これが要求、成功応答、誤り応答、または指示であるかを示します。 修理に続いて、ヘッダーは来ます。ゼロか、より多くの属性。(その属性は特定のメッセージのための追加情報を伝えるType長さの価値の拡大です)。
This document defines a single method called Binding. The Binding method can be used either in request/response transactions or in indication transactions. When used in request/response transactions, the Binding method can be used to determine the particular "binding" a NAT has allocated to a STUN client. When used in either request/ response or in indication transactions, the Binding method can also be used to keep these "bindings" alive.
このドキュメントはBindingと呼ばれるただ一つのメソッドを定義します。 要求/応答トランザクションか指示トランザクションにBindingメソッドを使用できます。 要求/応答トランザクションに使用されると、NATがSTUNクライアントに割り当てた特定の「結合」を決定するのにBindingメソッドを使用できます。 また、要求/応答か指示トランザクションに使用されると、これらの「結合」を生かすのにBindingメソッドを使用できます。
In the Binding request/response transaction, a Binding request is sent from a STUN client to a STUN server. When the Binding request arrives at the STUN server, it may have passed through one or more NATs between the STUN client and the STUN server (in Figure 1, there were two such NATs). As the Binding request message passes through a NAT, the NAT will modify the source transport address (that is, the source IP address and the source port) of the packet. As a result, the source transport address of the request received by the server will be the public IP address and port created by the NAT closest to the server. This is called a reflexive transport address. The STUN server copies that source transport address into an XOR-MAPPED- ADDRESS attribute in the STUN Binding response and sends the Binding response back to the STUN client. As this packet passes back through a NAT, the NAT will modify the destination transport address in the IP header, but the transport address in the XOR-MAPPED-ADDRESS attribute within the body of the STUN response will remain untouched. In this way, the client can learn its reflexive transport address allocated by the outermost NAT with respect to the STUN server.
Binding要求/応答トランザクションでは、STUNクライアントからSTUNサーバにBinding要求を送りました。Binding要求がSTUNサーバに到着するとき、それは、STUNクライアントとSTUNサーバの間の1NATsを通り抜けたかもしれません(図1には、そのような2NATsがありました)。 Binding要求メッセージがNATを通り抜けるとき、NATはパケットのソース輸送アドレス(すなわち、ソースIPアドレスとソースポート)を変更するでしょう。 その結果、NATによって作成される中で公共のIPアドレスとポートがサーバに最も近かったなら、サーバによって受け取られた要求のソース輸送アドレスは呼ぶでしょう。これは再帰の輸送アドレスと呼ばれます。 STUNサーバは、STUN Binding応答におけるXOR-MAPPED- ADDRESS属性にそのソース輸送アドレスをコピーして、Binding応答をSTUNクライアントに送り返します。 このパケットがNATを通り抜けて戻すとき、NATはIPヘッダーで送付先輸送アドレスを変更するでしょうが、STUN応答のボディーの中のXOR-MAPPED-ADDRESS属性における輸送アドレスは触れないままで残るでしょう。 このように、クライアントは一番はずれのNATによってSTUNサーバに関して割り当てられた再帰の輸送アドレスを学ぶことができます。
In some usages, STUN must be multiplexed with other protocols (e.g., [MMUSIC-ICE], [SIP-OUTBOUND]). In these usages, there must be a way to inspect a packet and determine if it is a STUN packet or not. STUN provides three fields in the STUN header with fixed values that can be used for this purpose. If this is not sufficient, then STUN packets can also contain a FINGERPRINT value, which can further be used to distinguish the packets.
いくつかの用法で、他のプロトコル(例えば、[MMUSIC-ICE]、[SIP-OUTBOUND])と共にSTUNを多重送信しなければなりません。 これらの用法には、パケットを点検して、それがSTUNパケットであるかどうか決定する方法があるに違いありません。 STUNはこのために使用できる一定の価値をSTUNヘッダーの3つの分野に提供します。 また、これが十分でないなら、STUNパケットはFINGERPRINT値を含むことができます。(さらに、パケットを区別するのにそれを使用できます)。
Rosenberg, et al. Standards Track [Page 7] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[7ページ]RFC5389は2008年10月に気絶させます。
STUN defines a set of optional procedures that a usage can decide to use, called mechanisms. These mechanisms include DNS discovery, a redirection technique to an alternate server, a fingerprint attribute for demultiplexing, and two authentication and message-integrity exchanges. The authentication mechanisms revolve around the use of a username, password, and message-integrity value. Two authentication mechanisms, the long-term credential mechanism and the short-term credential mechanism, are defined in this specification. Each usage specifies the mechanisms allowed with that usage.
STUNは用法が用いると決めることができる1セットの任意の手順を定義します、呼ばれたメカニズム。これらのメカニズムは2回のDNS発見、代替のサーバへのリダイレクションのテクニック、逆多重化のための指紋属性、認証、およびメッセージの保全交換を含んでいます。 認証機構はユーザ名、パスワード、およびメッセージの保全価値の使用を中心題目とします。 2台の認証機構(長期の資格証明メカニズムと短期的な資格証明メカニズム)が、この仕様に基づき定義されます。 各用法はその用法で許容されたメカニズムを指定します。
In the long-term credential mechanism, the client and server share a pre-provisioned username and password and perform a digest challenge/ response exchange inspired by (but differing in details) to the one defined for HTTP [RFC2617]. In the short-term credential mechanism, the client and the server exchange a username and password through some out-of-band method prior to the STUN exchange. For example, in the ICE usage [MMUSIC-ICE] the two endpoints use out-of-band signaling to exchange a username and password. These are used to integrity protect and authenticate the request and response. There is no challenge or nonce used.
長期の資格証明メカニズムでは、クライアントとサーバは、HTTP[RFC2617]のために定義されたものに、あらかじめ食糧を供給されたユーザ名とパスワードを共有して、交換が奮い立たせたダイジェスト挑戦/応答を実行します(細部が異なるのを除いて)。 短期的な資格証明メカニズムでは、クライアントとサーバはSTUN交換の前に何らかのバンドで出ているメソッドでユーザ名とパスワードを交換します。 例えば、ICE用法[MMUSIC-ICE]で、2つの終点が、ユーザ名とパスワードを交換するのにバンドの外でシグナリングを使用します。 使用されるこれらは、保全に保護して、要求と応答を認証します。 どんな使用された挑戦も一回だけもありません。
4. Terminology
4. 用語
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 [RFC2119] and indicate requirement levels for compliant STUN implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが言いなりになった状態でBCP14、RFC2119[RFC2119]で説明されるように解釈されて、要件レベルを示すことであるべきである、実装を気絶させてくださいだろう。
5. Definitions
5. 定義
STUN Agent: A STUN agent is an entity that implements the STUN
protocol. The entity can be either a STUN client or a STUN
server.
エージェントを気絶させてください: STUNエージェントはSTUNプロトコルを実装する実体です。 実体は、STUNクライアントかSTUNサーバのどちらかであるかもしれません。
STUN Client: A STUN client is an entity that sends STUN requests and
receives STUN responses. A STUN client can also send indications.
In this specification, the terms STUN client and client are
synonymous.
クライアントを気絶させてください: STUNクライアントは、要求をSTUNに送る実体であり、STUN応答を受けます。 また、STUNクライアントは指摘を送ることができます。 この仕様では、用語STUNクライアントとクライアントは同義です。
STUN Server: A STUN server is an entity that receives STUN requests
and sends STUN responses. A STUN server can also send
indications. In this specification, the terms STUN server and
server are synonymous.
サーバを気絶させてください: STUNサーバはSTUN要求を受け取って、応答をSTUNに送る実体です。 また、STUNサーバは指摘を送ることができます。 この仕様では、用語STUNサーバとサーバは同義です。
Transport Address: The combination of an IP address and port number
(such as a UDP or TCP port number).
アドレスを輸送してください: IPアドレスとポートナンバー(UDPかTCPポートナンバーなどの)の組み合わせ。
Rosenberg, et al. Standards Track [Page 8] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[8ページ]RFC5389は2008年10月に気絶させます。
Reflexive Transport Address: A transport address learned by a client
that identifies that client as seen by another host on an IP
network, typically a STUN server. When there is an intervening
NAT between the client and the other host, the reflexive transport
address represents the mapped address allocated to the client on
the public side of the NAT. Reflexive transport addresses are
learned from the mapped address attribute (MAPPED-ADDRESS or XOR-
MAPPED-ADDRESS) in STUN responses.
再帰の輸送アドレス: 輸送アドレスはIPネットワークで別のホストによって見られるそのクライアント、通常STUNサーバを特定するクライアントで学びました。クライアントと他のホストの間に介入しているNATがあるとき、再帰の輸送アドレスはNAT公共側の上のクライアントに割り当てられた写像しているアドレスを表します。 再帰の輸送アドレスはSTUN応答における写像しているアドレス属性(MAPPED-ADDRESSかXOR- MAPPED-ADDRESS)から学習されます。
Mapped Address: Same meaning as reflexive address. This term is
retained only for historic reasons and due to the naming of the
MAPPED-ADDRESS and XOR-MAPPED-ADDRESS attributes.
写像しているアドレス: 再帰のアドレスとしての同意義。 今期は歴史的な理由だけとMAPPED-ADDRESSとXOR-MAPPED-ADDRESS属性の命名のため保有されます。
Long-Term Credential: A username and associated password that
represent a shared secret between client and server. Long-term
credentials are generally granted to the client when a subscriber
enrolls in a service and persist until the subscriber leaves the
service or explicitly changes the credential.
長期の資格証明書: クライアントとサーバ長期の資格証明書の間の共有秘密キーを表すユーザ名と関連パスワードは、加入者がサービスに登録するとき、一般に、クライアントに与えられて、加入者がサービスを残すか、または明らかに資格証明書を変えるまで、持続しています。
Long-Term Password: The password from a long-term credential.
長期のパスワード: 長期の資格証明書からのパスワード。
Short-Term Credential: A temporary username and associated password
that represent a shared secret between client and server. Short-
term credentials are obtained through some kind of protocol
mechanism between the client and server, preceding the STUN
exchange. A short-term credential has an explicit temporal scope,
which may be based on a specific amount of time (such as 5
minutes) or on an event (such as termination of a SIP dialog).
The specific scope of a short-term credential is defined by the
application usage.
短期的な資格証明書: クライアントとサーバの間のある種のプロトコルメカニズムを通してクライアントとサーバ短い用語資格証明書の間の共有秘密キーを表す一時的なユーザ名と関連パスワードを得ます、STUN交換に先行して。 短期的な資格証明書には明白な時の範囲があります。(特定の時間(5分などの)に基づいたイベント(SIP対話の終了などの)の上にそれは、あるかもしれません)。 短期的な資格証明書の特定の範囲はアプリケーション用法で定義されます。
Short-Term Password: The password component of a short-term
credential.
短期的なパスワード: 短期的な資格証明書のパスワードコンポーネント。
STUN Indication: A STUN message that does not receive a response.
指示を気絶させてください: 応答を受けないSTUNメッセージ。
Attribute: The STUN term for a Type-Length-Value (TLV) object that
can be added to a STUN message. Attributes are divided into two
types: comprehension-required and comprehension-optional. STUN
agents can safely ignore comprehension-optional attributes they
don't understand, but cannot successfully process a message if it
contains comprehension-required attributes that are not
understood.
以下を結果と考えてください。 STUNメッセージに追加できるType長さの価値(TLV)のオブジェクトのためのSTUN用語。 属性は2つのタイプに分割されます: 読解で必要であって読解任意です。 STUNエージェントは、安全に、彼らが理解していない読解任意の属性を無視できますが、理解されていない読解で必要な属性を含むなら、首尾よくメッセージを処理できません。
RTO: Retransmission TimeOut, which defines the initial period of
time between transmission of a request and the first retransmit of
that request.
RTO: Retransmission TimeOut、どれが要求の伝達と1番目の間で時間の原初期を定義するかはその要求について再送されます。
Rosenberg, et al. Standards Track [Page 9] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[9ページ]RFC5389は2008年10月に気絶させます。
6. STUN Message Structure
6. メッセージ構造を気絶させてください。
STUN messages are encoded in binary using network-oriented format (most significant byte or octet first, also commonly known as big- endian). The transmission order is described in detail in Appendix B of RFC 791 [RFC0791]. Unless otherwise noted, numeric constants are in decimal (base 10).
STUNメッセージは、バイナリーでネットワーク指向の形式(最も重要なバイトか最初に、また、大きいエンディアンとして一般的に知られている八重奏)を使用することでコード化されます。 トランスミッション命令はRFC791[RFC0791]のAppendix Bで詳細に説明されます。 別の方法で注意されない場合、小数(ベース10)には数値定数があります。
All STUN messages MUST start with a 20-byte header followed by zero or more Attributes. The STUN header contains a STUN message type, magic cookie, transaction ID, and message length.
すべてのSTUNメッセージがゼロがあとに続いた20バイトのヘッダーか、より多くのAttributesから始まらなければなりません。 STUNヘッダーはSTUNメッセージタイプ、魔法のクッキー、トランザクションID、およびメッセージ長を含んでいます。
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| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| メッセージタイプを気絶させてください。| メッセージ長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 魔法クッキー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | トランザクションID(96ビット)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of STUN Message Header
図2: 形式、メッセージヘッダーを気絶させてください。
The most significant 2 bits of every STUN message MUST be zeroes. This can be used to differentiate STUN packets from other protocols when STUN is multiplexed with other protocols on the same port.
あらゆるSTUNメッセージの最も重要な2ビットはゼロであるに違いありません。 同じポートの上に他のプロトコルがある状態でSTUNを多重送信するとき、他のプロトコルとSTUNパケットを区別するのにこれを使用できます。
The message type defines the message class (request, success response, failure response, or indication) and the message method (the primary function) of the STUN message. Although there are four message classes, there are only two types of transactions in STUN: request/response transactions (which consist of a request message and a response message) and indication transactions (which consist of a single indication message). Response classes are split into error and success responses to aid in quickly processing the STUN message.
メッセージタイプはメッセージのクラス(要求、成功応答、失敗応答、または指示)とSTUNメッセージのメッセージメソッド(プライマリ機能)を定義します。 4つのメッセージのクラスがありますが、2つのタイプのトランザクションしかSTUNにありません: 要求/応答トランザクション(要求メッセージと応答メッセージから成る)と指示トランザクション(ただ一つの指示メッセージから成ります)。 応答のクラスは、すぐにSTUNメッセージを処理する際に支援するために誤りと成功応答に分割されます。
Rosenberg, et al. Standards Track [Page 10] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[10ページ]RFC5389は2008年10月に気絶させます。
The message type field is decomposed further into the following structure:
メッセージタイプ分野はさらに以下の構造に分解されます:
0 1
2 3 4 5 6 7 8 9 0 1 2 3 4 5
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
|M |M |M|M|M|C|M|M|M|C|M|M|M|M|
|11|10|9|8|7|1|6|5|4|0|3|2|1|0|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+ |M|M|M|M|M|C|M|M|M|C|M|M|M|M| |11|10|9|8|7|1|6|5|4|0|3|2|1|0| +--+--+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of STUN Message Type Field
図3: 形式、メッセージタイプ分野を気絶させてください。
Here the bits in the message type field are shown as most significant (M11) through least significant (M0). M11 through M0 represent a 12- bit encoding of the method. C1 and C0 represent a 2-bit encoding of the class. A class of 0b00 is a request, a class of 0b01 is an indication, a class of 0b10 is a success response, and a class of 0b11 is an error response. This specification defines a single method, Binding. The method and class are orthogonal, so that for each method, a request, success response, error response, and indication are possible for that method. Extensions defining new methods MUST indicate which classes are permitted for that method.
ここに、メッセージタイプ分野のビットは最も重要でない(M0)を通した最も重要(M11)として示されます。 M11からM0はメソッドをコード化する12ビットを表します。 C1とC0はクラスの2ビットのコード化を表します。 0b00のクラスは要求です、そして、0b01のクラスは指示です、そして、0b10のクラスは成功応答です、そして、0b11のクラスは誤り応答です。 Binding、この仕様はただ一つのメソッドを定義します。 メソッドとクラスは直交しています、そのメソッドに、要求、成功応答、誤り応答、および指示が各メソッドのために可能であるように。 新しいメソッドを定義する拡大は、どのクラスがそのメソッドのために受入れられるかを示さなければなりません。
For example, a Binding request has class=0b00 (request) and method=0b000000000001 (Binding) and is encoded into the first 16 bits as 0x0001. A Binding response has class=0b10 (success response) and method=0b000000000001, and is encoded into the first 16 bits as 0x0101.
例えば、Binding要求は、クラス=0b00(要求する)とメソッドが0b000000000001(拘束力がある)との等しさにして、0×0001として最初の16ビットにコード化されます。 Binding応答は、クラス=0b10(成功応答)とメソッドが0b000000000001との等しさにして、0×0101として最初の16ビットにコード化されます。
Note: This unfortunate encoding is due to assignment of values in
[RFC3489] that did not consider encoding Indications, Success, and
Errors using bit fields.
以下に注意してください。 この不幸なコード化は噛み付いている分野を使用することでIndications、Success、およびErrorsをコード化すると考えなかった[RFC3489]の値の課題のためです。
The magic cookie field MUST contain the fixed value 0x2112A442 in network byte order. In RFC 3489 [RFC3489], this field was part of the transaction ID; placing the magic cookie in this location allows a server to detect if the client will understand certain attributes that were added in this revised specification. In addition, it aids in distinguishing STUN packets from packets of other protocols when STUN is multiplexed with those other protocols on the same port.
魔法のクッキー分野はネットワークバイトオーダーに一定の価値0x2112A442を含まなければなりません。 RFC3489[RFC3489]では、この分野はトランザクションIDの一部でした。 魔法のクッキーをこの位置に置くのに、サーバは、クライアントがこの訂正明細書で加えられたある属性を理解するかどうか検出できます。 さらに、それは同じポートの上にそれらの他のプロトコルがある状態でSTUNを多重送信するとき他のプロトコルのパケットとSTUNパケットを区別する際に支援されます。
The transaction ID is a 96-bit identifier, used to uniquely identify STUN transactions. For request/response transactions, the transaction ID is chosen by the STUN client for the request and echoed by the server in the response. For indications, it is chosen by the agent sending the indication. It primarily serves to correlate requests with responses, though it also plays a small role
トランザクションIDは唯一STUNトランザクションを特定するのに使用される96ビットの識別子です。 要求/応答トランザクションにおいて、トランザクションIDは、STUNクライアントによって要求に選ばれていて、応答におけるサーバによって反映されます。 指摘において、それは指示を送るエージェントによって選ばれています。 また、脇役をプレーしますが、それは、応答で要求を関連させるのに主として役立ちます。
Rosenberg, et al. Standards Track [Page 11] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[11ページ]RFC5389は2008年10月に気絶させます。
in helping to prevent certain types of attacks. The server also uses the transaction ID as a key to identify each transaction uniquely across all clients. As such, the transaction ID MUST be uniformly and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be cryptographically random. Resends of the same request reuse the same transaction ID, but the client MUST choose a new transaction ID for new transactions unless the new request is bit-wise identical to the previous request and sent from the same transport address to the same IP address. Success and error responses MUST carry the same transaction ID as their corresponding request. When an agent is acting as a STUN server and STUN client on the same port, the transaction IDs in requests sent by the agent have no relationship to the transaction IDs in requests received by the agent.
擁立する際に、あるタイプの攻撃を防いでください。 また、サーバは、すべてのクライアントの向こう側に唯一各トランザクションを特定するのにキーとしてトランザクションIDを使用します。 そういうものとして、間隔0からトランザクションIDを一様に手当たりしだいに選ばなければなりません。 2**96-1、およびSHOULDは暗号でそうです。無作為。 新しい要求が噛み付き的に前の要求と同じで同じ輸送アドレスから同じIPアドレスに送られない場合、新しいトランザクションIDは新しいトランザクションのために、しかし、再利用同じトランザクションID、クライアントが選ばなければならないという同じ要求を再送します。 成功と誤り応答は彼らの対応する要求と同じトランザクションIDを運ばなければなりません。 エージェントがSTUNサーバとSTUNクライアントとして同じポートに務めているとき、エージェントによって送られた要求におけるトランザクションIDには、エージェントによって受け取られた要求におけるトランザクションIDとの関係が全くありません。
The message length MUST contain the size, in bytes, of the message not including the 20-byte STUN header. Since all STUN attributes are padded to a multiple of 4 bytes, the last 2 bits of this field are always zero. This provides another way to distinguish STUN packets from packets of other protocols.
メッセージ長は20バイトのSTUNヘッダーを含まないメッセージのバイトで表現されるサイズを含まなければなりません。 すべてのSTUN属性が4バイトの倍数に水増しされるので、いつもこの分野の最後の2ビットはゼロです。 これは他のプロトコルのパケットとSTUNパケットを区別する別の方法を提供します。
Following the STUN fixed portion of the header are zero or more attributes. Each attribute is TLV (Type-Length-Value) encoded. The details of the encoding, and of the attributes themselves are given in Section 15.
続いて、ヘッダーの一部が修理されたSTUNはゼロであるか以上が属性です。 各属性はコード化されたTLV(長さの値をタイプする)です。 コード化、および属性自体の詳細はそうです。セクション15では、与えます。
7. Base Protocol Procedures
7. 基地のプロトコル手順
This section defines the base procedures of the STUN protocol. It describes how messages are formed, how they are sent, and how they are processed when they are received. It also defines the detailed processing of the Binding method. Other sections in this document describe optional procedures that a usage may elect to use in certain situations. Other documents may define other extensions to STUN, by adding new methods, new attributes, or new error response codes.
このセクションはSTUNプロトコルのベース手順を定義します。 それは、どのようにメッセージを形成するか、そして、どのようにそれらを送るか、そして、それらが受け取られているときどのようにそれらを処理するかを説明します。 また、それはBindingメソッドの詳細な処理を定義します。 他のセクションは本書では、ある状況で用いる用法が、選ぶかもしれない任意の手順について説明します。 他のドキュメントは、新しいメソッド、新しい属性、または新しい誤り応答コードを加えることによって、他の拡大をSTUNと定義するかもしれません。
7.1. Forming a Request or an Indication
7.1. 要求か指示を形成します。
When formulating a request or indication message, the agent MUST follow the rules in Section 6 when creating the header. In addition, the message class MUST be either "Request" or "Indication" (as appropriate), and the method must be either Binding or some method defined in another document.
要求か指示メッセージを定式化するとき、ヘッダーを創造するとき、エージェントはセクション6で約束を守らなければなりません。 メソッドは、別のドキュメントで定義されたさらに、メッセージのクラスが、「要求」か「指示」のどちらかであるに違いなく(適宜)、Bindingか何らかのメソッドのどちらかであるに違いありません。
The agent then adds any attributes specified by the method or the usage. For example, some usages may specify that the agent use an authentication method (Section 10) or the FINGERPRINT attribute (Section 8).
そして、エージェントは、どんな属性もメソッドか用法で指定したと言い足します。 例えば、いくつかの用法が、エージェントが認証方法(セクション10)かFINGERPRINT属性(セクション8)を使用すると指定するかもしれません。
Rosenberg, et al. Standards Track [Page 12] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[12ページ]RFC5389は2008年10月に気絶させます。
If the agent is sending a request, it SHOULD add a SOFTWARE attribute to the request. Agents MAY include a SOFTWARE attribute in indications, depending on the method. Extensions to STUN should discuss whether SOFTWARE is useful in new indications.
エージェントは要求を送って、それはSHOULDです。SOFTWARE属性を要求に追加してください。 メソッドによって、エージェントは指摘でSOFTWARE属性を入れるかもしれません。 STUNへの拡大は、SOFTWAREが新しい指摘で役に立つかどうか議論するべきです。
For the Binding method with no authentication, no attributes are required unless the usage specifies otherwise.
認証のないBindingメソッドにおいて、用法が別の方法で指定しない場合、属性は全く必要ではありません。
All STUN messages sent over UDP SHOULD be less than the path MTU, if known. If the path MTU is unknown, messages SHOULD be the smaller of 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460]. This value corresponds to the overall size of the IP packet. Consequently, for IPv4, the actual STUN message would need to be less than 548 bytes (576 minus 20-byte IP header, minus 8-byte UDP header, assuming no IP options are used). STUN provides no ability to handle the case where the request is under the MTU but the response would be larger than the MTU. It is not envisioned that this limitation will be an issue for STUN. The MTU limitation is a SHOULD, and not a MUST, to account for cases where STUN itself is being used to probe for MTU characteristics [BEHAVE-NAT]. Outside of this or similar applications, the MTU constraint MUST be followed.
より経路MTUであって、あまり知られないで、すべてのSTUNメッセージがUDP SHOULDを移動しました。 経路MTUが未知のメッセージSHOULDであるなら、576バイトと最初に、ホップMTUでは、IPv4[RFC1122]と1280バイトにおいて、IPv6[RFC2460]のために、より小さくいてください。 この値はIPパケットの総合的なサイズに対応しています。 その結果、IPv4のために、実際のSTUNメッセージは、548バイト未満である必要があるでしょう(576のマイナス20バイトのIPヘッダー、8バイトのUDPヘッダーを引いて、IPを全く仮定しないで、オプションは使用されています)。 STUNはMTUの下に要求がありますが、応答がMTUより大きいケースを扱う能力を全く提供しません。 それは思い描かれません。この制限はSTUNのために問題になるでしょう。 MTU制限はSHOULDです、そして、どんなaもSHOULDであってはいけません、STUN自身がMTUの特性[BEHAVE-NAT]のために調べるのに使用されているケースのためのアカウントに。 これか同様のアプリケーションの外に、MTU規制に続かなければなりません。
7.2. Sending the Request or Indication
7.2. 要求か指示を送ります。
The agent then sends the request or indication. This document specifies how to send STUN messages over UDP, TCP, or TLS-over-TCP; other transport protocols may be added in the future. The STUN usage must specify which transport protocol is used, and how the agent determines the IP address and port of the recipient. Section 9 describes a DNS-based method of determining the IP address and port of a server that a usage may elect to use. STUN may be used with anycast addresses, but only with UDP and in usages where authentication is not used.
そして、エージェントは要求か指示を送ります。 このドキュメントはUDPの上のSTUNメッセージ、TCP、またはTLS過剰TCPを送る方法を指定します。 他のトランスポート・プロトコルは将来、加えられるかもしれません。 STUN用法は、どのトランスポート・プロトコルが使用されているか、そして、エージェントがどのように受取人のIPアドレスとポートを決定するかを指定しなければなりません。 セクション9はIPアドレスを決定するDNSベースのメソッドと用法が使用するのを選ぶかもしれないサーバのポートについて説明します。 STUNはanycastアドレスにもかかわらず、UDPだけと認証が使用されていない用法で使用されるかもしれません。
At any time, a client MAY have multiple outstanding STUN requests with the same STUN server (that is, multiple transactions in progress, with different transaction IDs). Absent other limits to the rate of new transactions (such as those specified by ICE for connectivity checks or when STUN is run over TCP), a client SHOULD space new transactions to a server by RTO and SHOULD limit itself to ten outstanding transactions to the same server.
いつでも、クライアントには、同じSTUNサーバによる複数の傑出しているSTUN要求があるかもしれません(それはそうです、進行中の多数の取引、異なったトランザクションIDで)。 それ自体で新しいトランザクション(接続性チェックかそれともSTUNがいつTCPの上に実行されるかとICEによって指定されたものなどの)のレート、RTOによるサーバへの新しいトランザクションとSHOULDが制限するクライアントSHOULDスペースへの他の限界を同じサーバへの10の傑出しているトランザクションに欠席してください。
7.2.1. Sending over UDP
7.2.1. UDPを移動します。
When running STUN over UDP, it is possible that the STUN message might be dropped by the network. Reliability of STUN request/ response transactions is accomplished through retransmissions of the
UDPの上にSTUNを実行するとき、STUNメッセージがネットワークによって下げられるのは、可能です。 STUN要求/応答トランザクションの信頼性は「再-トランスミッション」を通して達成されます。
Rosenberg, et al. Standards Track [Page 13] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[13ページ]RFC5389は2008年10月に気絶させます。
request message by the client application itself. STUN indications are not retransmitted; thus, indication transactions over UDP are not reliable.
クライアントアプリケーション自体でメッセージを要求してください。 STUN指摘は再送されません。 したがって、UDPの上の指示トランザクションは信頼できません。
A client SHOULD retransmit a STUN request message starting with an
interval of RTO ("Retransmission TimeOut"), doubling after each
retransmission. The RTO is an estimate of the round-trip time (RTT),
and is computed as described in RFC 2988 [RFC2988], with two
exceptions. First, the initial value for RTO SHOULD be configurable
(rather than the 3 s recommended in RFC 2988) and SHOULD be greater
than 500 ms. The exception cases for this "SHOULD" are when other
mechanisms are used to derive congestion thresholds (such as the ones
defined in ICE for fixed rate streams), or when STUN is used in non-
Internet environments with known network capacities. In fixed-line
access links, a value of 500 ms is RECOMMENDED. Second, the value of
RTO SHOULD NOT be rounded up to the nearest second. Rather, a 1 ms
accuracy SHOULD be maintained. As with TCP, the usage of Karn's
algorithm is RECOMMENDED [KARN87]. When applied to STUN, it means
that RTT estimates SHOULD NOT be computed from STUN transactions that
result in the retransmission of a request.
RTO(「再送タイムアウト」)の間隔から始めて、各「再-トランスミッション」の後に倍増して、クライアントSHOULDはSTUN要求メッセージを再送します。 RTOは往復の現代(RTT)の見積りであり、RFC2988[RFC2988]で説明されるように計算されます、2つの例外で。 RTO SHOULDに関して、構成可能であってください。最初に、初期の値、(この“SHOULD"が他のメカニズムが混雑敷居(定率ストリームのために氷で定義されたものなどの)を引き出すのに使用されるか、またはいつが気絶させられる時であるので500以上が原稿であったならRFC2988)とSHOULDで推薦されて、例外ケースが知られているネットワーク能力で非インターネットの環境で使用される3秒間よりむしろ。 固定系列アクセスリンクでは、500msの値はRECOMMENDEDです。 2番目、値、RTO SHOULD NOTでは、最も近い2番目まで一周してください。 むしろa1は精度SHOULDをmsします。維持されます。 TCPのように、Karnのアルゴリズムの用法はRECOMMENDED[KARN87]です。 STUNに適用されると、それは、RTTが、SHOULD NOTが要求の「再-トランスミッション」をもたらすSTUNトランザクションから計算されると見積もっていることを意味します。
The value for RTO SHOULD be cached by a client after the completion of the transaction, and used as the starting value for RTO for the next transaction to the same server (based on equality of IP address). The value SHOULD be considered stale and discarded after 10 minutes.
値、RTO SHOULDに関しては、トランザクションの完成の後にクライアントによってキャッシュされていて、RTOのための始動している値として次のトランザクションにおいて同じサーバに使用されてください(IPアドレスの平等に基づいています)。 聞き古したである考えられて、10分後に捨てられた値のSHOULD。
Retransmissions continue until a response is received, or until a total of Rc requests have been sent. Rc SHOULD be configurable and SHOULD have a default of 7. If, after the last request, a duration equal to Rm times the RTO has passed without a response (providing ample time to get a response if only this final request actually succeeds), the client SHOULD consider the transaction to have failed. Rm SHOULD be configurable and SHOULD have a default of 16. A STUN transaction over UDP is also considered failed if there has been a hard ICMP error [RFC1122]. For example, assuming an RTO of 500 ms, requests would be sent at times 0 ms, 500 ms, 1500 ms, 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has not received a response after 39500 ms, the client will consider the transaction to have timed out.
Retransmissionsを応答が受け取られているまで続くか、またはRc要求の合計まで送りました。 Rc SHOULD、構成可能にしてください、そして、SHOULDは7のデフォルトを持っています。 最後の要求の後にRm回と等しい持続時間であるなら、RTOは応答(この最終的な要求だけが実際に成功するなら、返事をもらう十分な時間を提供します)(SHOULDが、トランザクションが失敗したと考えるクライアント)なしで通りました。 Rm SHOULD、構成可能にしてください、そして、SHOULDは16のデフォルトを持っています。 また、困難なICMP誤り[RFC1122]があったなら、UDPの上のSTUNトランザクションは失敗されていると考えられます。 例えば、500のRTOがmsして、要求が回0のms、500ms、1500ms、3500ms、7500ms、15500ms、および31500で送られると仮定して、クライアントのIfにはある原稿は39500msの後に応答を受けないで、クライアントは、調節したトランザクションが出ていると考えるでしょう。
7.2.2. Sending over TCP or TLS-over-TCP
7.2.2. TCPかTLS過剰TCPを移動します。
For TCP and TLS-over-TCP, the client opens a TCP connection to the server.
TCPとTLS過剰TCPに関しては、クライアントはTCP接続をサーバに開きます。
Rosenberg, et al. Standards Track [Page 14] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[14ページ]RFC5389は2008年10月に気絶させます。
In some usages of STUN, STUN is sent as the only protocol over the TCP connection. In this case, it can be sent without the aid of any additional framing or demultiplexing. In other usages, or with other extensions, it may be multiplexed with other data over a TCP connection. In that case, STUN MUST be run on top of some kind of framing protocol, specified by the usage or extension, which allows for the agent to extract complete STUN messages and complete application layer messages. The STUN service running on the well- known port or ports discovered through the DNS procedures in Section 9 is for STUN alone, and not for STUN multiplexed with other data. Consequently, no framing protocols are used in connections to those servers. When additional framing is utilized, the usage will specify how the client knows to apply it and what port to connect to. For example, in the case of ICE connectivity checks, this information is learned through out-of-band negotiation between client and server.
STUNのいくつかの使用法で、唯一のプロトコルとしてTCP接続の上にSTUNを送ります。 この場合、どんな追加縁どりや逆多重化の援助なしでもそれを送ることができます。 他の用法、または他の拡大で、他のデータと共にTCP接続の上にそれを多重送信するかもしれません。 その場合、STUN MUSTはエージェントが完全なSTUNメッセージを抜粋するのを許容する用法か拡大で指定されたプロトコルをある種縁どる上で実行されて、応用層メッセージを完成します。 セクション9のDNS手順で発見されたよく知られているポートかポートで走るSTUNサービスは単独で他のデータと共に多重送信されたSTUNではなく、STUNのためのものです。 その結果、縁どりプロトコルは全く接続にそれらのサーバに使用されません。 追加縁どりが利用されているとき、用法はクライアントが、それを適用するのをどのように知るか、そして、どんなポートに接続するかを指定するでしょう。 例えば、ICE接続性チェックの場合では、この情報はクライアントとサーバとのバンドの外を通した学術的交渉です。
When STUN is run by itself over TLS-over-TCP, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented at a minimum. Implementations MAY also support any other ciphersuite. When it receives the TLS Certificate message, the client SHOULD verify the certificate and inspect the site identified by the certificate. If the certificate is invalid or revoked, or if it does not identify the appropriate party, the client MUST NOT send the STUN message or otherwise proceed with the STUN transaction. 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 [RFC2818]. 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 8.1 as the host portion of the URI that has been dereferenced. Alternatively, a client MAY be configured with a set of domains or IP addresses that are trusted; if a certificate is received that identifies one of those domains or IP addresses, the client considers the identity of the server to be verified.
_STUNがTLS過剰TCP、TLS_の上でそれ自体でRSA_WITH_AES_128を実行することであるときに、最小限でCBC_SHA ciphersuiteを実装しなければなりません。 また、実装はいかなる他のciphersuiteもサポートするかもしれません。 TLS Certificateメッセージを受け取るとき、クライアントSHOULDは証明書について確かめて、証明書によって特定されたサイトを点検します。 適切なパーティーを特定しないなら、証明書が無効であるか取り消されるなら、クライアントは、STUNメッセージを送ってはいけませんし、またそうでなければ、STUNトランザクションを続けてはいけません。 クライアントはサーバのアイデンティティについて確かめなければなりません。それをするために、識別手順がRFC2818のセクション3.1で[RFC2818]を定義したということになります。 それらの手順は、クライアントがURIに「反-参照をつけ」ていると仮定します。 この仕様がある用法の目的のために、クライアントは「反-参照をつけ」られたURIのホスト部分としてセクション8.1で使用されるドメイン名かIPアドレスを扱います。 あるいはまた、クライアントは信じられる1セットのドメインかIPアドレスによって構成されるかもしれません。 証明書が受け取られているなら、それはそれらのドメインかIPアドレスの1つを特定して、クライアントは、サーバのアイデンティティが確かめられると考えます。
When STUN is run multiplexed with other protocols over a TLS-over-TCP connection, the mandatory ciphersuites and TLS handling procedures operate as defined by those protocols.
STUNが他のプロトコルと共にTLS過剰TCP接続の上に多重送信された走行であるときに、義務的なciphersuitesとTLS取り扱い手順はそれらのプロトコルによって定義されるように作動します。
Reliability of STUN over TCP and TLS-over-TCP is handled by TCP itself, and there are no retransmissions at the STUN protocol level. However, for a request/response transaction, if the client has not received a response by Ti seconds after it sent the SYN to establish the connection, it considers the transaction to have timed out. Ti SHOULD be configurable and SHOULD have a default of 39.5s. This value has been chosen to equalize the TCP and UDP timeouts for the default initial RTO.
TCPの上のSTUNとTLS過剰TCPの信頼性はTCP自身によって扱われます、そして、「再-トランスミッション」が全くSTUNプロトコルレベルにありません。 しかしながら、要求/応答トランザクションのために、接続を証明するためにSYNを送った秒後にクライアントがTiによる応答を受けていないなら、それは、調節したトランザクションが出ていると考えます。 Ti SHOULD、構成可能にしてください、そして、SHOULDは39.5のデフォルトを持っています。 この値は、デフォルトの初期のRTOのためにTCPとUDPタイムアウトを均等化するために選ばれました。
Rosenberg, et al. Standards Track [Page 15] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[15ページ]RFC5389は2008年10月に気絶させます。
In addition, if the client is unable to establish the TCP connection, or the TCP connection is reset or fails before a response is received, any request/response transaction in progress is considered to have failed.
さらに、クライアントがTCP接続を確立できないか、または応答が受け取られている前に、TCP接続がリセットされるか、失敗するなら、進行中のどんな要求/応答トランザクションも失敗したと考えられます。
The client MAY send multiple transactions over a single TCP (or TLS- over-TCP) connection, and it MAY send another request before receiving a response to the previous. The client SHOULD keep the connection open until it:
クライアントは独身のTCP(または、TLS過剰TCP)接続の上に多数の取引を送るかもしれません、そして、前への応答を受ける前に、それは別の要求を送るかもしれません。 クライアントSHOULDはそれまで接続を開くように保ちます:
o has no further STUN requests or indications to send over that
connection, and
o そしてこれ以上その接続の上で送るSTUN要求か指摘を持っていない。
o has no plans to use any resources (such as a mapped address
(MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) or relayed address
[BEHAVE-TURN]) that were learned though STUN requests sent over
that connection, and
o そしてSTUN要求がその接続を移動しましたが、学習されたどんなリソース(写像しているアドレス(MAPPED-ADDRESSかXOR-MAPPED-ADDRESS)かリレーされたアドレス[BEHAVE-TURN]などの)も使用する計画を全く持っていない。
o if multiplexing other application protocols over that port, has
finished using that other application, and
o そしてそれの上のプロトコルが移植して、その他のアプリケーションを使用するのを完成させた他のアプリケーションを多重送信するなら。
o if using that learned port with a remote peer, has established
communications with that remote peer, as is required by some TCP
NAT traversal techniques (e.g., [MMUSIC-ICE-TCP]).
o 使用するなら、それは、リモート同輩と共にポートを学んで、そのリモート同輩と共にコミュニケーションを確立しました、いくつかのTCP NAT縦断のテクニック(例えば、[MMUSIC-ICE-TCP])が必要であるように。
At the server end, the server SHOULD keep the connection open, and let the client close it, unless the server has determined that the connection has timed out (for example, due to the client disconnecting from the network). Bindings learned by the client will remain valid in intervening NATs only while the connection remains open. Only the client knows how long it needs the binding. The server SHOULD NOT close a connection if a request was received over that connection for which a response was not sent. A server MUST NOT ever open a connection back towards the client in order to send a response. Servers SHOULD follow best practices regarding connection management in cases of overload.
サーバ終わりに、サーバSHOULDはクライアントに接続を開くように保って、それを閉じさせることができます、サーバが、接続は外(例えばネットワークから切断するクライアントのため)で時間があることを決定していない場合。 接続が開いたままで残っているだけである間、クライアントによって学習された結合は介入しているNATsで有効なままで残るでしょう。 クライアントだけが、それがどれくらい長い間結合を必要とするかを知っています。 応答が送られなかったその接続の上に要求を受け取ったなら、サーバSHOULD NOTは接続を終えます。 サーバは、応答を送るためにクライアントに向かって接続を公開して戻してはいけません。 サーバSHOULDはオーバーロードの場合における接続管理に関して最も良い習慣に続きます。
7.3. Receiving a STUN Message
7.3. aを受けて、メッセージを気絶させてください。
This section specifies the processing of a STUN message. The processing specified here is for STUN messages as defined in this specification; additional rules for backwards compatibility are defined in Section 12. Those additional procedures are optional, and usages can elect to utilize them. First, a set of processing operations is applied that is independent of the class. This is followed by class-specific processing, described in the subsections that follow.
このセクションはSTUNメッセージの処理を指定します。 ここで指定された処理はこの仕様に基づき定義されるようにSTUNメッセージのためのものです。 遅れている互換性のための付則はセクション12で定義されます。 それらの追加手順は任意です、そして、用法はそれらを利用するのを選ぶことができます。 最初に、適用された1セットのクラスから独立している加工作業。 続く小区分で説明されたクラス特有の処理はこれのあとに続いています。
Rosenberg, et al. Standards Track [Page 16] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[16ページ]RFC5389は2008年10月に気絶させます。
When a STUN agent receives a STUN message, it first checks that the message obeys the rules of Section 6. It checks that the first two bits are 0, that the magic cookie field has the correct value, that the message length is sensible, and that the method value is a supported method. It checks that the message class is allowed for the particular method. If the message class is "Success Response" or "Error Response", the agent checks that the transaction ID matches a transaction that is still in progress. If the FINGERPRINT extension is being used, the agent checks that the FINGERPRINT attribute is present and contains the correct value. If any errors are detected, the message is silently discarded. In the case when STUN is being multiplexed with another protocol, an error may indicate that this is not really a STUN message; in this case, the agent should try to parse the message as a different protocol.
STUNエージェントがSTUNメッセージを受け取るとき、メッセージがセクション6の規則に従うのは最初に、チェックします。 最初の2ビットが0であり、魔法のクッキー分野には正しい値があって、メッセージ長が分別があって、メソッド値がサポートしているメソッドであることがチェックします。 メッセージのクラスが特定のメソッドのために許容されているのはチェックします。 メッセージであるなら、クラスは「成功応答」であるか「誤り応答」、エージェントは、トランザクションIDがまだ進行しているトランザクションに合っているのをチェックします。 FINGERPRINT拡張子が使用されているなら、エージェントは、FINGERPRINT属性が存在しているのをチェックして、正しい値を含みます。 何か誤りが検出されるなら、メッセージは静かに捨てられます。 別のプロトコルと共にSTUNを多重送信しているときの場合では、誤りは、これが本当にSTUNメッセージでないことを示すかもしれません。 この場合、エージェントは異なったプロトコルとしてメッセージを分析しようとするべきです。
The STUN agent then does any checks that are required by a authentication mechanism that the usage has specified (see Section 10).
そして、STUNエージェントは用法が指定した認証機構によって必要とされるチェックをします(セクション10を見てください)。
Once the authentication checks are done, the STUN agent checks for unknown attributes and known-but-unexpected attributes in the message. Unknown comprehension-optional attributes MUST be ignored by the agent. Known-but-unexpected attributes SHOULD be ignored by the agent. Unknown comprehension-required attributes cause processing that depends on the message class and is described below.
STUNエージェントは、メッセージの未知の属性と知られていますが、予期していなかった属性がないかどうか一度、認証チェックをするのをチェックします。 エージェントは未知の読解任意の属性を無視しなければなりません。 知られていますが、予期していなかった属性SHOULD、エージェントによって無視されてください。 それを処理する未知の読解で必要な属性原因が、メッセージのクラスに依存して、以下で説明されます。
At this point, further processing depends on the message class of the request.
ここに、さらなる処理は要求のメッセージのクラスに依存します。
7.3.1. Processing a Request
7.3.1. 要求を処理します。
If the request contains one or more unknown comprehension-required attributes, the server replies with an error response with an error code of 420 (Unknown Attribute), and includes an UNKNOWN-ATTRIBUTES attribute in the response that lists the unknown comprehension- required attributes.
要求が1つ以上の未知の読解で必要な属性、420(未知のAttribute)のエラーコードによる誤り応答によるサーバ回答を含んでいて、記載する応答にUNKNOWN-ATTRIBUTES属性を含んでいるなら、未知読解は属性を必要としました。
The server then does any additional checking that the method or the specific usage requires. If all the checks succeed, the server formulates a success response as described below.
そして、サーバはメソッドか特定の用法が必要とする追加照合をします。 すべてのチェックが成功するなら、サーバは以下で説明されるように成功応答を定式化します。
When run over UDP, a request received by the server could be the first request of a transaction, or a retransmission. The server MUST respond to retransmissions such that the following property is preserved: if the client receives the response to the retransmission and not the response that was sent to the original request, the overall state on the client and server is identical to the case where only the response to the original retransmission is received, or
UDPの上に実行されると、サーバによって受け取られた要求は、トランザクションの最初の要求、または「再-トランスミッション」であるかもしれません。 サーバが「再-トランスミッション」に反応しなければならないので、以下の特性は保持されます: またはクライアントがオリジナルの要求に送られた応答ではなく、「再-トランスミッション」への応答を受けるなら、クライアントとサーバの総合的な状態がオリジナルの「再-トランスミッション」への応答だけが受け取られているケースと同じである。
Rosenberg, et al. Standards Track [Page 17] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[17ページ]RFC5389は2008年10月に気絶させます。
where both responses are received (in which case the client will use the first). The easiest way to meet this requirement is for the server to remember all transaction IDs received over UDP and their corresponding responses in the last 40 seconds. However, this requires the server to hold state, and will be inappropriate for any requests which are not authenticated. Another way is to reprocess the request and recompute the response. The latter technique MUST only be applied to requests that are idempotent (a request is considered idempotent when the same request can be safely repeated without impacting the overall state of the system) and result in the same success response for the same request. The Binding method is considered to be idempotent. Note that there are certain rare network events that could cause the reflexive transport address value to change, resulting in a different mapped address in different success responses. Extensions to STUN MUST discuss the implications of request retransmissions on servers that do not store transaction state.
両方の応答が受け取られている(その場合、クライアントは1番目を使用するでしょう)ところ。 この必要条件を満たす最も簡単な方法はサーバが最後の40秒でUDPの上に受け取られたすべてのトランザクションIDと彼らの対応する応答を覚えていることです。 しかしながら、これは、状態を保持するためにサーバを必要として、認証されないどんな要求にも不適当になるでしょう。 別の方法は「再-プロセス」への要求であり、recomputeは応答です。 同じ要求のための同じ成功応答におけるベキ等元(安全にシステムの総合的な事情に影響を与えないで同じ要求を繰り返すことができるとき、要求はベキ等元であると考えられる)である要求と結果に後者のテクニックを適用するだけでよいです。 Bindingメソッドはベキ等元であると考えられます。 再帰の輸送アドレス値が変化できたあるまれなネットワークイベントがあることに注意してください、異なった成功応答における異なった写像しているアドレスをもたらして。 STUN MUSTへの拡大はトランザクション状態を保存しないサーバで要求「再-トランスミッション」の含意について議論します。
7.3.1.1. Forming a Success or Error Response
7.3.1.1. 成功か誤り応答を形成します。
When forming the response (success or error), the server follows the rules of Section 6. The method of the response is the same as that of the request, and the message class is either "Success Response" or "Error Response".
応答(成功か誤り)を形成するとき、サーバはセクション6の規則に従います。 メッセージのクラスは、応答のメソッドが要求のものと同じであり、「成功応答」か「誤り応答」のどちらかです。
For an error response, the server MUST add an ERROR-CODE attribute containing the error code specified in the processing above. The reason phrase is not fixed, but SHOULD be something suitable for the error code. For certain errors, additional attributes are added to the message. These attributes are spelled out in the description where the error code is specified. For example, for an error code of 420 (Unknown Attribute), the server MUST include an UNKNOWN- ATTRIBUTES attribute. Certain authentication errors also cause attributes to be added (see Section 10). Extensions may define other errors and/or additional attributes to add in error cases.
誤り応答のために、サーバは、エラーコードを含むERROR-CODE属性が上の処理で指定したと言い足さなければなりません。 ものがエラーコードに何か適していたなら、修理されなかった句、しかし、SHOULDを推論してください。 ある誤りにおいて、追加属性はメッセージに追加されます。 これらの属性は記述におけるエラーコードが指定される外につづられます。 例えば、420(未知のAttribute)のエラーコードのために、サーバはUNKNOWN- ATTRIBUTES属性を含まなければなりません。 また、ある認証誤りで、属性を加えます(セクション10を見てください)。 拡大は、誤り事件を加えるために他の誤り、そして/または、追加属性を定義するかもしれません。
If the server authenticated the request using an authentication mechanism, then the server SHOULD add the appropriate authentication attributes to the response (see Section 10).
サーバが認証機構を使用することで要求を認証したなら、サーバSHOULDは適切な認証属性を応答に加えます(セクション10を見てください)。
The server also adds any attributes required by the specific method or usage. In addition, the server SHOULD add a SOFTWARE attribute to the message.
また、サーバは、どんな属性も特定のメソッドか用法が必要であると言い足します。 さらに、サーバSHOULDはSOFTWARE属性をメッセージに追加します。
For the Binding method, no additional checking is required unless the usage specifies otherwise. When forming the success response, the server adds a XOR-MAPPED-ADDRESS attribute to the response, where the contents of the attribute are the source transport address of the
Bindingメソッドにおいて、用法が別の方法で指定しない場合、どんな追加照合も必要ではありません。 成功応答を形成して、サーバはいつで応答へのXOR-MAPPED-ADDRESS属性を加えるか。そこでは、属性の内容がソース輸送アドレスです。
Rosenberg, et al. Standards Track [Page 18] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[18ページ]RFC5389は2008年10月に気絶させます。
request message. For UDP, this is the source IP address and source UDP port of the request message. For TCP and TLS-over-TCP, this is the source IP address and source TCP port of the TCP connection as seen by the server.
メッセージを要求してください。 UDPに関しては、これはアドレスとソースUDPが移植する要求メッセージのソースIPです。 TCPとTLS過剰TCPに関しては、これはアドレスとソースTCPが移植するサーバによって見られるTCP接続のソースIPです。
7.3.1.2. Sending the Success or Error Response
7.3.1.2. 成功か誤りに応答を送ります。
The response (success or error) is sent over the same transport as the request was received on. If the request was received over UDP, the destination IP address and port of the response are the source IP address and port of the received request message, and the source IP address and port of the response are equal to the destination IP address and port of the received request message. If the request was received over TCP or TLS-over-TCP, the response is sent back on the same TCP connection as the request was received on.
応答(成功か誤り)は移動されて、要求と同じ輸送のときに受け取ったということです。 UDPの上に要求を受け取ったなら、応答の送付先IPアドレスとポートは、受信された要求メッセージのソースIPアドレスとポートです、そして、応答のソースIPアドレスとポートは受信された要求メッセージの送付先IPアドレスとポートと等しいです。 TCPの上に要求を受け取ったか、そして、TLS過剰TCP、応答は要求としてのTCP接続が受け取られていた同じくらいで返送されます。
7.3.2. Processing an Indication
7.3.2. 指示を処理します。
If the indication contains unknown comprehension-required attributes, the indication is discarded and processing ceases.
指示が未知の読解で必要な属性を含んでいるなら、指示は捨てられます、そして、処理はやみます。
The agent then does any additional checking that the method or the specific usage requires. If all the checks succeed, the agent then processes the indication. No response is generated for an indication.
そして、エージェントはメソッドか特定の用法が必要とする追加照合をします。 すべてのチェックが成功するなら、エージェントは指示を処理します。 応答は全く指示のために生成されません。
For the Binding method, no additional checking or processing is required, unless the usage specifies otherwise. The mere receipt of the message by the agent has refreshed the "bindings" in the intervening NATs.
Bindingメソッドにおいて、用法が別の方法で指定しない場合、どんな追加照合も処理も必要ではありません。 エージェントによるメッセージの単なる領収書は介入しているNATsで「結合」をリフレッシュしました。
Since indications are not re-transmitted over UDP (unlike requests), there is no need to handle re-transmissions of indications at the sending agent.
指摘がUDP(要求と異なった)の上に再送されないので、送付エージェントで指摘の再送信を扱う必要は全くありません。
7.3.3. Processing a Success Response
7.3.3. 成功応答を処理します。
If the success response contains unknown comprehension-required attributes, the response is discarded and the transaction is considered to have failed.
成功応答が未知の読解で必要な属性を含んでいるなら、応答は捨てられます、そして、トランザクションが失敗したと考えられます。
The client then does any additional checking that the method or the specific usage requires. If all the checks succeed, the client then processes the success response.
そして、クライアントはメソッドか特定の用法が必要とする追加照合をします。 すべてのチェックが成功するなら、クライアントは成功応答を処理します。
For the Binding method, the client checks that the XOR-MAPPED-ADDRESS attribute is present in the response. The client checks the address family specified. If it is an unsupported address family, the
Bindingメソッドがないかどうか、クライアントは、XOR-MAPPED-ADDRESS属性が応答で存在しているのをチェックします。 クライアントは指定されたアドレスファミリーをチェックします。 それがサポートされないアドレスファミリーであるなら
Rosenberg, et al. Standards Track [Page 19] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[19ページ]RFC5389は2008年10月に気絶させます。
attribute SHOULD be ignored. If it is an unexpected but supported address family (for example, the Binding transaction was sent over IPv4, but the address family specified is IPv6), then the client MAY accept and use the value.
SHOULDを結果と考えてください。無視されます。 それが予期していなかったのですが、サポートしているアドレスファミリー(例えば、BindingトランザクションをIPv4の上に送りましたが、指定されたアドレスファミリーはIPv6である)であるなら、クライアントは、値を受け入れて、使用するかもしれません。
7.3.4. Processing an Error Response
7.3.4. 誤り応答を処理します。
If the error response contains unknown comprehension-required attributes, or if the error response does not contain an ERROR-CODE attribute, then the transaction is simply considered to have failed.
誤り応答がERROR-CODE属性を含んでいないなら誤り応答が未知の読解で必要な属性を含んでいるなら、トランザクションが失敗したと単に考えられます。
The client then does any processing specified by the authentication mechanism (see Section 10). This may result in a new transaction attempt.
そして、クライアントは認証機構によって指定されたどんな処理もします(セクション10を見てください)。 これは新しいトランザクション試みをもたらすかもしれません。
The processing at this point depends on the error code, the method, and the usage; the following are the default rules:
処理をここにエラーコード、メソッド、および用法に依存します。 ↓これは省略時の解釈です:
o If the error code is 300 through 399, the client SHOULD consider
the transaction as failed unless the ALTERNATE-SERVER extension is
being used. See Section 11.
o エラーコードが300〜399であり、ALTERNATE-SERVER拡張子が使用されていない場合、クライアントSHOULDは、トランザクションに失敗されているとみなします。 セクション11を見てください。
o If the error code is 400 through 499, the client declares the
transaction failed; in the case of 420 (Unknown Attribute), the
response should contain a UNKNOWN-ATTRIBUTES attribute that gives
additional information.
o エラーコードが400〜499であるなら、クライアントは、トランザクションに失敗されていると宣言します。 420(未知のAttribute)の場合では、応答は追加情報を与えるUNKNOWN-ATTRIBUTES属性を含むべきです。
o If the error code is 500 through 599, the client MAY resend the
request; clients that do so MUST limit the number of times they do
this.
o エラーコードが500〜599であるなら、クライアントは要求を再送するかもしれません。 そうするクライアントは彼らがこれをする回数を制限しなければなりません。
Any other error code causes the client to consider the transaction failed.
いかなる他のエラーコードでも、クライアントは、トランザクションに失敗されていると考えます。
8. FINGERPRINT Mechanism
8. 指紋メカニズム
This section describes an optional mechanism for STUN that aids in distinguishing STUN messages from packets of other protocols when the two are multiplexed on the same transport address. This mechanism is optional, and a STUN usage must describe if and when it is used. The FINGERPRINT mechanism is not backwards compatible with RFC 3489, and cannot be used in environments where such compatibility is required.
このセクションは同じ輸送アドレスで2を多重送信するとき他のプロトコルのパケットとSTUNメッセージを区別する際に支援するSTUNのために任意のメカニズムについて説明します。 このメカニズムは任意です、そして、STUN用法はそれが使用されているかどうか説明しなければなりません。 FINGERPRINTメカニズムは、後方にRFC3489と互換性があった状態でなくて、そのような互換性が必要である環境で使用できません。
In some usages, STUN messages are multiplexed on the same transport address as other protocols, such as the Real Time Transport Protocol (RTP). In order to apply the processing described in Section 7, STUN messages must first be separated from the application packets.
いくつかの用法で、他のプロトコルと同じ輸送アドレスでSTUNメッセージを多重送信します、レアルTime Transportプロトコル(RTP)などのように。 セクション7で説明された処理を適用するために、最初に、アプリケーションパケットとSTUNメッセージを切り離さなければなりません。
Rosenberg, et al. Standards Track [Page 20] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[20ページ]RFC5389は2008年10月に気絶させます。
Section 6 describes three fixed fields in the STUN header that can be used for this purpose. However, in some cases, these three fixed fields may not be sufficient.
セクション6はこのために使用できるSTUNヘッダーの3つの固定分野について説明します。 しかしながら、いくつかの場合、これらの3つの固定分野は十分でないかもしれません。
When the FINGERPRINT extension is used, an agent includes the FINGERPRINT attribute in messages it sends to another agent. Section 15.5 describes the placement and value of this attribute. When the agent receives what it believes is a STUN message, then, in addition to other basic checks, the agent also checks that the message contains a FINGERPRINT attribute and that the attribute contains the correct value. Section 7.3 describes when in the overall processing of a STUN message the FINGERPRINT check is performed. This additional check helps the agent detect messages of other protocols that might otherwise seem to be STUN messages.
FINGERPRINT拡張子が使用されているとき、エージェントはそれが別のエージェントに送るメッセージでFINGERPRINT属性を入れます。 セクション15.5はこの属性のプレースメントと値について説明します。 また、エージェントがそれが次に、他の基本的なチェックに加えたSTUNメッセージであると信じているものを受けるとき、エージェントは、メッセージがFINGERPRINT属性を含んでいて、属性が正しい値を含むのをチェックします。 セクション7.3は、STUNメッセージの総合的な処理では、FINGERPRINTチェックがいつ実行されるかを説明します。 この追加チェックは、エージェントが別の方法でSTUNメッセージであるように思えるかもしれない他のプロトコルに関するメッセージを検出するのを助けます。
9. DNS Discovery of a Server
9. サーバのDNS発見
This section describes an optional procedure for STUN that allows a client to use DNS to determine the IP address and port of a server. A STUN usage must describe if and when this extension is used. To use this procedure, the client must know a server's domain name and a service name; the usage must also describe how the client obtains these. Hard-coding the domain name of the server into software is NOT RECOMMENDED in case the domain name is lost or needs to change for legal or other reasons.
このセクションはクライアントにサーバのIPアドレスとポートを決定するのにDNSを使用させるSTUNのために任意の手順について説明します。STUN用法は、この拡大が使用されているかどうか説明しなければなりません。 この手順を用いるために、クライアントはサーバのドメイン名とサービス名を知らなければなりません。 また、用法はクライアントがどうこれらを得るかを説明しなければなりません。 一生懸命コード化している、ソフトウェアへのサーバのドメイン名は、ドメイン名が無くなるといけないのでNOT RECOMMENDEDであるか法的であるか他の理由で変化する必要があります。
When a client wishes to locate a STUN server in the public Internet that accepts Binding request/response transactions, the SRV service name is "stun". When it wishes to locate a STUN server that accepts Binding request/response transactions over a TLS session, the SRV service name is "stuns". STUN usages MAY define additional DNS SRV service names.
クライアントがBinding要求/応答トランザクションを受け入れる公共のインターネットでSTUNサーバの場所を見つけたがっているとき、SRVサービス名は「気絶させてください」です。 TLSセッションの間にBinding要求/応答トランザクションを受け入れるSTUNサーバの場所を見つけたがっているとき、存在というSRVサービス名は「気絶させられます」。 STUN用法は追加DNS SRVサービス名を定義するかもしれません。
The domain name is resolved to a transport address using the SRV procedures specified in [RFC2782]. The DNS SRV service name is the service name provided as input to this procedure. The protocol in the SRV lookup is the transport protocol the client will run STUN over: "udp" for UDP and "tcp" for TCP. Note that only "tcp" is defined with "stuns" at this time.
ドメイン名は、[RFC2782]で指定されたSRV手順を用いることで輸送アドレスに決議されています。 DNS SRVサービス名はこの手順に入力されるように提供というサービス名です。 SRVルックアップにおけるプロトコルはクライアントがSTUNを実行するトランスポート・プロトコルです: UDPのための"udp"とTCPのための"tcp"。 "tcp"だけ、が定義される注意はこのとき、「気絶させられます」。
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 is sorted and then tried. However, RFC 2782 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. When following these procedures, if the STUN transaction times out without receipt of a response, the client SHOULD retry the request to
RFC2782の手順は、接触へのサーバを決定するために従われています。 RFC2782は1セットのSRV記録がどう分類されて、次に、試みられるかに関する詳細についてスペルアウトします。 しかしながら、RFC2782が、クライアントがそうするべきであると述べるだけである、「接続しようとする、(プロトコル、アドレス、サービス) 」 何が失敗の場合、起こるかに関するどんな詳細も述べないで。 応答の領収書がなければSTUNトランザクション回数であるならこれらの手順に従って、クライアントSHOULDはいつまで要求を再試行しますか。
Rosenberg, et al. Standards Track [Page 21] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[21ページ]RFC5389は2008年10月に気絶させます。
the next server in the ordered defined by RFC 2782. Such a retry is only possible for request/response transmissions, since indication transactions generate no response or timeout.
RFC2782によって定義された命令の次のサーバ。 指示トランザクションがどんな応答もタイムアウトも生成しないので、要求/応答送信だけに、そのような再試行は可能です。
The default port for STUN requests is 3478, for both TCP and UDP.
STUN要求のためのデフォルトポートはTCPとUDPの両方のための3478です。
Administrators of STUN servers SHOULD use this port in their SRV records for UDP and TCP. In all cases, the port in DNS MUST reflect the one on which the server is listening. The default port for STUN over TLS is 5349. Servers can run STUN over TLS on the same port as STUN over TCP if the server software supports determining whether the initial message is a TLS or STUN message.
STUNサーバSHOULDの管理者はUDPとTCPにそれらのSRV記録でこのポートを使用します。 全部で、ケース、DNS MUSTのポートはサーバが聴かれているものを反映します。 TLSの上のSTUNのためのデフォルトポートは5349です。 サーバソフトウェアが、初期のメッセージがTLSであるかどうか決定するか、STUNがメッセージであるとサポートするなら、サーバはSTUNとしてTCPの上で同じポートの上のTLSの上にSTUNを実行できます。
If no SRV records were found, the client performs an A or AAAA 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 using UDP or TCP, independent of the STUN usage. For usages that require TLS, the client connects to one of the IP addresses using the default STUN over TLS port.
SRV記録が全く見つけられなかったか、クライアントがAを実行するか、またはAAAAがドメイン名のルックアップを記録するなら。 結果はIPアドレスのリストになるでしょう、STUN用法の如何にかかわらず。UDPかTCPを使用することでそれぞれデフォルトポートへそれに連絡できます。 TLSを必要とする用法のために、クライアントは、TLSポートの上でデフォルトSTUNを使用することでIPアドレスの1つに接続します。
10. Authentication and Message-Integrity Mechanisms
10. 認証とメッセージの保全メカニズム
This section defines two mechanisms for STUN that a client and server can use to provide authentication and message integrity; these two mechanisms are known as the short-term credential mechanism and the long-term credential mechanism. These two mechanisms are optional, and each usage must specify if and when these mechanisms are used. Consequently, both clients and servers will know which mechanism (if any) to follow based on knowledge of which usage applies. For example, a STUN server on the public Internet supporting ICE would have no authentication, whereas the STUN server functionality in an agent supporting connectivity checks would utilize short-term credentials. An overview of these two mechanisms is given in Section 3.
このセクションはクライアントとサーバが認証とメッセージの保全を提供するのに使用できるSTUNのために2つのメカニズムを定義します。 これらの2つのメカニズムが短期的な資格証明メカニズムと長期の資格証明メカニズムとして知られています。 これらの2つのメカニズムが任意です、そして、各用法はこれらのメカニズムが使用されているかどうか指定しなければなりません。 その結果、クライアントとサーバの両方が、用法が適用される知識に基づいてどのメカニズム(もしあれば)に従ったらよいかを知るでしょう。 例えば、ICEをサポートする公共のインターネットのSTUNサーバには、認証が全くないでしょうが、接続性チェックをサポートするエージェントのSTUNサーバの機能性は短期的な資格証明書を利用するでしょう。 セクション3でこれらの2つのメカニズムの概要を与えます。
Each mechanism specifies the additional processing required to use that mechanism, extending the processing specified in Section 7. The additional processing occurs in three different places: when forming a message, when receiving a message immediately after the basic checks have been performed, and when doing the detailed processing of error responses.
各メカニズムはセクション7で指定された処理を広げて、そのメカニズムを使用するのに必要である追加処理を指定します。 追加処理は3つの異なった場所で起こります: 誤り応答の詳細な処理をしながらメッセージ、直後のメッセージを受け取って、基本的なチェックがいつ実行されるか、そして、およびいつを形成するかとき。
10.1. Short-Term Credential Mechanism
10.1. 短期的な資格証明メカニズム
The short-term credential mechanism assumes that, prior to the STUN transaction, the client and server have used some other protocol to exchange a credential in the form of a username and password. This credential is time-limited. The time limit is defined by the usage.
短期的な資格証明メカニズムは、クライアントとサーバがSTUNトランザクションの前にユーザ名とパスワードの形で資格証明書を交換するのにある他のプロトコルを使用したと仮定します。 この資格証明書は期日です。 タイムリミットは用法で定義されます。
Rosenberg, et al. Standards Track [Page 22] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[22ページ]RFC5389は2008年10月に気絶させます。
As an example, in the ICE usage [MMUSIC-ICE], the two endpoints use out-of-band signaling to agree on a username and password, and this username and password are applicable for the duration of the media session.
例として、ICE用法[MMUSIC-ICE]で、2つの終点がユーザ名とパスワードに同意するのにバンドの外でシグナリングを使用します、そして、メディアセッションの持続時間に、このユーザ名とパスワードは適切です。
This credential is used to form a message-integrity check in each request and in many responses. There is no challenge and response as in the long-term mechanism; consequently, replay is prevented by virtue of the time-limited nature of the credential.
この資格証明書は、各要求と多くの応答におけるメッセージの保全チェックを形成するのに使用されます。 挑戦と応答が全く長期のメカニズムのようにありません。 その結果、再生は資格証明書の期日本質によって防がれます。
10.1.1. Forming a Request or Indication
10.1.1. 要求か指示を形成します。
For a request or indication message, the agent MUST include the USERNAME and MESSAGE-INTEGRITY attributes in the message. The HMAC for the MESSAGE-INTEGRITY attribute is computed as described in Section 15.4. Note that the password is never included in the request or indication.
要求か指示メッセージに関しては、エージェントはメッセージでUSERNAMEとMESSAGE-INTEGRITY属性を入れなければなりません。 MESSAGE-INTEGRITY属性のためのHMACはセクション15.4で説明されるように計算されます。 パスワードが要求か指示に決して含まれていないことに注意してください。
10.1.2. Receiving a Request or Indication
10.1.2. 要求か指示を受け取ります。
After the agent has done the basic processing of a message, the agent performs the checks listed below in order specified:
エージェントがメッセージの基本的な処理をした後に、エージェントは指定されていた状態で以下に整然とした状態で記載されたチェックを実行します:
o If the message does not contain both a MESSAGE-INTEGRITY and a
USERNAME attribute:
o メッセージがMESSAGE-INTEGRITYとUSERNAMEの両方を含まないなら、以下を結果と考えてください。
* If the message is a request, the server MUST reject the request
with an error response. This response MUST use an error code
of 400 (Bad Request).
* メッセージが要求であるなら、サーバは誤り応答で要求を拒絶しなければなりません。 この応答は400(悪いRequest)のエラーコードを使用しなければなりません。
* If the message is an indication, the agent MUST silently
discard the indication.
* メッセージが指示であるなら、エージェントは静かに指示を捨てなければなりません。
o If the USERNAME does not contain a username value currently valid
within the server:
o USERNAMEが現在サーバの中で有効なユーザ名値を含んでいないなら:
* If the message is a request, the server MUST reject the request
with an error response. This response MUST use an error code
of 401 (Unauthorized).
* メッセージが要求であるなら、サーバは誤り応答で要求を拒絶しなければなりません。 この応答は401(権限のない)のエラーコードを使用しなければなりません。
* If the message is an indication, the agent MUST silently
discard the indication.
* メッセージが指示であるなら、エージェントは静かに指示を捨てなければなりません。
o Using the password associated with the username, compute the value
for the message integrity as described in Section 15.4. If the
resulting value does not match the contents of the MESSAGE-
INTEGRITY attribute:
o ユーザ名に関連しているパスワードを使用して、メッセージの保全のためにセクション15.4で説明されるように値を計算してください。 結果として起こる値がMESSAGE- INTEGRITYのコンテンツに合っていないなら、以下を結果と考えてください。
Rosenberg, et al. Standards Track [Page 23] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[23ページ]RFC5389は2008年10月に気絶させます。
* If the message is a request, the server MUST reject the request
with an error response. This response MUST use an error code
of 401 (Unauthorized).
* メッセージが要求であるなら、サーバは誤り応答で要求を拒絶しなければなりません。 この応答は401(権限のない)のエラーコードを使用しなければなりません。
* If the message is an indication, the agent MUST silently
discard the indication.
* メッセージが指示であるなら、エージェントは静かに指示を捨てなければなりません。
If these checks pass, the agent continues to process the request or indication. Any response generated by a server MUST include the MESSAGE-INTEGRITY attribute, computed using the password utilized to authenticate the request. The response MUST NOT contain the USERNAME attribute.
これらのチェックが終わるなら、エージェントは、要求か指示を処理し続けています。 サーバによって生成されたどんな応答も要求を認証するのに利用されたパスワードを使用することで計算されたMESSAGE-INTEGRITY属性を含まなければなりません。 応答はUSERNAME属性を含んではいけません。
If any of the checks fail, a server MUST NOT include a MESSAGE- INTEGRITY or USERNAME attribute in the error response. This is because, in these failure cases, the server cannot determine the shared secret necessary to compute MESSAGE-INTEGRITY.
チェックのどれかが失敗するなら、サーバは誤り応答にMESSAGE- INTEGRITYかUSERNAME属性を含んではいけません。 これはこれらの失敗事件では、サーバがMESSAGE-INTEGRITYを計算するのに必要な共有秘密キーを決定できないからです。
10.1.3. Receiving a Response
10.1.3. 応答を受けます。
The client looks for the MESSAGE-INTEGRITY attribute in the response. If present, the client computes the message integrity over the response as defined in Section 15.4, using the same password it utilized for the request. If the resulting value matches the contents of the MESSAGE-INTEGRITY attribute, the response is considered authenticated. If the value does not match, or if MESSAGE-INTEGRITY was absent, the response MUST be discarded, as if it was never received. This means that retransmits, if applicable, will continue.
クライアントは応答におけるMESSAGE-INTEGRITY属性を探します。 存在しているなら、クライアントはセクション15.4で定義されるように応答に関してメッセージの保全を計算します、それが要求に利用した同じパスワードを使用して。 結果として起こる値がMESSAGE-INTEGRITY属性のコンテンツに合っているなら、応答は認証されていると考えられます。 値が合っていないか、またはMESSAGE-INTEGRITYが欠けたなら、応答を捨てなければなりません、まるでそれを決して受け取らないかのように。 適切であるなら再送されるこの手段は続くでしょう。
10.2. Long-Term Credential Mechanism
10.2. 長期の資格証明メカニズム
The long-term credential mechanism relies on a long-term credential, in the form of a username and password that are shared between client and server. The credential is considered long-term since it is assumed that it is provisioned for a user, and remains in effect until the user is no longer a subscriber of the system, or is changed. This is basically a traditional "log-in" username and password given to users.
長期の資格証明メカニズムはクライアントとサーバの間で共有されるユーザ名とパスワードの形で長期の資格証明書を当てにします。資格証明書をそれがユーザのために食糧を供給されると思われて、長期的であると考えて、ユーザがもうシステムの加入者にならないまで有効なままで残っているか、または変えます。 これは、基本的にユーザに与えられた伝統的な「ログイン」ユーザ名とパスワードです。
Because these usernames and passwords are expected to be valid for extended periods of time, replay prevention is provided in the form of a digest challenge. In this mechanism, the client initially sends a request, without offering any credentials or any integrity checks. The server rejects this request, providing the user a realm (used to guide the user or agent in selection of a username and password) and a nonce. The nonce provides the replay protection. It is a cookie, selected by the server, and encoded in such a way as to indicate a
これらのユーザ名とパスワードが延ばされた期間に有効であると予想されるので、ダイジェスト挑戦の形に再生防止を提供します。 このメカニズムでは、どんな資格証明書も提供しないで、クライアントが初めは、要求を送るか、またはどんな保全もチェックします。 サーバはこの要求を拒絶します、分野(以前はユーザ名とパスワードの選択でユーザかエージェントをよく誘導していた)と一回だけをユーザに提供して。 一回だけは反復操作による保護を提供します。 それはサーバによって選択されて、aを示すほどそのような方法でコード化されたクッキーです。
Rosenberg, et al. Standards Track [Page 24] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[24ページ]RFC5389は2008年10月に気絶させます。
duration of validity or client identity from which it is valid. The client retries the request, this time including its username and the realm, and echoing the nonce provided by the server. The client also includes a message-integrity, which provides an HMAC over the entire request, including the nonce. The server validates the nonce and checks the message integrity. If they match, the request is authenticated. If the nonce is no longer valid, it is considered "stale", and the server rejects the request, providing a new nonce.
それが有効である正当性かクライアントのアイデンティティの持続時間。 クライアントは要求を再試行します、今回がユーザ名と分野を含んで、サーバによって提供された一回だけを反響して。また、クライアントはメッセージの保全を入れます、一回だけを含んでいて。(メッセージの保全は全体の要求の上にHMACを提供します)。 サーバは、一回だけを有効にして、メッセージの保全をチェックします。 彼らが合っているなら、要求は認証されます。 一回だけがもう有効でないなら、それは「聞き古したである」考えられます、そして、サーバは要求を拒絶します、新しい一回だけを提供して。
In subsequent requests to the same server, the client reuses the nonce, username, realm, and password it used previously. In this way, subsequent requests are not rejected until the nonce becomes invalid by the server, in which case the rejection provides a new nonce to the client.
同じサーバへのその後の要求では、クライアントはそれが以前に使用した一回だけ、ユーザ名、分野、およびパスワードを再利用します。 このように、一回だけがサーバで無効になるまで、その後の要求は拒絶されません、その場合、拒絶が新しい一回だけをクライアントに提供します。
Note that the long-term credential mechanism cannot be used to protect indications, since indications cannot be challenged. Usages utilizing indications must either use a short-term credential or omit authentication and message integrity for them.
指摘に挑戦できないので、指摘を保護するのに長期の資格証明メカニズムを使用できないことに注意してください。 指摘を利用する用法は、短期的な資格証明書を使用しなければならないか、またはそれらのために認証とメッセージの保全を省略しなければなりません。
Since the long-term credential mechanism is susceptible to offline dictionary attacks, deployments SHOULD utilize passwords that are difficult to guess. In cases where the credentials are not entered by the user, but are rather placed on a client device during device provisioning, the password SHOULD have at least 128 bits of randomness. In cases where the credentials are entered by the user, they should follow best current practices around password structure.
長期の資格証明メカニズムがオフライン辞書攻撃に影響されやすいので、展開SHOULDは推測するのが難しいパスワードを利用します。 資格証明書がユーザによって入られませんが、デバイスの食糧を供給している間にむしろクライアントデバイスに置かれる場合では、パスワードSHOULDは偶発性の少なくとも128ビットを持っています。 資格証明書がユーザによって入られる場合では、それらはパスワード構造の周りで最も良い現在の実務に続くべきです。
10.2.1. Forming a Request
10.2.1. 要求を形成します。
There are two cases when forming a request. In the first case, this is the first request from the client to the server (as identified by its IP address and port). In the second case, the client is submitting a subsequent request once a previous request/response transaction has completed successfully. Forming a request as a consequence of a 401 or 438 error response is covered in Section 10.2.3 and is not considered a "subsequent request" and thus does not utilize the rules described in Section 10.2.1.2.
要求を形成するとき、2つのケースがあります。 前者の場合、クライアントからサーバまでこれは最初の要求(そのIPアドレスとポートによって特定されるように)です。 2番目のケース、クライアントに、その後の要求aかつて前の要求/応答トランザクションが首尾よく完成した提出があります。 401か438誤り応答の結果は、要求を形成しても、セクション10.2.3でカバーされていて、「その後の要求」であることは考えられないで、またその結果、セクション10.2.1で.2に説明された規則を利用しません。
10.2.1.1. First Request
10.2.1.1. 最初の要求
If the client has not completed a successful request/response transaction with the server (as identified by hostname, if the DNS procedures of Section 9 are used, else IP address if not), it SHOULD omit the USERNAME, MESSAGE-INTEGRITY, REALM, and NONCE attributes. In other words, the very first request is sent as if there were no authentication or message integrity applied.
クライアントがどんな完成したaもうまくいくようにしないなら、サーバで/応答トランザクションを要求してください(まして、セクション9のDNS手順が中古の、そして、ほかのIPアドレスであるならホスト名によって特定されるように)、それ。SHOULDはUSERNAME、MESSAGE-INTEGRITY、REALM、およびNONCE属性を省略します。 言い換えれば、まるで認証が全くないか、またはメッセージの保全が適用されるかのようにまさしくその最初の要求を送ります。
Rosenberg, et al. Standards Track [Page 25] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[25ページ]RFC5389は2008年10月に気絶させます。
10.2.1.2. Subsequent Requests
10.2.1.2. その後の要求
Once a request/response transaction has completed successfully, the client will have been presented a realm and nonce by the server, and selected a username and password with which it authenticated. The client SHOULD cache the username, password, realm, and nonce for subsequent communications with the server. When the client sends a subsequent request, it SHOULD include the USERNAME, REALM, and NONCE attributes with these cached values. It SHOULD include a MESSAGE- INTEGRITY attribute, computed as described in Section 15.4 using the cached password.
要求/応答トランザクションがいったんそうすると、首尾よく完成されて、クライアントは、分野と一回だけがサーバによって提示されて、それが認証したものでユーザ名とパスワードを選択してしまうでしょう。 クライアントSHOULDがサーバとのその後のコミュニケーションのためにユーザ名、パスワード、分野、および一回だけをキャッシュする、いつクライアントはその後の要求を送って、それはUSERNAME、REALM、およびこれらがキャッシュされているNONCE属性が評価するSHOULDインクルードであるか。 それ、SHOULDはセクション15.4でキャッシュされたパスワードを使用することで説明されるように計算されたMESSAGE- INTEGRITY属性を含んでいます。
10.2.2. Receiving a Request
10.2.2. 要求を受け取ります。
After the server has done the basic processing of a request, it performs the checks listed below in the order specified:
サーバが要求の基本的な処理をした後に、指定されたオーダーに以下に記載されたチェックを実行します:
o If the message does not contain a MESSAGE-INTEGRITY attribute, the
server MUST generate an error response with an error code of 401
(Unauthorized). This response MUST include a REALM value. It is
RECOMMENDED that the REALM value be the domain name of the
provider of the STUN server. The response MUST include a NONCE,
selected by the server. The response SHOULD NOT contain a
USERNAME or MESSAGE-INTEGRITY attribute.
o メッセージがMESSAGE-INTEGRITY属性を含んでいないなら、401のエラーコードが(権限のない)でサーバは誤り応答を生成しなければなりません。 この応答はREALM値を含まなければなりません。 REALM値がSTUNサーバのプロバイダーのドメイン名であることはRECOMMENDEDです。応答はサーバによって選択されたNONCEを含まなければなりません。応答SHOULD NOTはUSERNAMEかMESSAGE-INTEGRITY属性を含んでいます。
o If the message contains a MESSAGE-INTEGRITY attribute, but is
missing the USERNAME, REALM, or NONCE attribute, the server MUST
generate an error response with an error code of 400 (Bad
Request). This response SHOULD NOT include a USERNAME, NONCE,
REALM, or MESSAGE-INTEGRITY attribute.
o メッセージがMESSAGE-INTEGRITY属性を含んでいますが、USERNAME、REALM、またはNONCE属性がいなくて寂しいなら、サーバは400(悪いRequest)のエラーコードで誤り応答を生成しなければなりません。 この応答SHOULD NOTはUSERNAME、NONCE、REALM、またはMESSAGE-INTEGRITY属性を含んでいます。
o If the NONCE is no longer valid, the server MUST generate an error
response with an error code of 438 (Stale Nonce). This response
MUST include NONCE and REALM attributes and SHOULD NOT include the
USERNAME or MESSAGE-INTEGRITY attribute. Servers can invalidate
nonces in order to provide additional security. See Section 4.3
of [RFC2617] for guidelines.
o NONCEがもう有効でないなら、サーバは438(聞き古したNonce)のエラーコードで誤り応答を生成しなければなりません。 この応答はNONCEを含まなければなりません、そして、REALM属性とSHOULD NOTはUSERNAMEかMESSAGE-INTEGRITY属性を含んでいます。 サーバは、追加担保を提供するために一回だけを無効にすることができます。 ガイドラインに関して[RFC2617]のセクション4.3を見てください。
o If the username in the USERNAME attribute is not valid, the server
MUST generate an error response with an error code of 401
(Unauthorized). This response MUST include a REALM value. It is
RECOMMENDED that the REALM value be the domain name of the
provider of the STUN server. The response MUST include a NONCE,
selected by the server. The response SHOULD NOT contain a
USERNAME or MESSAGE-INTEGRITY attribute.
o USERNAME属性におけるユーザ名が有効でないなら、401のエラーコードが(権限のない)でサーバは誤り応答を生成しなければなりません。 この応答はREALM値を含まなければなりません。 REALM値がSTUNサーバのプロバイダーのドメイン名であることはRECOMMENDEDです。応答はサーバによって選択されたNONCEを含まなければなりません。応答SHOULD NOTはUSERNAMEかMESSAGE-INTEGRITY属性を含んでいます。
Rosenberg, et al. Standards Track [Page 26] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[26ページ]RFC5389は2008年10月に気絶させます。
o Using the password associated with the username in the USERNAME
attribute, compute the value for the message integrity as
described in Section 15.4. If the resulting value does not match
the contents of the MESSAGE-INTEGRITY attribute, the server MUST
reject the request with an error response. This response MUST use
an error code of 401 (Unauthorized). It MUST include REALM and
NONCE attributes and SHOULD NOT include the USERNAME or MESSAGE-
INTEGRITY attribute.
o USERNAME属性にユーザ名に関連しているパスワードを使用して、メッセージの保全のためにセクション15.4で説明されるように値を計算してください。 結果として起こる値がMESSAGE-INTEGRITY属性のコンテンツに合っていないなら、サーバは誤り応答で要求を拒絶しなければなりません。 この応答は401(権限のない)のエラーコードを使用しなければなりません。 それはREALMを含まなければなりません、そして、NONCE属性とSHOULD NOTはUSERNAMEかMESSAGE- INTEGRITY属性を含んでいます。
If these checks pass, the server continues to process the request. Any response generated by the server (excepting the cases described above) MUST include the MESSAGE-INTEGRITY attribute, computed using the username and password utilized to authenticate the request. The REALM, NONCE, and USERNAME attributes SHOULD NOT be included.
これらのチェックが終わるなら、サーバは、要求を処理し続けています。 サーバ(上で説明されたケースを除いた)によって生成されたどんな応答も要求を認証するのに利用されたユーザ名とパスワードを使用することで計算されたMESSAGE-INTEGRITY属性を含まなければなりません。 含まれていて、REALM、NONCE、およびUSERNAMEはSHOULD NOTを結果と考えます。
10.2.3. Receiving a Response
10.2.3. 応答を受けます。
If the response is an error response with an error code of 401 (Unauthorized), the client SHOULD retry the request with a new transaction. This request MUST contain a USERNAME, determined by the client as the appropriate username for the REALM from the error response. The request MUST contain the REALM, copied from the error response. The request MUST contain the NONCE, copied from the error response. The request MUST contain the MESSAGE-INTEGRITY attribute, computed using the password associated with the username in the USERNAME attribute. The client MUST NOT perform this retry if it is not changing the USERNAME or REALM or its associated password, from the previous attempt.
応答が401のエラーコードが(権限のない)であることでの誤り応答であるなら、クライアントSHOULDは新しいトランザクションで要求を再試行します。 この要求はREALMのための適切なユーザ名としてクライアントによって誤り応答から決定されたUSERNAMEを含まなければなりません。 要求は誤り応答からコピーされたREALMを含まなければなりません。 要求は誤り応答からコピーされたNONCEを含まなければなりません。 要求はUSERNAME属性にユーザ名に関連しているパスワードを使用することで計算されたMESSAGE-INTEGRITY属性を含まなければなりません。 USERNAME、REALMまたはその関連パスワードを変えていないなら、クライアントはこの再試行を実行してはいけません、前の試みから。
If the response is an error response with an error code of 438 (Stale Nonce), the client MUST retry the request, using the new NONCE supplied in the 438 (Stale Nonce) response. This retry MUST also include the USERNAME, REALM, and MESSAGE-INTEGRITY.
応答が438(聞き古したNonce)のエラーコードで誤り応答であるなら、クライアントは要求を再試行しなければなりません、438(聞き古したNonce)応答で供給された新しいNONCEを使用して。 また、この再試行はUSERNAME、REALM、およびMESSAGE-INTEGRITYを含まなければなりません。
The client looks for the MESSAGE-INTEGRITY attribute in the response (either success or failure). If present, the client computes the message integrity over the response as defined in Section 15.4, using the same password it utilized for the request. If the resulting value matches the contents of the MESSAGE-INTEGRITY attribute, the response is considered authenticated. If the value does not match, or if MESSAGE-INTEGRITY was absent, the response MUST be discarded, as if it was never received. This means that retransmits, if applicable, will continue.
クライアントは応答(成功か失敗のどちらか)におけるMESSAGE-INTEGRITY属性を探します。 存在しているなら、クライアントはセクション15.4で定義されるように応答に関してメッセージの保全を計算します、それが要求に利用した同じパスワードを使用して。 結果として起こる値がMESSAGE-INTEGRITY属性のコンテンツに合っているなら、応答は認証されていると考えられます。 値が合っていないか、またはMESSAGE-INTEGRITYが欠けたなら、応答を捨てなければなりません、まるでそれを決して受け取らないかのように。 適切であるなら再送されるこの手段は続くでしょう。
Rosenberg, et al. Standards Track [Page 27] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[27ページ]RFC5389は2008年10月に気絶させます。
11. ALTERNATE-SERVER Mechanism
11. 代替のサーバメカニズム
This section describes a mechanism in STUN that allows a server to redirect a client to another server. This extension is optional, and a usage must define if and when this extension is used.
このセクションはサーバに別のサーバにクライアントを向け直させるSTUNのメカニズムについて説明します。この拡大は任意です、そして、用法はこの拡大が使用されているかどうかを定義しなければなりません。
A server using this extension redirects a client to another server by replying to a request message with an error response message with an error code of 300 (Try Alternate). The server MUST include an ALTERNATE-SERVER attribute in the error response. The error response message MAY be authenticated; however, there are uses cases for ALTERNATE-SERVER where authentication of the response is not possible or practical.
この拡張子を使用するサーバは、300のエラーコードで誤り応答メッセージで要求メッセージに答えることによって、別のサーバにクライアントを向け直します(Alternateを試みてください)。 サーバは誤り応答にALTERNATE-SERVER属性を含まなければなりません。 誤り応答メッセージは認証されるかもしれません。 しかしながら、ALTERNATE-SERVERのための用途ケースが応答の認証が可能でもなくて、また実用的でもないところにあります。
A client using this extension handles a 300 (Try Alternate) error code as follows. The client looks for an ALTERNATE-SERVER attribute in the error response. If one is found, then the client considers the current transaction as failed, and reattempts the request with the server specified in the attribute, using the same transport protocol used for the previous request. That request, if authenticated, MUST utilize the same credentials that the client would have used in the request to the server that performed the redirection. If the client has been redirected to a server on which it has already tried this request within the last five minutes, it MUST ignore the redirection and consider the transaction to have failed. This prevents infinite ping-ponging between servers in case of redirection loops.
この拡張子を使用しているクライアントは以下の300(Alternateを試みる)エラーコードを扱います。 クライアントは誤り応答におけるALTERNATE-SERVER属性を探します。 1つが見つけられるなら、サーバが属性で指定されている状態で、クライアントは、失敗されるとしての経常取引、および「再-試み」が要求であると考えます、前の要求に使用される同じトランスポート・プロトコルを使用して。 認証されるなら、その要求はクライアントが要求でリダイレクションを実行したサーバに使用したのと同じ資格証明書を利用しなければなりません。 クライアントがそれがここ5個の議事録以内に既にこの要求を試みたサーバに向け直されたなら、それは、リダイレクションを無視して、トランザクションが失敗したと考えなければなりません。 これはリダイレクションの場合のサーバの間の無限のピング悪臭輪を防ぎます。
12. Backwards Compatibility with RFC 3489
12. RFC3489との遅れている互換性
This section defines procedures that allow a degree of backwards compatibility with the original protocol defined in RFC 3489 [RFC3489]. This mechanism is optional, meant to be utilized only in cases where a new client can connect to an old server, or vice versa. A usage must define if and when this procedure is used.
このセクションはオリジナルのプロトコルとの互換性がRFC3489[RFC3489]で定義した後方にの度合いを許容する手順を定義します。 このメカニズムは任意です、新しいクライアントが古いサーバに接続できるか、逆もまた同様です場合だけで利用されることが意味されて。 用法は、この手順が使用されているかどうかを定義しなければなりません。
Section 19 lists all the changes between this specification and RFC 3489 [RFC3489]. However, not all of these differences are important, because "classic STUN" was only used in a few specific ways. For the purposes of this extension, the important changes are the following. In RFC 3489:
セクション19はこの仕様とRFC3489[RFC3489]の間のすべての変化を記載します。 しかしながら、「古典的なSTUN」がいくつかの特定の方法で使用されただけであるので、これらの違いのすべてが重要であるというわけではありません。 この拡大の目的のために、重要な変化は以下です。 RFC3489で:
o UDP was the only supported transport.
o UDPは唯一のサポートしている輸送でした。
o The field that is now the magic cookie field was a part of the
transaction ID field, and transaction IDs were 128 bits long.
o 現在魔法のクッキー分野である分野はトランザクションID分野の一部でした、そして、トランザクションIDは長さ128ビットでした。
Rosenberg, et al. Standards Track [Page 28] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[28ページ]RFC5389は2008年10月に気絶させます。
o The XOR-MAPPED-ADDRESS attribute did not exist, and the Binding
method used the MAPPED-ADDRESS attribute instead.
o XOR-MAPPED-ADDRESS属性は存在しませんでした、そして、Bindingメソッドは代わりにMAPPED-ADDRESS属性を使用しました。
o There were three comprehension-required attributes, RESPONSE-
ADDRESS, CHANGE-REQUEST, and CHANGED-ADDRESS, that have been
removed from this specification.
o この仕様から取り外された3つの読解で必要な属性、RESPONSE- ADDRESS、CHANGE-REQUEST、およびCHANGED-ADDRESSがありました。
* CHANGE-REQUEST and CHANGED-ADDRESS are now part of the NAT
Behavior Discovery usage [BEHAVE-NAT], and the other is
deprecated.
* 現在CHANGE-REQUESTとCHANGED-ADDRESSはNAT Behaviorディスカバリー用法[BEHAVE-NAT]の一部です、そして、もう片方が推奨しないです。
12.1. Changes to Client Processing
12.1. クライアント処理への変化
A client that wants to interoperate with an [RFC3489] server SHOULD send a request message that uses the Binding method, contains no attributes, and uses UDP as the transport protocol to the server. If successful, the success response received from the server will contain a MAPPED-ADDRESS attribute rather than an XOR-MAPPED-ADDRESS attribute. A client seeking to interoperate with an older server MUST be prepared to receive either. Furthermore, the client MUST ignore any Reserved comprehension-required attributes that might appear in the response. Of the Reserved attributes in Section 18.2, 0x0002, 0x0004, 0x0005, and 0x000B may appear in Binding responses from a server compliant to RFC 3489. Other than this change, the processing of the response is identical to the procedures described above.
[RFC3489]サーバSHOULDと共に共同利用したがっているクライアントはトランスポート・プロトコルとしてサーバにBindingメソッドを使用して、属性を全く含んでいなくて、UDPを使用する要求メッセージを送ります。うまくいくと、サーバから受けられた成功応答はXOR-MAPPED-ADDRESS属性よりむしろMAPPED-ADDRESS属性を含むでしょう。 より古いサーバで共同利用しようとしているクライアントは受信する用意ができていなければなりません。 その上、クライアントは応答に現れるどんなReservedの読解で必要な属性も無視しなければなりません。 セクション18.2、0x0002におけるReserved属性では、0×0004、0×0005、および0x000BはRFC3489への対応することのサーバからBinding応答に現れるかもしれません。 この変化を除いて、応答の処理は上で説明された手順と同じです。
12.2. Changes to Server Processing
12.2. サーバ処理への変化
A STUN server can detect when a given Binding request message was sent from an RFC 3489 [RFC3489] client by the absence of the correct value in the magic cookie field. When the server detects an RFC 3489 client, it SHOULD copy the value seen in the magic cookie field in the Binding request to the magic cookie field in the Binding response message, and insert a MAPPED-ADDRESS attribute instead of an XOR- MAPPED-ADDRESS attribute.
STUNサーバは、与えられたBinding要求メッセージがいつRFC3489[RFC3489]クライアントから魔法のクッキー分野での正しい価値の欠如で送られたかを検出できます。 いつサーバが3489年のRFCクライアントを検出して、それがBindingの魔法のクッキー分野で目にふれている値がBinding応答メッセージにおける魔法のクッキー分野に要求するSHOULDコピーであるか、そして、MAPPED-ADDRESSがXOR- MAPPED-ADDRESS属性の代わりに結果と考える差し込み。
The client might, in rare situations, include either the RESPONSE- ADDRESS or CHANGE-REQUEST attributes. In these situations, the server will view these as unknown comprehension-required attributes and reply with an error response. Since the mechanisms utilizing those attributes are no longer supported, this behavior is acceptable.
まれな状況では、クライアントはRESPONSE- ADDRESSかCHANGE-REQUEST属性を入れるかもしれません。 これらの状況で、サーバは、未知の読解で必要な属性であるとこれらをみなして、誤り応答で返答するでしょう。 それらの属性を利用するメカニズムがもうサポートされないので、この振舞いは許容できます。
The RFC 3489 version of STUN lacks both the magic cookie and the FINGERPRINT attribute that allows for a very high probability of correctly identifying STUN messages when multiplexed with other protocols. Therefore, STUN implementations that are backwards
3489年のSTUNのRFCバージョンは魔法のクッキーと他のプロトコルと共に多重送信すると正しくSTUNメッセージを特定するという非常に高い確率を考慮するFINGERPRINT属性の両方を欠いています。 したがって、後方にSTUN実装
Rosenberg, et al. Standards Track [Page 29] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[29ページ]RFC5389は2008年10月に気絶させます。
compatible with RFC 3489 SHOULD NOT be used in cases where STUN will be multiplexed with another protocol. However, that should not be an issue as such multiplexing was not available in RFC 3489.
STUNが別のプロトコルと共に多重送信される場合に使用されるRFC3489SHOULD NOTと互換性があります。 しかしながら、そのようなマルチプレクシングがRFC3489で利用可能でなかったときに、それは問題であるべきではありません。
13. Basic Server Behavior
13. 基幹サーバの振舞い
This section defines the behavior of a basic, stand-alone STUN server. A basic STUN server provides clients with server reflexive transport addresses by receiving and replying to STUN Binding requests.
このセクションは基本的で、スタンドアロンのSTUNサーバの働きを定義します。基本的なSTUNサーバは、STUN Binding要求に受けて、答えることによって、サーバ反動的輸送アドレスをクライアントに提供します。
The STUN server MUST support the Binding method. It SHOULD NOT utilize the short-term or long-term credential mechanism. This is because the work involved in authenticating the request is more than the work in simply processing it. It SHOULD NOT utilize the ALTERNATE-SERVER mechanism for the same reason. It MUST support UDP and TCP. It MAY support STUN over TCP/TLS; however, TLS provides minimal security benefits in this basic mode of operation. It MAY utilize the FINGERPRINT mechanism but MUST NOT require it. Since the stand-alone server only runs STUN, FINGERPRINT provides no benefit. Requiring it would break compatibility with RFC 3489, and such compatibility is desirable in a stand-alone server. Stand-alone STUN servers SHOULD support backwards compatibility with [RFC3489] clients, as described in Section 12.
STUNサーバは、Bindingがメソッドであるとサポートしなければなりません。 それ、SHOULD NOTは短期的であるか長期の資格証明メカニズムを利用します。 これは要求を認証するのにかかわる仕事が単にそれを処理することにおける仕事以上であるからです。 それ、SHOULD NOTは同じ理由からALTERNATE-SERVERメカニズムを利用します。 それはUDPとTCPをサポートしなければなりません。 それはTCP/TLSの上でSTUNをサポートするかもしれません。 しかしながら、TLSは最小量のセキュリティ利益をこの基本的な運転モードに提供します。 それは、FINGERPRINTメカニズムを利用するかもしれませんが、それを必要としてはいけません。 スタンドアロンのサーバがSTUNを実行するだけであるので、FINGERPRINTは利益を全く提供しません。 それを必要とすると、RFC3489との互換性は壊れるでしょう、そして、そのような互換性はスタンドアロンのサーバで望ましいです。スタンドアロンのSTUNサーバSHOULDは後方に[RFC3489]クライアントとの互換性をサポートします、セクション12で説明されるように。
It is RECOMMENDED that administrators of STUN servers provide DNS entries for those servers as described in Section 9.
STUNサーバの管理者がセクション9で説明されるようにそれらのサーバのためのエントリーをDNSに供給するのは、RECOMMENDEDです。
A basic STUN server is not a solution for NAT traversal by itself. However, it can be utilized as part of a solution through STUN usages. This is discussed further in Section 14.
基本的なSTUNサーバはそれ自体でNAT縦断のためのソリューションではありません。 しかしながら、ソリューションの一部としてSTUN用法でそれを利用できます。 セクション14で、より詳しくこれについて議論します。
14. STUN Usages
14. 用法を気絶させてください。
STUN by itself is not a solution to the NAT traversal problem. Rather, STUN defines a tool that can be used inside a larger solution. The term "STUN usage" is used for any solution that uses STUN as a component.
それ自体でSTUNはNAT縦断問題への解決ではありません。 むしろ、STUNは、より大きいソリューションに使用できるツールを定義します。 「STUN用法」という用語はコンポーネントとしてSTUNを使用するどんなソリューションにも使用されます。
At the time of writing, three STUN usages are defined: Interactive Connectivity Establishment (ICE) [MMUSIC-ICE], Client-initiated connections for SIP [SIP-OUTBOUND], and NAT Behavior Discovery [BEHAVE-NAT]. Other STUN usages may be defined in the future.
これを書いている時点で、3つのSTUN用法が定義されます: 対話的なConnectivity特権階級(ICE)[MMUSIC-ICE]、SIPのためのClientによって開始された接続[SIP-OUTBOUND]、およびNAT Behaviorディスカバリー[BEHAVE-NAT]。 他のSTUN用法は将来、定義されるかもしれません。
A STUN usage defines how STUN is actually utilized -- when to send requests, what to do with the responses, and which optional procedures defined here (or in an extension to STUN) are to be used. A usage would also define:
STUN用法は発信するのに要求、応答でするべきこと、および任意の手順がここで定義したもの(またはSTUNへの拡大で)が使用されていることになっているとき、STUNが実際にどう利用されるかを定義します。 また、用法は以下を定義するでしょう。
Rosenberg, et al. Standards Track [Page 30] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[30ページ]RFC5389は2008年10月に気絶させます。
o Which STUN methods are used.
o どのSTUNメソッドが使用されていますか?
o What authentication and message-integrity mechanisms are used.
o どんな認証とメッセージの保全メカニズムが使用されていますか?
o The considerations around manual vs. automatic key derivation for
the integrity mechanism, as discussed in [RFC4107].
o [RFC4107]で議論するようなマニュアルの周りの問題対保全メカニズムのための自動主要な派生
o What mechanisms are used to distinguish STUN messages from other
messages. When STUN is run over TCP, a framing mechanism may be
required.
o どんなメカニズムが、他のメッセージとSTUNメッセージを区別するのに使用されますか? STUNがTCPの上に実行されると、縁どりメカニズムが必要であるかもしれません。
o How a STUN client determines the IP address and port of the STUN
server.
o STUNクライアントはどうSTUNサーバのIPアドレスとポートを決定するか。
o Whether backwards compatibility to RFC 3489 is required.
o RFC3489への遅れている互換性が必要であるかどうか
o What optional attributes defined here (such as FINGERPRINT and
ALTERNATE-SERVER) or in other extensions are required.
o ここ(FINGERPRINTとALTERNATE-SERVERとしてのそのようなもの)か他の拡大で定義されたすべての任意の属性が必要ですか?
In addition, any STUN usage must consider the security implications of using STUN in that usage. A number of attacks against STUN are known (see the Security Considerations section in this document), and any usage must consider how these attacks can be thwarted or mitigated.
さらに、どんなSTUN用法も、セキュリティがその用法でSTUNを使用する含意であると考えなければなりません。 どんな用法も、STUNに対する多くの攻撃が知られていて(本書ではSecurity Considerations部を見てください)、どうしたらこれらの攻撃を邪魔するか、または緩和できるかを考えなければなりません。
Finally, a usage must consider whether its usage of STUN is an example of the Unilateral Self-Address Fixing approach to NAT traversal, and if so, address the questions raised in RFC 3424 [RFC3424].
最終的に、用法は、STUNの使用法がUnilateral Self-アドレスFixingに関する例であるか否かに関係なく、NAT縦断にアプローチして、そうだとすれば、RFC3424[RFC3424]で引き起こされた疑問を扱うように考えなければなりません。
15. STUN Attributes
15. 属性を気絶させてください。
After the STUN header are zero or more attributes. Each attribute MUST be TLV encoded, with a 16-bit type, 16-bit length, and value. Each STUN attribute MUST end on a 32-bit boundary. As mentioned above, all fields in an attribute are transmitted most significant bit first.
STUNヘッダーの後に、ゼロか、より多くの属性があります。 各属性は16ビットのタイプ、16ビットの長さ、および値でコード化されたTLVであるに違いありません。 それぞれのSTUN属性は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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値(可変)… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of STUN Attributes
図4: 形式、属性を気絶させてください。
Rosenberg, et al. Standards Track [Page 31] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[31ページ]RFC5389は2008年10月に気絶させます。
The value in the length field MUST contain the length of the Value part of the attribute, prior to padding, measured in bytes. Since STUN aligns attributes on 32-bit boundaries, attributes whose content is not a multiple of 4 bytes are padded with 1, 2, or 3 bytes of padding so that its value contains a multiple of 4 bytes. The padding bits are ignored, and may be any value.
長さの分野の値は属性のValue部分の長さを含まなければなりません、バイトで測定された詰め物の前に。 STUNが32ビットの境界の属性を並べるので、内容が4バイトの倍数でない属性が1バイトか2バイトか3バイトの詰め物で水増しされるので、値は4バイトの倍数を含んでいます。 詰め物ビットは、無視されて、どんな値であるかもしれません。
Any attribute type MAY appear more than once in a STUN message. Unless specified otherwise, the order of appearance is significant: only the first occurrence needs to be processed by a receiver, and any duplicates MAY be ignored by a receiver.
どんな属性タイプもSTUNメッセージで一度より多く見えるかもしれません。 別の方法で指定されない場合、外観の注文は重要です: 最初の発生だけが、受信機によって処理される必要があります、そして、どんな写しも受信機によって無視されるかもしれません。
To allow future revisions of this specification to add new attributes if needed, the attribute space is divided into two ranges. Attributes with type values between 0x0000 and 0x7FFF are comprehension-required attributes, which means that the STUN agent cannot successfully process the message unless it understands the attribute. Attributes with type values between 0x8000 and 0xFFFF are comprehension-optional attributes, which means that those attributes can be ignored by the STUN agent if it does not understand them.
この仕様の今後の改正が新しい属性を加えるのを許容するために、必要であるなら、属性スペースは2つの範囲に分割されます。 0×0000と0x7FFFの間には、タイプ値がある属性は読解で必要な属性です(属性を理解していない場合STUNエージェントが首尾よくメッセージを処理できないことを意味します)。 0×8000と0xFFFFの間には、タイプ値がある属性は読解任意の属性です(それらを理解していないならSTUNエージェントがそれらの属性を無視できることを意味します)。
The set of STUN attribute types is maintained by IANA. The initial set defined by this specification is found in Section 18.2.
STUN属性タイプのセットはIANAによって維持されます。 この仕様で定義された始発はセクション18.2で見つけられます。
The rest of this section describes the format of the various attributes defined in this specification.
このセクションの残りはこの仕様に基づき定義された様々な属性の形式について説明します。
15.1. MAPPED-ADDRESS
15.1. 写像しているアドレス
The MAPPED-ADDRESS attribute indicates a reflexive transport address of the client. It consists of an 8-bit address family and a 16-bit port, followed by a fixed-length value representing the IP address. If the address family is IPv4, the address MUST be 32 bits. If the address family is IPv6, the address MUST be 128 bits. All fields must be in network byte order.
MAPPED-ADDRESS属性はクライアントの再帰の輸送アドレスを示します。 それはIPアドレスを表す固定長値があとに続いた8ビットのアドレスファミリーと16ビットのポートから成ります。 アドレスファミリーがIPv4であるなら、アドレスは32ビットでなければなりません。 アドレスファミリーがIPv6であるなら、アドレスは128ビットでなければなりません。 ネットワークバイトオーダーにはすべての分野があるに違いありません。
Rosenberg, et al. Standards Track [Page 32] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[32ページ]RFC5389は2008年10月に気絶させます。
The format of the MAPPED-ADDRESS attribute is:
MAPPED-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Family | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address (32 bits or 128 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| ファミリー| ポート| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | アドレス(32ビットか128ビット)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of MAPPED-ADDRESS Attribute
図5: 写像しているアドレス属性の形式
The address family can take on the following values:
アドレスファミリーは以下の値を呈することができます:
0x01:IPv4 0x02:IPv6
0×01: IPv4 0x02: IPv6
The first 8 bits of the MAPPED-ADDRESS MUST be set to 0 and MUST be ignored by receivers. These bits are present for aligning parameters on natural 32-bit boundaries.
MAPPED-ADDRESS MUSTの最初の8ビットを0に設定されて、受信機で無視しなければなりません。 これらのビットは、自然な32ビットの境界に関するパラメタを並べるために存在しています。
This attribute is used only by servers for achieving backwards compatibility with RFC 3489 [RFC3489] clients.
この属性は、RFC3489[RFC3489]クライアントとの互換性を後方に獲得するのにサーバだけによって使用されます。
15.2. XOR-MAPPED-ADDRESS
15.2. XORはアドレスを写像しました。
The XOR-MAPPED-ADDRESS attribute is identical to the MAPPED-ADDRESS attribute, except that the reflexive transport address is obfuscated through the XOR function.
XOR-MAPPED-ADDRESS属性はMAPPED-ADDRESS属性と同じです、再帰の輸送アドレスがXOR機能を通して困惑させられるのを除いて。
The format of the XOR-MAPPED-ADDRESS is:
XOR-MAPPED-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| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x x x x x x x| ファミリー| X-ポート| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | X-アドレス(可変)+++++++++++++++++++++++++++++++++
Figure 6: Format of XOR-MAPPED-ADDRESS Attribute
図6: XORがアドレスを写像している属性の形式
The Family represents the IP address family, and is encoded identically to the Family in MAPPED-ADDRESS.
FamilyはIPアドレスファミリーの代理をして、同様にMAPPED-ADDRESSのFamilyにコード化されます。
Rosenberg, et al. Standards Track [Page 33] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[33ページ]RFC5389は2008年10月に気絶させます。
X-Port is computed by taking the mapped port in host byte order, XOR'ing it with the most significant 16 bits of the magic cookie, and then the converting the result to network byte order. If the IP address family is IPv4, X-Address is computed by taking the mapped IP address in host byte order, XOR'ing it with the magic cookie, and converting the result to network byte order. If the IP address family is IPv6, X-Address is computed by taking the mapped IP address in host byte order, XOR'ing it with the concatenation of the magic cookie and the 96-bit transaction ID, and converting the result to network byte order.
X-ポートは魔法のクッキーの最も重要な16ビットでホストバイトオーダー、XOR'ingの写像しているポートにそれを持って行くことによって、計算されます、そして、ネットワークバイトオーダーへの結果は次に、変換が計算されます。 IPアドレスファミリーがIPv4であるなら、X-アドレスは、魔法のクッキーでホストバイトオーダーにおける写像しているIPアドレス、XOR'ingにそれを取って、ネットワークバイトオーダーに結果を変換することによって、計算されます。 IPアドレスファミリーがIPv6であるなら、X-アドレスは、魔法のクッキーの連結と96ビットのトランザクションIDでホストバイトオーダーにおける写像しているIPアドレス、XOR'ingにそれを取って、ネットワークバイトオーダーに結果を変換することによって、計算されます。
The rules for encoding and processing the first 8 bits of the attribute's value, the rules for handling multiple occurrences of the attribute, and the rules for processing address families are the same as for MAPPED-ADDRESS.
属性の価値の最初の8ビットをコード化して、処理するための規則、属性の複数の発生を扱うための規則、および処理アドレスファミリーのための規則はMAPPED-ADDRESSのように同じです。
Note: XOR-MAPPED-ADDRESS and MAPPED-ADDRESS differ only in their encoding of the transport address. The former encodes the transport address by exclusive-or'ing it with the magic cookie. The latter encodes it directly in binary. RFC 3489 originally specified only MAPPED-ADDRESS. However, deployment experience found that some NATs rewrite the 32-bit binary payloads containing the NAT's public IP address, such as STUN's MAPPED-ADDRESS attribute, in the well-meaning but misguided attempt at providing a generic ALG function. Such behavior interferes with the operation of STUN and also causes failure of STUN's message-integrity checking.
以下に注意してください。 XOR-MAPPED-ADDRESSとMAPPED-ADDRESSは単に彼らの輸送アドレスのコード化において異なります。 輸送がexclusive-or'ingで魔法でそれを扱う前のエンコード、クッキー。 後者は直接バイナリーでそれをコード化します。 RFC3489は元々、MAPPED-ADDRESSだけを指定しました。 しかしながら、展開経験によって、いくつかのNATsがNATの公共のIPアドレスを含む32ビットの2進のペイロードを書き直すのがわかりました、STUNのMAPPED-ADDRESS属性などのように、ジェネリックALG機能を提供することへの善意の、しかし、見当違いの試みで。 そのような振舞いは、STUNの操作を妨げて、また、STUNのメッセージの保全の照合の失敗を引き起こします。
15.3. USERNAME
15.3. ユーザ名
The USERNAME attribute is used for message integrity. It identifies the username and password combination used in the message-integrity check.
USERNAME属性はメッセージの保全に使用されます。 それは組み合わせがメッセージの保全チェックに使用したユーザ名とパスワードを特定します。
The value of USERNAME is a variable-length value. It MUST contain a UTF-8 [RFC3629] encoded sequence of less than 513 bytes, and MUST have been processed using SASLprep [RFC4013].
USERNAMEの値は可変長の値です。 それは、513バイト未満のUTF-8[RFC3629]のコード化された系列を含まなければならなくて、SASLprep[RFC4013]を使用して、処理されたに違いありません。
15.4. MESSAGE-INTEGRITY
15.4. メッセージの保全
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of the STUN message. The MESSAGE-INTEGRITY attribute can be present in any STUN message type. 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. With the exception of the FINGERPRINT attribute, which appears after MESSAGE-INTEGRITY, agents MUST ignore all other attributes that follow MESSAGE-INTEGRITY.
MESSAGE-INTEGRITY属性はSTUNメッセージのHMAC-SHA1[RFC2104]を含んでいます。 MESSAGE-INTEGRITY属性はどんなSTUNメッセージタイプでも存在している場合があります。 SHA1ハッシュを使用するので、HMACは20バイトになるでしょう。 HMACに入力されるように使用されるテキストはSTUNメッセージです、ヘッダーを含んでいて、MESSAGE-INTEGRITY属性に先行する属性を含めて。 FINGERPRINT属性を除いて、エージェントはMESSAGE-INTEGRITYに続く他のすべての属性を無視しなければなりません。(それは、MESSAGE-INTEGRITYの後に現れます)。
Rosenberg, et al. Standards Track [Page 34] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[34ページ]RFC5389は2008年10月に気絶させます。
The key for the HMAC depends on whether long-term or short-term credentials are in use. For long-term credentials, the key is 16 bytes:
HMACのためのキーは長期的であるか短期的な資格証明書が使用中であるかどうかよります。 長期の資格証明書のために、キーは16バイトです:
key = MD5(username ":" realm ":" SASLprep(password))
主要な=MD5「(」 : 」 ユーザ名」 : 」 分野SASLprep(パスワード))
That is, the 16-byte key is formed by taking the MD5 hash of the result of concatenating the following five fields: (1) the username, with any quotes and trailing nulls removed, as taken from the USERNAME attribute (in which case SASLprep has already been applied); (2) a single colon; (3) the realm, with any quotes and trailing nulls removed; (4) a single colon; and (5) the password, with any trailing nulls removed and after processing using SASLprep. For example, if the username was 'user', the realm was 'realm', and the password was 'pass', then the 16-byte HMAC key would be the result of performing an MD5 hash on the string 'user:realm:pass', the resulting hash being 0x8493fbc53ba582fb4c044c456bdc40eb.
すなわち、16バイトのキーは以下の5つの分野を連結するという結果のMD5ハッシュを取ることによって、形成されます: (1) ユーザ名、どんな引用文と引きずることで、ヌルは取り外されました、USERNAME属性から取るように(その場合、SASLprepは既に適用されました)。 (2) 1コロン。 (3) どんな引用文と引きずっているヌルも取り除かれている分野。 (4) 1コロン。 (5) そして、取り除くどんな引きずっているヌルともSASLprepを使用することで処理した後のパスワード。 例えば、ユーザ名が'ユーザ'であり、分野が'分野'であり、パスワードが'パス'であるなら、16バイトのHMACキーはストリング'ユーザ:分野:パス'(0x8493fbc53ba582fb4c044c456bdc40ebである結果として起こるハッシュ)にMD5ハッシュを実行するという結果でしょうに。
For short-term credentials:
短期的な資格証明書のために:
key = SASLprep(password)
主要な=SASLprep(パスワード)
where MD5 is defined in RFC 1321 [RFC1321] and SASLprep() is defined in RFC 4013 [RFC4013].
MD5がどこでRFC1321[RFC1321]とSASLprep()で定義されるかはRFC4013[RFC4013]で定義されます。
The structure of the key when used with long-term credentials facilitates deployment in systems that also utilize SIP. Typically, SIP systems utilizing SIP's digest authentication mechanism do not actually store the password in the database. Rather, they store a value called H(A1), which is equal to the key defined above.
長期の資格証明書と共に使用されると、キーの構造はまた、SIPを利用するシステムにおける展開を容易にします。 通常、SIPのダイジェスト認証機構を利用するSIPシステムが実際にデータベースのパスワードを保存しません。 むしろ、彼らは上で定義されたキーと等しいH(A1)と呼ばれる値を保存します。
Based on the rules above, the hash used to construct MESSAGE- INTEGRITY includes the length field from the STUN message header. Prior to performing the hash, the MESSAGE-INTEGRITY attribute MUST be inserted into the message (with dummy content). The length MUST then be set to point to the length of the message up to, and including, the MESSAGE-INTEGRITY attribute itself, but excluding any attributes after it. Once the computation is performed, the value of the MESSAGE-INTEGRITY attribute can be filled in, and the value of the length in the STUN header can be set to its correct value -- the length of the entire message. Similarly, when validating the MESSAGE-INTEGRITY, the length field should be adjusted to point to the end of the MESSAGE-INTEGRITY attribute prior to calculating the HMAC. Such adjustment is necessary when attributes, such as FINGERPRINT, appear after MESSAGE-INTEGRITY.
上では、ハッシュが以前はよく構成していた規則に基づいて、MESSAGE- INTEGRITYがSTUNメッセージヘッダーからの長さの分野を含んでいます。 ハッシュを実行する前に、メッセージ(ダミーの内容がある)にMESSAGE-INTEGRITY属性を挿入しなければなりません。 次に、上がって、含んでいて、MESSAGE-INTEGRITYがそれ自体を結果と考えるというメッセージの長さを示すように設定しなければなりませんが、それの後にどんな属性も除く長さ。 STUNヘッダーの長さの値を正しい値に設定できます--計算がいったん実行されると、MESSAGE-INTEGRITY属性の値に記入できます、そして、全体のメッセージの長さ。 MESSAGE-INTEGRITYを有効にするとき、同様に、長さの分野は、計算の前のMESSAGE-INTEGRITY属性の終わりにHMACを示すように調整されるべきです。 FINGERPRINTなどの属性がMESSAGE-INTEGRITYの後に現れるとき、そのような調整が必要です。
Rosenberg, et al. Standards Track [Page 35] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[35ページ]RFC5389は2008年10月に気絶させます。
15.5. FINGERPRINT
15.5. 指紋
The FINGERPRINT attribute MAY be present in all STUN messages. The value of the attribute is computed as the CRC-32 of the STUN message up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with the 32-bit value 0x5354554e (the XOR helps in cases where an application packet is also using CRC-32 in it). The 32-bit CRC is the one defined in ITU V.42 [ITU.V42.2002], which has a generator polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. When present, the FINGERPRINT attribute MUST be the last attribute in the message, and thus will appear after MESSAGE-INTEGRITY.
FINGERPRINT属性はすべてのSTUNメッセージに存在しているかもしれません。 属性の値はSTUNメッセージのCRC-32として(しかし、除外)FINGERPRINT属性自体まで計算されます、32ビットの値の0x5354554eとXOR'ed(XORはまたアプリケーションパケットがそれのCRC-32を使用している場合で助けます)。 32ビットのCRCは+1にx32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+xのジェネレータ多項式を持っているITU V.42[ITU.V42.2002]で定義されたものです。 存在しているとき、FINGERPRINT属性は、メッセージにおける最後の属性でなければならなく、その結果、MESSAGE-INTEGRITYの後に現れるでしょう。
The FINGERPRINT attribute can aid in distinguishing STUN packets from packets of other protocols. See Section 8.
FINGERPRINT属性は他のプロトコルのパケットとSTUNパケットを区別する際に支援されることができます。 セクション8を見てください。
As with MESSAGE-INTEGRITY, the CRC used in the FINGERPRINT attribute covers the length field from the STUN message header. Therefore, this value must be correct and include the CRC attribute as part of the message length, prior to computation of the CRC. When using the FINGERPRINT attribute in a message, the attribute is first placed into the message with a dummy value, then the CRC is computed, and then the value of the attribute is updated. If the MESSAGE-INTEGRITY attribute is also present, then it must be present with the correct message-integrity value before the CRC is computed, since the CRC is done over the value of the MESSAGE-INTEGRITY attribute as well.
MESSAGE-INTEGRITYのように、CRCはFINGERPRINT属性カバーでSTUNメッセージヘッダーから長さの分野を使用しました。 したがって、この値は、正しく、メッセージ長の一部としてCRC属性を含まなければなりません、CRCの計算の前に。 メッセージでFINGERPRINT属性を使用するとき、最初にダミーの値で属性をメッセージに置きます、そして、次に、CRCを計算します、そして、次に、属性の値をアップデートします。 また、MESSAGE-INTEGRITY属性も存在しているなら、CRCが計算される前に正しいメッセージの保全値について存在していなければなりません、また、MESSAGE-INTEGRITY属性の値の上にCRCをするので。
15.6. ERROR-CODE
15.6. エラーコード
The ERROR-CODE attribute is used in error response messages. It contains a numeric error code value in the range of 300 to 699 plus a textual reason phrase encoded in UTF-8 [RFC3629], and is consistent in its code assignments and semantics with SIP [RFC3261] and HTTP [RFC2616]. The reason phrase is meant for user consumption, and can be anything appropriate for the error code. Recommended reason phrases for the defined error codes are included in the IANA registry for error codes. The reason phrase MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes).
ERROR-CODE属性は誤り応答メッセージに使用されます。 それは、300〜699の範囲の数値エラーコード値とUTF-8[RFC3629]でコード化された原文の理由句を含んでいて、そのコード課題と意味論でSIP[RFC3261]とHTTP[RFC2616]と一致しています。 理由句は、ユーザ消費で意味されて、エラーコードに、何か適切なものであるかもしれません。 定義されたエラーコードのためのお勧めの理由句はエラーコードのためのIANA登録に含まれています。 理由句は128未満のキャラクタ(763バイトと同じくらい長いことができる)のUTF-8[RFC3629]のコード化された系列であるに違いありません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, should be 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であるべきです予約されていて。|クラス| 数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 句(変数)を推論してください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: ERROR-CODE Attribute
図7: エラーコード属性
Rosenberg, et al. Standards Track [Page 36] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[36ページ]RFC5389は2008年10月に気絶させます。
To facilitate processing, the class of the error code (the hundreds digit) is encoded separately from the rest of the code, as shown in Figure 7.
処理するのを容易にするために、エラーコード(数百ケタ)のクラスは別々にコードの残りからコード化されます、図7に示されるように。
The Reserved bits SHOULD be 0, and are for alignment on 32-bit boundaries. Receivers MUST ignore these bits. The Class represents the hundreds digit of the error code. The value MUST be between 3 and 6. The Number represents the error code modulo 100, and its value MUST be between 0 and 99.
ReservedビットSHOULDは0歳であり、32ビットの境界における整列のためのものです。 受信機はこれらのビットを無視しなければなりません。 Classはエラーコードの数百ケタを表します。 値は、3〜6でなければなりません。 値は、0〜Numberがエラーコード法100を表して、99でなければなりません。
The following error codes, along with their recommended reason phrases, are defined:
以下のエラーコードはそれらのお勧めの理由句と共に定義されます:
300 Try Alternate: The client should contact an alternate server for
this request. This error response MUST only be sent if the
request included a USERNAME attribute and a valid MESSAGE-
INTEGRITY attribute; otherwise, it MUST NOT be sent and error
code 400 (Bad Request) is suggested. This error response MUST
be protected with the MESSAGE-INTEGRITY attribute, and receivers
MUST validate the MESSAGE-INTEGRITY of this response before
redirecting themselves to an alternate server.
300 補欠を裁いてください: クライアントはこの要求のための代替のサーバに連絡するべきです。 要求がUSERNAME属性と有効なMESSAGE- INTEGRITY属性を含んでいたなら、この誤り応答を送るだけでよいです。 さもなければ、それを送ってはいけません、そして、エラーコード400(悪いRequest)を示します。 MESSAGE-INTEGRITY属性でこの誤り応答を保護しなければなりません、そして、代替のサーバに自分たちを向け直す前に、受信機はこの応答のMESSAGE-INTEGRITYを有効にしなければなりません。
Note: Failure to generate and validate message integrity
for a 300 response allows an on-path attacker to falsify a
300 response thus causing subsequent STUN messages to be
sent to a victim.
以下に注意してください。 300応答のためにメッセージの保全を生成して、有効にしないことで、その結果、経路の攻撃者は、犠牲者に送られるべきその後のSTUNメッセージを引き起こしながら、300応答を改竄できます。
400 Bad Request: The request was malformed. The client SHOULD NOT
retry the request without modification from the previous
attempt. The server may not be able to generate a valid
MESSAGE-INTEGRITY for this error, so the client MUST NOT expect
a valid MESSAGE-INTEGRITY attribute on this response.
400の悪い要求: 要求は奇形でした。 クライアントSHOULD NOTは前の試みから変更なしで要求を再試行します。 サーバがこの誤りによって有効なMESSAGE-INTEGRITYを生成することができないかもしれないので、クライアントはこの応答の有効なMESSAGE-INTEGRITY属性を予想してはいけません。
401 Unauthorized: The request did not contain the correct
credentials to proceed. The client should retry the request
with proper credentials.
401 権限のない: 要求は続かせる正しい資格証明書を含みませんでした。 クライアントは適切な資格証明書で要求を再試行するべきです。
420 Unknown Attribute: The server received a STUN packet containing
a comprehension-required attribute that it did not understand.
The server MUST put this unknown attribute in the UNKNOWN-
ATTRIBUTE attribute of its error response.
420の未知の属性: サーバはそれが理解していなかった読解で必要な属性を含むSTUNパケットを受けました。 サーバは誤り応答のUNKNOWN- ATTRIBUTE属性にこの未知の属性を入れなければなりません。
438 Stale Nonce: The NONCE used by the client was no longer valid.
The client should retry, using the NONCE provided in the
response.
438 一回だけは聞き古したになってください: クライアントによって使用されたNONCEはもう有効ではありませんでした。 応答に提供されたNONCEを使用して、クライアントは再試行するべきです。
500 Server Error: The server has suffered a temporary error. The
client should try again.
500 サーバ誤り: サーバは一時的な誤りを受けました。 クライアントは再試行するべきです。
Rosenberg, et al. Standards Track [Page 37] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[37ページ]RFC5389は2008年10月に気絶させます。
15.7. REALM
15.7. 分野
The REALM attribute may be present in requests and responses. It contains text that meets the grammar for "realm-value" as described in RFC 3261 [RFC3261] but without the double quotes and their surrounding whitespace. That is, it is an unquoted realm-value (and is therefore a sequence of qdtext or quoted-pair). It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes), and MUST have been processed using SASLprep [RFC4013].
REALM属性は要求と応答で存在しているかもしれません。 それは「分野値」のためにRFC3261[RFC3261]で説明されますが、二重引用符とそれらの周囲の空白なしで文法を満たすテキストを含んでいます。 すなわち、それは引用を終わっている分野値(qdtextか引用された組にはしたがって、系列がある)です。 それは、128未満のキャラクタ(763バイトと同じくらい長いことができる)のUTF-8[RFC3629]のコード化された系列でなければならなく、SASLprep[RFC4013]を使用して、処理されたに違いありません。
Presence of the REALM attribute in a request indicates that long-term credentials are being used for authentication. Presence in certain error responses indicates that the server wishes the client to use a long-term credential for authentication.
要求における、REALM属性の存在は、長期の資格証明書が認証に使用されているのを示します。 ある誤り応答における存在は、サーバが、クライアントが認証に長期の資格証明書を使用する必要であるのを示します。
15.8. NONCE
15.8. 一回だけ
The NONCE attribute may be present in requests and responses. It contains a sequence of qdtext or quoted-pair, which are defined in RFC 3261 [RFC3261]. Note that this means that the NONCE attribute will not contain actual quote characters. See RFC 2617 [RFC2617], Section 4.3, for guidance on selection of nonce values in a server.
NONCE属性は要求と応答で存在しているかもしれません。 それはqdtextか引用された組の系列を含んでいます。(組はRFC3261[RFC3261]で定義されます)。 これが、NONCE属性が実際の引用文字を含まないことを意味することに注意してください。 指導に関してRFC2617[RFC2617]、セクション4.3をサーバにおける、一回だけの値の品揃えに見てください。
It MUST be less than 128 characters (which can be as long as 763 bytes).
それは128未満のキャラクタであるに違いありません(763バイトと同じくらい長いことができます)。
15.9. UNKNOWN-ATTRIBUTES
15.9. 未知の属性
The UNKNOWN-ATTRIBUTES attribute is present only in an error response when the response code in the ERROR-CODE attribute is 420.
ERROR-CODE属性における応答コードが420であるときに、UNKNOWN-ATTRIBUTES属性は誤り応答だけで存在しています。
The attribute contains a list of 16-bit values, each of which represents an attribute type that was not understood by the server.
属性は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タイプを結果と考えてください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of UNKNOWN-ATTRIBUTES Attribute
エイト環: 未知の属性属性の形式
Rosenberg, et al. Standards Track [Page 38] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[38ページ]RFC5389は2008年10月に気絶させます。
Note: In [RFC3489], this field was padded to 32 by duplicating the
last attribute. In this version of the specification, the normal
padding rules for attributes are used instead.
以下に注意してください。 [RFC3489]では、この分野は、最後の属性をコピーすることによって、32に水増しされました。 仕様のこのバージョンでは、属性のための正常な詰め物規則は代わりに使用されます。
15.10. SOFTWARE
15.10. ソフトウェア
The SOFTWARE attribute contains a textual description of the software being used by the agent sending the message. It is used by clients and servers. Its value SHOULD include manufacturer and version number. The attribute has no impact on operation of the protocol, and serves only as a tool for diagnostic and debugging purposes. The value of SOFTWARE is variable length. It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes).
SOFTWARE属性はメッセージを送るエージェントによって使用されるソフトウェアの原文の記述を含んでいます。 それはクライアントとサーバによって使用されます。 値のSHOULDはメーカーとバージョン番号を含んでいます。 属性は、プロトコルの操作に影響力を全く持たないで、単に病気の特徴とデバッグ目的のためのツールとして機能します。 SOFTWAREの値は可変長です。 それは128未満のキャラクタ(763バイトと同じくらい長いことができる)のUTF-8[RFC3629]のコード化された系列であるに違いありません。
15.11. ALTERNATE-SERVER
15.11. 代替のサーバ
The alternate server represents an alternate transport address identifying a different STUN server that the STUN client should try.
代替のサーバはSTUNクライアントが試みるべきである異なったSTUNサーバを特定する代替の輸送アドレスを表します。
It is encoded in the same way as MAPPED-ADDRESS, and thus refers to a single server by IP address. The IP address family MUST be identical to that of the source IP address of the request.
それは、MAPPED-ADDRESSと同様に、コード化されて、その結果、IPアドレスでただ一つのサーバを示します。 IPアドレスファミリーは要求のソースIPアドレスのものと同じであるに違いありません。
16. Security Considerations
16. セキュリティ問題
16.1. Attacks against the Protocol
16.1. プロトコルに対する攻撃
16.1.1. Outside Attacks
16.1.1. 攻撃の外で
An attacker can try to modify STUN messages in transit, in order to cause a failure in STUN operation. These attacks are detected for both requests and responses through the message-integrity mechanism, using either a short-term or long-term credential. Of course, once detected, the manipulated packets will be dropped, causing the STUN transaction to effectively fail. This attack is possible only by an on-path attacker.
攻撃者は、STUN操作における失敗を引き起こすようにトランジットにおけるSTUNメッセージを変更しようとすることができます。 短期的であるか長期の資格証明書を使用して、これらの攻撃は要求と応答の両方のためにメッセージの保全メカニズムを通して検出されます。 もちろん、いったん検出されると、事実上、STUNトランザクションが失敗することを引き起こすと、操られたパケットは下げられるでしょう。 この攻撃は単に経路の攻撃者が可能です。
An attacker that can observe, but not modify, STUN messages in- transit (for example, an attacker present on a shared access medium, such as Wi-Fi), can see a STUN request, and then immediately send a STUN response, typically an error response, in order to disrupt STUN processing. This attack is also prevented for messages that utilize MESSAGE-INTEGRITY. However, some error responses, those related to authentication in particular, cannot be protected by MESSAGE- INTEGRITY. When STUN itself is run over a secure transport protocol (e.g., TLS), these attacks are completely mitigated.
STUNを観測しますが、変更できない攻撃者は、中でトランジット(例えば、Wi-Fiなどの共用アクセス媒体に出席している攻撃者)を通信させて、STUN要求を見て、次に、すぐにSTUN応答、通常誤り応答を送ることができます、STUN処理を中断するために。 また、この攻撃はMESSAGE-INTEGRITYを利用するメッセージのために防がれます。 しかしながら、MESSAGE- INTEGRITYはいくつかの誤り応答(特に認証に関連するもの)を保護できません。 STUN自身が安全なトランスポート・プロトコル(例えば、TLS)の上に実行されると、これらの攻撃は完全に緩和されます。
Rosenberg, et al. Standards Track [Page 39] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[39ページ]RFC5389は2008年10月に気絶させます。
Depending on the STUN usage, these attacks may be of minimal consequence and thus do not require message integrity to mitigate. For example, when STUN is used to a basic STUN server to discover a server reflexive candidate for usage with ICE, authentication and message integrity are not required since these attacks are detected during the connectivity check phase. The connectivity checks themselves, however, require protection for proper operation of ICE overall. As described in Section 14, STUN usages describe when authentication and message integrity are needed.
STUN用法によって、これらの攻撃は、最小量の結果があるかもしれなくて、その結果、緩和するメッセージの保全を必要としません。 STUNがICEと共に用法のサーバ反動的候補を発見するのに基本的なSTUNサーバに使用されるとき、これらの攻撃が接続性チェック段階の間、検出されるので、例えば、認証とメッセージの保全は必要ではありません。 しかしながら、接続性チェック自体は全体的に見てICEの適切な操作のための保護を必要とします。 セクション14で説明されるように、STUN用法は、認証とメッセージの保全がいつ必要であるかを説明します。
Since STUN uses the HMAC of a shared secret for authentication and integrity protection, it is subject to offline dictionary attacks. When authentication is utilized, it SHOULD be with a strong password that is not readily subject to offline dictionary attacks. Protection of the channel itself, using TLS, mitigates these attacks. However, STUN is most often run over UDP and in those cases, strong passwords are the only way to protect against these attacks.
STUNが認証と保全保護に共有秘密キーのHMACを使用するので、それはオフライン辞書攻撃を受けることがあります。 認証は利用されていて、それはSHOULDです。いつ、強いパスワードと共にいてください、そして、すなわち、容易でなく、オフライン辞書への対象は攻撃されるか。 TLSを使用して、チャンネル自体の保護はこれらの攻撃を緩和します。 しかしながら、STUNはUDPの上にたいてい実行されます、そして、それらの場合では、強いパスワードはこれらの攻撃から守る唯一の方法です。
16.1.2. Inside Attacks
16.1.2. 攻撃で
A rogue client may try to launch a DoS attack against a server by sending it a large number of STUN requests. Fortunately, STUN requests can be processed statelessly by a server, making such attacks hard to launch.
多くのSTUN要求をそれに送ることによって、凶暴なクライアントはサーバに対してDoS攻撃に着手しようとするかもしれません。 幸い、そのような攻撃を始めるのを困難にして、サーバは状態がなくSTUN要求を処理できます。
A rogue client may use a STUN server as a reflector, sending it requests with a falsified source IP address and port. In such a case, the response would be delivered to that source IP and port. There is no amplification of the number of packets with this attack (the STUN server sends one packet for each packet sent by the client), though there is a small increase in the amount of data, since STUN responses are typically larger than requests. This attack is mitigated by ingress source address filtering.
凶暴なクライアントは反射鏡としてSTUNサーバを使用するかもしれません、改竄されたソースIPアドレスとポートによる要求をそれに送って。 このような場合には、応答はそのソースIPとポートに提供されるでしょう。 この攻撃によるパケットの数の増幅が全くありません(STUNサーバはクライアントによって送られた各パケットあたり1つのパケットを送ります)、データ量の微増がありますが、STUN応答が要求より通常大きいので。 この攻撃はイングレスソースアドレスフィルタリングによって緩和されます。
Revealing the specific software version of the agent through the SOFTWARE attribute might allow them to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make usage of the SOFTWARE attribute a configurable option.
SOFTWARE属性を通してエージェントの特定のソフトウェアバージョンを明らかにすることによって、それらはセキュリティーホールを含むのが知られているソフトウェアに対する攻撃により被害を受け易くなるかもしれません。 Implementers SHOULDはSOFTWARE属性の用法を構成可能なオプションにします。
16.2. Attacks Affecting the Usage
16.2. 用法に影響する攻撃
This section lists attacks that might be launched against a usage of STUN. Each STUN usage must consider whether these attacks are applicable to it, and if so, discuss counter-measures.
このセクションはSTUNの使用法に対して着手されるかもしれない攻撃を記載します。 それぞれのSTUN用法は、これらの攻撃がそれに適切であるかどうか考えなければなりません、そして、そうだとすれば、対応策について議論してください。
Most of the attacks in this section revolve around an attacker modifying the reflexive address learned by a STUN client through a
このセクションでの攻撃の大部分はaを通してSTUNクライアントによって学習された再帰のアドレスを変更する攻撃者を中心題目とします。
Rosenberg, et al. Standards Track [Page 40] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[40ページ]RFC5389は2008年10月に気絶させます。
Binding request/response transaction. Since the usage of the reflexive address is a function of the usage, the applicability and remediation of these attacks are usage-specific. In common situations, modification of the reflexive address by an on-path attacker is easy to do. Consider, for example, the common situation where STUN is run directly over UDP. In this case, an on-path attacker can modify the source IP address of the Binding request before it arrives at the STUN server. The STUN server will then return this IP address in the XOR-MAPPED-ADDRESS attribute to the client, and send the response back to that (falsified) IP address and port. If the attacker can also intercept this response, it can direct it back towards the client. Protecting against this attack by using a message-integrity check is impossible, since a message- integrity value cannot cover the source IP address, since the intervening NAT must be able to modify this value. Instead, one solution to preventing the attacks listed below is for the client to verify the reflexive address learned, as is done in ICE [MMUSIC-ICE]. Other usages may use other means to prevent these attacks.
要求/応答トランザクションを縛ります。 再帰のアドレスの用法が用法の機能であるので、これらの攻撃の適用性と治療教育は用法特有です。 日常の状況では、経路の攻撃者による再帰のアドレスの変更はしやすいです。 例えばSTUNがUDPの直接上に実行される日常の状況を考えてください。 この場合、STUNサーバに到着する前に経路の攻撃者はBinding要求のソースIPアドレスを変更できます。STUNサーバは、次に、XOR-MAPPED-ADDRESS属性におけるこのIPアドレスをクライアントに返して、それへの逆(改竄される)IPアドレスとポートを応答に送るでしょう。 また、攻撃者がこの応答を妨害できるなら、それはクライアントにそれを向けて戻すことができます。 メッセージの保全チェックを使用することによってこの攻撃から守るのは不可能です、メッセージ保全価値がソースIPアドレスをカバーできないので、介入しているNATがこの値を変更できなければならないので。 代わりに、以下に記載された攻撃を防ぐことへの1つのソリューションはクライアントがそのままでICE[MMUSIC-ICE]でしていた状態で学習された再帰のアドレスについて確かめることです。 他の用法はこれらの攻撃を防ぐ他の手段を使用するかもしれません。
16.2.1. Attack I: Distributed DoS (DDoS) against a Target
16.2.1. 攻撃I: 目標に対する分配されたDoS(DDoS)
In this attack, the attacker provides one or more clients with the same faked reflexive address that points to the intended target. This will trick the STUN clients into thinking that their reflexive addresses are equal to that of the target. If the clients hand out that reflexive address in order to receive traffic on it (for example, in SIP messages), the traffic will instead be sent to the target. This attack can provide substantial amplification, especially when used with clients that are using STUN to enable multimedia applications. However, it can only be launched against targets for which packets from the STUN server to the target pass through the attacker, limiting the cases in which it is possible.
この攻撃では、攻撃者は意図している目標を示す再帰のアドレスを同じくらいが見せかけられている1人以上のクライアントに提供します。 これは、STUNクライアントが、彼らの再帰のアドレスが目標のものと等しいと考えるようにだますでしょう。 クライアントがそれ(例えばSIPメッセージで)でトラフィックを受けるためにその再帰のアドレスを与えると、代わりにトラフィックを目標に送るでしょう。 特にマルチメディア応用を可能にするのにSTUNを使用しているクライアントと共に使用されると、この攻撃はかなりの増幅を提供できます。 しかしながら、STUNサーバから目標までのパケットが攻撃者を通り抜ける目標に対してそれを始めることができるだけです、それが可能である場合を制限して。
16.2.2. Attack II: Silencing a Client
16.2.2. 攻撃II: クライアントを黙らせます。
In this attack, the attacker provides a STUN client with a faked reflexive address. The reflexive address it provides is a transport 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 reflexive 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. As with the attack in Section 16.2.1, this attack is only possible when the attacker is on path for packets sent from the STUN server towards this unused IP address.
この攻撃では、攻撃者は見せかけられた再帰のアドレスをSTUNクライアントに提供します。 それが提供する再帰のアドレスはそれがどこにも発送しない輸送アドレスです。 再帰のアドレスを与えるとき、その結果、クライアントはそれが受けると予想するパケットのいずれも受けないでしょう。 この攻略は攻撃者によってそれほどおもしろくはありません。 それは独身のクライアントに影響を与えます(頻繁に必要な目標ではありません)。 そのうえ、また、攻撃を仕掛けることができるどんな攻撃者も他の手段でクライアントに対するサービスを否定する場合がありました、クライアントがSTUNサーバ、またはDHCPサーバからさえどんな応答も受けるのを防ぐのなどように。攻撃者がSTUNサーバからこの未使用のIPアドレスに向かって送られたパケットのための経路にいるとき、単にセクション16.2.1における攻撃のように、この攻撃は可能です。
Rosenberg, et al. Standards Track [Page 41] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[41ページ]RFC5389は2008年10月に気絶させます。
16.2.3. Attack III: Assuming the Identity of a Client
16.2.3. 攻撃III: クライアントのアイデンティティを仮定します。
This attack is similar to attack II. However, the faked reflexive address points to the attacker itself. This allows the attacker to receive traffic that was destined for the client.
この攻撃は、IIを攻撃するために同様です。 しかしながら、見せかけられた再帰のアドレスは攻撃者自身を示します。 これで、攻撃者はクライアントのために運命づけられたトラフィックを受け取ることができます。
16.2.4. Attack IV: Eavesdropping
16.2.4. 攻撃IV: 盗聴
In this attack, the attacker forces the client to use a reflexive 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.
この攻撃では、攻撃者はクライアントに強制的にそれがそれ自体に発送する再帰のアドレスを使用させます。 そして、それはクライアントに受けるどんなパケットも進めます。 この攻撃で、攻撃者はクライアントに送られたすべてのパケットを観察できるでしょう。 しかしながら、攻撃に着手するために、攻撃者はクライアントからSTUNサーバまで既にパケットを観察できたに違いありません。多くの場合(攻撃がアクセスネットワークから着手される時としてのそのようなもの)、これは、攻撃者が既にクライアントに送られたパケットを観察できたことを意味します。 この攻撃は、その結果単に経路で攻撃者でクライアントからSTUNサーバまでトラフィックを観測することの役に立ちますが、一般にクライアントに向かって発送されるパケットの経路で役に立つというわけではありません。
16.3. Hash Agility Plan
16.3. ハッシュ機敏さプラン
This specification uses HMAC-SHA-1 for computation of the message integrity. If, at a later time, HMAC-SHA-1 is found to be compromised, the following is the remedy that will be applied.
この仕様はメッセージの保全の計算にHMAC-SHA-1を使用します。 HMAC-SHA-1が後で感染されるのがわかっているなら、↓これは適用される療法です。
We will define a STUN extension that introduces a new message- integrity attribute, computed using a new hash. Clients would be required to include both the new and old message-integrity attributes in their requests or indications. A new server will utilize the new message-integrity attribute, and an old one, the old. After a transition period where mixed implementations are in deployment, the old message-integrity attribute will be deprecated by another specification, and clients will cease including it in requests.
私たちは新しいハッシュを使用することで計算された新しいメッセージ保全属性を導入するSTUN拡張子を定義するつもりです。 クライアントは彼らの要求か指摘に両方の新しくて古いメッセージの保全属性を含まなければならないでしょう。 新しいサーバは新しいメッセージの保全属性、および古いもの、老人を利用するでしょう。 過渡期の後に、複雑な実装が展開中であるところで古いメッセージの保全属性は別の仕様で推奨しなくなるでしょう、そして、クライアントは要求にそれを含んでいるのをやめるでしょう。
It is also important to note that the HMAC is done using a key that is itself computed using an MD5 of the user's password. The choice of the MD5 hash was made because of the existence of legacy databases that store passwords in that form. If future work finds that an HMAC of an MD5 input is not secure, and a different hash is needed, it can also be changed using this plan. However, this would require administrators to repopulate their databases.
また、HMACがユーザのパスワードのMD5を使用することで計算されるキーを使用し終わっていることに注意するのも重要です。 そのフォームにパスワードを保存するレガシーデータベースの存在のためにMD5ハッシュの選択をしました。 また、MD5入力のHMACが安全でないことが今後の活動によってわかって、異なったハッシュを必要とするなら、このプランを使用することでそれを変えることができます。 しかしながら、これは、管理者が彼らのデータベースを再植民するのを必要とするでしょう。
17. IAB Considerations
17. IAB問題
The IAB has studied the problem of Unilateral Self-Address Fixing (UNSAF), which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT
IABはUnilateral Self-アドレスFixing(UNSAF)の問題を研究しました。(FixingはクライアントがNATの反対側の別の分野でアドレスを決定するのを試みる一般的なプロセスです)。
Rosenberg, et al. Standards Track [Page 42] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[42ページ]RFC5389は2008年10月に気絶させます。
through a collaborative protocol reflection mechanism (RFC3424 [RFC3424]). STUN can be used to perform this function using a Binding request/response transaction if one agent is behind a NAT and the other is on the public side of the NAT.
協力的なプロトコル反射メカニズム(RFC3424[RFC3424])を通して。 1人のエージェントがNATの後ろにいて、もう片方がNAT公共側にあるならBinding要求/応答トランザクションを使用することでこの機能を実行するのにSTUNを使用できます。
The IAB has mandated that protocols developed for this purpose document a specific set of considerations. Because some STUN usages provide UNSAF functions (such as ICE [MMUSIC-ICE] ), and others do not (such as SIP Outbound [SIP-OUTBOUND]), answers to these considerations need to be addressed by the usages themselves.
IABは、プロトコルがこの目的ドキュメントのために問題の特定のセットを発展させたのを強制しました。 いくつかのSTUN用法が機能(ICE[MMUSIC-ICE]などの)をUNSAFに供給して、他のものが(SIP Outbound[SIP-OUTBOUND]としてのそのようなもの)でないのをするので、これらの問題の答えは、用法自体で扱われる必要があります。
18. IANA Considerations
18. IANA問題
IANA has created three new registries: a "STUN Methods Registry", a "STUN Attributes Registry", and a "STUN Error Codes Registry". IANA has also changed the name of the assigned IANA port for STUN from "nat-stun-port" to "stun".
IANAは3つの新しい登録を作成しました: aは「メソッド登録を気絶させます」、そして、aは「属性登録を気絶させます」、そして、aは「エラーコード登録を気絶させます」。 また、「natはポートを気絶させること」からのSTUNが「気絶させる」ように、IANAが割り当てられたIANAポートの名前を変えました。
18.1. STUN Methods Registry
18.1. メソッド登録を気絶させてください。
A STUN method is a hex number in the range 0x000 - 0xFFF. The encoding of STUN method into a STUN message is described in Section 6.
STUNメソッドは範囲0x000の十六進法番号です--0xFFF。 STUNメッセージへのSTUNメソッドのコード化はセクション6で説明されます。
The initial STUN methods are:
初期のSTUNメソッドは以下の通りです。
0x000: (Reserved) 0x001: Binding 0x002: (Reserved; was SharedSecret)
0×000: (予約される)です。 0×001: 結合0x002: (予約されました; SharedSecretでした)
STUN methods in the range 0x000 - 0x7FF are assigned by IETF Review [RFC5226]. STUN methods in the range 0x800 - 0xFFF are assigned by Designated Expert [RFC5226]. The responsibility of the expert is to verify that the selected codepoint(s) are not in use and that the request is not for an abnormally large number of codepoints. Technical review of the extension itself is outside the scope of the designated expert responsibility.
範囲0x000のSTUNメソッド--0x7FFはIETF Review[RFC5226]によって割り当てられます。 範囲0x800のSTUNメソッド--0xFFFはDesignated Expert[RFC5226]によって割り当てられます。 専門家の責任は選択されたcodepoint(s)が使用中でなく、また要求が多くのcodepointsのためのものでないことを確かめることです。 指定された専門の責任の範囲の外に拡大自体の技術審査があります。
18.2. STUN Attribute Registry
18.2. 属性登録を気絶させてください。
A STUN Attribute type is a hex number in the range 0x0000 - 0xFFFF. STUN attribute types in the range 0x0000 - 0x7FFF are considered comprehension-required; STUN attribute types in the range 0x8000 - 0xFFFF are considered comprehension-optional. A STUN agent handles unknown comprehension-required and comprehension-optional attributes differently.
STUN Attributeタイプは範囲0x0000の十六進法番号です--0xFFFF。 範囲0x0000のSTUN属性タイプ--0x7FFFは読解で必要であると考えられます。 範囲0x8000のSTUN属性タイプ--0xFFFFは読解任意であると考えられます。 STUNエージェントは未知の読解で必要で読解任意の属性を異なって扱います。
The initial STUN Attributes types are:
初期のSTUN Attributesタイプは以下の通りです。
Rosenberg, et al. Standards Track [Page 43] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[43ページ]RFC5389は2008年10月に気絶させます。
Comprehension-required range (0x0000-0x7FFF):
0x0000: (Reserved)
0x0001: MAPPED-ADDRESS
0x0002: (Reserved; was RESPONSE-ADDRESS)
0x0003: (Reserved; was CHANGE-ADDRESS)
0x0004: (Reserved; was SOURCE-ADDRESS)
0x0005: (Reserved; was CHANGED-ADDRESS)
0x0006: USERNAME
0x0007: (Reserved; was PASSWORD)
0x0008: MESSAGE-INTEGRITY
0x0009: ERROR-CODE
0x000A: UNKNOWN-ATTRIBUTES
0x000B: (Reserved; was REFLECTED-FROM)
0x0014: REALM
0x0015: NONCE
0x0020: XOR-MAPPED-ADDRESS
読解で必要な範囲(0×0000 0x7FFF): 0×0000: (予約される)です。 0×0001: 写像しているアドレス0×0002: (予約されました; RESPONSE-ADDRESSでした) 0×0003: (予約されました; CHANGE-ADDRESSでした) 0×0004: (予約されました; SOURCE-ADDRESSでした) 0×0005: (予約されました; CHANGED-ADDRESSでした) 0×0006: ユーザ名0x0007: (予約されました; PASSWORDでした) 0×0008: メッセージの保全0x0009: エラーコード0x000A: 未知の属性0x000B: (予約されました; REFLECTED-FROMでした) 0×0014: 分野0x0015: 一回だけ0x0020: XORはアドレスを写像しました。
Comprehension-optional range (0x8000-0xFFFF)
0x8022: SOFTWARE
0x8023: ALTERNATE-SERVER
0x8028: FINGERPRINT
読解任意の範囲(0×8000 0xFFFF)0×8022: ソフトウェア0x8023: 代替のサーバ0×8028: 指紋
STUN Attribute types in the first half of the comprehension-required range (0x0000 - 0x3FFF) and in the first half of the comprehension- optional range (0x8000 - 0xBFFF) are assigned by IETF Review [RFC5226]. STUN Attribute types in the second half of the comprehension-required range (0x4000 - 0x7FFF) and in the second half of the comprehension-optional range (0xC000 - 0xFFFF) are assigned by Designated Expert [RFC5226]. The responsibility of the expert is to verify that the selected codepoint(s) are not in use, and that the request is not for an abnormally large number of codepoints. Technical review of the extension itself is outside the scope of the designated expert responsibility.
STUN Attributeは読解で必要な範囲(0×0000--0x3FFF)の前半にタイプして、読解の任意の範囲(0×8000--0xBFFF)の前半にIETF Review[RFC5226]によって割り当てられます。 STUN Attributeは読解で必要な範囲(0×4000--0x7FFF)の後半にタイプして、読解任意の範囲(0xC000--0xFFFF)の後半にDesignated Expert[RFC5226]によって割り当てられます。 専門家の責任は選択されたcodepoint(s)が使用中でなく、また要求が多くのcodepointsのためのものでないことを確かめることです。 指定された専門の責任の範囲の外に拡大自体の技術審査があります。
18.3. STUN Error Code Registry
18.3. エラーコード登録を気絶させてください。
A STUN error code is a number in the range 0 - 699. STUN error codes are accompanied by a textual reason phrase in UTF-8 [RFC3629] that is intended only for human consumption and can be anything appropriate; this document proposes only suggested values.
STUNエラーコードは範囲0--699の数です。 STUNエラーコードは単に人間の消費で意図して、何か適切なものであるかもしれないUTF-8[RFC3629]の原文の理由句によって伴われます。 このドキュメントは提案された値だけを提案します。
STUN error codes are consistent in codepoint assignments and semantics with SIP [RFC3261] and HTTP [RFC2616].
STUNエラーコードはcodepoint課題と意味論でSIP[RFC3261]とHTTP[RFC2616]と一致しています。
The initial values in this registry are given in Section 15.6.
セクション15.6でこの登録の初期の値を与えます。
Rosenberg, et al. Standards Track [Page 44] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[44ページ]RFC5389は2008年10月に気絶させます。
New STUN error codes are assigned based on IETF Review [RFC5226]. The specification must carefully consider how clients that do not understand this error code will process it before granting the request. See the rules in Section 7.3.4.
新しいSTUNエラーコードはIETF Review[RFC5226]に基づいて割り当てられます。 仕様は、要求を承諾する前にこのエラーコードを理解していないクライアントがどのようにそれを処理するかを慎重に考えなければなりません。 セクション7.3.4における規則を見てください。
18.4. STUN UDP and TCP Port Numbers
18.4. UDPとTCPポートナンバーを気絶させてください。
IANA has previously assigned port 3478 for STUN. This port appears in the IANA registry under the moniker "nat-stun-port". In order to align the DNS SRV procedures with the registered protocol service, IANA is requested to change the name of protocol assigned to port 3478 from "nat-stun-port" to "stun", and the textual name from "Simple Traversal of UDP Through NAT (STUN)" to "Session Traversal Utilities for NAT", so that the IANA port registry would read:
IANAは以前に、STUNのためにポート3478を割り当てました。 このポートはあだ名の下のIANA登録で「natにポートを気絶させる」ように見えます。 登録されたプロトコルサービスにDNS SRV手順を一直線にするために、IANAが「natはポートを気絶させること」から「気絶させる」3478を移植するために割り当てられたプロトコルの名前、および原文の「NAT(気絶させる)を通したUDPの簡単な縦断」から「NATのためのセッション縦断ユーティリティ」までの名前を変えるよう要求されています、IANAポート登録が読むように:
stun 3478/tcp Session Traversal Utilities for NAT (STUN) port stun 3478/udp Session Traversal Utilities for NAT (STUN) port
NAT(STUN)ポートが3478/udp Session Traversal UtilitiesをNAT(STUN)ポートに気絶させるので、3478/tcp Session Traversal Utilitiesを気絶させてください。
In addition, IANA has assigned port number 5349 for the "stuns" service, defined over TCP and UDP. The UDP port is not currently defined; however, it is reserved for future use.
さらに、IANAはTCPとUDPの上で定義された「気絶させる」サービスのポートNo.5349を割り当てました。 UDPポートは現在、定義されません。 しかしながら、それは今後の使用のために予約されます。
19. Changes since RFC 3489
19. RFC3489以来の変化
This specification obsoletes RFC 3489 [RFC3489]. This specification differs from RFC 3489 in the following ways:
この仕様はRFC3489[RFC3489]を時代遅れにします。 この仕様は以下の方法でRFC3489と異なっています:
o Removed the notion that STUN is a complete NAT traversal solution.
STUN is now a tool that can be used to produce a NAT traversal
solution. As a consequence, changed the name of the protocol to
Session Traversal Utilities for NAT.
o STUNが完全なNAT縦断対策であるという概念を取り除きました。 現在、STUNはNAT縦断対策を作成するのに使用できるツールです。 結果として変える、NATのためにプロトコルの名前をSession Traversal Utilitiesに変えました。
o Introduced the concept of STUN usages, and described what a usage
of STUN must document.
o STUN用法の概念を紹介して、STUNの使用法が記録しなければならないことについて説明しました。
o Removed the usage of STUN for NAT type detection and binding
lifetime discovery. These techniques have proven overly brittle
due to wider variations in the types of NAT devices than described
in this document. Removed the RESPONSE-ADDRESS, CHANGED-ADDRESS,
CHANGE-REQUEST, SOURCE-ADDRESS, and REFLECTED-FROM attributes.
o NATタイプ検出と拘束力がある生涯発見のためにSTUNの使用法を取り除きました。 これらのテクニックはNATデバイスのタイプの本書では説明されるより広い変化のためにひどくもろいと判明しました。 RESPONSE-ADDRESS、CHANGED-ADDRESS、CHANGE-REQUEST、SOURCE-ADDRESS、およびREFLECTED-FROM属性を取り外しました。
o Added a fixed 32-bit magic cookie and reduced length of
transaction ID by 32 bits. The magic cookie begins at the same
offset as the original transaction ID.
o 固定32ビットの魔法のクッキーを加えて、32ビットに従って、トランザクションIDの長さを減少させました。 魔法のクッキーはオリジナルのトランザクションIDと同じオフセットで始まります。
Rosenberg, et al. Standards Track [Page 45] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[45ページ]RFC5389は2008年10月に気絶させます。
o Added the XOR-MAPPED-ADDRESS attribute, which is included in
Binding responses if the magic cookie is present in the request.
Otherwise, the RFC 3489 behavior is retained (that is, Binding
response includes MAPPED-ADDRESS). See discussion in XOR-MAPPED-
ADDRESS regarding this change.
o XOR-MAPPED-ADDRESS属性を加えました。(魔法のクッキーが要求に存在しているなら、それは、Binding応答に含まれています)。 さもなければ、RFC3489の振舞いは保有されます(すなわち、Binding応答はMAPPED-ADDRESSを含んでいます)。 この変化に関してXOR-MAPPED- ADDRESSの議論を見てください。
o Introduced formal structure into the message type header field,
with an explicit pair of bits for indication of request, response,
error response, or indication. Consequently, the message type
field is split into the class (one of the previous four) and
method.
o 要求、応答、誤り応答、または指示のしるしのためにビットの明白な組と共にメッセージタイプヘッダーフィールドにホルマール構造を取り入れました。 タイプ分野がクラスに分けられるという(前の4つのものの1つ)その結果メッセージとメソッド。
o Explicitly point out that the most significant 2 bits of STUN are
0b00, allowing easy differentiation with RTP packets when used
with ICE.
o STUNの最も重要な2ビットが0b00であると明らかに指摘してください、ICEと共に使用されるとRTPパケットで簡単な分化を許容して。
o Added the FINGERPRINT attribute to provide a method of definitely
detecting the difference between STUN and another protocol when
the two protocols are multiplexed together.
o 2つのプロトコルを一緒に多重送信するとき確実にSTUNと別のプロトコルの違いを検出するメソッドを提供するためにFINGERPRINT属性を加えました。
o Added support for IPv6. Made it clear that an IPv4 client could
get a v6 mapped address, and vice versa.
o IPv6のサポートを加えました。 IPv4クライアントがv6を手に入れることができたのがアドレスを写像して、逆もまた同様ですと断言しました。
o Added long-term-credential-based authentication.
o 長期の資格証明書ベースの認証を加えました。
o Added the SOFTWARE, REALM, NONCE, and ALTERNATE-SERVER attributes.
o SOFTWARE、REALM、NONCE、およびALTERNATE-SERVER属性を加えました。
o Removed the SharedSecret method, and thus the PASSWORD attribute.
This method was almost never implemented and is not needed with
current usages.
o SharedSecretメソッドを取り外して、その結果、PASSWORD属性を取り外しました。 このメソッドは、ほとんど実装されないで、また現在の用法で必要ではありません。
o Removed recommendation to continue listening for STUN responses
for 10 seconds in an attempt to recognize an attack.
o 攻撃を認識する試みにおける10秒間、STUN応答の聞こうとし続けているという推薦を取り除きました。
o Changed transaction timers to be more TCP friendly.
o より多くのTCP好意的になるようにトランザクションタイマを変えました。
o Removed the STUN example that centered around the separation of
the control and media planes. Instead, provided more information
on using STUN with protocols.
o コントロールとメディア飛行機の分離を中心に置いたSTUNの例を取り除きました。 代わりにプロトコルがあるSTUNを使用する提供された詳しい情報。
o Defined a generic padding mechanism that changes the
interpretation of the length attribute. This would, in theory,
break backwards compatibility. However, the mechanism in RFC 3489
never worked for the few attributes that weren't aligned naturally
on 32-bit boundaries.
o 長さ属性の解釈を変えるジェネリック詰め物メカニズムを定義しました。 これは理論上後方に互換性を壊すでしょう。 しかしながら、RFC3489のメカニズムは32ビットの境界で自然に並べられなかったわずかな属性のために決して動作しませんでした。
o REALM, SERVER, reason phrases, and NONCE limited to 127
characters. USERNAME to 513 bytes.
o REALM(SERVER)は句、および127のキャラクタに制限されたNONCEを推論します。 513バイトへのUSERNAME。
Rosenberg, et al. Standards Track [Page 46] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[46ページ]RFC5389は2008年10月に気絶させます。
o Changed the DNS SRV procedures for TCP and TLS. UDP remains the
same as before.
o TCPとTLSのためにDNS SRV手順を変えました。 UDPは従来と同様同じままで残っています。
20. Contributors
20. 貢献者
Christian Huitema and Joel Weinberger were original co-authors of RFC 3489.
クリスチャンのHuitemaとジョエル・ワインバーガーはRFC3489のオリジナルの共著者でした。
21. Acknowledgements
21. 承認
The authors would like to thank Cedric Aoun, Pete Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus Westerlund, Miguel Garcia, Bruce Lowekamp, 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ジョニングス、ボブ・ペンフィールド、ザビエルMarjou、マグヌスWesterlund、ミゲル・ガルシア、ブルースLowekamp、彼らのコメントのためのクリス・サリバン、バルク書Sterman、およびアランHawrylyshenに感謝したがっています。 レスリーDaigle、アリソン・マンキン、エリック・レスコラ、およびヘニングSchulzrinneをこの仕事のときに入力されたIESGとIABのためにありがとうございます。
22. References
22. 参照
22.1. Normative References
22.1. 引用規格
[ITU.V42.2002] International Telecommunications Union, "Error-
correcting Procedures for DCEs Using Asynchronous-
to-Synchronous Conversion", ITU-T Recommendation
V.42, March 2002.
[ITU.V42.2002]国際Telecommunications Union、「DCEs Using AsynchronousのためにProceduresを修正する誤り、-、同期、Conversion、」、ITU-T Recommendation V.42、3月2002日
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication",
RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460,
December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
Rosenberg, et al. Standards Track [Page 47] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[47ページ]RFC5389は2008年10月に気絶させます。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J.,
Lawrence, S., Leach, P., Luotonen, A., and L.
Stewart, "HTTP Authentication: Basic and Digest
Access Authentication", RFC 2617, June 1999.
[RFC2617] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS
RR for specifying the location of services (DNS
SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P.、およびL.Esibov、「サービスの位置を指定するためのDNS RR(DNS SRV)」、RFC2782(2000年2月)。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 2000.
[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for
User Names and Passwords", RFC 4013, February 2005.
[RFC4013]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。
22.2. Informative References
22.2. 有益な参照
[BEHAVE-NAT] MacDonald, D. and B. Lowekamp, "NAT Behavior
Discovery Using STUN", Work in Progress, July 2008.
[NATを振る舞わせている] 「使用が気絶させられるというNAT振舞い発見」というマクドナルド、D.、およびB.Lowekampは進歩、2008年7月に働いています。
[BEHAVE-TURN] Rosenberg, J., Mahy, R., and P. Matthews,
"Traversal Using Relays around NAT (TURN): Relay
Extensions to Session Traversal Utilities for NAT
(STUN)", Work in Progress, July 2008.
[回転を振る舞わせている] ローゼンバーグ、J.、マーイ、R.、およびP.マシューズ、「縦断使用はNAT(ターンする)の周りで以下をリレーします」。 「NAT(気絶させる)のためのセッション縦断ユーティリティへのリレー拡大」は進歩、2008年7月に働いています。
[KARN87] Karn, P. and C. Partridge, "Improving Round-Trip
Time Estimates in Reliable Transport Protocols",
SIGCOMM 1987, August 1987.
[KARN87] KarnとP.とC.ヤマウズラ、「信頼できるトランスポート・プロトコルにおける往復の時間見積りを改良します」、SIGCOMM1987、1987年8月。
[MMUSIC-ICE] Rosenberg, J., "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal for Offer/Answer
Protocols", Work in Progress, October 2007.
ローゼンバーグ、[MMUSIC-氷]J.、「対話的な接続性設立(氷):」 「申し出/答えプロトコルのためのネットワークアドレス変換機構(NAT)縦断のためのプロトコル」、処理中の作業、2007年10月。
[MMUSIC-ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive
Connectivity Establishment (ICE)", Work
in Progress, July 2008.
[MMUSIC氷のTCP] ローゼンバーグ、J.、「対話的な接続性設立(氷)のTCP候補」が進歩、2008年7月に働いています。
[RFC2616] 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.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
Rosenberg, et al. Standards Track [Page 48] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[48ページ]RFC5389は2008年10月に気絶させます。
[RFC3261] 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.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Model with Session Description Protocol (SDP)",
RFC 3264, June 2002.
[RFC3264] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for
UNilateral Self-Address Fixing (UNSAF) Across
Network Address Translation", RFC 3424,
November 2002.
[RFC3424] DaigleとL.とIAB、「一方的な自己アドレスのためのネットワークアドレス変換の向こう側に(UNSAF)を修理するIAB問題」、RFC3424、2002年11月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R.
Mahy, "STUN - Simple Traversal of User Datagram
Protocol (UDP) Through Network Address Translators
(NATs)", RFC 3489, March 2003.
[RFC3489] ローゼンバーグ、J.、ワインバーガー、J.、Huitema、C.、およびR.マーイ、「気絶させてください--ネットワークアドレス変換機構(NATs)を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、2003年3月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for
Cryptographic Key Management", BCP 107, RFC 4107,
June 2005.
[RFC4107]Bellovin、S.とR.Housley、「暗号化キー管理のためのガイドライン」BCP107、2005年6月のRFC4107。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T.、およびH.Alvestrand(「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
[SIP-OUTBOUND] Jennings, C. and R. Mahy, "Managing Client
Initiated Connections in the Session Initiation
Protocol (SIP)", Work in Progress, June 2008.
[一口外国行き]のジョニングス、C.、およびR.マーイ、「クライアントを管理すると、セッション開始プロトコル(一口)のコネクションズは開始しました」、処理中の作業、2008年6月。
Rosenberg, et al. Standards Track [Page 49] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[49ページ]RFC5389は2008年10月に気絶させます。
Appendix A. C Snippet to Determine STUN Message Types
メッセージタイプを気絶させるように決定する付録A.C切れ端
Given a 16-bit STUN message type value in host byte order in msg_type parameter, below are C macros to determine the STUN message types:
msg_型引数のホストバイトオーダーにおける16ビットのSTUNメッセージタイプ価値を考えて、STUNメッセージがタイプすることを決定するCマクロが以下にあります:
#define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000) #define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010) #define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100) #define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110)
#定義..タイプ..タイプ..0×0110..0×0000..定義..タイプ..タイプ..0×0110..0×0010..定義..タイプ..タイプ..0×0110..0×0100..定義..タイプ(((msg_タイプ)と0×0110)=0×0110)
Authors' Addresses
作者のアドレス
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサンローゼンバーグシスコのニュージャージーエディソン(米国)
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
メール: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Rohan Mahy Unaffiliated
RohanマーイUnaffiliatedです。
EMail: rohan@ekabal.com
メール: rohan@ekabal.com
Philip Matthews Unaffiliated
フィリップ・マシューズUnaffiliatedです。
EMail: philip_matthews@magma.ca
メール: philip_matthews@magma.ca
Dan Wing Cisco 771 Alder Drive San Jose, CA 95035 US
ダン翼のシスコ771ハンノキDriveカリフォルニア95035サンノゼ(米国)
EMail: dwing@cisco.com
メール: dwing@cisco.com
Rosenberg, et al. Standards Track [Page 50] RFC 5389 STUN October 2008
ローゼンバーグ、他 標準化過程[50ページ]RFC5389は2008年10月に気絶させます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Rosenberg, et al. Standards Track [Page 51]
ローゼンバーグ、他 標準化過程[51ページ]
一覧
スポンサーリンク
