Network Working Group W. Marshall, Ed. Request for Comments: 3313 AT&T Category: Informational January 2003 メディア認可のためのセッション開始プロトコル(SIP) プライベート拡張 Private Session Initiation Protocol (SIP) Extensions for Media Authorization 本文書の位置付け 本文書は、インターネット社会に情報を提供するためのものである。いかなる インターネット標準も規定しない。この文書の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2003).All Rights Reserved. 概要 本文書は、サービス品質(Quality of Service/QoS)とメディア認可(media authorization)の必要性について説明する。また、QoSのアドミッション制御 を呼のシグナリングに統合し、DoS攻撃に対して防御することができる、セッ ション開始プロトコル(Session Initiation Protocol/SIP)拡張を定義する。 この拡張の用法は、事前に同意済みのポリシーを使用する管理ドメインまたは 管理ドメインの連合(federations)にのみ適用できる(この場合、QoSを認可す るSIPプロキシと、QoSを提供する基礎のネットワークのポリシー制御は、どち らもその管理ドメインまたはドメインの連合に所属する)。 Marshall, Ed. Informational [Page 1] RFC 3313 SIP Extensions for Media Authorization January 2003 目次 1. 適用性の範囲 ................................................. 2 2. 本文書で使用される規約 ....................................... 3 3. 背景と動機付け ............................................... 3 4. 概要 ......................................................... 4 5. メディア認可をサポートするためにSIPに加えられた変更 ........... 4 5.1 SIPヘッダー拡張 ........................................... 5 5.2 SIPの手順 ................................................. 5 5.2.1 ユーザーエージェントクライアント(UAC) ............... 6 5.2.2 ユーザーエージェントサーバー(UAS) ................... 6 5.2.3 送信元プロキシ(OP) ................................... 7 5.2.4 送信先プロキシ(DP) ................................... 7 6. 例 ........................................................... 8 6.1 RSVPメッセージングによる帯域の要求 ....................... 8 6.1.1 ユーザーエージェントクライアント側 ................... 8 6.1.1 ユーザーエージェントサーバー側 ....................... 10 7. アプローチ案の利点 ........................................... 12 8. セキュリティの考慮事項 ....................................... 13 9. IANA条項 ..................................................... 13 10. 知的所有権に関する注記 ....................................... 13 11. 規範となる参考文献 ........................................... 14 12. 有益な参考文献 ............................................... 14 13. 寄稿者 ....................................................... 15 14. 謝辞 ......................................................... 15 15. 編集者の連絡先 ............................................... 15 16. 完全な著作権表示 ............................................. 16 1. 適用性の範囲 本文書は、QoSアドミッション制御を呼のシグナリングと統合するために使用 可能なSIP拡張を定義する。また、DoS攻撃に対して防御するときにも役立つ。 この拡張の用法は、事前に同意済みのポリシーを使用する管理ドメインまたは 管理ドメインの連合(federations)にのみ適用できる(この場合、QoSを認可す るSIPプロキシと、QoSを提供する基礎のネットワークのポリシー制御は、どち らもその管理ドメインまたはドメインの連合に所属する)。さらに、このメカ ニズムは、メディアセッションを記述するメッセージボディのエンドツーエン ド暗号化とは一般的に互換性がない。 これは、データ伝送とアプリケーションを区別するという一般的なインター ネット原則とは対照的である。したがって、本文書で説明されているソリュー ションは、大規模のインターネットには適用できない。このような制限はある が、前述した想定を満たし、結果となる制限を受け入れることができる特殊な 配置であれば十分役に立つため、このメカニズムは通知目的の文書として正当 Marshall, Ed. Informational [Page 2] RFC 3313 SIP Extensions for Media Authorization January 2003 である。配置の一例として、従来の回線交換型の電話網をまねている、閉じた ネットワークがある。本文書は、この特殊な構成での使用を補助するプライ ベートヘッダーを指定する。 2. 本文書で使用される規約 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119[2]に記載されるとおり に解釈されるべきである。 3. 背景と動機付け 現在のIP電話システムでは、帯域幅が限定されなかったり、ネットワーク層の QoS (Quality of Service)がポリシー制御を何もを受けずに実現する、という 理想的な環境を想定している。ただし、現実には、エンドツーエンドの帯域に は制限があり、QoSに対するアクセスが制限されないということは一般的にあ りえない。主な理由は、QoSは、他のフローを犠牲にして1つのフローを優先し て扱うためである。したがって、あるフローがQoSへのアクセス権を持つかど うかについて、ポリシー制御を設定することが重要である。これによって、全 般的な公正さが実現するだけでなく、DoS攻撃も防ぐことができる。 本文書では、セッション開始プロトコル(SIP) [3]経由で確立したメディアス トリームにQoSを実現する方法について関心を持っている。本文書では、下図 に示すように、呼のシグナリングとメディアの認可を統合するアーキテクチャ を想定している。実線(AとB)はインターフェースを示す。破線(C)はQoS対応の メディアフローを示す。 +----------+ | プロキシ | +--------->| | | +----------+ | ^ A)| B) | | { } | | | v v +--------+ +------+ C) | エッジ | | UA |........|ルーター|...... +------+ +--------+ 図1 - 基本アーキテクチャ Marshall, Ed. Informational [Page 3] RFC 3313 SIP Extensions for Media Authorization January 2003 このアーキテクチャでは、ポリシー実施ポイント(Policy Enforcement Point/ PEP) [6]として動作するエッジルーターを含み、QoS対応ネットワークがあ り、そのネットワークにSIP UAが接続していると想定している。また、QoSの 取得を望むSIP UAが、プロキシ経由でセッションを開始するということも想定 している。このプロキシは、使用するデータネットワークのQoSポリシー制御 とインターフェースを取ることができる。このようなプロキシのことをここで はQoS対応プロキシと呼ぶ。ここでは、SIP UAがQoS (C)を取得するには、認可 トークンをネットワークに提示する必要がある、と想定している。SIP UAは、 この認可トークンをQoS対応プロキシからSIP (A)経由で取得する。このとき、 本文書で定義される拡張のSIPヘッダーを使用する。次に、プロキシは、UAに 適した認可トークンを取得するために、エッジルーターまたはポリシー決定ポ イント(Policy Decision Point/PDP - 図には非表示) [6]と直接通信する。 QoS対応プロキシを使用できるアクセスデータネットワークの例として、 DOCSISベースのケーブルネットワークと第3世代(3G)無線ネットワークなどが ある。 4. 概要 前述した基本アーキテクチャに従って、メディアストリームのためにQoSを取 得する必要があるセッションは、次の手順を使用する。 SIP UAは、QoS対応プロキシにINVITEを送信する。結果として作成される各ダ イアログでは、信頼性のない暫定応答(100以外)すべて、信頼性のある最初の 1xxまたは2xx応答、ダイアログ内でこの信頼性のある応答の再送信すべてに1 つ以上のメディア認可トークンが含まれる。UAがQoSを要求するときは、メ ディア認可トークンとリソース予約を含める。 また、SIP UAは、QoS対応プロキシから、1つ以上のメディア認可トークンを含 むINVITEを受信することがある。この場合、UAがQoSを要求するときは、メ ディア認可トークンとリソース予約を含める。リソース予約メカニズムはSIP の一部ではなく、本文書でも説明の対象としていない。 5. メディア認可をサポートするためにSIPに加えられた変更 本文書は、メディア認可スキームをサポートするために、プライベートSIP ヘッダー拡張を定義する。このアーキテクチャでは、QoS対応のSIPプロキシ は、QoSリクエストで使用される1つ以上の認可トークンをUAに提供する。本文 書で定義する拡張によって、QoS対応のSIPプロキシは、ネットワークのQoSリ ソースを認可することができる。 Marshall, Ed. Informational [Page 4] RFC 3313 SIP Extensions for Media Authorization January 2003 5.1 SIPヘッダー拡張 新規にP-Media-Authorizationという汎用のヘッダーフィールドを定義する。 P-Media-Authorizationヘッダーフィールドには、1つ以上のメディア認可トー クンが含まれる。このメディア認可トークンは、セッションと関連付けられる メディアフローで、以降のリソース予約に含まれる。つまり、独立したリソー ス予約メカニズムに渡される(この予約メカニズムについては本文書で規定し ない)。メディア認可トークンは、メディアストリームのQoSを認可するために 使用される。P-Media-Authorizationヘッダーフィールドは、次のABNF [4]で 記述される。 P-Media-Authorization = "P-Media-Authorization" HCOLON P-Media-Authorization-Token *(COMMA P-Media-Authorization-Token) P-Media-Authorization-Token = 1*HEXDIG 以下の表1は、[3]の表2および表3について、本文書で定義した新しいヘッダー フィールドで拡張したものである。この表には、情報として、本文書が発行 された時点で公開されていた標準化過程の拡張メソッドに関する項目も含めて いる。INFO、PRACK、UPDATE、SUBSCRIBE/NOTIFYの各メソッドは、それぞれ [11]、[9]、[12]、[10]で定義されている。 Where proxy ACK BYE CAN INV OPT REG P-Media-Authorization R ad o - - o - - P-Media-Authorization 2xx ad - - - o - - P-Media-Authorization 101-199 ad - - - o - - Where proxy INF PRA UPD SUB NOT P-Media-Authorization R ad - o o - - P-Media-Authorization 2xx ad - o o - - 表1: ヘッダーフィールドの概要 P-Media-Authorizationヘッダーフィールドは、SIPのオファー/アンサーを伝 達するSIPリクエスト/応答でのみ使用することができる。必然的に、このヘッ ダーフィールドの範囲は狭くなる。 5.2 SIPの手順 ここでは、QoSの認可という観点から、メディア認可と互換性のあるシステム で使用する場合のSIP [3]の手順について定義する。 Marshall, Ed. Informational [Page 5] RFC 3313 SIP Extensions for Media Authorization January 2003 5.2.1 ユーザーエージェントクライアント(UAC) 最初のSIP INVITEメッセージ、結果としてネットワークのQoSリソースが変化 する通話中のメッセージ、および発呼先での通話中の変化は、認可すべきであ る。このようなSIPメッセージは、QoS対応プロキシ経由で送信され、認可を受 信する。QoS対応のSIPプロキシは、QoSを認可するために、メディアストリー ムを記述するメッセージボディ(SDPなど)を検査してもよい[MAY]。したがっ て、このようなメッセージボディはエンドツーエンドで暗号化しないことが推 奨される(ただし、本文書のセクション1の適用範囲内では適切な場合もあ る)。 P-Media-Authorization-TokenはP-Media-Authorizationヘッダーに指定され る。また、信頼性のない暫定応答(100応答)すべて、信頼性のある最初の1xxま たは2xx応答、およびQoS対応のSIPプロキシからUACへ送信されたダイアログ内 でこの信頼性のある応答の再送信すべての各ダイアログに含まれる。 UACは、関連するメディアストリームのQoSを要求する場合、P-Media- Authorizationヘッダーを含む最新のリクエスト/応答のP-Media- Authorization-Tokensをすべて使用すべきである。これは初回および後続の更 新予約メッセージのどちらにも適用される(たとえば、RSVPベースの予約シス テムなどで)。RFC 2750 [5]で定義されているように、UAC内の予約機能は、16 進数の各文字列をバイナリに変換し、その各結果をPolicy-Elementとして利用 すべきである(Lengthは除外されるが、各トークンに含まれるP-Typeは含まれ る)。Policy-Elementsには一般的に認可エンティティと資格情報(credential) が含まれ、メディアデータストリームのQoSリソースに対するRSVPリクエスト で使用される。 5.2.2 ユーザーエージェントサーバー(UAS) ユーザーエージェントサーバーは、QoS対応のSIPプロキシから、INVITE (また は他の)メッセージでP-Media-Authorization-Tokenを受信する。応答に、UAが QoSを希望するメディアストリームが記述されているメッセージが含まれる場 合、(本文書のセクション2の適用範囲内で適切と考えられるため)このメッ セージボディはエンドツーエンドで暗号化しないことが推奨される。 UASは、関連するメディアストリームのQoSを要求する場合、P-Media- Authorizationヘッダーを含む最新のリクエスト/応答のP-Media- Authorization-Tokensをすべて使用すべきである。これは初回および後続の更 新予約メッセージのどちらにも適用される(たとえば、RSVPベースの予約シス テムなどで)。RFC 2750 [5]で定義されているように、UAS内の予約機能は、16 進数の各文字列をバイナリに変換し、その各結果をPolicy-Elementとして利用 すべきである(Lengthは除外されるが、各トークンに含まれるP-Typeは含まれ る)。Policy-Elementsには一般的に認可エンティティと資格情報(credential) Marshall, Ed. Informational [Page 6] RFC 3313 SIP Extensions for Media Authorization January 2003 が含まれ、メディアデータストリームのQoSリソースに対するRSVPリクエスト で使用される。 5.2.3 送信元プロキシ(OP) 送信元のQoS対応プロキシ(originating QoS enabled proxy/OP)がINVITE (ま たは他の)メッセージをUACを受信した場合、プロキシは発信元を認証し、発信 元がQoSを受信する権限があることを検証する。 OPは、送信元のポリシー決定ポイント(originating Policy Decision Point/ PDP-o)と連携して、1つ以上のメディア認可トークンを取得/生成する。この トークンには、メディアストリームについて認可されたQoSをUACが取得するた めに必要な情報が含まれている。各メディア認可トークンは、RFC 2750 [5]で 定義されているようにPolicy-Elementとして構成され(Lengthは除外される が、各トークンに含まれるP-Typeは含まれる)、次に16進数の文字列へ変換さ れてP- Media-Authorization-Tokenが構成される。プロキシのリソース管理機 能では、QoSで認可する対象を決定するために、リクエストと応答の両方でメ ディアストリームを記述するメッセージボディ(SDPなど)を検査してもよい。 元のプロキシは、UACから受信したINVITE (または他の)メッセージの結果生成 される各ダイアログについて、応答によってネットワークのQoSが変化する可 能性がある場合、信頼性のない暫定応答(100以外)すべて、信頼性のある最初 の1xxまたは2xx応答、プロキシがUACに送信するこの信頼性のある応答の再送 信すべてに、P-Media-Authorization-Tokenを指定したP-Media-Authorization ヘッダーを追加する必要がある。SDPを含む応答は、ネットワークのQoSが変化 する可能性がある。 5.2.4 送信先プロキシ(DP) 送信先のQoS対応プロキシ(Destination QoS Enabled Proxy/DP)は、着呼側に QoSを受信する権限があることを検証する。 DPは、終端側のポリシー決定ポイント(terminating Policy Decision Point/ PDP-t)と連携して、メディアストリームについて認可されたQoSをUASが取得す るために必要な情報を含むメディア認可トークンを取得/生成する。メディア 認可トークンは、RFC 2750 [5]で定義されているようにPolicy-Elementとして 構成され(Lengthは除外されるが、各トークンに含まれるP-Typeは含まれる)、 次に16進数の文字列へ変換されてP- Media-Authorization-Tokenが構成され る。プロキシのリソース管理機能では、QoSで認可する対象を決定するため に、リクエストと応答の両方でメディアストリームを記述するメッセージボ ディ(SDPなど)を検査してもよい。 Marshall, Ed. Informational [Page 7] RFC 3313 SIP Extensions for Media Authorization January 2003 送信先プロキシは、メッセージによってネットワークのQoSが変化する可能性 がある場合、UASに送信するINVITE(または他の)リクエストに、P-Media- Authorization-Tokenを指定したP-Media-Authorizationヘッダーを追加する必 要がある。SDPを含むメッセージは、ネットワークのQoSが変化する可能性があ る。 6. 例 6.1 RSVPメッセージングによる帯域の要求 リソース予約プロトコル(Resource Reservation Protocol/RSVP) [7]と連携し てP-Media-Authorizationヘッダーフィールドを使用する例を以下に示す。以 下の例では、オファーは最初のINVITEで受信し、アンサーは信頼性のある暫定 応答[9]で受信し、この応答にはメディアフローのSDP記述が含まれる、と想定 している。 6.1.1 ユーザーエージェントクライアント側 図2は、UACの観点から見た、メディア認可を使用する基本的なコールフローの 高水準な概要を示す。わかりやすくするために、ポリシーの相互作用の一部は 省略した。 ユーザーが受話器を上げ、電話番号をダイヤルすると、UACはダイヤルされた 数字を収集し、最初の(1) INVITEメッセージを送信元SIPプロキシへ送信す る。 送信元SIPプロキシ(OP)は、ユーザー/UACを認証し、(2)INVITEメッセージを適 切なSIPプロキシへ転送する。 呼が転送されない場合、終端側エンドポイントは、最初のINVITEに対してOP経 由で(3) 18x応答を送信する。この応答には、接続に関してネゴシエートされ る帯域要件の指定が(SDP記述[8]の形式で)含まれる。 OPは、(3) 18xを受信すると、エンドポイント、帯域、およびメディア交換の 特性に関して十分な情報が得られる。OPはPolicy-SetupメッセージをPDP-o へ開始する((4) AuthProfile)。 PDP-oは、認可されたメディア記述をローカルストアに格納し、この記述を指 す認可トークンを生成し、認可トークンをOPへ返す((5) AuthToken)。 Marshall, Ed. Informational [Page 8] RFC 3313 SIP Extensions for Media Authorization January 2003 UAC ER-o PDP-o OP |(1)INVITE | | | クライアントの認証 |------------------------------------------->| と呼の認可 | | | | (2)INVITE | | | |--------------> | | | | (3)18x | | |(4)AuthProfile |<-------------- | | |<--------------| | | |(5)AuthToken | | | |-------------->| P-Media-Authorization | | | (6)18x | ヘッダー拡張に配置され |<-------------------------------------------| る認可トークン |---(7)PRACK-------------------------------->| | |--(8)PRACK----> | |<-(9)200 (PRACK) |<--(10)200 (PRACK)--------------------------| | | | | |P-Media-AuthorizationからRSVP | |ポリシーオブジェクトをコピー | |(11)RSVP-PATH | | |----------->| (12)REQ | | | |-------------->| SIPプロキシが設定した認可トークンと | | (13)DEC | 認可済みプロファイルを使用 | |<--------------| PDPは決定を下す | | | |(14)RSVP-PATH | |------------------------------------------------> | | | |(15)RSVP-PATH |<-------------------------------------------------------------- |P-Media-AuthorizationからRSVP | |ポリシーオブジェクトをコピー | |(16)RSVP-RESV | | |----------->| (17)REQ | | | |-------------->| SIPプロキシが設定した認可トークンと | | (18)DEC | 認可済みプロファイルを使用 | |<--------------| PDPは決定を下す | | | |(19)RSVP-RESV | |---------------------------------------------------> | | | |(20)RSVP-RESV |<---------------------------------------------------------------- | | | | 図2 - RSVPでのメディア認可(UAC) OPは、認可トークンを、(6) 18xメッセージのP-Media-Authorizationヘッダー 拡張に含める。 Marshall, Ed. Informational [Page 9] RFC 3313 SIP Extensions for Media Authorization January 2003 UACは、(6) 18xメッセージを受信して、P-Media-Authorizationヘッダーのメ ディア認可トークンを格納する。また、UACは、(7) PRACKメッセージを送信す ることで18xを受信確認する。このメッセージは(10) 200で応答される。 UACは、メディアを送信する前に、(11) RSVP-PATHメッセージを送信すること でQoSを要求する。このメッセージには、以前にPolicy-Elementとして格納し たP-Media-Authorization-Tokenが含まれる。 ER-oは、(11) RSVP-PATHメッセージを受信し、PDP-o COPSのメッセージ交換 ((12) REQ)によって認可をチェックする。PDP-oは、OPに返した認可トークン にリンクされていた、格納されている認可済みメディア記述を使用して、認可 をチェックする。認可が成功すると、PDP-oは「インストール」の決定を返す ((13) DEC)。 ER-oはリクエストに関してアドミッションの可能性をチェックし、アドミッ ションが成功すると、(14) RSVP-PATHメッセージを転送する。 UACはUASから(15) RSVP-PATHメッセージを受信すると、(16) RSVP-RESVメッ セージを送信してネットワークリソースを予約する。 ER-oは、(16) RSVP-PATHメッセージを受信し、PDP-o COPSのメッセージ交換 ((17) REQ)によって認可をチェックする。PDP-oは、OPに返した認可トークン にリンクされていた、格納されている認可済みメディア記述を使用して、認可 をチェックする。認可が成功すると、PDP-oは「インストール」の決定を返す ((18) DEC)。 ER-oはリクエストに関してアドミッションの可能性をチェックし、アドミッ ションが成功すると、(19) RSVP-RESVメッセージを転送する。 (20) RSVP-RESVメッセージを受信すると、双方向でネットワークリソースが予 約される。 6.1.1 ユーザーエージェントサーバー側 図3は、UASの観点から見た、メディア認可を使用するコールフローの高水準な 概要を示す。わかりやすくするために、ポリシーの相互作用の一部は省略し た。 送信先SIPプロキシ(DP)は、エンドポイント、帯域、およびメディア交換の特 性に関する情報を十分に保持しているため、(1) INVITEの受信時に終端側ポリ シー決定ポイント(PDP-t)に対してPolicy-Setupメッセージを開始する。 Marshall, Ed. Informational [Page 10] RFC 3313 SIP Extensions for Media Authorization January 2003 UAS ER-t PDP-t DP | | | | (1)INVITE | | | |<-------------- | | | | プロキシ認証と | | | (2)AuthProfile| 呼の認可 | | |<--------------| | | | (3)AuthToken | | | |-------------->| P-Media-Authorization | | | (4)INVITE | ヘッダー拡張に配置され |<------------------------------------------| る認可トークン | (5)18x | | | |------------------------------------------>| (6)18x |P-Media-AuthorizationからRSVP |--------------> |ポリシーオブジェクトをコピー | |(7)RSVP-PATH | | |---------->| (8)REQ | | | |-------------->| SIPプロキシが設定した認可トークンと | | (9)DEC | 認可済みプロファイルを使用 | |<--------------| PDPは決定を下す | | | |(10)RSVP-PATH | |--------------------------------------------------> | | | |(11)RSVP-PATH |<-------------------------------------------------------------- |P-Media-AuthorizationからRSVP | |ポリシーオブジェクトをコピー | | (12)RSVP-RESV | | |---------->| | | | | (13)REQ | | | |-------------->| SIPプロキシが設定した認可トークンと | | (14)DEC | 認可済みプロファイルを使用 | |<--------------| PDPは決定を下す | | | |(15)RSVP-RESV | |---------------------------------------------------> | | | |(16)RSVP-RESV |<--------------------------------------------------------------- | | | |<-(17)PRACK--------- |<--(18)PRACK ------------------------------| |---(19)200 (PRACK) ----------------------->| | | | |--(20)200 (PRACK)--> | | | | 図3 - RSVPでのメディア認可(UAS) PDP-tは、認可されたメディア記述をローカルストアに格納し、この記述を指 す認可トークンを生成し、認可トークンをDPへ返す。トークンは(4) INVITE メッセージに配置され、UASへ転送される。 Marshall, Ed. Informational [Page 11] RFC 3313 SIP Extensions for Media Authorization January 2003 呼が転送されない場合、UASは(5) 18x応答を最初のINVITEメッセージに対して 送信し、UACへ逆に転送される。同時に、UASは(7)RSVP-PATHメッセージを送信 する。このメッセージには、以前にPolicy-Elementとして格納したP-Media- Authorization-Tokenが含まれる。 ER-tは、(7) RSVP-PATHメッセージを受信し、PDP-t COPSのメッセージ交換に よって認可をチェックする。PDP-tは、DPに返した認可トークンにリンクされ ていた、格納されている認可済みメディア記述を使用して、認可をチェックす る。認可が成功すると、PDP-tは「インストール」の決定を返す((9) DEC)。 ER-tはリクエストに関してアドミッションの可能性をチェックし、アドミッ ションが成功すると、(10) RSVP-PATHメッセージを転送する。 UASは(11) RSVP-PATHメッセージを受信すると、(12) RSVP-RESVメッセージを 送信してネットワークリソースを予約する。 ER-tは、(12) RSVP-RESVメッセージを受信し、PDP-t COPSのメッセージ交換に よって認可をチェックする。PDP-tは、DPに返した認可トークンにリンクされ ていた、格納されている認可済みメディア記述を使用して、認可をチェックす る。認可が成功すると、PDP-tは「インストール」の決定を返す((14) DEC)。 ER-tはリクエストに関してアドミッションの可能性をチェックし、アドミッ ションが成功すると、(15) RSVP-RESVメッセージを転送する。 (16) RSVP-RESVメッセージを受信すると、双方向でネットワークリソースが予 約される。 この図では、網羅するために、(5) 18x応答に対する(17) PRACKメッセージ と、結果としてそのPRACKを受信確認する(19) 200応答も示している。 7. アプローチ案の利点 メディア認可を利用することで、ネットワークリソースの使用を制御すること ができるようになる。それによって、DoS攻撃やさまざまな種類のサービス詐 欺攻撃に対して、IP電話は堅牢になる。認可機能を使用することで、多数のフ ロー、および予約されるネットワークリソース量を制御することができる。こ れによって、乏しいリソースの場合でもIP電話システムの信頼性は高くなる。 Marshall, Ed. Informational [Page 12] RFC 3313 SIP Extensions for Media Authorization January 2003 8. セキュリティの考慮事項 QoSへのアクセスを制御するために、QoS対応プロキシは、メディア認可トーク ンを使用してアクセス権を付与する前にUAを認証すべきである。このような認 証に関連する方法やポリシーは、本文書の範囲外である。ただし、たとえば [3]に記述されているようなSIPの標準的な認証メカニズムを使用して実行する ことができる。 QoS対応プロキシからUAに対して、P-Media-Authorizationヘッダーで送信され るメディア認可トークンは、盗聴や改ざんから保護しなければならない [MUST]。たとえば、IPSecまたはTLSなどのメカニズムによって実現できる。た だし、このようなメカニズムではホップバイホップのセキュリティしか実現さ れない。UAとQoS対応プロキシとの間に1つ以上の仲介(プロキシなど)が存在す る場合、このような仲介はP-Media-Authorizationヘッダーフィールド値にア クセス権を持つため、機密性と完全性の保護が危うくなる。結果として、サー ビス盗用やUAに対するDoS攻撃が可能になる。したがって、P-Media- Authorizationヘッダーフィールドは、信頼性のない仲介が平文で使用できた り、完全性が保護されていない状況で使用できてはならない[MUST NOT]。この ような要件を満たすメカニズムは、現在のところSIPでは定義されていない。 このようなメカニズムができるまだ、プロキシは信頼性のない仲介を経由して P-Media-Authorizationヘッダーを送信してはならない[MUST NOT]。送信した 場合、ヘッダーのコンテンツが公開されたり変更される可能性がある(SIPで は、プロキシはメッセージボディを追加することが許可されていないため、S/ MIMEベースの暗号化はプロキシには使用できない)。 QoS対応プロキシは、メディアストリームを記述するメッセージボディ(SDPな ど)を検査してもよい。したがって、このようなメッセージボディは暗号化す べきではない。言い換えると、前述したメッセージボディのエンドツーエンド の機密性は損なわれ、見込まれるセキュリティ全体のレベルは低くなる。 9. IANA条項 本文書は、メディア認可用に新しいプライベートSIPヘッダー「P-Media- Authorization」を定義する。このヘッダーは、本文書のRFC番号を参考文献に 使用して、IANAのSIPヘッダー登録に登録された。 10. 知的所有権に関する注記 本文書に含まれる仕様の一部またはすべてに関する知的所有権について、IETF に通知している。詳細については、主張している権利の一覧(オンライン)を参 照のこと。 Marshall, Ed. Informational [Page 13] RFC 3313 SIP Extensions for Media Authorization January 2003 11. 規範となる参考文献 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 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] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [5] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. 12. 有益な参考文献 [6] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [7] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [9] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [10] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [11] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [12] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002. Marshall, Ed. Informational [Page 14] RFC 3313 SIP Extensions for Media Authorization January 2003 13. 寄稿者 本文書の旧バージョンの寄稿者および共著者を以下に示す。 Bill Marshall (AT&T)、K. K. Ramakrishnan (AT&T)、Ed Miller (Terayon)、 Glenn Russell (CableLabs)、Burcak Beser (Juniper Networks)、Mike Mannette (3Com)、Kurt Steinbrenner (3Com)、Dave Oran (Cisco)、Flemming Andreasen (Cisco)、John Pickens (Com21)、Poornima Lalwaney (Nokia)、 Jon Fellows (Copper Mountain Networks)、Doc Evans (Arris)、Keith Kelly (NetSpeak)。 14. 謝辞 PacketCableプロジェクトのDistributed Call Signaling研究は、多様な会社 を代表する多数の方々の研究成果である。寄稿者一同、以下の方々の助力に感 謝を述べたい。John Wheeler (Motorola); David Boardman、Daniel Paul (Arris Interactive); Bill Blum、Jay Strater、Jeff Ollis、Clive Holborow (Motorola); Doug Newlin、Guido Schuster、Ikhlaq Sidhu (3Com); Jiri Matousek (Bay Networks); Farzi Khazai (Nortel); John Chapman、 Bill Guckel、Michael Ramalho (Cisco); Chuck Kalmanek、Doug Nortz、John Lawser、James Cheng、Tung-Hai Hsiao、Partho Mishra (AT&T); Telcordia Technologies (Lucent Cable Communications)。Dean WillisとRohan Mahyも 貴重なフィードバックをくださった。 15. 編集者の連絡先 Bill Marshall AT&T Florham Park, NJ 07932 EMail: wtm@research.att.com Marshall, Ed. Informational [Page 15] RFC 3313 SIP Extensions for Media Authorization January 2003 16. 完全な著作権表示 Copyright (C) The Internet Society (2003).All Rights Reserved. 本記述とその翻訳はコピーし他に提供することができる。また論評を加えた派 生的製品や、この文書を説明したり、その実装を補助するもので、上記の著作 権表示およびこの節を付加するものはすべて、全体であってもその一部であっ ても、いっさいの制約を課されること無く、準備、複製、発表、配布すること ができる。しかし、この文書自体にはいかなる方法にせよ、著作権表示やイン ターネット協会もしくは他のインターネット関連団体への参照を取り除くなど の変更を加えてはならない。インターネット標準を開発するために必要な場合 は例外とされるが、その場合はインターネット標準化過程で定義されている著 作権のための手続きに従わなければならない。またRFCを英語以外の言語に翻 訳する必要がある場合も例外である。 以上に述べられた制限は永久的なものであり、インターネット協会もしくはそ の継承者および譲渡者によって破棄されることはない。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、インターネッ ト協会およびIETFは、この情報がいかなる権利も侵害していないという保証、 商用利用および特定目的への適合性への保証を含め、また、これらだけに限ら ずすべての保証について、明示的もしくは暗黙的の保証は行われない。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供されて いる。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Marshall, Ed. Informational [Page 16]