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
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）提供了一个对等框架，该框架利用现有IETF定义的协议（如SIP和ENUM）的构建块来实现SIP服务提供商（SSP）之间的互连。本文件的目的是识别和列举特定威胁向量，并为实施者选择适当对策提供指导。从本文件中详述的威胁中衍生出的SPEERMINT安全要求可在RFC 6271中找到；本文件提供了满足这些特殊安全要求的具体对策。在本文档中，与SPEERMINT相关的不同安全威胁分为对特定SIP服务提供商的查找功能（LUF）、位置路由功能（LRF）、信令功能（SF）和媒体功能（MF）的威胁。分类中简要介绍了各种威胁实例。最后，介绍了SIP和RTP/RTCP（实时传输控制协议）的现有安全解决方案，以描述目前可用于此类威胁的对策。每个SSP可以通过对等或传输合同连接到一个或多个远程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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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）工作组提供了一个对等框架，该框架利用现有IETF定义的协议（如SIP和ENUM）的构建块来实现SIP服务器之间的互连[RFC5486]。本文件的目的是识别和列举特定威胁向量，并为实施者选择适当对策提供指导。SPEERMINT的安全要求可在RFC 6271“基于SIP的会话对等要求”[RFC6271]中找到。SPEERMINT的这些安全要求源自本文件中详述的威胁；它们已从本文件的早期版本移至SPEERMINT需求文件[RFC6271]。除了作为这些安全要求的基础外，本文件还向实施者提供了关于如何通过技术手段满足这些安全要求的具体对策的建议和示例。本文件中使用了[RFC5486]中概述的特殊术语。
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服务提供商（SSP）的查找功能（LUF）、位置路由功能（LRF）、信令功能（SF）和媒体功能（MF）的威胁。本文简要介绍了各种威胁实例
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可以通过对等或传输合同连接到一个或多个远程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);
o 查找函数（LUF）；
o Location Routing Function (LRF);
o 位置路由功能（LRF）；
o Signaling Function (SF);
o 信号功能；
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:
对于给定的请求，查找函数（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和对等域捕获-如果基础数据库的身份验证系统较弱，或者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设备枚举-攻击者通过查看Via并记录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 中间人攻击-攻击者在修改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:
SF流量容易被窃听，特别是当数据在具有不同安全策略级别的多个SSP之间移动时。以下列出了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路由信息（即记录路由、Via或联系人头）了解直接或间接连接的对等伙伴的内部网络结构信息。
The integrity of the SF can be violated using SIP request spoofing, SIP reply spoofing, and SIP message tampering.
可以使用SIP请求欺骗、SIP应答欺骗和SIP消息篡改来破坏SF的完整性。
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 INVITE消息）要劫持的呼叫的SIP对话（标记、来自标记、呼叫ID），要么可能依赖没有基于SIP对话正确认证请求的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 计费欺诈-攻击者可以修改和重播截获的INVITE请求，以便向受害者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的信令功能（SF）之间进行注册。因此，应该拒绝诸如寄存器之类的多余请求。
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);
o 伪造200响应-在看到INVITE请求的内容后，窃听者可以注入200响应，从而影响注入点和发起UA之间以及发起UA本身的所有代理事务的处理。在极端情况下，这可能导致电话被劫持。然而，在许多情况下，这种攻击将留下可允许其被检测的信令伪影（例如，接收伪造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请求的内容后，窃听者还可以注入伪造的“302临时移动”回复，从而影响中间实体和发起UA的交易处理。这可能允许攻击者成功地将呼叫重定向到其选择的任何目标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请求的内容后，窃听者还可以注入伪造的“404未找到”回复，从而影响中间实体和发起UA的交易处理。此类攻击可能导致呼叫建立中断。
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音调的PIN）。一些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发送虚假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.
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中媒体安全属性的交换。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或DTL）的优点是，使用它的应用程序知道是否启用了安全性（或者更确切地说是相应的安全特性）。例如，如果相应的连接端点不能正确地进行身份验证，则使用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）在满足特定安全需求方面比IPsec有一些显著的优势。特别是，对于SPEERMINT，传输层安全性优于IPsec，因为使用TLS（或DTLS）时，安全性与LUF或LRF的耦合更紧密。然而，仅从技术角度来看，这两种解决方案（传输层安全或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]中描述的特殊安全要求的实施者特定对策。本节列出的对策并非详尽无遗；相反，建议的对策旨在作为起点，并为试图针对某些威胁选择适当对策的实施者提供指导。
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 | |
+-------+---------------+-------------------------------------------+
| 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 | |
+-------+---------------+-------------------------------------------+
| | 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.
如果LRF使用DNS，建议部署[RFC4033]、[RFC4034]和[RFC4035]定义的最新版本的域名系统安全扩展（非正式称为“DNSSEC bis”）。DNSSEC旨在保护DNS免受众所周知的攻击，如DNS缓存中毒或对DNS查询的中间人（MitM）攻击。从本质上讲，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
DNSSEC已部署在根级别和几个顶级域（例如.com和.net）中。尽管在撰写本文时，DNSSEC尚未在Internet上广泛部署，但即使是有限的部署也可以增加显著的完整性保护和安全性
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环境中，即使在部分DNSSEC部署的情况下，也可以满足所有这三个要求。特别是，即使没有在互联网范围内部署DNSSEC，发送SSP也可能获得适当的信任锚，用于验证接收SSP的公钥。例如，可以为特定SSP的顶级域或直接为特定SSP的域配置合适的信任锚。如果发送和接收SSP使用公共枚举树，则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.
[RFC3323]中描述的保护SIP隐私的机制包括剥离和记录路由头、替换联系人头，甚至更改呼叫ID。这种做法允许SSP隐藏其SIP网络拓扑，防止中间信令设备成为DoS攻击的目标，并根据用户的偏好保护其隐私。此实践可有效防止利用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可以在UDP或TCP之上用作传输协议[RFC3261]。但是，应安全地交换查找和SED数据（参见安全要求（第3.2节）），例如，增加执行会话拆卸和伪造响应的难度（200、302、404等）。如果UDP用于传输SIP消息，则应使用DTL来保护SSP之间的SIP消息交换。如果将TCP用作传输协议，则可以使用TLS对其进行保护。因此，根据底层传输协议，SSP应该使用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或DTL）或网络层（使用IPsec）上实现信令消息的加密和完整性保护。这两种解决方案在技术上都很可靠，但传输层安全性有一些优势。有关使用TLS/DTLS或IPsec保护信令消息的机密性和完整性的讨论，请参阅关于满足SPEERMINT安全要求的小节（第3.2节）。与强身份断言类似，假定TLS/DTLS（或IPsec）部署有公钥基础设施（PKI），以便SSP可以获得并信任解密消息和验证其他SSP发送的签名所需的密钥。
Message-oriented protection such as [RFC3261] authentication does not fulfill the SPEERMINT requirements (e.g., mutual authentication).
以消息为导向的保护，如[RFC3261]身份验证，不能满足特定的要求（如相互身份验证）。
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]），可有效防止UE发送具有伪造源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
由于INVITE请求的From URI上的弱标识断言，可以实现“呼叫方ID欺骗”。在单个SSP域中，通过对每个INVITE请求进行身份验证，可以轻松实现强身份断言。但是，在SPEERMINT上下文中，只有发起SSP能够直接验证身份。为了克服这个问题，目前只有两种主要的方法：传递信任和密码签名。传递信任方法在不同SSP域之间建立信任链。此方法的一个示例是[RFC3324]和[RFC3325]中指定的组合机制。在传输对等网络场景中使用此方法，终止SSP必须与路径上的所有SSP域建立信任关系，这可以被视为潜在的弱点。使用加密签名是另一种方法。[RFC3893]中规定了“会话启动协议（SIP）身份验证主体（AIB）格式”。[RFC4474]引入了两个新的头字段IDENTITY和IDENTITY-INFO，允许发起SSP中的SIP服务器在验证发送UE后对INVITE请求进行数字签名。终止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建立信任关系，但假定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 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）功能。最常见的方法是使用会话边界控制器（SBC）作为SBE。[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元素中的漏洞（如缓冲区溢出、格式字符串漏洞等）进行攻击，这些实现应该加强安全性。例如，模糊测试是一种常用的黑盒测试技术
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的服务劫持和拒绝服务，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作为默认密码，并定义了两种操作模式（分段整数计数器模式和f8模式），这两种模式在协商后达成一致。它还使用HMAC-SHA1和索引保持来启用防止媒体注入攻击所需的消息身份验证/完整性和重播保护。安全RTCP（SRTCP）为RTCP提供的安全相关功能与SRTP为RTP提供的功能相同。[RFC3711]中将SRTCP描述为可选。为了防止媒体会话断开，建议启用此功能。外部密钥管理协议的选择由部署决定，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的建议对策，以及通过这些对策缓解现有威胁的可能性。
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，感谢他们在邮件列表上以及IETF会议期间对本文件先前版本的有用评论。
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.
Jan Sedorf和Saverio Niccolini部分得到了DEMONS项目的支持，DEMONS项目是欧盟委员会第七个框架计划（合同号257315）支持的一个研究项目。本文中包含的观点和结论是作者的观点和结论，不应被解释为必然代表DEMONS项目或欧盟委员会的官方政策或支持，无论明示或暗示。
[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，“会话对等资源调配协议”，正在进行的工作，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]Ferguson，P.和D.Senie，“网络入口过滤：击败利用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：会话启动协议”，RFC 3261，2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[RFC3324]Watson，M.，“网络断言身份的短期要求”，RFC 33242002年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 33252002年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，“安全实时传输协议（SRTP）”，RFC 37112004年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 40342005年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 43012005年12月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，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]Peterson，J.和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，“传输层安全（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，“聚合服务器访问协议（ASAP）”，RFC 53522008年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，“端点Handlespace冗余协议（ENRP）”，RFC 53532008年9月。
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009.
[RFC5486]Malas，D.和D.Meyer，“多媒体互连的会话对等（SPEERMINT）术语”，RFC 54862009年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 58532010年4月。
[RFC6271] Mule, J-F., "Requirements for SIP-Based Session Peering", RFC 6271, June 2011.
[RFC6271]Mule，J-F，“基于SIP的会话对等的要求”，RFC6271，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.和J.Livingood，Ed.，“多媒体互连（SPEERMINT）架构的会话对等”，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.和等人，“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
Jan Seedorf NEC Laboratories Europe，NEC Europe，Ltd.Kurfuersten Anlage 36海德堡69115德国
Phone: +49 (0) 6221 4342 221
EMail: jan.seedorf@neclab.eu
URI: http://www.neclab.eu
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德国海德堡69115
Phone: +49 (0) 6221 4342 118
EMail: saverio.niccolini@.neclab.eu
URI: http://www.neclab.eu
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信息共享平台实验室，NTT 3-9-11 Midori cho Musashino，东京180-8585
EMail: eric.chen@lab.ntt.co.jp
URI: http://www.ntt.co.jp/index_e.html
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汉堡20097德国
Phone: +49 (0) 40 688 900 163
EMail: hendrik.scholz@voipfuture.com
URI: http://voipfuture.com
Phone: +49 (0) 40 688 900 163
EMail: hendrik.scholz@voipfuture.com
URI: http://voipfuture.com