Network Working Group J. Rosenberg Request for Comments: 3263 dynamicsoft Obsoletes: 2543 H. Schulzrinne Category: Standards Track Columbia U. June 2002 セッション開始プロトコル(SIP): SIPサーバーの位置特定 Session Initiation Protocol (SIP): Locating SIP Servers 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準 トラックプロトコルを規定するものであり、改善のための議論や提案を 依頼するものである。標準化の段階や、プロトコルの位置付けについては、 最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。 この文書の配布は無制限である。 Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. 概要 Session Initiation Protocol (SIP)は、クライアントがSIPのUniform Resource Identifier (URI)を接続するネクストホップのIPアドレス、ポート、 トランスポートプロトコル解決することができるように、DNS処理を使用する。 また、SIPは、プライマリクライアントが機能しない場合に、サーバーが応答 をバックアップクライアントへ送信できるように、DNSを使用する。このドキ ュメントは、それらのDNS処理を詳しく解説する。 目次 1 はじめに ............................................ 2 2 DNSが解決する必要のある問題 ......................... 2 3 述語規則 ............................................ 5 4 クライアントの用法 .................................. 5 4.1 トランスポートプロトコルの選択 ...................... 6 4.2 ポートとIPアドレスの決定 ............................ 8 4.3 RFC2782処理の詳細 ................................... 9 4.4 ステートレスプロキシの考慮 .......................... 10 5 サーバーの用法 ...................................... 11 6 SIP URIの構成 ....................................... 12 7 セキュリティの考慮 .................................. 12 8 トランスポート決定アプリケーション .................. 13 9 IANAの考慮 .......................................... 14 10 謝辞 ................................................ 14 11 規範的な参考文献 .................................... 15 12 有益な参考文献 ...................................... 15 Rosenberg & Schulzrinne Standards Track [Page 1] RFC 3263 SIP: Locating SIP Servers June 2002 13 著者の連絡先 ........................................ 16 14 完全な著作権表記 .................................... 17 1 はじめに Session Initiation Protocol (SIP) (RFC 3261 [1])は、ユーザー間の コミュニケーションセッションを開始・管理するクライアント-サーバー プロトコルである。SIPのエンドシステムは、ユーザーエージェントと 呼ばれ、中間エレメントはプロキシサーバーとして知られている。典型的な SIPの仕様、SIPの「台形(trapezoid)」と呼ばれるものは、図1で示される。 この図では、ドメインAの発呼側(UA1)は、ドメインBのJoe(joe@B)へ通話しよ うとしている。そのために、UA1は自分のドメイン(ドメインA)にあるプロキシ 1へ通信する。プロキシ1は、着呼側パーティーのドメイン(ドメインB)のプロ キシ、プロキシ2へリクエストを転送(forward)する。プロキシ2は呼を着呼側 パーティーのUA2へ転送する。 このコールフローの一環として、プロキシ1はドメインBのSIPサーバーを決め る必要がある。このために、SRV[2]とNAPTR[3]のレコードを使用して、 プロキシ1はDNS処理を利用する。このドキュメントは、SIPが解決の助けに するDNSを使用する問題について記載し、解決方法を提供する。 2 DNSが解決する必要のある問題 DNSは、｢はじめに｣に記載されている一般的なコールフローの2つの側面を解決 する助けが必要である。1つ目は、呼をjoe@Bへ転送(forward)するために、プロ キシ1がドメインBにあるSIPサーバーを見つけることである。2つめは、リクエ ストの転送(forward)後に転送(forward)が失敗したときに、プロキシ2がプロキ シ1のためにバックアップを識別することである。 1つめの側面では、プロキシ1は具体的にドメインBにあるサーバーに対して IPアドレス、ポート、トランスポートプロトコルを決定する必要がある。 トランスポートプロトコルの選択は特に注目に値する。他の多くのプロトコル と違い、SIPはTCP、UDP、SCTPを含む様々なトランスポートプロトコル上で稼 動できる。SIPはTLSも使用できる。どの信頼性のあるトランスポート上でも、 その瞬間は単にTCPである。したがって、クライアントは自動的にどのトラン スポートプロトコルが利用できるかを決定できる必要がある。リクエストを送 信するプロキシは、対応する特定のトランスポートプロトコルのセットと、そ れらのトランスポートプロトコルを使用する際のプリファレンスを持っている。 プロキシ2は自分自身の対応トランスポートプロトコルと、それらのトランス ポートプロトコルの相対的なプリファレンスを持っている。すべてのプロキシ は、能力の共通部分(intersection)が常にあるように、TCP上のTLSとともに、 UDPとTCPの両方を実装しなければならない。DNS処理のある方式では、ドメイ ンBのSIPサービスに対して、使用できるトランスポートプロトコルと、トラン スポートプロトコルの相対的なプリファレンスを、プロキシ1が発見する必要 がある。プロキシ1は対応トランスポートのリストとプロキシ2のリストとの共 通部分を見つけ、それからプロキシ2が優先するプロトコルを選択する。 Rosenberg & Schulzrinne Standards Track [Page 2] RFC 3263 SIP: Locating SIP Servers June 2002 ............................ .............................. . . . . . +-------+ . . +-------+ . . | | . . | | . . | プロ |------------- | プロ | . . | キシ1 | . . | キシ2 | . . | | . . | | . . / +-------+ . . +-------+ \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . +-------+ . . +-------+ . . | | . . | | . . | | . . | | . . | UA 1 | . . | UA 2 | . . | | . . | | . . +-------+ . . +-------+ . . ドメイン A . . ドメイン B . ............................ .............................. 図 1: SIPの台形 DNSのルックアップは、1通話の処理を通して複数回使用される可能性に注意す ることは重要である。一般に、リクエストを送信したいエレメント(クライア ントと呼ばれる)は、サーバーと呼ばれる(プロキシまたはユーザーエージェン トの可能性がある)ネクストホップのエレメントのIPアドレス、ポート、トラ ンスポートプロトコルを決定するためにDNS処理を実行する必要があるかもし れない。 このような処理は原則的にエレメント間のすべてのホップで発生しうる。 SIPは相互通信サービスの確立に使用されるので、発呼側と着呼側パーティー の間のトランザクションを完了するのにかかる時間は重要である。一般に、発 呼側が呼を初期化するときから、着呼側パーティーがアラートされるまでの時 間は、2、3秒ほどであるべきである。もし複数ホップの可能性があり、他の潜 在的で時間の集中する操作に加えて各々がDNSのルックアップをしているとす ると、各ホップでDNSのルックアップに利用できる時間の量は、限られる。 スケーラビリティと高い利便性はSIPにおいてで重要である。SIPサービスは クラスタリングの技術を通して拡張する。一般に、図1の現実的なネットワー クでは、プロキシ2は均一に設定されたプロキシのクラスタでありうる。能力 ベースのロードバランスについてそのままのレベルを提供するために、 Rosenberg & Schulzrinne Standards Track [Page 3] RFC 3263 SIP: Locating SIP Servers June 2002 ドメインBが優先順位とウエイト持ったサーバー群のセットを設定する能力を、 DNSは提供する必要がある。 SIPは、アップストリームエレメント持つことで、失敗を検知するのに高い利 便性を持っている。例えば、プロキシが2つのプロキシ、プロキシ2.1、プロキ シ2.2のクラスタとして実装されていると仮定する。プロキシ1がプロキシ2.1 にリクエストを送信し、そのリクエストが失敗すると、プロキシ1はプロキシ 2.2へ再試行する。多くの場合、プロキシ1は最終的に通信するのがどのドメイ ンかは知らない。その情報は、そのドメインで実際にユーザーが別のユーザー に発呼したのであれば、わかる。プロキシ1は通話が完了した後にそのドメイ ンと再度通信しないかもしれない。プロキシ1は数分のうちに数千の異なるド メインと通信するかもしれない。また、プロキシ2は数分のうちに数千の異な るドメインからリクエストを受けるかもしれない。この｢多対多｣関係と、1組 のドメイン間の通信に長い間隔のある可能性のために、エレメントが通信する プロキシに対して動的な利便性のステートを維持するのは一般的に不可能であ る。プロキシがあるドメインとの最初の呼を取得したとき、プロキシはそのド メインのサーバーを何らかの順序で利用できるものを見つけるまで試す。利用 可能なサーバーの身元は、続く呼のコールセットアップの時間を減らすために 理想的にはすこしの間、キャッシュされる。クライアントはいつまた利用でき るようになるか決めるために、失敗したサーバーを連続して問い合わせられな い。というのも、これはスケールしないし、さらに、利便性のステートは、オ ンラインに戻ったときに再生したエレメントへのロードを再配分するために最 終的に流されなければならないからである。 エレメントがトランザクションの途中で失敗する可能性がある。例えば、 プロキシ2がリクエストをUA2へ転送した後、プロキシ1が失敗した場合。UA2は プロキシ2へ応答を送信する。プロキシ2は、もう利用できないプロキシ1へ 転送しようとする。どのDNSが必要かという｢はじめに｣にあるフローの2つめの 側面は、プロキシ2が、応答を送信できるプロキシ1のバックアップを識別する ことである。この問題は他のトランザクションのプロトコルにあるものよりも、 SIPにおいてはより現実的である。その理由は、応答を生成するには、しばしば 人の手が必要なので、あるSIP応答は生成されるまでに長い時間かかる可能性が あるためである。従って、通話のリクエストとその受け入れまでに数十秒経過 するのはまれなことではない。 Rosenberg & Schulzrinne Standards Track [Page 4] RFC 3263 SIP: Locating SIP Servers June 2002 3 述語規則 このドキュメントでは、キーワード｢MUST｣、｢MUST NOT｣、｢REQUIRED｣、 ｢SHALL｣、｢SHALL NOT｣、｢SHOULD｣、｢SHOULD NOT｣、｢RECOMMENDED｣、 ｢MAY｣、｢OPTIONAL｣はRFC2119[4]に記載されているように解釈される べきであり、対応するSIPの実装のための必要レベルを示す。 4 クライアントの用法 DNSの使用方法は、クライアントとサーバーでは異なる。このセクションでは クライアントの用法を議論する。ここでは、クライアントはステートフル (ユーザーエージェントクライアント(UAC)とステートフルプロキシの両方) とみなす。ステートレスプロキシはセクション4.4で議論される。 ここでの処理は、クライアントがリクエストをSIPまたはSIPS(secure SIP) URIで識別されるリソースへ送信する必要があるときに呼び出される。この URIは、リクエストが対象とされていた目的のリソースを識別できる(この 場合、URIはRequest-URIにある)。または、URIはそのリソースに向きの 中間ホップを識別できる(この場合、URIはRouteヘッダにある)。ここで 定義される処理は、このURIに何も影響は与えず(例えば、URIはDNSルック アップの結果で書き替えられない)、単にリクエストが送信されたIPアド レス、ポート、トランスポートプロトコルという結果になるだけである。 RFC3261[1]は、リクエストが送信される必要のあるホストを決めるDNSで、 どのURIが解決される必要があるかを決める上でのガイドラインを提供する。 ある場合では、[1]でも書かれているように、リクエストはSIP URIで識別され ず、ホスト名や数値のIPアドレスによって特定の中間プロキシへ送信される可 能性がある。その場合、一時URIが、この仕様の目的で、構築される。その URIは、書式 sip:からなり、そのは、ネクストホップのプロキ シのFQDNまたは数値のIPアドレスである。結果として、すべての場合において、 問題は要するに、DNSがIPアドレス、ポート、リクエストが送信されるべきホ ストのトランスポートを決定する上でのSIPまたはSIPS URIの名前解決という ことである。 ここでの処理は、1トランザクションにつき1度だけ実行されなければなら ない[MUST]。トランザクションは[1]で定義されている通りである。つまり、 SIPサーバーが接続に一度成功すると(成功は下で定義されている)、すべて のSIPリクエストと非2xxのSIP応答に対するACKの再送は同じホストに送信 されなければならないということである[MUST]。さらに、あるSIPリクエス トに対するCANCELは、SIPリクエストが配信された同じSIPサーバーへ送信 されなければならない[MUST]。 INVITEへの2xx応答に対するACKリクエストは、別のトランザクションを 構成するため、元のリクエストを受信した同じサーバーへ配信される 必要はない(実際、サーバーがrecord-routeしなければ、ACKを取得 しない)。 Rosenberg & Schulzrinne Standards Track [Page 5] RFC 3263 SIP: Locating SIP Servers June 2002 ここでは、TARGETを、もしあればURIのmaddrパラメータ値として、 なければ、URIのホストポートのコンポーネントのホスト値として 定義する。それは、接続されるべきドメインを識別する。SIPと SIPS URIの記述とこれらのパラメータの定義は[1]にある。 ここでは、セクション4.1と4.2で、TARGETの適切なインスタンスの トランスポートプロトコル、ポート、IPアドレスを定義する。 4.1 トランスポートプロトコルの選択 まず、クライアントはトランスポートプロトコルを選択する。 URIがトランスポートパラメータにトランスポートプロトコルを指定している 場合、そのトランスポートプロトコルが使用されるべきである[SHOULD]。 一方、トランスポートプロトコルが指定されていない場合で、TARGETが数値の IPアドレスの場合、クライアントはSIP URIに対してUDPを使用すべきである [SHOULD]。同様に、トランスポートプロトコルが指定されていない場合で、 TARGETが数値ではなく、明示的なポートが提示されている場合、クライアント は、SIP URIにはUDP、SIPS URIにはTCPを使用すべきである[SHOULD]。これは、 UDPがRFC2543[6]において唯一必須のトランスポートだっ たためであり、従っ て、SIP URIの相互運用性を保証するただひとつのものなのである。UDPはまた、 SIP URIにトランスポートが提示されていない場合、RFC2543においてデフォル トトランスポートとして指定されていた。しかし、SIPのガイドラインが特定 のリクエストに対して必須とする場合は、TCPのような別のトランスポートが 使用されてもよい[MAY]。それは、例えば、パスのMTUを越えるリクエストケー スがある。 また、トランスポートプロトコルもポートも指定されていない場合で、ターゲ ットが数値のIPアドレスではない場合、クライアントはNAPTRクエリーをURIの ドメインに対して実行すべきである[SHOULD]。トランスポートプロトコルの選 択のタスクに関係があるサービスは、「SIP+D2X」や「SIPS+D2X」の値の NAPTRサービスフィールドを持っている。この X は、ドメインがサポートして いるトランスポートプロトコルに該当する文字である。この仕様は、UDPには D2Uを、TCPにはD2Tを、SCTPにはD2Sを定義する。ここでは、また、トランスポ ートプロトコルマッピングに名前を付けるNAPTRサービスのためにIANA登録を 確立する。 これらのNAPTRのレコードは、ドメインからSRVのレコードまで、NAPTRサービ スフィールドで特定のトランスポートプロトコルを持つサーバーに接続する ために、マッピングを提供する。リソースレコードは空の正規表現と置換値 を含む。これは、特定のトランスポートプロトコルのためのSRVレコードであ る。サーバーが複数トランスポートに対応する場合、各々異なるサービス値 を持つ複数のNAPTRレコードがあるだろう。RFC2915 [5]のように、クライア ントは、サービスフィールドを適用できないすべてのレコードを破棄する。 この仕様の用途で、いくつかのルールが定義される。まず、SIPS URIを名前 解決するクライアントは、サービスフィールドのプロトコルとして、SIPSを 含まないすべてのサービスを破棄しなければならない[MUST]。 Rosenberg & Schulzrinne Standards Track [Page 6] RFC 3263 SIP: Locating SIP Servers June 2002 だが、逆は真ではない。SIP URIを名前解決するクライアントはプロトコルと してSIPSを持つレコードを保持すべきである[SHOULD]。次に、クライアントは 値が「D2X」以外のレゾリューションサービスを識別するサービスフィールド を破棄しなければならない[MUST]。RFC2915で書かれているNAPTR処理は、クラ イアントが対応している最もサーバーに好まれるトランスポートプロトコルを 見つけるという結果になり、これはサーバーに対するSRVレコードと同様であ る。クライアントは、また、TLSが利用可能かどうかと、その使用のプリファ レンスを見い出すことができる。 一例として、sip:user@example.comを解決したいと思っているクライアント を挙げる。クライアントはそのドメインに対してNAPTRクエリーを実行し、 以下のNAPTRレコードが見つかる。 ; order pref flags service regexp replacement IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com. これは、サーバーがTCP上のTLS、TCP、UDPにこのプリファレンスで対応してい ることを示す。クライアントはTCPとUDPに対応しているので、TCPが使用され、 _sip._tcp.example.comのSRVルックアップで決定されたホストにターゲットさ れる。そのルックアップは以下のように返す。 ;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com SIPプロキシまたはリダイレクトサーバー、登録サーバーがNAPTRレコードのル ックアップによって接続されるのであれば、少なくとも3つのレコード、 「SIP+D2T」サービスフィールドを持つもの、「SIP+D2U」サービスフィールド を持つもの、「SIPS+D2T」サービスフィールドを持つものがなければならない [MUST]。サービスフィールドにプロトコルとしてSIPSを持つレコードは(例え ば、より低い値の順序付けのフィールドを持つものでも)、サービスフィール ドにプロトコルとしてSIPを持つレコードよりも優先されるべきである [SHOULD]。「SIPS+D2U」サービスフィールドを持つレコードは、DNSに置くべ きではない[SHOULD NOT]。なぜなら、UDP上のTLSを使用するのは不可能なため である。 NAPTR置換フィールドにあるドメインサフィックスは、元のクエリーのドメイ ン (例えば、上のexample.com)と一致する必要はない。しかし、RFC2543との 下位互換性のために、たとえNAPTRレコードが異なるドメインにあっても、 ドメインは、元のクエリーのドメインについてSRVレコードを保持しなければ ならない。一例を挙げると、TCPに対するSRVレコードが_sip._tcp.school.edu でも、_sip._tcp.example.comにもSRVレコードが存在するべきである[MUST]。 Rosenberg & Schulzrinne Standards Track [Page 7] RFC 3263 SIP: Locating SIP Servers June 2002 RFC2543は、ドメインについてSRVレコードを直接ルックアップする。 NAPTR置換が異なるドメインを指すことでこれらが存在しない場合は、 クライアントは失敗する。 SIPSプロトコルフィールドを持つNAPTRレコードにとって、(サーバーがサイ ト認証を使用する場合、)クエリーのドメイン名と置換フィールドのドメイン 名は、どちらもTLS交換でサーバーに渡されたサイト認証に基づいて、有効 でなければならない[MUST]。同様に、SRVクエリーのドメイン名はSRVレコー ドにあるターゲットのドメイン名は同じサイト認証に基づいてどちらも有効 でなければならない[MUST]。そうでなければ、アタッカーは異なるドメインに ある置換値を含むDNSレコードを変更するかもしれない。また、クライアント は、これが目的の動作なのか、攻撃の結果なのか、どちらが正当かを判断で きないかもしれない。 NAPTRレコードが見つからない場合、クライアントは対応するトランスポート プロトコルのためのSRVクエリーを構築し、そしてそれぞれのクエリーを構築 する。クエリーは、SIP URIの「_sip」、SIPS URIの「_sips」というサービス 識別子を使って実行される。クエリーが成功すると、特定のトランスポートが 対応される。クライアントは、サーバーが対応するもので、望みのトランスポ ートプロトコルのどれを使用してよい[MAY]。 これはRFC2543から変わっている。RFC2543はクライアントは対応するすべ てのトランスポートに対してルックアップし、これらのレコードで優先度 をマージし、それから、最も望ましいレコードを選択する、と指定して いる。 SRVレコードが見つからない場合、クライアントは、SIPS URIにはTCP、 SIP URIにはUDPを使用すべきである[SHOULD]。しかし、SIPのガイドラインが 特定のリクエストに対して必須とする場合は、TCPのような別のトランスポー トが使用されてもよい[MAY]。それは、例えば、パスのMTUを越えるリクエス トケースがある。 4.2 ポートとIPアドレスの決定 トランスポートプロトコルが決定された後は、次のステップはIPアドレスと ポートの決定である。 TARGETが数値のIPアドレスの場合、クライアントはそのアドレスを使用する。 URIがポートを含む場合、そのポートを使用する。ポートが指定されていない 場合は、そのトランスポートプロトコルのデフォルトポートを使用する。 TARGESが数値のIPアドレスではなく、ポートがURIに提示されている場合は、 クライアントはドメイン名のAまたはAAAAレコードのルックアップを実行する。 結果はIPアドレスのリストになるだろう。そして、各IPアドレスは、URIの特 定のポートとすでに決まっているトランスポートプロトコルを使って接続す ることができる。 Rosenberg & Schulzrinne Standards Track [Page 8] RFC 3263 SIP: Locating SIP Servers June 2002 クライアントは最初のレコードを試行すべきである[SHOULD]。試行が失敗し たら、セクション4.3にある失敗の定義に基づいて、次のレコードを試行し、 それが失敗した場合はまた次を試行、と続けるべきである[SHOULD]。 これはRFC2543からの変更である。以前はポートが明示的で5060の値を 持つ場合は、SRVレコードが使用された。現在は、AまたはAAAAレコードが 使用される。 TARGETが数値のIPアドレスではなく、ポートがURIに提示されていない場合、 クライアントは、セクション4.1のNAPTR処理が実行されていれば、そこから 返されたレコード上でSRVクエリーを実行する。そうでない場合は、トランス ポートが明示的に指定されているので、クライアントは、SIPS URIのサービ ス識別子「_sips」を使用し、特定のトランスポートに対して、SRVクエリー を実行する。SIP URIにとって、クライアントがTLSを使用したい場合、 トランスポートを指定するためにサービス識別子「_sips」または「_sip」 も使用する。NAPTR処理がNAPTRレコードが見つからないために実行されず、 対応トランスポートプロトコルに対するSRVクエリーが成功した場合は、 それらのSRVレコードは選択される。SRVレコードがどのように決定されるか にかかわらず、RFC2782の「Usage rules」セクションで書かれている通りに 従い、このドキュメントのセクション4.3の追加の処理によって補強される。 SRVレコードが見つかった場合、クライアントはドメイン名のAまたはAAAA レコードのルックアップを実行する。結果はIPアドレスのリストになるだろ う。そして、各IPアドレスは、すでに決まっているトランスポートプロトコ ルを使い、そのトランスポートのデフォルトのポートで、接続することがで きるだろう。AまたはAAAAレコードがルックアップされるとすぐに、前述の ように明示的なポートへ処理は進むだろう。 4.3 RFC2782処理の詳細 RFC2782では、SRVレコードのセットがどのようにソートされ、試行されるか について詳細に記載している。だが、そこでは、失敗時に何が起こるかにつ いて何も詳細は提示されず、クライアントは「(プロトコル、アドレス、サー ビスへ)接続を試行」すべきだとしか書いていない。それらの詳細について は、ここでSIPに対して記載される。 SIPリクエストでは、トランザクション層が503エラー応答や、何かのトラン スポートの失敗(一般に、UDPでの致命的なICMPエラーやTCPでの接続失敗のた めに)を報告した場合に、失敗が発生する。暫定も最終も(例えばRFC3261[1]の timer Bやtimer F)何も応答を受け取らないうちにトランザクション層がタイ ムアウトした場合にも、失敗は発生する。失敗が発生した場合は、クライア ントは、前のものと同一で、前のものと異なるViaのブランチID値を持つ Rosenberg & Schulzrinne Standards Track [Page 9] RFC 3263 SIP: Locating SIP Servers June 2002 新規のリクエストを生成すべきである[SHOULD](これによってSIPが新規のSIP トランザクションを構築する)。そのリクエストはRFC2782によって規定され るリストにある次のエレメントへ送信される。 4.4 ステートレスプロキシの考慮 前セクションの処理は非常にステートフルである。サーバーが接続に成功する と、トランザクションに対するすべてのリクエスト再送は、非2xx最終応答に 対するACKやトランザクションに対するCANCELリクエストと同様に、同じサー バーへ行かなければならない[MUST]。 接続が成功したサーバーの身元はトランザクションステートの書式である。こ れはステートレスプロキシについての難関である。ステートレスプロキシはす べてのリクエストをトランザクション内で同じサーバーへ送信する必要条件を 満たさなければならないからである。 この問題は、DNSのランダム化に基づいて異なるサーバーへのルートを取る クッキーセッション内でHTTPトランザクションの問題と似ているが、異なる。 そちらでは、このような配信は問題はでない。サーバーのファームは一般に 共通のバックエンドデータ保存を持ち、そこにはセッションデータが保存さ れている。ファーム内のサーバーがいつHTTPリクエストを受信しても、セッ ション識別子があれば、サーバーはそれを取得し、リクエストを処理する ために必要なステートを抽出する。セッション識別子がないリクエストは、 新規のセッションを生成する。ステートレスプロキシの問題はより低層に ある。というのも、それは、複数のサーバーに広まったかもしれないトラ ンザクション内で再送されたリクエストだからである。これらの再送は、 どれも「セッション識別子」(SIP用語における完全なダイアログ識別子) を持たないので、新規のダイアログが個々のサーバーに同様に生成される。 これによって、例えば、同じ電話に複数の電話の呼が実行されるという結果に なるかもしれない。そのため、このようなことがまず発生しないようにするこ とは、非常に重要である。 サーバーに接続を試行する際に失敗が発生しないという単純なケースに出会う 必要要件は難しいことではない。ステートレスプロキシは、リクエストを受信 すると常に、適切なDNSクエリーを前述したように実行する。だが、RFC2782の 処理は確定的であるとは保証されていない。これは、同じ重要度を持つレコー ドは特別な順序がないためである。ステートレスプロキシは、自身の自由にな るアルゴリズムを何か使用して、このケースのレコードに確定的な順序を定義 しなければならない[MUST]。提案のひとつは、アルファベット順にすることで あり、もっと一般的には、ASCII互換のエンコードでソートすることである。 処理をステートレスプロキシにとってより簡易にするために、ドメインの管理 者がSRVレコードについて同じ重要度を異なるものへ重み付けをし(例えば、2 つのサーバーが同じであれば、両方を1000とアサインするのではなく、1000と 1001の重み付けを使用する)、NAPTRレコードにも同様にすることを推奨する [RECOMMENDED]。 最初のサーバーが接続に成功すると、そのプロキシはステートレスのままで Rosenberg & Schulzrinne Standards Track [Page 10] RFC 3263 SIP: Locating SIP Servers June 2002 いられる。だが、最初のサーバーが接続に失敗して、次のはサーバーが成功 すると、そのプロキシはこのトランザクション中はストーとレスではいられ ない。ステートレスなら、失敗したサーバーが再送の間に復活した場合、 異なるサーバーへの再送は非常にうまくいく。従って、プロキシは最初の サーバーへの接続が成功しないときは常に、ステートフルプロキシとして 動作すべきである[SHOULD]。 不運なことに、前述の推奨に従ったとしても、まだ、ステートレスプロキシ が異なるサーバーに再送を配信することは可能なのである。これは、DNSの TTLがトランザクションの最中に期限切れになり、エントリーが変わった場合 に起こる可能性がある。これは防ぐことができない。ネットワークの実装者 はこの制限に注意すべきであり、このエラーが致命的だと思われるなら、DNS にアクセスするステートレスプロキシを使用しないようにすべきである。 5 サーバーの用法 RFC3261[1]はサーバーからクライアントへ応答を返す処理を定義している。 一般的に、ユニキャストのUDPリクエストに対しては、応答は、Viaヘッダー に含まれるポートを使用して、リクエストを送信したソースIPアドレスへ返 される。信頼性のあるトランスポートプロトコルでは、応答はリクエストが 届いた接続上で送信される。だが、リクエスト送信と応答受信の間でクライ アントのエレメントが失敗したとき、フェイルオーバーの対応を提供する ことは重要である。 サーバーは、RFC3261[1]によると、接続が到着したところへ応答を送信し(信 頼性のあるトランスポートプロトコルの場合)、信頼性のないトランスポート プロトコルの場合は、リクエストのViaヘッダーフィールドにあるソースアド レス、ポートへ送信する。ここでの処理は、サーバーがその場所とその応答の 失敗(具体的なの条件はRFC3261に詳述されている)を送信しようとするときに 呼び出される。「失敗」は、リクエストが入ってきたトランスポート接続が応 答が送信できる前に締め切られること、またはトランスポート層からの致命的 なエラーの通信として定義される。 これらの場合、サーバーはViaヘッダーの先頭にある sent-by構文の値を 検討する。それが数値のIPアドレスを含む場合は、サーバーは、Viaヘッダー のトランスポートプロトコルとsent-byのポートがあればそれを使用して、 なければトランスポートプロトコルのデフォルトを使用して、そのアドレス に応答を送信しようと試みる。Viaヘッダーのトランスポートプロトコルは 「TLS」を指定できる。それは、TCP上のTLSを指す。この値が提示されたと きは、サーバーは応答を送信するときにTCP上のTLSを使用しなければならな い[MUST]。 Rosenberg & Schulzrinne Standards Track [Page 11] RFC 3263 SIP: Locating SIP Servers June 2002 だが、sent-byフィールドがドメイン名とポート番号を含む場合、サーバーは AまたはAAAAレコードをその名前で問い合わせる。IPアドレスの一覧結果上で、 ViaのポートとViaのトランスポートプロトコルを使用し(先ほどと同様に、 TLSの値はTCP上のTLSを指す)、各エレメントに応答を送信しようと試みる。 クライアント処理にあるように、リストの次のエントリは、1つ前が失敗に 終わった場合に試行される。 一方、sent-byフィールドがドメイン名を含むがポートを含まない場合、サー バーは、Viaのトランスポートが「TLS」の場合はサービス識別子の「_sips」、 そうでなければ「_sip」、またViaヘッダーの先頭のトランスポートを使用し て、そのドメイン名でSVRレコードを問い合わせる(「TLS」はSRVクエリーにお けるトランスポートプロトコルはTCPであると意味する)。結果のリストは[2] で書かれているとおりにソートされ、応答は、そこに記載されている新規リス ト上の先頭のエレメントへ送信される。それが失敗に終わると、リストの次の エントリーが試行される。 6 SIP URIの構築 多くの場合、REGISTERのContactヘッダーや、INVITEのRecord-Routeヘッダー を含め、エレメントはSIP URIを構築する必要がある。RFC3261[1]によると、 これらのURIは、そのURIを挿入した特定のエレメントを解決する特徴を持って いなければならない。だが、以下の例の用に、URIがIPアドレスだけで構築さ れていた場合、 sip:1.2.3.4 エレメントは失敗するだろう。バックアップを通してリクエストや応答を ルートする方法がないのだから。 SRVはこれを確定する方法を提供する。IPアドレスを使う代わりに、SRVレ コードに解決されるドメイン名が使用されうる。 sip:server23.provider.com 優先順のフィールド(優先的に選択されるものを示す)について低い値を持つ1 個のレコードがあるので、特定のターゲットに対するSRVレコードが確立され る。また、このレコードはURIを構築したエレメントを指し示す。だが、優先 順のフィールドで、失敗時に使用されるバックアップエレメントを示す、より 高い値を持つ別のレコードがある。このことによって、健全な操作を許容する 一方で、RFC3261[1]の制限が兼ね備わることになる。 Rosenberg & Schulzrinne Standards Track [Page 12] RFC 3263 SIP: Locating SIP Servers June 2002 7 セキュリティの考慮 DNS NAPTRレコードは、クライアントがサーバーがTLSに対応しているとわか るようになるために使用される。TLSが使用可能で優先されていて、安全では ないトランスポートを使用するクライアントの場合、アタッカーはこれらの レコードを修正するかもしれない。 これは、常にTLS上でのみ送信されるSIPS URIスキームの提示によって、部分 的に緩和されている。アタッカーはDNSレコードの削除や変更によって、優先 順位を下げる[訳注: bid down]ように強要はできない。最悪のケースでは、彼 らがすべてのレコードを削除することによって発生することで、通信できなく なることである。SIPS URI自体は一般にセキュアなコンテキスト、しばしばビ ジネスカードやセキュアなWebページといった中や、またはTLSですでにセキュ アな状態になつているSIPメッセージで、交換される。詳しくはRFC3261[1]を 参照のこと。そのため、セキュリティが本当に必要な場合に、SIPS URIが好ま れる。だが、TLSがまったくないよりもましなセキュリティをSIP URIが許容す ることで解決されたリクエストに対して、TLSが使用されることは許容する。 優先順下げの攻撃は、キャッシュを通しても緩和される可能性がある。同じ ドメインによく接続するクライアントは、NAPTRレコードがservicesフィール ドにSIPSを含む含まないにかかわらず、キャッシュすべきである[SHOULD]。 このようなレコードが提示された場合で、より後のクエリーが提示された 場合を除くと、それは潜在的な攻撃の兆候である。この場合、クライアント は警告や警報のたぐいのものを生成すべきであり[SHOULD]、リクエストを 拒否してもよい[MAY]。 別の問題は、システムのユーザー間で仲介者のプロキシが、しばしば、NAPTR クエリーを実行するクライアントであるということだ。そのため、プロキシは SIPSのエントリーが提示されていても無視し、セキュリティを格下げする結果 になる可能性がある。このような攻撃を防ぐためにできることは非常に少ない。 クライアントは、通話の完了のためにプロキシサーバーにまったく依存してお り、セキュリティが提供されるためにプロトコルを正しく実装していると信頼 しなければならない。プロキシサーバーが侵入を要求し、格下の扱いに近いほ ど大幅に低く見られる妥協や命令のために、電信のトラフィックを改ざんして (DNSSECがないばあい)、DNSレコードを偽造することは可能である。 8 トランスポート決定アプリケーション このセクションでは、ガイドの[7]にあるように、動的な委任発見システム (Dynamic Delegation Discovery System / DDDS)のフレームワークを使用し て、より正式に、この仕様でのNAPTRの用法を定義する。DDDSは、NAPTR レコードを特定の解決サービスに利用できるアプリケーションを定義する。 このアプリケーションは、トランスポート決定アプリケーション(Transport Determination Application)と呼ばれ、その目的は、URIを操作できる様々な サーバーのためのSRVレコードのセットに対して入ってくるSIPまたはSIPS URIをマップすることである。 Rosenberg & Schulzrinne Standards Track [Page 13] RFC 3263 SIP: Locating SIP Servers June 2002 以下は、DDDSがアプリケーションに提供を求める情報である。 アプリケーションユニークストリング(Application Unique String): アプリケーションユニークストリング(AUS)は、解決サービスへの入力 である。このアプリケーションでは、URIを解決する。 既知の第一ルール(First Well Known Rule): 既知の第一ルールはAUSか らキーを抽出する。このアプリケーションでは既知の第一ルールは SIPまたはSIP URIのホストの一部を抽出する。 有効なデータベース(Valid Databases): 既知の第一ルールの結果のキーは 1個のデータベース、DNSでルックアップされる[8]。 期待される出力(Expected Output): アプリケーションの結果は、サー バーが接続するSRVレコードである。 9 IANAの考慮 ここで書かれているNAPTRレコードの用法は、SIPに対応される各トランスポー トのためのサービスフィールドの既知の値を必要とする。サービスフィールド の値からトランスポートプロトコルまでのマッピングテーブルはIANAによって 維持される。RFC2434[5]に記載されている通り、テーブルの新しいエントリー はスタンダードトラックのRFCの発行で追加されてもよい[MAY]。 RFCへの登録は、以下の情報を含まなければならない[MUST]。 サービスフィールド(Service Field): サービスフィールドの登録。 新しい架空のトランスポートプロトコル、NCTPを例に取ると、 「SIP+D2N」となるだろう。 プロトコル(Protocol): サービスフィールドに関連する特定のトランス ポートプロトコル。これには、トランスポートプロトコルを解説する ドキュメントへの参照とともに、プロトコルの名称と略称を含まなけ ればならない[MUST]。例えば、「New Connectionless Transport Protocol (NCTP), RFC 5766」のように。 名前と接続情報(Name and Contact Information): 登録を実行する人の 名前、アドレス、emailアドレス、電話番号 以下の値は登録に配置されなければならない。 Servicesフィールド プロトコル SIP+D2T TCP SIPS+D2T TCP SIP+D2U UDP SIP+D2S SCTP (RFC 2960) Rosenberg & Schulzrinne Standards Track [Page 14] RFC 3263 SIP: Locating SIP Servers June 2002 10 謝辞 Randy Bush、Leslie Daigle、Patrik Faltstrom、Jo Hornsby、Rohan Mahy、 Allison Mankin、Michael Mealling、Thomas Narten、Jon Petersonへ、 有益なコメントをいただいたことに感謝したい。 11 規範的な参考文献 [1] 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. [2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for Specifying the Location of Services (DNS SRV)", RFC 2782, February 2000. [3] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000. [4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 12 有益な参考文献 [6] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Standard", Work in Progress. [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database", Work in Progress. Rosenberg & Schulzrinne Standards Track [Page 15] RFC 3263 SIP: Locating SIP Servers June 2002 13 著者の連絡先 Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 EMail: jdrosen@dynamicsoft.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 EMail: schulzrinne@cs.columbia.edu Rosenberg & Schulzrinne Standards Track [Page 16] RFC 3263 SIP: Locating SIP Servers June 2002 14 完全な著作権表記 Copyright (c) The Internet Society (2002). All Rights Reserved. 本記述とその翻訳は複写し他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布す ることができる。しかし、この文書自体にはいかなる方法にせよ、著作権表 示やインターネットソサエティもしくは他のインターネット関連団体への参 照を取り除くなどの変更を加えてはならない。インターネット標準を開発す るために必要な場合は例外とされるが、その場合はインターネット標準化過 程で定義されている著作権のための手続きに従わなければならない。またRFC を英語以外の言語に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネットソサエティも しくはその継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ トソサエティおよびIETFは、この情報がいかなる権利も侵害していないとい う保証、商用利用および特定目的への適合性への保証を含め、また、これら だけに限らずすべての保証について、明示的もしくは暗黙的の保証は行われ ない。 謝辞 RFC編集者の職務のための資金は、現在、インターネットソサエティによって 提供されている。 --------------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただし、 この権利の設定は原文から新たな翻訳を作成し公開することを妨げるものではあり ません。本翻訳物は、本著作権表示を含めて改変しないことを条件に再配布を許可 します。翻訳の正確さについては一切保証しません。原文とあわせてご利用くだ さい。 2003年 --------------------------------------------------------------------------- Rosenberg & Schulzrinne Standards Track [Page 17]