本論文は、 SIP(Session Initiation Protocol)は関する既知の脆弱性についてまとめたものである。本章では、本論文の目的、構成、概要等について記述する。
近年、 IP 電話の需要の高まりから VoIP への注目が高まっている。 VoIPの呼制御を行うプロトコルのうち、インターネット電話などで用いられる通信制御プロトコルの一つである SIP （Session Initiation Protocol）に関しての研究を行った。 SIP は拡張性が高く、簡単に開発できる利点があるが、 SIP そのものには SIP の通信を保護する機能がない。また、メディアを転送する RTPにも、保護機能は無いに等しく、音声やビデオのデータを簡単に盗聴できてしまう。そこで、安全な SIPネットワーク構成に関する研究を行った。
IP 電話とはインターネットを活用した電話技術である。音声通話には RTP(Real Time TransportProtocol) という技術があり、この RTPのセッションをどのようにして確立させるかというのも研究目的の一つである。
RTP(Real Time Transport Protocol),RTCP(RTP Control Protocol) は、 1996 年に提唱されたメディアストリーミングのために用いられる代表的なプロトコルである。 RTP はストリーミングデータを送受信するためのプロトコルで、 RTCPはデータ送受信のセッションを制御するプロトコルである。通常この 2 つのプロトコルを組み合わせて使用される。 RTPはその名の通り、リアルタイム伝送を行うことを目的としたプロトコルである。そのため、パケットロスに関する対策は行われない。 VoIPでは、音声の途切れが生じる事があっても、遅延を一定の範囲以内に留めることを重視し、メディアストリーミングのためのプロトコルとしてRTP を使用される。 RTP は通常、 UDP(User Datagram Protocol)上で動作するように実装されている。プロトコルの規定上は UDP である必要はない。しかし、以下の理由からTCP(Transmission Control Protocol) では実装されない。
TCP はコネクション型プロトコルで、データを送信する前に 3ウェイハンドシェイクというプロセスを利用して通信相手とのコネクションを確立する。 3 ウェイハンドシェイクとは、送信元と宛先の間で 3 回の通信をすることで確立される仮想的なコネクションである。 3ウェイハンドシェイクでは、コードビットの SYN と ACK の 2 つのフラグを使用した TCPセグメントを交換する。また、このときに実際のデータ転送に使用するためのシーケンス番号と確認応答番号を決定する。
以上のステップで、 TCP コネクションが確立する。このあと、実際のデータ転送が開始される。
UDP(User Datagram Protocol) は信頼性を実現するための制御を行わない、 TCP/IPトランスポート層のコネクションレス型のプロトコルである。 UDP は、 TCPのようなコネクションの確立、確認応答、再送制御やフロー制御などの機能を持たない。 UDPはポート番号でアプリケーションプロセスを識別してデータを渡すだけである。なので、 UDPヘッダは非常にシンプルな構成になっている。
UDP のメリットとしては、 TCP による通信では信頼性の確保はできるが、オーバーヘッド が大きいため、リアルタイムでの通信や高速性が要求される場面にはあまり向いていない。そこで、リアルタイム性などが必要とされる場合にはUDP を利用する。 UDP はアプリケーションへの転送のほかには何もしないためオーバーヘッドが小さくて済む。また、 UDPのヘッダサイズは８バイトで、 TCP(20-60 バイト)と比較するととても小さく、その分多くのアプリケーションデータを送受信できるため、 UDPを使った方が転送効率を上げることができる。
インターネットは、 Web やメールの機能を提供する「サーバー」に対して、 SIPは、クライアントとクライアントの「エンド・ツー・エンド (End to End)」で、マルチメディア・データを直接、双方向でリアルタイムにやり取りすることを目的とした通信プロトコルである。 エンド・ツー・エンドでリアルタイム通信を行うためには、互いにマルチメディアデータを送受信する「セッション」を開設する必要があります。SIP は、セッションを開設するため、通信相手を特定する機能と、発信 / 着信 / 切断の機能を提供する。
SIPは、セッションの開設を制御する「シグナリング」と呼ばれる機能を実現する通信プロトコルである。それ以外の機能については、他のプロトコルと組み合わせて実現する。 例えば、セッションを開設する互いのクライアント間で、セッションのトランスポート・アドレス（IPアドレスやポート番号）、マルチメディア・データの圧縮方式を交換するのには、 SDP(SessionDescription Protocol) というプロトコルを使用する。 このように SIPは、自身の機能する範囲をシグナリング部分に明確に限定しているため、他の通信プロトコルとの組み合わせが容易である。
SIPは、データ転送の信頼性を確保するための方式を定めたトランスポート層の上位に位置するプロトコルである。様々なネットワーク構成に柔軟に対応できるように、UDP(UserDatagram Protocol) および TCP(Transmission Control Protocol) のトランスポートに対応する。 SIP は、リアルタイム・コミュニケーションを行う IP電話や携帯電話、さらにネット家電など、様々なアプリケーションで利用されている。アプリケーションが SIPに対応すれば、リアルタイム・コミュニケーションに対応した他のアプリケーションと容易に相互接続ができる。 また SIPは、より高度なリアルタイム・コミュニケーションを実現するため、基本的なシグナリング機能の他にも、ユーザーや機器の状態に関する情報をやり取りする「プレゼンス」や「インスタント・メッセージ」に対応している。
SIP は、クライアントだけでなく、いくつかのサーバー機器によってシステムが構成される。SIPではこれらの機器を機能ごとに分類し、「エンティティ」（実体）として定義している。
SIP において、クライアントとなるのが UA である。 UA はユーザーの操作に応じて SIP メッセージを生成/ 送信し、相手 UA からの SIP メッセージを受けてユーザーの結果を知らせる、 SIPメッセージの「エンドポイント」（端点）となる端末である。 UA は機器面から見ると、 UAC （ユーザー・エージェント・クライアント）と UAS（ユーザー・エージェント・サーバー）に分けられる。 UAC は SIP メッセージを生成して送信する側を指し、 UASはSIP メッセージを受け入れ応答する側を指します。 セッション開設時には、発信側が UAC、着信側が UAS になる。 UAは、通信中のその時々の必要に応じて UAC として機能したり、 UAS として振舞ったりする。 UA には、 IP 電話やビデオフォン、ソフトフォンなどのほか、アナログ電話を IP電話として使うためのレジデンシャル・ゲートウェイ（VoIP アダプタ）や、一般公衆回線網と接続する PSTN-SIPGWなど、多くの機器が含まれる。
SIP では、各 UA は SIP 「SIP URI」と呼ばれる ID によって識別される。 SIPにおける通信は、この SIP URI指定することで行われるが、実際には相手のトランスポート・アドレスの対応付けを行う必要があるが、そこで重要な役割を果たすのがレジストラである。 UA はその起動時などに、自身の SIP URIとトランスポート・アドレスの情報を、レジストラに「登録」します。レジストラはこの登録を受け付け、その情報を対応するロケーション・サーバーに登録するサーバーである。UAからの登録を受け付ける際に端末認証を行うことが可能なため、不正な端末（ユーザー）がサービスに登録できないようにすることもできる。
ロケーション・サーバーは、レジストラが各 UAから受け付けた登録情報を管理する機能を提供するエンティティである。。物理的なサーバーと言うより、レジストラとプロキシ・サーバー間で端末情報を共有する機能を表す ”概念 ”を表す。実際には、各 UA の SIP URIとトランスポート・アドレスの対応付けが、データベースとして管理される。 ロケーション・サーバー自身は SIP メッセージの送受信は行わず、レジストラからの端末情報の登録 / 更新 /削除や、プロキシ・サーバーやリダイレクト・サーバーからの端末情報の参照を受け付ける。 SIPは、ロケーション・サーバーの役割を定義するのみで、その仕組みや、レジストラなど他のエンティティ間とのインターフェースを規定していない。ベンダーなどがシステム構築する際に設計する。 多くの場合、ロケーション・サーバーはリレーショナル・データベースにより構築され、そのインターフェースにはデータベース操作用の言語であるSQL(Structured Query Language) などの手順が用いられている。
プロキシ・サーバーは、 UA と UA の間で、 SIPメッセージを仲介するサーバーである。主にルーティングの役割を担う。 UA が他の UA に対して通信を試みる時、発信元 UA は相手の SIP URI を指定してからプロキシ・サーバーへ SIPメッセージを送る。プロキシ・サーバーは、ロケーション・サーバーへ SIP URI を問い合わせ、相手先 UAのトランスポートのアドレスを取得した後に、 SIP メッセージを転送する。メッセージを転送する際には、必要に応じてそのメッセージ内の特定部分を書き換える。この仕組みによって、 UA が相手のトランスポート・アドレスを知らなくとも SIP URIだけを知っていれば、通信が成立する。 IP アドレスに依存せずに通信相手を特定することができるため、ユーザーの所在地（IPアドレスが異なる外出先など）にとらわれないサービスが可能である。
リダイレクト・サーバーは、プロキシ・サーバーと同じく、 UA からの SIP メッセージを適切な相手先UAへ到達させる役割を担う。プロキシ・サーバーと異なる点は、リダイレクト・サーバーが SIP メッセージを相手先 UA へ直接転送するのではなく、適切なトランスポート・アドレスを送り元の UA へ通知し、 UAがそのトランスポート・アドレスに基づいて、相手先 UA へ SIP メッセージを送り直すという点である。UA が通信したい相手の SIP URI を指定して、リダイレクト・サーバーへ SIPメッセージを送る。するとリダイレクト・サーバーは、ロケーション・サーバーに問い合わせて、相手 UA のトランスポート・アドレスを取得する。その後「リダイレクト応答」と呼ばれる、宛先指示を行う応答メッセージにより、相手 UAのトランスポート・アドレスを、送り元の UA へ通知する。送り元の UA は、相手UAのトランスポート・アドレスが得られるので、 SIP メッセージを直接相手 UA へ送りなおすことができる。 このようにリダイレクト・サーバーは、 SIPメッセージを仲介することなく、正しい転送先を「指示」する機能を持つ。しかし、一般的な SIPのシステムにおいて、リダイレクト・サーバーが実際に使われることは少ないようである。
このように SIPのシステムは、多くのエンティティによって構成されているが、各エンティティが物理的にひとつの機器として存在しなくてはならないわけではない。 一般に「SIPサーバー」と呼ぶ場合には、レジストラ、プロキシ・サーバー、リダイレクト・サーバーの各機能を備える 1つのサーバー機器を指す。また、各エンティティの必要性は、システムの構成によって変わる。
IP 電話の標準プロトコルとして普及している SIP は、多くの機能を備えたプロトコルである。ここでは、 SIPの各機能の概要を説明する。
SIP の最も基本的な機能が、 UA と UA の間でセッションの確立を制御する機能である。セッションは、 IP電話の音声や、ビデオフォンの動画などのマルチメディア・データを転送するための通信チャネルとなる。 このセッションを UA（端末）間で開設するためには、通信相手の特定と、呼び出し、それに対する応答、更に開設したセッションの終了などの制御が必要となる。SIP を規定する RFC3261 は、このセッション制御の基本メカニズムを規定したものになる。SIP におけるセッション確立までの一般的な流れを以下に示す。
UA は起動時に、自分自身の SIP URI と、 SIP シグナリングを受信するトランスポート・アドレス（IPアドレスとポート番号）を含めた登録要求メッセージを、レジストラへ送る。レジストラは UAからの登録を受け付け、そのデータをロケーション・サーバーに格納する。
相手先へ発信する（電話をかける）際には、 UA はプロキシ・サーバーに対し、通信相手の SIP URIを指定して接続要求メッセージを送る。このとき接続要求メッセージ中には、発信元 UA が相手先 UAとの間で開設したいセッションのトランスポート・アドレス、つまりマルチメディアのデータを受信したい IPアドレスとポート番号を明記する。 プロキシ・サーバーはロケーション・サーバーに指定された SIP URI を照会し、相手 UA のSIPシグナリング用のトランスポート・アドレスを取得して接続要求メッセージを転送する。
接続要求を受信した UA （発信先からみ見た相手先 UA ＝着信UA）は、着信音を鳴らすなどして、ユーザーへ接続要求が行われていることを知らせる。 ユーザーが着信に対して応答指示を行う（電話の受話器を上げる）と、着信 UA はプロキシ・サーバー経由で、発信元の UAへ接続応答メッセージを送信する。このとき接続応答メッセージ中には、着信 UAのセッション開設用のトランスポート・アドレスを記述する。
2.6.2と2.6.3の接続要求メッセージと応答メッセージによって、互いのセッション開設用のトランスポート・アドレスの交換が完了する。これにより互いのUAは、プロキシ・サーバーを経由せず直接データを送受信すること、すなわち開設したセッションをチャネルとして使った通信が可能になる。UAはこのセッションにより、相手 UA との間でメディアストリームと呼ばれるマルチメディア・データ通信を行う。
ここでは SIP URI がどのようなものか説明する。
SIP URI は、 SIP のエンティティを識別する URI(Uniform Resource Identifer)である。 URI は、世界中のリソースを一意に表現するために与えられた仕組みで、 RFC2396 で規定されている。
<スキーマ>:<スキーマ依存の文字列>mailto: alice@example.comhttp://www.ietf.org/html.charters/sip-charter.htmlftp://ftp.ietf.org/rfc/rfc2396.txtSIP URI は、「sip」や「sips」スキーマで識別される URI である。 SIPメッセージ中で、送信元や宛先などを指定する。メールアドレスとよく似た形式で、次のように表記する。
sip:alice@example.com また、 SIP URI にはパラメータを付与することも可能である。 UA が、 SIP-PSTNゲートウェイを介して一般公衆回線へ接続する際には、ユーザーパートに E.164形式の電話番号を、パラメータに「user=phone」をつけた下記のような SIP URIが使われる場合がある。
sip:+81-123-456-7890@gateway.example.com;user=phoneこの他、電話番号を指定する URI として「tel URI」がある。 tel URIは「tel」スキーマによって識別される URI で、固定電話または携帯電話を示す。 SIP では、発信元や宛先などに、 SIP URI と同様に tel URI を用いることができる。
tel:+81-123-456-7980ロケーションに縛られないコミュニケーションを実現できるのが、 SIP の大きな特徴である。これは「モビリティ」と呼ばれ、SIP の重要で本質的な機能である。 UA などの SIP の各エンティティは、その物理的なトランスポート・アドレス（IPアドレスとポート番号）ではなく、論理的な SIP URI によって識別される。各 UA が動的にレジストラへ登録することで、SIP URI とトランスポートアドレスが対応付けられる。 このことは、ユーザーは自分の所在に関わらず、常に同じ SIP URI を利用できるということを意味している。
SIP による場所に縛られないサービスの実現は、同時にセキュリティへの注意を必要とする。他のユーザーに自分の SIP URIを勝手に使われるなど、サービスの不正利用を防ぐ必要がある。また、外出先のネットワーク経由でサービスを利用する場合には、通信の漏洩も防がなくてはならない。 SIPでは、サービスの利用者が正しいユーザーであるかを認証する基本的な仕組みや、より高度な認証や暗号化によってセキュリティを実現するメカニズムが規定されている。
SIP を規定する RFC3261 では、正しいユーザーであるかを確認する方式として HTTPダイジェスト認証の使用が規定されている。 HTTP ダイジェスト認証が用いられる場合、 UA が SIPサーバーへアクセスする際などに、ユーザー ID とパスワードが必要となる。 SIP サーバーは、 UA から送られたユーザーID とパスワードが登録されたものと一致するかをチェックして、正しいユーザーかどうか確認する。 HTTP ダイジェスト認証は、現在のほとんどの一般的な IP 電話サービスで実際に使われている。IP電話サービス事業者は、契約者にユーザー ID とパスワードを発行し、これらの情報を IP 電話機 (UA) の本体に設定する。IP 電話機は登録や発信の際に自動的にユーザー ID とパスワードを付け、 SIP サーバーが IP電話機が正しい契約者のものであるかチェックしている。
SIP では、より高度な認証と SIP シグナリングの暗号化の方法として、 TLS(Transport Layer Security)の使用も規定している。 TLS は、 WWW などで一般に使用される SSL を、 IETFで規定した通信プロトコルである。 TCP の上位に位置し、 HTTP や SIP などの TCPを利用する上位層のプロトコルに対して、セキュリティ機能を提供する。 SIP では TLS を使用することによって、 SIP メッセージのやり取りをすべて暗号化できるのに加えて、 TLSの高度な認証機能を使って UA や SIP サーバーの不正な「成りすまし」を防ぐことが出来る。 TLS は、 SIPによりコミュニケーションの形態が多様化していく中で、より強固なセキュリティを実現する技術として注目を集めている。
プレゼンス (Presence)という言葉は、直訳すると「存在」という意味である。通信の世界では、通信したい相手がいま通信可能であるかどうかを認識するための仕組みを指す。 許可されたメンバー同士で互いの状態情報を交換することで、自分の通信したい相手が「オンライン」なのか「在籍中」なのか、それとも「オフライン」「離席中」「会議中」なのかが分かる機能である。相手のプレゼンスに応じて電話やメールなどコミュニケーションの手段を変えることができる。 SIP のプレゼンス機能は、コミュニケーションをよりスムーズにし、単なる電話以上の付加価値を実現する重要な機能である。 また、状態情報を公開する側を「プレゼンティティ」、状態情報を閲覧する側を「ウォッチャー」と呼び、プレゼンス・サーバーが状態情報の蓄積や中継を行う。一般的なインスタント・メッセンジャーでは、クライアント・ソフトはプレゼンティティであり、かつウォッチャーとなっている。
インスタント・メッセージは、 UA と UAの間で、短い任意のデータを送りあう機能である。一般にテキストでのチャットに使われる。 SIP のインスタント・メッセージ機能は、ユーザーが入力したテキストを格納した SIPメッセージを送受信することで実現する。この SIP メッセージは、他の SIP の機能と同様に SIPサーバーを中継し、そのテキストデータを UA 間で交換する。 SIP サーバーを中継することで、 SIP URIによるアドレス解決、すなわち SIP URI から、適切なトランスポート・アドレスへの転送が行われる。 そのため、UA は相手UA のトランスポート・アドレスを知らなくても、テキストを送ることができる。 SIPはさまざまな形態のリアルタイム・コミュニケーションを包括的に実現することを目的とし、インスタント・メッセージの機能も規定している。現座、インターネット上で利用されているテキストベースのチャットサービスにおいても、このSIP の機能を利用しているものが多くある。
SIP は HTTP をベースとしたプロトコルで、メッセージすなわち通信データをテキスト形式で表現する。これは、 SIPの大きな特徴となっている。 H.323 など他のシグナリング・プロトコルは、バイナリ形式で通信データを表現するためである。
SIPのメッセージがテキスト形式だということは、人間が判読しやすいということである。開発が容易で、各種の機能拡張にも柔軟に対応できるというメリットを持っている。
INVITE sip:bob@example.com SIP/2.0 <- スタートライン Via: SIP/2.0/UDP client.example.com;branch=z9hG4bknashds8 lt;- 以下ヘッダー Max-Forwards: 70 To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@client.example.com Cseq: 3 INVITE Contact: <sip:alice@client.example.com> Content-Type: application/adp Content-Length:151 <-空白行 v=0 <-以下ボディ o=alice 53655765 2353687637 IN IP4 client.example.com s=- t=0 0 c=IN IP4 client.example.com m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
SIP のメッセージは大きく、「スタートライン」「ヘッダー」「ボディ」に分けることが出来る。スタートラインは、 SIP メッセージの先頭の行にあり、その SIPメッセージがどのような目的のものなのかを記述する。スタートラインは SIPメッセージのもっとも重要な部分であり、必須となる行である。
ヘッダーは SIPメッセージの制御内容について詳細を記述したもので、それぞれあらかじめ規定された意味を持つ、複数のヘッダー行により構成されている。各ヘッダー行は、スタートラインの内容またはそのヘッダーの意味により、SIP メッセージで必須の行または必須でない行が存在する。ただし、ヘッダーがない SIP メッセージは無い。
ボディは、 SIP メッセージによって運ばれるデータである。
この例では、セッションを開設する際のメディアの情報が、SDP(Session Description Protocol) という形式で表記されている。
インスタント・メッセージを行うSIPメッセージの場合は、ボディ部分にユーザーがタイプしたテキストが記述される。ボディ部分は、不要になる場合がある。すなわち、ボディを持たないスタートラインとヘッダーのみのSIP メッセージもあるということである。
ヘッダーとボディの間は空白行により区切られ、どこからボディが始まるのかを識別できるようになっている。また、スタートライン、ヘッダー、空白行の各行は、キャリッジリターン・ラインコード(CRLF) により終端 (改行) することが規定されている。改行コードは Windows 系では「CRLF」、 Unix系では「LF」と、システムによって異なるが、 SIP では「CRLF」に統一している。
SIP は、「リクエスト」と「レスポンス」のやり取りによって通信を行う。リクエストは ユーザー・エージェント・クライアント(UAC) によって、レスポンスはユーザー・エージェント・サーバー (UAS)が受け取ったリクエストに対して、それぞれ生成され送出される。 SIPのメッセージは、リクエストまたはレスポンスのいずれの場合においても、その構造は変わらない。しかし、スタートラインについてはそれぞれ「リクエスト・ライン」または「ステータス・ライン」と呼ばれ、HTTP と同様のフォーマットになっている。
リクエストの SIP メッセージは、次の形式のリクエスト・ラインで始まる。
| INVITE | sip:bob@example.com | SIP/2.0 |
| ↑メソッド名 | ↑リクエストURI | ↑プロトコル・バージョン番号 |
リクエスト・ライン中の「メソッド名」は、リクエストとなる SIPメッセージがどのような制御を要求するものであるかを示している。メソッド名は SIP で規定されており、 UACは相手へ要求する制御内容に適したメソッド名をリクエスト・ラインに記述する。 「リクエスト URI」は、 SIP サーバーなどが SIPメッセージを中継・配送する上で、重要な役割を担っている。リクエストが誰に対して送られるものであるかを示す。上記の例では、”INVITE”というメソッド名のリクエストを、”sip:bob@example.com”へ送ることを指示している。 「プロトコル・バージョン番号」は、プロトコルが SIP であるということと、そのバージョン番号が 2.0であることを示している。現在は「SIP/2.0」で固定されている。
レスポンスの SIP メッセージは、次の形式のステータス・ラインで始まる。
| SIP/2.0 | 200 OK |
| ↑理由フレーズ | ↑ステータス・コード |
ステータス・ラインは、「プロトコル・バージョン番号」から始まる。これは、リクエスト・ラインと同様に固定的に「SIP/2.0」となっている。 「ステータス・コード」は「応答コード」とも呼ばれ、レスポンスがどのような意味を持つかを、3 桁の番号により示す。この 3桁の番号は、 HTTP と同様の番号形態になっていて、各番号とその意味は SIPで規定されている。次の「理由フレーズ」は、ステータス・コードの意味を人間が判読しやすいように文で示したものである。理由フレーズも、ステータス・コードに対応してSIP で規定されている。
SIP のリクエストはメソッド名によってその要求内容が示されている。 SIP では、次のリクエストが規定されている。
| メッセージ | 内容 | 規定している規格名 |
|---|---|---|
| INVITE | セッションの確立 (接続要求) | RFC3261 |
| ACK | セッション確立の確認 | RFC3261 |
| BYE | セッションの終了 (切断) | RFC3261 |
| CANCEL | セッション確立の取り消し | RFC3261 |
| RESISTER | レジストラへの登録 | RFC3261 |
| OPTIONS | サポート機能の問い合わせ | RFC3261 |
| PRACK | 暫定応答の確認 | RFC3262 |
| INFO | セッション中の情報通知 | RFC2976 |
| SUBSCRIBE | 状態情報の要求 | RFC3265 |
| NOTIFY | 状態情報の通知 | RFC3265 |
| MESSAGE | テキストメッセージ等の送信 | RFC3428 |
| REFER | 呼の転送 | RFC3515 |
| UPDATE | セッションの変更 | RFC3311 |
| PUBLISH | 状態情報の通知 | RFC3903 |
INVITE ～ OPTIONS までの各メソッドは、 SIP そのものを規定する RFC3261で定められたものである。しかしそれ以降のメソッドは、その後の拡張機能で新たに追加されたものである。 UAはこれらメソッドのすべてに必ずしも対応する必要はなく、システムやサービスにおいて必要とされる機能のメソッドに対応することになる。例えば、インスタント・メッセージ機能を持たないIP 電話では、一般的に INVITE ～ OPTIONS メソッドには対応しているが、 MESSAGEメソッドには対応していない。
ステータス・コードは、レスポンス・メッセージの中で、受け取ったリクエストが「正常に処理された」または「エラーとなった」などの応答内容を、3 桁の番号で示す。この番号は、 HTTP と同様に100 番台ごとにその意味付けが分けられている。
| ステータス・コード | 内容 | 意味 |
|---|---|---|
| 1xx(100 番台) | 進行状況を示すための暫定応答。 | リクエストが受信され、そのリクエストの処理を継続していることを示す。 |
| 2xx(200 番台) | 成功応答 | リクエストが理解され、受け入れられ、正しく処理されたことを示す。 |
| 3xx(300 番台) | リダイレクト応答 | リクエストを完了するために、他の場所へリクエストを再送するなど、更なるアクションを取る必要があることを示す。 |
| 4xx(400 番台) | クライアント・エラー応答。 | リクエストが誤りのある構文を含む、またはこのサーバーではそのリクエストを実行できないことを示す。 |
| 5xx(500 番台) | サーバ－・エラー応答。 | リクエストに誤りはないが、サーバーがそのリクエストの処理に失敗したことを示す。 |
| 6xx(600 番台) | グローバル・エラー応答。 | リクエストはどのサーバーでも実行できなかったことを示す。 |
これらのうち、 100 番台の応答は暫定的なものであり、最終的な結果は示していない。最終的な結果は 200番以上の応答によって示され、これらは「最終応答」とも呼ばれる。また、最終応答の中でも200 番台の応答は「成功応答」を意味し、300 番以上の応答は「エラー応答」を意味している。 SIP のステータス・コードはこの分類に従い、それぞれの状況に応じた値が規定されている。RFC3261で規定されているステータス・コードの一覧を付録に示す。
SIP リクエストやレスポンスは、メッセージ中のヘッダーによって、要求する制御や応答の内容の詳細を記述する。 SIPのヘッダーは次の形式の複数のヘッダー・フィールドによって構成される。
<ヘッダー名>:<ヘッダー値>Call-ID: a84b4c76e66710@client-a.example.comTo: Bob ;<sip:bob@example.com>基本的に 1 つのヘッダー・フィールドは、 1 行で書かれます。複数のヘッダー・フィールドが、1つの行に書かれることはない。だたし、先頭が空白またはタブにより始まる行は前の行の続きを意味するため、 1つのヘッダー・フィールドが複数の行にまたがることが可能である。
WWW-Authenticate: Digest realm=”unknown”,nonce=”8a8aee67577e338dae62dc442149b8d”, opaque=””, qop=”auth”, stale=FALSE, algorithm=MDまた、同じヘッダー名を持つヘッダー・フィールドが複数行ある場合もある。 ヘッダーのタイプを示すヘッダー名は、それぞれの目的に応じて様々なものが規定されている。ここでは、 SIPの基本的なシーケンスを理解する上で必要ないくつかのヘッダーについて紹介する。各ヘッダーの詳細は、 SIPのメッセージ・シーケンスを紹介する際に具体的に見ていく。
| ヘッダ名 | 内容 |
|---|---|
| ヘッダ名 | 内容 |
| Call-ID | ひとつの「呼」を識別するグローバルユニークな ID。 |
| To | リクエストの宛先。 |
| From | リクエストの送り元。 |
| Contact | 以降のリクエストの送り先を指定。 |
| CSeq | 新しいトランザクションと再送を区別するためのインクリメント値。 |
| Via | リクエストがたどったパスを示す。レスポンスはこの情報を元に返る。 |
| Recoed-Route | それ以降のリクエストがどのプロキシーを通して送信されるべきか示す。 |
| Route | リクエストがルーティングされるべきプロキシを示す。 |
| Max-Forwards | リクエストが各ホップを経由するごとにデクリメントされる値。リクエストがホップできる最大数を示す。 |
| Content-Type | ボディのタイプ。 |
| Content-Length | ボディの長さ。 |
IP 電話などでも使われる SIP の基本的なシーケンスを、詳細に説明する。
SIP において、「モビリティ」という重要な機能を実現するために必要なのが、レジストラへの登録である。 UAはその起動時などに、あらかじめ設定されたレジストラのアドレスへ、 REGISTER リクエストを送る。レジストラは受け取ったREGISTER リクエストの内容を確認し、「200 OK」成功応答を返す。 これにより、レジストラはロケーション・サーバーへ UAを登録し、以降プロキシ・サーバーなどでこの登録情報を使ったリクエスト配送処理が行われる。 REGISTERリクエストによるシーケンスを次に示す。
上記のシーケンス図では、縦軸が UAおよびレジストラのエンティティを、横に伸びる矢印はエンティティ間で送られるメッセージを示している。下に行くほど時間がたっているという前提で、エンティティ間でメッセージのやり取りがどのような順序で行われるかを示している。
REGISTER リクエストの目的は、他の UA からリクエストの宛先として指定される SIP URIと、実際にリクエストを処理する UA の SIP URIをレジストラへ伝え、ロケーション・サーバーへの登録を要求することにある。 REGISTERリクエストは次のようなメッセージになる。
REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP client.example.com:5060;branch=z9hG4bknashds8 Max-Forwards: 70 To: sip:alice@example.com From: sip:alice@example.com;tag=1008141161 Call-ID: 75671f481397401d8f6508d51ae9a1dc@client.example.com CSeq: 1 REGISTER Contact: sip:alice@client.example.com:5060;expires=3600 Content-Length: 0
登録では、メディア情報などの特別なコンテンツは必要ないため、通常の場合ボディ部分が無い。 ”Content-Length:0”は、ボディ部分が 0 オクテットである（存在しない）ことを示している。以下では、REGISTER リクエストの中で、特に重要なヘッダーについて解説する。
例では、リクエスト URI は ”sip:example.com”となっている。 REGISTERリクエストにおいては、リクエスト URI は登録を行う「サービス」を表すドメイン名を指定する。例では、”example.com”というドメインの配下に、 UA の SIP URIとトランスポート・アドレスを登録することを意味している。
REGISTER 以外のリクエストは、その「宛先」をリクエスト URI に指定する。しかし REGISTERリクエストは例外的に、 @ やユーザーパートを含まないドメイン名をリクエスト URI に指定しなくてはならない。
To ヘッ ダーは、「誰の」 SIP URI に対して登録するかを示す。多くの場合、 REGISTER を送るUAは自分自身の SIP URI に対して、 DHCPなどで割り当てられた自分のトランスポート・アドレスを登録するもので、 To ヘッダーには自分自身の SIP URIを指定する。例では、”sip:alice@example.com”に対して登録することを示している。
From ヘッ ダー に は、 「誰 が」 SIP URI に対して登録を行うかを示す。多くの場合、 REGISTERを送る UA が自分自身の登録を行うので、 To ヘッダーと同様に、 From ヘッダーには自分自身の SIP URIを指定する。例では、 SIP URI の後に ”tag=1008141161”という「tagパラメータ」が付けられている。From ヘッダーの tag パラメータは、送り元の UAを一意に特定するための情報である。 REGISTER リクエストにおける To ヘッダーおよび From ヘッダーで、注目すべきは、「誰の」 SIP URI を「誰が」指定するのかを明確に指定できる点にある。これは別の第三者が特定の SIP URIに対し、代理で登録できる機能を SIP が備えていることを示している。 このような場合、登録が行われる UA の SIP URI （To ヘッダー）と、登録を行う UAの SIP URI（From ヘッダー）は異なることになる。一般的な IP 電話サービスでは、To ヘッダーおよび Fromヘッダーには、自分自身の SIP URIを示す同一の値が指定される。なお、第三者登録はセキュリティ上の問題を引き起こす恐れがあるが、認証機能を利用して問題を回避できる。
Call-ID ヘッダーは、 UA からの登録を識別するための、世界で唯一の ID である。最初の REGISTERリクエストを送る UA が生成する。
Contact ヘッダーには、登録によってその後のリクエストを受け取る先の SIP URI（Contactアドレス）を指定する。つまり他の UA などから、 To ヘッダーで示す SIPURIに対してリクエストが送られた場合、 リクエストは Contact ヘッダーで指定された宛先へ送られる。例では、 Toヘッダーで示される ”sip:alice@example.com”に対して、 Contact ヘッダーで”sip:alice@client.example.com:5060”を指定している。その結果、”client.example.com”のポート 5060 番へリクエストが送られる。 またこの例では、 Contact ヘッダーには ”expires=3600”のパラメータが付けられる。これはContact アドレスの「生存期間」を示すもので、その URIがどれくらいの期間有効であって欲しいかを秒単位で指定したものである。 登録は REGISTERリクエストにより「抹消」することも可能で、その場合 UA は、 ”expires=0”（有効期間が0、すなわち抹消）を指定して、 REGISTER リクエストを送る。
レジストラは、受信した REGISTER リクエストに問題がない場合、「200 OK」のレスポンスを UAへ返し、登録を正常に受け付けたことを知らせる。 REGISTER に対する 200 OK は、次のようになる。
SIP/2.0 200 OK Via: SIP/2.0/UDP client.example.com:5060;branch=z9hG4bknashds8 To: sip:alice@example.com;tag=1089012406244 From:sip:alice@example.com;tag=1008141161 Call-ID:75671f481397401d8f6508d51ae9a1dc@client.example.com CSeq: 1 RESISTER Contact:sip:alice@client.example.com:5060;expires=3600 Content-Length:0
To,From,Call-ID,Contact などの各ヘッダーは REGISTER リクエストからコピーされる。このときToヘッダーには、レスポンスの送り元を位置に特定するための tag パラメータが新たに付けられる。 また、 Contact ヘッダーの expires パラメータは、 REGISTERリクエストで要求された有効期間そのままではなく、それに対してレジストラが受け入れた有効期間になる。つまり、 REGISTER リクエストで要求した値よりも、小さな値で返される場合がある。この時間を超過すると、その登録は無効になるため、 UAはこの有効期間内に再度 REGISTER リクエストを送り、登録を「更新」する必要がある。
IP 電話における音声通話など、 UA と UA の間でマルチメディアのデータをやり取りするためには、UA間でセッション（論理的な通信チャネル）を確立し、そのセッションの中でメディアデータを送受信する。このセッションの確立は、SIP のもっとも基本的な機能であり、 INVITE リクエストによって実現される。
INVITE リクエストは、 UA が他の UA に対し、セッションへの参加を招待するメッセージである。INVITEリクエストは、相手 UA とのセッションの確立を求めるもので、メッセージ内にセッションの確立に必要な様々な値が指定される。次にINVITE リクエストの例を示し、主要なヘッダーを解説する。
INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP client.example.com:5060;branch=z9hG4bknashds8 Max-Forwards: 70 To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.com>;tag=251659630 Call-ID: 90be1379fa1a4bffa56f51d5a9428634@client.example.com CSeq: 1 INVITE Contact: sip:alice@client.example.com Content-Length: 133 v=0 o=-635372910 635372910 IN IP4 192.168.1.100 s=- c=IN IP4 192.168.1.100 t=0 0 m=audio 5004 RTP/AVP 0 a=rtpmap:0 PCMU/8000
リクエスト URI では、セッションの開設を望む相手 UA の SIP URI を指定する。この例では、 Aliceが通話を望む Bob の URI”sip:bob@example.com”を指定している。
Viaヘッダーは、リクエストがネットワーク上のどのようなパスで送られたのかを示すヘッダーで、レスポンスがそのパスをさかのぼって返信されるようにするための情報である。リクエストに対するレスポンスは、このVia ヘッダーで示されたアドレスに対して返される。プロキシ・サーバーは、リクエストを転送するとき新たな Viaヘッダーを追加し、レスポンスを転送する際には自分の Via ヘッダーを削除する。 また、Viaヘッダーには「フォーク（分 岐）した」リクエストを区別するための「branch パラメータ」が付けられる。これは「グループ着信」の機能をSIPで実現するために、プロキシ・サーバーがひとつのリクエストを複数の宛先にコピーして送る場合に備えたパラメータである。branch パラメータは、 ”z9hG4bk”で始まる一意の文字列であることが規定されている。次は、 Alice から送られた INVITE リクエストを、プロキシが Bob へ転送した時の、 Viaヘッダーの例である。
Via:SIP/2.0/UDP proxy.example.com:5060;branch=z9hG4bK69290 Via:SIP/2.0/UDP client.example.com:5060;branch=z9hG4bknashds8
Toヘッダーには、論理的な宛先の SIP URI を指定する。 SIP URIの前には電子メールと同様に、ディスプレイ・ネームも記述できる。次の例では、 ”Bob”がディスプレイ・ネームになる。
To: Bob<sip:bob@example.com>Fromヘッダーには、リクエストの送信元を指定する。 To ヘッダーと同じくディスプレイ・ネームも記述できる。 Fromヘッダーには、送り元を特定するための Call-ID に対して一意な値を持つ「tag パラメータ」が付く。通常 tagパラメータの値は、乱数文字列となる。
ヘッダー Call-IDヘッダーは、その名の通り「呼」を一意に識別するためのヘッダーである。 Call-ID は全世界で唯一な IDで、リクエストの送り元の UA が生成する。グローバルユニーク性を実現するため、一般に Call-IDは次のような文字列とされる。
Call-ID:<グローバルユニークIDまたは乱数>@<ホスト名またはIPアドレス>Contactヘッダーは、 UA がその後相手からリクエストを受ける際の URI を指定する。この例の ”Contact: sip:alice@client.example.com”によって、 Bob はその後 Aliceへ新たなリクエストを送る際には、リクエスト URI に”alice@client.example.com”を指定することになる。
CSeqヘッダーは、そのリクエストが新たに送られるものか、再送できるかを識別し、リクエストとレスポンスを関係付ける役目を果たす。CSeq ヘッダーの値は、リクエスト名とそれぞれの UAが持つ「カウンタ値」により構成され、このカウンタは新たなリクエストを送るごとに値が 1 つ増加される。 CSeqの値はそのままレスポンスにコピーされ、レスポンスがどのリクエストに対応するかを区別する。
Content-Type ヘッダーは、メッセージのボディ部分の形式を指定する。この例の ”Content-Type: application/sdp”は、ボディ部分が「SDP」であることを示している。
Content-Lengthヘッダーは、メッセージのボディ部分のサイズをオクテット単位で指定する。ヘッダーとボディの区切りの改行（CRLF）はサイズに含まれない。確立したいセッションの内容は、 INVITE リクエストのボディ部分によって示される。
リクエストを受け取ったサーバーや UAは、そのリクエストを受信して処理した結果をレスポンスにより返される。しかし電話においては、 INVITEリクエストによる呼び出しに対し、ユーザーが直ちに電話に出られるとは限らず、応答・非応答の結果をすぐに返すことはできない。 これはリクエスト送信元の UA にとっては、大きな問題となる。 SIP のデフォルトのトランスポートは UDPだが、パケットがネットワーク上で欠落する可能性がある。このため直ちにレスポンスが得られない場合には、リクエストが相手まで正しく届かなかったのか、届いたが処理中なのか、区別できない。 このため SIP では、最終的な応答を返す前に 100番台の「暫定応答」を返す。こうすることで、「リクエストは届いたが処理中」であることを、リクエスト送信元の UAへ知らせることができるようになっている。「100 Trying」は、「リクエストが届き現在その処理を施行中」であることを示している。 リクエストを受信したサーバーや UA が一定時間内（200 ミリ秒）に何らかの応答を返すことが出来ない場合、とりあえず100 Trying を返す。逆に一定時間内の応答が確実に返せる時には、 100Trying は返信しない。 この例では、プロキシ・サーバーは INVITE リクエストリクエストを受信し、適切な UA （この例ではBob）へリクエストを転送したことを示すために、 100 Trying を返す。また、 INVITE リクエストを受信したUA では、リクエストを受信して処理を開始したことを示すために、 100 Tryingをプロキシ・サーバーに返す。ここで注意すべきことは、プロキシ・サーバーは 100 Trying を決して ”中継しない”ということである。プロキシ・サーバーが返す 100 Trying のメッセージ例を次に示す。
SIP/2.0 100 Trying Via: SIP/2.0/UDP client.example.com:5060;branch=z9hG4bknashds8 To:Bob <sip:bob@example.com> From:Alice<sip:alice@example.com>;tag=251659630 Call-ID:90be1379fa1a4bffa56f51d5a9428634@client.example.com CSeq:1 INVITE Content-Length:0
Via,To,From,Call-ID,CSeq の各ヘッダーは、 INVITE リクエストからコピーされた値である。CSeqの値によって、この 100 Trying がどのリクエストに対して返されるか識別できる。また、 100Tryingにはコンテンツが無いため、ボディは存在しない。 Content-Length ヘッダーは 0 になる。
電話アプリケーションでは、 INVITE リクエストを受信した UAは、着信したことをユーザーに知らせるために、呼び出しベルを鳴らす。 180Ringing は、着信 UAが呼び出しベルを鳴らし、ユーザーに電話に応答するように促していることを示すために返される。着信側 UA(Bob)が、プロキシ・サーバーへ返す 180Ringing の例を次に示す。
SIP/2.0 180 Ringing Via:SIP/2.0/UDP proxy.example.com:5060;branch=z9hG4bK69290 Via:SIP/2.0/UDP client.example.com:5060;branch=z9hG4bk32814 To:Bob<sip:bob@example.com>;tag=2688362 From:Alice<sip:alice@example.com>;tag=251659630 Call-ID:90be1379fa1a4bffa56f51d5a9428634@client.example.com CSeq:1 INVITE Contact:sip:bob@client.example.com Content-Length:0
Contact ヘッダーには、 UA Bob がその後の新たなリクエストの宛先として望む URI が指定される。 また、 To ヘッダーには新たに「tag パラメータ」が追加されている。これはリクエストを受け付けた UAを一意に特定するための印（トークン）で、 UA Bob が生成する。セッションの確立に関する UA Alice と UA Bob の１対１の関係（ダイアログ）は、この To のTag パラメータ、 From の Tag パラメータ、そしてCall-ID の組み合わせにより識別できる。
INVITE リクエストを受け付けた UA は、その後ユーザーが電話に出ることにより「200 OK」を返す。次がその例である。200 番以上のレスポンスは、リクエストに対する最終的な回答を示している。
SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.example.com:5060;branch=z9hG4bK69290 Via: SIP/2.0/UDP client.example.com:5060;branch=z9hG4bk32814 To: Bob <sip:bob@example.com>;tag=2688362 From: Alice <sip:alice@example.com>;tag=251659630 Call-ID: 90be1379fa1a4bffa56f51d5a9428634@client.example.com CSeq: 1 INVITE Contact:sip:bob@client.example.com Content-Type:application/sdp Content-Length:92 v=0 c=-0 0 IN 192.168.1.101 s=- c=IN IP4 192.168.1.101 t=0 0 m=audio 15482 RTP/AVP 0 a=rtpmap:0 PCMU/8000
電話に出ることを示す 200 OK では、 INVITE リクエストのボディ部分で示されたセッション内容に対する着信側の UAが望むセッションの内容が、ボディ部分で示されている。
200 OK を受信した発信元 UA は、 INVITE リクエストに対する最終応答を受信したことを示すために、ACK(ACKnowledgement) リクエストを送る。これは INVITEリクエストに対する最終応答メッセージが、パケット欠落などの原因で失われた場合に備えるための仕組みである。 ACKリクエストは、両方の UA にセッション確立の状態を正しく認識させる機能を持つ。 ACK リクエストは、 INVITE リクエストの最終応答に対してのみ送られる特別なリクエストである。 REGISTERリクエストのような INVITE 以外のリクエストでは、 ACK は送られない。また、 ACKリクエスト自身に対するレスポンスがないという点も、他のリクエストとは異なる。 結論を言うと、セッションを確立する INVITE リクエストでは特別に、 INVITE/ 最終応答 /ACKの 3つのメッセージが必要になる。 ACK リクエストの例を次に示す。
ACK sip:bob@client.example.com SIP/2.0 Via: SIP/2.0/UDP client.example.com:5060;branch=z9hG4bk32814 Max-Forwards: 70 To: Bob <sip:bob@example.com>;tag=2688362 From: Alice <sip:alice@example.com>;tag=251659630 Call-ID: 90be1379fa1a4bffa56f51d5a9428634@client.example.com CSeq: 1 ACK Content-Length:0
リクエスト URI は、 INVITE に対する最終応用 (この場合は 200 OK) 中の Contactヘッダーで示された URI になる。また、 200 OK を受けた UA が送る ACK リクエストでは、 Via ヘッダーのbranchパラメータが新しい値になっている。 CSeq ヘッダーの値は ”1 ACK”となっている。通常新たなリクエストが送られるたびに値が 1増加（インクリメント）するので、 INVITE の CSeq が 1 であるならば、 ACK では 2になると思われるかもしれないが、 ACK リクエストと CANCEL リクエストについては、それがどの INVITEリクエストに対するものかを識別するために、例外的にインクリメントせずそのままの値になると規定されている。ACK リクエストが着信 UA へ届くと、 2 つの UA 間でセッションが確立する。 UAは互いに示されたメディア情報に従って、マルチメディア・データを送受信し、音声通話が始まる。
INVITE/200 OK/ACKで確立したセッションは、ユーザーの「電話を切る」操作によって、正しくセッションを切断（終了）できなくてはならない。セッションの切断は、BYE リクエストにより実現されている。
この図では、着信側 UA から BYE リクエストを送っているが、セッションの切断は発信側、着信側のどちらからでも可能である。BYE リクエストに対して 200 OKを返信することによって、セッションは正しく切断される。各メッセージについて詳しく見ていく。
BYEリクエストは、確立しているセッションを切断することを要求するメッセージである。従ってそのメッセージ内には切断するセッションを特定するための情報が指定される。BYE リクエストの例を次に示す。
BYE sip:alice@client.example.com SIP/2.0 Via: SIP/2.0/UDP client.example.com:5060;branch=z9hG4bk11345 Max-Forwards: 70 To: Alice <sip:alice@example.com>;tag=251659630 From: Bob <sip:bob@example.com>;tag=2688362 Call-ID: 90be1379fa1a4bffa56f51d5a9428634@client.example.com CSeq: 1 BYE Content-Type: application/sdp Content-Length:0
これは、着信側 UA Bob から送られた BYE リクエストです。リクエスト URI が INVITE リクエストのContact ヘッダーで、 Alice に指定された URI になっている。また、INVITEリクエストと送信の向きが逆になるため、 To と From ヘッダーが逆になっている。ただし tagパラメータはそれぞれ、INVITE リクエストに対する 200 OK からそのままコピーされ、To の tag パラメータ、From の tag パラメータ、そして Call-ID の 3 つの値によって、切断する対象のセッションが指定される。CSeq の値は、 UA Bob から初めて送られるリクエストであるため、 Bob が持つカウンタ値の 1 になる。
BYE リクエストを受け取った UA は、セッション切断を受け入れることを 200 OK により返します。BYEリクエストを受け取った UA Alice が返す 200 OK の例を次に示す。 BYE リクエストに対する200 OKにより、互いの UA はマルチメディア・データの送受信を中止し、通話を終了する。
SIP/2.0 200 OK via: sip/2.0/udp proxy.example.com:5060;branch=z9hG4bk29301 via: sip/2.0/udp client.example.com:5060;branch=z9hg4bk11345 To: Alice<sip:alice@example.com>;tag=251659630 From: Bob<sip:bob@example.com>;tag=2688362 Call-ID: 90be1379fa1a4bffa56f51d5a9428634@client.example.com CSeq:1 BYE Content-Type:application/sdp Content-Length:0
INVITE リクエストによるセッション確立要求は、相手 UAが通話中だったり、席にいなかったりするなど、必ず成功するとは限らない。このような場合、着信 UA は 300番以上の「エラー応答」によって、 INVITE リクエストを受け付けられないというメッセージを返信する。次に、着信 UAが通話中であったためにエラー応答を返す場合のシーケンス例を示す。
この例では、 100 Trying までのシーケンスは前項と同じだが、着信側 UA Bob が通話中であったために「486 Busy Here」応答を返す点が異なる。 486 Busy Here は、リクエストを受け取った UAまたはサーバーがビジー (通話中) のため、要求を受け付けられないことを示す最終応答である。 エラーを示す最終応答では、適切な内容のステータス・コードを返さなくてはならない。「404 NotFound」や「603 Decline」など多くの種類がある。 INVITE リクエストに対する最終応答によって、これを受信したことを示す ACKリクエストが送られ、メッセージのやり取りは終了する。
リクエストを受け入れられない場合に送られるエラー応答には、さまざまな種類（ステータス・コード）があるが、基本的なメッセージ内容はあまり変わらない。着信側のUA Bob が返す 486BusyHereの例を次に示す。
SIP/2.0 486 Busy Here Via:sip/2.0/udp proxy.example.com:5060;branch=z9hG4bk29301 Via:sip/2.0/udp client.example.com:5060;branch=z9hg4bk11345 To:Bob<sip:bob@example.com>;tag=2688362 From:Alice<sip:alice@example.com>;tag=251659630 Call-ID:90be1379fa1a4bffa56f51d5a9428634@client.example.com CSeq:1 INVITE Contact:sip:bob@client.example.com Content-Length:0
メッセージ内の各ヘッダーの内容は 200 OKと同じだが、エラー応答によりその後のセッションを確立することはないので、セッション内容を示すボディ部分がない。
INVITE リクエストに対してエラー応答が返された場合、 ACKリクエストの振る舞いは成功応答の場合と少し異なる。プロキシは、 INVITEに対するエラー応答を自信で処理し、エラー応答を送った UAではへ自ら ACK リクエストを送る。このプロキシが Bob に返すACK リクエストの例を次に示す。
ACKsip:bob@client.example.com SIP/2.0 Via:sip/2.0/udp proxy.example.com:5060;branch=z9hG4bk29301 Max-Forwards:70 To:Bob<sip:bob@example.com>;tag=2688362 From:Alice<sip:alice@example.com>;tag=251659630 Call-ID:90be1379fa1a4bffa56f51d5a9428634@client.example.com CSeq:1 ACK Content-Length:0
プロキシが独自に送る ACK リクエストであるため、 Viaヘッダーにはプロキシのアドレスのみが書かれる。また成功応答の場合と異なり、エラー応答に対する ACK リクエストでは、 Via ヘッダーのbranch パラメータは、 INVITE リクエストと同じ値になる。これは、 INVITEと最終応答の「リクエスト - レスポンス」の関係に対して、成功応答とエラー応答で ACKリクエストの扱いが異なる事に起因する。
INVITE/ 成功応答に対する ACK リクエストは、 INVITEのトランザクションとは「独立したリクエスト」として送られる。それに対し、 INVITE/ エラー応答に対する ACKリクエストは、 INVITEトランザクションの「一部」として送らなくてはならない。
Via ヘッダーの branchパラメータは、このトランザクションを識別するための値であるため、エラー応答に対する ACK では、 INVITEリクエストと同じ値を使用する。
このように INVITE に対するエラー応答と ACK リクエストに関しては、特別なルールが存在する。
1 つの INVITE リクエストが、プロキシによって複数の UA へフォークされた場合、「着信したUAのひとつが電話に出る＝成功応答を返す」前に、他の UA がエラー応答を返すかもしれない。これを防ぐため、 1 つの着信 UA からのエラー応答をプロキシ・サーバーで処理し、他の UA から成功応答が返るか、すべての着信 UAからエラー応答が返るまで、発信元 UA へはその結果を知らせない仕組みが必要になる。 SIPでは、こうした機能を実現する工夫が基本メカニズムに盛り込まれ、 INVITE に対するレスポンスと ACKリクエストに特別なルールが与えられている。
リクエストに対するエラー応答のうち、 300番台の応答は、「リダイレクト」という特別な機能を持つ。リクエストを受け付けることができない UAではまたはサーバーが、他の宛先へ再送信するように案内する場合に返す。 300 番台の応答を受け取った UA は、Contact ヘッダーで指定されるリダイレクト先に対して、改めてリクエストを送る。
リクエストに対して、宛先が一時的に他へ移動したことを知らせるために「302 MovedTemporarily」応答が返される。メッセージの例では、 Contactヘッダーで、新しい宛先”sip:bob@osaka.example.com”が指定されている。発信側 UA は、 302 Moved Temporarily 応答に対する ACK をプロキシ・サーバーへ送った後に、新たにこの URI に対してINVITE リクエストを再送する。 INVITE リクエストに対して、その正しい宛先を 300 番台応答で返すことのみを目的としたサーバーを「リダイレクト・サーバー (リダイレクタ）」と呼ぶ。
SIP/2.0 302 Moved Temporarily Via: sip/2.0/udp client.example.com:5060;branch=z9hg4bk11345 To:Bob<sip:bob@example.com>;tag=2688362 From:Alice<sip:alice@example.com>;tag=251659630 Call-ID:90be1379fa1a4bffa56f51d5a9428634@client.example.com CSeq:1 INVITE Contact:sip:bob@client.example.com Content-Length:0
電話アプリケーションにおいては、相手へ電話をかけた際に、相手が電話に出ないために途中で電話を切る場合がある。 SIPでは、発信の取消しを CANCEL リクエストによって実現する。
CANCEL リクエスト以降の各メッセージについて以降に 示す。
INVITE リクエストの取消しを要求する CANCEL リクエストは、 INVITE の最終応答を受信する前に送られる。発信UA Alice がプロキシ・サーバーへ送る CANCEL リクエストの例を次に示す。
CANCEL sip:bob@example.com SIP/2.0 Via:sip/2.0/udp client.example.com:5060;branch=z9hg4bk11345 Max-Forwards:70 To:Bob<sip:bob@example.com>;tag=2688362 From:Alice<sip:alice@example.com>;tag=251659630 Call-ID:90be1379fa1a4bffa56f51d5a9428634@client.example.com CSeq:1 CANCEL Content-Length:0
リクエスト URI と、 Call-ID、 To、 From の各ヘッダーは tagパラメータも含めて、キャンセルする対象となっているリクエストと同じ値でなくてはならない。また、 CSeqヘッダーのカウンタ値についても、対象リクエストと同じ値である必要がある。
CANCEL リクエストを受信したプロキシ・サーバーまたは UA （UAS）は、 CANCELが受け付けられたことを示すために 200 OK を返す。次にプロキシ・サーバーが発信元 UA Alice に対して返す、200 OK のメッセージ例を示す。 CSeq ヘッダーのメソッド名によって、この 200 OK が CANCELリクエストに対するものである事がわかる。
SIP/2.0 200 OK Via:sip/2.0/udp client.example.com:5060;branch=z9hg4bk11345 To:Bob<sip:bob@example.com>;tag=2688362 From:Alice<sip:alice@example.com>;tag=251659630 Call-ID:90be1379fa1a4bffa56f51d5a9428634@client.example.com CSeq:1 CANCEL Content-Length:0
CANCEL/200 OK によって、 INVITE リクエストへの取消しが受け付けられると、 INVITEに対して「487RequestTerminated」エラー応答が返信される。プロキシ・サーバーが発信元 UAAliceに対して返す、 487RequestTerminated 応答のメッセージ例を次に示す。 CSeqヘッダーでは、このレスポンスが INVITE リクエストに対するものであることが示されている。
SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP client.example.com:5060;branch=z9hg4bk11345 To: Bob <sip:bob@example.com>;tag=2688362 From: Alice <sip:alice@example.com>;tag=251659630 Call-ID: 90be1379fa1a4bffa56f51d5a9428634@client.example.com CSeq: 1 INVITE Content-Length: 0
SIP は拡張性が高く、簡単に開発できる利点があるが、 SIP そのものには SIPの通信を保護する機能が無い。また、メディアを転送する RTPにも保護機能は無いに等しく、音声やビデオのデータを簡単に盗聴できてしまう。
以上のことから不正な利用を許してしまう問題がある。
SIPのリクエストを盗聴し、リクエストを偽装することにより、正規のシーケンスの妨害や、不正なセッションの確立を行える可能性がある。図7は、攻撃者の SIP端末が発信側の SIP リクエストを盗聴することによって、必要な情報を獲得し、偽装された SIPリクエストを送信している例である。
なお、この節では、 SIP リクエストに対する認証については以下のような仮定をとる。
偽装されたリクエストには以下のような種類がある。
メッセージの種類によって、攻撃により受ける影響は変わってくる。
SIP 端末が INVITE リクエストなどの SIP リクエストを受信するために、自身の IP アドレスとポートを、 SIPサーバに登録ために使われるのが REGISTER というリクエストである。 既に REGISTER リクエストによって登録されている、 SIP 端末の情報 (IP アドレス等)に対して、第三者からの偽装された REGISTER リクエスト送信によって以下の行為が可能となる。
攻撃者による盗聴によって、 REGISTER リクエスト内で使用される Call-ID などの情報が分かると、攻撃者の SIP端末は「登録削除」や「登録書き換え」の偽装 REGISTER リクエストを送信できるようになる。 「登録削除」の偽装 REGISTER リクエストによって、 SIP サーバの登録情報が削除された状態では、 SIP発信端末から SIP 端末 [sip:ua@example.com] 宛の INVITE リクエストが SIPサーバ受信されても 404 レスポンスで拒否されてしまう。また、「登録書き換え」の偽装 REGISTERリクエストが、攻撃者の SIP 端末の IP アドレスで SIP サーバ上の登録情報を書き換えてしまった状態で、 SIP発信端末から SIP 端末 [sip:ua@example.com] 宛の INVITE リクエストが SIPサーバ受信されると、 INVITE リクエストが攻撃者の SIP 端末に着信してしまい、通話を横取りされる。
INVITE リクエストに対して、ダイジェスト認証などを用いてユーザを認証し たとしても、悪意のある第 3 者が CANCEL リクエストを偽装して送信した場 合、発信 SIP 端末のユーザの意図にかかわらず発信が取り消されてしまう可 能性がある。
例えば、 攻撃者の SIP 端末が INVITE リクエストを盗聴し、 Call-ID な どの必要な情報を取得することによって、偽装された CANCEL リクエストを送 信し、発信を取り消すことができる。
但し、 CANCEL リクエストを送信するタイミン グは 100 Trying レスポンスが着信 SIP 端末から送信された後でなければな らないので、 CANCEL リクエスト送信のタイミングのために 100 Tryingレス ポンスも盗聴する必要がある。
さて、 偽装された CANCEL リクエストを受信した着信 側 SIP 端末は 487Request Terminated レスポンスを送信し、着信側 SIP 端 末は発信が拒否されたと判断してしまう。 これは RFC3261 の 22.1 Framework では、 CANCEL リクエストを受け取った SIPサーバが、取り消しの対象となる INVITE リクエストと同じ経路で CANCELリクエストが送信されていることを確認する ように求められているためである。
そのために、トランスポートレイヤーまたはネットワー クレイヤーで送信元となるSIP 端末 (またはサーバ) を確認するという前提が 記述されている (ただし、具体的な確認手段に関する記述は無い)。
このような状況にも関わらず、 一般的なSIP の実装では主に UDP が使用されているので、 INVITE リクエストをネッ トワーク上でキャプチャできれば、 IP アドレスを含めて、偽装された CANCEL リクエストは、容易に作成できる。
re-INVITE リクエストとは、確立したダイアログ内で送信される INVITEリクエストのことであり、セッション確立の確認や、メディア情報 (コーデックの種類、メディア送信の保留・保留解除) の変更のために使用される。 INVITE リクエストにより正常に通話などのセッションが確立された後、偽装されたre-INVITE リクエストによって既存のセッションが乗っ取られる場合がある。 もし通話が成立した後で、攻撃者の SIP 端末から偽装された re-INVITE リクエストが送信された場合、まず、発信SIP 端末から INVITE リクエストが送信され着信側 SIP 端末との間にセッションが確立し音声による通信が行われている。このときに送受信された正規の SIPリクエストとレスポンスが、攻撃者の SIP 端末に盗聴された場合、盗聴者の SIP 端末は着信 SIP 端末には偽装した BYE リクエストを送信してセッションが切断されたように見せかけ、発信 SIP端末には re-INVITEリクエストを送信しセッションを乗っ取ろうとしている。この偽装された re-INVITE リクエストの Contact ヘッダやSDP 内には、攻撃者の SIP 端末の IPアドレスが記述されており、発信 SIP 端末は攻撃者の SIP端末と通和状態になってしまう。
INVITE リクエストにより正常に通話などのセッションが確立された後、偽装された BYEリクエストによって既存のセッションが切断され、その結果、通話が意図せず切断される場合がある。 例えば、 INVITE リクエストなどを盗聴し必要な情報を取得した攻撃者の SIP 端末が、偽装した BYEリクエストを発信 SIP 端末と着信 SIP 端末に送信することにより通話を切断している状況を考える。まず、発信 SIP端末から INVITE リクエストが送信され着信側 SIP 端末との間にセッションが確立し音声による通信が行われている。このとき に送受信された正規の SIPリクエストとレスポンスが、攻撃者の SIP 端末に盗聴された場合、盗聴者の SIP 端末は発信 SIP 端末と着信 SIP端末の両方にそれぞれ偽装した BYEリクエストを送信してセッションが切断されたように見せかけ、通話が切断されてしまう。
SIP のリクエストやレスポンスは UDP で送られる場合がある。 UDPはその仕様の範囲内では、送信パケットの受信を、送信側が確認できない。受信の確認が必要な場合は、受信側から確認のためのパケットを別途送信する必要がある。
SIP でも、 ACK以外のリクエストに対してはレスポンスを送信することが定められている。だが、レスポンスの受信をレスポンスの送信元が確認しなければならない場合があり、具体的にはINVITE リクエストの最終応答と信頼性の必要な暫定応答である。ここで言う信頼性とは、パケットの受信状態に関して、送信側と受信側の認識を同期できるという意味であり、具体的には受信確認のリクエストが正しく送受信された状態を指す。
INVITE リクエストの最終応答の受信確認に使われるのが ACKリクエストで、信頼性の必要な暫定応答の受信確認に使われるのが PRACK リクエストである。このPRACKリクエストが偽装された場合、暫定応答の信頼性が損なわれてしまう可能性がある。
例えば、着信 SIP 端末は受信した INVITE リクエストに対して 183 Session Progressレスポンスを送信している場合、攻撃者の SIP 端末はこの 183 Session Progress レスポンスの送信を盗聴した直後に、偽装した PRACK リクエストを送信したとする。このことにより受信 SIP 端末は、発信SIP 端末が 183 Session Progress レスポンスを受信したと判断するが、実際には発信 SIP端末の送信した正規の PRACK リクエストは遅れて受信 SIP 端末に届き、 500 Server Internal Error で拒否される。この時点で発信 SIP 端末は183 Session Progress レスポンスの受信を受信し、SIP 端末の確認が出来ていないと判断する。
この状態で、新たな 180 Ringing レスポンスが送信されても、発信 SIP端末は新しい暫定応答 (180 Ringing) の確認処理 (PRACK 送信) に移行できない可能性が高い。その結果、着信 SIP 端末では 180 Ringing レスポンスの再送が起こり、結局 180Ringingレスポンスの信頼性は確認されない。また、偽装された PRACK リクエストに SDPが記述されていた場合は、トーン信号の入力を促す通話前アナウンス等が横取りされる可能性もある。
偽装した SIP リクエストによる攻撃は、正規の SIP リクエストとレスポンスが盗聴されていたり、SIP認証が効力を失っている場合に成功する確率が高い。 SIP 認証が効力失っている場合とは以下のような場合が考えられる。
なお、以下に CANCEL リクエストで SIP 認証を要求できない理由を説明する。 CANCEL リクエストに関しては、認証要求の SIP レスポンス (401/407)による再送信ができないため、認証の手法が使えない。これは、再送信する際には通常 CSeq ヘッダの値を 1増加させるのだが、CANCEL リクエストの CSeq 値は取り消す INVITE リクエストと関連付けるため、 INVITE リクエストの CSeq 値と同じにしなければならないという特殊な制約があるからである。例えば、 CSeq 値が 1 のINVITE リクエストを取り消すための CANCEL リクエストは CSeq値が１で無ければならない。この CANCELリクエストが 401 Unauthorized レスポンスで認証を求められると CSeq 値を 1 増加させて CANCELリクエストを再送信することになるが、取り消したい INVITE リクエストの CSeq 値は 1 のため、対応が取れなくなる。
本項では、 invite リクエストに対する 200 ok レスポンスの偽装について説明する。 inviteリクエストに対する 200 ok レスポンスは、着信側の端末が通信に同意したことを意味するレスポンスであり、電話機の操作におけるオフフック(受話器を取り上げること) にあたる。 また、 200 ok レスポンスには通常 sdpと呼ばれるボディ部が存在し、音声やビデオなどのメディアを送受信するために必要な情報 (コーデック、 ipアドレスやポートなど) が記述されている。 200ok レスポンスが偽装された場合、以降の sip シグナリングとメディアの送受信が乗っ取られる。意図しない相手と通信させられることになる。例えば、発信 sip端末からのinvite リクエストと、着信 sip 端末からの 100 trying レスポンスを攻撃者の sip 端末が盗聴している場合、攻撃者の sip 端末は盗聴から得た情報を元に偽装した 200 ok レスポンスを発信 sip端末に送信し、着信 sip 端末になりすます。同時に着信 sip 端末には偽装した cancelリクエストを送信し、発信が取り消されたように見せかけることができる。
本項では、 invite リクエストに対する 302 moved temporarily レスポンスの偽装について説明する。 invite リクエストに対する 302 moved temporarilyレスポンスは、着信側のユーザが一時的に違う端末を使用する状態にあることを意味するレスポンスである。例えば、一時的に別室で作業中なので、その部屋で電話を取りたいような状況が考えられる。移動先の端末を示す新たな sip-uri は 302 moved temporarily レスポンスのcontactヘッダに記述され、発信側に新たな宛先への invite リクエスト送信を促す。 302 movedtemporarily レスポンスが偽装された場合、発信者の意図しない着信先と通信させられることになる。 発信 sip 端末からの invite リクエストと着信 sip 端末からの 100 tryingレスポンスを攻撃者のsip 端末が盗聴し、着信側 sip 端末に偽装した cancel リクエストを送信している点では前述の200ok レスポンスの偽装と同じである。異なるのは、発信 sip 端末に 200 ok レスポンスではなく 302moved temporarily レスポンスを送信している点である。この偽装された 302 moved temporarilyレスポンスによって、発信 sip 端末は意図しない sip 端末と通話してしまう可能性がある。
本項では、 invite リクエストに対する 404 not found レスポンスの偽装について説明する。 invite リクエストに対する 404 not found レスポンスは、 inviteリクエストの宛先として記述されている sip-uri が、 sipサーバに登録されていないことを意味するレスポンスである。
例えば、指定した sip-uri が間違っていたり、受信 sip端末が起動していない状態、あるいは、起動はしているがネットワークに接続されていなかったり、ネットワークの障害で通信不能な状態などが考えられる。 404 not found レスポンスが偽装された場合、発信者は通信不能と判断して通信をあきらめざるをえなくなる。
sip 認証は、 httpのダイジェスト認証を利用している。この認証方式は、パスワードをハッシュ値で確認するのでネットワーク上をパスワードが直接送信されることがない。通常 sip リクエストを sip サーバや sip 端末が認証するが、 authentication-info ヘッダを使ってsipレスポンスを sip 端末が認証することも可能である。しかし、レスポンスに対する認証は sip ではほとんど使われていない。これは、 sip を規定する rfc3261 の古いバージョンである rfc2543 でauthentication-info ヘッダを使わないことになっていたからである。
SIP は HTTP ダイジェスト認証のメカニズムを使用して、リクエストに対して認証を要求することができる。認証情報は SIP のヘッダとしてリクエストに記述されるが、このリクエストをキャプチャされた場合、考えられるパスワードを次々試にしてみて結果を比較するブルートフォースという手法によるパスワード解読が行われる危険がある。パスワードが解読されると、任意の SIP リクエストが作成可能となり、認証要求が無意味となってしまう。
SIP のリクエストをサーバやクライアント (UAS) が認証する場合、 RFC2617 で規定されているHTTPで使用されるダイジェスト認証の仕組みを利用する。 ダイジェスト認証はリクエストに対して、認証を求めるサーバやクライアントが401(Unauthorized) または 407(ProxyAuthentication Required) というレスポンスを返すことで始まる。前者のレスポンスにはWWW-Authenticate ヘッダが付加され、後者にはProxy-Authenticate ヘッダが付加されている。
(1) 407 Proxy Authentication Required Proxy-Authenticate: Digest realm=”atlanta.com”, domain=”sip:ss1.carrier.com”,qop=”auth”, nonce=”f84f1cec41e6cbe5aea9c8e88d359”, opaque=””,stale=FALSE,algorithm=MD5
(2) INVITE sip:bob@example.com SIP/2.0 Proxy-Authorization:Digest username=”Alice”,realm=” atlanta.com”, nonce=”c60f3082ee1212b402a21831ae”, response=”245f23415f11432b3434341c022”
上記のヘッダには”nonce”や”opaque”というパラメータが設定されていて、これらの情報を受け取ったリクエスト送信クライアント (UAC)は、自分のユーザ名とパスワードという秘密情報を加えてハッシュ値といわれる情報を計算する。 このハッシュ値を計算する関数は一般にハッシュ関数と呼ばれ、ハッシュ値から、計算の元になった入力値を求めることが非常に困難だという性質を持つ。
例えば、HTTP や SIP のダイジェスト認証では MD5 というハッシュ関数が使われる。 RFC2617 には、 MD5の実装コードサンプルが記述されている。 この関数を使ってハッシュ値を計算する場合、図中のメッセージの他に必要な情報はパスワードだけである。 言い換えるとパスワード以外の値は全てメッセージから知ることができる。 そして盗聴者は、順番に予想・生成したパスワードをハッシュ関数に適用し、得られたハッシュ値を、盗聴して得た responseパラメータと比較することにより、攻撃者が予想したパスワードが正しいか否かを判断できる。 このように総当りで予想したパスワードを比較していけば、時間はかかるがいつかは正しいパスワードを特定できる。 このような攻撃手法をブルートフォースと呼ぶ。
SIP パスワードが攻撃者に知られてしまった場合、不正な SIP リクエストが偽装され、登録の改ざん、不正な発信など SIPの機能全般が悪用される可能性がある。
ダイジェスト認証は、パスワードそのものを交換せず、 nonceなどの乱数と、ハッシュ関数の特徴をあわせて利用して、認証処理の安全性を確保しようとする方法である。しかし、 SIPのダイジェスト認証では、ハッシュ関数に入力する情報のうちパスワード以外はすべて通信路上で得られるため、パスワードの総当りで解読ができる。また、パスワードの予想には、よくあるパスワード文字列のリストとして、パスワードの候補となる単語や文字列の辞書を利用することで、パスワード解読を高速化する攻撃手法がある。なお、MD5 という計算方式そのものについては、 MD5 自体の脆弱性のため、将来的に利用が推奨されていない。米国政府の情報セキュリティの標準化組織 NIST では、 2010年以降、従来の暗号方式の一部を含めて、ハッシュ関数については MD5 ではなく 256bit の SHA1 または SHA2という別のハッシュ関数を利用するよう推奨している。これに対して、利用環境やセキュリティの要件に応じて利用基準を設けるべきとする考え方もあり、動向に注意が必要である。
SIP メッセージのボディには、その目的により様々なフォーマットが使用される。もっとも一般的なものは SDPと呼ばれる、セッション記述に関するフォーマットである。 SDP はセッションのネゴシエーション規則の一部として、メディア(音声や映像) の種類、受信アドレス・ポート、使用されるコーデックなどのパラメータを記述する際に使用される。この他に、 INVITEリクエストには、 JPEG などの画像データが載ることがある。この JPEGデータは着信ユーザに表示される。以下に、これらの情報が改ざんされた場合の脆弱性について記述する。
SDPにはメディアの受信アドレス・ポート、メディアの種類、使用されるコーデックなどのパラメータが記述されている。攻撃者の端末が途中でINVITE リクエストとその 200 レスポンスに記述されているSDPの内容を改ざんすることにより、音声メディアが攻撃者の端末を経由するようになっていると、会話の内容は攻撃者に筒抜けになってしまい、金庫の開錠番号などが不正に取得される場合がある。
INVITE リクエストには JPEG などの画像データが添付されることがある。
図10は攻撃者の端末によってINVITE リクエストが不正に中継され、ボディに JPEG ファイルが添付されている様子を示している。以下にボディに JPEG ファイルが添付された INVITE リクエストの例を示す。 添付されたファイルはユーザに表示され、発信者の意図しない画像情報が着信ユーザに提示されたり、 JPEGファイルを表示しようとする処理自体がコンピュータにダメージを与える可能性もある。
INVITE sip:bob@biloxi.example.com SIP/2.0 Via:SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 Max-Forwards:70 From:Alice<sip:alice@atlanta.example.com>;tag=9fxced76sl To:Bob<sip:bob@biloxi.example.com> Call-ID:3848276298220188511@atlanta.example.com CSeq:1 INVITE Contact:<sip:alice@client.atlanta.example.com;transport=tcp> Content-Disposition:render Content-Type:image/jpeg;name=”img10192419528.jpg” Content-Transfer-Encoding:base64 Content-Length:951 /9j/4AAQSkZJRgABAgEASABIAAD/2wBDAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQ DAwMDAwMEAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/2wBDAQcHBw0MDRgQEBgUDg4O ...
SIP で TLS 接続を開始する際の TCP 接続時に、 TCP 接続失敗を示すレスポンスパケットを受信すると、 SIPメッセージの送信を TLS ではなく、保護されていない UDP による送信に切り替えてしまうことがある。 SIP はメッセージを送信するトランスポートプロトコルとして、 TCP,UDP の他にセキュリティを考慮したプロトコルであるTLS を使用することも仕様として決められている。
TLS での接続を開始する場合、まず TCP による接続を行う。この TCP 接続確立手順に攻撃者が介入することで、 TCP接続の確立を失敗させ、 TCP 接続の失敗に関する RFC の追加手順を悪用することで、 UDPプロトコルの使用に誘導し盗聴やなりすましが容易になってしまう。 まず発信 SIP 端末が、 INVITE リクエストを送信するトランスポートとして使用する TLS の接続手順のためにSYN フラグの立った TCP の接続要求パケットを送信し、攻撃者の SIP サーバあるいはSIP 端末はこの TCP の接続要求パケットに対して TCP の RST フラグが立ったパケットかICMP(Protocol Unreachable)を送信する。発信側 SIP 端末は、この TCP パケットあるいは ICMP を受信したことにより、 TCP接続が失敗したと判断し、 RFC3261 に対する記述の誤解から UDP で SIP リクエストを再送信しようとする。
RFC3261 の「18.1.1 リクエストの送信」にはトランスポートのダウングレードに関して以下のような記述がある。「端末が大きなサイズのメッセージを送る場合、 UDP 送信に関するメッセージサイズの制限のために、そうでなければ UDP で送られた筈のリクエストを TCP 上で送った場合、コネクションを確立する試みが ICMP Protocol Not Supported を生成するか TCP のリセットを招く結果になるなら、エレメントは UDPを使ってリクエストを再試行するべきである[SHOULD]。これは、 TCP をサポートしない RFC2543 準拠の実装との下位互換を提供するためだけである。この仕様の今後の改定において、この動作は反対されることが予想される。」 RFC3261 の旧バージョンである RFC2543 では TCP のサポートがオプションであったため下位互換性への配慮からRFC3261 には上記のようなトランスポートのダウングレード規定が含まれる。 TLS も TCP の接続で開始されることから、発信側 SIP 端末が無条件にこの記述に従って動作した場合、悪意のあるSIP サーバ / 端末が TCP(RST) か ICMP(Protocol Unreachable)を送信することで、TCP の接続を UDP にダウングレードさせられる可能性がある。RFC3261 の「18.1.1 Sending Requests」に記述されているトランスポートのダウングレードに関する記述は、あくまでも TCP での接続に関する下位互換性を考慮した内容であり、 TLS の接続手順の一部である TCP 接続の失敗が UDPでの接続を強制するものではない。記述の前提も UDP での送信に関して安全上の懸念がない場合なので、発信側 SIP 端末はTLS を UDP にダウングレードすべきでない。また、ネットワーク自体が安全でない環境では TCP-RST 自体の偽装は防ぐのは難しいことも問題である。
DoS(Denial of Service) や DDoS(Distributed Denial of Service)と呼ばれる攻撃手法は、 SIP にも適用できる。意味のないリクエストを大量に作成し送りつける、あるいは別の SIPサーバを使って攻撃メッセージを増幅させるなどの手法により、攻撃対象ホストの処理能力を低下させることできる。 単純な DoS の手法は、偽装されたリクエストやレスポンスを攻撃対象の SIP端末に直接送信することである。これはサーバ認証への対応などが必要なく比較的難易度は低いと考えられる。一方閉じたネットワーク内に存在する SIP 端末を攻撃対象とする場合は、出入り口として存在する SIP サーバを経由した攻撃となる。或いは SIPサーバ自体を攻撃対象とした場合の方がシステム全体に与えるインパクトは大きいと考えることもできる。ここでは、いろいろ考えられる攻撃手法の中でRFC3261 の「26.1.5 サービス拒否および増幅」に記述されているは二つの DoS 攻撃手法を例として考える。
攻撃者の SIP 端末が INVITE リクエストを偽装する際に、攻撃対象となる SIP 端末の IPアドレス(1.1.1.1) とポートを SIP リクエストの Via ヘッダに設定し、攻撃の仲介役として利用する SIPサーバまたは端末に送信することで、身に覚えのないレスポンスが攻撃対象の SIP端末に集中する。レスポンスは、攻撃に利用される端末あるいはサーバの設定によって、 180, 200, 401 または 407などが考えられるが、攻撃目標となる SIP 端末に不正なレスポンスが送信される点で違いはないと考えられ る。
攻撃者の SIP 端末が INVITE リクエストを偽装するさいに、攻撃対象となる SIP 端末の IPアドレス(1.1.1.1) とポートを SIP リクエストの Route ヘッダに設定し、攻撃の仲介役として利用される SIP サーバに送信することで、無意味な SIP リクエストが攻撃対象の SIP 端末に集中する。攻撃目標への送信はRouteヘッダによって決定されるので、リクエスト内の宛先を表す SIP-URIは、必ずしも攻撃目標を特定するものである必要は無い。しかし、攻撃に利用される SIPサーバによってフォークされるようなSIP-URI を選択することで、リクエストを増幅し攻撃効果を大きくすることも可能である。
RTP のメディアストリームは盗聴、傍受されることがある。オープンソースのパケットキャプチャソフトを利用すると、簡単な操作でIP 電話用の音声ストリームを取り出して再生できる。
他のホストのパケットを取り出せる環境で、 RTP メディアストリームを含む IPパケットのキャプチャを行う。キャプチャしたパケットから、 RTPメディアストリームを特定し、その中から音声やビデオ、テキストなどのメディアデータを取り出すことができる。オープンソースで無料のパケット解析ソフトウェアを利用するだけでも、IP 電話の通話前後のパケットをキャプチャしたあと、双方の話者の音声を簡単に再生できる。 盗聴の対象となる RTP メディアストリーム上で、転送されるメディアの例には次のようなものがある。
RTP が暗号化されていないため、盗聴の危険があることは、 RTP の RFC1889(1996 年 1 月) の”9.Security”、” 9.1 Con↓dentiality”で指摘されている。 RTP の標準では、 RTP 内でのDES 暗号方式の利用が示唆されているが、実際は IPsec などの RTPより低いレイヤでの保護機能の利用が期待されていた。 RFC1889 の改版である RFC3550 では、 RTP メディアストリームの保護のためにSRTP(SecureRTP、その後 RFC3711 として標準化) の利用が推奨されている。 しかし、 RTP と SRTPはともに暗号化については定義しているものの、暗号化やメッセージ署名のための鍵の生成や、安全な鍵の交換については定義していなかった。その後、2004 年には MIKEY という鍵交換プロトコルが RFC3830 として標準化されたが、鍵交換に証明書が必要になるなど、実用的でないことから、 SRTP用の鍵交換方法としては普及していない。一方、現実の世界では SDP 上に鍵をそのまま記述して転送する方法が、一般の IP電話機器で普及するようになった。このように、現在に至るまで、 RTPメディアストリームを保護するための課題は鍵の交換方法に残されている。
すでに確立された RTP メディアストリームに、第三者の端末から、偽の音声やビデオの RTPメディアストリームが挿入・置換されることで、発信者が送ったメディアストリームとは異なるメディアが、受信者側で再生される。 また、 RTP メディアデータを第三者が改ざんすることで、 RTPメディアストリームの品質を低下させられたり、受信者側の再生が停止してしまう場合もある。
メディアストリームを転送する RTP に対して、 RTP の制御を行う RTCP を偽装することで、特定のRTPメディアストリームを停止させたり、参加者名のなりすまし、より低品質なコーデックへのダウングレードが可能になる。
すでに確立された RTP メディアストリームが、意図せず第三者から停止または中止させられる。第三者の端末から、特定の RTPストリーム上のどれかの端末に、特定端末になりすまして RTCP のBYEメッセージを送り届けることで成立する。このとき、意図せず RTP ストリームが終了させられた端末またはサーバ上の、 SIP レイヤのプロトコルスタック実装では、異なるプロトコル・コンポーネント間でのイベント通知機構などがなければ、 RTPストリームの終了がわからない。 SIPプロトコルや SIP 端末の制御部が RTPメディアストリームの終了がわからない場合、例えば通話は成立していて課金されているのに、音声だけが届かない、などの現象が起こる。 また、制御コンポーネントが RTP の終了を検出したとしても、偽装された RTCP BYE を受信したSIP端末は「その参加者、またはメディアソースが離脱した」ということだけがわかるため、事実上の SIPセッションの終了や、音声・ビデオのメディアストリームの終了につながる。 これらの攻撃は SIP の認証とは関係なく実行できる。また、 SIP を利用しない IP 電話システムでも、 RTPを利用している IP 電話システムは多く、攻撃が成功する可能性がある。
RTP メディアストリーム上で、 RTCPを偽装して、参加者の発番号や発信者名を別の値に置き換え、詐称できることがある。特定の RTPメディアストリーム上の端末のどれかに、偽装された RTCP のソース記述 (SDES) パケットの NAME(表示名)、 EMAIL(電子メールアドレス)、 PHONE(電話番号) を送信する。 RTCP SDES パケットを受信した RTP端末は、これらの表示名、電子メールアドレス、電話番号などをそのまま受け入れてしまう場合がある。 また、 RTCP SDES パケットは、 1 つ以上の SSRC で示される RTPメディアストリームを、CNAME(Canonical Name) によってひとつの端末やセッションに対応づける役目を持つ。 SSRC は音声やビデオのメディアストリームを識別する、一時的な値なのに対し、 CNAME はユーザ名と端末のIPアドレスなどを使って一意になるように作られる、長期間にわたって使われる名前である。CNAMEによって、「誰の」端末に「どのメディアストリームが対応する」というような対応付けができる。 しかし、 RTCPパケットが暗号化やメッセージ認証などで保護されていないと、第三者に書き換えられることで予期しない結果となってしまう。
RTP メディアストリーム上で発生するパケット損失について、 RTCP 受信報告 (RR)パケットによって、パケット欠落率またはパケット欠落数を過大に報告されると、該当するメディアストリームに使われているコーデックが、より低品質のコーデックに変更させられることがある。 低品質のコーデックに変更させられることにより、通話中の音声品質が劣化して、相手の声や周囲の音が聞こえにくくなったり、テレビ電話の画像で相手の顔や状況が判別しにくくなるなどの影響がある。また、経由する回線品質が悪いとみなされて、通話やセッションそのものが終了してしまう場合もある。
MAC アドレスを含む乱数性が低い値が使われるなど、 Call-ID が予想されやすい実装が存在する。
SIP 端末が登録に使用する REGISTER リクエストの Call-ID を予想して REGISTERリクエストを偽装することにより、 SIP サーバに記録されている CSeq値を不当に増加させ、正規の登録リクエストを受信しても、サーバが拒否してしまう可能性がある。
認証動作が不完全で、認証時の動作作業が不十分であったり、認証後のパラメータの維持や照合動作の不足により、認証が済んでいない第三者の端末からのなりすましメッセージを受け入れてしまうことがある。
不正にキャプチャして取得した SIPリクエストに記述されている。認証ヘッダをコピーして、偽装リクエストを作成することにより、チェックの甘いサーバ・端末の認証チェックを通ってしまい、偽装リクエストが処理されてしまう。または、不正に解読された認証のパスワードを使い、ランダムに作成されたnonce, opaque などのパラメータから認証ヘッダを生成して偽装リクエストを作成する。
SIP のダイジェスト認証は、 SIP リクエストを受けた SIP サーバや SIP 端末 (UAS) が 407 か 401のレスポンスに認証要求の情報を載せて SIPレスポンスを返すことで始まる。この認証要求の中には、偽装リクエストに対する耐性を高めるために、 nonce,opaqueなどのパラメータが含まれている。
WWW-Authenticate:Digest realm=”biloxi.com”, qop=”auth,auth-int”, nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093”, opaque=”5ccc069c403ebaf9f0171e9517f40e41”
SIP リクエストに対して、 401/407 レスポンスで認証要求を受けた SIP 端末 (UAC) は認証情報を追加したSIP リクエストを再送する。
Authorization:Digest username=”bob”, realm=”biloxi.com”, nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093”, uri=”sip:bob@biloxi.com”, qop=auth, nc=00000001, cnonce=”0a4f113b”, response=”6629fae49393a05397450978507c4ef1”, opaque=”5ccc069c403ebaf9f0171e9517f40e41”
このとき、 cnonce や nc などのデータを追加して、ハッシュ値 (response)を計算する。nonce,opaque は認証要求が生成される都度、サーバや UAS が新たに生成する値である。 cnonceは認証要求に対して UAC が生成するランダムなトークンで、任意のタイミングで新しい cnonce に変更できる値である。cn は同じ cnonce を使い続ける場合のカウントで 1 から始まりで 1 ずつ増えていく値である。 認証情報をチェックする側は自分が生成した認証要求や最新の認証情報のパラメータを記憶し、チェックする必要がある。例えば、自分が生成していないnonceパラメータを許容してしまうと、偽装メッセージの生成時に本来は認証要求をキャプチャしなければならないパラメータを、ランダムに生成するだけでよくなり、偽装の難易度が下がってしまう。また、nc の増加をチェックしないようなサーバは、キャプチャしたリクエストのリプレイ攻撃を受け付けてしまうことになる。
SIP サーバのソース IP アドレスを確認しない端末実装では、他の第三者から SIPサーバになりすましたメッセージを受信してしまう可能性がある。
図に示すように、攻撃者は任意の SIP リクエストを偽装して、攻撃目標の SIP 端末に送信する。SIP 端末が、 SIPサーバから受信したリクエストは無条件に信頼するという設定で動作しているにも拘らず、受信した INVITE リクエストの IPアドレスを SIP 端末が確認しないような実装であった場合、 SIP 端末は不正な SIPリクエストを処理してしまう可能性がある。
SIP 端末は、リクエストの送受信を仲介するプロキシサーバが設定できるようになっていることが多く、 REGISTERリクエストや INVITE リクエストの送信先として使われたり、 SIP 端末への INVITEリクエストの送信元となる。 SIP 端末はリクエストの送信時に SIP サーバから認証を要求されるのが一般的であるが、 SIP サーバから SIP端末へ送信される際に SIP 端末が認証要求を出すこと例は少ないと考えられる。この理由として、着信 SIP 端末が全ての発信 SIP 端末に関する認証情報を持つことが実用上困難であることが考えられる。システム全体は、発信側の SIP端末の正当性はSIP サーバが確認し、 SIP サーバは正しい SIP端末にリクエストを送信するという前提で動作しているものと考えられる。このことにより、受信リクエストの正当性はサーバがチェック済みだという前提で受信側 SIP 端末が動作可能となり、端末でのセキュリティに対する要件を少なくすることができる。しかし、限定された SIPサーバからのリクエストだという点に関する信頼性の上に成立する運用ポリシーであることから、この信頼性の確保が十分でない場合、端末でのセキュリティに重大な問題が発生する可能性がある。
SIP メッセージ中には、複数箇所に IP アドレスが記述されているが、 SIP の処理上問題のある IP アドレス(ループバックアドレス、自端末のアドレスやブロードキャストアドレスなど)をチェックしない実装では、サービス不能状態になったり、再起動しなければならないような状態になってしまう可能性がある。
SIP メッセージ中には、複数箇所に IP アドレスが記述されているが、 SIP の処理上問題のある IP アドレス(ループバックアドレス、自端末のアドレスやブロードキャストアドレスなど) をチェックしない実装では、サービス不能状態になったり、再起動しなければならないような状態になってしまう可能性がある。 偽装された INVITE リクエストの SDP にループバックアドレス (127.0.0.1) を記述したり、Viaヘッダや Contact ヘッダにブロードキャストアドレスや受信端末の IP アドレスを記述して攻撃対象の端末に送信する。このことにより、メディアを自分自身と送受信したり、レスポンスを自分自身に送信するという結果になる。自己ループ状態になった端末はサービス不能な状態になったり、再起動が必要な状態になる可能性がある。 15 は攻撃者のSIP 端末、あるいは SIP サーバが INVITE リクエストの Via ヘッダや SDP の c 行に、不適切な IPアドレスを記述している例ある。 Via ヘッダに受信 SIP 端末の IP アドレスを記述した場合、受信端末は SIPレスポンスを受信 SIP 端末、つまり自分自身に送信してしまうことになる。また、 SDP の c行にループバックアドレスが記述されていると、受信SIP端末は音声やビデオなどのメディアをやはり自分自身に送信してしまう可能性がある。
SIP メッセージは、以下の箇所などに IP アドレスとポート番号が記述される。
1, 3, 4 はリクエストの送信に関係するアドレス情報なので、 SIP サーバと SIP 端末の両方に対して影響がある。 2, はレスポンスの送信に関係するアドレス情報なので、やはり SIP サーバと SIP 端末の両方に対して影響がある。 5,は直接リクエストやレスポンスの送信に関係するわけではないが、新たなリクエストの送信時に Routeヘッダの情報として扱われるため、最終的には SIP サーバと SIP 端末の両方に対して影響がある。 6, は SIP端末あるいは、 SIP端末として動作するメディアゲートウェイが、音声やビデオなどのメディアを送信する際に使用されるので、広義には SIP 端末、狭義には SIP端末のメディアゲートウェイに影響があると考えられる。これらは、シグナリングやメディアの送受信に必要な情報であるが、ループバックアドレスや、ブロードキャストアドレスなど明らかに不適切なアドレスでもプロトコル上は記述できる。これらのアドレス情報はアプリケーションレイヤでチェックすべきだが、無条件に使用される実装が存在する。
卓上電話機タイプの SIP 端末や、電話機を接続して使用する IP 電話アダプタなどを作成する際には、組み込み OSと呼ばれる OS を使用することが多い。組み込み OSは、応答のリアルタイム性が高く、少ないメモリで動作するなどの要件があり、以下のような OS が代表的なものと考えられる。
また、これらの OS 上で SIP 端末を開発する際には、 Windows や Linuxなどの別プラットフォーム上で、バイナリコードをクロスコンパイルし、実際のハードウェアにアップロードして動作させるという開発手法が一般的で、この際ソフトウェアの起動状態、内部遷移状態、各種パラメータ等を実際に動作している状態で確認する手段として、リモートデバッグという手法が用いられる。リモートデバッグとは、組み込み OS が動いているハードウェア (ローカル側と呼ぶ) と、デバッグソフトウェアが動作している Windows やLinuxなどの開発マシン (リモート側と呼ぶ) をシリアルケーブルや、 IPネットワークで接続し、必要なデータをリモート側で読み出したり、ローカル側のデータを書き換えて実行させる処理である。このようなリモートデバッグ機能に接続できてしまう製品がある。
GDB(GNU Source-Level Debugger) などのリモートデバッガを使って、下記の手順で機器のOS(VxWorks など) 上で任意のバイナリコードを実行される可能性がある。
リモートデバッグ機能は、開発時に非常に有効な機能であるが、製品出荷時には停止させなければならない。本節の問題は、この機能をオフにしないで製品を出荷していることである。ポートスキャンを行えば容易に接続ポートは判明してしまい、特定環境での初期設定を知っていれば接続できてしまう可能性がある。リモートデバッグ機能は強力なバックドアとして働くため、開発環境以外でこの機能を使うことは非常に危険である。
SIP 関連プロトコルを利用した機器で、 SIP関連プロトコル以外の、管理、設定、監視などの機能や使い方に脆弱性が含まれていることがある。これら脆弱性を利用して、攻撃者は管理権限を奪取したり、ID やパスワード、構成情報を収集できる。 SIP 関連プロトコルを利用する機器は、 TCP/IPをベースにした複数の機能から構成されていることが一般的である。ここでは SIP関連プロトコル以外の、管理機能と管理設定に関する問題について説明する。ここで言う管理機能とは、 SIP関連プロトコルを利用する機器を適切安全に利用するために、必要な設定を行ったり、機器を構成したりするための機能を指す。 こうした管理機能が適切に利用されていなかったり、機器の出荷時の設定が不適切な場合に問題が発生することがある。
SIP関連プロトコルを利用する製品、機器の設定管理インターフェースにはいくつかの方法がある。代表的な方法には以下のような方法がある。
これらの方法で設定管理機能が提供されるときに、認証なしに設定変更ができるようになっていたり、マニュアルに記載されたデフォルトのIDとパスワードがそのまま使えるようになっていて、他のネットワークの任意のホストに対して応答するものがある。攻撃者は設定管理機能を利用して、そのSIP 関連機器が利用する SIP プロキシサーバの IP アドレスを変更して、その機器が利用する SIP セッションをすべて盗聴したり、その機器の SIPセッションのすべてに介入することができるようになる。その結果、本資料で紹介した SIP/RTPへの攻撃が非常に実行しやすくなる。
SIP 関連プロトコルを利用する製品、機器の設定情報や構成情報をダウンロードするために使われる、 TFTPをパケットキャプチャすることで、攻撃者は設定に含まれる IDとパスワード、その他の構成情報を収集できる。また、一部の機器では、任意のリモートホストに対して、機器のMACアドレスとファームウェアのバージョン番号を無制限に応答するものもあった。攻撃者に設定管理用の IDとパスワードが漏れれば、攻撃者はその機器を自由に設定変更できるようになる。すると、攻撃者は偽装した SIPプロキシサーバを設定して、その機器が利用するすべての SIP セッションを盗聴したり、 SIPセッションに介入できるようになる。
SIP関連プロトコルを利用する製品、機器の一部には、ファームウェアの更新機能がないものや、非常にしにくいものがある。また、メーカによっては機器の脆弱性が発表されても、ファームウェアの更新が半年以上にわたって提供されない場合がある。既知の脆弱性を持ちながら、脆弱性対策がしにくい機器を狙って、攻撃者は容易に機器への攻撃を行うことができる。
SIP 関連プロトコルを利用する製品のマニュアル (取り扱い説明書)などのドキュメント、が不足していることがある。特に、運用上の脆弱性につながる重要事項が説明されていない場合に問題がある。例えば、機器が持つ専用の管理プロトコルの存在と、製品出荷時の動作状況がドキュメントに書かれていないと、導入設計時にファイアウォールで適切に保護されず、容易な攻撃を許してしまうことがある。また、出荷時の管理用の ID とパスワードの内容と、ネットワーク経由での利用条件についても、利用者に説明されていないと、 IDとパスワードが適切に管理・防御されない。
管理機能に関する問題は、脆弱性を研究する分野では「設定の問題」とも言われている。 しかし、本資料ではあえて管理機能の問題とした。その理由は、設定作業は管理機能がなければ行うことはできず、管理機能が適切な設定方法やデフォルト値を提供することが非常に重要だからである。
機器や製品の設定変更やパスワード変更などを行う、管理インターフェース (I/F)を利用することは、機器を乗っ取ろうとする攻撃者にとっても、たいへん利用価値が高い手段である。 管理 I/Fのアクセス制御は、攻撃者や許可されない第三者の利用を制限するための重要な機能である。 一般的には、 SIP関連プロトコルを利用する機器は出荷時に管理者パスワードを設定したり、機器の起動時に TFTPなどによって設定ファイルをダウンロードすることでアクセス制限方法が設定される。
出荷時に管理者パスワードを設定する方法は、取扱説明書などにパスワード文字列を書いて利用者に渡すことになり、誰にでも知られやすいものとなる。 そのため、機器や製品の起動時に、パスワードを更新するまではネットワークに接続しないか、機器と同じIP セグメントに対してだけ管理 I/Fへのアクセスを許可する、などのアクセス制限が必要とされる。
もともと TFTPはルータやスイッチなどのネットワーク機器の設定情報をファイルの形でサーバに置いて集中管理するために利用されているプロトコルである。 TFTP は特に組み込み機器用に、認証なしの簡単な手順でファイルをダウンロードできるプロトコルで、 UDP上で利用する。
通常、 TFTP に暗号化機能はなく、ファイルの内容をそのままUDP パケットで転送する。 本来TFTPは管理用に利用するため、通信事業者などの運用者は管理専用のネットワークを物理的または論理的に分離して、一般ユーザや第三者がTFTPサーバにアクセスできないようにするのが普通である。
具体的には、ネットワーク機器の管理用 Ethernetポートや管理用 IP アドレスを、 VLAN やトンネルを使って分離 する。
IP 電話機などの SIP関連機器では、簡易な実装と処理が可能なため、 TFTPを利用した構成情報のダウンロードやファームウェアの更新ができるようにしている。 しかし、 IP電話機のような機器にも、ルータやスイッチ並みの管理通信の保護が適用されていないと、構成情報が第三者に漏れてしまうことになる。
管理用 WEB ページに、 XSS(クロスサイトスクリプティング) 脆弱性やXSRF(クロスサイトリクエストフォージュリ) 脆弱性があると、管理者のブラウザを経由して、管理WEBインターフェースに任意の JavaScriptを埋め込まれて実行されたり、利用者が意図しない操作を勝手に行われることがある。その結果、管理 WEBインターフェースが攻撃者によって事実上、乗っ取られてしまうことがある。また、管理 WEB サーバ内にSQLインジェクション脆弱性があると、やはり管理 WEB が提供していない機能まで含めてデータベース機能の制御が奪われる。管理 WEB ページ上の XSS 脆弱性、 SQLインジェクション脆弱性の問題は、 SIP サーバ機能が複雑になるのに従って、 IP-PBXなどにおいても事例が報告されるようになった。また、管理機能の乗っ取りにより、 IP電話サービスの不正な利用や課金情報の不正操作への危険性も指摘されている。
ファームウェアの更新機能は Webブラウザで利用できる機器が多いが、一部の機器は保守用のシリアルポートや、フラッシュメモリカードの交換などで更新機能が提供されていたり、機器そのものをメーカに返送して書き換えてもらう場合もある。シリアルポートは直接 IPネットワークに接続できないため、ファームウェアを更新するためには機器が設置してある現場に出向くか、機器を管理者の手元に移動しなければならない。フラッシュメモリカードを交換する場合も、同様である。メーカへの機器の返送には輸送期間と費用がかかることや、その間機器が利用できなくなることから、ファームウェアの更新は非常にしにくいものとなる。ファームウェアの更新が遅いメーカの問題は、格安の機器を販売しているメーカや、保守サービスを提供していないメーカに目立つ。どうしても格安の機器を利用する場合は、脆弱性対策として運用上の対応策をとる必要がある。
SIP 関連プロトコルを利用する製品、機器に対して複数の方法で、登録された ID や、内部の構成情報を収集される場合がある。
インターネット検索エンジンを利用して、 SIP関連プロトコルを利用する製品、機器が内蔵している管理ページに特有のキーワードや検索キーを指定して検索する。検索結果として、インターネットからアクセス可能な、稼動中の製品や機器の管理ページ、稼働中の製品の IPアドレスの一覧を収集できる。攻撃者は稼働中の製品の管理ページにインターネット経由でアクセスし、製品の出荷時の管理用ID とパスワードを試して、 SIP プロキシサーバや SIP アドレス、 DNS や NTPのアドレスなどの管理情報を収集することができる。一般的に、基本的な SIP/RTP製品の管理ページに含まれる設定情報には次のようなものがある。
または固定 IP アドレス、デフォルトルータ IP アドレス、 DNS サーバ IPアドレスまた、検索エンジンを利用した情報収集では、特定組織の電話番号を収集して、複数の部署や関連会社をまたがった、電話番号と窓口の一覧が取得できる。さらに、場合によっては公開されるべきではない、組織内の電話番号や、内線番号も収集できる場合がある。
SIPアドレスが既存の公衆電話網に使われているような、連続した数字である場合、攻撃者はコンピュータプログラムやバッチ処理を使って連続した番号に発信することで、大量のSIP アドレスに対して自動的に電話発信ができる。スパム (SPAM) と呼ばれる、迷惑メールと同じ手口と同じように、IP 電話を使った迷惑電話を、 SPIT(Spam for Internet Telephony)などと呼ぶ。SPIT では、攻撃者は IP電話の受信者に対して、自動的に商品を説明する音声データを再生したり、偽の「ID やパスワードの入力」といった詐欺を実行する。偽のガイダンスに従って、テンキーを押して IDやパスワードを入力すると、攻撃者はトーン信号の音声認識処理によって、 ID とパスワードが攻撃者の手に渡ってしまう。
SIP 関連プロトコルを利用する製品、機器が SNMP(Simple Network Monitoring Protocol: ネットワーク管理プロトコル) に応答することがある。攻撃者は機器の一覧や構成情報を得るために、SNMP のデフォルトポート番号で特定の IPアドレスを持つホストに、よくある SNMP コミュニティ名を指定して問い合わせを行うと、機器が SNMP の問い合わせに応答してしまうことがある (SNMP Read)。応答する機器に対しては、 SNMP Walkと呼ばれる、構成情報を繰り返し再帰的に問い合わせる処理を行い、ネットワークインターフェースの一覧や、 IPアドレスの一覧、オープンしているポートの一覧やホスト名などの構成情報をとりだされてしまう。また、 SNMP を使った、機器への設定投入も可能な場合 (SNMP Write)、攻撃者が機器の設定を勝手に変更してしまうこともある。
保護されていない SIP の通信をパケットキャプチャして、 SIP のヘッダにある SIP URI を収集することで、SIP 通信に使われている SIP の ID 一覧を攻撃者に収集される。攻撃者は IDの一覧を利用して、別の攻撃を行う準備をする。
SIP サーバの実装の中には、 SIP の OPTIONS 要求や SIP の REGISTER 要求に対して、SIP アドレスが存在するかどうかわかるような応答を返すものがある。こうした応答を判別することで、ありがちな SIP アドレスの一覧を SIP サーバに問い合わせ、実際に SIP サーバに登録されている SIPアドレスの一覧を選別することができる。攻撃者は SIP アドレスの一覧を利用して、別の攻撃の準備を行う。
一般に、インターネット検索エンジンを利用した、非公開情報の収集手法は、「検索エンジンハッキング」などと呼ばれる。最初にまとめられた検索例は2003 年の Defcon の資料「Watching the Watcher」に見られる。
もともとインターネット検索エンジンは、「クローラー」または「ボット」などと呼ばれるソフトウェアを使って、自動的にインターネットから Web ページを収集している。
クローラーは一般公開されている Webのみを収集しており、一般的にインターネット検索エンジンのクローラーは、 IDやパスワードを使わずに閲覧できるページだけを収集している。しかし、 IP 電話機や呼制御サーバなどの SIP 関連プロトコルを利用する機器を、インターネットに公開されたページからリンクしてしまったり、機器へのアクセス履歴や、ログファイルの一覧などを一般に掲示公開すると、インターネット検索エンジンのクローラーにもWeb ページが収集されてしまう。 一旦、 Webページが収集されると、インターネット検索エンジン上で特定のキーワードを指定すれば検索可能となる。一部のインターネット検索エンジンにある検索オプションで、「タイトル内文字列検索 ” intitle:”」や「URL 内の文字列検索”inurl:”」などを利用すると、簡単に管理ページや特定の設定ページを検索できる。 また、「数字..数字」という検索パターンでは、連続した数字の範囲を検索することができるため、電話番号の検索に利用できる。
インターネット検索エンジンでは、一般公開された情報を収集し、それを検索できるようにしているが、検索文字列から、必ずしも悪意があるかどうかを特定することはむずかしい。 そのため、基本的にはサイト管理者が秘密にしておくべき情報は公開しないか、アクセス制限を適用するなどの、適切な対応が必要である。また、本報告書のほかの項目で指摘するように、 SIP 関連機器は基本的に閉じたネットワークで利用することが望ましい。そのため、インターネットからSIP関連機器をアクセス可能にするかどうかは、十分な配慮が必要である。
サイト管理者はクローラーを拒否することもできるよう、 robots.txt というファイルに、 Webページの収集可否を宣言することもできるが、インターネット検索エンジンは必ずしもrobots.txtに従っているとは考えられないため、 robots.txtによるアクセス制限には限界がある。検索エンジンハッキングが指摘する運用上の注意点としては、このほか、ディレクトリの一覧表示を行わないことや、開発途中のサイトやネットワーク情報のまちがった公開への注意、運用中のサイトの秘密情報を検索してみる確認作業、などを勧めている。悪意のある検索キーワードを収集してデータベース化しているサイトもあるので、Web サイト管理者やネットワーク管理者は定期的な検査をすることが求められる。
SNMP は組み込み型のネットワーク機器が標準的に搭載する、ネットワーク管理機能である。 SNMPを使った管理サーバなどから、管理対象の機器に対して、 SNMP の情報取得リクエストや情報設定リクエストを送信して、機器が構成情報を応答したり、機器内部の設定を変更する。
似たような機能は、HTTP 上での Web ページでの管理設定機能にもあるが、 Web ページ上の管理設定機能は人間に対する GUI提供が目的であるのに対して、 SNMPはユーザインターフェースなしの管理機能のみの提供が目的にある。 現在の設定管理の主流は GUI ベースの Webページによる管理であり、一部の高機能機器では、 XML をベースにした高度な設定や認証機能が提供されている。 一方、SNMP はUDP上で、簡単な認証機能と、単一のツリー状の名前付けルールによって統一的に設定や管理情報を参照できる。
もともとルータやスイッチなどの組込機器が、あまりメモリやCPU を持っていなかった時代に考案されたプロトコルだが、 IP電話機やネットワーク対応プリンタのような簡易な組込機器にも搭載されている例が多い。 しかし、 SNMPを実装した IP電話機製品の多くが、出荷時の認証機能は無効になっており、識別名としての「コミュニティ名」も共通のものとなっている。
また、機器出荷時のSNMPでのアクセス制限がなく、どのネットワークからも受け付けるようになっている。 そのため、攻撃者から共通のコミュニティ名を使って問い合わせされると、応答してしまうことが多い。 また、SNMP でアクセスできる構成情報 (オブジェクト)は単一のツリー状になっているため、再帰的に所定のオブジェクト名を指定することで、ほとんどすべての構成情報にアクセスすることができる。
SIP 関連プロトコルを利用する機器を導入する場合は、 SNMPへのアクセス方法を適切に制限する必要がある。また、導入後も定期的な検査が必要である。
すでに公衆電話網でも問題になっているが、コンピュータによって自動化された発呼処理によって、セールスや詐欺を試みる攻撃者が存在する。このような手口を「SPIT」と呼ぶ。連続した数字を使った電話番号体系を使う限り、連続した番号への自動発呼そのものを制限することはむずかしいが、受信する側での SPIT への対応方法が、 IETF で議論されているので、参照してほしい。 (A Framework for Reducing Spam for InternetTelephony)
SIP の通信を保護していない場合、 SIP のヘッダには自ホストまたはあて先ホストのSIPアドレスが生のテキストで書かれているため、パケットキャプチャすれば SIPアドレスを収集することができる。その他の SIP の脆弱性への対策と同様に、閉じたネットワークを利用するか、 SIPの通信自体を TLS や IPsec などのプロトコルを利用して保護する必要がある。
SIP のパケットをキャプチャする方法が受身的な方法なのに対して、 SIPサーバに対して問い合わせメッセージを送信して ID の一覧を得るため、この方法は能動的な方法である。
SIPサーバは、それぞれのリクエストに対して、相応のレスポンスを返す。このとき、レスポンスの内容を確認すると、 IDが存在する場合と存在しない場合に、レスポンスが異なっている実装がある。例えば、 ID が存在しない場合の REGISTER リクエストに対して「その ID は存在しない」などと応答し、 ID が存在する場合のREGISTER リクエストに対しては「認証が必要です」などと応答する場合である。 このような応答をする SIPサーバに対して、よくある ID や辞書を使って、手持ちのすべての ID の問い合わせを行うと、 SIPサーバ上にも存在する ID が確認できることになる。
一般に、 SIP サーバは IDが存在するかどうかに関わらず、異なる応答をしないような実装が求められる。 なお、 OPTIONS リクエストを利用して、SIP サーバや SIP プロキシサーバの存在を確認する手法もある。
IDの収集対策も含めた対応をするためには、閉じたネットワークを利用するか、 SIP の認証か別の認証結果を元にした SIPリクエストの利用制限を行う必要がある。
TLS を実装して利用する場合、適切に利用しないと、保護の効果が失われ、攻撃者によって成りすましをされ、 TLS暗号セッションに介入されることがある。その他 TLS の利用上の注意点をまとめる。
TLS には、いくつかの攻撃手法があるが、そのうち、不正なサーバ証明書を利用して TLS接続でなりすましを行い、第三者として暗号セッションに介入する攻撃についてとりあげる。 このような第三者による介入は「Man in the Middle(MITM) 攻撃」や「中間攻撃」あるいは「第三者介入攻撃」などと呼ぶ。
例えば、 TLS の暗号セッションを SIP 端末と SIPサーバの間で確立しようとしたが、攻撃者によって割って入られ、介入されてしまった場合、 SIP 端末は TLS接続を開始するため、 SIP サーバに対して TLS 接続要求を送信するが、攻撃者は ARP 偽装や DNS 応答偽装などの手法を利用して SIPサーバに成りすまして、 SIP 端末と攻撃者の間で TLS暗号セッションを確立する。一方、攻撃者は SIP サーバ側に対して、 SIP 端末に成りすまし、 TLS暗号セッションを確立する。
攻撃者は TLS 暗号セッションに介入することで、 SIP 端末と SIPサーバのそれぞれの通信内容を入手することができ、両方に対して成りすますことができる。そのため、 TLS暗号セッションに介入されたあと、 SIP 端末が SIP サーバに送信した SIP REGISTER メッセージとその中に含まれるユーザ名が復号されて攻撃者の手に渡り、そのまま SIPサーバに成りすまして送信される。その後交換される、 SIP サーバからのチャレンジ文字列や、 SIP端末からのチャレンジ応答についても同様に攻撃者の手にわたることになる。
TLSでは、安全に暗号セッションを確立するために、公開鍵証明書を利用するが、図の成りすましの例では、公開鍵証明書が適切に利用されないときに起こる。公開鍵証明書が適切に利用されていない例は次のものがある。
その他の TLS の不適切な実装と利用方法について、一覧をまとめておく。 2008 年 9 月現在、TLSのバージョンは 1.2が最新である。過去のバージョンでは、複数の脆弱性に対応するなどの対策が行われているため、最新のバージョンを利用することが望ましい。
攻撃者によって RTP パケットを盗聴される環境では、 RTP 上のメディアストリームを保護する方法のひとつとして、SRTP(Secure RTP) を利用することができる。 SRTP では、メディアストリームの暗号化のための共通鍵(以下、共通鍵) を、 SIP メッセージ上にある SDP 内で交換する。 SIP メッセージ上の SDP 内で SRTP 用の共通鍵を交換するとき、実装によっては共通鍵そのものが生のテキストで記述されていることがある。この場合、 SIP メッセージを盗聴できる環境では、 SRTP用の共通鍵を攻撃者が容易に入手でき、暗号化されたメディアストリームの内容が攻撃者によって解読されたり、改ざんされる可能性がある。
攻撃者は通信路上で、他のホストのパケットを取り出せる環境で、まず攻撃対象の SIP 端末が送受信する SIP メッセージを含むIP パケットのキャプチャを行う。この中から、 INVITE メッセージと 200 OK 応答に含まれる SDP を取り出し、さらに a=crypt行で始まる、暗号鍵の記述を取り出して、送受信者のそれぞれの SRTP 用の暗号鍵をとりだす。 a=crypt行で始まる暗号鍵の記述例を以下に示す。各行はそれぞれ 1 行で記述するが、長い行は改行したあと、先頭に空白を挿入して連続行としてみなしている。この例はRFC 4568 の例だが、a=crypt 行が 2 行あり、最初の行はビデオのメディアストリーム用の暗号鍵が、次の a=crypt行は音声のメディアストリーム用の暗号鍵が記述されている。
v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com(Jane Doe) c=IN IP4 161.44.17.12/127 t=2873397496 2873404696 m=video 51372 RTP/SAVP 31 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 m=audio 49170 RTP/SAVP 0 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 m=application 32416 udp wb a=orient:portrait
その後、 SRTP のメディアストリームが確立されたら、さきほど取り出しておいた SRTP 用の暗号鍵を使って、 SRTPメディアストリームをキャプチャしながら解読し、メディアストリームの内容を盗聴する。 SRTP メディアストリームの盗聴による被害は、 RTP メディアストリームの盗聴による被害とほぼ同様である。例えば、 IP電話の通話中の会話、 IP 電話で音声自動応答システム (IVR)などに入力するプッシュ番号、テレビ会議でのビデオカメラの映像やアプリケーションの画面例、などが攻撃者に知られることにつながる。ただし、一般的にSRTP で保護するようなメディアストリームの内容は、 RTP だけを使う場合に比べると、よりリスクが高いコンテンツであると考えられる。また、 RTP パケットには、 RTP を制御するための、 RTCP(リアルタイム制御プロトコル:Realtime Control Protocol) の情報も含まれているため、 RTP メディアと同様に、 RTP の品質レポートや RTPの発信者情報なども露出する。
SRTP[RFC3711] は音声やビデオのようなリアルタイムなメディアストリームの転送処理のために、 RTPパケットのうち、保護する対象をできるかぎり最小限にとどめた方式である。
IPsec では最大で、 IPパケット全体が暗号化されるが、 SRTP では RTP ペイロードのみが暗号化される。
SRTP の問題は、暗号化やメッセージ署名に使う、暗号鍵の交換方法を定めていない、という点である。 そこで、 RFC 4568 では、 SRTPに限らず、メディアストリームで利用する暗号化やメッセージ署名のための共通鍵を交換するために、 SDPに暗号方式や鍵データを記述する手順を標準化している。
SIP メッセージ内の SDP 上に”a=”属性の値として記述され、 a=crypt 行として記述される。この方法を業界では”sDescription(SDES) での鍵配布”などと呼ぶ。 しかし RFC4568 では、 SRTP 用の暗号鍵の保護は RFC4568 仕様の範囲外であり、SDP内の暗号鍵はバイナリデータをテキスト形式に変換して記述しているだけである。そのため、第三者が SDP 上に記述された暗号鍵を、 SIP メッセージを盗聴するなどして入手すれば、簡単にバイナリデータに復号でき、 SRTPで暗号化されたメディアストリームを解読するために再利用できてしまう。
SRTP のための鍵交換を保護する対策としてはいくつかの方法がある。
まず、 SDP を含む、 SIP メッセージ全体をTLS や IPsec などで保護する方法がある。また、 SIP メッセージのヘッダを除く、ボディ部分だけを暗号化する S/MIME で SDP 全体を保護する方法もある。また、 SDP のうち鍵交換の処理だけを、 MIKEY やZRTP、 IKEなどで処理する方法もある。それぞれの利点と問題は以下の表のようになる。
ここで共通の条件にしているのは、 SRTPの暗号鍵交換を保護するためには、 SRTP のメディアストリームを確立する端末間で直接行う必要がある、という点である。 SRTP 用の鍵交換の保護については、 SIP との間で目的のズレがある。 SIP は柔軟な呼制御を提供するため、SIP 端末の間に SIP サーバや SIPプロキシが介在して、セッションの転送や保留、認証や課金、複製や変換などさまざまな仲介処理を行う。一方、 SRTPはSIP による呼設定が終わったあとで確立する、 1 対 1 の対向通信であり、仲介処理はSIPほど必要ではない。そのため、 SRTP では端末間でのエンドツーエンドの暗号鍵の交換が必要になる。 このように RTP メディアストリームの保護を重視する場合は対向でのエンドツーエンドの鍵交換と暗号化が必要になり、SIP の柔軟な呼制御機能を重視する場合は SIP サーバを介したホップバイホップの処理を可能にするため、 SRTPの鍵交換は SIP とは独立して処理することが理想になる。 そこで、 TLS の UDP 拡張である DTLS(RFC 4347: Datagram Transport Layer Security)を利用して、 SIP とは独立に、安全に生成・交換された鍵を SRTPのための暗号鍵として使う標準仕様が DTLS-SRTP として提案されている。
DTLS-SRTP では、よく普及して長年の実績がある TLS を利用して、安全に鍵を生成する。その上で SRTPの対向にあたるホスト間で安全に鍵を交換し、 SRTP の暗号鍵を生成する手順である。 DTLSだけでメディアストリームを暗号化するには処理が重すぎるため、 DTLS は鍵の生成と交換の処理までに限定されている。そのあとのメディアストリームの暗号化処理はパケット数が多いため SRTPに処理させている。 DTLS-SRTP はまた、 SRTP の鍵交換を保護するが、 SIP自体の保護は行わず、別の方法を利用する前提となっている。このような SIP と RTPの保護を個別に独立して考え、分担させる方法については、 DTLS-SRTP framework(Framework for Establishing an SRTP SecurityContext using DTLS)としてまとめられている。
VBR(Variable Bit Rate: 可変ビットレート) で音声メディアを符号化または圧縮すると、SRTP(SecureRTP) で暗号化したとしても、個々のパケットの長さの違いと送出パターンを分析することで、SRTP用の共通鍵がなくても元の音声 (2008 年時点で英単語) を解読される可能性がある問題。
他のホストのパケットを取り出せる環境で、 SRTP メディアストリームを含む IPパケットのキャプチャを行う。キャプチャしたパケットから、音声の SRTP メディアストリームを特定する。 音声メディアストリームが VBR(Variable Bit Rate: 可変ビットレート) で符号化または圧縮されている場合、それぞれのパケットの長さと、パケットの送出パターンについて、事前に作成しておいた送出パターンの辞書と照らし合わせながら分析することで、発声された単語を予想する。 2008 年 3 月の [VBR 解析] によれば、この方法による音声の解読の成功率について、特定の英単語については 90は約 50 務内容や専門分野に適応した辞書を作成し、利用する必要がある、と指摘されている。この、 VBRのパケット送出パターンによる音声解析は、 RTP メディアの暗号化、復号のための鍵をまったく必要としない。そのため、暗号化の前後でパケット長が同じになるような暗号化方式では、暗号化によるデータの保護がまったく意味を持たない点が重要である。
RTPでは、音声やビデオなどのメディアストリームはすべて、デジタル化された信号で転送される。デジタル化するためには、なんらかの符号化を行う。
例えば、マイクで収集した信号は、音声アナログ信号だが、これをG.711 という符号化方式を利用すると、アナログ信号に対して毎秒 8,000 回、 8ビットの符号でデジタルの値に変換を行う。このような G.711 の PCM 符号化では、毎秒 64Kbpsの、符号化されたデータが得られるため、固定ビットレート (CBR: Constant Bit Rate) と呼ばれる。 VBRは、音声やビデオなどのアナログ信号をデジタル信号に符号化するとき、常に同じビットレートではなく、元のアナログ信号の特徴に応じた、可変長のビットレートで符号化または符号化後に圧縮する方法である。
JPEG や MPEGなどでは、人が色や音を認識するときに、細かく判別できる色域や音量に偏りがあることを利用しているため、圧縮後のデータ量を可変にできる。
RTPでの音声符号化と圧縮では、特に人の会話に最適化されている方法の場合、人体の声帯のふるわせ方や、口の発音の動作から、音声の特徴を抽出する符号化が行われている。
このような音声符号化方式には、CELP(Code-Excited Linear Prediction) がある。 CELPは音声の特徴をコードブックという辞書に持ち、音声データから辞書に含まれるデータを符号の形で抽出して圧縮する。
CELPは人体に共通な音響的な特徴を辞書に持つことによって、特定の国や地域の言語には関係なく圧縮効果を得ることができる。また、CELP方式では、音声の特徴を整理した辞書内の項目数が多ければ音声の詳細度が高くなり、ビットレートが高くなる。
その反対に、辞書内の項目数が少なければ、音声の詳細度が低くなり、ビットレートも低くなる。特にCELP の派生方式である QCELP と Speex は VBR方式を採用しており、 音声品質を向上するために発音の種類に応じて高速に音声符号化のビットレートを変化させている。 また、会話や単語の間の、断続的に細かく声が途切れる状況に対しても、符号化データを削減したり、音声データを生成しない処理(VAD: 発話区間検出) が行われている。 こうした VBRに対応した音声符号化や圧縮と、無音の処理によって、単語や会話は音声データにしたときにパケット長とパケット数が大きく異なることになる。 こうしたパケット長とパケット数の変化は元の発音や会話を予想するのに利用できる。こうしたVBR ビットレートの解析を実際に行い、特定の英単語について 90 とする論文が、 [VBR 解析] である。
従来、このようなトラフィックパターンによる解析は Winny や Skype のような暗号通信を利用する P2Pファイル交換トラフィックの発見や抽出に利用される事例があった。 音声についてはさらに短いパケット長で、多数のパケットに対して、より面的なパケット量分析が行われている。
本論文にて取り上げた SIP プロトコルに関する脆弱性を考慮した対策以下に示す。
ネットワークを物理的または論理的に分離または隔離し、 SIP/RTP を使用するネットワークと、それ以外のネットワークをEthernet の VLAN 機能や、 802.1X 認証、無線 LAN の仮想アクセスポイント機能や、マルチ SSID機能などを利用して、認証を成功した端末だけが、特定のネットワークに接続できるように、管理、制御する。 SIP/RTP 関連プロトコルを利用する上での「閉じたネットワークの利用」で行われる制御の中身は、 SIP/RTPとは異なる、 IP レイヤや Ethernet レイヤでのアクセス制御である。言い換えれば、 SIP/RTPに通信内容を暗号化するなどの保護機能が普及していないため、 SIP/RTPよりも下の通信レイヤで保護することが「閉じたネットワーク」となる。
IPSec(Internet Protocol Security) は RFC 2401 ～ 2412、 RFC 2451などで規定されている IP の拡張プロトコルである。 1995 年に IETF によって最初の標準化がなされた後、 1998年に改訂されて現在に至る。現在広く使われている IP （IPv4）では、オプションとして利用可能な拡張だが、次世代IP（IPv6）では実装することが必須となっている。 IPsec での SIP 保護は、既存の企業向け IP 電話利用者が、外出先から社内の IP電話システムに接続する場合に使用し、遠隔地とはルータ間でトンネルを張りレイヤ 4 ルーティングを行う。
使用端末を登録して使う。
ファイアウォール、侵入防止システム (IPS)は、コストの関係や機能のため、設置が限定されるが、不正な形式のプロトコルの内容に応じた対応ができる製品も提供されている。
受信した IP パケットを、 SIP のリクエストやレスポンスとして処理する前に、 1秒間のリクエスト処理数など、実装要件から決定された上限値を超える場合は、 SIPのリクエストやレスポンスを処理せずに廃棄する。また、上限値を超えるリクエストのソース IPアドレスを記録し、運用者が確認できる機能を提供することが望ましい。
保護対象が RTP のペイロードだけで十分ならば、 Secure RTP を利用するのが適当である。しかしSRTPを使用できる場合は他の RTP 製品との互換性に配慮が必要である。 SRTPについては脆弱な暗号化方法を選択させられるなどの危険性も指摘されており、新たな脆弱性を組み込まれないよう注意が必要である。
途中の SIP サーバでヘッダやボディ内に記述されている IPアドレスやポートの正当性を検証し、不適当と判断された場合はエラーを返したり、リクエストを破棄する。
ダイジェスト認証を実装する際には、変化すべきでないデータと、変化していなければならないデータをしっかりチェックしなければならない。サーバ/UAS での認証情報に関するヘッダレベルのチェック項目は以下のようになる。
また、サーバ /UAS での認証ヘッダのチェック項目は以下のようになる。
VoIP には、トールバイパスという構成方法がある。この構成方法とこれまで取り上げた SIPセキュリティを踏まえて、電機大学のネットワーク構成を考える。 トールバイパスの利点を以下に示す。
現在の電機大学のネットワーク構成を図16に示す。
トールバイパスを使用したネットワーク構成を17に示す。
現在の構成では、 ATM回線を使用して、鳩山キャンパスまたは公衆回線網に接続している。しかし、品質が向上している現在のインターネット回線を使用し、神田キャンパスと鳩山キャンパス間では、音声とデータを統合し、 VoIP を使用して通話を行えば、 ATM 回線を使用する必要性は無いのではないだろうか。またアネックスのような完全な IP電話網から攻撃を仕掛けられた場合に備え、閉じたネットワークの検討やファイアウォールなどその他のシステムの使用も検討するべきである。
本論文では SIP の脆弱性に関する問題点について言及した。そして最後には問題点を踏まえた安全なSIPネットワーク構成を提案した。 今現在、日本での SIP プロトコル普及率はそれほど高くは無い。だが、他のプロトコルとの親和性の高い SIPは今後発展が期待できるものだと思う。また、海外との通話料金を大幅に削減できることや、 SIPを使用すれば敷居が高かった音声会議システムなども簡単かつ安価に構築する事が可能である。しかしながら、ネットワーク機器会社から発売されているSIP に関する製品は極端に少ないので今後 SIP の発展を期待する為にも各ベンダーがSIPをビジネスプランとして取り入れ、こぞって様々な製品を販売する可能性に期待したい。
RFC3261 で規定されているステータス・コードの一覧
| ステータス・コード | 内容 | 意味 |
|---|---|---|
| 100 Trying | 施行中 | リクエストはサーバー (UAS)に届いており、他のステータス・コードに当てはまらない何らかのアクションが行われていることを示す。 |
| 180 Ringing | 呼び出し中。 | INVITE を受け取った UA が、ユーザーに対して注意を促そうとしていることを示す。 |
| 181 Call Is Being Forwarded | 呼が転送されている。 | サーバーによって、呼が別の宛先へフォワードされていることを示す。 |
| 182 Queued | キューに入れられた。 | 着呼側は一時的に電話に出られないが、サーバーはその呼を拒否せず一時的にキューに入れられたことを示す。 |
| 183 Session Progress | セッションの進捗状況。 | 呼の進捗状況についての情報を伝えるために使用される。 |
| 200 OK | 成功。 | リクエストは受け付けられ、処理が成功したことを示す。 |
| 300 Multiple Choices | 複数の選択肢がある。 | リクエストが送られるべきアドレスが複数存在する。 |
| 301 Moved Permanently | 恒久的に移動した。 | リクエストが送られるべきユーザーは、恒久的に他へ移動したことを示す。 |
| 302 Moved Temporarily | 一時的に移動した。 | リクエストが送られるべきユーザーは、一時的に他へ移動したことを示す。 |
| 305 User Proxy | プロキシを使用せよ。 | リクエストは、プロキシを経由して送られなければならないことを示す。 |
| 380 Alternative Service | 代替サービス。 | 呼は成功しなかったが、代わりのサービスが可能であることを示す。 |
| 400 Bad Request | 不正なリクエスト。 | リクエストの内容が、異常な構文であるため理解できなかったことを示す。 |
| 401 Unauthorized | 許可されていない。 | リクエストに対して、ユーザー認証を要求することを示す。 |
| 402 Payment Required | 料金支払いが必要。 | 将来の使用のために予約されている。 |
| 403 Forbidden | 禁止。 | リクエストを理解したが、それを処理することを拒否したこととを示す。 |
| 404 Not Found | 見つからない。 | リクエストの宛先のユーザーが存在しないことを示す。 |
| 405 Method Not Allowed | メソッドが許可されていない。 | リクエストで指定されたメソッドは理解したが、宛先のアドレスに対してはそれが許可されないことを示す。 |
| 406 Not Acceptable | 受け入れできない。 | リクエストで指定されたコンテンツなどを、受け入れることができないことを示す。 |
| ステータス・コード | 内容 | 意味 |
|---|---|---|
| 407 Proxy Authentication Required | プロキシ認証が必要。 | 401 と似ているが、リクエストに対して UACがプロキシサーバーと認証しなくてはならないことを示す。 |
| 408 Request Timeout | リクエストがタイムアウトした。 | サーバーが一定時間内に応答を生成出来なかったことを示す。 |
| 410 Gone | リソースが既に存在しない。 | リクエストの宛先がもはや存在せず、転送先のアドレスも分からないことを示す。 |
| 413 Request Entity Too Large | リクエストのエンティティが大きすぎる。 | リクエストのサイズが大きすぎて、処理できないことを示す。 |
| 414 Request-URI Too Long | リクエスト URI が長すぎる。 | リクエストの URI が長すぎて、処理できないことを示す。 |
| 415 Unsupported Media Type | サポートされていないメディアタイプ | リクエストのメッセージボディが、メソッドに対してそのサーバーでサポートしていない書式であることを示す。 |
| 416 Unsupported URI Scheme | サポートされていない URI スキーム | リクエスト URI のスキームがサーバーがサポートされていないものであることを示す。 |
| 420 Bad Extension | 不正な拡張。 | Proxy-Require ヘッダまたは Requireヘッダで指定されたプロトコル拡張を、サポートしていないことを示す。 |
| 421 Extension Required | 拡張が必要。 | リクエストを処理するために特定の拡張を必要とするが、その拡張がリクエストの Supportedヘッダに記されていないことを示す |
| 423 Interval Too Brief | 間隔が短すぎる。 | リクエストによって示されたリソースの有効期限時間が短すぎることを示す。 |
| 480 Temporarily Unavailable | 一時的に利用不可。 | リクエストは着呼側のエンドシステムに到着したが、着呼側が現在電話を受けられる状態でないことを示す。 |
| 481 Call/Transaction Does Not Exist | 呼またはトランザクションが存在しない。 | リクエストが既存のどのダイアログやトランザクションにもマッチしなかったことを示す。 |
| 482 Loop Detected | ループが検出された。 | サーバーがリクエストの転送ループを検出したことを示す。 |
| 483 Too Many Hops | ホップが多すぎる。 | リクエストが多くのサーバーを経由したなどで、 Max-Forward ヘッダの値が0のリクエストを受け取ったことを示す。 |
| 484 Address Incomplete | アドレスが不完全。 | 不完全なリクエスト URI を持つリクエストを受け取ったことを示す。 |
| 485 Ambiguous | 不明瞭。 | リクエスト URI が不明瞭だったことを示す。 |
| 486 Busy Here | ここは現在ビジー | リクエストは着呼側のエンドシステムへ到達したが、着呼側は話し中などで電話を受けられる状態でないことを示す。 |
| ステータス・コード | 内容 | 意味 |
|---|---|---|
| 487 Request Terminated | リクエストが終了させられた。 | リクエストが BYE または CANCEL リクエストで終了させられたことを示す。 |
| 488 Not Acceptable Here | ここでは受け入れ不能。 | リクエストは着呼側のエンドシステムへ到達したが、そのエンドシステムでは、リクエストを受け入れることができないことを示す。 |
| 491 Request Pending | リクエストペンディング | リクエストは、同じダイアログ内にペンディング中のリクエストを持つ UA に受け取られたことを示す。 |
| 493 Undecipherable | 解読不能。 | 受け取ったリクエスト中の暗号化された MIME ボディを、解読することができないことを示す。 |
| 500 Server Internal Error | サーバー内部エラー。 | サーバーがリクエストを処理できない予期しない状態に遭遇したことを示す。 |
| 501 Not Implemented | 実装されていない。 | リクエストを処理するために必要な機能をサーバーがサポートしていないことを示す。 |
| 502 Bad Gateway | 不正なゲートウェイ。 | サーバーがリクエストの処理を試みたダウンストリーム・サーバーから、無効な応答を受け取ったことを示す。 |
| 503 Service Unavailable | サービスを利用できない。 | サーバーは一時的な過負荷やメンテナンスのため、一時的にリクエストを処理できないことを示す。 |
| 504 Server Time-out | サーバータイムアウト。 | サーバーはリクエストの処理を試みた外部サーバーから、一定時間内に応答を受け取ることが出来なかったことを示す。 |
| 505 Version Not Supported | サポートされていないバージョン。 | サーバーはリクエストで指定された SIP プロトコル・バージョンを、サポートしていないことを示す。 |
| 513 Message Too Large | メッセージが大きすぎる。 | メッセージ長がサーバーの処理能力を超えたため、リクエストが処理できなかったことを示す。 |
| 600 Busy Everywhere | どの場所もビジー。 | リクエストは着呼側のエンドシステムに到達したが、着呼側はビジーで、ボイスメール・システムなど他のどのエンドポイントでも応答できないことを示す。 |
| 603 Decline | 辞退。 | リクエストは着呼側のエンドシステムに到達したが、ユーザーが応答することを望まない、または応答出来ないことを示す。 |
| 604 Does Not Exist Anywhere | どこにも存在しない。 | リクエスト URI で指定されたユーザーがどこにも存在しないことを示す。 |
| 606 Not Acceptable | 受け入れ不能 | リクエストは着呼側のエンドシステムに到達したが、リクエストを受け入れることが出来ないことを示す。 |