この文書はRFC 5389の日本語訳(和訳)です。この文書の翻訳内容の正確さは保障 できないため、正確な知識や情報を求める方は原文を参照してください。翻訳者 はこの文書によって読者が被り得る如何なる損害の責任をも負いません。この翻 訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。この文書の 配布は元のRFC同様に無制限です。 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 NATのためのセッショントラバーサルユーティリティ (STUN) このメモの位置づけ この文書は、インターネットコミュニティのためのインターネット標準ト ラックプロトコルを規定して、そして改良のための議論と提案を求める。こ のプロトコルの標準化状態と位置づけは、"インターネット公式プロトコル標 準" (STD 1)の最新版を参照されたい。このメモの配布に制限はない。 要約 Session Traversal Utilities for NAT (STUN)は、他のプロトコルが、 Network Address Translator(NAT)越えを処理するためのツールとして役立つ プロトコルである。STUNは、エンドポイントがNATによって割り当てられたIP アドレスとポートを判定するのに使用できる。また、2つのエンドポイント間 の接続性のチェック、そしてNATバインディングを維持するキープアライブプ ロトコルとして使用できる。STUNは多くの既存のNATsで動作して、それらか らどんな特別な挙動も要求しない。 STUNはそれ自身でNAT越えソリューションではない。むしろ、NAT越えソ リューションの中で使用されるツールである。これは、完全なソリューショ ンとしてSTUNを提供していた、この仕様の旧版(RFC 3489)からの重要な変化 である。 この文書は RFC 3489 を廃止する。 目次 1. 前置き ..........................................................4 2. RFC 3489からの進化 ..............................................4 3. 操作の概要 ......................................................5 4. 用語 ............................................................8 5. 定義 ............................................................8 6. STUNメッセージ構造 .............................................10 7. 基本プロトコル手順 .............................................12 7.1. リクエストまたはインディケーションの形成 ..................12 7.2. リクエストまたはインディケーションの送信 ..................13 Rosenberg, et al. Standards Track [Page 1] RFC 5389 STUN October 2008 7.2.1. UDP上での送信 ......................................13 7.2.2. TCPやTLS-over-TCP上での送信 ........................14 7.3. STUNメッセージの受信 ......................................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. FINGERPRINTメカニズム ..........................................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. ALTERNATE-SERVERメカニズム ....................................28 12. RFC 3489との後方互換性 ........................................28 12.1. クライアント処理の変更点 .................................29 12.2. サーバ処理の変更点 .......................................29 13. 基本的なサーバの挙動 ..........................................30 14. STUN用法 ......................................................30 15. STUNアトリビュート ............................................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. セキュリティの検討事項 ........................................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 16.2.3. 攻撃III: クライアントの身元の横領 .................42 16.2.4. 攻撃IV: 盗み聞き ..................................42 16.3. ハッシュアルゴリズムの移行計画 ...........................42 17. IABの検討事項 .................................................42 18. IANAの検討事項 ................................................43 18.1. STUNメソッドレジストリ ...................................43 18.2. STUNアトリビュートレジストリ .............................43 18.3. STUNエラーコードレジストリ ...............................44 18.4. STUN UDP/TCPポート番号 ...................................45 19. RFC 3489からの変更 ............................................45 20. 貢献者 ........................................................47 21. 謝辞 ..........................................................47 22. 参考文献 ......................................................47 22.1. 規範的な参考文献 .........................................47 22.2. 有益な参考文献 ...........................................48 付録A. STUNメッセージタイプを判定するCの補完機能 .................50 Rosenberg, et al. Standards Track [Page 3] RFC 5389 STUN October 2008 1. 前置き この仕様書に定義されたプロトコル、Session Traversal Utilities for NAT は、NATsを処理するツールを提供する。エンドポイントのプライベートIPア ドレス/ポートに対応する、NATによって割り当てられたIPアドレス/ポートを 判定する手段をエンドポイントに提供する。また、エンドポイントがNATバイ ンディングを有効に保つための方法を提供する。いくつかの拡張を使用し て、このプロトコルは2つのエンドポイント間の接続性チェックをすること [MMUSIC-ICE] や、2つのエンドポイント間のパケットを中継すること [BEHAVE-TURN] に使用できる。 ツール性を維持するために、この仕様書は、拡張可能なパケットフォーマッ トを定義して、いくつかのトランスポートプロトコル上の操作を定義して、2 つの形式の認証を提供する。 STUNは、1つまたはそれ以上のNAT越えソリューション中で使用されることを 意図する。これらのソリューションはSTUN用法として知られている。各用法 は、STUNがNAT越えソリューションを達成するのにどう利用されるかを説明す る。一般的に、用法は、いつSTUNメッセージを送信して、どのオプションア トリビュートを含んでいて、何のサーバが使用されて、そして何の認証機構 が使用されるか、を示す。Interactive Connectivity Establishment (ICE) [MMUSIC-ICE]は、STUNの1つの用法だ。SIP Outbound [SIP-OUTBOUND]は、 STUNの別の用法だ。いくつかの場合、用法はSTUNに拡張を要求するだろう。 STUNの拡張は、新しいメソッド、アトリビュート、あるいはエラーレスポン スコードの形式とすることができる。STUN用法に関する詳しい情報を14章で 見つけることができる。 2. RFC 3489からの進化 STUNは元々RFC 3489 [RFC3489] で定義された。たまに"クラシックSTUN"とし て参照されるその仕様は、NAT越え問題の完全解を述べていた。そのソ リューションでは、クライアントがNATの背後にいるかどうかを検出して、 NATタイプを判定して、最も外側にあるNATのパブリック側のIPアドレス/ポー トを検出するだろう。それから、Session Initiation Protocol (SIP) [RFC3261] などのようなプロトコルのボディー中でそのIPアドレス/ポートを 利用する。しかしながら、RFC 3489の公表からの経験で、クラシックSTUNが 展開可能なソリューションとして十分よく機能していないということが分 かった。クラシックSTUNを通して知ったアドレス/ポートは、ピアとの通信に ある時は使用可能で、ある時はそうではない。クラシックSTUNは実際はそれ が機能するかどうか検出する方法を全く提供していなく、そして、それが機 能しなかったケースで救済策を全く提供しなかった。その上、多くのNATsが きれいにそこで定義されたタイプに収まらなかったので、NATタイプの分類の ためのクラシックSTUNのアルゴリズムは不完全であることがわかった。 Rosenberg, et al. Standards Track [Page 4] RFC 5389 STUN October 2008 また、クラシックSTUNにはセキュリティの脆弱性があり、それは、あるトポ ロジーとある制約下で、攻撃者は不適当なマップドアドレスをクライアント に提供でき、そして、これはどんな暗号手段でも基本的に解決できなかっ た、というものである。この問題はこの仕様書で残っているが、それらの攻 撃は、現在、STUNを利用するよりもより完全なソリューションの使用で軽減 される。 これらの理由により、この仕様書はRFC 3489を廃止して、代わりに完全なNAT 越えソリューションの一部として利用されるツールとしてSTUNを記述する。 ICE [MMUSIC-ICE]は、SIPなどのオファー/アンサー [RFC3264] 方法論に基づ くプロトコルの完全なNAT越えソリューションだ。SIP Outbound [SIP-OUTBOUND]は、SIPシグナリングのNAT越えの完全解で、そしてそれは非 常に変わった方法でSTUNを使用する。プロトコル自体がNAT越えソリューショ ンとしてSTUN(クラシックSTUN)を使用することは可能だが、そのような用法 がここで説明されていなく、上で説明された理由で強く止めさせようとして いる。 ここで説明された一連のネットワークプロトコル(on-the-wire protocol) は、クラシックSTUNから少しだけ変えられている。プロトコルはも今ではUDP に加えてTCP上でも走る。拡張性はさらに構造化された方法でプロトコルに追 加された。STUNをアプリケーションプロトコルと逆多重化するためのマジッ ククッキー機構は、変更が後方互換性を与えるように、RFC 3489で定義され た128ビットトランザクションIDから32ビット取ることで追加された。マップ ドアドレスは、新しい排他的論理和形式を使用してエンコードされる。その 他、多くのマイナーチェンジがある。より完全な一覧表は19章を参照のこ と。 適用範囲の変更のため、STUNもまた"Simple Traversal of UDP through NAT" から"Session Traversal Utilities for NAT"に改名された。頭字語は、誰も が覚えているSTUNのまま残っている。 3. 操作の概要 この章は記述のみである。 Rosenberg, et al. Standards Track [Page 5] RFC 5389 STUN October 2008 /-----\ // STUN \\ | サーバ | \\ // \-----/ +--------------+ パブリックインターネット ................| NAT 2 |....................... +--------------+ +--------------+ プライベートネット2 ................| NAT 1 |....................... +--------------+ /-----\ // STUN \\ | クライ | \\ アント// プライベートネット1 \-----/ 図1: STUNの構成の一例 STUNの構成の一例を図1に示す。この構成には、STUNプロトコルを実装する2 つの実体(STUNエージェントと呼ばれる)がある。図の下側のエージェントは クライアントであり、プライベートネットワーク1に接続される。このネット ワークは、NAT1を通ってプライベートネットワーク2に接続する。プライベー トネットワーク2は、NAT2を通ってパブリックインターネットに接続する。図 の上側のエージェントはサーバであり、パブリックインターネットに存在し ている。 STUNはクライアント/サーバプロトコルである。それは2タイプのトランザク ションをサポートする。一つ目は、クライアントがリクエストをサーバに送 り、そしてサーバがレスポンスを返すリクエスト/レスポンストランザクショ ンである。2つ目は、どちらかのエージェント(クライアントかサーバ)がレス ポンスを伴わない指示を送るための、インディケーショントランザクション である。両タイプのトランザクションはトランザクションIDを含んでいて、 それはランダムに選択された96ビットの数である。リクエスト/レスポンスト ランザクションについては、このトランザクションIDはそれを生成したリク Rosenberg, et al. Standards Track [Page 6] RFC 5389 STUN October 2008 エストとレスポンスをクライアントに関連づけさせることができ、インディ ケーションについては、トランザクションIDはデバッギングエイドとして機 能する。 すべてのSTUNメッセージはメソッド、クラス、およびトランザクションIDを 含む固定ヘッダーで始まる。メソッドはこれが様々なリクエストかインディ ケーションのどちらであるかを示す。この仕様書はBindingというただ1つの メソッドを定義していて、その他のメソッドは他の文書で定義されると期待 される。クラスは、これがリクエストか成功レスポンスかエラーレスポンス か、あるいはインディケーションであるかを示す。固定ヘッダーに続いてゼ ロもしくはそれ以上のアトリビュートが来て、そのアトリビュートは特定の メッセージの追加情報を伝える"タイプ-長さ-値"形式の拡張である。 このドキュメントはBindingと呼ばれるただ一つのメソッドを定義する。 Bindingグメソッドは、リクエスト/レスポンストランザクションかインディ ケーショントランザクションに使用できる。リクエスト/レスポンストランザ クションで使用すると、Bindingグメソッドは、NATがSTUNクライアントに割 り当てた特定の"バインディング"を判定するのに使用できる。リクエスト/レ スポンスかインディケーショントランザクションのいずれかで使用すると、 バインディングメソッドは、これらの"バインディング"を維持するのに使用 できる。 Bindingリクエスト/レスポンストランザクションでは、STUNクライアントか らSTUNサーバにBindingリクエストを送る。BindingリクエストがSTUNサーバ に到着するとき、それはSTUNクライアントとSTUNサーバの間の1つ、またはそ れ以上のNATsを通り抜けたかもしれない(図1には、そのような2つのNATsが あった)。BindingリクエストメッセージがNATを通り抜けるとき、NATはパ ケットの送信元トランスポートアドレス(すなわち、送信元IPアドレス/送信 元ポート)を変更するだろう。その結果、サーバで受信したリクエストの送信 元トランスポートアドレスは、サーバに最も近いNATによって作成されたパブ リックIPアドレス/ポートとなるだろう。これはリフレクシブトランスポート アドレスと呼ばれる。STUNサーバは、STUN Bindingレスポンス中のXOR- MAPPED-ADDRESSアトリビュートにその送信元トランスポートアドレスをコ ピーして、BindingレスポンスをSTUNクライアントに送り返す。このパケット がNATを通り抜けて戻るとき、NATはIPヘッダー中の宛先トランスポートアド レスを変更するだろうが、STUNレスポンスのボディーにあるXOR-MAPPED- ADDRESSアトリビュート中のトランスポートアドレスは触れないままで残るだ ろう。このように、STUNサーバに対して最も外側のNATによって割り当てられ たリフレクシブトランスポートアドレスを、クライアントは知ることができ る。 いくつかの用法では、STUNと他のプロトコル(例えば、[MMUSIC-ICE]、 [SIP-OUTBOUND])とを多重化しなければならない。これらの用法には、それが STUNパケットであるかどうかパケットを検閲して判定する方法を持たなけれ ばならない。STUNはこのために使用できる固定値をSTUNヘッダーの3つの フィールドに提供する。また、これが十分でないなら、STUNパケットは、さ らにパケットを区別するのに使用できるFINGERPRINT値を入れることができ る。 Rosenberg, et al. Standards Track [Page 7] RFC 5389 STUN October 2008 STUNは、用法が使うことを決めることができる、メカニズムと呼ばれるオプ ション手順一式を定義する。これらのメカニズムは、DNS探索、代替サーバへ のリダイレクションテクニック、逆多重化のためのフィンガープリントアト リビュート、そして2種類の認証、およびメッセージ完全性交換を含んでい る。認証メカニズムはユーザ名、パスワード、およびメッセージ完全性値の 使用を中心題目とする。2つの認証メカニズム(長期資格情報メカニズムと短 期資格情報メカニズム)が、この仕様書で定義されている。各用法はその用法 で許容されたメカニズムを規定する。 長期資格情報メカニズムでは、クライアントとサーバは事前に用意しておい たユーザ名とパスワードを共有して、HTTP [RFC2617]のために定義されたも のを参考にした、ダイジェスト値のチャレンジ/レスポンス交換を実行する (細部は異なる)。短期資格情報メカニズムでは、クライアントとサーバは STUN交換の前に、何らかの別経路でユーザ名とパスワードを交換する。例え ば、ICE用法 [MMUSIC-ICE]で、2つのエンドポイントが、ユーザ名とパスワー ドを交換するのに別経路のシグナリングを使用する。これらは完全性の保護 に使用され、リクエストとレスポンスを認証する。どんなチャレンジやナン スも使わない。 4. 用語 この文書に出てくるキーワード "しなければならない(MUST)", "してはなら ない(MUST NOT)", "要求されている(REQUIRED)", "することになる (SHALL)", "することはない(SHALL NOT)", "する必要がある(SHOULD)", "しないほうがよい(SHOULD NOT)", "推奨される(RECOMMENDED)", "してもよ い(MAY)", と"選択できる(OPTIONAL)" は、BCP 14、 RFC 2119 [RFC 2119]に 記述されている様に解釈され、STUN準拠の実装のための要件レベルを示す。 5. 定義 STUNエージェント: STUNエージェントはSTUNプロトコルを実装する実体であ る。実体は、STUNクライアントかSTUNサーバのいずれかである。 STUNクライアント: STUNクライアントは、STUNリクエストを送信して、STUN レスポンスを受信する、実体である。また、STUNクライアントはインディ ケーションを送信することが出来る。この仕様書では、STUNクライアント とクライアントという用語は同義である。 STUNサーバ: STUNサーバは、STUNリクエストを受信して、STUNレスポンスを 送信する、実体である。また、STUNサーバはインディケーションを送信す ることが出来る。この仕様書では、STUNサーバとサーバという用語は同義 である。 トランスポートアドレス: IPアドレスと(UDPやTCPポート番号などの)ポート 番号の組み合わせ。 Rosenberg, et al. Standards Track [Page 8] RFC 5389 STUN October 2008 リフレクシブトランスポートアドレス: トランスポートアドレスは、IPネッ トワーク上の別のホスト(一般にSTUNサーバ)によって見えるそのクライア ントを特定するものとして、クライアントが知っているものである。クラ イアントと他のホストの間に介在しているNATがあるとき、リフレクシブ トランスポートアドレスは、そのクライアントに割り当てられた、NATの パブリック側のマップドアドレスを表す。リフレクシブトランスポートア ドレスは、STUNレスポンス内のマップドアドレスアトリビュート(MAPPED- ADDRESSまたはXOR-MAPPED-ADDRESS)から知ることが出来る。 マップドアドレス: リフレクシブアドレスと同義。この用語は、歴史的な理 由と、MAPPED-ADDRESSとXOR-MAPPED-ADDRESSアトリビュートの命名のため だけに残されている。 長期資格情報: クライアントとサーバ間の共有秘密鍵を表しているユーザ名 と関連したパスワードのこと。長期資格情報は、利用者がサービスに登録 するとき、一般にクライアントに与えられて、加入者がサービスを去る か、または明らかに資格情報を変更するまで存続する。 長期パスワード: 長期資格情報によるパスワードのこと。 短期資格情報: クライアントとサーバ間の共有秘密鍵を表している一時的な ユーザ名と関連したパスワードのこと。短期資格情報は、STUN交換に先行 して、クライアントとサーバ間のある種のプロトコルメカニズムを通して 得られる。短期資格情報には明示的な時間的範囲があり、それは特定の時 間(5分など)やイベント(SIPダイアログの終了など)に基づいてもよい。短 期資格情報の具体的な範囲はアプリケーション用法で定義される。 短期パスワード: 短期資格情報のパスワード構成要素のこと。 STUNインディケーション: レスポンスを受けないSTUNメッセージのこと。 アトリビュート: STUNメッセージに追加できる、タイプ-長さ-値(TLV)型オ ブジェクトのSTUN用語。アトリビュートは次の2つのタイプに分けられ る。理解必須と理解任意である。STUNエージェントは、それらが知らない 理解任意のアトリビュートを安全に無視できるが、知らない理解必須なア トリビュートが入っているとうまくメッセージを処理できない。 RTO: 再送タイムアウト値のことで、それはリクエストの送信とそのリクエ ストの最初の再送との初期間隔と定義する。 Rosenberg, et al. Standards Track [Page 9] RFC 5389 STUN October 2008 6. STUNメッセージ構造 STUNメッセージは、ネットワーク指向形式(最上位バイト/オクテットが先、 また、ビッグエンディアンとして一般的に知られている)を使用してバイナリ でエンコードされる。送信順はRFC 791 [RFC0791]の付録Bで詳細に説明され る。特に断らない限り、数値定数は十進数(底は10)である。 すべてのSTUNメッセージは、0個もしくはそれ以上のアトリビュートを伴う20 バイトのヘッダーで始まらなければならない(MUST)。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メッセージタイプ | メッセージ長 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マジッククッキー | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | トランザクションID (96ビット) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図2: STUNメッセージヘッダの書式 すべてのSTUNメッセージの最上位2ビットは0でなければならない(MUST)。 STUNが同じポート上に他のプロトコルを多重化するとき、他のプロトコルと STUNパケットを区別するのにこれを使用できる。 メッセージタイプは、メッセージクラス(リクエスト、成功レスポンス、失敗 レスポンス、あるいはインディケーション)とSTUNメッセージのメッセージメ ソッド(主機能)を定義する。4つのメッセージのクラスがあるけれども、STUN には次の2タイプのトランザクションしかない。リクエスト/レスポンストラ ンザクション(それはリクエストメッセージとレスポンスメッセージからな る)とインディケーショントランザクション(それはただひとつのインディ ケーションメッセージからなる)である。レスポンスクラスは、STUNメッセー ジをすぐに処理するのを補助するためにエラーと成功のレスポンスに分けら れる。 Rosenberg, et al. Standards Track [Page 10] RFC 5389 STUN October 2008 メッセージタイプフィールドは、さらに以下の構造に分解される: 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| +--+--+-+-+-+-+-+-+-+-+-+-+-+-+ 図3: STUNメッセージタイプフィールドの書式 ここに、メッセージタイプフィールドのビットを最上位(M11)から最下位(M0) として示す。M11からM0は、12ビットにエンコードしたメソッドを表す。C1と C0は、2ビットにエンコードしたクラスを表す。クラス0b00はリクエスト、ク ラス0b01はインディケーション、クラス0b10は成功レスポンス、そしてクラ ス0b11はエラーレスポンスである。この仕様書はただひとつのメソッド、 Bindingを定義する。メソッドとクラスは独立していて、それぞれのメソッド について、リクエスト、成功レスポンス、エラーレスポンス、およびイン ディケーションがそのメソッドに使用可能である。新しいメソッドを定義す る拡張は、どのクラスがそのメソッドに受入れられるかを示さなければなら ない(MUST)。 例えば、Bindingリクエストは、クラス=0b00 (リクエスト)とメソッド= 0b000000000001 (Binding)を取り、0x0001として最初の16ビットにエンコー ドされる。Bindingレスポンスは、クラス=0b10 (成功レスポンス)とメソッド =0b000000000001を取り、0x0101として最初の16ビットにエンコードされる。 注記: この残念なエンコーディングは、ビットフィールドを使用して、イ ンディケーション、成功、およびエラーをエンコードすると考えなかった [RFC3489]の値割り当ての結果である。 マジッククッキーフィールドはネットワークバイトオーダーで固定値 0x2112A442が入っていなければならない(MUST)。RFC 3489 [RFC3489]で、こ のフィールドはトランザクションIDの一部だった。マジッククッキーをこの 位置に置くことで、クライアントがこの改訂した仕様書で追加されたあるア トリビュートを理解出来るかどうかをサーバが検知できるようになる。さら に、それは同じポート上で他のプロトコルとSTUNとを多重化するとき、他の プロトコルのパケットとSTUNパケットを区別する際の助けとなる。 トランザクションIDは96ビットの識別子で、STUNトランザクションをユニー クに特定するのに使用される。リクエスト/レスポンストランザクションにお いて、トランザクションIDは、STUNクライアントによってリクエスト用に選 ばれ、レスポンスでサーバによって反復される。インディケーションにおい ては、それはインディケーションを送信するエージェントによって選ばれ る。それは、リクエストとレスポンスを関連させるのに主として役立ち、ま た、ある種の攻撃防止を助ける際に脇役を演ずる。また、サーバは、すべて Rosenberg, et al. Standards Track [Page 11] RFC 5389 STUN October 2008 のクライアント中でそれぞれのトランザクションをユニークに特定するキー としてトランザクションIDを使用する。そのため、トランザクションIDは、 0〜2**96-1から一様でかつランダムに選ばれなければならなく(MUST)、そし て暗号学的にランダムである必要がある(SHOULD)。同じリクエストの再送に は同じトランザクションIDを再使用するが、新しいリクエストが前のリクエ ストとビット単位で同一で、同一トランスポートアドレスから同一IPアドレ スへ送信する場合を除いて、クライアントは新しいトランザクションのため に新しいトランザクションIDを選ばなければならない(MUST)。成功/エラーレ スポンスは、それらに 対応するリクエストと同じトランザクションIDを持 ち歩かなければならない(MUST)。エージェントが同一ポートでSTUNサーバか つSTUNクライアントとして振る舞っているとき、エージェントによって送信 されたリクエストのトランザクションIDは、エージェントによって受信され たリクエストのトランザクションIDとは全く関係が無い。 メッセージ長は、20バイトのSTUNヘッダーを含まないメッセージの、バイト で表現されるサイズが入っていなければならない(MUST)。すべてのSTUNアト リビュートが4バイトの倍数にパディングされるので、いつもこのフィールド の最後の2ビットは0である。これは他のプロトコルのパケットとSTUNパケッ トを区別する別の方法と規定する。 ヘッダーの固定長部に続くものは、0個もしくはそれ以上のアトリビュートで ある。各アトリビュートはTLV(タイプ-長さ-値)でエンコードされる。エン コーディングの詳細およびアトリビュート自体の詳細は15章に譲る。 7. 基本プロトコル手順 この章はSTUNプロトコルの基本手順を定義する。どのようにメッセージを形 成するか、そしてどのようにそれらを送信するか、そしてそれらが受信され たときどのようにそれらを処理されるかを説明する。また、Bindingメソッド の詳細な処理を定義する。この文書の他の章では、用法がある状況で用いる ことを選んでもよいオプション手順について説明する。他の文書では、新し いメソッド、新しいアトリビュート、または新しいエラーレスポンスコード を追加することによって、STUNの他の拡張を定義してもよい。 7.1. リクエストまたはインディケーションの形成 リクエストまたはインディケーションメッセージを組み立てる場合、エー ジェントはヘッダーを作成するときに6章のルールを守らなければならない (MUST)。さらに、メッセージクラスは"リクエスト"か"インディケーション" のどちらか(適宜)でなければならなく(MUST)、かつBindingか他の文書で定義 された何らかのメソッドのいずれかでなければならない。 そして、エージェントは、メソッドや用法で規定されたいくらかアトリ ビュートを追加する。例えば、ある用法は、エージェントが認証方法(10章) やFINGERPRINTアトリビュート(8章)を使用すると規定してもよい。 Rosenberg, et al. Standards Track [Page 12] RFC 5389 STUN October 2008 エージェントがリクエストを送信しているなら、リクエストにSOFTWAREアト リビュートを追加する必要がある(SHOULD)。メソッドによっては、エージェ ントはインディケーションにSOFTWAREアトリビュートを入れてもよい(MAY)。 STUNへの拡張は、SOFTWAREが新しいインディケーションで役に立つかどうか 議論する必要がある。 認証のないBindingメソッドにおいて、用法が別段規定しない限り、アトリ ビュートは全く必要ではない。 UDP上で送信されるすべてのSTUNメッセージは(分かっているならば)パスMTU 以下である必要がある(SHOULD)。パスMTUが未知であるなら、メッセージは、 576バイトと、IPv4なら最初のホップのMTU [RFC1122]と、IPv6なら1280バイ ト [RFC2460]のうち、より小さいものである必要がある(SHOULD)。この値は IPパケットの全体のサイズに該当する。その結果、IPv4で実際のSTUNメッ セージは548バイト(IPオプションが全く使用されないと仮定して、576 - 20 バイトのIPヘッダー - 8バイトのUDPヘッダー)以下である必要があるだろ う。STUNは、リクトエスがMTU以下だが、レスポンスがMTUより大きい場合を 扱う能力を全く提供しない。この制限はSTUNの問題であると想定していな い。MTUの制限は、STUN自身がMTUの特性を調べるのに使用される場合 [BEHAVE-NAT]を出来なくしてしまうため、"でなければならない(SHOULD)"で はなく"である必要がある(MUST)"である。このアプリケーションか同様のア プリケーション以外のところで、MTUの制約について議論しなければならな い(MUST)。 7.2. リクエストまたはインディケーションの送信 それから、エージェントはリクエストかインディケーションを送信する。こ の文書はUDP、TCP、またはTLS-over-TCP上でSTUNメッセージを送信する方法 を規定する(他のトランスポートプロトコルが将来追加されるかもしれな い)。STUN用法は、どのトランスポートプロトコルが使用されるか、そして エージェントが受取者のIPアドレス/ポートをどのように判定するかを規定し なければならない。9章では、用法が使用するために選んでもよいサーバのIP アドレス/ポートを決定するDNSベースのメソッドについて説明する。UDPで、 かつ認証が使用されていない用法でのみ、STUNをエニーキャストアドレスで 使用してもよい。 いかなる時も、クライアントは同じSTUNサーバで複数の未処理STUNリクエス トを持っていてもよい(MAY)(それは異なったトランザクションIDの処理中の 多数のトランザクションである)。新しいトランザクションの割合を制限する もの(接続性チェックのためにICEで規定されたトランザクションや、STUNが TCP上で実行されるときなど)がないなら、クライアントは一つのサーバへの 新しいトランザクションをRTOに間隔を空ける必要があり(SHOULD)、かつ同じ サーバへは10個の未処理トランザクションにクライアント自身を制限する必 要がある(SHOULD)。 7.2.1. UDP上での送信 UDP上でSTUNを実行するとき、STUNメッセージがネットワークで破棄されるこ とが起こりうる。STUNリクエスト/レスポンストランザクションの信頼性は、 Rosenberg, et al. Standards Track [Page 13] RFC 5389 STUN October 2008 クライアントアプリケーション自身でリクエストメッセージを再送すること によって達成される。STUNインディケーションは再送されない。したがっ て、UDP上のインディケーショントランザクションは信頼性がない。 RTO("再送タイムアウト")の間隔から始めて、各再送信の後に2倍にして、ク ライアントはSTUNリクエストメッセージを再送する必要がある(SHOULD)。RTO は往復時間(RTT)の推定値であり、2つの例外はあるが、RFC 2988 [RFC2988] に記述されるように計算される。まず最初に、RTOの初期値は(RFC 2988で推 奨している3秒間よりむしろ)構成可能である必要があり(SHOULD)、かつ500ms 以上である必要がある(SHOULD)。この"である必要がある(SHOULD)"の例外 ケースは、他のメカニズムが(ICEで固定レートストリームのために定義され たものなどの)輻輳閾値を得るのに使用されるとき、またはSTUNをネットワー ク容量が既知の非インターネット環境で使用するときである。固定回線アク セスリンクでは、500ms値が推奨される(RECOMMENDED)。二つ目に、RTO値を最 も近い秒数に四捨五入しないほうがよい(SHOULD NOT)。むしろ、1msの精度は 維持する必要がある(SHOULD)。TCPのように、Karnのアルゴリズムの使い方が 推奨される(RECOMMENDED) [KARN87]。STUNに適用されるとき、RTT推定値はリ クエストの再送をもたらすSTUNトランザクションから計算されないほうがよ い(SHOULD NOT)ことを意味する。 RTOのための値は、トランザクション完了後にクライアントでキャッシュされ て、(IPアドレスの同一に基づいて)同じサーバへの次のトランザクションの ためのRTO開始値として使用される必要がある(SHOULD)。その値は、10分後に は無効とみなされ捨てられる必要がある(SHOULD)。 レスポンスを受信するまで、またはRc回のリクエストのすべてが送信される まで、再送を続ける。Rcは構成可能である必要があり(SHOULD)、デフォルト を7とする必要がある(SHOULD)。最後のリクエストの後、つまりRm×RTOに等 しい期間が(もしこの最後のリクエストだけが実際に成功するとして、レスポ ンス受け取る十分な時間を提供して)レスポンスなしで過ぎたら、クライアン トは、トランザクションが失敗したとみなす必要がある(SHOULD)。Rmは構成 可能である必要があり(SHOULD)、デフォルトを16とする必要がある (SHOULD)。また、ハードICMPエラー [RFC1122]があったなら、UDP上のSTUNト ランザクションは失敗したとみなされる。例えば、500msのRTOを仮定する場 合、リクエストは0ms、500ms、1500ms、3500ms、7500ms、15500ms、および 31500msで送信されるだろう。クライアントが39500ms後にレスポンスを受信 していないならば、クライアントはトランザクションがタイムアウトしたと みなすだろう。 7.2.2. TCPやTLS-over-TCP上での送信 TCPとTLS-over-TCPに関しては、クライアントはサーバにTCP接続を開く。 Rosenberg, et al. Standards Track [Page 14] RFC 5389 STUN October 2008 STUNのいくつかの用法で、STUNはTCP接続上のプロトコルだけで送信される。 この場合、どんな追加フレーム化や逆多重化の手助けなしでそれを送信する ことができる。他の用法や他の拡張とでは、TCP接続上で他のデータと多重化 されるかもしれない。その場合、エージェントが完全なSTUNメッセージと完 全なアプリケーション層メッセージを抽出出来るようにする用法か拡張で規 定されたある種のフレーム化プロトコル上でSTUNを実行しなければならな い(MUST)。9章のDNS手順で検出されたウェルノウンポートかポート群で動く STUNサービスは、STUN単独用で、他のデータと多重化されたSTUN用ではな い。従って、フレーム化プロトコルはそれらのサーバへの接続に全く使用さ れない。追加フレーム化を利用するとき、クライアントがそれを適用するこ とをどのように知るか、そして何のポートに接続するかを、用法が規定する だろう。例えば、ICE接続性チェックの場合では、この情報はクライアントと サーバ間の別経路のネゴシエーションを通して知らされる。 STUNがTLS-over-TCP上のそれ自身で実行されるとき、最低限、 TLS_RSA_WITH_AES_128_CBC_SHA暗号スイートを実装しなければならない (MUST)。また、実装はどんな他の暗号スイートもサポートしてもよい(MAY)。 TLS Certificateメッセージを受信するとき、クライアントはその証明書を検 証して、証明書によって特定されたサイトを検査する必要がある(SHOULD)。 証明書が無効か失効しているか、適切な関係者を特定しないなら、クライア ントはSTUNメッセージを送ってはならないか、あるいはSTUNトランザクショ ンを続けてはならない(MUST NOT)。クライアントはサーバの身元を検証しな ければならない(MUST)。それをするために、RFC 2818 [RFC2818]の3.1節で定 義された身元証明手順に従う。それらの手順は、クライアントがURIを逆参照 していると仮定する。この仕様書の用法の目的のために、クライアントは逆 参照されたURIのホスト部として8.1節で使用されたドメイン名またはIPアド レスを扱う。あるいは、クライアントは信頼された一式のドメイン群または IPアドレス群によって構成されてもよい(MAY)。証明書がそれらのドメイン群 またはIPアドレス群のうちの一つを特定して受信されるなら、クライアント はサーバの身元が検証されたとみなす。 STUNがTLS-over-TCP上で他のプロトコルと多重化されて実行されるとき、必 須の暗号スイートとTLS取扱手順はそれらのプロトコルによって定義されたよ うに作動する。 TCPとTLS-over-TCP上のSTUNの信頼性はTCP自身によって扱われ、STUNプロト コルレベルで再送は全く無い。しかしながら、リクエスト/レスポンストラン ザクションに関して、接続を確立するためにSYNを送った後にクライアントが Ti秒でレスポンスを受信しなかったなら、トランザクションがタイムアウト したとみなす。Tiは構成可能である必要があり(SHOULD)、39.5秒のデフォル トを取る必要がある(SHOULD)。この値は、デフォルトの初期RTOでTCPとUDPの タイムアウトを等しくするように選ばれた。 Rosenberg, et al. Standards Track [Page 15] RFC 5389 STUN October 2008 さらに、クライアントがTCP接続を確立できないか、TCP接続がリセットされ るかレスポンスが受信される前に失敗するなら、処理中のどんなリクエスト/ レスポンストランザクションは失敗したとみなされる。 クライアントは単一のTCP(または、TLS-over-TCP)接続上で多数のトランザク ションを送信してもよく(MAY)、しかも前のものへのレスポンスを受信する前 に、別のリクエストを送ってもよい(MAY)。クライアントは以下の事項まで接 続を開き続ける必要がある(SHOULD)。 o その接続上で送るSTUNリクエストかインディケーションがこれ以上なく、 かつ o STUNリクエストがその接続上で送信されたことを通じて知らされたどんな リソース(マップドアドレス(MAPPED-ADDRESSやXOR-MAPPED-ADDRESS)やリ レーされたアドレス [BEHAVE-TURN]など)も使用する計画が全くなく、か つ o そのポート上でその他のアプリケーションプロトコルを多重化しているな ら、そのアプリケーションを使用し終えていて、かつ o リモートピアでポートを知らされて使用しているなら、あるTCP NAT越え 技術(例えば、[MMUSIC-ICE-TCP])で要求されるような、そのリモートピア との通信を確立している。 サーバ端では、接続がタイムアウトした(例えばネットワークから切断するク ライアントのため)とサーバが判定するまで、サーバは接続を開けたままにし て、そしてクライアントに閉じさせる必要がある(SHOULD)。クライアントが 知ったバインディングは、接続が開いたままでいる間だけ、介在している NATsに有効なまま残るだろう。クライアントだけがバインディングをどれく らい長い間必要とするかを知っている。レスポンスを送信していない接続上 でリクエストを受信したら、サーバはその接続を閉じないほうがよい (SHOULD NOT)。サーバは、レスポンスを送信するためにクライアントに向 かって決して逆の接続を開いてはならない(MUST NOT)。サーバは高負荷状態 における接続管理の最良の方法に従う必要がある(SHOULD)。 7.3. STUNメッセージの受信 この節はSTUNメッセージの処理を規定する。ここで規定された処理はこの仕 様書で定義されるようなSTUNメッセージのためのものである。後方互換性の ための付則は12章で定義される。それらの追加手順はオプションであり、用 法はそれらを利用することを選ぶことができる。最初に、処理操作一式がク ラスに依存せずに適用される。これが、続く小節で説明されるクラス固有処 理に続いていく。 Rosenberg, et al. Standards Track [Page 16] RFC 5389 STUN October 2008 STUNエージェントがSTUNメッセージを受信するとき、最初にメッセージが6章 の規則に従うことをチェックする。先頭の2ビットが0であり、マジッククッ キーフィールドが正しい値を持ち、メッセージ長が実際のものであり、そし てメソッド値がサポートしているメソッドであることをチェックする。メッ セージクラスがそのメソッドに許されていることをチェックする。メッセー ジクラスが"成功レスポンス"もしくは"エラーレスポンス"であるなら、エー ジェントはトランザクションIDがまだ処理中であるトランザクションと合っ ているかをチェックする。FINGERPRINT拡張が使用されているなら、エージェ ントは、FINGERPRINTアトリビュートがあり、正しい値が入っていることを チェックする。何かエラーが検知されるなら、メッセージは黙って捨てられ る。STUNが別のプロトコルと多重化されている場合に、エラーが、これは実 際にはSTUNメッセージでないことを示すかもしれない。この場合、エージェ ントは異なるプロトコルとしてメッセージを分解してみる必要がある。 そして、STUNエージェントは用法が規定した認証機構で要求されるチェック をする(10章を参照)。 いったん認証チェックが終わると、STUNエージェントはメッセージ中の未知 のアトリビュートと既知だが期待されないアトリビュートをチェックする。 エージェントは未知の理解任意のアトリビュートを無視しなければならな い(MUST)。既知だが期待されないアトリビュートはエージェントによって無 視される必要がある(SHOULD)。未知の理解必須なアトリビュートはメッセー ジクラスに依存した処理と以下で説明される処理をさせる。 この点で、さらなる処理はリクエストのメッセージクラスに依存する。 7.3.1. リクエストの処理 リクエストが1つ以上の未知の理解必須なアトリビュートを含んでいるなら、 サーバは420のエラーコード(未知のアトリビュート)のエラーレスポンスで返 答して、その未知の理解必須なアトリビュートをリストアップしたUNKNOWN- ATTRIBUTESアトリビュートをレスポンスに含める。 そして、サーバはメソッドか特定の用法が要求するいくつかの追加チェック をする。すべてのチェックが成功するなら、サーバは以下で説明されるよう に成功レスポンスを組み立てる。 UDP上で実行するとき、サーバによって受信されたリクエストは、トランザク ションの最初のリクエストまたは再送だろう。サーバは、以下の特性が維持 されるように再送に応答しなければならない(MUST)。クライアントが、元の リクエストに対して送信されたレスポンスではなく、再送へのレスポンスを 受信するなら、クライアントとサーバ上の全体の状態は、元の再送へのレス ポンスだけがが受信されているか、または(クライアントが最初に着いたもの を使用するだろうという立場で)両方のレスポンスが受信されている場合と同 Rosenberg, et al. Standards Track [Page 17] RFC 5389 STUN October 2008 じである。この要件を満たす最も簡単な方法は、サーバがUDP上で受信したす べてのトランザクションIDと、それらの対応する直近40秒のレスポンスを覚 えていることだ。しかしながら、これは、サーバが状態を保持することを要 求して、認証されていないリクエストについては不適当になるだろう。別の 方法は、リクエストを再処理することとレスポンスを再計算することだ。冪 等(システムの全体の状態に影響を与えないで、同じリクエストを無事に繰り 返すことが出来るとき、リクエストは冪等であるとみなされる)であるリクエ ストと、同じリクエストに対する同じ成功レスポンスの結果とに、後者のテ クニックだけを適用しなければならない(MUST)。Bindingメソッドは冪等であ るとみなされる。リフレクシブトランスポートアドレス値に変化を引き起こ す、つまり異なる成功レスポンスで異なるマップドアドレスの結果となる、 あるまれなネットワーク事象があることに注意すること。STUNへの拡張で は、トランザクション状態を保存しないサーバでリクエスト再送の密接な関 係について議論しなければならない(MUST)。 7.3.1.1. 成功またはエラーレスポンスの形成 レスポンス(成功またはエラー)を形成するとき、サーバは6章の規則に従う。 レスポンスのメソッドはリクエストのものと同じであり、メッセージクラス は"成功レスポンス"か"エラーレスポンス"のどちらかである。 エラーレスポンスにおいて、サーバは上記処理を明細に記されたエラーコー ドが入っているERROR-CODEアトリビュートを追加しなければならない (MUST)。理由句は決められていないが、エラーコードは適切なものである必 要がある(SHOULD)。あるエラーにおいて、追加アトリビュートがメッセージ に追加される。これらのアトリビュートは、エラーコードが明記されるとこ ろの記述で詳細に説明される。例えば、420(未知のアトリビュート)のエラー コードで、サーバはUNKNOWN-ATTRIBUTESアトリビュートを含まなければなら ない(MUST)。また、ある認証エラーではアトリビュートが追加される(10章を 参照)。拡張は、その他のエラーまたはエラーケースに追加する追加アトリ ビュート、あるいはその両方を定義してもよい。 サーバが認証機構を使用するリクエストを認証するなら、サーバは適 切な認証アトリビュートをレスポンスに追加する必要がある(SHOULD)(10章を 参照)。 また、サーバは特定のメソッドや用法で要求されるどんなアトリビュートで も追加する。さらに、サーバはSOFTWAREアトリビュートをメッセージに追加 する必要がある(SHOULD)。 Bindingメソッドにおいて、用法が別段規定しない限り、どんな追加チェック も必要ではない。成功レスポンスを形成するとき、サーバはレスポンスに XOR-MAPPED-ADDRESSアトリビュートを追加して、そのアトリビュートの内容 Rosenberg, et al. Standards Track [Page 18] RFC 5389 STUN October 2008 はリクエストメッセージの送信元トランスポートアドレスである。UDPにおい て、これはリクエストメッセージの送信元IPアドレスと送信元UDPポートであ る。TCPとTLS-over-TCPにおいて、これはサーバで見えるTCPコネクションの 送信元IPアドレスと送信元TCPポートである。 7.3.1.2. 成功またはエラーレスポンスの送信 レスポンス(成功もしくはエラー)は、リクエストを受信したのと同じトラン スポート上で送信される。UDP上でリクエストを受信したなら、レスポンスの 宛先IPアドレス/ポートは受信されたリクエストメッセージの送信元IPアドレ ス/ポートであり、レスポンスの送信元IPアドレス/ポートは受信されたリク エストメッセージの宛先IPアドレス/ポートと等しい。TCPまたは TLS-over-TCP上でリクエストを受信したなら、レスポンスはリクエストを受 信したのと同じTCP接続で返送される。 7.3.2. インディケーションの処理 インディケーションが未知の理解必須なアトリビュートを含んでいるなら、 インディケーションは捨てられ処理は終わる。 そして、エージェントはメソッドや特定の用法が要求する追加チェックを行 う。すべてのチェックが成功するなら、エージェントはインディケーション を処理する。レスポンスはインディケーションに対しては生成されない。 Bindingメソッドにおいて、用法が別段規定しない限り、どんな追加チェック も処理も必要ない。エージェントによるメッセージの単なる受信は、介在し ているNATsの"バインディング"をリフレッシュしてしまう。 (リクエストと異なり)UDP上ではインディケーションを再送しないので、送信 エージェントでインディケーションの再送を扱う必要は全くない。 7.3.3. 成功レスポンスの処理 成功レスポンスが未知の理解必須なアトリビュートを含んでいるなら、レス ポンスは捨てられトランザクションは失敗したとみなされる。 そして、クライアントはメソッドや特定の用法が要求する追加チェックを行 う。すべてのチェックが成功するなら、クライアントは成功レスポンスを処 理する。 Bindingメソッドにおいて、クライアントは、XOR-MAPPED-ADDRESSアトリ ビュートがレスポンスに存在していることをチェックする。クライアントは 指定されたアドレスファミリーをチェックする。それがサポートされないア ドレスファミリーであるなら、アトリビュートは無視される必要がある Rosenberg, et al. Standards Track [Page 19] RFC 5389 STUN October 2008 (SHOULD)。それが予期しないがサポートしているアドレスファミリー(例え ば、BindingトランザクションはIPv4上で送信されたが、指定されたアドレス ファミリーはIPv6である)であるなら、クライアントは受け入れて、値を使用 してもよい(MAY)。 7.3.4. エラーレスポンスの処理 エラーレスポンスが未知の理解必須なアトリビュートを含んでいるか、もし くはエラーレスポンスがERROR-CODEアトリビュートを含んでいないなら、ト ランザクションは単に失敗したとみなされる。 そして、クライアントは認証機構(10章を参照)によって規定されたすべての 処理を行う。これは新規トランザクション試行をもたらすかもしれない。 この時点での処理は、エラーコード、メソッド、および用法に依存する。以 下はデフォルトルールである。 o エラーコードが300から399であり、ALTERNATE-SERVER拡張子が使用されて いない場合、クライアントはトランザクション失敗とみなす必要がある (SHOULD)。11章を参照のこと。 o エラーコードが400から499であるなら、クライアントはトランザクション 失敗を示す。420(未知のアトリビュート)の場合、レスポンスは追加情報 を与えるUNKNOWN-ATTRIBUTESアトリビュートが入っている必要がある。 o エラーコードが500から599であるなら、クライアントはリクエストを再送 してもよい(MAY)。そうするクライアントはこれをする回数を制限しなけ ればならない(MUST)。 その他のエラーコードは、クライアントにトランザクション失敗とみなさせ る。 8. FINGERPRINTメカニズム この章は、同じトランスポートアドレスでSTUNメッセージと他のプロトコル のパケットが多重化されているときに、他のプロトコルのパケットからSTUN メッセージを区別する際の助けとなるSTUNのオプションメカニズムについて 説明する。このメカニズムはオプションであり、そしてSTUN用法がもしそれ を使用するときは記述しなければならない。FINGERPRINTメカニズムは、RFC 3489と後方互換性は無く、そのような互換性が要求される環境では使用でき ない。 いくつかの用法で、STUNメッセージが、リアルタイム転送プロトコル(RTP)な どの他のプロトコルと同じトランスポートアドレスで多重化される。7章で説 明された処理を適用するため、まず始めにアプリケーションパケットから Rosenberg, et al. Standards Track [Page 20] RFC 5389 STUN October 2008 STUNメッセージを切り離さなければならない。6章ではこのために使用できる STUNヘッダーの3つの固定フィールドについて説明する。しかしながら、いく つかの場合、これらの3つの固定フィールドでは十分でないかもしれない。 FINGERPRINT拡張が使用されているとき、エージェントは別のエージェントに 送信するメッセージにFINGERPRINTアトリビュートを入れる。15.5節はこのア トリビュートの配置と値について記述する。エージェントがSTUNメッセージ だと思うものを受信するとき、他の基本チェックに加え、さらに、エージェ ントは、メッセージがFINGERPRINTアトリビュートを含んでいることと、アト リビュートが正しい値を含んでいるかもチェックする。7.3節は、STUNメッ セージの総合的な処理中で、FINGERPRINTチェックがいつ実行されるかを記述 する。この追加チェックは、エージェントがSTUNメッセージであるように思 えるかもしれない他のプロトコルのメッセージをその他の点で検知するのを 助ける。 9. サーバのDNS探索 この章は、クライアントにサーバのIPアドレス/ポートを決定するのにDNSを 使用させるSTUNのオプション手順について記述する。STUN用法がもしこの拡 張を使用するときは記述しなければならない。この手順を用いるために、ク ライアントはサーバのドメイン名とサービス名を知らなければならない。ま た、用法はクライアントがどのようにこれらを得るかを記述しなければなら ない。ソフトウェア内にサーバのドメイン名をハードコーディングすること は、ドメイン名が無くなったり法的や他の理由で変更する必要がある場合の 用心のため、推奨されない(NOT RECOMMENDED)。 クライアントがBindingリクエスト/レスポンストランザクションを受け入れ るパブリックインターネットにあるSTUNサーバの場所を見つけたいとき、SRV サービス名は"stun"である。TLSセッション上でBindingリクエスト/レスポン ストランザクションを受け入れるSTUNサーバの場所を見つけたいとき、SRV サービス名は"stuns"である。STUN用法は追加のDNS SRVサービス名を定義し てもよい(MAY)。 ドメイン名は、[RFC2782]で規定されたSRV手順を用いることでトランスポー トアドレスに解決される。DNS SRVサービス名はこの手順へ入力として提供さ れるサービス名である。SRVルックアップのプロトコルは、クライアントが STUNを実行するトランスポートプロトコルである。つまり、UDPの場合には "udp"、TCPの場合には"tcp"。このとき"tcp"だけ"stuns"が定義されるのに注 意すること。 コンタクトをとるサーバを決定するために、RFC 2782の手順に従う。RFC 2782は、SRVレコード一式がどう分類されて、そしてどう試みられるかの詳細 を説明する。しかしながら、RFC 2782は、失敗の事象で起ることの詳細も述 べずに、クライアントが"その(プロトコル, アドレス, サービス)に接続しよ うとする"必要があると述べるだけである。これらの手順に従うとき、レスポ ンスの受信無しにSTUNトランザクションがタイムアウトするなら、クライア ントはRFC 2782で定義された順で次のサーバにリクエストを再試行する必要 Rosenberg, et al. Standards Track [Page 21] RFC 5389 STUN October 2008 がある(SHOULD)。インディケーショントランザクションがどんなレスポンス もタイムアウトも生成しないので、リクエスト/レスポンストランザクション だけにそのような再試行が可能である。 STUNリクエストのデフォルトポートは、TCPとUDP共に3478である。 STUNサーバの管理者は、UDPとTCPのそれらのSRVレコードでこのポートを使用 する必要がある(SHOULD)。すべての場合で、DNSのポートはサーバがリスニン グしているものを反映しなければならない(MUST)。TLS上でSTUNのデフォルト ポートは5349である。サーバソフトウェアが、最初のメッセージがTLSかSTUN メッセージであるかどうか決定することをサポートするなら、サーバはTCP上 のSTUNと同じポートでTLS上のSTUNを実行できる。 SRVレコードが見つからなかったなら、クライアントはAまたはAAAAレコード でドメイン名のルックアップを実行する。結果は、STUN用法とは無関係に、 UDPまたはTCPを使用してデフォルトポートへコンタクトできるIPアドレスの リストになるだろう。TLSを要求する用法において、クライアントは、TLS上 のSTUNのデフォルトポートを使用してIPアドレスの1つに接続する。 10. 認証とメッセージ完全性メカニズム この章はクライアントとサーバが認証とメッセージ完全性を提供するのに使 用できるSTUNのための2つのメカニズムを定義する。これらの2つのメカニズ ムは短期資格情報メカニズムと長期資格情報メカニズムとして知られてい る。これらの2つのメカニズムはオプションであり、各用法はもしこれらのメ カニズムを使用する時は明示しなければならない。その結果、クライアント とサーバの両方が、(もしあるならば)用法が適用される知識に基づいて、ど のメカニズムに従ったらよいかが分かるだろう。例えば、ICEをサポートする パブリックインターネットにあるSTUNサーバは認証がないだろうが、接続性 チェックをサポートするエージェントのSTUNサーバ機能性では短期資格情報 を利用するだろう。3章でこれらの2つのメカニズムの概要を述べる。 各メカニズムは、7章で規定された処理を拡張して、そのメカニズムを使用す るのに必要とされる追加処理を規定する。追加処理は次の3つの異なる個所に 生じる。メッセージを形成するとき、基本チェックを実行した後すぐにメッ セージを受信するとき、エラーレスポンスの詳細な処理を行うとき、であ る。 10.1. 短期資格情報メカニズム 短期資格情報メカニズムは、STUNトランザクションより前に、クライアント とサーバがユーザ名とパスワードの形で資格情報を交換するのにある他のプ ロトコルを使用した、と仮定する。この資格情報は有効期限付きである。有 Rosenberg, et al. Standards Track [Page 22] RFC 5389 STUN October 2008 効期限は用法で定義される。例として、ICE用法 [MMUSIC-ICE]では、2つのエ ンドポイントがユーザ名とパスワードに同意するのに別経路のシグナリング を使用して、そしてこのユーザ名とパスワードはメディアセッションの期間 中に適用できる。 この資格情報は、各リクエストと多くのレスポンスのメッセージ完全性 チェックを形成するのに使用される。長期メカニズムにあるようなチャレン ジ/レスポンスは無い。その結果、リプレイは資格情報の有効期限による特徴 によって防止される。 10.1.1. リクエストまたはインディケーションの形成 リクエストまたはインディケーションメッセージに関して、エージェントは メッセージにUSERNAMEとMESSAGE-INTEGRITYアトリビュートを入れなければな らない(MUST)。MESSAGE-INTEGRITYアトリビュートのHMACは15.4節に記述され るように計算される。パスワードがリクエストあるいはインディケーション に決して含まれていないことに注意すること。 10.1.2. リクエストまたはインディケーションの受信 エージェントがメッセージの基本処理を行った後に、エージェントは以下に リストアップされたチェックを明示された順に実行する。 o メッセージがMESSAGE-INTEGRITYとUSERNAMEアトリビュートの両方を含ま ないなら、 * メッセージがリクエストならば、サーバはエラーレスポンスでリクエ ストを破棄しなければならない(MUST)。このレスポンスは400(不正な リクエスト)のエラーコードを使用しなければならない(MUST)。 * メッセージがインディケーションならば、エージェントはインディ ケーションを黙って捨てなければならない(MUST)。 o USERNAMEがサーバ内で現在有効なユーザ名値を含んでいないなら、 * メッセージがリクエストならば、サーバはエラーレスポンスでリクエ ストを破棄しなければならない(MUST)。このレスポンスは401(認証失 敗)のエラーコードを使用しなければならない(MUST)。 * メッセージがインディケーションならば、エージェントはインディ ケーションを黙って捨てなければならない(MUST)。 o ユーザ名に関連しているパスワードを使用して、15.4節に記述されるよう にメッセージ完全性のための値を計算せよ。演算結果がMESSAGE- INTEGRITYアトリビュートの内容と合わないなら、 Rosenberg, et al. Standards Track [Page 23] RFC 5389 STUN October 2008 * メッセージがリクエストならば、サーバはエラーレスポンスでリクエ ストを破棄しなければならない(MUST)。このレスポンスは401(認証失 敗)のエラーコードを使用しなければならない(MUST)。 * メッセージがインディケーションならば、エージェントはインディ ケーションを黙って捨てなければならない(MUST)。 これらのチェックが通るなら、エージェントはリクエストもしくはインディ ケーションを処理し続ける。サーバによって生成されたどんなレスポンス も、リクエストを認証するのに利用されたパスワードを使用して計算された MESSAGE-INTEGRITYアトリビュートを含まなければならない(MUST)。レスポン スはUSERNAMEアトリビュートを入れてはならない(MUST NOT)。 チェックのどれかが失敗するなら、サーバはエラーレスポンスにMESSAGE- INTEGRITYもしくはUSERNAMEアトリビュートを含めてはならない(MUST NOT)。 これは、これらの失敗の場合に、サーバがMESSAGE-INTEGRITYを計算するのに 必要な共有秘密鍵を決定できないからである。 10.1.3. レスポンスの受信 クライアントはレスポンス中のMESSAGE-INTEGRITYアトリビュートを探す。存 在しているなら、クライアントは15.4節で定義されるように、リクエストに 利用したのと同じパスワードを使用して、レスポンスに関してメッセージ完 全性を計算する。演算結果がMESSAGE-INTEGRITYアトリビュートの内容と合っ ているなら、レスポンスは認証されているとみなされる。値が合っていない かMESSAGE-INTEGRITYが欠落していたなら、それを決して受け取らなかったか のように、レスポンスを捨てなければならない(MUST)。これに当てはまるな らば、このことは再送が続くことを意味する。 10.2. 長期資格情報メカニズム 長期資格情報メカニズムは、クライアントとサーバ間で共有されるユーザ名 とパスワードの形の長期資格情報に依存する。資格情報は、それがユーザに 供給されて、ユーザがシステムの利用者でなくなるか、ユーザが変わるまで 有効なままで残っていると思われるので、長期的であるとみなされる。これ は、基本的にユーザに与えられた伝統的な"ログイン"ユーザ名とパスワード である。 これらのユーザ名とパスワードが長期間ずっと有効であるはずなので、リプ レイ防止がダイジェストチャレンジの形で提供される。このメカニズムで は、クライアントは初回、どんな資格情報やどんな完全性チェックも提示せ ずに、リクエストを送信する。サーバはこのリクエストを破棄して、レルム( ユーザ名とパスワードの選択でユーザまたはエージェントを案内するのに使 われる)とナンスをユーザに提供する。ナンスはリプレイ保護を提供する。そ れはクッキーであり、サーバで選択され、有効期間もしくはクッキーが有効 であるところからのクライアントであることを示すような方法でエンコード Rosenberg, et al. Standards Track [Page 24] RFC 5389 STUN October 2008 されたものである。クライアントはリクエストを再試行して、この時、ユー ザ名とレルムを含め、そしてサーバによって提供されたナンスを反復する。 また、クライアントは、ナンスを含むリクエスト全体のHMACを提供するメッ セージ完全性を含める。サーバはナンスを確認して、メッセージ完全性を チェックする。それらが合っているなら、リクエストは認証される。ナンス がもう有効でないなら、それは"無効"とみなされ、そしてサーバはリクエス トを破棄して、新しいナンスを提供する。 同じサーバへの後続リクエストでは、クライアントは前回使用したナンス、 ユーザ名、レルム、およびパスワードを再利用する。この方法で、破棄が新 しいナンスをクライアントに提供する場合には、ナンスがサーバで無効にな るまで、後続リクエストは破棄されない。 インディケーションは応答をとれないので、インディケーションを保護する のに長期資格情報メカニズムを使用できないことに注意すること。インディ ケーションを利用する用法は、短期資格情報を使用しなければならないか、 またはそれらのための認証とメッセージ完全性を省かなければならない。 長期資格情報メカニズムはオフライン辞書攻撃に影響されやすいので、配置 には推測するのが難しいパスワードを利用する必要がある(SHOULD)。資格情 報がユーザによって入力されるのではなく、デバイス準備中にクライアント デバイスに置かれる場合では、パスワードは少なくとも128ビットのランダム 性を持つ必要がある(SHOULD)。資格情報がユーザによって入力される場合で は、それらはパスワード構造周りで現時点での最良の方法をとる必要があ る。 10.2.1. リクエストの形成 リクエストを形成するときには2つのケースがある。最初のケースは、これは クライアントから(IPアドレスとポートで特定される)サーバへの最初のリク トエスである。2番目のケースは、クライアントが、前回のリクエスト/レス ポンストランザクションがいったん正常に完了した、後続リクエストの送信 することである。401または438エラーレスポンスの結果としてのリクエスト を形成することは10.2.3小節でカバーされていて、"後続リクエスト"を考慮 されないので、従って10.2.1.2少々節に記述された規則を利用しない。 10.2.1.1. 最初のリクエスト クライアントが、(9章のDNS手順が使われているならホスト名、使われていな いならIPアドレスで特定される)サーバとのリクエスト/レスポンストランザ クションを正常に完了していないなら、それはUSERNAME、MESSAGE- INTEGRITY、REALM、およびNONCEアトリビュートを省く必要がある(SHOULD)。 言い換えれば、認証もしくはメッセージ完全性が適用されないかのように、 一番最初のリクエストが送信される。 Rosenberg, et al. Standards Track [Page 25] RFC 5389 STUN October 2008 10.2.1.2. 後続リクエスト いったんリクエスト/レスポンストランザクションが正常に完了すると、クラ イアントはサーバによってレルムとナンスを提示されていて、ユーザ名とパ スワードにクライアントが認証したものを選択しているだろう。クライアン トはサーバとの後続通信のためにユーザ名、パスワード、レルム、およびナ ンスをキャッシュする必要がある(SHOULD)。クライアントが後続リクエスト を送信するとき、USERNAME、REALM、およびNONCEアトリビュートをそれらの キャッシュされた値で含める必要がある(SHOULD)。そこには、キャッシュさ れたパスワードを使用している15.4節に記述されるように計算された MESSAGE-INTEGRITYアトリビュートを含める必要がある(SHOULD)。 10.2.2. リクエストの受信 サーバがリクエストの基本処理を行った後に、以下にリストアップされた チェックを明示された順に実行する。 o メッセージがMESSAGE-INTEGRITYアトリビュートを含んでいないなら、 サーバは401(認証失敗)のエラーコードでエラーレスポンスを生成しなけ ればならない(MUST)。このレスポンスはREALM値を含まなければならない (MUST)。REALM値はSTUNサーバの提供者のドメイン名とすることが推奨さ れる(RECOMMENDED)。レスポンスはサーバによって選択されたNONCEを含ま なければならない(MUST)。レスポンスはUSERNAMEまたはMESSAGE- INTEGRITYアトリビュートが入っていないほうがよい(SHOULD NOT)。 o メッセージがMESSAGE-INTEGRITYアトリビュートを含んでいるが、 USERNAME、REALM、またはNONCEアトリビュートが見つからないなら、サー バは400(不正なリクエスト)のエラーコードでエラーレスポンスを生成し なければならない(MUST)。このレスポンスはUSERNAME、NONCE、REALM、ま たはMESSAGE-INTEGRITYアトリビュートを含まないほうがよい(SHOULD NOT)。 o NONCEがもはや有効でないなら、サーバは438(無効なナンス)のエラーコー ドでエラーレスポンスを生成しなければならない(MUST)。このレスポンス は、NONCEとREALMアトリビュートを含まなければならなくて(MUST)、 USERNAMEまたはMESSAGE-INTEGRITYアトリビュートは含まないほうがよい (SHOULD NOT)。サーバは、追加セキュリティを提供するためにナンスを無 効にすることができる。ガイドラインに関して[RFC2617]の4.3節を参照の こと。 o USERNAMEアトリビュートにおけるユーザ名が有効でないなら、サーバは 401(認証失敗)のエラーコードでエラーレスポンスを生成しなければなら ない(MUST)。このレスポンスはREALM値を含まなければならない(MUST)。 REALM値はSTUNサーバの提供者のドメイン名とすることが推奨される (RECOMMENDED)。レスポンスはサーバによって選択されたNONCEを含まなけ ればならない(MUST)。レスポンスはUSERNAMEまたはMESSAGE-INTEGRITYア トリビュートが入っていないほうがよい(SHOULD NOT)。 Rosenberg, et al. Standards Track [Page 26] RFC 5389 STUN October 2008 o USERNAMEアトリビュート中のユーザ名に関連しているパスワードを使用し て、15.4節に記述されるようにメッセージ完全性の値を計算せよ。演算結 果がMESSAGE-INTEGRITYアトリビュートの内容に合っていないなら、サー バはエラーレスポンスでリクエストを破棄しなければならない(MUST)。こ のレスポンスは401(認証失敗)のエラーコードを使用しなければならない (MUST)。それは、REALMとNONCEアトリビュートを含まなければならなくて (MUST)、USERNAME、またはMESSAGE-INTEGRITYアトリビュートは含まない ほうがよい(SHOULD NOT)。 これらのチェックが通るなら、サーバはリクエストを処理し続ける。サーバ によって生成されたどんなレスポンス(上に記述されたケースを除く)も、リ クエストを認証するのに利用されたユーザ名とパスワードを使用して計算さ れたMESSAGE-INTEGRITYアトリビュートを含まなければならない(MUST)。 REALM、NONCE、およびUSERNAMEアトリビュートは含めないほうがよい (SHOULD NOT)。 10.2.3. レスポンスの受信 レスポンスが401(認証失敗)のエラーコードのエラーレスポンスであるなら、 クライアントは新しいトランザクションでリクエストを再試行する必要があ る(SHOULD)。このリクエストは、REALMのための適切なユーザ名としてクライ アントによってエラーレスポンスから決定されたUSERNAMEが入っていなけれ ばならない(MUST)。リクエストはエラーレスポンスからコピーされたREALMが 入っていなければならない(MUST)。リクエストはエラーレスポンスからコ ピーされたNONCEが入っていなければならない(MUST)。リクエストはUSERNAME アトリビュート中のユーザ名に関連しているパスワードを使用して計算され たMESSAGE-INTEGRITYアトリビュートが入っていなければならない(MUST)。ク ライアントが、前回の試みから、USERNAME、あるいはREALM、あるいはその関 連パスワードを変更していないなら、この再試行を行ってはならない(MUST NOT)。 レスポンスが438(無効なナンス)のエラーコードのエラーレスポンスであるな ら、クライアントは、438(無効なナンス)レスポンスで供給された新しい NONCEを使用して、リクエストを再試行しなければならない(MUST)。また、こ の再試行はUSERNAME、REALM、およびMESSAGE-INTEGRITYを含まなければなら ない(MUST)。 クライアントはレスポンス(成功か失敗のどちらか)中のMESSAGE-INTEGRITYア トリビュートを探す。存在しているなら、クライアントは15.4節で定義され るように、リクエストに利用したのと同じパスワードを使用して、レスポン ス全体のメッセージ完全性を計算する。演算結果がMESSAGE-INTEGRITYアトリ ビュートの内容に合っているなら、レスポンスは認証されているとみなされ る。値が合っていないかMESSAGE-INTEGRITYが欠落していたなら、それを決し て受け取らなかったかのように、レスポンスを捨てなければならない (MUST)。これに当てはまるならば、このことは再送が続くことを意味する。 Rosenberg, et al. Standards Track [Page 27] RFC 5389 STUN October 2008 11. ALTERNATE-SERVERメカニズム この章は、サーバに、クライアントを別のサーバに向け直させるSTUNのメカ ニズムについて記述する。この拡張はオプションであり、そして用法がこの 拡張を使用するときは定義しなければならない。 この拡張を使用するサーバは、リクエストメッセージに300(代替を試行せよ) のエラーコードのエラーレスポンスメッセージで応答することで、クライア ントを別のサーバに向け直す。サーバはエラーレスポンスにALTERNATE- SERVERアトリビュートを含まなければならない(MUST)。エラーレスポンス メッセージを認証してもよい(MAY)。しかしながら、レスポンスの認証が出来 ないか実用的ではないALTERNATE-SERVERのユースケースがある。 この拡張を使用するクライアントは、以下のように300(代替を試行せよ)エ ラーコードを処理する。クライアントはエラーレスポンス中のALTERNATE- SERVERアトリビュートを探す。それが見つかるなら、クライアントは現在の トランザクションを失敗とみなして、クライアントはアトリビュートに指定 されたサーバに、前回のリクエストに使用されたのと同じトランスポートプ ロトコルを使用して、リクエストを試みる。そのリクエストは、認証済みで あるなら、向け直しをさせたサーバへのリクエストにクライアントが使用し たのと同じ資格情報を利用しなければならない(MUST)。クライアントが、最 近5分以内にこのリクエストを既に試みたサーバに向け直されているなら、向 け直しを無視して、トランザクションが失敗したとみなさなければならな い(MUST)。これは、リダイレクションループの場合のサーバ間無限ピンポン を防ぐ。 12. RFC 3489との後方互換性 この章は、RFC 3489 [RFC3489]で定義したオリジナルのプロトコルとのある 程度の後方互換性を許容する手順を定義する。このメカニズムはオプション であり、新しいクライアントが古いサーバに接続できるか、または逆も同様 にできる場合にだけ利用されることを意味する。用法がこの手順を使用する ときは定義しなければならない。 19章はこの仕様書とRFC 3489 [RFC3489]との間のすべての変更を記載する。 しかしながら、"クラシックSTUN"がいくつかの特定の方法で使用されただけ であるので、これらの違いのすべてが重要であるというわけではない。この 拡張の目的について、重要な変更は以下である。RFC 3489では、 o UDPが唯一サポートされていたトランスポートだった。 o 現在マジッククッキーフィールドであるフィールドは、トランザクション IDフィールドの一部であり、トランザクションIDは128ビット長だった。 Rosenberg, et al. Standards Track [Page 28] RFC 5389 STUN October 2008 o XOR-MAPPED-ADDRESSアトリビュートは存在していなく、Bindingメソッド は代わりにMAPPED-ADDRESSアトリビュートを使用していた。 o この仕様書から削除された3つの理解必須なアトリビュート、RESPONSE- ADDRESS、CHANGE-REQUEST、およびCHANGED-ADDRESSがあった。 * CHANGE-REQUESTとCHANGED-ADDRESSは、現在、NATの挙動検出用法 [BEHAVE-NAT]の一部であり、残りのものは非推奨である。 12.1. クライアント処理の変更点 [RFC3489]サーバと相互運用したいクライアントは、Bindingメソッドを使用 して、何もアトリビュートが入っておらず、サーバへのトランスポートプロ トコルとしてUDPを使用するリクエストメッセージを送る必要がある (SHOULD)。うまくいくなら、サーバから受信した成功レスポンスは、XOR- MAPPED-ADDRESSアトリビュートよりむしろMAPPED-ADDRESSアトリビュートが 入っているだろう。より古いサーバで相互運用しようとしているクライアン トは、どちらでも受信する準備ができていなければならない(MUST)。その 上、クライアントは、レスポンスに現れるどんな予約された理解必須なアト リビュートも無視しなければならない(MUST)。18.2節にある予約されたアト リビュートの、0x0002, 0x0004, 0x0005, 0x000Bは、RFC 3489に準拠する サーバからのBindingレスポンスに現れるかもしれない。この変更を除いて、 レスポンスの処理は上に記述された手順と同じである。 12.2. サーバ処理の変更点 STUNサーバは、与えられたBindingリクエストメッセージがRFC 3489 [RFC3489]クライアントからマジッククッキーフィールドに正しい値無しで送 信されたときに検知できる。サーバがRFC 3489クライアントを検知すると き、Bindingリクエストのマジッククッキーフィールドにあった値をBinding レスポンスメッセージのマジッククッキーフィールドにコピーして、XOR- MAPPED-ADDRESSアトリビュートの代わりにMAPPED-ADDRESSアトリビュートを 挿入する必要がある(SHOULD)。 まれな状況では、クライアントはRESPONSE-ADDRESSやCHANGE-REQUESTアトリ ビュートを入れるかもしれない。これらの状況で、サーバはこれらを未知の 理解必須なアトリビュートであるとみなして、エラーレスポンスで返答する だろう。それらのアトリビュートを利用するメカニズムがもうサポートされ ないので、この挙動は許容できる。 STUNのRFC 3489版は、他のプロトコルと多重化するときに、非常に高い確率 で正しくSTUNメッセージを特定することを可能にするマジッククッキーと FINGERPRINTアトリビュートの両方が無い。したがって、RFC 3489と後方互換 Rosenberg, et al. Standards Track [Page 29] RFC 5389 STUN October 2008 性があるSTUNの実装は、別のプロトコルと多重化される場合には使用しない ほうがよい(SHOULD NOT)。しかしながら、そのような多重化がRFC 3489で利 用できなかったので、それは問題とならなかったのだろう。 13. 基本的なサーバの挙動 この章は、スタンドアロンのSTUNサーバの基本的な挙動を定義する。基本的 なSTUNサーバは、STUN Bindingリクエストへの受信と応答で、サーバリフレ クシブトランスポートアドレスをクライアントに提供する。 STUNサーバは、Bindingメソッドをサポートしなければならない(MUST)。短期 または長期資格情報メカニズムを利用しないほうがよい(SHOULD NOT)。これ は、リクエストを認証するのに伴う仕事が単にそれを処理することに伴う仕 事以上であるからだ。同じ理由からそれはALTERNATE-SERVERメカニズムを利 用しないほうがよい(SHOULD NOT)。UDPとTCPをサポートしなければならな い(MUST)。TCP/TLS上でSTUNをサポートしてもよい(MAY)。とはいえ、TLSはこ の操作の基本形態に最小限のセキュリティ利益を提供する。FINGERPRINTメカ ニズムを利用してもよい(MAY)が、それを要求してはならない(MUST NOT)。ス タンドアロンサーバはSTUNを実行するだけであるので、FINGERPRINTは利益を 提供しない。それを要求することはRFC 3489との互換性を崩すだろうし、そ のような互換性はスタンドアロンサーバに好ましい。スタンドアロンSTUN サーバは、12章に記述されるような[RFC3489]クライアントと後方互換性をサ ポートする必要がある(SHOULD)。 STUNサーバの管理者が9章に記述されるようにそれらのサーバのためのDNSエ ントリーを供給することが推奨される(RECOMMENDED)。 基本的なSTUNサーバはそれ自体ではNAT越えのためのソリューションではな い。しかしながら、ソリューションの一部としてSTUN用法でそれを利用でき る。このことは14章でより詳しく議論する。 14. STUN用法 STUNそれ自体はNAT越え問題のソリューションではない。むしろ、STUNはより 大きいソリューション内で使用されるツールと定義する。用語の"STUN用法" は、STUNをコンポーネントとして使用するどんなソリューションでも使用さ れる。 これを書いている時点で、3つのSTUN用法が定義されている。Interactive Connectivity Establishment (ICE) [MMUSIC-ICE]、Client-initiated connections for SIP [SIP-OUTBOUND]、NATの挙動検出 [BEHAVE-NAT]、であ る。他のSTUN用法が将来定義されるかもしれない。 STUN用法はSTUNが実際にどう利用されるかを定義して、それは、いつリクエ ストを送信するか、レスポンスで何をするか、ここで(またはSTUNの拡張で) 定義したどんなオプション手順が使用されるか、である。用法は以下もまた 定義するだろう。 Rosenberg, et al. Standards Track [Page 30] RFC 5389 STUN October 2008 o どのSTUNメソッドが使用されるか。 o どんな認証とメッセージ完全性メカニズムが使用されるか。 o [RFC4107]で議論されるような、完全性メカニズムの手動対自動鍵導出ま わりの検討事項。 o どんなメカニズムが、他のメッセージからSTUNメッセージを区別するのに 使用されるか。STUNがTCP上で実行されるとき、フレーム化メカニズムが 要求されるかもしれない。 o STUNクライアントはSTUNサーバのIPアドレス/ポートをどのように決定す るか。 o RFC 3489への後方互換性が要求されるかどうか。 o ここや他の拡張で定義された(FINGERPRINTとALTERNATE-SERVERのような) どのオプションアトリビュートが要求されるかどうか。 さらに、どんなSTUN用法も、その用法でSTUNを使用することのセキュリティ の意味合いを考えなければならない。STUNに対する多くの攻撃が知られてい て(本書ではセキュリティの検討事項の章を参照)、どんな用法も、どうした らこれらの攻撃を妨害できるか、または緩和できるかを考えなければならな い。 最終的に、用法は、STUNの使い方がNAT越えへのUnilateral Self-Address Fixing(訳注: 相手に見える自己のアドレスを検出したり固定したりする手 順)アプローチの一例であるか否かを考えなければならなく、そうだとすれ ば、RFC 3424 [RFC3424]で出された問題点を処理せよ。 15. STUNアトリビュート STUNヘッダーの後ろに0個以上のアトリビュートがある。各アトリビュートは 16ビットのタイプ、16ビットの長さ、および値でTLVエンコードされなければ ならない(MUST)。それぞれのSTUNアトリビュートは32ビット境界で終わらな ければならない(MUST)。上に記載ものと同様に、アトリビュート内のすべて のフィールドが最上位ビットを先にして転送される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ | 長さ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 値 (可変) .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図4: STUNアトリビュートの書式 Rosenberg, et al. Standards Track [Page 31] RFC 5389 STUN October 2008 長さフィールドの値は、パディングする前に、アトリビュートの値部分の長 さがバイト単位で入っていなければならない(MUST)。STUNはアトリビュート を32ビット境界に整列して、内容が4バイトの倍数でないアトリビュートは1 〜3バイトの詰め物でパディングされるので、その値は4バイトの倍数が入っ ている。パディングビットは無視され、そしてどんな値でも差し支えない。 どんなアトリビュートタイプもSTUNメッセージに一度以上現われれてもよい (MAY)。別段規定されない限り、出現の順番は重要である。つまり、受信者は 最初に現れたものだけは処理する必要があり、そして受信者はどんな重複す るものも無視してもよい(MAY)。 必要とされるなら、この仕様書の将来の改訂が新しいアトリビュートを追加 出来るようにするために、アトリビュート空間は2つの範囲に分けられる。 0x0000〜0x7FFFのタイプ値を持つアトリビュートは理解必須なアトリビュー トであり、それはSTUNエージェントがアトリビュートを理解していなけれ ば、メッセージをうまく処理できないことを意味する。0x8000〜0xFFFFのタ イプ値を持つアトリビュートは理解任意のアトリビュートであり、それは STUNエージェントがそれらを理解していないなら、それらのアトリビュート を無視できることを意味する。 STUNアトリビュートタイプ一式はIANAによって整備される。この仕様書で定 義された初版は18.2節で得られる。 この章の残りはこの仕様書で定義された様々なアトリビュートの形式につい て記述する。 15.1. MAPPED-ADDRESS MAPPED-ADDRESSアトリビュートはクライアントのリフレクシブトランスポー トアドレスを示す。それは、8ビットのアドレスファミリーと16ビットのポー ト、続いてIPアドレスを表す固定長値から成る。アドレスファミリーがIPv4 であるなら、アドレスは32ビットでなければならない(MUST)。アドレスファ ミリーがIPv6であるなら、アドレスは128ビットでなければならない(MUST)。 すべてのフィールドはネットワークバイトオーダーでなければならない。 Rosenberg, et al. Standards Track [Page 32] RFC 5389 STUN October 2008 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| ファミリー | ポート | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | アドレス (32 ビットか128 ビット) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図5: MAPPED-ADDRESS アトリビュートの形式 アドレスファミリーは以下の値を取ることができる。 0x01:IPv4 0x02:IPv6 MAPPED-ADDRESSの最初の8ビットを0に設定しなければならなくて(MUST)、受 信者で無視しなければならない(MUST)。これらのビットは本来の32ビット境 界に揃えるパラメータとして存在している。 このアトリビュートは、RFC 3489 [RFC3489]クライアントとの後方互換性を 達成するためのサーバでだけ使用される。 15.2. XOR-MAPPED-ADDRESS XOR-MAPPED-ADDRESSアトリビュートは、リフレクシブトランスポートアドレ スがXOR関数を通してわかりにくくさせられていることを除いて、MAPPED- ADDRESSアトリビュートと同じである。 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| ファミリー | X-ポート | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | X-アドレス (可変) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図6: XOR-MAPPED-ADDRESS アトリビュートの形式 ファミリーはIPアドレスファミリーの表わしていて、MAPPED-ADDRESSのファ ミリーと同様にエンコードされる。 Rosenberg, et al. Standards Track [Page 33] RFC 5389 STUN October 2008 X-ポートは、マップされたポートをホストバイトオーダーで取得して、マ ジッククッキーの最上位16ビットでそれをXORして、そしてその後、その結果 をネットワークバイトオーダーへ変換することで計算される。IPアドレス ファミリーがIPv4であるなら、X-アドレスは、マップされたIPアドレスをホ ストバイトオーダーで取得して、マジッククッキーでそれをXORして、そして その結果をネットワークバイトオーダーに変換することで計算される。IPア ドレスファミリーがIPv6であるなら、X-アドレスは、マップされたIPアドレ スをホストバイトオーダーで取得して、マジッククッキーと96ビットのトラ ンザクションIDとを連結したものでそれをXORして、そしてその結果をネット ワークバイトオーダーに変換することで計算される。 アトリビュートの値の最初の8ビットをエンコードや処理するための規則、ア トリビュートが複数回現れたものを扱うための規則、およびアドレスファミ リーを処理するための規則は、MAPPED-ADDRESSのものと同じである。 注意: XOR-MAPPED-ADDRESSとMAPPED-ADDRESSはトランスポートアドレスのエ ンコードにおいてだけ異なる。前者はトランスポートアドレスをそれとマ ジッククッキーとの排他的論理和を取ることでエンコードする。後者はそれ を直接バイナリーでエンコードする。RFC 3489は元々、MAPPED-ADDRESSだけ を指定した。しかしながら、展開経験によっていくつかのNATsが、汎用ALG機 能を提供しようとする善意だが的外れな試みで、STUNのMAPPED-ADDRESSアト リビュートのような、NATのパブリックIPアドレスが入っている32ビットバイ ナリペイロードを書き換えるのがわった。そのような挙動は、STUNの操作を 妨げ、そしてSTUNのメッセージ完全性チェックの失敗もまた引き起こす。 15.3. USERNAME USERNAMEアトリビュートはメッセージ完全性のために使用される。それは メッセージ完全性チェックに使用したユーザ名とパスワードの組み合わせを 確認する。 USERNAMEの値は可変長の値である。それは、513バイト以下にエンコードされ たUTF-8 [RFC3629]列が入っていなければならなく(MUST)、そして、 SASLprep [RFC4013]を使用して処理されていなければならない(MUST)。 15.4. MESSAGE-INTEGRITY MESSAGE-INTEGRITYアトリビュートはSTUNメッセージのHMAC-SHA1 [RFC2104] が入っている。MESSAGE-INTEGRITYアトリビュートはどんなSTUNメッセージタ イプでも与えることが出来る。SHA1ハッシュを使用するので、HMACは20バイ トになるだろう。HMACへの入力として使用されるテキストは、ヘッダーを含 み、MESSAGE-INTEGRITYアトリビュートに先行するアトリビュートまでを含め たSTUNメッセージである。MESSAGE-INTEGRITYの後に現れるFINGERPRINTアト リビュートを除いて、エージェントはMESSAGE-INTEGRITYに続く他のすべての アトリビュートを無視しなければならない(MUST)。 Rosenberg, et al. Standards Track [Page 34] RFC 5389 STUN October 2008 HMACのための鍵は長期または短期資格情報が使用中であるかどうかよる。長 期資格情報では、鍵は16バイトであり、以下となる。 鍵 = MD5(ユーザ名 ":" レルム ":" SASLprep(パスワード)) すなわち、16バイトの鍵は以下の5つのフィールドを連結した結果のMD5ハッ シュを取ることで次のように形成される。(1) (SASLprepが既に適用されてい る場合に)USERNAMEアトリビュートから取ってきたような、すべての引用符と 後ろに続くヌル文字を取り除いたユーザ名、(2) 単独のコロン、(3) すべて の引用符と後ろに続くヌル文字を取り除いたレルム、(4) 単独のコロン、そ して、(5) 後ろに続くすべてのヌル文字を取り除いて、SASLprepを使用して 処理した後のパスワード。例えば、ユーザ名が'user'であり、レルムが 'realm'であり、パスワードが'pass'であるなら、16バイトのHMAC鍵は、文字 列'user:realm:pass'にMD5ハッシュを実行した結果で、結果となるハッシュ は0x8493fbc53ba582fb4c044c456bdc40ebとなるだろう。 短期資格情報では、 鍵 = SASLprep(パスワード) これらMD5はRFC 1321 [RFC1321]に定義されていて、SASLprep()はRFC 4013 [RFC4013]に定義されている。 長期資格情報で使用される鍵の構造は、SIPもまた利用するシステムの展開を 容易にする。通常、SIPのダイジェスト認証機構を利用するSIPシステムは データベースにパスワードを実際には保存しない。むしろ、それらは上で定 義された鍵と等しいH(A1)と呼ばれる値を保存する。 上の規則に基づいて、そのハッシュは、STUNメッセージヘッダーの長さ フィールドを含んでいるMESSAGE-INTEGRITYを構成するのに使われる。ハッ シュを実行する前に、MESSAGE-INTEGRITYアトリビュートは(ダミーの内容で) メッセージに挿入されなければならない(MUST)。次に、長さは、MESSAGE- INTEGRITYアトリビュート自身までを含んだ、その後のどんなアトリビュート も除いたところまでのメッセージの長さを示すように設定されなければなら ない(MUST)。いったん計算が実行されると、MESSAGE-INTEGRITYアトリビュー トの値に記入することができて、STUNヘッダー中の長さの値を正しい値、つ まり全体のメッセージの長さに設定できる。同様に、MESSAGE-INTEGRITYを確 認するとき、長さフィールドは、HMACを計算する前のMESSAGE-INTEGRITYアト リビュートの最後を示すように調整される必要がある。FINGERPRINTなどのア トリビュートがMESSAGE-INTEGRITYの後に現れるとき、そのような調整が必要 である。 Rosenberg, et al. Standards Track [Page 35] RFC 5389 STUN October 2008 15.5. FINGERPRINT FINGERPRINTアトリビュートはすべてのSTUNメッセージで存在してもよい (MAY)。アトリビュートの値は、FINGERPRINTアトリビュート自身(ただし除外 する)までのSTUNメッセージのCRC-32として計算され、32ビット値0x5354554e とXORされる(XORは、アプリケーションパケットもまたその中でCRC-32を使用 している場合に役に立つ)。32ビットCRCはITU V.42 [ITU.V42.2002]で定義さ れたもので、x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1の生成 多項式を持っている。存在するならば、FINGERPRINTアトリビュートはメッ セージの最後のアトリビュートでなければならなく(MUST)、その結果 MESSAGE-INTEGRITYの後に現れるだろう。 FINGERPRINTアトリビュートは他のプロトコルのパケットとSTUNパケットを区 別することを手助け出来る。8章参照。 MESSAGE-INTEGRITYのように、FINGERPRINTアトリビュートで使用されるCRCは STUNメッセージヘッダーの長さフィールドが取り扱う。したがって、この値 は、CRCの計算の前に、正しく、かつメッセージ長の一部としてCRCアトリ ビュートを含まなければならない。メッセージでFINGERPRINTアトリビュート を使用するとき、最初にダミーの値でアトリビュートをメッセージに置き、 次にCRCを計算して、次にアトリビュートの値を更新する。MESSAGE- INTEGRITYアトリビュートもまた存在しているなら、MESSAGE-INTEGRITYアト リビュートの値も含めてその上でCRCを計算するので、CRCが計算される前に 正しいメッセージ完全性値で存在していなければならない。 15.6. ERROR-CODE ERROR-CODEアトリビュートはエラーレスポンスメッセージで使用される。そ れは、300から699の範囲の数値エラーコードにUTF-8 [RFC3629]でエンコード したテキストの理由句を加えたものが入っていて、そのコード割り当てと意 味ではSIP [RFC3261]とHTTP [RFC2616]と一致している。理由句はユーザ消費 を意図されていて、エラーコードのために何か適切なものにするとよい。定 義されたエラーコードのための推奨される理由句は、エラーコードのIANAレ ジストリに含まれている。理由句は128文字未満(763バイトほどに長くなるこ とがある)のUTF-8 [RFC3629]エンコード列でなければならない(MUST)。 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である必要がある |クラス| 番号 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+ | 理由句 (可変) .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+ 図7: ERROR-CODE アトリビュート Rosenberg, et al. Standards Track [Page 36] RFC 5389 STUN October 2008 処理を容易にするために、エラーコードのクラス(百の桁)は、図7に示される ように、コードの残りと分けてエンコードされる。 予約されたビットは0である必要があり(SHOULD)、32ビット境界に整列するた めのものである。受信者はこれらのビットを無視しなければならない (MUST)。クラスはエラーコードの百の桁に対応する。値は3〜6でなければな らない(MUST)。番号はエラーコードを100で割った余りに対応して、その値は 0〜99でなければならない(MUST)。 以下のエラーコードは、それらの推奨される理由句と共に、以下のように定 義される。 300 代替を試行せよ(Try Alternate): クライアントはこの要求のための代 替サーバにコンタクトをとる必要がある。リクエストがUSERNAMEアトリ ビュートと有効なMESSAGE-INTEGRITYアトリビュートを含んでいたな ら、このエラーレスポンスだけを送信しなければならない(MUST)。その 他では、送信してはならず(MUST NOT)、エラーコード400(不正なリクエ スト)が提案される。このエラーレスポンスはMESSAGE-INTEGRITYアトリ ビュートで保護されなければならなく(MUST)、そして受信者は、代替 サーバに自分たちを向け直す前に、このレスポンスのMESSAGE- INTEGRITYを確認しなければならない(MUST)。 注意: 300レスポンスのメッセージ完全性の生成・確認不足は、経 路上の攻撃者に300レスポンスの改ざんを許し、例えば、後続STUN メッセージが被害者に送られることを引き起こす。 400 不正なリクエスト(Bad Request): リクエストが不正だった。クライア ントは前回の試みから変更なしでリクエストを再試行しないほうがよ い(SHOULD NOT)。サーバがこのエラーの有効なMESSAGE-INTEGRITYを生 成することができないかもしれないので、クライアントはこのレスポン スで有効なMESSAGE-INTEGRITYアトリビュートを期待してはならない (MUST NOT)。 401 認証失敗(Unauthorized): リクエストには続行するための正しい資格情 報が入っていなかった。クライアントは適切な資格情報でリクエストを 再試行する必要がある。 420 未知のアトリビュート(Unknown Attribute): サーバは、理解していな い理解必須なアトリビュートが入っているSTUNパケットを受信した。 サーバはエラーレスポンスのUNKNOWN-ATTRIBUTEアトリビュートにこの 未知のアトリビュートを入れなければならない(MUST)。 438 無効なナンス(Stale Nonce): クライアントによって使用されたNONCEがも う有効ではなかった。レスポンスで提供されたNONCEを使用して、クラ イアントは再試行する必要がある。 500 サーバエラー(Server Error): サーバは一時的なエラーを受信した。ク ライアントは再試行する必要がある。 Rosenberg, et al. Standards Track [Page 37] RFC 5389 STUN October 2008 15.7. REALM REALMアトリビュートはリクエストとレスポンスで存在してもよい。それは、 RFC 3261 [RFC3261]で記述されているような"レルム値"の文法で、しかし二 重引用符とそれらの周囲の空白文字を含まないことを満たすテキストが入っ ている。すなわち、それは引用符無しレルム値である(従って、qdtextや quoted-pairの列である)。それは、128文字未満(763バイトほどに長くなるこ とがある)のUTF-8 [RFC3629]エンコード列でなければならなく(MUST)、そし て、SASLprep [RFC4013]を使用して処理されていなければならない(MUST)。 リクエスト内のREALMアトリビュートの存在は、長期資格情報が認証に使用さ れていることを示す。あるエラーレスポンス内での存在は、サーバがクライ アントに認証で長期資格情報を使用して欲しいことを示す。 15.8. NONCE NONCEアトリビュートはリクエストとレスポンスで存在してもよい。それは、 RFC 3261 [RFC3261]で定義されるqdtextやquoted-pairの列が入っている。こ れはNONCEアトリビュートには実際の引用符文字が入っていないことを意味す る、ということに注意すること。サーバでのナンス値選択に関する手引きに ついては、RFC 2617 [RFC2617]の4.3節を参照のこと。 それは、128文字未満(763バイトほどに長くなることがある)でなければなら ない(MUST)。 15.9. UNKNOWN-ATTRIBUTES UNKNOWN-ATTRIBUTESアトリビュートは、ERROR-CODEアトリビュートにおける レスポンスコードが420であるときのエラーレスポンスにだけ存在する。 アトリビュートは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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アトリビュート 1 タイプ | アトリビュート 2 タイプ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アトリビュート 3 タイプ | アトリビュート 4 タイプ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 図8: UNKNOWN-ATTRIBUTES アトリビュートの形式 Rosenberg, et al. Standards Track [Page 38] RFC 5389 STUN October 2008 注意: [RFC3489]では、このフィールドは最後のアトリビュートを複製す ることで、32ビットにパディングされた。仕様書のこの版では、アトリ ビュートの標準パディング規則が代わりに使用される。 15.10. SOFTWARE SOFTWAREアトリビュートはメッセージを送るエージェントによって使用され るソフトウェアのテキストでの記述が入っている。それはクライアントと サーバで使用される。その値は製造者とバージョン番号を含む必要がある (SHOULD)。そのアトリビュートは、プロトコルの操作に影響力を全く持たな いで、単に診断とデバッグ目的のためのツールとして機能する。SOFTWAREの 値は可変長である。それは128文字未満(763バイトほどに長くなることがあ る)のUTF-8 [RFC3629]エンコード列でなければならない(MUST)。 15.11. ALTERNATE-SERVER 代替サーバは、STUNクライアントが試みる必要がある別のSTUNサーバを特定 する代替トランスポートアドレスを表わす。 それはMAPPED-ADDRESSと同様にエンコードされていて、従ってIPアドレスで 一つのサーバを示す。そのIPアドレスファミリーはリクエストのソースIPア ドレスのものと同じでなければならない(MUST)。 16. セキュリティの検討事項 16.1. プロトコルに対する攻撃 16.1.1. 外部攻撃 攻撃者は、STUN操作での失敗を引き起こすために、伝送中のSTUNメッセージ を変更しようとすることができる。これらの攻撃は、短期または長期資格情 報のいずれかを使用するメッセージ完全性メカニズムを通して、リクエスト とレスポンスの両方で検知される。もちろん、いったん検知されると、小細 工されたパケットは落とされて、STUNトランザクションが事実上失敗するこ とを引き起こす。この攻撃は経路上の攻撃者でだけ可能である。 伝送中のSTUNメッセージを観測できるが変更できない攻撃者(例えば、Wi-Fi などの共用アクセス媒体にいる攻撃者)は、STUNリクエストを見て、それから すぐにSTUNレスポンス、典型的にはエラーレスポンスを、STUN処理を中断す るために、送信することが出来る。また、この攻撃はメッセージがMESSAGE- INTEGRITYを利用することを妨げられる。しかしながら、MESSAGE-INTEGRITY はいくつかのエラーレスポンス、特に認証に関連するものを保護できない。 STUN自身が安全なトランスポートプロトコル(例えば、TLS)上で実行される と、これらの攻撃は完全に静められる。 Rosenberg, et al. Standards Track [Page 39] RFC 5389 STUN October 2008 STUN用法に頼ることで、これらの攻撃は最小限の結果となるかもしれなく て、従って、静めるためのメッセージ完全性を要求しない。例えば、ICEの 用法のためのサーバリフレクシブ候補を発見するために、STUNが基本的な STUNサーバに使用されるとき、これらの攻撃が接続性チェック段階の間に検 知されるので、認証とメッセージ完全性は要求されない。しかしながら、接 続性チェック自体は全体的に見てICEの適切な操作のための保護を要求する。 14章に記述されるように、STUN用法は、認証とメッセージ完全性とがいつ必 要とされるかを記述する。 STUNが認証と完全性保護に共有秘密鍵のHMACを使用するので、それはオフラ イン辞書攻撃を受ける問題がある。認証が利用されているとき、オフライン 辞書攻撃を容易には受けにくい強いパスワードを用いる必要がある (SHOULD)。通信路自体の保護、つまりTLSを使用することは、これらの攻撃を 静める。しかしながら、STUNはたいていUDP上で実行され、そしてそれらの場 合、強いパスワードがこれらの攻撃から守る唯一の方法である。 16.1.2. 内部攻撃 不正なクライアントが多くのSTUNリクエストをサーバに送ることで、サーバ に対してのDoS攻撃を起こそうとするかもしれない。幸い、STUNリクエストは サーバでステートレスに処理でき、そのような攻撃を起こすのを困難にす る。 不正なクライアントはリフレクターとしてSTUNサーバを使用して、改竄され たソースIPアドレス/ポートによるリクエストを送るかもしれない。このよう な場合には、レスポンスはそのソースIP/ポートに届けられるだろう。STUNレ スポンスがリクエストより通常大きいので、データ量に微増があるが、この 攻撃によるパケット数の増幅は全くない(STUNサーバは、クライアントによっ て送信された各パケットに対して1つのパケットを送信する)。この攻撃はイ ングレスソースアドレスフィルタリングによって静められる。 SOFTWAREアトリビュートを通してエージェントの特定のソフトウェアバー ジョンを明らかにすることが、セキュリティーホールがあるのが知られてい るソフトウェアに対する攻撃に、より脆弱にさせるかもしれない。実装者は SOFTWAREアトリビュートの使用を構成可能なオプションにする必要がある (SHOULD)。 16.2. 用法に影響する攻撃 この章はSTUNの用法に対して起こされるかもしれない攻撃をリストアップす る。それぞれのSTUN用法はこれらの攻撃がそれに当てはまっているかどうか を考察して、もし当てはまるならば、対策について議論しなければならな い。 この章での攻撃の大部分は、Bindingリクエスト/レスポンストランザクショ ンを通してSTUNクライアントが知ったリフレクシブアドレスを改ざんする攻 Rosenberg, et al. Standards Track [Page 40] RFC 5389 STUN October 2008 撃者を中心題目とする。リフレクシブアドレスの利用が用法の一機能である ので、これらの攻撃の適否と対処法は用法特有となる。日常の状況では、経 路上の攻撃者によるリフレクシブアドレスの改ざんはしやすい。例えば、 STUNがUDP上で直接実行される日常の状況を考えろ。この場合、経路上の攻撃 者はBindingリクエストがSTUNサーバに到着する前にそのソースIPアドレスを 改ざんできる。それからSTUNサーバはXOR-MAPPED-ADDRESSアトリビュート内 のこのIPアドレスをクライアントに返そうとして、その(改ざんされた)IPア ドレス/ポートにレスポンスを送り返すだろう。また、攻撃者がこのレスポン スを傍受できるなら、クライアントに対してそれを戻すことができる。メッ セージ完全性値がソースIPアドレスを取り扱えないのと、介在しているNAT がこの値を変更できなければならないので、メッセージ完全性チェックを使 用することによるこの攻撃に対する保護は不可能である。代わりに、以下に リストアップされた攻撃を防ぐことへの1つのソリューションは、ICE [MMUSIC-ICE]でされているように、クライアントが知ったリフレクシブアド レスを確かめることである。他の用法はこれらの攻撃を防ぐ他の手段を使用 するかもしれない。 16.2.1. 攻撃I: 標的に対する分散DoS (DDoS) この攻撃では、攻撃者は向けられる標的を指す同じ偽装されたリフレクシブ アドレスを1台以上のクライアントに与える。このことは、STUNクライアント らのリフレクシブアドレスが標的のものと等しいと思うようにSTUNクライア ントをだますだろう。クライアントがそれ上で(例えば、SIPメッセージで)ト ラフィックを受信するためにそのリフレクシブアドレスを配ると、トラ フィックが代わりに標的に送られるだろう。特にマルチメディアアプリケー ションを有効にするのにSTUNを使用しているクライアントで使用されると、 この攻撃はかなりの増幅を与えることができる。しかしながら、STUNサーバ から攻撃者を通り抜けて標的へ行くパケットの標的に対して起こすことがで きるだけであり、それが可能である場合を限定する。 16.2.2. 攻撃II: クライアントの沈黙 この攻撃では、攻撃者は偽装されたリフレクシブアドレスをSTUNクライアン トに与える。与えるリフレクシブアドレスはどこにも届かないトランスポー トアドレスである。その結果、そのリフレクシブアドレスを与えるとき、ク ライアントは受信を期待するパケットのいずれも受信しないだろう。この攻 撃は攻撃者とってそれほどおもしろくない。それは単独のクライアントに影 響を与え、それは滅多に望まれる標的ではない。そのうえ、攻撃を仕掛ける ことができるどんな攻撃者は、クライアントがSTUNサーバ、またはDHCPサー バからさえも、どんなレスポンスも受信させないなどのような、他の手段で クライアントへのサービスを不能にもまたできるだろう。16.2.1小節におけ る攻撃のように、攻撃者がSTUNサーバからこの未使用のIPアドレスに向けて 送られたパケットの経路上にいるときだけ、この攻撃は可能である。 Rosenberg, et al. Standards Track [Page 41] RFC 5389 STUN October 2008 16.2.3. 攻撃III: クライアントの身元の横領 この攻撃は攻撃IIと類似している。しかしながら、偽装されたリフレクシブ アドレスは攻撃者自身を指す。これは攻撃者にクライアントに望まれたトラ フィックを受信できるようにする。 16.2.4. 攻撃IV: 盗み聞き この攻撃では、攻撃者は攻撃者自身に届くリフレクシブアドレスをクライア ントに強制的に使用させる。そして、攻撃者が受信するどんなパケットもク ライアントに転送する。この攻撃では、クライアントに送信されるすべての パケットを攻撃者が観察できるだろう。しかしながら、攻撃を始めるため に、攻撃者はクライアントからSTUNサーバへのパケットを既に観察できたに 違いない。多くの場合(攻撃がアクセスネットワークから起こされる時のよう な)、これは攻撃者がクライアントに送られたパケットを既に観察できたこと を意味する。この攻撃は、その結果、クライアントからSTUNサーバまでの経 路上にいる攻撃者にトラフィックを観測することの役に立つだけで、クライ アントに向けて配送されているパケットの経路上にいる多くの人に役に立つ というわけではない。 16.3. ハッシュアルゴリズムの移行計画 この仕様書はメッセージ完全性の計算にHMAC-SHA-1を使用する。後で、HMAC- SHA-1がセキュリティを脅かされているのが分かったなら、以下が適用される 療法である。 私たちは、新しいハッシュを使用して計算される新しいメッセージ完全性ア トリビュートを導入するSTUN拡張を定義するつもりである。クライアントは それらのリクエストやインディケーションに新しいメッセージ完全性アトリ ビュートと古いのの両方を含めることが要求されるだろう。新しいサーバで は新しいメッセージ完全性アトリビュート、古いサーバでは古いものを利用 するだろう。混在した実装が展開中である移行期の後、古いメッセージ完全 性アトリビュートは別の仕様書で非推奨となり、そしてクライアントはリク エストにそれを含めるのをやめるだろう。 また、HMACがユーザのパスワードのMD5を使用してそれ自身が計算される鍵が 使用されていることに注意するのも重要である。その形式でパスワードを保 存するレガシーデータベースの存在のためにMD5ハッシュの選択をした。MD5 入力のHMACが安全でないことが今後の活動によってわかって、異なるハッ シュを必要とするなら、この計画を使用することでもまた変えることができ る。しかしながら、これは、管理者が彼らのデータベースを再配置すること を要求するだろう。 17. IABの検討事項 IABはUnilateral Self-Address Fixing (UNSAF)の問題を研究していて、それ は、クライアントが、協力的プロトコル反射メカニズム(RFC3424 [RFC3424]) Rosenberg, et al. Standards Track [Page 42] RFC 5389 STUN October 2008 を通じてNATの反対側にある別レルムでのそのアドレスを判定することを試み る一般的な処理である。1つのエージェントがNAT配下にあり、もう1つがNAT のパブリック側にあるなら、Bindingリクエスト/レスポンストランザクショ ンを使用しているこの機能を実行するのにSTUNを使用できる。 IABは、この目的のために開発されたプロトコルが特定の検討事項一式を記載 するよう委任している。いくつかのSTUN用法がUNSAF機能を供給して(ICE [MMUSIC-ICE]など)、他のものがしない(SIP Outbound [SIP-OUTBOUND]など) ので、これらの検討事項への回答を用法自体が扱う必要がある。 18. IANAの検討事項 IANAは次の3つの新しいレジストリを作成した。"STUNメソッドレジストリ"、 "STUNアトリビュートレジストリ"、そして"STUNエラーコードレジストリ"、 である。また、IANAは"nat-stun-port"から"stun"にSTUN用に割り当てられた IANAポートの名前を変更した。 18.1. STUNメソッドレジストリ STUNメソッドは範囲0x000〜0xFFFの16進数である。STUNメソッドのSTUNメッ セージへのエンコーディングは6章に記述される。 STUNメソッドの初版は以下の通りである。 0x000: (予約済み) 0x001: Binding 0x002: (予約済み、SharedSecretだった) 範囲0x000〜0x7FFのSTUNメソッドはIETFレビュー[RFC5226]によって割り当て られる。範囲0x800〜0xFFFのSTUNメソッドは選定された専門家[RFC5226]に よって割り当てられる。専門家の責任は選択されたコード値が使用中でな く、また要求が異常に多くのコード値のためでないことを確かめることであ る。拡張自体の技術審査は選定された専門家の責任の範囲外である。 18.2. STUNアトリビュートレジストリ STUNアトリビュートタイプは範囲0x0000〜0xFFFの16進数である。範囲0x0000 〜0x7FFFのSTUNアトリビュートタイプは理解必須であるとみなされる。範囲 0x8000〜0xFFFFのSTUNアトリビュートタイプは理解任意であるとみなされ る。STUNエージェントは未知の理解必須と理解任意のアトリビュートを別に 扱う。 STUNアトリビュートタイプの初版は以下の通りである。 Rosenberg, et al. Standards Track [Page 43] RFC 5389 STUN October 2008 理解必須の範囲 (0x0000〜0x7FFF): 0x0000: (予約済み) 0x0001: MAPPED-ADDRESS 0x0002: (予約済み、RESPONSE-ADDRESSだった) 0x0003: (予約済み、CHANGE-ADDRESS(訳注: CHANGE-REQUESTの誤り)だっ た) 0x0004: (予約済み、SOURCE-ADDRESSだった) 0x0005: (予約済み、CHANGED-ADDRESSだった) 0x0006: USERNAME 0x0007: (予約済み、PASSWORDだった) 0x0008: MESSAGE-INTEGRITY 0x0009: ERROR-CODE 0x000A: UNKNOWN-ATTRIBUTES 0x000B: (予約済み、REFLECTED-FROMだった) 0x0014: REALM 0x0015: NONCE 0x0020: XOR-MAPPED-ADDRESS 理解任意の範囲 (0x8000〜0xFFFF) 0x8022: SOFTWARE 0x8023: ALTERNATE-SERVER 0x8028: FINGERPRINT 理解必須な範囲の前半(0x0000〜0x3FFF)と理解任意の範囲の前半(0x8000〜 0xBFFF)のSTUNアトリビュートタイプはIETFレビュー[RFC5226]によって割り 当てられる。理解必須な範囲の後半(0x4000〜0x7FFF)と理解任意の範囲の後 半(0xC000〜0xFFFF)のSTUNアトリビュートタイプは選定された専門家 [RFC5226]によって割り当てられる。専門家の責任は選択されたコード値が使 用中でなく、また要求が異常に多くのコード値のためでないことを確かめる ことである。拡張自体の技術審査は選定された専門家の責任の範囲外であ る。 18.3. STUNエラーコードレジストリ STUNエラーコードは範囲0〜699の数である。STUNエラーコードは、人間の消 費だけを意図されていて、何か適切なものにすることができるテキストの理 由句がUTF-8 [RFC3629]で添えられる。この文書は提案された値だけを提案す る。 STUNエラーコードはコード値割り当てと意味でSIP [RFC3261]とHTTP [RFC2616]と一致している。 このレジストリの初版の値が15.6節に与えられる。 Rosenberg, et al. Standards Track [Page 44] RFC 5389 STUN October 2008 新しいSTUNエラーコードはIETFレビュー [RFC5226]に基づいて割り当てられ る。仕様書は、このエラーコードを理解していないクライアントがどのよう にそれを処理するかを要求を承諾する前に慎重に考えなければならない。 7.3.4小節における規則を参照のこと。 18.4. STUN UDP/TCPポート番号 IANAは以前STUNのためにポート3478を割り当てた。このポートはIANAレジス トリに名前"nat-stun-port"として出ている。登録済みプロトコルサービスと DNS SRV手順を合わせるために、IANAはポート3478に割り当てられたプロトコ ルの名前を"nat-stun-port"から"stun"に、テキストの名前を"Simple Traversal of UDP Through NAT (STUN)"から"Session Traversal Utilities for NAT"に変えるよう要求されて、それでIANAポートレジストリには以下の ように書いてあるだろう: stun 3478/tcp Session Traversal Utilities for NAT (STUN) ポート stun 3478/udp Session Traversal Utilities for NAT (STUN) ポート さらに、IANAはTCPとUDP上で定義された"stuns"サービスにポート番号5349を 割り当てた。そのUDPポートは現在定義されていない。しかしながら、それは 将来使用するために予約される。 19. RFC 3489からの変更 この仕様書はRFC 3489 [RFC3489]を廃止する。この仕様書は以下の点でRFC 3489と異なっている。 o STUNが完全なNAT越えソリューションであるという考えを取り除いた。現 在、STUNはNAT越えソリューションを作り出すのに使用できるツールであ る。ゆえに、プロトコルの名前をNATのためのセッショントラバーサル ユーティリティに変更した。 o STUN用法の概念を導入して、STUN用法が記載しなければならないことにつ いて記述した。 o NATタイプ検知とバインディング存続期間検出のためのSTUNの用法を削除 した。これらのテクニックはNATデバイスのタイプが本文書で記述される より多岐に渡るために大いに当てにならないことがわかった。RESPONSE- ADDRESS、CHANGED-ADDRESS、CHANGE-REQUEST、SOURCE-ADDRESS、および REFLECTED-FROMアトリビュートを削除した。 o 固定32ビットのマジッククッキーを追加して、トランザクションIDの長さ を32ビット分減らした。マジッククッキーは元のトランザクションIDと同 じオフセットで始まる。 Rosenberg, et al. Standards Track [Page 45] RFC 5389 STUN October 2008 o XOR-MAPPED-ADDRESSアトリビュートを追加して、それは、マジッククッ キーがリクエストに存在しているなら、Bindingレスポンスに含まれる。 そうでなければ、RFC 3489の挙動が維持される(すなわち、Bindingレスポ ンスはMAPPED-ADDRESSを含む)。この変更に関するXOR-MAPPED-ADDRESSの 議論を参照のこと。 o リクエスト、レスポンス、エラーレスポンス、あるいはインディケーショ ンを示すもののために明示的なビットの組で、メッセージタイプヘッダー フィールドにきちんとした構造を導入した。その結果、メッセージタイプ フィールドがクラス(前述の4つのうちの1つ)とメソッドに分けられる。 o ICEで使用されるときRTPパケットと簡単な区別が出来るように、STUNの最 上位2ビットが0b00であると明示的に指摘した。 o 2つのプロトコルが一緒に多重化されるとき、STUNと別のプロトコルの違 いを確実に検知する方法を提供するためにFINGERPRINTアトリビュートを 加えた。 o IPv6のサポートを追加した。IPv4クライアントがv6のマップドアドレスを 得ること、その逆も同様に出来ることを明確にした。 o 長期資格情報ベース認証を追加した。 o SOFTWARE、REALM、NONCE、とALTERNATE-SERVERアトリビュートを追加し た。 o SharedSecretメソッドを削除して、その結果、PASSWORDアトリビュートを 削除した。このメソッドはほとんど実装されなく、また現在の用法で必要 ではない。 o 攻撃を認識しようとするために10秒間STUNレスポンスを聞き続けるという 推奨を削除した。 o よりTCPフレンドリーになるためにトランザクションタイマーを変更し た。 o 制御面とメディア面の分離を中心に置いたSTUNの例を削除した。代わり に、プロトコルでSTUNを使用する詳しい情報を提供した。 o 長さアトリビュートの解釈を変更する一般的なパディングメカニズムを定 義した。これは、理論上、後方互換性を壊すだろう。しかしながら、RFC 3489のメカニズムは、32ビット境界に自然に並べられなかったわずかなア トリビュートにおいて決して動作しなかった。 o REALM、SERVER、理由句、そしてNONCEは127文字に制限した。USERNAMEは 513バイトに。 Rosenberg, et al. Standards Track [Page 46] RFC 5389 STUN October 2008 o TCPとTLSのためにDNS SRV手順を変更した。UDPは従来と同様のままで残っ ている。 20. 貢献者 Christian Huitema氏とJoel Weinberger氏はRFC 3489の原共同執筆者であ る。 21. 謝辞 執筆者は、Cedric Aoun氏、Pete Cordell氏、Cullen Jennings氏、Bob Penfield氏、Xavier Marjou氏、Magnus Westerlund氏、Miguel Garcia氏、 Bruce Lowekamp氏、Chris Sullivan氏の彼らのコメントに、そしてBaruch Sterman氏とAlan Hawrylyshen氏の初期実装に感謝致します。この仕事に関 わったIESGとIABのLeslie Daigle氏、Allison Mankin氏、Eric Rescorla氏、 Henning Schulzrinne氏に感謝します。 22. 参考文献 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. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Rosenberg, et al. Standards Track [Page 47] RFC 5389 STUN October 2008 [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. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005. 22.2. 有益な参考文献 [BEHAVE-NAT] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using STUN", Work in Progress, July 2008. [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. [KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", SIGCOMM 1987, August 1987. [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-ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, July 2008. [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. Rosenberg, et al. Standards Track [Page 48] RFC 5389 STUN October 2008 [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. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [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. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [SIP-OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, June 2008. Rosenberg, et al. Standards Track [Page 49] RFC 5389 STUN October 2008 付録A. STUNメッセージタイプを判定するCの補完機能 msg_typeパラメータにホストバイトオーダーで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) 執筆者の連絡先 Jonathan Rosenberg Cisco Edison, NJ US EMail: jdrosen@cisco.com URI: http://www.jdrosen.net Rohan Mahy Unaffiliated EMail: rohan@ekabal.com Philip Matthews Unaffiliated EMail: philip_matthews@magma.ca Dan Wing Cisco 771 Alder Drive San Jose, CA 95035 US EMail: dwing@cisco.com Rosenberg, et al. Standards Track [Page 50] RFC 5389 STUN October 2008 Full Copyright Statement Copyright (C) The IETF Trust (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. 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. 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. 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. 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. 日本語訳 2010/12/09版 訳者 佐藤 良 Rosenberg, et al. Standards Track [Page 51]