Network Working Group O. Levin Request for Comments: 4488 Microsoft Corporation Category: Standards Track May 2006 セッション開始プロトコル(SIP) REFERメソッドの暗黙的サブスクリプションの抑制 Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription 本文書の位置付け 本文書は、インターネットコミュニティのためのインターネット標準化過程 プロトコルを規定し、改善のための議論や提案を依頼するものである。標準 化の段階や、プロトコルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。本文書の配信は無 制限である。 著作権表記 Copyright (C) The Internet Society (2006). 概要 RFC 3515に定義されているセッション開始プロトコル(Session Initiation Protocol / SIP) REFER拡張は、一般的に、受信者のステータスについて REFERリクエストの送信パーティに通知するために使用される、短期のイベ ントサブスクリプションを自動的に確立する。こうした通知は、どのような 状況でも必要とは限らない。本仕様は、REFERリクエストに含めることができ る新しいSIP拡張ヘッダーフィールドを使用して、イベントサブスクリプショ ンの自動確立と以降の通知を回避する方法を提供する。 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. 動機 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. 定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. REFERリクエストの分岐の回避 . . . . . . . . . . . . . . . . . . 4 6. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 6 9. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . 7 10.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . 7 Levin Standards Track [Page 1] RFC 4488 SIP REFER without Subscription May 2006 1. はじめに REFER仕様[3]では、どのREFERでも、REFER発行者(REFER-Issuer)とREFER受信 者(REFER- Recipient)間に暗黙的サブスクリプションが作成されると規定し ている。 本文書は、REFERトランザクション内でのみ意味がある新しいSIPヘッダー フィールド「Refer-Sub」を定義する。このヘッダーフィールドを「false」 に設定すると、REFER発行者が、暗黙的サブスクリプションとその結果のダ イアログを確立しないことをREFER受信者に要求することを示す。 本文書は新しいオプションタグ「norefersub」を定義する。このタグを Supportedヘッダーフィールドに含めると、ユーザーエージェント(User Agent / UA)がREFER受信者として動作する場合に、暗黙的サブスクリプショ ンを作成することなく、REFERリクエストを受け入れることができることを 示す。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119 [1]の記載に従って解 釈されるべきである。 REFERメソッドとその拡張の議論を簡略化するために、本文書では以下の3つ の用語を使用する。 o REFER発行者(REFER-Issuer)： REFERリクエストを発行するUA o REFER受信者(REFER-Recipient)： REFERリクエストを受信するUA o REFERターゲット(REFER-Target): Refer-Toの統合リソース識別子 (Uniform Resource Identifier / URI)に指定されるUA 3. 動機 REFER仕様では、どのREFERでも、REFER発行者(REFER-Issuer)とREFER受信者 (REFER- Recipient)間に暗黙的サブスクリプションが作成されることを必須 としている。このサブスクリプションの結果、REFER受信者からREFER発行者 に1つ以上のNOTIFYが送信される。REFER受信者は、このNOTIFYを含む暗黙的 サブスクリプションをキャンセルすることができる。REFER発行者は、最初 のNOTIFYの受信後に、明示的なSUBSCRIBE (Expires: 0)でこの暗黙的サブス クリプションをキャンセルすることができる。 暗黙的サブスクリプションと最初のNOTIFYを必須とする目的の1つは、REFER リクエストが分岐し、分岐したREFERの結果として確立する可能性がある複数 のダイアログをREFER発行者が確認する方法が必要な状況を考慮するためで ある。これは、SUBSCRIBE [4]リクエストの分岐を処理する場合に使用する Levin Standards Track [Page 2] RFC 4488 SIP REFER without Subscription May 2006 アプローチと同じである。分岐が発生しないことをREFER発行者が明示的に 指定する場合、暗黙的サブスクリプションを確立する要件は不要である。 NOTIFYのもう1つの目的は、REFER受信者のREFERに起因するSIPトランザク ションの進行状況について、REFER発行者に通知することである。要求された 操作の進行状況についてREFER発行者がすでに意識している場合(REFER受信者 のダイアログイベントパッケージに対する明示的なサブスクリプションを REFER発行者が持っている場合など)、暗黙的サブスクリプションとそのREFER に関連する結果のNOTIFYトラフィックは、不要なネットワークオーバーヘッ ドを生成する可能性がある。 4. 定義 本文書は新規のSIPヘッダーフィールドである「Refer-Sub」を定義する。こ のヘッダーフィールドに意味があり、使用してもよい[MAY]のは、REFERリク エストと対応する2xx応答とともに使用する場合のみである。このヘッダー フィールドを「false」に設定すると、REFER発行者が、暗黙的なサブスクリ プションとその結果のダイアログを確立しないことをREFER受信者に要求する ことを示す。この拡張を使用する場合、REFERはターゲット更新リクエストの ままであることに注意(この拡張を使用しない、というデフォルトの場合)。 本文書では、[2]の表2に以下のエントリを追加する。この表への追加は、本 文書の発行時点の拡張メソッドにも反映される。これは読者のために提供さ れているものであり、規範とはならない。 Header field where proxy ACK BYE CAN INV OPT REG MSG Refer-Sub R, 2xx - - - - - - - Header field where SUB NOT REF INF UPD PRA PUB Refer-Sub R, 2xx - - o - - - - Refer-Subヘッダーフィールドは、エンドツーエンドの暗号の一部として暗 号化してもよい[MAY]。 ヘッダーフィールドの構文は以下に定義するBNFに従う。 Refer-Sub = "Refer-Sub" HCOLON refer-sub-value *(SEMI exten) refer-sub-value = "true" / "false" exten = generic-param このgeneric-paramの構文は[2]に定義されている。 Levin Standards Track [Page 3] RFC 4488 SIP REFER without Subscription May 2006 「false」に設定した「Refer-Sub」ヘッダーフィールドをREFER発行者が使用 してもよい[MAY]のは、REFERリクエストが分岐されないことをREFER発行者が 確信できる場合のみである。 REFER受信者がこの拡張をサポートし、暗黙的サブスクリプションを確立する ことなくREFERトランザクションを処理する意思がある場合、「false」に設 定した「Refer-Sub」ヘッダーフィールドを、REFER発行者に対する2xx応答に 挿入しなければならない[MUST]。この場合、暗黙的サブスクリプションは作 成されない。結果として、REFERが既存のダイアログ外で発行された場合、 新しいダイアログは作成されない。 REFER発行者が「false」に設定した「Refer-Sub」ヘッダーフィールドを挿入 しても、REFER受信者がその提案を受け入れない場合(つまり、「Refer-Sub」 ヘッダーフィールドを含めない場合、または「true」に設定した 「Refer-Sub」ヘッダーフィールドを2xxに含める場合)、暗黙的サブスクリ プションはデフォルトのケースと同様に作成される。 本文書は新しいオプションタグ「norefersub」も定義する。このタグを Supportedヘッダーフィールドに含めると、ユーザーエージェント(User Agent / UA)がREFER受信者として動作する場合に、暗黙的なサブスクリプ ションを作成することなく、REFERリクエストを受け入れることができるこ とを示す。 ダイアログを開始するリクエストまたは応答のSupportedヘッダーフィール ドにこのオプションタグが存在することから、REFER発行者はREFER受信者の 能力を知ることができる。能力を知るためのもう1つの方法として、[6]など に定義されているプレゼンスを使用する方法がある。 ただし、REFER受信者の能力が不明な場合、Requireヘッダーフィールドに 「norefersub」タグを使用することは推奨されない[NOT RECOMMENDED]。こ れは、REFER受信者がこの拡張をサポートしていない場合、通常のREFERに戻 すために、REFER発行者が新しいREFERトランザクションを発行し、結果とし て追加の往復処理が必要になるためである。 [2]のセクション8.2.2.3に記載されているように、REFER受信者は、この拡 張をサポートしていない場合、Require: norefersubヘッダーフィールドを 含むREFERリクエストを420 (Bad Extension)応答で拒否する。 Require: norefersubはRefer-Sub: falseヘッダーフィールドとともに提示 される可能性があることに注意。 5. REFERリクエストの分岐の回避 REFER仕様では、既存のダイアログ外でREFERリクエストの分岐が送信される 可能性が許容されている。さらに、プロキシは不明なメソッドタイプを分岐 する可能性がある。分岐が発生した場合でも、分岐プロキシから1つの2xx応 答しか転送されないため、「Refer-Sub」を含むREFERの送信者は分岐を認識 しない。結果として、分岐が発生しないことを確定する責任は、 「Refer-Sub」を含むREFERの発行者である。 Levin Standards Track [Page 4] RFC 4488 SIP REFER without Subscription May 2006 あるRequest-URIに対するREFERリクエストが分岐した可能性がある場合、 REFER発行者は「Refer-Sub」ヘッダーフィールドを含めるべきではない [SHOULD NOT]。REFER発行者は、REFERリクエストが分岐しないことを確保す るために、標準的なメカニズムを使用すべきである[SHOULD]。他のメカニズ ムがない場合、REFERリクエストのRequest-URIには、[5]の定義に従って、 グローバルにルーティング可能なユーザーエージェントURI (Globally Routable User Agent URI / GRUU)を含むべきである[SHOULD]。これは、 GRUUの特性によってリクエストが分岐しないことを確保できるためである。 6. 例 暗黙的サブスクリプションを抑制するREFERの例を以下に示す。SIP Torture Test Messages [7]で使用される条項(特にタグ)が再利用され ることに注意。 REFER sip:pc-b@example.com SIP/2.0 Via: SIP/2.0/TCP issuer.example.com;branch=z9hG4bK-a-1 From: ;tag=1a To: sip:b@example.com;opaque=urn:uuid:f8 1d4fae-7dec-11d0-a765-00a0c91e6bf6;grid=99a Call-ID: 1@issuer.example.com CSeq: 234234 REFER Max-Forwards: 70 Refer-To: Refer-Sub: false Supported: norefersub Contact: sip:a@issuer.example.com Content-Length: 0 7. IANA条項 本文書は新規のSIPヘッダーフィールドである「Refer-Sub」を登録する。こ のヘッダーフィールドに意味があるのは、RFC 3515 [3]に定義されるREFER リクエストと、対応する応答の場合のみである。「SIP Parameters Registry」の「SIP Header field」の下位登録に以下の情報が追加された。 o ヘッダー名: Refer-Sub o 短縮形： なし o 参考文献： RFC 4488 また、本文書は新規のSIPオプションタグ「norefersub」を登録し、「SIP Parameters Registry」の「SIP Option Tags」の下位登録に追加された。RFC 3261 [2]の規定に従って、登録の必須情報を以下に示す。 Levin Standards Track [Page 5] RFC 4488 SIP REFER without Subscription May 2006 o 名前: norefersub o 説明： このオプションタグは、(RFC 3515 [3]に定義されているデフォル トのケースと比較して)暗黙的サブスクリプションを確立することなく、 ユーザーがREFERリクエストを受け入れることができる能力を示す。 8. セキュリティの考慮事項 このSIP拡張の目的は、REFER受信者の予想される動作を変更することであ る。動作の変更は、REFER受信者がダイアログを確立しないこと、および REFER発行者に対してNOTIFYリクエストを送信しないことである。したがっ て、「false」に設定した「Refer-Sub」ヘッダーフィールドを不正に含め ると、受信側の処理と状態の要件が減る。結果として、DoS攻撃の使用は限 定されていると考えられる。 一方、「false」に設定した「Refer-Sub」ヘッダーフィールドを送信するこ とで、man-in-the-middle (MitM)攻撃によって、REFER発行者が通知するこ となくREFER受信者からの通知を(傍受より)簡単に抑制するメカニズムが利 用される可能性がある。また、「false」に設定した「Refer-Sub」ヘッダー フィールドを削除することで、MitMによって、REFER受信者が、暗黙的なダイ アログ上で(本来であればREFER発行者が抑制した)通知を生成する可能性が ある。 このような種類のMitM攻撃から保護するために、完全性の保護を使用すべき である。たとえば、REFER発行者は、このような種類の攻撃から保護するた めに、RFC 3261 [2]の説明に従ってS/MIMEを使用することができる。 9. 謝辞 SIPコミュニティは、「Suppressing Refer Implicit Subscription」(2002 年10月)で初めて提示されたSriram Parameswar氏のアイデアに感謝を述べ たい。このアイデアは本仕様の基礎として利用した。 Levin Standards Track [Page 6] RFC 4488 SIP REFER without Subscription May 2006 10. 参考文献 10.1. 規範となる参考文献 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. 10.2. Informative References [5] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, October 2005. [6] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Work in Progress, January 2006. [7] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006. 著者の連絡先 Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: 425-722-2225 EMail: oritl@microsoft.com Levin Standards Track [Page 7] RFC 4488 SIP REFER without Subscription May 2006 完全な著作権表記 Copyright (C) The Internet Society (2006). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿 者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イン ターネット協会およびIETFは、この情報がいかなる権利も侵害していないと いう保証、商用利用および特定目的への適合性への保証を含め、また、これ らだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行わ れない。 知的所有権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79 に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセ ンスの保証すべて、またはこのような所有権の使用に関して、本仕様の実装 者またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につ いては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能 である。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情報 は、IETF (ietf-ipr@ietf.org)宛てに送信していただきたい。 謝辞 RFC編集職務のための資金は、IETF Administrative Support Activity (IASA)によって提供されている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2008年 ----------------------------------------------------------------------- Levin Standards Track [Page 8]