[要約] 要約： RFC 6404は、SPEERMINT（Session PEERing for Multimedia INTerconnect）のセキュリティ脅威と対策についての情報を提供しています。目的： このRFCの目的は、SPEERMINTネットワークにおけるセキュリティ上の脅威を特定し、それに対する適切な対策を提案することです。
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
マルチメディアインターコネクト（Speermint）セキュリティの脅威と推奨される対策のセッションピアリング
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や列挙などの既存のIETF定義プロトコルの構成要素を活用するピアリングフレームワークを提供します。このドキュメントの目的は、Speermint固有の脅威ベクトルを特定して列挙し、適切な対策を選択する導入者にガイダンスを提供することです。このドキュメントで詳述されている脅威から導き出されたSpeermintのセキュリティ要件は、RFC 6271にあります。このドキュメントは、これらのSpeermintのセキュリティ要件を満たすための具体的な対策を提供します。このドキュメントでは、Speermintに関連するさまざまなセキュリティの脅威は、特定のSIPサービスのルックアップ関数（LUF）、位置ルーティング関数（LRF）、シグナル関数（SF）、およびメディア関数（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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
Voice over 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セルバー間の相互接続のためにSIPや列挙などの既存のIETF定義プロトコルの構成要素を活用するピアリングフレームワークを提供します[RFC5486]。このドキュメントの目的は、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
このドキュメントでは、Speermintに関連するさまざまなセキュリティの脅威は、特定のSIPサービスのルックアップ関数（LUF）、位置ルーティング関数（LRF）、シグナル関数（SF）、およびメディア関数（MF）に対する脅威に分類されます。プロバイダー（SSP）。脅威のさまざまな事例が内部に簡単に導入されます
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.
分類。最後に、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（機密性、整合性、および可用性）Triadに従ってリストされ、詳細にリストされています。
o Lookup Function (LUF);
o ルックアップ関数（LUF）;
o Location Routing Function (LRF);
o ロケーションルーティング関数（LRF）;
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は、終了ドメイン上の要求されたリソースのIDを決定するメカニズムを提供します。返されたIDは、ロケーションルーティング関数（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:
特定の要求に対して、ルックアップ関数（LUF）は、リクエストをルーティングするターゲットドメインを決定します。以下の攻撃は、LUFメッセージの盗聴に関して関連しています。
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.
o SIP URIおよびPeering Domain Harvesting-基礎となるデータベースに弱い認証システムがある場合、または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.
o URIの収穫 - 攻撃者は、多数のロケーションリクエストを発行することにより、既存のユーザーエンドポイント（UE）のURIとIPアドレスを収穫します。脆弱な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メッセージのVIAとRecord -routeヘッダーを調べることにより、各中間信号デバイスの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 中間の攻撃 - 攻撃者は、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攻撃は、LRFまたはLUFに多数のクエリを送信することで実行できます。これは、発信されたSSPが管理ドメイン外のURIの通話ルーティングデータを検索することを妨げた結果です。別の方法として、攻撃者はDNSを標的にして、SIPアドレスの解決を無効にすることができます。
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.
シグナリング関数には、多くの機密情報が含まれます。シグナリング機能を通じて、ユーザーエージェント（UAS）はアイデンティティを主張し、オペレーターは請求可能なリソースを承認します。信号機能の正確で信頼できる操作は、サービスプロバイダーにとって不可欠です。このセクションでは、シグナル伝達機能に対する潜在的なセキュリティの脅威について説明し、可能な攻撃ベクトルを詳述します。
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:
特に、さまざまなレベルのセキュリティポリシーを持つ複数のSSPにデータが移動する場合、SFトラフィックは盗聴に対して脆弱です。SFの機密性の脅威はここにリストされています：
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;
o コールパターン分析 - 攻撃者は、プライバシーに違反するユーザーのコールパターンを追跡します（たとえば、さまざまなユーザーのソーシャルネットワーク、毎日の電話の使用などを明らかにします）。また、ライバル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要求スプーフィング攻撃では、最初に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レイヤーで既存の呼び出しを取り壊すために、キャンセル/バイのメッセージを送信できます。このような攻撃のために、攻撃者は（たとえば、SIP招待メッセージを盗聴することで）、コールのSIPダイアログ（To-Tag、From-From、Call-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に電話をかけ、電話の支払いを避けるために、傍受された招待状リクエストを変更および再生できます。
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スプーフィング攻撃を実施するエントリポイントを作成する可能性があります。
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 不要なリクエスト - 攻撃者は、電話をハイジャックするためにレジスタリクエストを送信することにより、定期的な操作を妨害するリクエストを送信します。[RFC6406]で定義されているSpeermintアーキテクチャは、接続されたSSPのシグナリング関数（SFS）間の登録を必要としません。したがって、レジスタのような余分な要求を拒否する必要があります。
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 Forged 199の応答 - 攻撃者は、初期のダイアログを終了するためにForged 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);
o Forged 200の応答 - 招待要求の内容を見て、盗聴者は200の応答を注入でき、注入点と発生するUAの間のすべてのプロキシのトランザクションの処理に影響を与えます。極端な場合、これによりハイジャックされた呼び出しが発生する可能性があります。ただし、多くの場合、そのような攻撃は、それを検出できるように信号アーティファクトを残します（たとえば、Forged 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 Forged 302応答 - 招待リクエストの内容を見て、盗聴者は、中間エンティティと発信されるUAでのトランザクションの処理に影響を与え、鍛造「302移動」応答を注入することもできます。これにより、攻撃者は、選択した任意の目的地への通話を正常にリダイレクトすることができます。
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 Forged 404応答 - 招待リクエストの内容を見て、盗聴者は、中間エンティティと発信される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 セッションブラックホール - 攻撃者（中間の攻撃を行うことができると想定されている）は、特定の呼び出しが確立されないように、招待されている重要なパケットを意図的にドロップします。
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パケットよりも一貫して大きなタイムスタンプとシーケンス番号（許容範囲内）を持っている場合、受信者は偽の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.
o サービス品質（QOS）劣化 - 攻撃者は、実際に実験されたよりも多くのパケット損失またはジッターを広告する間違った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のメディアセキュリティ属性の交換を妨害してはなりません。SBESによって理解されていないメディア属性行は無視され、シグナリングパスに沿って渡される必要があります。
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または特定のセキュリティ機能がオンになっているかどうかを認識できないように、専用のエンティティによって多くの場合提供されます（「bump-in-the-wire」）。
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（またはDTL）には、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に適切なセキュリティ対策を適用して、一般的なデータベースシステムでよく見られる攻撃のターゲットであることを防ぐ必要があります。データベースシステムの一般的なセキュリティの最良の現在のプラクティス（BCPS）には、不正アクセスを防ぐための強力なパスワードの使用、SQLインジェクションを防ぐためのパラメーター化されたステートメント、およびデータベースが単一の障害点になるのを防ぐためのサーバーの複製が含まれます。[DBSEC]は、この分野のBCPを説明する多くの既存のドキュメントの1つです。
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-BIS」と呼ばれる）を展開することをお勧めします。DNSSECは、DNSキャッシュ中毒やDNSクエリに対する中間（MITM）攻撃などのよく知られた攻撃からDNSを保護するように設計されています。基本的に、DNSSECは、DNSデータの認証、DNSエントリの整合性保護、および存在しないDNSエントリに関する存在の認証拒否を提供するDNSへの公開キー暗号化拡張のセットです。SSP Peeringのコンテキストでは、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
DNSSECは、ルートレベルといくつかのトップレベルドメイン（.comや.netなど）で展開されています。この執筆時点では、DNSSECはまだインターネット上に広く展開されていませんが、展開が限られている場合でも、重要な完全性保護を追加し、
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".
DNSエントリを介して受信されたシグナリング関数の位置のLRFへの認証。エンドユーザーも端末も、LRFのDNS解像度プロセスに関与していません。したがって、a）送信SSPがDNSSEC拡張機能をサポートするDNSリゾルバーを使用する場合、b）受信SSPは、DNSで暗号化された（DNSSEC拡張機能を使用）暗号化されたシグナル関数の位置を保存し、c）送信SSPは認証を取得できますレシーブSSPにチェーン（つまり、リンクされた一連のDSおよびDNSKEYレコード）、LRFはDNSSECで固定できます。 Speermintのコンテキストでは、これら3つの要件はすべて、部分的なDNSSEC展開の場合でも満たすことができます。特に、DNSSECのインターネット全体の展開がなくても、SSPを送信すると、受信SSPの公開キーを検証するための適切な信頼アンカーを取得できる可能性があります。たとえば、特定のSSPのトップレベルドメインまたは特定のSSPのドメインに対して直接適切な信頼アンカーを構成できます。送信と受信SSPが共通の列挙ツリーを使用する場合、enum Treeの信頼アンカーで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.
SIPプライバシーを保護するために、[RFC3323]に記載されているメカニズムである、コンタクトヘッダーを介してストリッピングし、コンタクトヘッダーを交換し、さらにはCall-IDを変更することです。このプラクティスにより、SSPはSIPネットワークトポロジを隠すことができ、中間のシグナリング機器がDOS攻撃のターゲットになるのを防ぎ、好みに応じてUESのプライバシーを保護します。このプラクティスは、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データを安全に交換する必要があります（セキュリティ要件（セクション3.2）を参照）。たとえば、セッションの分解と鍛造応答（200、302、404など）を実行することの難しさを高める必要があります。UDPを使用してSIPメッセージを運ぶ場合、DTLを使用してSSP間のSIPメッセージ交換を確保する必要があります。TCPが輸送プロトコルとして使用される場合、TLSで保護できます。したがって、基礎となる輸送プロトコルに応じて、SSPSはDTLまたはTLSを使用してSIPメッセージ配信を保護する必要があります。
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）を満たすためのサブセクションを参照してください。強力なアイデンティティアサーションと同様に、SSPSがメッセージを復号化して他のSSPから送信した署名を検証するために必要なキーを取得および信頼できるように、公開キーインフラストラクチャ（PKI）が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.
イングレスフィルタリング、つまり、そのホストに割り当てられたアドレスとは異なるソースアドレスを持つホストから来るすべてのトラフィックをブロックする（[RFC2827]を参照）、UがスプーフィングされたソースIPアドレスでパケットを送信するのを効果的に防ぐことができます。これは、リバースパスフィルタリングによって達成できます。つまり、応答が同じパスを取る場合にのみ、イングレストラフィックを受け入れることができます。このプラクティスは、受信者が各着信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スプーフィング」は、招待状リクエストのURIからの弱いIDアサーションのおかげで達成できます。単一のSSPドメインでは、各招待リクエストを認証することで、強力なアイデンティティアサーションを簡単に達成できます。ただし、Speermintのコンテキストでは、発生するSSPのみがIDを直接検証できます。この問題を克服するために、現在、2つの主要なアプローチのみがあります。推移的信頼と暗号化の署名です。推移的信頼アプローチは、さまざまなSSPドメイン間で信頼のチェーンを構築します。このアプローチの1つの例は、[RFC3324]と[RFC3325]で指定された組み合わせメカニズムです。トランジットピアリングネットワークシナリオでこのアプローチを使用して、終了SSPは、パス上のすべてのSSPドメインとの信頼関係を確立する必要があります。これは、根本的な弱点と見なすことができます。暗号化署名の使用は、代替アプローチです。 「セッション開始プロトコル（SIP）認証されたアイデンティティボディ（AIB）形式」は[RFC3893]で指定されています。 [RFC4474] 2つの新しいヘッダーフィールド、IDとID-INFOを導入します。これにより、発信元のSSP内のSIPサーバーが、送信UEを認証した後に招待リクエストにデジタル的に署名できます。終了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.
招待リクエストは、信頼できるSSPドメインによって署名されます。このアプローチでは、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.
SFSおよびMFSへの洪水攻撃は、ポリシングまたはキューイングを通じて入ってくるトラフィックの速度を制限することにより、軽減することもできます。このようにして、トラフィックが破棄される可能性があるため、合法的なクライアントはサービスを拒否される可能性があります。各攻撃パケットのソースIPが動的にスプーフィングされていないという仮定の下で、レート制限は、ソースごとのIPベースで適用することもできます。 NATおよびモビリティの問題に関連する制限が適用され、複数の正当なクライアントが同じNAT IPアドレスの後ろに配置されている場合、誤検知（つまり、ソース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
Speermint Border Elementsの脆弱性（バッファーオーバーフロー、フォーマット文字列の脆弱性など）を活用する攻撃を防ぐために、これらの実装はセキュリティを強化する必要があります。たとえば、ファズテストは使用される一般的なブラックボックステスト手法です
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.
ソフトウェアエンジニアリング。また、セキュリティの脆弱性テストを予防的に実行して、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を活用するサービスのハイジャックやサービス拒否などの攻撃を防ぐために、SSPSは、SEDを交換するために認証、機密性、および完全性を提供する安全な輸送プロトコルを採用する必要があります。詳細については、[Drinks-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の盗聴を防ぎます。AEをデフォルトの暗号として使用し、交渉後に合意された2つの動作モード（セグメント化された整数カウンターモードとF8モード）を定義します。また、HMAC-SHA1とインデックスキーピングを使用して、メディアインジェクション攻撃を防ぐために必要なメッセージ認証/整合性とリプレイ保護を可能にします。Secure RTCP（SRTCP）は、RTPに対してSRTPと同じセキュリティ関連の機能を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に感謝したいと思います。さらに、著者は、Cullen Jennings、Jon Peterson、David Schwartz、Hadriel Kaplan、Peter Koch、Daryl Malas、Jason Livingood、およびRobert Sparksに感謝します。会議。
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.
ヤン・シードルフとサヴェリオ・ニッコリーニは、第7回フレームワークプログラム（契約番号257315）に基づいて欧州委員会がサポートする研究プロジェクトであるデーモンズプロジェクトによって部分的にサポートされています。本明細書に含まれる見解と結論は著者の見解であり、デーモンズプロジェクトまたは欧州委員会の表明または暗示された公式の政策または承認を必ずしも表現するものとして解釈されるべきではない。
[DBSEC] Gertz, M. and S. Jajodia, "Handbook of Database Security: Applications and Trends", Springer, 2008.
[DBSEC] Gertz、M。およびS. Jajodia、「データベースセキュリティのハンドブック：アプリケーションとトレンド」、Springer、2008。
[DRINKS-SPPROV] Mule, J., Cartwright, K., Ali, S., and A. Mayrhofer, "Session Peering Provisioning Protocol", Work in Progress, September 2011.
[Drinks-Spprov] Mule、J.、Cartwright、K.、Ali、S。、およびA. Mayrhofer、「Session Pearing Provisioning Protocol」、Work in Progress、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.セニー、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[RFC3324]ワトソン、M。、「ネットワーク主張されたアイデンティティの短期要件」、RFC 3324、2002年11月。
[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] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内での主張されたアイデンティティのセッション開始プロトコル（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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Real-Time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[RFC3893] Peterson、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] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル修正」、RFC 4035、2005年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、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] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、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] Sparks、R.、Hawrylyshen、A.、Johnston、A.、Rosenberg、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] Andreasen、F.、Baugher、M。、およびD. Wing、「セッション説明プロトコル（SDP）メディアストリームのセキュリティ説明」、RFC 4568、2006年7月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732] Handley、M.、Rescorla、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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] Lei、P.、Ong、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] Stewart、R.、Xie、Q.、Stillman、M。、およびM. Tuexen、「Aggregate Server Access Protocol（ASAP）」、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] Xie、Q.、Stewart、R.、Stillman、M.、Tuexen、M.、およびA. Silverton、「エンドポイントハンドルスペース冗長プロトコル（ENRP）」、RFC 5353、2008年9月。
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009.
[RFC5486] Malas、D。およびD. Meyer、「Multimedia Interconnect（Speermint）用語のセッションピアリング」、RFC 5486、2009年3月。
[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.、Camarillo、G.、Penfield、R.、Hawrylyshen、A。、およびM. Bhatia、「セッション開始プロトコル（SIP）セッション国境管理（SBC）の要件」、RFC 5853、4月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] Malas、D.、ed。and J. Livingood、ed。、「Multimedia Interconnect（Speermint）Architectureのセッションピアリング」、RFC 6406、2011年11月。
[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] Zar、J。およびet al、「Voipsa Voip Security and Privacy Threat Taxonomy、Public Release 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
JAN SEADORF NEC Laboratories Europe、NEC Europe、Ltd。Kurfuersten-Anlage 36 Heidelberg 69115ドイツ
Phone: +49 (0) 6221 4342 221
EMail: jan.seedorf@neclab.eu
URI: http://www.neclab.eu
Saverio Niccolini NEC Laboratories Europe, NEC Europe, Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Saverio Niccolini Nec Laboratories Europe、Nec Europe、Ltd。Kurfuersten-Anlage 36 Heidelberg 69115ドイツ
Phone: +49 (0) 6221 4342 118
EMail: 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
Eric Chen Information Sharing Platform Laboratories、NTT 3-9-11 Midori-Cho Musashino、Tokyo 180-8585 Japan
EMail: eric.chen@lab.ntt.co.jp
URI: http://www.ntt.co.jp/index_e.html
Hendrik Scholz VOIPFUTURE GmbH Wendenstrasse 4 Hamburg 20097 Germany
Hendrik Scholz Voipfuture GmbH Wendenstrasse 4 Hamburg 20097ドイツ
Phone: +49 (0) 40 688 900 163
EMail: hendrik.scholz@voipfuture.com
URI: http://voipfuture.com