Network Working Group D. Willis Request for Comments: 3608 dynamicsoft Inc. Category: Standards Track B. Hoeneisen Switch October 2003 登録時のサービスルート検出のための セッション開始プロトコル(SIP)拡張ヘッダーフィールド Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2003). All Rights Reserved. 概要 本文書は、REGISTERリクエストへの応答と同時に使用される、セッション開始 プロトコル(Session Initiation Protocol/SIP)拡張ヘッダーフィールドを定 義して、レジストラが登録ユーザーエージェント(UA)にサービスルートを通知 できるメカニズムを実現する。UAは、このサービスルートを使用して、レジス トラドメインから外部のサービスをリクエストすることができる。 目次 1. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. メカニズムに関する議論 . . . . . . . . . . . . . . . . . . . 4 4. 適用性証明 . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. 構文 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. 用法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. UAでの手順 . . . . . . . . . . . . . . . . . . . . . . 6 6.2. プロキシでの手順 . . . . . . . . . . . . . . . . . . . 7 6.3. レジストラでの手順 . . . . . . . . . . . . . . . . . . 8 6.4. 使用例 . . . . . . . . . . . . . . . . . . . . . . . . 9 6.4.1. REGISTERトランザクションにおけるメカニズムの例. 9 6.4.2. INVITEトランザクションにおけるメカニズムの例 . 12 7. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . 14 8. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . . . 15 10. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . . . 15 Willis & Hoeneisen Standards Track [Page 1] RFC 3608 SIP Extension for Service Route Discovery October 2003 11. 知的所有権表記 . . . . . . . . . . . . . . . . . . . . . . . 16 12. 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . 16 13. 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . 17 1. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119[1]のBCP 14に記載さ れるとおりに解釈されるべきである。 2. 背景 第3世代パートナーシッププロジェクト(Third Generation Partnership Project/3GPP)は、SIPの登録時にホームプロキシを検出する要件を確立し、 [6]でその要件を公表した。3GPPネットワークは、動的にホームサービスプロ キシを各Addresses-of-Record(AOR)に割り当てる。この割り当ては、 Addresses-of-Recordに登録がないときにコールサービスをサポートする必要 があるときに、REGISTER操作と連動して発生するか、または帯域外で発生する 可能性がある。このホームサービスプロキシは、受信(UAによる中止)と送信 (UAによる開始)のサービスの両方を提供する可能性がある。 受信の場合、受信SIPリクエストのRequest-URI(Uniform Resource Identifier)は、ホームサービスプロキシと関連付けられているユーザーの Addresses-of-Recordと一致する。(ほとんどの場合、)ホームサービスプロキ シは、そのAORの登録済みコンタクトアドレスに対してリクエストを転送す る。ホームサービスプロキシと登録済みUAの間で、必要なプロキシを横断する メカニズムは、[4]で説明されている。 送信(UAによる開始)セッションの場合は、別の問題がある。特に、「使用する サービスプロキシをUAが知る方法、およびそのプロキシに到達する方法」であ る。 メーリングリストの議論で、次のようにいくつかのメカニズムが提案された。 1. UAの設定データ。この方法では、UA設定の管理と更新という問題が生じ た。特に、プロキシの割り当てが非常に動的な場合(ロードバランスの場合 など)である。 2. ホームネットワークの設定サーバーから設定データを取得するときに、他 の何らかのプロトコル(HTTPなど)を使用する方法。このソリューションは 機能するが、別のプロトコルエンジン、ファイアウォールの複雑さ、操作 のオーバーヘッド、および「無線の(over the air)」大量トラフィックが 新たに必要になる。 3. 何らかの3Gネットワークの受信リクエストについて処理するときに、ホー ムネットワークの参照テーブルを使用する方法。これは、データベース操 作の点で、比較的高いオーバーヘッドがある。 Willis & Hoeneisen Standards Track [Page 2] RFC 3608 SIP Extension for Service Route Discovery October 2003 4. 新しいコンタクトでサーバープロキシを示す302応答を返すことで、302 (ostensibly the UA)を処理するアップストリームのノードは、サービスプ ロキシにリクエストを再送信する方法。この方法は、前の案のデータベー ス操作が共通しているが、明示的に302応答のキャッシュを許容しているた め、データベース操作の頻度や回数を低く抑えることができる。 5. UAと関連するレジストラ間のREGISTERトランザクションで、Record-Route と同等の操作を実行してから、UAでそのルートを格納し、そのUAから開始 される将来的なリクエストで、格納したルートをサービスルートとして再 利用する方法。この方法は効率的だが、プロキシ操作のサービスルート が、REGISTERメッセージで使用するルートと合致する、という制約があ る。 6. REGISTER応答のヘッダーフィールド値としてサービスルート情報を返す方 法。前の案と似ているが、この方法では、サービスルートを構築するとき に、ホームネットワークのトポロジに関する情報を選択的に適用する機能 を、レジストラに認めている。 本文書では、「REGISTER応答のヘッダーフィールドとしてサービスルート情報 を返す方法」という最終案を定義する。この新しいヘッダーフィールドは、 「ロード済みルート(preloaded route)」を示す。これは、応答を生成するレ ジストラに関連付けられているプロキシネットワークに対して、UAがサービス をリクエストする場合に使用を希望するルートである。 シナリオ UA1----P1-----| |--R-------| | | | P2---| DBMS | | | UA2-----------| |--HSP-----| このシナリオでは、ルーティングプロキシP2、レジストラR、ホームサービス プロキシHSP、RとHSPの両方が使用するデータベースDBMSを含む「ホームネッ トワーク」がある。P2は、SIPの観点から見るとホームネットワークの「エッ ジ」であり、「エッジプロキシ」と呼ばれることがある。UA1は、プロキシP1 の背後にいる外部のUAである。UA1は、DHCP(Dynamic Host Configuration Protocol)経由でP1を検出する(これは単に一例であり、DHCP以外のメカニズム も可能である)。UA2は、インターネット上にある別のUAであり、デフォルトの アウトバウンドプロキシを使用していない。この図ではDNS (Domain Name System)要素を示していないが、議論上では、その合理的な可用性を前提とす ることが予想される。UA1の使命は、UA1からの送信リクエストをHSP経由で ルーティングし、HSPからの送信サービスを受信できるように、HSPを検出する ことである。 Willis & Hoeneisen Standards Track [Page 3] RFC 3608 SIP Extension for Service Route Discovery October 2003 3. メカニズムに関する議論 UAは、最初のリクエストにRouteヘッダーフィールドを含めて、強制的に1つ以 上のプロキシを経由して(おそらくサービスも受ける)もよい。このようなルー ト(「サービスルートまたはロード済みルート」)を使用することで、UAは、特 定のホームプロキシまたはプロキシのネットワークのサービスをリクエストす ることができる。未解決の問題は、「UAは、どのサービスルートを使用すべき かについて、どのように検出するか」ということである。 本文書では、「Service-Route」というヘッダーフィールドを定義する。この ヘッダーフィールドにはルートのベクトルを含めることができる。このベクト ルは、前述のように使用されると、特定シーケンスのプロキシを経由するよう にリクエストの方向を指定することができる。レジストラは、Service-Route ヘッダーフィールドを使用して、UAにサービスルートを通知してもよい。この サービスルートは、UAが使用すると、レジストラと関連付けられている1つの プロキシまた複数プロキシのセットからのサービスが提供される。Service- Routeヘッダーフィールドは、REGISTERリクエストに対する応答でレジストラ が含めてもよい。結果的に、UAを登録することで、登録したシステムのサービ スをリクエストするときに使用できるサービスルートを知ることになる。 Service-Routeメカニズムで確立したルーティングは、ユーザーエージェント が開始するリクエストにのみ適用される。つまり、UAが開始したリクエストに のみ適用されるのであって、そのUAが終了するリクエストには適用されない。 簡単に言うと、レジストラは、登録するUAのサービスルートを生成し、成功し た各REGISTERリクエストに対する応答で、そのサービスルートを返すのであ る。このサービスルートの形式は、登録するUAが、レジストラによって選択さ れるサービスプロキシ経由でリクエストを送信するときに使用できるRoute ヘッダーフィールドの形式である。UAは、このルートを使用する場合、サービ スプロキシ経由でルーティングする目的で、ロード済みRouteヘッダーフィー ルドとしてこのルートをUAが開始するリクエストに挿入する。 レジストラがヘッダーフィールド値を構築するメカニズムは、ローカルの実装 に固有のものであり、本文書の範囲外である。 4. 適用性証明 Service-Routeメカニズムは、以下の場合に適用可能である。 1. UAがレジストラに登録する。 2. レジストラは、UAがレジストラのドメインのサービスをリクエストしたと きに、UAが使用するサービスプロキシのことを認識している。認識する方 法は、動的な割り当てによる場合、または本文書の範囲外である何らかの メカニズムの場合が考えられる。 Willis & Hoeneisen Standards Track [Page 4] RFC 3608 SIP Extension for Service Route Discovery October 2003 3. レジストラが、適切なサービスルートを構築するために必要なネットワー クトポロジ、ポリシー、状況を認識している。 4. レジストラが構築したサービスルートは、1つのAddresses-of-Recordと関 連付けられるすべてのコンタクトで同一である。このメカニズムでは、コ ンタクト固有のサービスルートを規定しない。 5. UAに対してサービスルートを提案するその他のメカニズムは、使用環境に よって、利用できない場合や不適切な場合がある。 UAにサービスルートを通知するには、他の方法も利用できる可能性がある。こ のような代替的な方法は、本文書の範囲外である。登録時にサービスルートを 割り当てる理由、またはその割り当ての適切なタイミングの議論については、 本文書の範囲外である。 5. 構文 Service-Routeヘッダーフィールドの構文は以下の通り。 Service-Route = "Service-Route" HCOLON sr-value *( COMMA sr-value) sr-value = name-addr *( SEMI rr-param ) Service-Routeヘッダーフィールド値は、[3]で定義されているRoute要素の構 文に準拠しなければならない[MUST]ということに注意。[3]で提案されている ように、[3]に完全に準拠するには、ルースルーティングのインジケータパラ メータである「;lr」をヘッダーフィールド値に含めなければならない [MUST]。 ヘッダーフィールドの許容用途は、[3]の表2と3に記述されている。Service- Routeに対応し、この表に追記した。 SIPの表3へのService-Routeの追加: Header field where proxy ACK BYE CAN INV OPT REG PRA _______________________________________________________________ Service-Route 2xx ar - - - - - o - Willis & Hoeneisen Standards Track [Page 5] RFC 3608 SIP Extension for Service Route Discovery October 2003 6. 用法 6.1. UAでの手順 UAは通常どおりに登録を実行する。REGISTERの応答には、Service-Routeヘッ ダーフィールドが含まれる場合がある。含まれる場合、UAは、コンタクトを登 録したREGISTERトランザクションのAddresses-of-Recordと関連付けて、 Service-Routeヘッダーフィールドの値を格納してもよい[MAY]。UAが複数の Addresses-of-Recordをサポートする場合、複数のサービスルート(個々の Addresses-of-Recordごとに1つ)を格納することができる。UAが登録を更新す ると、Service-Routeの格納値は、最新の200クラス応答のService-Routeヘッ ダーフィールドに従って更新される。応答にService-Routeヘッダーフィール ドがない場合、UAは、以前に格納したそのAddresses-of-Recordのサービス ルートをすべて消去する。再登録リクエストが拒否された場合、または既存の 登録が期限切れになってUAが再登録を選択しなかった場合、UAは、その Addresses-of-Recordの格納済みサービスルートを破棄すべきである [SHOULD]。 UAは、認知しているサービスルートの特定Addresses-of-Recordと関連付けら れる、将来的なリクエストについて、サービスルートの使用を選択してもよい [MAY]。この場合、最初の送信リクエストで、Service-Routeヘッダーフィール ドのコンテンツをロード済みRouteヘッダーフィールドとして使用する。複数 のService-Routeヘッダーフィールドまたはヘッダーフィールド値がある場 合、UAはその順序を保存しなければならない[MUST]。 ルースルートは、興味深い方法でルーティングポリシーと相互作用することが ある。サービスルートセットを、ローカルで必要なデフォルトルートやローカ ルポリシーと統合する具体的な方法については、実装の問題である。たとえ ば、ローカルで設定した明示的ルースルーティングを使用して、次ホップのプ ロキシに到達するデバイスや、デフォルトのアウトバウンドプロキシのルー ティング規則を使用するデバイスがある。ただし、最終的に機能するために、 その組み合わせで、ローカル環境に有効なルーティングを実現しなければなら ない[MUST]。一般的に、アクセスプロキシチェーンを出る(egress)必要がある ローカル設定のルートへ、サービスルートセットを追加する。システム設計者 は、機能するシステムにするために、ノードのサービスルーティングポリシー と、基本的なSIPのルーティングポリシーとを一致させなければならない。 6.2. プロキシでの手順 一般的に、中間プロキシは、Service-Routeヘッダーフィールドを他の未知の ヘッダーフィールドと同様に扱う。プロキシは単に送信先へ転送するのみであ る。通常どおり、ダイアログ内のその後のリクエストが経由する必要がある中 間プロキシは、Record-Routeする可能性がある、ということに注意。プロキシ は、Service-Routeヘッダーフィールドにそのプロキシが含まれているという 理由だけで、ダイアログ内のその後のリクエストで経由されると仮定すべきで はない。 Willis & Hoeneisen Standards Track [Page 6] RFC 3608 SIP Extension for Service Route Discovery October 2003 REGISTER応答を処理するプロキシは、Service-Routeヘッダーフィールドの ルートセットに自身を追加してもよいかどうかという問題がある。追加するこ とで、サービスルートを動的に構築することができるが、2つの重大な問題が ある。1つ目の問題は、レジストラから見た場合の透過性である。中間プロキ シは、レジストラの認知または同意なしで自身を追加することができる。2つ 目の問題は、エンドツーエンドのセキュリティとの相互作用である。レジスト ラがS/MIME技術を使用してREGISTER応答を保護する場合、UAにとって、このよ うな追加は、応答で「man in the middle」による改ざんがあったと見なされ る可能性がある。結果的に、中間プロキシは、REGISTER応答のService-Route 値を変更すべきではない[SHOULD NOT]。また、変更する場合、UAに対して変更 を受け入れるように要求してはならない[MUST NOT]。 プロキシが「デュアルホーム(dual homed)」の場合、別の考慮事項がある。つ まり、2つの(またはさらに多い)異なるネットワークに接続されていること で、リクエストは一方のネットワークインターフェースで受信され、別のネッ トワークインターフェースでプロキシされる。複数のホームを実装するプロキ シは、[3]に記載されているとおりに、送信インターフェースでリクエストを Record-Routeする。この応答を処理するときに、リクエストをプロキシしたイ ンターフェースを示すRecord-Routeヘッダーフィールド値を、応答をプロキシ するインターフェースを示す新しい値で置換する。結果的に、ユーザーエー ジェントサーバー(UAS)側から見たルートベクトルは、ユーザーエージェント クライアント(UAC)側から見たルートベクトルの正反対にはならない。これ自 体は無害だが、その後に使用するサービスルートを決定するときに、記録済み ルートのベクトル(または[4]の記録済みPathベクトル)を使用するノードの問 題が複雑になる。 プロキシで、Record-RouteまたはPathヘッダーフィールド値を挿入する Service-Routeを使用する場合、[3]の手順に従う代わりに、リクエストを処理 するときに1つではなく2つのルート値を記録すべきである[SHOULD]。最初に記 録される値は受信インターフェースを示し、2つ目は送信インターフェースを 示す。応答を処理するときに、記録済みルートの変更は必要ない。この最適化 によって、サービスルートの構築で実質的に使用できる、正反対のルートが実 現する。 6.3. レジストラでの手順 レジストラは、正常なREGISTERリクエストを受信したときに、200クラス応答 で1つ以上のService-Routeヘッダーフィールドを返すことを選択してもよい [MAY]。Service-Routeヘッダーフィールドを200クラス応答に含めるかどう か、および挿入する値の判断は、ローカルポリシーの問題であり、本文書の範 囲外である。 Willis & Hoeneisen Standards Track [Page 7] RFC 3608 SIP Extension for Service Route Discovery October 2003 レジストラは、1つ以上のService-Routeヘッダーフィールドを挿入し、標準的 な手順に従って、200クラス応答をUAに返す。 バインディングのフェッチ(Fetching Bindings)を実行するREGISTER操作(つま り、Contactヘッダーフィールドがリクエストに存在しない)では、該当する Addresses-of-Recordに対応するREGISTER応答で返されたのと同じ値を、 Service-Route値として返すべきである[SHOULD]。レジストラは、場合によっ て、Service-Routeを格納するのではなく、動的に計算してもよい。バイン ディングのフェッチ操作の際に、このルートを再計算すべきかどうかの判断 は、実装に委ねられる。 注意: バインディングのフェッチ操作は、UAが損失したService-Route値を復 元するために使用する可能性がある。または、このような状況のUAは単 に再REGISTERすることもできる。 ネットワークトポロジによっては、ホームサービスプロキシの前に、特定のプ ロキシ(ファイアウォールプロキシなど)を経由することを必須にしてもよい [MAY]。したがって、ネットワークトポロジを具体的に認識しているレジスト ラであれば、複数のService-Routeヘッダーフィールドまたは要素を200クラス 応答で返してもよい[MAY]。順序はトップダウンで指定する(つまり、最初の Service-Routeエントリを最初に経由する)。このような構成は、実装独自のも のであり、本文書の範囲外である。 一般的に、Service-Routeヘッダーフィールドには、レジストラおよびホーム サービスプロキシの管理ドメイン内の要素への参照が含まれる。たとえば、 ユーザーが「ホーム」ネットワークを離れて、「訪問先」ネットワークにロー ミングした場合があるとする。レジストラは、訪問先ネットワークのトポロジ を認識していると想定できないため、返すService-Routeに、ホームネット ワーク内の要素のみを含める。 挿入したService-Route要素は、[3]で定義されているRoute要素の構文に準拠 しなければならない[MUST]ということに注意。[3]で提案されているように、 [3]に完全に準拠するには、ルースルーティングのインジケータパラメータで ある「;lr」を含めなければならない[MUST]。 Willis & Hoeneisen Standards Track [Page 8] RFC 3608 SIP Extension for Service Route Discovery October 2003 6.4. 使用例 ここでは、本文書の「背景」セクションで示したシナリオの場合について例を 示す。同じネットワーク図を以下にコピーする。 シナリオ UA1----P1-----| |--R-------| | | | P2---| DBMS | | | UA2-----------| |--HSP-----| 6.4.1. REGISTERトランザクションにおけるメカニズムの例 この例では、レジストラRを使用して、HOME.EXAMPLE.COMへ登録しているユー ザーエージェントUA1のメッセージシーケンスを示す。Rが返すService-Route には、UA1が、HOME.EXAMPLE.COMから送信されるサービスを受信するときに、 ホームサービスプロキシHSP.HOME.EXAMPLE.COMを使用できる、ということが示 される。 例を短くし、読みやすくするために、一部のヘッダーフィールド(Content- Lengthなど)やセッション記述は省略されていることに注意。 Service-Routeを返すREGISTERのメッセージシーケンス: F1 Register UA1 -> P1 REGISTER sip:HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer From: Lawyer ;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: . . . Willis & Hoeneisen Standards Track [Page 9] RFC 3608 SIP Extension for Service Route Discovery October 2003 F2 Register P1 -> P2 REGISTER sip:HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer From: Lawyer ;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: . . . F3 Register P2 -> R REGISTER sip:HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKvE0R2l07o2b6T Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer From: Lawyer ;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: . . . F4 RがREGISTERを実行 R Stores: For Contact: F5 RがService Routeを計算 この例では、HSPをサービスルートとして参照できるように、Rが厳密に設定され る。また、Rは、P2がプロバイダのエッジプロキシとして使用されていることも 知っている。そのため、以下のようになる。 Service-Route: , Willis & Hoeneisen Standards Track [Page 10] RFC 3608 SIP Extension for Service Route Discovery October 2003 F6 REGISTER応答 r -> P2 SIP/2.0 200 OK Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKvE0R2l07o2b6T Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer ;tag=87654 From: Lawyer ;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Service-Route: , . . . F7 REGISTER応答 P2 -> P1 SIP/2.0 200 OK Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKlJuB1mcr Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer ;tag=87654 From: Lawyer ;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Service-Route: , . . . F8 REGISTER応答 P1 -> UA1 SIP/2.0 200 OK Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKcR1ntRAp To: Lawyer ;tag=87654 From: Lawyer ;tag=981211 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Service-Route: , . . . F9 UA1はサービスルートをUA1@HOME.EXAMPLE.COMに格納する Willis & Hoeneisen Standards Track [Page 11] RFC 3608 SIP Extension for Service Route Discovery October 2003 6.4.2. INVITEトランザクションにおけるメカニズムの例 この例では、HOME.EXAMPLE.COMから送信されるサービスを使用して、UA1から 最終的にUA2に到達するINVITEトランザクションのメッセージシーケンスを示 す。UA1はHOME.EXAMPLE.COMに登録済みであり、HSP.HOME.EXAMPLE.COM経由で サービスルートが通知されている。HOME.EXAMPLE.COMが提供しているサービス は、「ログ」サービスであり、UA1が使用した通話記録を提供する(おそらく、 UA1のユーザーは、顧客への通話費用を請求する弁護士か何かである)。 この例のUA1とUA2は、同じネットワーク(HOME.EXAMPLE.COM)に登録済みと仮定 されていることに注意。一般的に、ここで説明しているサービスルートメカニ ズムを使用するときに、このような条件は必要ない。 Service-Routeを使用したINVITEのメッセージシーケンス: F1 INVITE UA1 -> P1 INVITE sip:UA2@HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7 To: Customer From: Lawyer ;tag=456248 Call-ID: 38615183343@s1i1l2j6u CSeq: 18 INVITE Contact: Route: , . . . 注意: P1は、UAの「アウトバウンドプロキシ」規則を使用して選択された。 F2 INVITE P1 -> P2 INVITE sip:UA2@HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7 To: Customer From: Lawyer ;tag=456248 Call-ID: 38615183343@s1i1l2j6u CSeq: 18 INVITE Contact: Record-Route: Route: , . . . Willis & Hoeneisen Standards Track [Page 12] RFC 3608 SIP Extension for Service Route Discovery October 2003 注意: P1は、自身をRecord-Routeに追加した。 F3 INVITE P2 -> HSP INVITE sip:UA2@HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7 To: Customer From: Lawyer ;tag=456248 Call-ID: 38615183343@s1i1l2j6u CSeq: 18 INVITE Contact: Record-Route: Record-Route: Route: . . . 注意: HSPは、HOME.EXAMPLE.COM内のHSPを検索するDNSを使用して選択された。 P2は、自身をRecord-Routeに追加した。 P2は、Routeから自身を削除した。 F4 HSPがサービスを実行する HSPは、UA1の格納済みプロファイルから、実行するサービスを特定する。この特 定方法は、本文書の範囲外である。この例の場合、HSPは、「Lawyer's log book (弁護士のログブック)」にレコードを書き込み、AOR「sip:UA2@HOME.EXAMPLE. COM」を検索し、UA2の現在のコンタクトが、UAADDR2.HOME.EXAMPLE.COMのホスト にあることを検出する。これは、次ホップのINVITEのRequest-URIになる。 F5 INVITE HSP -> P2 INVITE sip:UA2@UAADDR2.HOME.EXAMPLE.COM SIP/2.0 Via: SIP/2.0/USP HSP.HOME.EXAMPLE.COM:5060;branch=z9hG4bKHSP10120323 Via: SIP/2.0/UDP P2.HOME.EXAMPLE.COM:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP P1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP UADDR1.VISITED.EXAMPLE.ORG:5060;branch=z9hG4bKnashds7 To: Customer From: Lawyer ;tag=456248 Call-ID: 38615183343@s1i1l2j6u CSeq: 18 INVITE Contact: Record-Route: Record-Route: Record-Route: Willis & Hoeneisen Standards Track [Page 13] RFC 3608 SIP Extension for Service Route Discovery October 2003 . . . 注意: P2は、HSP上のアウトバウンドプロキシ規則によって選択された。 HSPは、Routeから自身を削除した。 INVITEは、通常どおり、UA2へ伝播する。 7. セキュリティの考慮事項 REGISTERトランザクションで、UAとレジストラの間にあるプロキシは、レジス トラから返されるService-Routeの値を変更すること、またはレジストラから 返されていない場合でもService-Routeを挿入することができる。このような 攻撃が発生すると、サービスルートを使用するUAによる以降のリクエストは、 通常は経由しないノードあてに(または経由で)配信される可能性がある。ま た、INVITEパス上のプロキシは、多彩な攻撃を実行することができる。そのた め、このような攻撃を防ぐには、sips:や他の利用できるメカニズムを使用し て、推移的な相互認証を適用するのが望ましい。 [3]で定義されている「sips:」URIでは、トランスポートレベルのメッセージ の完全性と相互認証をUAがリクエストできるメカニズムを定義している。プロ キシがメッセージを変更するときの要件はないため、S/MIMEで署名されたボ ディを使用すると、返り値のエンドツーエンドの保護を実現することができ る。 Service-Routeを使用するシステムは、ホップバイホップのメッセージ整合性 と相互認証を提供すべきである[SHOULD]。UAは、「sips:」URIを使用して、こ れをサポートするようにリクエストすべきである[SHOULD]。Service-Routeを 返すREGISTERは、S/MIMEを使用してエンドツーエンドの保護を実装しなければ ならない[MUST]。また、S/MIMEを使用してREGISTERの応答をすべて保護すべき である[SHOULD]。Service-Routeを受信するUAは、S/MIMEボディが付随してい る場合、それを認証すべきである[SHOULD]。 Willis & Hoeneisen Standards Track [Page 14] RFC 3608 SIP Extension for Service Route Discovery October 2003 8. IANA条項 本文書は、SIP拡張ヘッダーフィールド「Service-Route」を定義する。この ヘッダーフィールドは、[3]で定義されているSIPヘッダーフィールドの登録に 含まれている。SIPの変更処理として、[5]では、一般的なSIP拡張ヘッダー フィールドを標準化過程のRFCで定義することを必須としている。本文書は、 これに必要な定義を提供している。 Service-Routeヘッダーフィールドについての登録は以下の通り。 RFC番号: RFC 3608 ヘッダーフィールド名: Service-Route 短縮形: なし 9. 規範となる参考文献 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. [3] 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. [4] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. [5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002. 10. 有益な参考文献 [6] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", Work in Progress, October 2002. Willis & Hoeneisen Standards Track [Page 15] RFC 3608 SIP Extension for Service Route Discovery October 2003 11. 知的所有権表記 IETFは、知的所有権、あるいは本文書に記載される技術の実装または使用に関 して主張される可能性のある他のいかなる権利についても、有効期間または範 囲に関して、あるいはこのような権利下でどのようなライセンスの範囲までが 利用可能か否かに関して、何ら見解を持たない。また、このような権利を特定 しようともしていない。標準化過程および標準化関連の文書における権利につ いてIETFの手続き上の情報は、BCP-11を参照すること。こうした所有権につい て、本仕様の実装者あるいはユーザーが公開のために利用可能とされた権利請 求のコピー、および、利用可能とされたライセンスの保証、あるいは、一般的 なライセンスまたは許可を取得しようと試みた結果は、IETF事務局から入手で きる。 IETFは、この規格を実行するために必要とされる技術の範囲にある可能性があ る、すべての著作権、特許または特許アプリケーション、あるいは他の所有権 について、すべての関連団体に対して配慮するよう依頼している。これらの情 報については、IETFの事務局長への連絡を請う。 12. 著者の連絡先 Dean Willis dynamicsoft Inc. 3100 Independence Parkway #311-164 Plano, TX 75075 US Phone: +1 972 473 5455 EMail: dean.willis@softarmor.com Bernie Hoeneisen Switch Limmatquai 138 CH-8001 Zuerich Switzerland Phone: +41 1 268 1515 EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org URI: http://www.switch.ch/ Willis & Hoeneisen Standards Track [Page 16] RFC 3608 SIP Extension for Service Route Discovery October 2003 13. 完全な著作権表示 Copyright (C) The Internet Society (2003).All Rights Reserved. 本記述とその翻訳はコピーし他に提供することができる。また論評を加えた 派生的製品や、この文書を説明したり、その実装を補助するもので、上記の著 作権表示およびこの節を付加するものはすべて、全体であってもその一部で あっても、いっさいの制約を課されること無く、準備、複製、発表、配布する ことができる。しかし、この文書自体にはいかなる方法にせよ、著作権表示や インターネット協会もしくは他のインターネット関連団体への参照を取り除く などの変更を加えてはならない。インターネット標準を開発するために必要な 場合は例外とされるが、その場合はインターネット標準化過程で定義されてい る著作権のための手続きに従わなければならない。またRFCを英語以外の言語 に翻訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネット協会もしくはそ の継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ ト協会およびIETFは、この情報がいかなる権利も侵害していないという保証、 商用利用および特定目的への適合性への保証を含め、また、これらだけに限ら ずすべての保証について、明示的もしくは暗黙的の保証は行われない。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供されて いる。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Willis & Hoeneisen Standards Track [Page 17]