Internet Engineering Task Force (IETF) J. Seedorf
Request for Comments: 6404 S. Niccolini
Category: Informational NEC
ISSN: 2070-1721 E. Chen
NTT
H. Scholz
VOIPFUTURE
November 2011
Session PEERing for Multimedia INTerconnect (SPEERMINT)
Security Threats and Suggested Countermeasures
Abstract
抽象
The Session PEERing for Multimedia INTerconnect (SPEERMINT) working group (WG) provides a peering framework that leverages the building blocks of existing IETF-defined protocols such as SIP and ENUM for the interconnection between SIP Service Providers (SSPs). The objective of this document is to identify and enumerate SPEERMINT-specific threat vectors and to give guidance for implementers on selecting appropriate countermeasures. Security requirements for SPEERMINT that have been derived from the threats detailed in this document can be found in RFC 6271; this document provides concrete countermeasures to meet those SPEERMINT security requirements. In this document, the different security threats related to SPEERMINT are classified into threats to the Lookup Function (LUF), the Location Routing Function (LRF), the Signaling Function (SF), and the Media Function (MF) of a specific SIP Service Provider. Various instances of the threats are briefly introduced inside the classification. Finally, existing security solutions for SIP and RTP/RTCP (Real-time Transport Control Protocol) are presented to describe countermeasures currently available for such threats. Each SSP may have connections to one or more remote SSPs through peering or transit contracts. A potentially compromised remote SSP that attacks other SSPs is out of the scope of this document; this document focuses on attacks on an SSP from outside the trust domain such an SSP may have with other SSPs.
マルチメディア相互接続（SPEERMINT）ワーキンググループ（WG）のためにピアリングセッションは、SIPサービスプロバイダ（SSP）間の相互接続のためのそのようなSIP及びENUMなどの既存のIETF定義のプロトコルのビルディングブロックを活用ピアリング・フレームワークを提供します。このドキュメントの目的は、特定しSPEERMINT固有の脅威ベクトルを列挙し、適切な対策を選択する上で実装するためのガイダンスを提供することです。本書で詳述脅威に由来しているSPEERMINTのためのセキュリティ要件は、RFC 6271で見つけることができます。この文書では、これらのSPEERMINTのセキュリティ要件を満たすために、具体的な対策を提供します。この文書では、SPEERMINTに関連するさまざまなセキュリティ上の脅威は、ルックアップ機能（LUF）への脅威に分類され、場所ルーティング機能（LRF）、シグナリング機能（SF）、および特定のSIPサービスのメディア機能（MF）プロバイダ。脅威の様々なインスタンスを簡単に分類内側に導入されています。最後に、SIPとRTP / RTCP（リアルタイムトランスポート制御プロトコル）のための既存のセキュリティ・ソリューションは、このような脅威のために現在利用可能な対策を説明するために提示されています。各SSPは、ピアリングやトランジット契約を通じて、1つ以上のリモートのSSPへの接続を有していてもよいです。他のSSPを攻撃する可能性損なわリモートSSPは、この文書の範囲外です。この文書では、SSPは、他のSSPを持っていることがあり、このような信頼ドメインの外部からSSPへの攻撃に焦点を当てています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6404.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6404で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................4
2. Security Threats Relevant to SPEERMINT ..........................5
2.1. Threats to the Lookup Function (LUF) .......................5
2.1.1. Threats to LUF Confidentiality ......................5
2.1.2. Threats to LUF Integrity ............................6
2.1.3. Threats to LUF Availability .........................6
2.2. Threats to the Location Routing Function (LRF) .............6
2.2.1. Threats to LRF Confidentiality ......................6
2.2.2. Threats to LRF Integrity ............................7
2.2.3. Threats to LRF Availability .........................7
2.3. Threats to the Signaling Function (SF) .....................7
2.3.1. Threats to SF Confidentiality .......................7
2.3.2. Threats to SF Integrity .............................8
2.3.3. Threats to SF Availability .........................10
2.4. Threats to the Media Function (MF) ........................10
2.4.1. Threats to MF Confidentiality ......................10
2.4.2. Threats to MF Integrity ............................10
2.4.3. Threats to MF Availability .........................11
3. Security Requirements ..........................................11
3.1. Security Requirements from SPEERMINT Requirements
Document ..................................................11
3.2. How to Fulfill the Security Requirements for SPEERMINT ....11
4. Suggested Countermeasures ......................................12
4.1. Database Security BCPs ....................................14
4.2. DNSSEC ....................................................14
4.3. DNS Replication ...........................................15
4.4. Cross-Domain Privacy Protection ...........................15
4.5. Secure Exchange of SIP Messages ...........................15
4.6. Ingress Filtering / Reverse-Path Filtering ................16
4.7. Strong Identity Assertion .................................16
4.8. Reliable Border Element Pooling ...........................17
4.9. Rate limit ................................................17
4.10. Topology Hiding ..........................................17
4.11. Border Element Hardening .................................17
4.12. Securing Session Establishment Data ......................18
4.13. Encryption and Integrity Protection of Media Stream ......18
5. Conclusions ....................................................18
6. Security Considerations ........................................18
7. Acknowledgements ...............................................19
8. Informative References .........................................19
With Voice over IP (VoIP), the need for security is compounded because there is the need to protect both the control plane and the data plane. In a legacy telephone system, security is a more valid assumption. Intercepting conversations requires either physical access to telephone lines or a compromise to the Public Switched Telephone Network (PSTN) nodes or the office Private Branch eXchanges (PBXs). Only particularly security-sensitive organizations bother to encrypt voice traffic over traditional telephone lines. In contrast, the risk of sending unencrypted data across the Internet is more significant (e.g., dual-tone multi-frequency (DTMF) tones corresponding to the credit card number). An additional security threat to Internet Telephony comes from the fact that the signaling devices may be addressed directly by attackers as they use the same underlying networking technology as the multimedia data; traditional telephone systems have the signaling network separated from the data network. This is an increased security threat since a hacker could attack the signaling network and its servers with increased damage potential (call hijacking, call drop, Denial-of-Service (DoS) attacks [RFC4732], etc.). Therefore, there is a need to investigate the different security threats, to extract security-related requirements, and to highlight potential solutions on how to protect against such threats.
コントロールプレーンとデータプレーンの両方を保護する必要があるので、ボイスオーバーIP（VoIP）のでは、セキュリティの必要性が配合されます。従来の電話システムでは、セキュリティがより有効な仮定です。公衆交換電話網（PSTN）のノードやオフィス構内交換機（PBX）をスイッチに会話を傍受することは物理的な電話回線へのアクセスや妥協のいずれかが必要です。のみ、特にセキュリティに敏感な組織では、従来の電話回線を介して音声トラフィックを暗号化するためにわざわざ。対照的に、インターネットを介して暗号化されていないデータを送信するリスクは、（クレジットカード番号に対応する、例えば、デュアルトーン多重周波数（DTMF）トーン）がより重要です。インターネット電話への追加のセキュリティ脅威は、彼らは、マルチメディアデータと同一の基盤となるネットワーク技術を使用して信号装置は、攻撃者によって直接アドレス指定することができるという事実から来ています。従来の電話システムは、データネットワークから分離されたシグナリングネットワークを持っています。これは、ハッカーが（ハイジャック、コール・ドロップ、サービス拒否（DoS）攻撃[RFC4732]、などを呼び出す）シグナリングネットワークと増加損傷の可能性とそのサーバを攻撃する可能性があるため増加セキュリティ上の脅威です。そのため、セキュリティ関連の要件を抽出するために、そのような脅威から保護する方法についての潜在的な解決策を強調するために、さまざまなセキュリティの脅威を調査する必要があります。
The Session PEERing for Multimedia INTerconnect (SPEERMINT) working group provides a peering framework that leverages the building blocks of existing IETF-defined protocols such as SIP and ENUM for the interconnection between SIP servers [RFC5486]. The objective of this document is to identify and enumerate SPEERMINT-specific threat vectors and to give guidance for implementers on selecting appropriate countermeasures. Security requirements for SPEERMINT can be found in RFC 6271 "Requirements for SIP-Based Session Peering" [RFC6271]. These security requirements for SPEERMINT are derived from the threats that are detailed in this document; they have been moved from an earlier version of this document to the SPEERMINT requirements document [RFC6271]. In addition to being the base for those security requirements, this document provides to implementers advice and examples for concrete countermeasures on how to meet these security requirements for SPEERMINT with technical means. The SPEERMINT terminology outlined in [RFC5486] is used throughout this document.
マルチメディア相互接続（SPEERMINT）ワーキンググループのセッションピアリングは、SIPサーバ[RFC5486]との間の相互接続のためのそのようなSIP及びENUMなどの既存のIETF定義のプロトコルのビルディングブロックを活用ピアリング・フレームワークを提供します。このドキュメントの目的は、特定しSPEERMINT固有の脅威ベクトルを列挙し、適切な対策を選択する上で実装するためのガイダンスを提供することです。 SPEERMINTのためのセキュリティ要件は、RFC 6271「SIPベースのセッションピアリングのための要件」[RFC6271]で見つけることができます。 SPEERMINTのためのこれらのセキュリティ要件は、この文書に詳述されている脅威から派生しています。彼らはSPEERMINT要件ドキュメント[RFC6271]に、このドキュメントの以前のバージョンから移動されました。これらのセキュリティ要件のためのベースであることに加えて、この文書は、実装者の助言や技術的手段とのSPEERMINTのためにこれらのセキュリティ要件を満たす方法についての具体的な対策のための例を提供します。 [RFC5486]に概説SPEERMINT用語は、この文書全体を通して使用されます。
In this document, the different security threats related to SPEERMINT are classified into threats to the Lookup Function (LUF), the Location Routing Function (LRF), the Signaling Function (SF), and the Media Function (MF) of a specific SIP Service Provider (SSP). Various instances of the threats are briefly introduced inside the classification. Finally, existing security solutions for SIP and RTP/RTCP are presented to describe countermeasures currently available for such threats. Each SSP may have connections to one or more remote SSPs through peering or transit contracts. A potentially compromised remote SSP that attacks other SSPs is out of the scope of this document; this document focuses on attacks on an SSP from outside the trust domain such an SSP may have with other SSPs.
この文書では、SPEERMINTに関連するさまざまなセキュリティ上の脅威は、ルックアップ機能（LUF）への脅威に分類され、場所ルーティング機能（LRF）、シグナリング機能（SF）、および特定のSIPサービスのメディア機能（MF）プロバイダ（SSP）。脅威の様々なインスタンスを簡単に分類内側に導入されています。最後に、SIPとRTP / RTCPのための既存のセキュリティ・ソリューションは、このような脅威のために現在利用可能な対策を説明するために提示されています。各SSPは、ピアリングやトランジット契約を通じて、1つ以上のリモートのSSPへの接続を有していてもよいです。他のSSPを攻撃する可能性損なわリモートSSPは、この文書の範囲外です。この文書では、SSPは、他のSSPを持っていることがあり、このような信頼ドメインの外部からSSPへの攻撃に焦点を当てています。
This section enumerates potential security threats relevant to SPEERMINT. A taxonomy of VoIP security threats is defined in [VOIPSATAXONOMY]. This taxonomy is comprehensive and also takes into account non-VoIP-specific threats (e.g., loss of power, etc.). Threats relevant to the boundaries of Layer 5 SIP networks are extracted from this taxonomy and mapped to the functions of the SPEERMINT architecture as defined in [RFC6406]. Moreover, additional threats for the SPEERMINT architecture are listed and detailed under the same classification of SPEERMINT functions and according to the CIA (Confidentiality, Integrity, and Availability) triad:
このセクションでは、SPEERMINTに関連する潜在的なセキュリティの脅威を列挙します。 VoIPセキュリティの脅威の分類は、[VOIPSATAXONOMY]で定義されています。この分類では包括的であり、また非VoIPの特定の脅威（例えば、電源の喪失など）を考慮する。レイヤ5 SIPネットワークの境界に関連する脅威は、この分類から抽出され、[RFC6406]で定義されるようSPEERMINTアーキテクチャの機能にマッピングされます。また、SPEERMINTアーキテクチャの追加の脅威が表示され、詳細なSPEERMINT機能の同じ分類の下及びCIA（機密性、完全性、可用性）トライアドに従ってれます。
o Lookup Function (LUF);
ルックアップ関数（LUF）O。
o Location Routing Function (LRF);
場所ルーティング機能（LRF）O;
o Signaling Function (SF);
Oシグナリング機能（SF）;
o Media Function (MF).
Oメディア機能（MF）。
For a given request, the LUF provides a mechanism to determine the identity of the requested resource on the terminating domain. The returned identity can be used to look up Session Establishment Data (SED) using the Location Routing Function (LRF). In direct peerings, the LUF is usually hosted locally, whereas in a federation context, this function may be offered by a third party.
所与の要求に対して、LUFは、終端領域に要求されたリソースの同一性を決定するためのメカニズムを提供します。返されたアイデンティティは場所ルーティング機能（LRF）を使用して、セッションの確立データ（SED）をルックアップするために使用することができます。フェデレーション文脈において、この機能は、第三者によって提供されてもよい一方、直接ピアリングでは、LUFは、通常、ローカルにホストされています。
If the LUF is hosted locally, it is vulnerable to the same threats that affect database systems in general. If the SSP relies on a remote third party to provide the LUF functionality, confidentiality, integrity, and authenticity of the responses are at risk.
LUFがローカルでホストされている場合、それは一般的に、データベース・システムに影響を与える同じ脅威に対して脆弱です。 SSPは、LUF機能を提供するために、遠隔の第三者に依存している場合は、機密性、完全性、および応答の信憑性は危険にさらされています。
For a given request, the Lookup Function (LUF) determines the target domain to which the request should be routed. The following attacks are relevant with respect to eavesdropping on LUF messages: o SIP URI and peering domain harvesting - an attacker can exploit this weakness if the underlying database has a weak authentication system or if SIP messages are sent unencrypted, and then use the gained knowledge to launch other kinds of attacks.
特定の要求のために、ルックアップ機能（LUF）は、要求がルーティングされる対象のドメインを決定します。次の攻撃はLUFメッセージの盗聴に関しては関連していますSIP URIとピアリングドメイン収穫がO - 攻撃者は、基礎となるデータベースが弱い認証システムを持っている場合は、この弱点を悪用したりSIPメッセージが暗号化されずに送信された場合、その後、得られた知識を使用することができます攻撃の他の種類を起動します。
o Third-party information - a LUF providing information to multiple companies / third parties can be attacked to obtain information about third party peering configurations and possible contracts.
Oサードパーティの情報 - 複数の企業に情報を提供LUF /第三者が第三者ピアリング構成し、可能な契約についての情報を取得するために攻撃することができます。
The underlying database or LUF messages could be vulnerable to input/ output message modification attacks:
基礎となるデータベースまたはLUFメッセージは、入力/出力メッセージの変更攻撃の影響を受ける可能性があり：
o Injection attack - an attacker could manipulate statements performed on the database LUF messages sent to a third party. A specific version of this attack is known as "SQL injection". An SQL injection is a code insertion into the LUF due to incorrect input validation.
Oインジェクション攻撃は - 攻撃者が第三者に送信されたデータベースLUFメッセージに対して実行文を操作することができます。この攻撃の特定のバージョンは、「SQLインジェクション」として知られています。 SQLインジェクションは、誤入力の検証のためにLUFへのコード挿入です。
The underlying database or third party LUF service could be vulnerable to:
基礎となるデータベースまたは第三者LUFサービスが影響を受ける可能性があり：
o Denial-of-Service attacks - For example, an attacker makes incomplete requests causing the server to create an idle state for each of them, which causes memory to be exhausted.
サービス拒否攻撃O - たとえば、攻撃者は、メモリが枯渇することになり、それらの各々のためのアイドル状態を、作成するためのサーバーを引き起こして、不完全な要求を行います。
The LRF determines the location of the Signaling Function (SF) for the target domain of a given request. Optionally, it may return additional SED.
LRFは、与えられた要求の対象ドメインのシグナリング機能（SF）の位置を決定します。必要に応じて、それは追加のSEDを返すことがあります。
Similar to the LUF, the following attacks are related to eavesdropping on LRF messages:
LUFと同様には、次のような攻撃は、LRFメッセージ上の盗聴に関連しています。
o URI harvesting - the attacker harvests URIs and IP addresses of the existing User Endpoints (UEs) by issuing a multitude of location requests. Direct intrusion against vulnerable UEs or telemarketing are possible attack scenarios that would use the gained knowledge.
ロケーション要求を多数発行することによって、攻撃者の収穫のURIと、既存のユーザ・エンドポイント（のUE）のIPアドレス - O URI収穫。脆弱なのUEまたはテレマーケティングに対する直接の侵入が得られた知識を使用する可能性の攻撃シナリオです。
o SIP device enumeration - the attacker discovers the IP address of each intermediate signaling device by looking at the Via and Record-Route headers of a SIP message. Targeting the discovered devices with subsequent attacks is a possible attack scenario.
O SIPデバイス列挙 - 攻撃者は、SIPメッセージのビアとレコードルートヘッダを見ることによって、各中間信号装置のIPアドレスを発見します。その後の攻撃に検出されたデバイスを標的にすることは可能な攻撃のシナリオです。
An attacker may modify messages, e.g., by feeding bogus information to the LRF, if the routing data is not correctly validated or sent unencrypted. Dynamic call routing discovery and establishment, as in the scope of SPEERMINT, introduce opportunities for attacks such as the following:
ルーティングデータが正しく検証または暗号化されずに送信されていない場合、攻撃者は、LRFに偽の情報を供給することにより、例えば、メッセージを修正することができます。 SPEERMINTの範囲内として、発見と確立をルーティング、動的呼び出しは、次のような攻撃の機会をご紹介します：
o Man-in-the-Middle attacks - the attacker inserts or has already inserted an unauthorized node in the signaling path modifying the SED. The result is that the attacker is then able to read, insert, and modify the multimedia communications.
O man-in-the-middle攻撃 - 攻撃の挿入または既にSEDを変更するシグナリングパスに不正ノードを挿入しました。その結果、攻撃者は、その後、読み取り挿入し、マルチメディア通信を修正することができることです。
o Incorrect destinations - the attacker redirects the calls to an incorrect destination with the purpose of establishing fraud communications like voice phishing or DoS attacks.
O誤った目的地 - 攻撃者は、ボイスフィッシングやDoS攻撃のような詐欺の通信を確立する目的で、誤った宛先へのコールをリダイレクトします。
The LRF can be the object of DoS attacks. DoS attacks to the LRF can be carried out by sending a large number of queries to the LRF or LUF, with the result of preventing an Originating SSP from looking up call routing data of any URI outside its administrative domain. As an alternative, the attacker could target the DNS to disable resolution of SIP addresses.
LRFは、DoS攻撃の対象となることができます。 LRFへのDoS攻撃は、その管理ドメイン外の任意のURIのコールルーティングデータを調べるから発信SSPを防止する結果と、LRFやLUFにクエリを大量に送信することにより行うことができます。別の方法として、攻撃者は、SIPアドレスの解決を無効にするには、DNSをターゲットにすることができます。
The Signaling Function involves a great number of sensitive information. Through the Signaling Function, User Agents (UAs) assert identities and operators authorize billable resources. Correct and trusted operation of Signaling Function is essential for service providers. This section discusses potential security threats to the Signaling Function to detail the possible attack vectors.
シグナリング機能は、機密情報の多くを必要とします。シグナリング機能により、ユーザーエージェント（UAは）アイデンティティを主張し、事業者は請求可能なリソースを認可します。シグナリング機能の正確かつ信頼できる操作は、サービスプロバイダのために不可欠です。このセクションでは、可能な攻撃ベクトル細部へのシグナル伝達機能への潜在的なセキュリティ上の脅威について説明します。
SF traffic is vulnerable to eavesdropping, in particular, when the data is moved across multiple SSPs having different levels of security policies. Threats for the SF confidentiality are listed here: o Call pattern analysis - the attacker tracks the call patterns of the users violating his/her privacy (e.g., revealing the social network of various users, the daily phone usage, etc.); also, rival SSPs may infer information about the customer base of other SSPs in this way;
SFトラフィックは、データがセキュリティポリシーの異なるレベルを有する複数のSSPを横切って移動する際に、特に、盗聴に対して脆弱です。 SFの機密性のための脅威は、ここに記載されています：コールパターン解析○ - 攻撃者が（例えば、など様々なユーザーのソーシャルネットワーク、毎日電話の使用状況を、明らかに）彼/彼女のプライバシーを侵害するユーザの通話パターンを追跡します。また、ライバルのSSPは、このように他のSSPの顧客ベースの情報を推論することができます。
o Password cracking - the challenge-response authentication mechanism of SIP Digest can be attacked with offline dictionary attacks. With such attacks, an attacker tries to exploit weak passwords that are used by incautious users.
Oパスワードクラッキング - SIPダイジェストのチャレンジレスポンス認証メカニズムは、オフライン辞書攻撃で攻撃することができます。このような攻撃では、攻撃者は事も無げユーザーによって使用されている弱いパスワードを悪用しようとします。
o Network discovery - the attacker may learn information about the internal network structure of a peering partner that is directly or indirectly connected by looking at SIP routing information (i.e, Record-Route, Via or Contact headers).
Oネットワーク探索 - 攻撃者は、直接的または間接的にSIPルーティング情報（すなわち、レコード・ルート、を介して、または連絡先ヘッダ）を見て、接続されたピアリングパートナーの内部ネットワーク構造についての情報を知ることがあります。
The integrity of the SF can be violated using SIP request spoofing, SIP reply spoofing, and SIP message tampering.
SFの整合性は、SIPリクエストなりすまし、SIP応答スプーフィング、およびSIPメッセージの改ざんを使用して違反することができます。
Most SIP request spoofing attacks first require SIP message eavesdropping. However, some of these attacks can be also performed by estimating certain fields in SIP headers (e.g., by exploiting the fact that weak implementations may generate predictable SIP Dialog parameters) or exploiting broken implementations that do not properly verify the content of certain headers. Threats in this category are as follows:
ほとんどのSIPリクエストスプーフィング攻撃は、第1のSIPメッセージの盗聴を必要とします。しかし、これらの攻撃のいくつかはまた、又は適切に特定のヘッダの内容を確認していない壊れた実装を利用する（弱い実装が予測可能なSIPダイアログ・パラメータを生成することができるという事実を利用することによって、例えば）SIPヘッダにおける特定のフィールドを推定することによって行うことができます。次のようにこのカテゴリーの脅威は、次のとおりです。
o session teardown - an attacker can send CANCEL/BYE messages in order to tear down an existing call at the SIP layer; for such an attack, the attacker either needs to know (e.g., by eavesdropping a SIP INVITE message) the SIP Dialog of the call to be hijacked (To-tag, From-tag, Call-ID) or alternatively may rely on SIP implementations that do not properly authenticate requests based on the SIP Dialog;
Oセッションのティアダウン - 攻撃者は、SIP層で既存のコールを切断するために、CANCEL / BYEメッセージを送信することができます。このような攻撃、どちらかを知る必要があり、攻撃者のためのコールのSIPダイアログがハイジャックされる（例えば、SIP INVITEメッセージを盗聴して）SIPの実装に依存していることがあり、代替的（からタグ、TO-タグ、ID-コール）またはそれは適切にSIPダイアログに基づいて要求を認証しません。
o Billing fraud - the attacker can modify and replay an intercepted INVITE request in order to bill a call to a victim UE and avoid paying for the phone call;
Oの振り込め詐欺 - 攻撃者が変更し、被害者UEへの呼び出しに請求し、電話の支払いを避けるために、インターセプト、INVITEリクエストを再生することができます。
o User ID spoofing - SSPs are responsible for asserting the legitimacy of a user ID; if an SSP fails to achieve the level of identity assertion that the federation to which it belongs expects, it may create an entry point for attackers to conduct user ID spoofing attacks;
OユーザIDスプーフィング - のSSPは、ユーザーIDの正当性を主張する責任があります。 SSPは、フェデレーションは、それが期待するの属するというIDアサーションのレベルを達成するために失敗した場合、それは攻撃者がユーザーIDスプーフィング攻撃を行うためのエントリポイントを作成することができ、
o Unwanted requests - the attacker sends requests to interfere with regular operation, e.g., by sending a REGISTER request in order to hijack calls. The SPEERMINT architecture as defined in [RFC6406] does not require registrations between the Signaling Functions (SFs) of the connected SSPs. Hence, superfluous requests like REGISTERs should be rejected.
不要なリクエストO - 攻撃者は、コールをハイジャックするために、REGISTERリクエストを送信することにより、例えば、通常動作を妨害する要求を送信します。 [RFC6406]で定義されるようSPEERMINTアーキテクチャは、接続のSSPのシグナリング機能（サービスフロー）との間の登録を必要としません。したがって、レジスタなどの余計な要求は拒否されなければなりません。
Threats in this category are as follows:
次のようにこのカテゴリーの脅威は、次のとおりです。
o Forged 199 Response - the attacker sends a forged 199 response to terminate an early dialog. The forged response will not terminate the entire session but may alter the direction of the session;
oは199レスポンスを鍛造 - 攻撃者は、早期にダイアログを終了するための偽造199応答を送信します。偽造応答は、全体セッションを終了しませんが、セッションの方向を変更することができます。
o Forged 200 Response - having seen the contents of an INVITE request, an eavesdropper can inject a 200 response, affecting the processing of the transaction of all proxies between the injection point and the originating UA and at the originating UA itself. In the extreme case, this can result in a hijacked call. In many cases, however, such an attack will leave signaling artifacts that may allow it to be detected (e.g., the element receiving the forged 200 response may also receive other SIP reply messages from the actual terminating UE);
200応答を鍛造O - INVITE要求の内容を見た、盗聴者は、注入点と発信UA間で発信UA自体ですべてのプロキシのトランザクションの処理に影響を与える、200レスポンスを注入することができます。極端な場合には、これはハイジャックコールにつながることができます。しかし、多くの場合、そのような攻撃（例えば、偽造200応答を受信した要素は、実際の終端UEから他のSIP応答メッセージを受信してもよい）が検出されることを可能にすることができるアーティファクトをシグナリング残します。
o Forged 302 Response - having seen the contents of an INVITE request, an eavesdropper could also inject a forged "302 Moved Temporarily" reply, affecting the processing of the transaction at intermediate entities and the originating UA. This may allow the attacker to successfully redirect the call to any destination UE of his choosing;
O 302応答を鍛造 - INVITE要求の内容を見た、盗聴者は、中間エンティティおよび発信UAにトランザクションの処理に影響を与え、鍛造「302は一時的に移動し、」返信を注入することができました。これは、攻撃者が自分の選択した任意の宛先UEへのコールをリダイレクトすることを可能にします。
o Forged 404 Response - having seen the contents of an INVITE request, an eavesdropper could also inject a forged "404 Not Found" reply, affecting the processing of the transaction at intermediate entities and the originating UA. Such an attack may result in disrupting the call establishment.
O 404レスポンスを鍛造 - INVITE要求の内容を見た、盗聴者は、中間エンティティと元のUAでトランザクションの処理に影響を与え、鍛造「404が見つかりません」返信を注入できます。このような攻撃は、コールの確立を中断することがあります。
This threat involves the alteration of important field values in a SIP message or in the Session Description Protocol (SDP) body. Examples of this threat could be the dropping or modification of handshake packets in order to avoid the establishment of a secure RTP session (SRTP). The same approach could be used to degrade the quality of media session by letting a UE negotiate a poor quality codec.
この脅威は、SIPメッセージまたはセッション記述プロトコル（SDP）の体内で重要なフィールド値の変更を含みます。この脅威の例としては、安全なRTPセッション（SRTP）の確立を避けるために、ハンドシェイクパケットのドロップや変更可能性があります。同じアプローチは、UEが低品質のコーデックをネゴシエートさせることにより、メディアセッションの品質を劣化させるために使用することができます。
o Flooding attack - a Signaling Path Border Element (SBE) is susceptible to message flooding attacks that may come from interconnected SSPs;
Oフラッディング攻撃 - シグナリングパスボーダー要素（SBE）は、相互接続されたSSPから来るかもしれないメッセージのフラッディング攻撃を受けやすいです。
o Session blackholing - the attacker (assumed to be able to make Man-in-the-Middle attacks) intentionally drops essential packets, e.g., INVITEs, to prevent certain calls from being established;
Oセッションは、ブラックホール - （man-in-the-middle攻撃を行うことができると仮定）攻撃者が意図的に確立されてから特定のコールを防止するために不可欠なパケット、例えば、招待、ドロップ。
o SIP Fuzzing attack - fuzzing tests and software can be used by attackers to discover and exploit vulnerabilities of a SIP entity. This attack may result in crashing a SIP entity.
O SIPファジング攻撃 - ファジングテストとソフトウェアは、SIPエンティティの脆弱性を発見し、利用するために攻撃者によって使用することができます。この攻撃は、SIPエンティティをクラッシュする可能性があります。
The Media Function (MF) is responsible for the actual delivery of multimedia communication between the users and carries sensitive information. Through the media function, the UE can establish secure communications and monitor the quality of conversations. Correct and trusted operations of MF is essential for privacy and service-assurance issues. This section discusses potential security threats to the MF to detail the possible attack vectors.
メディア機能（MF）は、ユーザ間のマルチメディア通信の実際の配信を担当して、機密情報を運びます。メディア機能を通じて、UEは、安全な通信を確立し、会話の品質を監視することができます。 MFの正しいと信頼できる操作は、プライバシーおよびサービス保証の問題のために不可欠です。このセクションでは、可能な攻撃ベクトル細部にMFへの潜在的なセキュリティの脅威について説明します。
The MF is vulnerable to eavesdropping in which the attacker may reconstruct the voice conversation or sensitive information (e.g., PINs from DTMF tones). Some SRTP key exchange mechanisms (e.g., [RFC4568]) are vulnerable to bid-down attacks, where an attacker selectively changes key exchange protocol fields in order to enforce the establishment of a less secure or even non-secure communication.
MFは、攻撃者が音声通話や機密情報を再構築できる、盗聴に対して脆弱である（例えば、DTMFトーンからピン）。いくつかのSRTP鍵交換メカニズム（例えば、[RFC4568]）は入札ダウンする攻撃者が選択的非セキュアも安全性が低い、または通信の確立を実施するために鍵交換プロトコルフィールドを変更攻撃を受けやすいです。
Both RTP and RTCP are vulnerable to integrity violation in many ways:
RTPとRTCPはどちらも多くの点で整合性違反に対して脆弱です。
o Media injection - if an attacker can somehow detect an ongoing media session and eavesdrop a few RTP packets, he can start sending bogus RTP packets to one of the UEs involved using the same codec. If the bogus RTP packets have consistently greater timestamps and sequence numbers (but within the acceptable range) than the legitimate RTP packets, the recipient UE may accept the bogus RTP packets and discard the legitimate ones.
Oメディア注入は - 攻撃者が何らかの形で継続的なメディアセッションを検出し、いくつかのRTPパケットを盗聴することができた場合、彼は同じコーデックを使用して関与するUEの1に偽のRTPパケットの送信を開始することができます。偽のRTPパケットが正当なRTPパケットよりも一貫して大きいタイムスタンプとシーケンス番号を有している（ただし、許容範囲内）場合、受信者UEは、偽のRTPパケットを受信し、正当なものを破棄してもよいです。
o Media session teardown - the attacker sends bogus RTCP BYE messages to a target UE signaling to tear down the media communication; please note that RTCP messages are normally not authenticated.
Oメディアセッションティアダウン - 攻撃者は、メディアの通信を切断するターゲットUEシグナリングに偽のRTCP BYEメッセージを送信します。 RTCPメッセージは正常に認証されないことに注意してください。
o Quality-of-Service (QoS) degradation - the attacker sends wrong RTCP reports advertising more packet loss or more jitter than actually experimented resulting in the usage of a poor quality codec degrading the overall quality of the call experience.
サービス品質（QoS）の劣化O - 攻撃者は、より多くのパケット損失または実際のコールの経験の全体的な品質を低下させる低品質のコーデックの使用が生じ実験よりも多くのジッタを宣伝し、間違ったRTCPレポートを送信します。
o Malformed messages - the attacker tries to cause a crash or a reboot of the Data Path Border Element (DBE)/UE by sending RTP/ RTCP malformed messages;
Oの不正な形式のメッセージ - 攻撃者は、RTP / RTCP不正な形式のメッセージを送信することにより、クラッシュやデータパスボーダー要素（DBE）/ UEのリブートを引き起こすしようとします。
o Messages flooding - the attacker tries to exhaust the resources of the DBE/UE by sending many RTP/RTCP messages.
Oメッセージは、フラッディング - 攻撃者は、多くのRTP / RTCPメッセージを送信することにより、DBE / UEの資源を使い果たししようとします。
The security requirements for SPEERMINT have been moved from an earlier version of this document to the SPEERMINT requirements [RFC6271]. The security requirements for SPEERMINT are the following, from [RFC6271]:
SPEERMINTのセキュリティ要件は、SPEERMINT要件[RFC6271]に、このドキュメントの以前のバージョンから移動されました。 SPEERMINTのセキュリティ要件は[RFC6271]から、次のとおりです。
o Requirement #15: The protocols used to query the Lookup and Location Routing Functions SHOULD support mutual authentication.
Oの必要条件＃15：検索と場所ルーティング機能を照会するために使用されるプロトコルは、相互認証をサポートする必要があります。
o Requirement #16: The protocols used to query the Lookup and Location Routing Functions SHOULD provide support for data confidentiality and integrity.
O要件＃16：検索と場所ルーティング機能を照会するために使用されるプロトコルは、データの機密性と整合性のためのサポートを提供する必要があります。
o Requirement #17: The protocols used to enable session peering MUST NOT interfere with the exchanges of media security attributes in SDP. Media attribute lines that are not understood by SBEs must be ignored and passed along the signaling path untouched.
Oの必要条件＃17：セッションピアリングを有効にするために使用されるプロトコルは、SDP内のメディアのセキュリティ属性の交換を妨害してはなりません。残りのSBEによって理解されていないメディア属性行は無視され、手つかずのシグナリングパスに沿って渡す必要があります。
Requirements #15 and #16 state that the LUF and LRF should support mutual authentication, data confidentiality, and integrity. In principle, these requirements can be fulfilled technically with Transport Layer Security (TLS) or Datagram TLS (DTLS) [RFC5246] [RFC4347] or IP layer security (IPsec) [RFC4301]. From a pure
要件＃15と＃16 LUFとLRFは、相互認証、データの機密性、および完全性をサポートする必要がある状態。原則として、これらの要件は、トランスポート層セキュリティ（TLS）またはデータグラムTLS（DTLS）[RFC5246] [RFC4347]またはIP層セキュリティ（IPsec）[RFC4301]で技術的に満たすことができます。純粋から
security perspective both solutions fulfill the security requirements for SPEERMINT, just on a different layer, and both solutions are widely deployed.
セキュリティの観点の両方のソリューションは、ちょうど別の層の上に、SPEERMINTのセキュリティ要件を満たし、かつ両方のソリューションを広く展開されています。
However, from a more practical perspective, transport layer security (i.e., TLS or DTLS) has the advantage that the application using it is aware of whether or not security (or rather the corresponding security features) is enabled. For instance, using TLS has the consequence that the connection fails if the corresponding connection endpoint cannot authenticate properly.
しかし、より実用的な観点から、トランスポート層セキュリティ（すなわち、TLSまたはDTLS）は、それを使用するアプリケーションは、セキュリティ（またはむしろ、対応するセキュリティ機能）が有効になっているか否かを知っているという利点を有します。例えば、TLSを使用すると、対応する接続エンドポイントが正常に認証できない場合は、接続が失敗した結果を有します。
While IPsec fulfills the same requirements from a security perspective, IPsec is somewhat de-coupling security from the application using it. For instance, IPsec is often provided by dedicated entities in such a way that from the application layer, it cannot be recognized whether or not IPsec or certain security features are turned on ("bump-in-the-wire").
IPsecはセキュリティの観点から同じ要件を満たしながら、IPsecは幾分それを使用して、アプリケーションから脱カップリングセキュリティです。例えば、IPsecのは、多くの場合、アプリケーション層から、IPSecまたは特定のセキュリティ機能（「バンプ・イン・ザ・ワイヤ」）がオンされたか否かを認識できないように専用のエンティティによって提供されます。
In summary, TLS (or DTLS) has some notable advantages over IPsec for addressing the SPEERMINT security requirements. In particular, transport layer security is preferable over IPsec for SPEERMINT because with TLS (or DTLS) security is more closely coupled to the LUF or LRF. From a mere technical perspective, however, both solutions (transport layer security or IPsec) fulfill the SPEERMINT security requirements, and there may be particular cases where IPsec is a preferable solution.
要約すると、TLS（またはDTLS）はSPEERMINTセキュリティ要件に対処するためにIPsecを超えるいくつかの注目すべき利点があります。 TLS（またはDTLS）を使用してセキュリティをより密接LUFまたはLRFに連結されているので、特に、トランスポート層セキュリティはSPEERMINTのIPsec上好ましいです。単なる技術的な観点から、しかし、両方の溶液（トランスポート層セキュリティやIPsec）がSPEERMINTセキュリティ要件を満たし、かつIPsecが好ましい解決策である特定の場合があります。
This section describes implementer-specific countermeasures against the threats described in the previous sections and for addressing the SPEERMINT security requirements described in [RFC6271]. The countermeasures listed in this section are not meant to be exhaustive; rather, the suggested countermeasures are aimed to serve as starting points and to give guidance for implementers that are trying to select appropriate countermeasures against certain threats.
このセクションでは、前のセクションでと[RFC6271]で説明SPEERMINTセキュリティ要件に対処するための説明脅威に対する実装固有の対策を説明しています。このセクションに記載されている対策を網羅するものではありません。むしろ、提案の対策が出発点として機能するようにして、特定の脅威に対する適切な対策を選択しようとしている実装のための指針を与えることを目的としています。
The following table provides a map of the relationships between threats and countermeasures. The suggested countermeasures are discussed in detail in the subsequent subsections.
次の表は、脅威と対策の関係のマップを提供します。提案対策は、後続のサブセクションで詳細に説明されています。
+-------+---------------+-------------------------------------------+
| Group | Threat | Suggested Countermeasure |
+-------+---------------+-------------------------------------------+
| LUF | Unauthorized | database security BCPs (Section 4.1), |
| | access | Secure Exchange of SIP messages |
| | | (Section 4.5) |
| | SQL injection | database security BCPs (Section 4.1), |
| | | Secure Exchange of SIP messages |
| | | (Section 4.5) |
| | DoS to LUF | database security BCPs (Section 4.1), |
| | | Secure Exchange of SIP messages |
| | | (Section 4.5) |
| LRF | URI | privacy protection (Section 4.4), Secure |
| | harvesting | Exchange of SIP messages (Section 4.5) |
| | SIP equipment | privacy protection (Section 4.4), Secure |
| | enumeration | Exchange of SIP messages (Section 4.5) |
| | MitM attack | DNSSEC (Section 4.2), Secure Exchange of |
| | | SIP messages (Section 4.5) |
| | Incorrect | DNSSEC (Section 4.2), Secure Exchange of |
| | destinations | SIP messages (Section 4.5) |
| | DoS to LRF | DNS replication (Section 4.3) |
| SF | Call pattern | Secure Exchange of SIP messages |
| | analysis | (Section 4.5), Securing Session |
| | | Establishment Data (Section 4.12) |
| | Password | Secure Exchange of SIP messages |
| | cracking | (Section 4.5) |
| | Network | Securing Session Establishment Data |
| | discovery | (Section 4.12), Topology Hiding |
| | | (Section 4.10) |
| | Session | Secure Exchange of SIP messages |
| | teardown | (Section 4.5), ingress filtering |
| | | (Section 4.6) |
| | Billing fraud | strong identity assertion (Section 4.7) |
| | User ID | strong identity assertion (Section 4.7) |
| | spoofing | |
| | Forged 200 | Secure Exchange of SIP messages |
| | Response | (Section 4.5), ingress filtering |
| | | (Section 4.6) |
| | Forged 302 | Secure Exchange of SIP messages |
| | Response | (Section 4.5), ingress filtering |
| | | (Section 4.6) |
| | Forged 404 | Secure Exchange of SIP messages |
| | Response | (Section 4.5), ingress filtering |
| | | (Section 4.6) |
| | Flooding | reliable border element pooling |
| | attack | (Section 4.8), rate limit (Section 4.9) |
| | Session | DNSSEC (Section 4.2) |
| | blackholing | |
| | SIP fuzzing | border element hardening (Section 4.11) |
| | attack | |
| MF | Eavesdropping | Encryption and Integrity Protection of |
| | | Media Stream (Section 4.13) |
| | Media | Encryption and Integrity Protection of |
| | injection | Media Stream (Section 4.13) |
| | Media session | Encryption and Integrity Protection of |
| | teardown | Media Stream (Section 4.13) |
| | QoS | Encryption and Integrity Protection of |
| | degradation | Media Stream (Section 4.13) |
| | Malformed | border element hardening (Section 4.11) |
| | messages | |
| | Message | rate limit (Section 4.9) |
| | flooding | |
+-------+---------------+-------------------------------------------+
Adequate security measures must be applied to the LUF to prevent it from being a target of attacks often seen on common database systems. Common security Best Current Practices (BCPs) for database systems include the use of strong passwords to prevent unauthorized access, parameterized statements to prevent SQL injections, and server replication to prevent any database from being a single point of failure. [DBSEC] is one of many existing documents that describe BCPs in this area.
適切なセキュリティ対策は、多くの場合、一般的なデータベース・システムに見られる攻撃の対象となるのを防ぐためにLUFに適用されなければなりません。データベースシステムのための一般的なセキュリティのベスト現在のプラクティス（のBCP）は、単一障害点であるから、任意のデータベースを防ぐために、不正アクセス、SQLインジェクションを防ぐために、パラメータ化された文、およびサーバーの複製を防止するための強力なパスワードの使用を含みます。 [DBSEC]この領域でのBCPを説明し、多くの既存の文書の一つです。
If DNS is used by the LRF, it is recommended to deploy the recent version of Domain Name System Security Extensions (informally called "DNSSEC-bis") defined by [RFC4033], [RFC4034], and [RFC4035]. DNSSEC has been designed to protect DNS against well-known attacks such as DNS cache poisoning or Man-in-the-Middle (MitM) attacks on DNS queries. Essentially, DNSSEC is a set of public key cryptography extensions to DNS that provide authentication of DNS data, integrity protection for DNS entries, and authenticated denial of existence regarding non-existing DNS entries. In the context of SSP peering, DNSSEC can provide authentication and integrity regarding the location of a Signaling Function (SF) entity retrieved via DNS. Using DNSSEC can thus help to defend against MitM attacks on DNS queries invoked by the LRF, session blackholing and other attacks that lead traffic to incorrect destinations.
DNSは、LRFで使用されている場合は、[RFC4033]、[RFC4034]、および[RFC4035]で定義されたドメインネームシステムのセキュリティ拡張機能（非公式に「DNSSECビス」と呼ばれる）の最新バージョンを展開することをお勧めします。 DNSSECは、DNSクエリのDNSキャッシュポイズニングやMITM（中間者）攻撃などのよく知られた攻撃からDNSを保護するように設計されています。基本的に、DNSSECは、DNSエントリの完全性保護、DNSデータの認証を提供するDNSに公開鍵暗号の拡張機能のセットで、非既存のDNSエントリに関して存在の否定を認証されました。 SSPピアリングの文脈では、DNSSECは、DNSを介して検索されたシグナリング機能（SF）エンティティの位置に関する認証と完全性を提供することができます。 DNSSECを使用すると、このようにLRF、セッションのブラックホールと間違った宛先にトラフィックを導くその他の攻撃によって呼び出されたDNSクエリ上のMITM攻撃を防御するのに役立ちます。
DNSSEC has been deployed at the root level and in several top-level domains (e.g., .com and .net). Although, at the time of this writing, DNSSEC is still not yet widely deployed on the Internet, even limited deployment can add significant integrity protection and authentication to the LRF for Signaling Function locations received via DNS entries. Neither end users nor terminals are involved in the DNS resolution process of the LRF. Hence, if a) the sending SSP uses a DNS resolver that supports DNSSEC extensions, b) the receiving SSP stores the location of its Signaling Function cryptographically signed (using DNSSEC extensions) in the DNS, and c) the sending SSP can obtain an authentication chain (i.e., a series of linked DS and DNSKEY records) to the receiving SSP, the LRF can be secured with DNSSEC. In the context of SPEERMINT, all three of these requirements can be fulfilled even in the case of partial DNSSEC deployment. In particular, even without Internet-wide deployment of DNSSEC, it may be possible for a sending SSP to obtain a suitable trust anchor for verifying the receiving SSP's public key. For instance, a suitable trust anchor could be configured for that specific SSP's top-level domain or for the particular SSP's domain directly. If the sending and the receiving SSP use a common ENUM tree, DNSSEC use with the ENUM tree's trust anchor is "straightforward".
DNSSECは、ルートレベルで、いくつかのトップレベルドメイン（例えば、.COMおよび.NET）に配備されています。この記事の執筆時点では、DNSSECはまだまだ広くインターネット上に展開されていない、けれども、でも、限られた展開では、DNSエントリを介して受信された機能の場所に信号を送るためLRFに重要な完全性保護と認証を追加することができます。どちらのエンドユーザーや端末がLRFのDNS解決プロセスに関与しています。 A）送信SSPがDNSSEC拡張をサポートDNSリゾルバを使用する場合したがって、a、b）は受信SSPは、暗号DNSに（）DNSSEC拡張を使用して署名され、そのシグナル伝達機能の位置を記憶し、そしてc）送信SSPは、認証を取得することができます受信SSPへの連鎖（リンクDSとDNSKEYレコードのすなわち、シリーズ）、LRFは、DNSSECを確保することができます。 SPEERMINTの文脈では、これらの要件のすべての3つであっても、部分的DNSSECの導入の場合に満たすことができます。送信SSPは、受信SSPの公開鍵を検証するために、適切なトラストアンカーを取得するために、特に、でもDNSSECのインターネット全体の展開せずに、それが可能です。例えば、適したトラストアンカーは、その特定のSSPのトップレベルドメインのために、または直接、特定のSSPのドメイン用に構成することができます。送信側と受信側のSSPは、共通のENUMツリーを使用している場合は、ENUMツリーのトラストアンカーとDNSSECの使用は、「単純明快」です。
DNS replication is a very important countermeasure to mitigate DoS attacks on the LRF. Simultaneously bringing down multiple DNS servers that support the LRF is much more challenging than attacking a sole DNS server (single point of failure).
DNSの複製は、LRFにDoS攻撃を軽減するために非常に重要な対策です。同時に、LRFは、はるかに困難な唯一のDNSサーバー（単一障害点）を攻撃するよりもサポートして複数のDNSサーバーをダウンさせ。
Stripping Via and Record-Route headers, replacing the Contact header, and even changing Call-IDs are the mechanisms described in [RFC3323] to protect SIP privacy. This practice allows an SSP to hide its SIP network topology, prevents intermediate signaling equipment from becoming the target of DoS attacks, as well as protects the privacy of UEs according to their preferences. This practice is effective in preventing SIP equipment enumeration that exploits LRF.
、ビアとレコードルートヘッダを剥離Contactヘッダを置き換え、さらに変化のCall-IDは、SIPのプライバシーを保護するために[RFC3323]で説明されたメカニズムです。この方法は、SSPがそのSIPネットワークトポロジーを隠蔽することを可能にするDoS攻撃の対象となる、並びにそれらの好みに応じたUEのプライバシーを保護するから中間シグナリング装置を防ぎます。この方法は、LRFを利用SIP機器の列挙を防ぐのに効果的です。
SIP can be used on top of UDP or TCP as transport protocol [RFC3261]. However, look-up and SED data should be exchanged securely (see security requirements (Section 3.2)), e.g., to increase the difficulty of performing session teardown and forging responses (200, 302, 404, etc). If UDP is used to carry SIP messages, DTLS should be used to secure SIP message exchange between SSPs. If TCP is used as a transport protocol, it can be secured with TLS. Therefore, depending on the underlying transport protocol, SSPs should use either DTLS or TLS to secure SIP message delivery.
SIPは、トランスポートプロトコル[RFC3261]としてUDPまたはTCPの上で使用することができます。しかし、ルックアップとSEDのデータは、例えば、（など、200、302、404）セッションのティアダウンを実行し、応答を鍛造することの難しさを高めるために（セキュリティ要件（3.2節）を参照）安全に交換する必要があります。 UDPは、SIPメッセージを運ぶために使用されている場合は、DTLSはSSPの間のSIPメッセージの交換を確保するために使用されるべきです。 TCPはトランスポートプロトコルとして使用されている場合は、TLSで保護することができます。したがって、基礎となるトランスポートプロトコルに応じて、SSPがSIPメッセージの配信を確保するためにDTLSまたはTLSのいずれかを使用すべきです。
In general, encryption and integrity protection of signaling messages can be achieved on the transport layer (with TLS or DTLS) or on the network layer (with IPsec). Both solutions are technically sound, but transport layer security has some advantages. Please refer to the subsection on fulfilling the SPEERMINT security requirements (Section 3.2) for a discussion on using TLS/DTLS or IPsec for protecting the confidentiality and integrity of signaling messages. Similar to strong identity assertion, a Public Key Infrastructure (PKI) is assumed to be in place for TLS/DTLS (or IPsec) deployment so that SSPs can obtain and trust the keys necessary to decrypt messages and verify signatures sent by other SSPs.
一般的に、シグナリングメッセージの暗号化および完全性保護（TLSまたはDTLSで）トランスポート層の上又は（IPsecを使用）、ネットワーク層上で達成することができます。どちらのソリューションは、技術的に健全であるが、トランスポート層セキュリティは、いくつかの利点があります。シグナリングメッセージの機密性と完全性を保護するためにTLS / DTLSまたはIPsecを使用しての議論のためのSPEERMINTセキュリティ要件（3.2節）を満たす上でのサブセクションを参照してください。強いIDアサーションと同様に、公開鍵基盤（PKI）は、SSPのは、取得したメッセージを復号化し、他のSSPによって送られた署名を検証するために必要なキーを信頼できるように、TLS / DTLS（またはIPsec）の展開のための場所であると仮定されます。
Message-oriented protection such as [RFC3261] authentication does not fulfill the SPEERMINT requirements (e.g., mutual authentication).
このような[RFC3261]として認証メッセージ指向保護SPEERMINT要件（例えば、相互認証）を満たしていません。
Ingress filtering, i.e., blocking all traffic coming from a host that has a source address different than the addresses that have been assigned to that host (see [RFC2827]), can effectively prevent UEs from sending packets with a spoofed source IP address. This can be achieved by reverse-path filtering, i.e., only accepting ingress traffic if responses would take the same path. This practice is effective in preventing session teardown and forged SIP replies (200, 302, 404, etc.), if the recipient correctly verifies the source IP address for the authenticity of each incoming SIP message.
イングレスフィルタリング、すなわち、そのホストに割り当てられているアドレスとは異なる送信元アドレスを持つホストからのすべてのトラフィックをブロックし、効果的に偽装された送信元IPアドレスを持つパケットを送信するUEを防止することができる（[RFC2827]を参照します）。これは、応答が同じ経路を取る場合にのみ入力トラフィックを受け入れ、即ち、リバースパスフィルタリングによって達成することができます。この方法は、受信者が正しく各着信SIPメッセージの真正の送信元IPアドレスを検証した場合、セッションのティアダウンと鍛造のSIP応答（200、302、404、等）を防止するのに有効です。
"Caller ID spoofing" can be achieved thanks to the weak identity assertion on the From URI of an INVITE request. In a single SSP domain, strong identity assertion can be easily achieved by authenticating each INVITE request. However, in the context of SPEERMINT, only the Originating SSP is able to verify the identity directly. In order to overcome this problem, there are currently only two major approaches: transitive trust and cryptographic signature. The transitive trust approach builds a chain of trust among different SSP domains. One example of this approach is a combined mechanism specified in [RFC3324] and [RFC3325]. Using this approach in a transit peering network scenario, the terminating SSP must establish a trust relationship with all SSP domains on the path, which can be seen as an underlying weakness. The use of cryptographic signatures is an alternative approach. "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format" is specified in [RFC3893]. [RFC4474] introduces two new header fields, IDENTITY and IDENTITY-INFO, that allow a SIP server in the Originating SSP to digitally sign an INVITE request after authenticating the sending UE. The terminating SSP can verify if the
「発信者IDのスプーフィングは、」INVITEリクエストのURIからの弱アイデンティティ・アサーションのおかげで達成することができます。単一SSPドメインにおいて、強いIDアサーションは、容易にINVITE要求を認証することによって達成することができます。しかし、SPEERMINTの文脈では、唯一の発信SSPは、直接の身元を確認することができます。推移的な信頼と暗号化署名：この問題を克服するために、現在、唯一の2つの主要なアプローチがあります。推移的な信頼のアプローチは異なるSSPのドメイン間の信頼の連鎖を構築します。このアプローチの一例は、[RFC3324]及び[RFC3325]で指定された合成機構です。中継ピアリングネットワークのシナリオでは、このアプローチを使用して、終端SSPは、基礎となる弱点として見ることができる経路上のすべてのSSPのドメインとの信頼関係を確立しなければなりません。暗号署名の使用は、代替的なアプローチです。 「セッション開始プロトコル（SIP）認証済みアイデンティティボディ（AIB）フォーマット」[RFC3893]で指定されています。 [RFC4474]は発信SSPにおけるSIPサーバは、デジタル送信UEを認証した後に、INVITE要求に署名するための2つの新しいヘッダフィールド、IDENTITYとIDENTITY-INFOを導入します。終端SSPがいるかどうかを確認することができます
INVITE request is signed by a trusted SSP domain. Although this approach does not require the terminating SSP to establish a trust relationship with all transit SSPs on the path, a PKI is assumed to be in place.
INVITEリクエストは、信頼されたSSPドメインによって署名されています。このアプローチは、パス上のすべてのトランジットのSSPとの信頼関係を確立するために終了するSSPを必要としませんが、PKIは、所定の位置にあると想定されます。
It is advisable to implement reliable pooling on border elements. An architecture and protocols for the management of server pools supporting mission-critical applications are addressed in the RSERPOOL WG. Using such mechanisms and protocols (see [RFC5351] [RFC5352] [RFC5353] for details), a UE can effectively increase its capacity in handling flooding attacks.
境界要素に関する信頼できるプールを実装することをお勧めします。ミッションクリティカルなアプリケーションをサポートするサーバー・プールの管理のためのアーキテクチャとプロトコルはRSERPOOL WGで対処されています。そのようなメカニズムおよびプロトコルを使用して（詳細については[RFC5351]、[RFC5352]、[RFC5353]を参照）、UEは、効果的にフラッディング攻撃の処理にその容量を増加させることができます。
Flooding attacks on SFs and MFs can also be mitigated by limiting the rate of incoming traffic through policing or queuing. In this way, legitimate clients can be denied the service since their traffic may be discarded. Rate limiting can also be applied on a per-source-IP basis under the assumption that the source IP of each attack packet is not spoofed dynamically. Limitations related to NAT and mobility issues apply and may result in false positives (i.e., source IP addresses blocked) when multiple legitimate clients are located behind the same NAT IP address. It may be preferable to limit the number of concurrent 'sessions', i.e., ongoing calls instead of the messaging associated with it (since sessions use more resources on backend-systems). When calculating rate limits, all entities along the session path should be taken into account. SIP entities on the receiving end of a call may be the limiting factor (e.g., the number of ISDN channels on PSTN gateways) rather than the ingress limiting device.
SFとMFSのフラッディング攻撃もポリシングまたはキューイングを通じて着信トラフィックのレートを制限することによって緩和することができます。そのトラフィックが破棄されてもよいので、この方法では、正当なクライアントは、サービスを拒否することができます。レート制限は、各攻撃パケットの送信元IPが動的に偽装されていないという仮定の下あたりのソースIPベースで適用することができます。 NATとモビリティの問題に関連する制限事項が適用され、偽陽性（すなわち、送信元のIPアドレスがブロックされた）複数の正当なクライアントが同じNAT IPアドレスの背後に配置されているときになることがあります。 （セッションは、バックエンド・システムに、より多くのリソースを使用するので）代わりに、それに関連付けられたメッセージの、すなわち、継続中の呼同時「セッション」の数を制限することが好ましいかもしれません。レート制限を計算する場合、セッションパスに沿ってすべてのエンティティを考慮すべきです。コールの受信側SIPエンティティはかなり制限装置入口より限定的因子（例えば、PSTNゲートウェイ上のISDNチャネルの数）であってもよいです。
Topology hiding applies to both the signaling and media plane and consists of limiting the amount of topology information exposed to peering partners. Topology hiding requires back-to-back user agent (B2BUA) functionality. The most common way is the use of a Session Border Controller (SBC) as SBE. Topology hiding is explained in [RFC5853].
トポロジー隠蔽は、シグナリングとメディアプレーンの両方に適用され、ピアリングパートナーにさらされるトポロジー情報の量を制限することから成ります。トポロジ隠蔽は、バックツーバックユーザエージェント（B2BUA）機能が必要です。最も一般的な方法は、SBEとしてセッションボーダーコントローラー（SBC）の使用です。トポロジー隠蔽は、[RFC5853]で説明されています。
To prevent attacks that exploit vulnerabilities (such as buffer overflows, format string vulnerabilities, etc.) in SPEERMINT border elements, these implementations should be security hardened. For instance, fuzz testing is a common black box testing technique used in software engineering. Also, security vulnerability tests can be carried out preventively to assure a UE/SBE/DBE can handle unexpected data correctly without crashing. [RFC4475] and [PROTOS] are examples of torture test cases specific for SIP devices and freely available security testing tools, respectively. These type of tests needs to be carried out before product release and in addition throughout the product life cycle.
SPEERMINT境界要素に（例えばバッファオーバーフロー、書式文字列の脆弱性など）の脆弱性を悪用する攻撃を防ぐために、これらの実装は、セキュリティを強化する必要があり。例えば、ファズ・テストは、ソフトウェア工学で使用される一般的なブラックボックステスト技術です。また、セキュリティ上の脆弱性テストは、クラッシュすることなく正確に予期しないデータを扱うことができるUE / SBE / DBEを確保するために予防的に行うことができます。 [RFC4475]及び[PROTOS]は、それぞれ、SIPデバイスと自由に利用可能なセキュリティテストツールのための特定の拷問テストケースの例です。テストのこれらのタイプは、製品のリリース前に、製品のライフサイクル全体加えて行う必要があります。
Session Establishment Data (SED) contains critical information for the routing of SIP sessions. In order to prevent attacks such as service hijacking and denial of service that exploit SED, SSPs should adopt a secure transport protocol that provides authentication, confidentiality and integrity to exchange SED among themselves. Further details can be found in [DRINKS-SPPROV].
セッション確立データ（SED）は、SIPセッションのルーティングのための重要な情報が含まれています。 SEDを利用するようなサービスのサービスの乗っ取りや拒否などの攻撃を防ぐために、SSPが自分たちの中でSEDを交換するために、認証、機密性と完全性を提供し、安全なトランスポートプロトコルを採用すべきです。さらなる詳細は[ドリンク-SPPROV]に見出すことができます。
The Secure Real-time Transport Protocol (SRTP) [RFC3711] prevents eavesdropping on plain RTP by encrypting the data flow. It uses AES as the default cipher and defines two modes of operation (Segmented Integer Counter Mode and f8-mode), which is agreed upon after negotiation. It also uses HMAC-SHA1 and index keeping to enable message authentication/integrity and replay protection required to prevent media injection attacks. Secure RTCP (SRTCP) provides the same security-related features to RTCP as SRTP does for RTP. SRTCP is described in [RFC3711] as optional. In order to prevent media session teardown, it is recommended to turn this feature on. The choice of the external key management protocol is left to the deployment, a PKI is necessary to implement the security requirements of the SPEERMINT requirements document.
セキュアリアルタイム転送プロトコル（SRTP）[RFC3711]は、データフローを暗号化することで、プレーンRTP上の盗聴を防止します。これは、デフォルトの暗号としてAESを使用し、2つの動作モード（セグメント化された整数カウンタモードとF8-モード）ネゴシエーション後に合意され、定義されています。また、メディア・インジェクション攻撃を防ぐために必要なメッセージ認証/完全性および再生保護を有効にするために維持するHMAC-SHA1とインデックスを使用しています。セキュアRTCP（SRTCP）SRTPは、RTPの場合と同様にRTCPに同一のセキュリティ関連機能を提供します。 SRTCPは、オプションとして、[RFC3711]に記載されています。メディアセッションのティアダウンを防止するためには、この機能をオンにすることをお勧めします。外部の鍵管理プロトコルの選択は、展開に残され、PKIはSPEERMINT要件ドキュメントのセキュリティ要件を実装する必要があります。
This document presented the different SPEERMINT security threats classified in groups related to the LUF, LRF, SF, and MF, respectively. The multiple instances of the threats were presented with a brief explanation. Finally, suggested countermeasures for SPEERMINT were outlined together with possible mitigation of the existing threats by means of them.
この文書は、それぞれ、LUF、LRF、SF、およびMFに関連するグループに分類異なるSPEERMINTセキュリティの脅威を提示しました。脅威の複数のインスタンスは、簡単な説明で発表されました。最後に、SPEERMINTための対策は、それらの手段によって、既存の脅威の可能性緩和と一緒に概説された提案。
This document is entirely focused on the security threats for SPEERMINT.
この文書は完全にSPEERMINTのためのセキュリティの脅威に焦点を当てています。
This document was originally inspired by the VOIPSA VoIP Security and Privacy Threat Taxonomy. The authors would like to thank VOIPSA for having produced a comprehensive taxonomy as the starting point of this document. Additionally, the authors would like to thank Cullen Jennings, Jon Peterson, David Schwartz, Hadriel Kaplan, Peter Koch, Daryl Malas, Jason Livingood, and Robert Sparks for useful comments to previous editions of this document on the mailing list as well as during IETF meetings.
この文書は、もともとVOIPSA VoIPのセキュリティとプライバシーの脅威分類学に触発されました。著者は本書の出発点として、包括的な分類法を作成したためVOIPSAに感謝したいと思います。さらに、著者はIETFメーリングリストでこのドキュメントの以前の版にだけでなく、中に有益なコメントをカレン・ジェニングス、ジョンピーターソン、デヴィッド・シュワルツ、Hadrielカプラン、ピーター・コッホ、ダリル・マラス、ジェイソンLivingood、およびロバート・スパークスに感謝したいと思います会議。
Jan Seedorf and Saverio Niccolini are partially supported by the DEMONS project, a research project supported by the European Commission under its 7th Framework Program (contract no. 257315). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the DEMONS project or the European Commission.
ヤン・セードルフとサヴェリオニッコリーニは、部分的にDEMONSプロジェクト、その第7フレームワークプログラムの下で、欧州委員会でサポートされている研究プロジェクト（契約なし。257315）をサポートしています。ここに含まれている見解と結論は著者のものであり、DEMONSプロジェクトや欧州委員会の、明示または黙示、必ずしも公式のポリシーまたは推薦を表すものとして解釈すべきではありません。
[DBSEC] Gertz, M. and S. Jajodia, "Handbook of Database Security: Applications and Trends", Springer, 2008.
[DBSEC]ガーツ、M.とS. Jajodia、 "データベースセキュリティのハンドブック：アプリケーションと動向"、スプリンガー、2008。
[DRINKS-SPPROV] Mule, J., Cartwright, K., Ali, S., and A. Mayrhofer, "Session Peering Provisioning Protocol", Work in Progress, September 2011.
[DRINKS-SPPROV]ミュール、J.、カートライト、K.、アリ、S.、およびA. Mayrhofer、 "セッションピアリングプロビジョニングプロトコル"、進歩、2011年9月での作業。
[PROTOS] Wieser, C., Laakso, M., and H. Schulzrinne, "SIP Robustness Testing for Large-Scale Use", First International Workshop on Software Quality (SOQUA 2004), September 2004.
[PROTOS] Wieserの、C.、Laakso、M.、およびH. Schulzrinneと、 "大規模使用のためのSIP堅牢性テスト"、ソフトウェア品質上の第一回国際ワークショップ（SOQUA 2004）、2004年9月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、BCP 38、RFC 2827、2000年5月。
[RFC3261] 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.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[RFC3324]ワトソン、M.、2002年11月、RFC 3324、 "ネットワークのための短期要件は、アイデンティティをアサート"。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[RFC3893]ピーターソン、J.、 "セッション開始プロトコル（SIP）認証済みアイデンティティボディ（AIB）フォーマット"、RFC 3893、2004年9月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.
[RFC4475]スパークス、R.、Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）調教テストメッセージ"、RFC 4475、2006年5月。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[RFC4568]アンドレア、F.、Baugher、M.、およびD.翼、 "メディア・ストリームのセッション記述プロトコル（SDP）のセキュリティの説明"、RFC 4568、2006年7月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]ハンドリー、M.、レスコラ、E.、およびIAB、 "インターネットサービス拒否の注意事項"、RFC 4732、2006年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An Overview of Reliable Server Pooling Protocols", RFC 5351, September 2008.
[RFC5351]レイ、P.、オング、L.、Tuexen、M.、およびT. Dreibholz、 "信頼できるサーバプーリングプロトコルの概要"、RFC 5351、2008年9月。
[RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP)", RFC 5352, September 2008.
[RFC5352]スチュワート、R.、謝、Q.、スティルマン、M.、およびM. Tuexen、 "集計サーバアクセスプロトコル（至急）"、RFC 5352、2008年9月。
[RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008.
[RFC5353]謝、Q.、スチュワート、R.、スティルマン、M.、Tuexen、M.、およびA.シルバー、 "エンドポイントHandlespace冗長プロトコル（ENRP）"、RFC 5353、2008年9月。
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009.
[RFC5486]マラス、D.とD.マイヤー、 "マルチメディアインターコネクトのためのセッションピアリング（SPEERMINT）用語"、RFC 5486、2009月。
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853] Hautakorpi、J.、カマリロ、G.、ペンフィールド、R.、Hawrylyshen、A.、およびM. Bhatiaは、RFC 5853年4月 "セッション開始プロトコル（SIP）セッションボーダーコントロール（SBC）デプロイメントの要件" 2010。
[RFC6271] Mule, J-F., "Requirements for SIP-Based Session Peering", RFC 6271, June 2011.
[RFC6271]ミュール、J-F。、 "SIPベースのセッションピアリングのための要件"、RFC 6271、2011年6月。
[RFC6406] Malas, D., Ed. and J. Livingood, Ed., "Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture", RFC 6406, November 2011.
[RFC6406]マラス、D.、エド。そして、J. Livingood、エド。、2011年11月、RFC 6406 "のセッションは、マルチメディア相互接続（SPEERMINT）アーキテクチャのためのピアリング"。
[VOIPSATAXONOMY] Zar, J. and et al, "VOIPSA VoIP Security and Privacy Threat Taxonomy, Public Release 1.0", http://www.voipsa.org/Activities/taxonomy.php, October 2005.
[VOIPSATAXONOMY]ツァラ、J.らと、 "VOIPSA VoIPのセキュリティとプライバシーの脅威分類、公共リリース1.0"、http://www.voipsa.org/Activities/taxonomy.php、2005年10月。
Authors' Addresses
著者のアドレス
Jan Seedorf NEC Laboratories Europe, NEC Europe, Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
ヤン・セードルフNEC欧州研究所、NECヨーロッパ社Kurfuerstenコンディショニング36 69115ハイデルベルクドイツ
Phone: +49 (0) 6221 4342 221 EMail: jan.seedorf@neclab.eu URI: http://www.neclab.eu
電話：+49（0）6221 4342 221電子メール：jan.seedorf@neclab.eu URI：http://www.neclab.eu
Saverio Niccolini NEC Laboratories Europe, NEC Europe, Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
サヴェリオニッコリーニNEC欧州研究所、NECヨーロッパ社Kurfuerstenコンディショニング36 69115ハイデルベルクドイツ
Phone: +49 (0) 6221 4342 118 EMail: saverio.niccolini@.neclab.eu URI: http://www.neclab.eu
電話：+49（0）6221 4342 118 Eメール：@ saverio.niccolini .neclab.eu URI：http://www.neclab.eu
Eric Chen Information Sharing Platform Laboratories, NTT 3-9-11 Midori-cho Musashino, Tokyo 180-8585 Japan
エリック・チェン情報流通プラットフォーム研究所NTT 3-9-11みどり町武蔵野市、東京180から8585日本
EMail: eric.chen@lab.ntt.co.jp URI: http://www.ntt.co.jp/index_e.html
電子メール：eric.chen@lab.ntt.co.jp URI：http://www.ntt.co.jp/index_e.html
Hendrik Scholz VOIPFUTURE GmbH Wendenstrasse 4 Hamburg 20097 Germany
ヘンドリック・ショルツVOIPFUTURE社Wendenstrasse 4ハンブルク20097ドイツ
Phone: +49 (0) 40 688 900 163 EMail: hendrik.scholz@voipfuture.com URI: http://voipfuture.com
電話：+49（0）40 688 900 163 Eメール：hendrik.scholz@voipfuture.com URI：http://voipfuture.com