Network Working Group J. Rosenberg Request for Comments: 3857 dynamicsoft Category: Standards Track August 2004 セッション開始プロトコル(SIP)のための ウォッチャー情報のイベントテンプレートパッケージ A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP) 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するも のである。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 本文書は、セッション開始プロトコル(Session Initiation Protocol/SIP)イ ベントフレームワーク用にウォッチャー情報のテンプレートパッケージを定義 する。ウォッチャー情報とは、特定のイベントパッケージ内で、特定のリソー スにサブスクライブされた1組のユーザーを指す。ウォッチャー情報は、ユー ザーがサブスクライブするとき、サブスクライブ解除するとき、承認されると き、拒否されるときに、動的に変化する。ユーザーは、この情報にサブスクラ イブすることで、情報の変化について知る。このイベントパッケージは、任意 のイベントパッケージ(このイベントパッケージを含む)に適用できるため、テ ンプレートパッケージである。 Rosenberg Standards Track [Page 1] RFC 3857 Watcher Information August 2004 目次 1. はじめに ............................................ 2 2. 用語 ................................................ 3 3. 用法のシナリオ ...................................... 3 3.1. プレゼンスの認可 .............................. 4 3.2. ブラックリスト警告 ............................ 5 4. パッケージ定義 ...................................... 5 4.1. イベントパッケージ名 .......................... 5 4.2. イベントパッケージパラメータ .................. 5 4.3. SUBSCRIBEのボディ ............................. 6 4.4. サブスクリプションの有効期間 .................. 6 4.5. NOTIFYのボディ ................................ 7 4.6. SUBSCRIBEリクエストのノーティファイア処理 ..... 7 4.7. NOTIFYリクエストのノーティファイア生成 ........ 8 4.7.1. サブスクリプション状態マシン .......... 9 4.7.2. 状態マシンの適用 ...................... 11 4.8. NOTIFYリクエストのサブスクライバ処理 .......... 12 4.9. フォークされたリクエストの操作 ................ 12 4.10. 通知の頻度 .................................... 13 4.11. 状態エージェント .............................. 13 5. 使用例 .............................................. 14 6. セキュリティの考慮事項 .............................. 17 6.1. DoS攻撃 ....................................... 17 6.2. 機密情報の漏洩 ................................ 17 7. IANA条項 ............................................ 18 8. 謝辞 ................................................ 18 9. 規範となる参考文献 .................................. 18 10. 有益な参考文献 ...................................... 19 11. 著者の連絡先 ........................................ 19 12. 完全な著作権表示 .................................... 20 1. はじめに セッション開始プロトコル(Session Initiation Protocol/SIP)イベントフ レームワークは、RFC 3265[1]で説明されている。SIPイベントフレームワーク では、SIPシステムに関連するイベントのサブスクリプションと通知に関する 一般的な枠組みを定義している。この枠組みでは、SUBSCRIBEおよびNOTIFYメ ソッドを定義し、パッケージの概念を導入している。パッケージとは、イベン トの特定クラスに対する、イベントの枠組みを持つ具体的なアプリケーション である。パッケージは、たとえば、ユーザープレゼンス[5]のために定義され た。 本文書は、SIPイベントフレームワーク内で、「テンプレートパッケージ」を 定義する。テンプレートパッケージには、通常のSIPイベントパッケージのプ ロパティがすべて含まれている。ただし、このテンプレートパッケージは、常 に他のイベントパッケージに関連付けられるため、常に任意のイベントパッ ケージ(このテンプレートパッケージ自体を含む)に適用することができる。 Rosenberg Standards Track [Page 2] RFC 3857 Watcher Information August 2004 本文書で定義されるテンプレートパッケージは、ウォッチャー情報用であり、 トークン「winfo」という名称である。どのイベントパッケージ(プレゼンスな ど)の場合でも、サブスクリプションのセット(場合によっては空のセット)が 存在する。このサブスクリプションは、そのパッケージのリソースの状態を確 定しようとするユーザーによって、作成またはリクエストされたものである。 このサブスクリプションのセットは、時間が経つと、ユーザーがリクエストす る新規サブスクリプションによって変わり、古いサブスクリプションは期限切 れになり、サブスクリプションは、リソースの所有者によって承認または拒否 される。特定イベントパッケージの特定リソースにサブスクライブしたユー ザーのセットと、サブスクリプションの状態は、ウォッチャー情報と呼ばれ る。この状態自体が動的なため、状態の変更を知るには、状態にサブスクライ ブするのが適切である。ウォッチャー情報のイベントテンプレートパッケージ は、まさにこの点(他のパッケージのリソースに対するサブスクリプションの 状態を追跡)を容易にするためのものである。 このテンプレートパッケージを示すには、追跡対象である任意のパッケージ名 の後に「.winfo」を付けて名前を構築する。たとえば、プレゼンスにサブスク ライブされるユーザーのセットは、「presence.winfo」パッケージと定義され る。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119のBCP 14 [5]に記載さ れるとおりに解釈されるべきであり、CPL準拠の実装のための実装レベルを示 すものである。 本文書は、基本的に、サブスクリプションからサブスクリプションの再帰を扱 う。したがって、本文書では、「サブスクリプション」という用語自体が混 乱を招く可能性がある。混乱を軽減するために、「ウォッチャー情報のサブス クリプション(watcherinfo subscription)」は、ウォッチャー情報に対するサ ブスクリプションを指し、「ウォッチャー情報のサブスクライバ(watcherinfo subscriber)」は、ウォッチャー情報に対してサブスクライブしたユーザーを 指すこととする。「ウォッチャー情報通知(watcherinfo notification)」 は、ウォッチャー情報サブスクリプションの一部として送信されたNOTIFYリ クエストを指す。無条件で「サブスクリプション(subscription)」、「サブ スクライバ(subscriber)」、「通知(notification)」が使用される場合、そ れぞれ、「内部(inner)」のサブスクリプション、サブスクライバ、通知を指 す。これらは、ウォッチャー情報のサブスクリプションによって監視されて いる。また、「ウォッチャー(watcher)」は、「内部」のリソースに対するサ ブスクライバを指すときにも使用される。ウォッチャーに関する情報は、 ウォッチャー情報のサブスクリプションによって報告される。 3. 用法のシナリオ ウォッチャー情報テンプレートパッケージには、多くの適用方法がある。 Rosenberg Standards Track [Page 3] RFC 3857 Watcher Information August 2004 3.1. プレゼンスの認可 このテンプレートパッケージを適用する動機付けとなるものは、プレゼンスの 認可である。ユーザーAがユーザーBのプレゼンスにサブスクライブすると、そ のサブスクリプションは認可される必要がある。認可は、ユーザーが直接介入 して行う必要がある場合が多い。そうするには、Bのソフトウェアで、プレゼ ンスのサブスクリプションがリクエストされたことを認知する必要がある。こ れは、ウォッチャー情報によってサポートされる。Bのクライアントソフト ウェアは、以下のように、Bのプレゼンスのウォッチャー情報にSUBSCRIBEす る。 SUBSCRIBE sip:B@example.com SIP/2.0 Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7 From: sip:B@example.com;tag=123s8a To: sip:B@example.com Call-ID: 9987@pc34.example.com Max-Forwards: 70 CSeq: 9887 SUBSCRIBE Contact: sip:B@pc34.example.com Event: presence.winfo サーバーのポリシーでは、Bが自分のウォッチャー情報にサブスクライブする ことを許可している。そのため、AがBのプレゼンスにサブスクライブすると、 Bは、以下のようにウォッチャー情報の状態が変化した通知を受け取る。 NOTIFY sip:B@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna66g From: sip:B@example.com;tag=xyz887 To: sip:B@example.com;tag=123s8a Call-ID: 9987@pc34.example.com Max-Forwards: 70 CSeq: 1288 NOTIFY Contact: sip:B@server.example.com Event: presence.winfo Content-Type: application/watcherinfo+xml Content-Length: ... sip:A@example.com Rosenberg Standards Track [Page 4] RFC 3857 Watcher Information August 2004 これは、Bに対して、Aがサブスクライブしたことと、サブスクリプションが保 留中(つまり認可待ち)であることを示している。Bのソフトウェアは、サブス クリプションが認可待ち状態であることをBに警告できる。Bは、それを受け て、サブスクリプションのポリシーを設定する。 3.2. ブラックリスト警告 アプリケーションは、付加価値機能を提供する目的で、ウォッチャー情報にサ ブスクライブできる。アプリケーションの一例は、「ブラックリスト警告」で ある。このシナリオでは、アプリケーションサーバーが、既知の「悪者(bad guys)」の一覧を保持する。Joeというユーザーが、Webページにアクセスして 自分のプレゼンスURIを入力するなどの方法で、アプリケーションプロバイダ でサービスにサインアップする。アプリケーションサーバーは、Joeのプレゼ ンスに関するウォッチャー情報にサブスクライブする。何者かがJoeのユー ザープレゼンスにSUBSCRIBEを試行すると、アプリケーションは、このサブス クリプションのことを、ウォッチャー情報のサブスクリプションの結果として 認知する。アプリケーションは、ウォッチャーのURIを既知の悪人データベー スに照会する。マッチするデータがある場合、Joeに電子メールでそのことを 知らせる。 このアプリケーションが機能するには、Joeのpresence.winfoに対してアプリ ケーションはサブスクライブが許容されている、ということをJoeが確認して いる必要がある。 4. パッケージ定義 このセクションでは、イベントパッケージの規定に必要な詳細を、RFC 3265 [1]のセクション4.4の定義通りに説明する。 4.1. イベントパッケージ名 RFC 3265[1]では、パッケージまたはテンプレートパッケージの名前を規定す るパッケージ定義が必要とされる。 このテンプレートパッケージの名称は「winfo」である。これは、他の任意の パッケージに適用可能である。任意のパッケージ「foo」のウォッチャー情報 は、「foo.winfo」という名称で示される。再帰的なテンプレートパッケージ は、明示的に許容されている(また、有益である)。そのため、「foo.winfo. winfo」は有効なパッケージ名である。 4.2. イベントパッケージパラメータ RFC 3265[1]では、パッケージおよびテンプレートパッケージの定義で、Event ヘッダーフィールドについて、パッケージ固有のパラメータを規定する必要が ある。 このイベントテンプレートパッケージでは、パッケージ固有のEventヘッダー フィールドのパラメータは定義されていない。 Rosenberg Standards Track [Page 5] RFC 3857 Watcher Information August 2004 4.3. SUBSCRIBEのボディ RFC 3265 [1]では、SUBSCRIBEリクエストにボディがある場合、ボディの用法 を規定するパッケージまたはテンプレートパッケージの定義が必要とされる。 ウォッチャー情報のSUBSCRIBEリクエストには、ボディを含めてもよい[MAY]。 このボディでは、ウォッチャー情報サブスクリプションをフィルタする用途で 使用される。このボディの定義は、本仕様の範囲外である。たとえば、プレゼ ンスの場合、何か変更があるたびに、通知に完全な状態を含めるべきである、 とボディに示す場合がある。また、サブスクリプションが最初に作成された時 間は、ウォッチャー情報の通知に含めるべきではない、と示す場合もある。 ウォッチャー情報パッケージのSUBSCRIBEリクエストは、ボディなしで送信し てもよい[MAY]。これは、デフォルトのウォッチャー情報サブスクリプション のフィルタリングポリシーが要求されたことを意味する。デフォルトポリシー を以下に示す。 o ウォッチャー情報は、ウォッチャー情報の状態に何らかの変更があるたび に毎回生成される。 o SUBSCRIBEでトリガされたウォッチャー情報通知には、完全な状態(ウォッ チャー情報のサブスクライバが取得を許可されているウォッチャー全員の 一覧)が含まれる。ウォッチャーの状態変化によってトリガされたウォッ チャー情報通知には、状態に変更があったウォッチャーに関する情報のみ が含まれる。 当然ながら、サーバーは、サブスクリプションに対して任意のポリシーを適用 することができる。 4.4. サブスクリプションの有効期間 . RFC 3265[1]では、パッケージ定義がサブスクリプションの有効期間について デフォルト値を規定し、明示的に指定する場合の適切な有効期間の指定につい て論ずることが必要とされる。 ウォッチャー情報は、ユーザーがあるパッケージの特定リソースにサブスクラ イブしたとき、またはサブスクリプションがタイムアウトしたときに変わる。 結果として、ウォッチャー情報は、あるパッケージ内の特定リソースのサブス クライバ数によっては、非常に動的に変化する可能性がある。サブスクリプ ションがタイムアウトする頻度は、ユーザーが自身のサブスクリプションを維 持する期間によって異なる。通常、ウォッチャー情報のサブスクリプション は、ウォッチされるサブスクリプションの生存時間に渡る時間が設定される。 そのため、範囲は数分から数日にまで渡る。 この要因のために、ウォッチャー情報のサブスクリプションの生存時間につい て、広範に実用的なデフォルト値を定義するのは困難である。本文書の判断 で、ここでは1時間を選択する。ただし、クライアントは、Expiresヘッダー フィールドを使用して、望ましい期限切れを指定すべきである[SHOULD]。 Rosenberg Standards Track [Page 6] RFC 3857 Watcher Information August 2004 4.5. NOTIFYのボディ RFC 3265[1]では、NOTIFYリクエストで許容されるボディ型のセットを説明 し、SUBSCRIBEリクエストにAcceptヘッダーフィールドがない場合に使用され るデフォルト値を規定するパッケージ定義が必要とされる。 ウォッチャー情報通知のボディには、ウォッチャー情報ドキュメントが含まれ る。このドキュメントには、あるパッケージ内のリソースについて、ウォ ッチャーの一部または全部と、そのサブスクリプションの状態が記述される。 すべてのウォッチャー情報のサブスクライバとノーティファイアは、[3]に記 載されているapplication/watcherinfo+xml形式をサポートしなければならな い[MUST]。また、そのMIMEタイプ(application/watcherinfo+xml)を、 SUBSCRIBEリクエストに含まれるすべてのAcceptヘッダーフィールドにリスト しなければならない[MUST]。 将来的に、他のウォッチャー情報形式が定義される可能性がある。その場合、 ウォッチャー情報のサブスクリプションで、他の形式へのサポートを示しても よい[MAY]。ただし、許容形式として、必ずapplication/watcherinfo+xmlをサ ポートし、またリストしなければならない[MUST]。 当然ながら、サーバーにより生成されるウォッチャー情報通知は、SUBSCRIBE リクエスト内のAcceptヘッダーフィールドで指定される形式のいずれかに則っ ていなければならない[MUST]。Acceptヘッダーフィールドが存在しない場合、 通知は、[3]に記載されているapplication/watcherinfo+xml形式を使用しなけ ればならない[MUST]。 4.6. SUBSCRIBEリクエストのノーティファイア処理 RFC 3265[1]では、パッケージは、ノーティファイア(notifier)側における SUBSCRIBEリクエストのパッケージ固有の処理(特に認証と認可の点)について 定義すべきである、と規定されている。 特定パッケージのウォッチャー情報には、機密情報が含まれる。そのため、す べてのウォッチャー情報のサブスクリプションは、承認(approval)の前に、認 証(authenticated)および認可(authorized)されるべきである[SHOULD]。認証 は、ダイジェスト認証、S/MIME、TLS、または他の伝送固有の仕組みなど、SIP で利用できる任意の技術を使用して実行してもよい[4][MAY]。認可ポリシー は、通例通り、管理者の裁量にある。ただし、いくつかの推奨はできる。 すべてのパッケージで、ユーザーAに対し、自身のウォッチャー情報にサブス クライブ可能にすることが推奨される[RECOMMENDED]。再帰の場合でも真であ る。そのため、ユーザーが、どのパッケージのウォッチャー情報に関する ウォッチャー情報にでもサブスクライブ可能にすることが推奨される [RECOMMENDED]。 あるパッケージ「foo」内で、ユーザーBがユーザーAの認可済みサブスクライ バの場合、ユーザーAのパッケージfooに対して、ユーザーBからのウォッ チャー情報サブスクリプションを許可することが推奨される[RECOMMENDED]。 Rosenberg Standards Track [Page 7] RFC 3857 Watcher Information August 2004 ただし、Bに送信されるウォッチャー情報通知には、B自身のサブスクリプショ ンの状態のみを含めることが推奨される[RECOMMENDED]。言い替えると、ユー ザーには、自分自身のサブスクリプションの状態を監視することを許可するこ とが推奨される[RECOMMENDED]。 認可ポリシーの無限再帰を防ぐために、ユーザーAのみが、任意のfooのfoo. winfo.winfo にサブスクライブできるようにすることが推奨される [RECOMMENDED]。また、デフォルトで、サーバーは、foo.winfo.winfo.winfo や、それより深い再帰に対するサブスクリプションは、いずれも認可しない、 とすることも推奨される[RECOMMENDED]。 4.7. NOTIFYリクエストのノーティファイア生成 SIP Eventフレームワークでは、パッケージで送信される通知、およびその通 知の構築方法について、パッケージが条件を規定する必要がある。 各ウォッチャー情報のサブスクリプションは、ウォッチ対象である「内部の」 サブスクリプションのセットに関連付けられる。このセットは、ウォッチャー 情報のSUBSCRIBEリクエストのRequest-URIに含まれるURIと、ウォッチャー情 報サブスクリプションの親イベントパッケージとで定義される。親イベント パッケージを取得するには、ウォッチャー情報のSUBSCRIBEリクエストにある Eventヘッダーフィールドの値から、後ろに付いている「.winfo」を取り除 く。ウォッチャー情報サブスクリプションのEventヘッダーフィールドの値が 「presence.winfo」の場合、親イベントパッケージは「presence」である。 Eventヘッダーフィールドの値が「presence.winfo.winfo」の場合、親イベン トパッケージのは「presence.winfo」である。通常、ウォッチャー情報の SUBSCRIBEのRequest-URIに含まれるURIによって、ドメイン内のAddresses-of- Recordが識別される。この場合、ウォッチ対象のサブスクリプションのセット は、ウォッチャー情報のSUBSCRIBEのRequest-URIに含まれるリソースに合わせ て作成された親イベントパッケージの、全サブスクリプションである。ただ し、Request-URIには、より大きなコレクションのリソースに対するサブスク リプションなど、任意のサブスクリプションセットを識別するURIを含めるこ とができる。たとえば、sip:all-resources@example.comがexample.com内で定 義され、すべてのリソースを参照しているとする。この場合、 sip:all-resources@example.comに対する「presence.winfo」のウォッチャー 情報サブスクリプションは、example.com内の任意のリソースに関してプレゼ ンスサブスクリプションの状態が変化したときは、いつでも通知を要求する。 ウォッチャー情報ノーティファイアは、ウォッチ対象の任意のサブスクリプ ションについて状態が変化したときは、いつでも通知を生成してもよい [MAY]。 ウォッチャー情報サブスクリプションはサブスクリプションのコレクションに 合わせて作成されているため、ウォッチャー情報パッケージは、サブスクリプ ション状態のモデルが必要である。これは、以下で説明するサブスクリプショ ンの有限状態マシン(Finite State Machine / FSM)を指定することで実現され る[訳注: 原文の「Fine State」は「Finite State」の誤り]。FSMは、任意の パッケージでユーザーのサブスクリプションを管理する。ウォッチャー情報通 知は、この状態マシンの遷移によって生成されてもよい[MAY]。注意が必要なの Rosenberg Standards Track [Page 8] RFC 3857 Watcher Information August 2004 は、このFSMは、サーバーに維持されるサブスクリプションの状態マシンの単な る1モデルである、ということである。実装では、実装固有の方法で、自分の状 態マシンをこのFSMにマップする。 4.7.1. サブスクリプション状態マシン 基礎となる登録用状態マシンを図1に示す。これはRFC 3265[1]の記述を、ほと んどそのまま使用したものだが、waiting(待機中)状態の通知が追加されてい る。 SUBSCRIBEリクエストが届くと、初期状態でサブスクリプションFSMが作成され る。この状態は一時的なものである。次の状態は、サブスクリプションのポリ シーが存在するかどうかによって異なる。サブスクリプションの禁止を決定す る既存のポリシーがある場合、ただちにterminated(終了)状態に遷移する。こ の状態では、FSMを破棄できる。サブスクリプションの認可を決定する既存の ポリシーがある場合、FSMはactive(アクティブ)状態に遷移する。この状態 は、サブスクライバが通知を受信することを示す。 サブスクリプションが届いたときに、既存の認可ポリシーがない場合、サブス クリプションはpending(保留中)状態に遷移する。この状態では、サーバーは 認可決定を待機している。プレゼンス状態に変更があっても通知は生成されな い(RFC 3265[1]に従って最初のNOTIFYは配信される)が、サブスクリプション FSMは維持される。認可決定が肯定に帰着すると、サブスクリプションは認証 され、active状態に遷移する。認可が否定の場合、サブスクリプションは拒否 され、FSMはterminated状態に遷移する。任意決定には非常に時間がかかる可 能性がある。実際のところ、サブスクリプション自体が期限切れになった後 に、認可決定が届く可能性もある。pendingのサブスクリプションが時間切れ になりそうな場合、waiting(待機中)状態に遷移する。任意のタイミングで、 サーバーは、pendingまたはwaitingのサブスクリプションについて、終了を決 定することができる。理由は、未認可のサブスクリプション状態にメモリと CPUリソースを割り当てることに関する懸念のためである。サーバーが終了を 決定すると、「giveup」(中止する)イベントがサーバーによって生成され、サ ブスクリプションはterminatedに遷移する。 waiting状態はpendingに似ているが、waiting状態では通知は生成されない。 ただし、サブスクリプションが承認または拒否されると、FSMはterminated状 態に移行し、破棄される。さらに、別のサブスクリプションが、SUBSCRIBEリ クエスト(最初に提示されていた場合)のボディで、同じリソースに対して、同 じウォッチャーから、同じイベントパッケージ/イベントパッケージのパラ メータ/フィルタで受信された場合、FSMは「giveup」イベントでterminated状 態に移行し、破棄される。この遷移が発生する理由は、同じパラメータを持つ 新しいサブスクリプションが到着したときに、pending状態に移行し、それに よって前のサブスクリプションのwaiting状態が冗長になるためである。 waiting状態の目的は、ユーザーがウォッチャー情報の状態を任意のタイミン Rosenberg Standards Track [Page 9] RFC 3857 Watcher Information August 2004 グでフェッチし、以前に届いた(また今後もまた届く可能性のある)、認可決定 が必要なサブスクリプションについて、認知できるようにするためである。一 例を挙げる。AはBにサブスクライブする。Bは、このサブスクリプションに関 するポリシーを定義していなかったため、pending状態に遷移する。Bは「オン ライン」ではないため、Bのソフトウェアエージェントに連絡を取ってサブ スクリプションの承認を得ることができない。サブスクリプションは期限切れ になる。ここで、破棄されたとする。Bがログインして、自身のウォッチャー 情報状態をフェッチする。Aからのサブスクリプション記録はないため、Aから のサブスクリプションに関するポリシーの決定は行われない。Bはログオフす る。Aはサブスクリプションを更新する。このサブスクリプションに対するポ リシーは定義されていないため、サブスクリプションは再びpendingになる。 この処理は、無限に続く可能性がある。waiting状態によって、Bは、このサブ スクリプションが試みられたことを検出できる。 subscribe, policy= +----------+ reject | |<------------------------+ +------------>|terminated|<---------+ | | | | | | | | | |noresource | | +----------+ |rejected | | ^noresource |deactivated | | |rejected |probation | | |deactivated |timeout |noresource | |probation | |rejected | |giveup | |giveup | | | |approved +-------+ +-------+ +-------+ | | |subscribe| |approved| | | | init |-------->|pending|------->|active | | | |no policy| | | | | | | | | | | | +-------+ +-------+ +-------+ | | | ^ | | subscribe, | | | +-----------------------------------+ | policy = accept | +-------+ | | | | | | |waiting|----------+ +----------->| | timeout | | +-------+ 図1: サブスクリプション状態マシン waiting状態は、フェッチの試行(すぐに期限切れになるサブスクリプション) を認可することを許容するためにも必要とされる。 Rosenberg Standards Track [Page 10] RFC 3857 Watcher Information August 2004 当然ながら、サブスクリプションに対するポリシーは指定できない。結果とし て、サーバーはgiveupイベントを生成して、waitingのサブスクリプションを terminated状態に遷移することができる。giveupイベントを発行するまでの待 機時間数は、システム依存である。 giveupイベントは、未認可のサブスクリプションに関連付けられたリソースを 破棄するために、waitingとpendingのいずれの場合でも生成される。このイベ ントは、giveupタイマーが切れたときに生成される。このタイマーには、 pendingまたはwaiting状態に移行するときに、期限切れ値が設定される。サー バーは、十分に注意して、この値を選択する必要がある。ユーザーの使用感を 向上するには、値を大きくする必要がある。というのも、ユーザーは数日後に ログインして、何者かが自分にサブスクライブしようとしたことを知る可能性 が高いためである。ただし、状態を未認可のサブスクリプションに割り当てる と、DoS攻撃のソースとして使用される可能性がある。そのため、特定のサブ スクライバがpendingやwaitingのサブスクリプションを一定数以上持つことを 禁止するポリシーを、未認可のサブスクリプションの状態を保持するサーバー が追加することを推奨する[RECOMMENDED]。 任意の時点で、サーバーはサブスクリプションを非アクティブ化することがで きる。非アクティブ化とは、認可ポリシーに変化がなくても、サブスクリプ ションを破棄することを意味する。これは、正常終了やサブスクリプションの 移動操作の目的で、サブスクリプションの更新をトリガするために実行される 可能性がある。関連するイベントは、probation(試用期間)である。この場 合、サブスクリプションは終了し(terminated)、サブスクライバは再試行ま で、一定時間を待機するように要求される。このイベントの意味は、RFC 3265 [1]のセクション3.2.4で詳しく説明されている。 サブスクリプションを任意の時点で終了できる理由は、そのサブスクリプショ ンに関連付けられるリソースが存在しなくなるためである。これは、 noresource(リソースなし)イベントに関連する。 4.7.2. 状態マシンの適用 サーバーは、ウォッチャー情報のサブスクリプションに対して、状態マシンの 遷移に関する通知を生成してよい[MAY]。これを実行するかどうかは、ポリ シー次第である。ただし、いくつかのガイドラインが定義される。 あるイベントパッケージfooを例に上げる。Aは、このパッケージ内のイベント で、Bにサブスクライブする。また、Aは、Bのfoo.winfoにもサブスクライブす る。このシナリオ(foo.winfoのサブスクライバは、同じリソースのfooに対す るサブスクライバでもある場合)では、Aが受信するウォッチャー情報通知は、 自分自身のサブスクリプションに変更があった点についてのみにすることが推 奨される[RECOMMENDED]。通常、Aは、Subscription-Stateヘッダーフィールド によって、fooに対するサブスクリプションの変更に関する通知を受信する。 これは、foo.winfoに対して別々のサブスクリプションが必要とされること を、高頻度で未然に防ぐためである。ただし、このようなサブスクリプション がAによって実行された場合、fooに関する通知のSubscription-Stateヘッダー Rosenberg Standards Track [Page 11] RFC 3857 Watcher Information August 2004 フィールドで、(認可ポリシーの理由から)レポートされていない状態の変 更は、いずれも、foo.winfoの通知でレポートすべきでない[SHOULD NOT]。 一般則として、ウォッチャー情報のサブスクライバで、複数のウォッチャーに 関してウォッチャー情報通知を受信することが認可されている場合、全ウォッ チャー情報通知で全ウォッチャーの現在の状態を配信するのではなく、状態が 変わった(その結果通知がトリガされた)ウォッチャーに関する情報を、ウォッ チャー情報通知に含めることが推奨される[RECOMMENDED]。ただし、フェッチ 操作(0のExpiresでSUBSCRIBE)の結果としてトリガされたウォッチャー情報通 知は、全ウォッチャー(当然ながら、ウォッチャー情報のサブスクライバに対 する公開が認可されたウォッチャーのみ)の完全な状態がNOTIFYに提示される という結果になるべきである[SHOULD]。 多くの場合、サブスクリプション状態マシンの状態は一時的なものになる。た とえば、認可済みウォッチャーがフェッチ操作を実行した場合、それによって 状態マシンが作成され、initからactiveに移行し、activeからterminatedに移 行し、FSMが破棄される。このような場合、一時的な状態についてウォッ チャー情報の通知を送信すべきではない[SHOULD NOT]。前述の例では、サー バーは通知を送信しない。これは、すべての状態が一時的なためである。 4.8. NOTIFYリクエストのサブスクライバ処理 RFC 3265[1]では、パッケージ独自の方法でサブスクライバがNOTIFYリクエス トを処理する方法、および、特に、サブスクライブされたリソースの一貫した ビューを構築するためにNOTIFYを使用する方法を指定するパッケージが期待さ れている。通常、ウォッチャー情報のNOTIFYには、状態が変わったウォッ チャーに関する情報のみが含まれる。全ウォッチャーの状態全体の整合性がと れたビューを構築するために、ウォッチャー情報のサブスクライバは、長期間 に渡って受け取ったNOTIFYをバインドする必要がある。この処理の詳細は、ド キュメント形式に依存する。application/watcherinfo+xml形式の詳細につい ては、[3]を参照のこと。 4.9. フォークされたリクエストの操作 SIPイベントフレームワークでは、フォークされたSUBSCRIBEリクエストが、複 数のサブスクリプションを組み込むことができるかどうか、パッケージで示す 必要がある。 ユーザーが、パッケージfooのあるリソースに関するウォッチャー情報を取得 する場合、ウォッチャー情報に対するSUBSCRIBEは、複数サーバー集合に到達 する必要がある。複数サーバー集合は、全体で、パッケージのfooのそのリ ソースに関する全ウォッチャーの完全な情報を持つ。パッケージfooのそのリ ソースに関するサブスクリプションを操作するサーバーが多数存在する場合 Rosenberg Standards Track [Page 12] RFC 3857 Watcher Information August 2004 (通常、負荷分散上の理由から)、ウォッチャー情報の完全なセットを保持する サーバーが1台もない、という可能性は高い。この場合の解決方法はいくつか ある。本仕様では、特定の方法を必須とはせず、また、他の方法を禁止するこ ともしない。単に、広範な解決方法を構築可能であることを示すのみである。 1つ目の解決方法は、フォークの使用である。このシステムは、ウォッチャー 情報のSUBSCRIBEが、ウォッチャー情報の要件を認知している特定のプロキシ に到達するように設計することができる。このプロキシは、そのパッケージの そのリソースに関するサブスクリプションを維持する可能性のある全サーバー に、SUBSCRIBEリクエストをフォークする。これらの各サーバーは、そのリ ソースの現在のサブスクライバを保持しているかどうかに関わらず、ウォッ チャー情報のサブスクリプションを受け入れる。各サーバーは、そのリソース に関するサブスクリプションを最終的にはすべて受信する可能性があるため、 受け入れる必要がある。ウォッチャー情報のサブスクライバは、一定数の ウォッチャー情報NOTIFYリクエストを受け取り、リクエストのそれぞれが個々 にダイアログボックスを確立する。各ダイアログ間の情報を集めることで、 ウォッチャー情報のサブスクライバは、完全なウォッチャー情報状態を算出す ることができる。多くの場合、特定のダイアログはウォッチャー情報通知を まったく生成しない場合がある。これは、サーバーがそのリソースに関するサ ブスクリプションを受信しない場合に発生する。 このようなシステムを相互運用可能な形式で構築するには、1つのSUBSCRIBEに 対する応答で、複数のNOTIFYメッセージが生成される結果として、複数のサ ブスクリプションを組み込むように、すべてのウォッチャー情報のサブスクラ イバを準備しなければならない[MUST]。 多数サーバー問題に関するもう1つの対処方法は、状態エージェントの使用で ある。詳細はセクション4.11を参照のこと。 4.10. 通知の頻度 RFC 3265[1]では、パッケージの最大通知頻度をパッケージで定義することを 必須としている。 輻輳制御(congestion control)の理由から、通知頻度が過度にならないように することが重要である。したがって、サーバーは、1つのウォッチャー情報の サブスクライバに対して、毎5秒に1度を超える頻度でウォッチャー情報通知を 生成しないことが推奨される[RECOMMENDED]。 4.11. 状態エージェント RFC 3265 [1]では、パッケージで、設計における状態エージェントの役割を検 討するように求めている。 状態エージェントは、本パッケージで重要な役割を果たす。セクション4.9で 説明されているように、特定パッケージのサブスクリプションの負荷を共有す るサーバーが、多数存在する場合がある。ウォッチャー情報のサブスクリプ Rosenberg Standards Track [Page 13] RFC 3857 Watcher Information August 2004 ションは、その複数サーバー全体に渡って分散するサブスクリプション状態を 要求する可能性がある。この問題に対処するには、状態エージェントのファー ム(farm)を使用することができる。各状態エージェントは、特定のリソース セットに関するウォッチャー情報状態全体を知っている。状態エージェントが 完全なウォッチャー情報状態を判断する手段は、本仕様の範囲外である。 ウォッチャー情報のサブスクリプションは、受信されると、要求されたリソー スの完全なウォッチャー情報状態を保持する状態エージェントにルートされ る。このサーバーは、ウォッチャー情報のサブスクリプションを受け入れ(当 然ながら、認可済みと想定)、ウォッチャー情報状態が変更されると、ウォッ チャー情報通知を生成する。ウォッチャー情報のサブスクライバは、この場 合、1つのダイアログのみを保持する。 5. 使用例 以下のセクションでは、ウォッチャー情報パッケージを使用するアプリケー ションとコールフローの例について説明する。 この例では、ユーザーJoe(sip:joe@example.com)は、example.comプレゼンス サーバー経由でプレゼンスを提供する。Joeは、自分のプレゼンスにサブスク ライブしたユーザーを確認して、サブスクリプションを承認または拒否するた めに、自身のウォッチャー情報にサブスクライブする。 Joeは以下のSUBSCRIBEリクエストを送信する。 SUBSCRIBE sip:joe@example.com SIP/2.0 Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7 From: sip:joe@example.com;tag=123aa9 To: sip:joe@example.com Call-ID: 9987@pc34.example.com CSeq: 9887 SUBSCRIBE Contact: sip:joe@pc34.example.com Event: presence.winfo Max-Forwards: 70 サーバーは、認証するために401で応答し、Joeは、資格情報付きでSUBSCRIBE を再実行する(メッセージは示さない。次に、サーバーはこのサブスクリプ ションを認可する。これは、Joeが、自分自身のプレゼンスのウォッチャー情 報にサブスクライブすることを許可するためである。サーバーは200 OK応答を 返す。 SIP/2.0 200 OK Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds8 ;received=192.0.2.8 From: sip:joe@example.com;tag=123aa9 To: sip:joe@example.com;tag=xyzygg Call-ID: 9987@pc34.example.com CSeq: 9988 SUBSCRIBE Contact: sip:server19.example.com Expires: 3600 Event: presence.winfo Rosenberg Standards Track [Page 14] RFC 3857 Watcher Information August 2004 次に、サーバーは、presence.winfoの現在の状態が含まれるNOTIFYをjoe@example.comに送信する。 NOTIFY sip:joe@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1288 NOTIFY Contact: sip:server19.example.com Event: presence.winfo Subscription-State: active Max-Forwards: 70 Content-Type: application/watcherinfo+xml Content-Length: ... sip:A@example.com 次に、Joeは200 OKでNOTIFYに対して応答する。 SIP/2.0 200 OK Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii ;received=192.0.2.7 From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1288 NOTIFY Rosenberg Standards Track [Page 15] RFC 3857 Watcher Information August 2004 NOTIFYは、Joeに、ユーザーAがpendingのサブスクリプションにあることを通 知する。次に、Joeは、何らかの方法を使って、Aのサブスクリプションを認可 する。この結果、サブスクリプションのステータスは変わり(pendingから activeに遷移)、別の通知が配信される。 NOTIFY sip:joe@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1289 NOTIFY Contact: sip:server19.example.com Event: presence.winfo Subscription-State: active Max-Forwards: 70 Content-Type: application/watcherinfo+xml Content-Length: ... sip:A@example.com 次に、Bは200 OKでNOTIFYに対して応答する。 SIP/2.0 200 OK Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij ;received=192.0.2.7 From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1289 NOTIFY Rosenberg Standards Track [Page 16] RFC 3857 Watcher Information August 2004 6. セキュリティの考慮事項 6.1. DoS攻撃 ウォッチャー情報は、特定リソースのウォッチャー状態が変化したことに関す る通知を生成する。1つのリソースが多数のウォッチャーを保持する可能性が あり、その結果、大量の通知となる可能性がある。そのため、ウォッチャー情 報のサブスクリプションは、DoS(denial of service attack)攻撃ツールとな る可能性がある。賢明な認可ポリシーと有効な操作原則を組み合わせること で、この問題を回避することができる。 第一に、1リソースが大量のウォッチャーを保持する場合、そのリソースに対 するウォッチャー情報のサブスクリプションは、明示的に認可済みのエンティ ティ(アイデンティティが適切に認証済み)からの場合にのみ、許容すべきであ る。この方法で、攻撃者が作成したサブスクリプションによって、ウォッ チャー情報のNOTIFYストリームが生成されることを回避できる。 ウォッチャー情報のサブスクリプションが適切に認証されている場合でも、攻 撃の可能性はある。たとえば、攻撃の対象となる有効なユーザーTを想定す る。Tは、自分のウォッチャー情報にサブスクライブした。攻撃者は、大量の サブスクリプション(ウォッチャー情報のサブスクリプションではない)を生成 する。サーバーが未認証のサブスクリプションに対してサブスクリプション状 態を生成し、ウォッチャー情報通知でそれらの変化をレポートすると、ユー ザーTは大量のウォッチャー情報通知を受信することになる。実際、サブスク リプションが生成されたときと、サブスクリプションが終了したときに、サー バーがウォッチャー情報通知を生成すると、2つの要因で増幅される。サー バーが各ウォッチャー情報通知の完全な状態を生成すると、増幅は非常に重大 な問題となる。実際のところ、Tに送信されるデータ量は、攻撃者が生成する データの2乗にもなるだろう。攻撃者が生成するN個のサブスクリプションの 各々は、結果としてTにウォッチャー情報のNOTIFYが送信されることになり、 それぞれが最大でN個のウォッチャーに関するレポートになる。これを防ぐた めに、サーバーは、未認証のSUBSCRIBEリクエストに関して、サブスクリプ ション状態を生成すべきではないし、ウォッチャー情報通知を生成すべきでは ない。 6.2. 機密情報の漏洩 ウォッチャー情報は、特定リソースに関心を持つユーザーを示す。パッケージ とリソースによっては、これは重要な機密情報になりうる。たとえば、プレゼ ンスの場合、あるユーザーのウォッチャー情報は、その人物の友人、家族、仕 事の関係者を示す。この情報は、多様な悪質な目的に使用される可能性があ る。 Rosenberg Standards Track [Page 17] RFC 3857 Watcher Information August 2004 この情報が漏洩する可能性の1つは、盗聴である。攻撃者は、ウォッチャー情 報通知を監視して、この情報を知る。盗聴を防ぐために、ウォッチャーは、 ウォッチャー情報リソースにサブスクライブするときに、sips URIスキームを 使用してもよい[MAY]。ウォッチャー情報のノーティファイア(RFC 3261のセク ション26.3.1を参照)は、プロキシと同様に、TLSとsipsに対応しなければなら ない。 S/MIMEによって、SUBSCRIBEとNOTIFYリクエストの両方の伝送時に、エンド ツーエンドでSIPの暗号化を使用してもよい[MAY]。 この情報が漏洩する可能性のもう1つは、なりすましのサブスクリプションに よるものである。この攻撃は、すべてのウォッチャー情報のサブスクリプショ ンを認証および認可することで防ぐことができる。ノーティファイアがサブス クライバを認証するために、HTTPダイジェスト(RFC 3261のセクション22)を使 用してもよい[MAY]。結果的に、全ウォッチャーがHTTPダイジェストに対応し なければならない[MUST]。これは冗長な要件ではあるが、RFC 3261で、すべて のSIPユーザーエージェントは対応が義務づけられているためである。 7. IANA条項 本仕様では、RFC 3265[1]のセクション6.2で指定されている通りに、イベント テンプレートパッケージを登録する。 パッケージ名: winfo テンプレートパッケージ: 該当 公開されている仕様: RFC 3857 連絡先: Jonathan Rosenberg, jdrosen@jdrosen.net。 8. 謝辞 Adam Roach、Allison Mankin、Brian Stuckerの各氏からいただいた詳細なコ メントに感謝を述べたい。 9. 規範となる参考文献 [1] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004. Rosenberg Standards Track [Page 18] RFC 3857 Watcher Information August 2004 [4] 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. 10. 有益な参考文献 [5] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, July 2004. 11. 著者の連絡先 Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 EMail: jdrosen@dynamicsoft.com Rosenberg Standards Track [Page 19] RFC 3857 Watcher Information August 2004 12. 完全な著作権表示 Copyright (C) The Internet Society (2004).本文書は、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編集職務のための資金は、現在、インターネット協会によって提供されて いる。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Rosenberg Standards Track [Page 20]