Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 7340 NeuStar, Inc.
Category: Informational H. Schulzrinne
ISSN: 2070-1721 Columbia University
H. Tschofenig
September 2014
Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 7340 NeuStar, Inc.
Category: Informational H. Schulzrinne
ISSN: 2070-1721 Columbia University
H. Tschofenig
September 2014
Secure Telephone Identity Problem Statement and Requirements
安全电话标识问题声明和要求
Abstract
摘要
Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space.
在过去的十年中，基于SIP的IP语音（VoIP）系统已经取代了许多传统的电话部署。VoIP系统与传统电话网络的互通降低了主叫方号码和主叫方ID保证的总体水平，因为攻击者在策划批量商业呼叫方案、黑客语音信箱、，甚至绕过银行信任的多因素认证系统。尽管以前曾试图提供SIP通信来源的安全保证，但我们仍然缺乏在VoIP会话中识别主叫方的有效标准。本文分析了在互联网上为电话号码提供身份证明如此困难的原因，并展示了过去十年的变化如何为我们提供了将安全身份附加到SIP会话的新策略。它还对该领域的解决方案提出了高层次的要求。
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/rfc7340.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7340.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 ....................................................3
2. Problem Statement ...............................................4
3. Terminology .....................................................6
4. Use Cases .......................................................6
4.1. VoIP-to-VoIP Call ..........................................7
4.2. VoIP-PSTN-VoIP Call ........................................7
4.3. PSTN-to-VoIP Call ..........................................8
4.4. VoIP-to-PSTN Call ..........................................9
4.5. PSTN-VoIP-PSTN Call .......................................10
4.6. PSTN-to-PSTN Call .........................................11
5. Limitations of Current Solutions ...............................11
5.1. P-Asserted-Identity .......................................12
5.2. SIP Identity ..............................................14
5.3. VIPR ......................................................17
6. Environmental Changes ..........................................19
6.1. Shift to Mobile Communication .............................19
6.2. Failure of Public ENUM ....................................19
6.3. Public Key Infrastructure Developments ....................20
6.4. Prevalence of B2BUA Deployments ...........................20
6.5. Stickiness of Deployed Infrastructure .....................20
6.6. Concerns about Pervasive Monitoring .......................21
6.7. Relationship with Number Assignment and Management ........21
7. Basic Requirements .............................................22
8. Acknowledgments ................................................23
9. Security Considerations ........................................23
10. Informative References ........................................23
1. Introduction ....................................................3
2. Problem Statement ...............................................4
3. Terminology .....................................................6
4. Use Cases .......................................................6
4.1. VoIP-to-VoIP Call ..........................................7
4.2. VoIP-PSTN-VoIP Call ........................................7
4.3. PSTN-to-VoIP Call ..........................................8
4.4. VoIP-to-PSTN Call ..........................................9
4.5. PSTN-VoIP-PSTN Call .......................................10
4.6. PSTN-to-PSTN Call .........................................11
5. Limitations of Current Solutions ...............................11
5.1. P-Asserted-Identity .......................................12
5.2. SIP Identity ..............................................14
5.3. VIPR ......................................................17
6. Environmental Changes ..........................................19
6.1. Shift to Mobile Communication .............................19
6.2. Failure of Public ENUM ....................................19
6.3. Public Key Infrastructure Developments ....................20
6.4. Prevalence of B2BUA Deployments ...........................20
6.5. Stickiness of Deployed Infrastructure .....................20
6.6. Concerns about Pervasive Monitoring .......................21
6.7. Relationship with Number Assignment and Management ........21
7. Basic Requirements .............................................22
8. Acknowledgments ................................................23
9. Security Considerations ........................................23
10. Informative References ........................................23
In many communication architectures that allow users to communicate with other users, the need arises for identifying the originating party that initiates a call or a messaging interaction. The desire to identify communication parties in end-to-end communication derives from the need to implement authorization policies (to grant or reject call attempts) but has also been utilized for charging. While there are a number of ways to enable identification, this functionality has been provided by the Session Initiation Protocol (SIP) [RFC3261] by using two main types of approaches, namely, P-Asserted-Identity (PAI) [RFC3325] and SIP Identity [RFC4474], which are described in more detail in Section 5. The goal of these mechanisms is to validate that the originator of a call is authorized to claim an originating identifier. Protocols like the Extensible Messaging and Presence Protocol (XMPP) use mechanisms that are conceptually similar to those offered by SIP.
在许多允许用户与其他用户通信的通信体系结构中，需要识别发起呼叫或消息传递交互的发起方。在端到端通信中识别通信方的愿望源于实施授权策略（允许或拒绝呼叫尝试）的需要，但也被用于收费。虽然有许多方法可以实现标识，但是会话启动协议（SIP）[RFC3261]通过使用两种主要类型的方法提供了该功能，即P-断言标识（PAI）[RFC3325]和SIP标识[RFC4474]，这在第5节中有更详细的描述。这些机制的目标是验证呼叫的发起人是否有权声明发起标识符。可扩展消息和状态协议（XMPP）等协议使用的机制在概念上与SIP提供的机制类似。
Although solutions have been standardized, it turns out that the current deployment situation is unsatisfactory, and even worse, there is little indication that it will improve in the future. In [SECURE-ORIGIN], we illustrate what challenges arise. In particular, interworking with different communication architectures (e.g., SIP, Public Switched Telephone Network (PSTN), XMPP, Real-Time Communications on the Web (RTCWeb)) or other forms of mediation breaks the end-to-end semantic of the communication interaction and destroys any identification capabilities. (In this document, we use the term "PSTN" colloquially rather than in a legal or policy sense, as a common shorthand for the circuit-switched analog and time-division multiplexing (TDM) digital telephone system, often using Signaling System #7 (SS7) to control call setup and teardown.) Furthermore, the use of different identifiers (e.g., E.164 numbers vs. SIP URIs) creates challenges for determining who is able to claim "ownership" for a specific identifier; although domain-based identifiers (sip:user@example.com) might use certificate or DNS-related approaches to determine who is able to claim "ownership" of the URI, telephone numbers do not yet have any similar mechanism defined.
虽然解决办法已经标准化，但事实证明，目前的部署情况并不令人满意，更糟糕的是，几乎没有迹象表明今后会有所改善。在[SECURE-ORIGIN]一文中，我们阐述了出现的挑战。特别是，与不同通信体系结构（例如，SIP、公共交换电话网（PSTN）、XMPP、网上实时通信（RTCWeb））或其他形式的中介进行交互会破坏通信交互的端到端语义，并破坏任何识别能力。（在本文件中，我们将术语“PSTN”作为电路交换模拟和时分多路复用（TDM）数字电话系统的常用缩写，通常使用信令系统#7（SS7）来控制呼叫设置和拆卸，而不是法律或政策意义上的术语。）此外，使用不同的标识符（例如，164个数字与SIP URI）为确定谁能够声明特定标识符的“所有权”带来了挑战；尽管基于域的标识符（SIP：user@example.com)可能会使用证书或DNS相关方法来确定谁能够声明“所有权”在URI中，电话号码尚未定义任何类似的机制。
After the publication of the PAI and SIP Identity specifications ([RFC3325] and [RFC4474], respectively), further attempts have been made to tackle the topic but, unfortunately, with little success, due to the complexity of deploying solutions and the long list of (often conflicting) requirements. A number of years have passed since the last attempts were made to improve the situation, and we therefore believe it is time to give it another try. With this document, we would like to start to develop a common understanding of the problem
在PAI和SIP标识规范（分别为[RFC3325]和[RFC4474]）发布后，人们进一步尝试解决这一问题，但不幸的是，由于部署解决方案的复杂性和一长串（通常相互冲突的）需求，几乎没有成功。自从上次试图改善这种情况以来，已经过去了若干年，因此，我们认为现在是再次尝试的时候了。通过这份文件，我们希望开始对这个问题达成共识
statement as well as basic requirements to develop a vision on how to advance the state of the art and to initiate technical work to enable secure call origin identification.
声明以及基本要求，以制定关于如何提高技术水平的愿景，并启动技术工作以实现安全的呼叫来源识别。
In the classical Public Switched Telephone Network, there were a limited number of carriers, all of whom trusted each other to provide accurate caller origination information in an environment without any cryptographic validation. In some cases, national telecommunication regulation codified these obligations. This model worked as long as the number of entities was relatively small, easily identified (e.g., in the manner carriers are certified in the United States), and subject to effective legal sanctions in case of misbehavior. However, for some time, these assumptions have no longer held true. For example, entities that are not traditional telecommunication carriers, possibly located outside the country whose country code they are using, can act as voice service providers. While there was a clear distinction between customers and service providers in the past, VoIP service providers can now easily act as customers or either originating or transit providers. Moreover, the problem is not limited to voice communications, as growth in text messaging has made it another vector for bulk unsolicited commercial messaging relying on impersonation of a source telephone number or, sometimes, an SMS short code. For telephony, Caller ID spoofing has become common, with a small subset of entities either ignoring abuse of their services or willingly serving to enable fraud and other illegal behavior.
在传统的公共交换电话网络中，运营商数量有限，所有运营商都相互信任，在没有任何密码验证的环境中提供准确的呼叫方发起信息。在某些情况下，国家电信条例将这些义务编成法典。只要实体数量相对较少、易于识别（例如，以美国承运人的认证方式），并且在不当行为发生时受到有效的法律制裁，这种模式就有效。然而，一段时间以来，这些假设不再成立。例如，非传统电信运营商的实体（可能位于其使用国家代码的国家之外）可以充当语音服务提供商。虽然过去客户和服务提供商之间存在着明显的区别，但VoIP服务提供商现在可以轻松地充当客户或发起或传输提供商。此外，这一问题不仅限于语音通信，因为短信的增长使其成为依靠模拟源电话号码或短信短代码的大量未经请求的商业信息的另一个载体。在电话方面，来电显示欺骗已经变得很普遍，一小部分实体要么忽视对其服务的滥用，要么自愿为欺诈和其他非法行为提供服务。
For example, recently, enterprises and public safety organizations have been subjected to telephony denial-of-service attacks [TDOS]. In this case, an individual claiming to represent a collections company for payday loans starts the extortion scheme with a phone call to an organization. Failing to get payment from an individual or organization, the criminal organization launches a barrage of phone calls with spoofed numbers, preventing the targeted organization from receiving legitimate phone calls. Other boiler-room organizations use number spoofing to place illegal "robocalls" (automated telemarketing; see, for example, the US Federal Communications Commission webpage on this topic [ROBOCALL-FCC]). Robocalls are a problem that has been recognized already by various regulators; for example, the US Federal Trade Commission (FTC) recently organized a robocall competition to solicit ideas for creating solutions that will block illegal robocalls [ROBOCALL-CHALLENGE]. Criminals may also use number spoofing to impersonate banks or bank customers to gain access to information or financial accounts.
例如，最近，企业和公共安全组织受到电话拒绝服务攻击[TDO]。在这种情况下，一个声称代表收款公司领取发薪日贷款的个人通过给一个组织打电话来启动勒索计划。犯罪组织未能从个人或组织处获得付款，就用伪造的号码拨打了大量电话，阻止目标组织接收合法电话。其他锅炉房组织使用数字欺骗来放置非法的“robocalls”（自动电话营销；例如，参见美国联邦通信委员会关于此主题的网页[ROBOCALL-FCC]）。Robocals是一个已经被各监管机构认识到的问题；例如，美国联邦贸易委员会（FTC）最近组织了一次机器人呼叫竞赛，征求创意，以创建阻止非法机器人呼叫的解决方案[robocall-CHALLENGE]。犯罪分子还可能利用数字欺骗来冒充银行或银行客户以获取信息或金融账户。
In general, number spoofing is used in two ways: impersonation and anonymization. For impersonation, the attacker pretends to be a specific individual. Impersonation can be used for pretexting, where the attacker obtains information about the individual impersonated and, for example, activates credit cards, or for harassment, e.g., causing utility services to be disconnected, take-out food to be delivered, or police to respond to a non-existing hostage situation ("swatting"; see [SWATTING]). Some voicemail systems can be set up so that they grant access to stored messages without a password, relying solely on the caller identity. As an example, in the News International phone-hacking scandal [NEWS-HACK], employees of the newspaper were accused of engaging in phone hacking by utilizing Caller ID spoofing to get access to voicemail. For numbers where the caller has suppressed textual caller identification, number spoofing can be used to retrieve this information, stored in the so-called Calling Name (CNAM) database. For anonymization, the caller does not necessarily care whether the number is in service or who it is assigned to and may switch rapidly and possibly randomly between numbers. Anonymization facilitates automated illegal telemarketing or telephony denial-of-service attacks, as described above, as it makes it difficult to identify perpetrators and craft policies to block them. It also makes tracing such calls much more labor-intensive, as each call has to be identified in each transit carrier hop-by-hop, based on destination number and time of call.
通常，数字欺骗有两种使用方式：模拟和匿名。对于模拟，攻击者假装是特定的个人。假冒可用于伪装，攻击者获取有关被假冒个人的信息，例如激活信用卡，或用于骚扰，例如导致公用事业服务中断、外卖食物或警察对不存在的人质情况做出反应（“打击”；参见[打击]）。一些语音邮件系统可以设置为不需要密码就可以访问存储的消息，这完全取决于呼叫者身份。例如，在新闻国际电话窃听丑闻（News-HACK）中，该报社的员工被指控利用来电显示欺骗获取语音邮件，进行电话窃听。对于呼叫方已禁止文本呼叫方识别的号码，可以使用号码欺骗来检索存储在所谓的呼叫名称（CNAM）数据库中的此信息。对于匿名化，呼叫者不一定关心号码是否在服务中或被分配给谁，并且可能在号码之间快速且可能随机地切换。如上所述，匿名化有助于自动非法电话营销或电话拒绝服务攻击，因为它使得很难识别犯罪者并制定政策阻止他们。它还使得追踪此类呼叫更加费力，因为每个呼叫都必须根据目的地号码和呼叫时间在每个中转运营商中逐跳识别。
It is insufficient to simply outlaw all spoofing of originating telephone numbers because the entities spoofing numbers are already committing other crimes and are thus unlikely to be deterred by legal sanctions. Secure origin identification should prevent impersonation and, to a lesser extent, anonymization. However, if numbers are easy and cheap to obtain, and if the organizations assigning identifiers cannot or will not establish the true corporate or individual identity of the entity requesting such identifiers, robocallers will still be able to switch between many different identities.
仅仅取缔所有伪造原始电话号码的行为是不够的，因为伪造电话号码的实体已经在犯下其他罪行，因此不太可能受到法律制裁的威慑。安全的来源识别应防止冒充，并在较小程度上防止匿名化。然而，如果数字容易获得且价格低廉，并且如果分配标识符的组织无法或不会确定请求此类标识符的实体的真实公司或个人身份，则机器人呼叫器仍将能够在许多不同的身份之间切换。
The problem space is further complicated by a number of use cases where entities in the telephone network legitimately send calls on behalf of others, including "Find-Me/Follow-Me" services. Ultimately, any SIP entity can receive an INVITE request and forward it to any other entity, and the recipient of a forwarded message has little means to ascertain which recipient a call should legitimately target (see [SIP-SECURITY]). Also, in some cases, third parties may
电话网络中的实体代表其他人合法地发送电话，包括“查找我/跟踪我”服务的许多用例使问题空间更加复杂。最终，任何SIP实体都可以接收INVITE请求并将其转发给任何其他实体，而转发消息的接收者几乎没有办法确定呼叫应该合法指向哪个接收者（请参见[SIP-SECURITY]）。此外，在某些情况下，第三方可能
need to temporarily use the identity of another individual or organization with full consent of the "owner" of the identifier. For example:
需要临时使用另一个人或组织的身份，并获得该身份标识“所有人”的完全同意。例如：
Doctors' offices: Physicians calling their patients using their cell phones would like to replace their mobile phone number with the number of their office to avoid being called back by patients on their personal phone.
医生办公室：医生用手机给病人打电话时，希望用办公室号码替换手机号码，以避免病人用个人电话回电话。
Call centers: Call centers operate on behalf of companies, and the called party expects to see the Caller ID of the company, not the call center.
呼叫中心：呼叫中心代表公司运营，被叫方希望看到公司的来电显示，而不是呼叫中心。
The following terms are defined in this document:
本文件中定义了以下术语：
In-band Identity Conveyance: In-band conveyance is the presence of call origin identification information conveyed within the control plane protocol(s) setting up a call. Any in-band solution must accommodate in-band intermediaries such as Back-to-Back User Agents (B2BUAs).
带内标识传输：带内传输是指在建立呼叫的控制平面协议内传输的呼叫源标识信息的存在。任何带内解决方案都必须适应带内中介，如背靠背用户代理（B2BUA）。
Out-of-Band Identity Verification: Out-of-band verification determines whether the telephone number used by the calling party actually exists, whether the calling entity is entitled to use the number, and whether a call has recently been made from this phone number. This approach is needed because the in-band technique does not work in all cases, as when certain intermediaries are involved or due to interworking with circuit-switched networks.
带外身份验证：带外验证确定呼叫方使用的电话号码是否实际存在，呼叫实体是否有权使用该号码，以及最近是否使用该电话号码进行了呼叫。之所以需要这种方法，是因为带内技术并非在所有情况下都有效，例如涉及某些中介体或由于与电路交换网络互通。
Authority Delegation Infrastructure: The delegation authority infrastructure determines how the authority over telephone numbers is used when numbers are ported and delegated. It also describes how the existing numbering infrastructure is reused to maintain the lifecycle of number assignments.
权限委派基础结构：委派权限基础结构确定在移植和委派电话号码时如何使用电话号码的权限。它还描述了如何重用现有的编号基础结构来维护编号分配的生命周期。
Canonical Telephone Number: In order for either in-band conveyance or out-of-band verification to work, entities must be able to canonicalize telephone numbers to arrive at a common syntactical form.
规范化电话号码：为了使带内传输或带外验证能够工作，实体必须能够规范化电话号码，以获得通用的语法形式。
In order to explain the requirements and other design assumptions, we will explain some of the scenarios that need to be supported by any solution. To reduce clutter, the figures do not show call-routing
为了解释需求和其他设计假设，我们将解释任何解决方案都需要支持的一些场景。为了减少混乱，图中没有显示呼叫路由
elements such as SIP proxies of voice or text service providers. We generally assume that the PSTN component of any call path cannot be altered.
元素，例如语音或文本服务提供商的SIP代理。我们通常假设任何呼叫路径的PSTN组件都无法更改。
For the VoIP-to-VoIP communication case, a group of service providers that offer interconnected VoIP service exchange calls using SIP end-to-end but may also deliver some calls via circuit-switched facilities, as described in separate use cases below. These service providers use telephone numbers as source and destination identifiers, either as the user component of a SIP URI (e.g., sip:12125551234@example.com) or as a tel URI [RFC3966].
对于VoIP到VoIP通信案例，一组服务提供商使用SIP端到端提供互连的VoIP服务交换呼叫，但也可以通过电路交换设施发送一些呼叫，如下面单独的用例中所述。这些服务提供商使用电话号码作为源和目标标识符，或者作为SIP URI的用户组件（例如，SIP：12125551234@example.com)或作为电话URI[RFC3966]。
As illustrated in Figure 1, if Alice calls Bob, the call will use SIP end-to-end. (The call may or may not traverse the Internet.)
如图1所示，如果Alice调用Bob，则调用将使用SIP端到端。（电话可能会也可能不会穿越互联网。）
+------------+
| IP-based |
| SIP Phone |<--+
| of Bob | |
|+19175551234| |
+------------+ |
|
+------------+ |
| IP-based | |
| SIP Phone | ------------
| of Alice | / | \
|+12121234567| // | \\
+------------+ // ,' \\\
| /// / -----
| //// ,' \\\\
| / ,' \
| | ,' |
+---->|......: IP-based |
| Network |
\ /
\\\\ ////
-------------------------
+------------+
| IP-based |
| SIP Phone |<--+
| of Bob | |
|+19175551234| |
+------------+ |
|
+------------+ |
| IP-based | |
| SIP Phone | ------------
| of Alice | / | \
|+12121234567| // | \\
+------------+ // ,' \\\
| /// / -----
| //// ,' \\\\
| / ,' \
| | ,' |
+---->|......: IP-based |
| Network |
\ /
\\\\ ////
-------------------------
Figure 1: VoIP-to-VoIP Call
图1:VoIP到VoIP呼叫
Frequently, two VoIP-based service providers are not directly connected by VoIP and use Time Division Multiplexer (TDM) circuits to exchange calls, leading to the IP-PSTN-IP use case. In this use case, Dan's Voice Service Provider (VSP) is not a member of the
通常，两个基于VoIP的服务提供商不直接通过VoIP连接，而是使用时分多路复用器（TDM）电路交换呼叫，从而导致IP-PSTN-IP用例。在这个用例中，Dan的语音服务提供商（VSP）不是
interconnect federation Alice's and Bob's VSP belongs to. As far as Alice is concerned, Dan is not accessible via IP, and the PSTN is used as an interconnection network. Figure 2 shows the resulting exchange.
Alice和Bob的VSP所属的互连联盟。就Alice而言，Dan无法通过IP访问，PSTN被用作互连网络。图2显示了结果交换。
--------
//// \\\\
+--- >| PSTN |
| | |
| \\\\ ////
| --------
| |
| |
| |
+------------+ +--+----+ |
| IP-based | | PSTN | |
| SIP Phone | --+ VoIP +- v
| of Alice | / | GW | \ +---+---+
|+12121234567| // `''''''' \\| PSTN |
+------------+ // | \+ VoIP +
| /// | | GW |\
| //// | `'''''''\\ +------------+
| / | | \ | IP-based |
| | | | | | Phone |
+---->|---------------+ +------|---->| of Dan |
| | |+12039994321|
\ IP-based / +------------+
\\\\ Network ////
-------------------------
--------
//// \\\\
+--- >| PSTN |
| | |
| \\\\ ////
| --------
| |
| |
| |
+------------+ +--+----+ |
| IP-based | | PSTN | |
| SIP Phone | --+ VoIP +- v
| of Alice | / | GW | \ +---+---+
|+12121234567| // `''''''' \\| PSTN |
+------------+ // | \+ VoIP +
| /// | | GW |\
| //// | `'''''''\\ +------------+
| / | | \ | IP-based |
| | | | | | Phone |
+---->|---------------+ +------|---->| of Dan |
| | |+12039994321|
\ IP-based / +------------+
\\\\ Network ////
-------------------------
Figure 2: IP-PSTN-IP Call
图2:IP-PSTN-IP呼叫
Note: A B2BUA/Session Border Controller (SBC) exhibits behavior that looks similar to this scenario since the original call content would, in the worst case, be re-created on the call origination side.
注：B2BUA/会话边界控制器（SBC）表现出与此场景类似的行为，因为在最坏的情况下，原始呼叫内容将在呼叫发起端重新创建。
Consider Figure 3, where Carl is using a PSTN phone and initiates a call to Alice. Alice is using a VoIP-based phone. The call from Carl traverses the PSTN and enters the Internet via a PSTN/VoIP gateway. This gateway attaches some identity information to the call, for example, based on the caller identification information it had received through the PSTN, if available.
请考虑图3，其中卡尔使用PSTN电话，并启动对爱丽丝的呼叫。Alice正在使用基于VoIP的电话。来自Carl的呼叫通过PSTN并通过PSTN/VoIP网关进入互联网。此网关将一些身份信息附加到呼叫，例如，基于它通过PSTN接收到的呼叫者身份信息（如果可用）。
--------
//// \\\\
+->| PSTN |--+
| | | |
| \\\\ //// |
| -------- |
| |
| v
| +----+-------+
+---+------+ |PSTN / VoIP | +-----+
|PSTN Phone| |Gateway | |SIP |
|of Carl | +----+-------+ |UA |
+----------+ | |Alice|
INVITE +-----+
| ^
V |
+---------------+ INVITE
|VoIP | |
|Interconnection| INVITE +-------+
|Provider(s) |----------->+ |
+---------------+ |Alice's|
|VSP |
| |
+-------+
--------
//// \\\\
+->| PSTN |--+
| | | |
| \\\\ //// |
| -------- |
| |
| v
| +----+-------+
+---+------+ |PSTN / VoIP | +-----+
|PSTN Phone| |Gateway | |SIP |
|of Carl | +----+-------+ |UA |
+----------+ | |Alice|
INVITE +-----+
| ^
V |
+---------------+ INVITE
|VoIP | |
|Interconnection| INVITE +-------+
|Provider(s) |----------->+ |
+---------------+ |Alice's|
|VSP |
| |
+-------+
Figure 3: PSTN-to-VoIP Call
图3:PSTN到VoIP呼叫
Consider Figure 4, where Alice calls Carl. Carl uses a PSTN phone, and Alice uses an IP-based phone. When Alice initiates the call, the E.164 number is translated to a SIP URI and subsequently to an IP address. The call of Alice traverses her VoIP provider, where the call origin identification information is added. It then hits the PSTN/VoIP gateway. It is desirable that the gateway verify that Alice can claim the E.164 number she is using before it populates the corresponding calling party number field in telephone network signaling. Carl's phone must be able to verify that it is receiving a legitimate call from the calling party number it will render to Carl.
请考虑图4，爱丽丝称之为卡尔。Carl使用PSTN电话，Alice使用基于IP的电话。当Alice发起呼叫时，E.164号码被转换为SIPURI，随后转换为IP地址。Alice的呼叫通过她的VoIP提供商，其中添加了呼叫来源标识信息。然后点击PSTN/VoIP网关。网关在填充电话网络信令中相应的主叫方号码字段之前，最好验证Alice可以声明她正在使用的E.164号码。Carl的手机必须能够验证它正在接收来自其将提供给Carl的主叫方号码的合法呼叫。
+-------+ +-----+ -C
|PSTN | |SIP | |a
|Phone |<----------------+ |UA | |l
|of Carl| | |Alice| |l
+-------+ | +-----+ |i
--------------------------- | |n
//// \\\\ | |g
| PSTN | INVITE |
| | | |P
\\\\ //// | |a
--------------------------- | |r
^ | |t
| v |y
+------------+ +--------+|
|PSTN / VoIP |<--INVITE----|VoIP ||D
|Gateway | |Service ||o
+------------+ |Provider||m
|of Alice||a
+--------+|i
-n
+-------+ +-----+ -C
|PSTN | |SIP | |a
|Phone |<----------------+ |UA | |l
|of Carl| | |Alice| |l
+-------+ | +-----+ |i
--------------------------- | |n
//// \\\\ | |g
| PSTN | INVITE |
| | | |P
\\\\ //// | |a
--------------------------- | |r
^ | |t
| v |y
+------------+ +--------+|
|PSTN / VoIP |<--INVITE----|VoIP ||D
|Gateway | |Service ||o
+------------+ |Provider||m
|of Alice||a
+--------+|i
-n
Figure 4: VoIP-to-PSTN Call
图4:VoIP到PSTN呼叫
Consider Figure 5, where Carl calls Alice. Both users have PSTN phones, but interconnection between the two circuit-switched parts of the PSTN is accomplished via an IP network. Consequently, Carl's operator uses a PSTN-to-VoIP gateway to route the call via an IP network to a gateway to break out into the PSTN again.
请考虑图5，卡尔称之为爱丽丝。两个用户都有PSTN电话，但PSTN的两个电路交换部分之间的互连是通过IP网络实现的。因此，Carl的运营商使用PSTN到VoIP网关，通过IP网络将呼叫路由到网关，再次进入PSTN。
+----------+
|PSTN Phone|
-------- |of Alice |
//// \\\\ +----------+
+->| PSTN |------+ ^
| | | | |
| \\\\ //// | |
| -------- | --------
| v //// \\\\
| ,-------+ | PSTN |
| |PSTN | | |
+---+------+ __|VoIP GW|_ \\\\ ////
|PSTN Phone| / '`''''''' \ --------
|of Carl | // | \\ ^
+----------+ // | \\\ |
/// -. INVITE ----- |
//// `-. \\\\ |
/ `.. \ |
| IP-based `._ ,--+----+
| Network `.....>|VoIP |
| |PSTN GW|
\ '`'''''''
\\\\ ////
-------------------------
+----------+
|PSTN Phone|
-------- |of Alice |
//// \\\\ +----------+
+->| PSTN |------+ ^
| | | | |
| \\\\ //// | |
| -------- | --------
| v //// \\\\
| ,-------+ | PSTN |
| |PSTN | | |
+---+------+ __|VoIP GW|_ \\\\ ////
|PSTN Phone| / '`''''''' \ --------
|of Carl | // | \\ ^
+----------+ // | \\\ |
/// -. INVITE ----- |
//// `-. \\\\ |
/ `.. \ |
| IP-based `._ ,--+----+
| Network `.....>|VoIP |
| |PSTN GW|
\ '`'''''''
\\\\ ////
-------------------------
Figure 5: PSTN-VoIP-PSTN Call
图5:PSTN VoIP PSTN呼叫
For the "legacy" case of a PSTN-to-PSTN call, otherwise beyond improvement, we may be able to use out-of-band IP connectivity at both the originating and terminating carrier to validate the call information.
对于PSTN到PSTN呼叫的“传统”情况，除了改进之外，我们可能能够在发起和终止运营商使用带外IP连接来验证呼叫信息。
From the inception of SIP, the From header field value has held an arbitrary user-supplied identity, much like the From header field value of an SMTP email message. During work on [RFC3261], efforts began to provide a secure origin for SIP requests as an extension to SIP. The so-called "short term" solution, the P-Asserted-Identity header described in [RFC3325], is deployed fairly widely, even though it is limited to closed trusted networks where end-user devices cannot alter or inspect SIP messages and offers no cryptographic validation. As P-Asserted-Identity is used increasingly across multiple networks, it cannot offer any protection against identity spoofing by intermediaries or entities that allow untrusted entities
从SIP开始，From header字段值就持有用户提供的任意标识，这与SMTP电子邮件的From header字段值非常相似。在[RFC3261]的工作中，人们开始努力为SIP请求提供一个安全的来源，作为SIP的扩展。所谓的“短期”解决方案，[RFC3325]中描述的P-Asserted-Identity报头被广泛部署，即使它仅限于封闭的可信网络，其中终端用户设备无法更改或检查SIP消息，并且不提供加密验证。随着P-Asserted-Identity在多个网络中的使用越来越多，它无法提供任何保护，以防止允许不受信任实体的中介或实体进行身份欺骗
to set the P-Asserted-Identity information. An overview of addressing spam in SIP and an explanation of how it differs from similar problems with email appeared in [RFC5039].
设置P-Asserted-Identity信息。[RFC5039]中概述了SIP中处理垃圾邮件的方法，并解释了它与电子邮件中类似问题的区别。
Subsequent efforts to prevent calling-origin identity spoofing in SIP include the SIP Identity effort (the "long-term" identity solution) [RFC4474] and Verification Involving PSTN Reachability (VIPR) [VIPR-OVERVIEW]. SIP Identity attaches a new header field to SIP requests containing a signature over the From header field value combined with other message components to prevent replay attacks. SIP Identity is meant to prevent both (a) SIP UAs from originating calls with spoofed From headers and (b) intermediaries, such as SIP proxies, from launching man-in-the-middle attacks by altering calls as they pass through the intermediaries. The VIPR architecture attacked a broader range of problems relating to spam, routing, and identity with a new infrastructure for managing rendezvous and security, which operated alongside of SIP deployments.
在SIP中防止呼叫源身份欺骗的后续工作包括SIP身份工作（“长期”身份解决方案）[RFC4474]和涉及PSTN可达性（VIPR）的验证[VIPR-OVERVIEW]。SIP Identity将一个新的头字段附加到SIP请求，该请求包含来自头字段值的签名，并与其他消息组件相结合，以防止重播攻击。SIP标识旨在防止（a）SIP UAs使用来自报头的欺骗发起呼叫，以及（b）中间人（如SIP代理）通过改变通过中间人的呼叫来发起中间人攻击。VIPR体系结构通过一个新的用于管理集合和安全的基础设施（与SIP部署一起运行），解决了与垃圾邮件、路由和身份相关的更广泛的问题。
As we will describe in more detail below, both SIP Identity and VIPR suffer from serious limitations that have prevented their deployment on a significant scale, but they may still offer ideas and protocol building blocks for a solution.
正如我们将在下面更详细地描述的，SIP Identity和VIPR都受到严重的限制，这些限制阻碍了它们的大规模部署，但它们仍然可以为解决方案提供想法和协议构建块。
The P-Asserted-Identity header field of SIP [RFC3325] provides a way for trusted network entities to share with one another an authoritative identifier for the originator of a call. The value of P-Asserted-Identity cannot be populated by a user, though if a user wants to suggest an identity to the trusted network, a separate header (P-Preferred-Identity) enables them to do so. The features of the P-Asserted-Identity header evolved as part of a broader effort to reach parity with traditional telephone network signaling mechanisms for selectively sharing and restricting presentation of the calling party number at the user level while still allowing core network elements to know the identity of the user for abuse prevention and accounting.
SIP[RFC3325]的P-Asserted-Identity报头字段为可信网络实体彼此共享呼叫发起人的权威标识符提供了一种方式。P-Asserted-Identity的值不能由用户填充，但如果用户希望向受信任网络建议标识，则可以使用单独的头（P-Preferred-Identity）来执行此操作。P-Asserted-Identity报头的特征是作为与传统电话网络信令机制实现奇偶性的更广泛努力的一部分而发展的，传统电话网络信令机制用于在用户级别选择性地共享和限制主叫方号码的呈现，同时仍然允许核心网络元件知道用户的身份以供滥用预防和核算。
In order for P-Asserted-Identity to have these properties, it requires the existence of a trust domain as described in [RFC3324]. Any entity in the trust domain may add a P-Asserted-Identity header to a SIP message, and any entity in the trust domain may forward a message with a P-Asserted-Identity header to any other entity in the trust domain. If a trusted entity forwards a SIP request to an untrusted entity, however, the P-Asserted-Identity header must first be removed; most end-user devices are outside trust domains. Sending a P-Asserted-Identity request to an untrusted entity could leak potentially private information, such as the network-asserted calling
为了使P-Asserted-Identity具有这些属性，它需要存在[RFC3324]中描述的信任域。信任域中的任何实体可以向SIP消息添加P-Asserted-Identity报头，并且信任域中的任何实体可以向信任域中的任何其他实体转发具有P-Asserted-Identity报头的消息。但是，如果受信任的实体将SIP请求转发给不受信任的实体，则必须首先删除P-Asserted-Identity报头；大多数最终用户设备位于信任域之外。向不受信任的实体发送P-Asserted-Identity请求可能会泄漏潜在的私有信息，例如网络断言呼叫
party number in a case where a caller has requested presentation restriction. This concept of a trust domain is modeled on the trusted network of devices that operate the traditional telephone network.
主叫方请求演示限制时的参与方编号。信任域的概念是以操作传统电话网络的设备的受信任网络为模型的。
P-Asserted-Identity has been very successful in telephone replacement deployments of SIP. It is an extremely simple in-band mechanism, requiring no cryptographic operations. Since it is so reminiscent of legacy mechanisms in the traditional telephone network and interworks so seamlessly with those protocols, it has naturally been favored by providers comfortable with these operating principles.
P-Asserted-Identity在SIP的电话替换部署中非常成功。它是一种非常简单的带内机制，不需要加密操作。由于它让人想起传统电话网络中的遗留机制，并且与这些协议无缝地交互，因此它自然受到熟悉这些操作原则的提供商的青睐。
In practice, a trust domain exhibits many of the same merits and flaws as the traditional telephone network when it comes to securing a calling party number. Any trusted entity may provide P-Asserted-Identity, and a recipient of a SIP message has no direct assurance of who generated the P-Asserted-Identity header field value: all trust is transitive. Trust domains are dictated by business arrangements more than by security standards; thus, the level of assurance of P-Asserted-Identity is only as good as the least trustworthy member of a trust domain. Since the contents of P-Asserted-Identity are not intended for consumption by end users, end users must trust that their service provider participates in an appropriate trust domain, as there will be no direct evidence of the trust domain in the SIP signaling that end-user devices receive. Since the mechanism is so closely modeled on the traditional telephone network, it is unlikely to provide a higher level of security than that.
实际上，在保护呼叫方号码方面，信任域与传统电话网络具有许多相同的优点和缺点。任何受信任的实体都可以提供P-Asserted-Identity，SIP消息的接收者不能直接保证是谁生成了P-Asserted-Identity头字段值：所有信任都是可传递的。信任域更多地由业务安排而非安全标准决定；因此，P-Asserted-Identity的保证级别仅与信任域中最不可信的成员相同。由于P-Asserted-Identity的内容不是供最终用户使用的，因此最终用户必须相信其服务提供商参与了适当的信任域，因为在最终用户设备接收的SIP信令中不会有信任域的直接证据。由于该机制与传统电话网络非常接近，因此不可能提供比这更高级别的安全性。
Since [RFC3325] was written, the whole notion of "P-" headers intended for use in private SIP domains has also been deprecated (see [RFC5727]) largely because of overwhelming evidence that these headers were being used outside of private contexts and leaking into the public Internet. It is unclear how many deployments that make use of P-Asserted-Identity in fact conform to the Spec(T) requirements of [RFC3324].
自[RFC3325]被编写以来，用于私有SIP域的“P-”报头的整个概念也遭到了反对（参见[RFC5727]），这主要是因为大量证据表明这些报头在私有上下文之外使用，并泄漏到公共互联网中。目前尚不清楚有多少使用P-Asserted-Identity的部署实际上符合[RFC3324]的规范（T）要求。
P-Asserted-Identity also complicates the question of which URI should be presented to a user when a call is received. Per [RFC3261], SIP user agents would render the contents of the From header field to a user when receiving an INVITE request, but what if the P-Asserted-Identity contains a more trustworthy URI, and presentation is not restricted? Subsequent proposals have suggested additional header fields to carry different forms of identity related to the caller, including billing identities. As the calling identities in a SIP request proliferate, the question of how to select one to render to the end user becomes more difficult to answer.
P-Asserted-Identity还使在接收到呼叫时应该向用户显示哪个URI的问题变得复杂。根据[RFC3261]，SIP用户代理在接收到INVITE请求时会将From头字段的内容呈现给用户，但如果P-ASSECTED-Identity包含更可靠的URI，并且呈现不受限制，该怎么办？随后的提案建议增加标题字段，以携带与呼叫者相关的不同形式的身份，包括计费身份。随着SIP请求中呼叫身份的激增，如何选择一个向最终用户呈现的问题变得更加难以回答。
The SIP Identity mechanism [RFC4474] provides two header fields for securing identity information in SIP requests: the Identity and Identity-Info header fields. Architecturally, the SIP Identity mechanism assumes a classic "SIP trapezoid" deployment in which an authentication service, acting on behalf of the originator of a SIP request, attaches identity information to the request that provides partial integrity protection; a verification service acting on behalf of the recipient validates the integrity of the request when it is received.
SIP标识机制[RFC4474]为保护SIP请求中的标识信息提供了两个头字段：标识和标识信息头字段。在体系结构上，SIP身份机制假设经典的“SIP梯形”部署，其中代表SIP请求的发起人的认证服务将身份信息附加到提供部分完整性保护的请求；代表接收者的验证服务在收到请求时验证其完整性。
The Identity header field value contains a signature over a hash of selected elements of a SIP request, including several header field values (most significantly, the From header field value) and the entirety of the body of the request. The set of header field values was chosen specifically to prevent cut-and-paste attacks; it requires the verification service to retain some state to guard against replays. The signature over the body of a request has different properties for different SIP methods, but all prevent tampering by man-in-the-middle attacks. For a SIP MESSAGE request, for example, the signature over the body covers the actual message conveyed by the request: it is pointless to guarantee the source of a request if a man in the middle can change the content of the message, as in that case the message content is created by an attacker. Similar threats exist against the SIP NOTIFY method. For a SIP INVITE request, a signature over the Session Description Protocol (SDP) body is intended to prevent a man in the middle from changing properties of the media stream, including the IP address and port to which media should be sent, as this provides a means for the man in the middle to direct session media to a resource that the originator did not specify and thus impersonate an intended listener.
标识头字段值包含SIP请求所选元素散列上的签名，包括几个头字段值（最重要的是，From头字段值）和整个请求体。选择标题字段值集是为了防止剪切和粘贴攻击；它要求验证服务保留一些状态以防止重播。对于不同的SIP方法，请求体上的签名具有不同的属性，但都可以防止中间人攻击的篡改。例如，对于SIP消息请求，主体上的签名覆盖了请求传递的实际消息：如果中间的人可以改变消息的内容，则保证请求的源是毫无意义的，因为在这种情况下，消息内容是由攻击者创建的。SIP NOTIFY方法也存在类似的威胁。对于SIP邀请请求，会话描述协议（SDP）主体上的签名旨在防止中间人改变媒体流的属性，包括要发送媒体的IP地址和端口，因为这为中间人提供了一种手段来将会话媒体引导到始发者未指定的资源，从而模拟预期的监听器。
The Identity-Info header field value contains a URI designating the location of the certificate corresponding to the private key that signed the hash in the Identity header. That certificate could be passed by-value along with the SIP request, in which case a cid URI appears in Identity-Info, or by-reference, for example, when the Identity-Info header field value has the URL of a service that delivers the certificate. [RFC4474] imposes further constraints governing the subject of that certificate, namely, that it must cover the domain name indicated in the domain component of the URI in the From header field value of the request.
Identity Info header字段值包含一个URI，指定与在Identity header中签名哈希的私钥相对应的证书的位置。该证书可以通过值与SIP请求一起传递，在这种情况下，cid URI出现在Identity Info中，或者通过引用传递，例如，当Identity Info头字段值具有传递证书的服务的URL时。[RFC4474]对该证书的主题施加了进一步的约束，即它必须覆盖请求的From头字段值中URI的域组件中指示的域名。
The SIP Identity mechanism, however, has two fundamental limitations that have precluded its deployment: first, it provides identity only for domain names rather than other identifiers, and second, it does not tolerate intermediaries that alter the bodies, or certain header fields, of SIP requests.
然而，SIP标识机制有两个基本限制，妨碍了它的部署：第一，它只为域名而不是其他标识符提供标识；第二，它不允许中介更改SIP请求的主体或某些头字段。
As deployed, SIP predominantly mimics the structures of the telephone network and thus uses telephone numbers as identifiers. Telephone numbers in the From header field value of a SIP request may appear as the user part of a SIP URI or, alternatively, in an independent tel URI. The certificate designated by the Identity-Info header field as specified, however, corresponds only to the domain portion of a SIP URI in the From header field. As such, [RFC4474] does not have any provision to identify the assignee of a telephone number. While it could be the case that the domain name portion of a SIP URI signifies a carrier (like "att.com") to whom numbers are assigned, the SIP Identity mechanism provides no assurance that a particular number has been assigned to any specific carrier. For a tel URI, moreover, it is unclear in [RFC4474] what entity should hold a corresponding certificate. A caller may not want to reveal the identity of its service provider to the callee and may thus prefer tel URIs in the From header field.
部署时，SIP主要模仿电话网络的结构，因此使用电话号码作为标识符。SIP请求的From报头字段值中的电话号码可以显示为SIP URI的用户部分，或者，在独立的tel URI中。但是，由指定的Identity Info标头字段指定的证书仅对应于From标头字段中SIP URI的域部分。因此，[RFC4474]没有识别电话号码受让人的任何规定。虽然可能是SIP URI的域名部分表示向其分配号码的运营商（如“att.com”），但SIP标识机制不能保证特定号码已分配给任何特定运营商。此外，对于tel URI，[RFC4474]中不清楚哪个实体应该持有相应的证书。调用者可能不想向被调用者透露其服务提供者的身份，因此可能更喜欢From头字段中的tel URI。
This lack of authority gives rise to a whole class of SIP Identity problems when dealing with telephone numbers, as is explored in [CONCERNS]. That document shows how the Identity header of a SIP request targeting a telephone number (embedded in a SIP URI) could be dropped by an intermediate domain, which then modifies and re-signs the request, all without alerting the verification service: the verification service has no way of knowing which original domain signed the request. Provided that the local authentication service is complicit, an originator can claim virtually any telephone number, impersonating any chosen Caller ID from the perspective of the verifier. Both of these attacks are rooted in the inability of the verification service to ascertain a specific certificate that is authoritative for a telephone number.
在处理电话号码时，这种缺乏权威性会导致一系列SIP身份问题，如[关注点]中所述。该文档显示了中间域如何删除以电话号码（嵌入SIP URI中）为目标的SIP请求的标识头，然后中间域修改并重新签名该请求，而无需通知验证服务：验证服务无法知道哪个原始域签署了该请求。如果本地身份验证服务是共谋者，发起者可以声称几乎任何电话号码，从验证者的角度模拟任何选择的呼叫者ID。这两种攻击的根源都在于验证服务无法确定对电话号码具有权威性的特定证书。
Moreover, as deployed, SIP is highly mediated and is mediated in ways that [RFC3261] did not anticipate. As request routing commonly depends on policies dissimilar to [RFC3263], requests transit multiple intermediate domains to reach a destination; some forms of intermediaries in those domains may effectively reinitiate the session.
此外，在部署时，SIP是高度中介的，并且以[RFC3261]没有预料到的方式进行中介。由于请求路由通常依赖于与[RFC3263]不同的策略，请求通过多个中间域到达目的地；这些域中的某些形式的中介可以有效地重新初始化会话。
One of the main reasons that SIP deployments mimic the PSTN architecture is because the requirement for interconnection with the PSTN remains paramount: a call may originate in SIP and terminate on the PSTN, or vice versa. Worse still, a PSTN-to-PSTN call may
SIP部署模仿PSTN体系结构的主要原因之一是，与PSTN互连的要求仍然是最重要的：呼叫可以在SIP中发起并在PSTN上终止，反之亦然。更糟糕的是，PSTN对PSTN呼叫可能
transit a SIP network in the middle, or vice versa. This necessarily reduces SIP's feature set to the least common denominator of the telephone network and mandates support for telephone numbers as a primary calling identifier.
在中间传输SIP网络，反之亦然。这必然会将SIP的功能集减少到电话网络的最小公分母，并强制支持电话号码作为主要呼叫标识符。
Interworking with non-SIP networks makes end-to-end identity problematic. When a PSTN gateway sends a call to a SIP network, it creates the INVITE request anew, regardless of whether a previous leg of the call originated in a SIP network that later delivered the call to the PSTN. As these gateways are not necessarily operated by entities that have any relationship to the number assignee, it is unclear how they could provide an identity signature that a verifier should trust. Moreover, how could the gateway know that the calling party number it receives from the PSTN is actually authentic? And when a gateway receives a call via SIP and terminates a call to the PSTN, how can that gateway verify that a telephone number in the From header field value is authentic before it presents that number as the calling party number in the PSTN?
与非SIP网络的互通导致端到端身份问题。当PSTN网关向SIP网络发送呼叫时，它会重新创建INVITE请求，而不管呼叫的前一段是否起源于后来将呼叫发送到PSTN的SIP网络。由于这些网关不一定由与号码受让人有任何关系的实体操作，因此不清楚它们如何提供验证者应该信任的身份签名。此外，网关如何知道它从PSTN接收的主叫方号码实际上是真实的？当网关通过SIP接收呼叫并终止对PSTN的呼叫时，该网关如何验证From报头字段值中的电话号码是否真实，然后再将该号码显示为PSTN中的主叫方号码？
Similarly, some SIP networks deploy intermediaries that act as back-to-back user agents (B2BUAs), typically in order to provide policy or interworking functions at network boundaries (hence, the nickname "Session Border Controller"). These functions range from topology hiding, to alterations necessary to interoperate successfully with particular SIP implementations, to simple network address translation from private address space. To implement these functions, these entities modify SIP INVITE requests in transit, potentially changing the From, Contact, and Call-ID header field values, as well as aspects of the SDP, including especially the IP addresses and ports associated with media. Consequently, a SIP request exiting a B2BUA does not necessarily bear much resemblance to the original request received by the B2BUA, just as an SS7 request exiting a PSTN gateway may transform all aspects of the SIP request in the VoIP leg of the call. An Identity signature provided for the original INVITE has no bearing on the post-B2BUA INVITE, and, were the B2BUA to preserve the original Identity header, any verification service would detect a violation of the integrity protection.
类似地，一些SIP网络部署充当背靠背用户代理（B2BUA）的中介，通常是为了在网络边界提供策略或互通功能（因此，昵称为“会话边界控制器”）。这些功能包括拓扑隐藏、与特定SIP实现成功互操作所需的更改，以及从专用地址空间进行简单的网络地址转换。为了实现这些功能，这些实体在传输过程中修改SIP INVITE请求，可能会更改From、Contact和Call ID头字段值，以及SDP的各个方面，尤其包括与媒体相关的IP地址和端口。因此，退出B2BUA的SIP请求不一定与B2BUA接收到的原始请求非常相似，正如退出PSTN网关的SS7请求可以转换呼叫的VoIP分支中的SIP请求的所有方面。为原始INVITE提供的身份签名与B2BUA后的INVITE无关，并且，如果B2BUA保留原始身份头，任何验证服务都会检测到违反完整性保护的情况。
The SIP community has long been aware of these problems with [RFC4474] in practical deployments. Some have therefore proposed weakening the security constraints of [RFC4474] so that at least some deployments of B2BUAs will be compatible with integrity protection of SIP requests. However, such solutions do not address the key problems identified above: the lack of any clear authority for telephone numbers and the fact that some INVITE requests are generated by intermediaries rather than endpoints. Removing the
SIP社区早就意识到[RFC4474]在实际部署中存在这些问题。因此，一些人建议削弱[RFC4474]的安全约束，以便至少一些B2BUA部署与SIP请求的完整性保护兼容。然而，此类解决方案并没有解决上述关键问题：电话号码缺乏明确的权限，以及一些INVITE请求是由中介机构而不是端点生成的事实。移除
signature over the SDP from the Identity header will not, for example, make it any clearer how a PSTN gateway should assert identity in an INVITE request.
例如，来自标识头的SDP签名不会使PSTN网关如何在INVITE请求中声明标识变得更清晰。
Verification Involving PSTN Reachability (VIPR) directly attacks the twin problems of identifying number assignees on the Internet and coping with intermediaries that may modify signaling. To address the first problem, VIPR relies on the PSTN itself: it discovers which endpoints on the Internet are reachable via a particular PSTN number by calling the number on the PSTN to determine whom a call to that number will reach. As VIPR-enabled Internet endpoints associated with PSTN numbers are discovered, VIPR provides a rendezvous service that allows the endpoints of a call to form an out-of-band connection over the Internet; this connection allows the endpoints to exchange information that secures future communications and permits direct, unmediated SIP connections.
涉及PSTN可达性（VIPR）的验证直接解决了在互联网上识别号码受让人和处理可能修改信令的中介的双重问题。为了解决第一个问题，VIPR依赖于PSTN本身：它通过呼叫PSTN上的号码来确定对该号码的呼叫将到达谁，从而发现通过特定PSTN号码可以到达Internet上的哪些端点。当发现与PSTN号码相关联的支持VIPR的互联网端点时，VIPR提供会合服务，允许呼叫端点在互联网上形成带外连接；此连接允许端点交换确保未来通信安全的信息，并允许直接、非中介的SIP连接。
VIPR provides these services within a fairly narrow scope of applicability. Its seminal use case is the enterprise IP Private Branch Exchange (IPBX), a device that has both PSTN connectivity and Internet connectivity, which serves a set of local users with telephone numbers; after a PSTN call has connected successfully and then ended, the PBX searches a distributed hash table to see if any VIPR-compatible devices have advertised themselves as a route for the unfamiliar number on the Internet. If advertisements exist, the originating PBX then initiates a verification process to determine whether the entity claiming to be the assignee of the unfamiliar number in fact received the successful call: this involves verifying details such as the start and stop times of the call. If the destination verifies successfully, the originating PBX provisions a local database with a route for that telephone number to the URI provided by the proven destination. Moreover, the destination gives a token to the originator that can be inserted in future call setup messages to authenticate the source of future communications.
VIPR在相当狭窄的适用范围内提供这些服务。其开创性的使用案例是企业IP专用分支交换机（IPBX），这是一种既有PSTN连接又有互联网连接的设备，为一组本地用户提供电话号码；PSTN呼叫成功连接并结束后，PBX搜索分布式哈希表，查看是否有任何与VIPR兼容的设备在互联网上宣传自己为不熟悉号码的路由。如果存在广告，发起PBX随后启动验证过程，以确定声称是不熟悉号码的受让人的实体是否确实收到了成功呼叫：这涉及验证呼叫的开始和停止时间等详细信息。如果目的地验证成功，发起PBX将提供一个本地数据库，其中包含该电话号码到经验证的目的地提供的URI的路由。此外，目的地向发起者提供令牌，该令牌可插入未来呼叫建立消息中以认证未来通信的源。
Through this mechanism, the VIPR system provides a suite of properties, ones that go well beyond merely securing the origins of communications. It also provides a routing system that dynamically discovers mappings between telephone numbers and URIs, effectively building an ad hoc ENUM database in every VIPR implementation. The tokens exchanged over the out-of-band connection established by VIPR also provide an authorization mechanism for accepting calls over the Internet, which significantly reduces the potential for spam. Because the token can act as a cookie due to the presence of this
通过这种机制，VIPR系统提供了一套财产，这些财产远远超出了仅仅保护通信来源的范围。它还提供了一个路由系统，可以动态发现电话号码和URI之间的映射，从而在每个VIPR实现中有效地构建一个特别的ENUM数据库。通过VIPR建立的带外连接交换的令牌还提供了一种通过互联网接受呼叫的授权机制，这大大降低了垃圾邮件的可能性。因为令牌可以充当cookie，因为存在此
out-of-band connectivity, the VIPR token is less susceptible to cut-and-paste attacks and thus needs to cover far less of a SIP request with its signature.
带外连接，VIPR令牌不太容易受到剪切和粘贴攻击，因此需要用其签名覆盖的SIP请求要少得多。
Due to its narrow scope of applicability and the details of its implementation, VIPR has some significant limitations. The most salient for the purposes of this document is that it only has bearing on repeated communications between entities: it has no solution to the classic "robocall" problem, where the target typically receives a call from a number that has never called before. All of VIPR's strengths in establishing identity and spam prevention kick in only after an initial PSTN call has been completed and subsequent attempts at communication begin. Every VIPR-compliant entity, moreover, maintains its own stateful database of previous contacts and authorizations, which lends itself more to aggregators like IP PBXs that may front for thousands of users than to individual phones. That database must be refreshed by periodic PSTN calls to determine that control over the number has not shifted to some other entity; figuring out when data has grown stale is one of the challenges of the architecture. As VIPR requires compliant implementations to operate both a PSTN interface and an IP interface, it has little apparent applicability to ordinary desktop PCs or similar devices with no ability to place direct PSTN calls.
由于其适用范围狭窄以及实施细节，VIPR存在一些重大限制。本文件中最突出的一点是，它只与实体之间的重复通信有关：它无法解决经典的“机器人呼叫”问题，即目标通常从一个以前从未呼叫过的号码接收呼叫。VIPR在建立身份和防止垃圾邮件方面的所有优势只有在最初的PSTN呼叫完成并且随后的通信尝试开始后才能发挥作用。此外，每一个符合VIPR的实体都维护着自己的有状态数据库，该数据库包含了以前的联系人和授权信息，这使得它更适合像IP PBX这样的聚合器，这些聚合器可能面向数千用户，而不是单个电话。该数据库必须通过定期PSTN呼叫进行刷新，以确定对该号码的控制权没有转移到其他实体；找出数据何时过时是体系结构的挑战之一。由于VIPR需要兼容的实现来操作PSTN接口和IP接口，因此它对普通台式PC或无法直接拨打PSTN电话的类似设备几乎没有明显的适用性。
The distributed hash table (DHT) also creates a new attack surface for impersonation. Attackers who want to pose as the owners of telephone numbers can advertise themselves as routes to a number in the hash table. VIPR has no inherent restriction on the number of entities that may advertise themselves as routes for a number; thus, an originator may find multiple advertisements for a number on the DHT even when an attack is not in progress. Attackers may learn from these validation attempts which VIPR entities recently placed calls to the target number, even if they cannot impersonate the target since they lack the PSTN call detail information. It may be that this information is all the attacker hopes to glean. The fact that advertisements and verifications are public results from the public nature of the DHT that VIPR creates. The public DHT prevents any centralized control or attempts to impede communications, but those come at the cost of apparently unavoidable privacy losses.
分布式哈希表（DHT）还为模拟创建了一个新的攻击面。想要冒充电话号码所有者的攻击者可以将自己宣传为哈希表中某个号码的路由。VIPR对可能宣传自己为某个数量的路线的实体的数量没有固有的限制；因此，即使攻击未进行，发起人也可能在DHT上发现多个号码广告。攻击者可以通过这些验证尝试了解哪些VIPR实体最近拨打了目标号码的电话，即使他们无法模拟目标，因为他们缺少PSTN呼叫详细信息。这可能是攻击者希望收集的全部信息。事实上，广告和验证是公开的，这源于VIPR创建的DHT的公共性。公共DHT阻止任何集中控制或阻止通信的企图，但这些都是以显然不可避免的隐私损失为代价的。
Because of these limitations, VIPR, much like SIP Identity, has had little impact in the marketplace. Ultimately, VIPR's utility as an identity mechanism is limited by its reliance on the PSTN, especially its need for an initial PSTN call to complete before any of VIPR's benefits can be realized, and by the drawbacks of the highly public exchanges required to create the out-of-band connection between VIPR entities. As such, there is no obvious solution to providing secure origin services for SIP on the Internet today.
由于这些限制，VIPR与SIP Identity非常相似，在市场上几乎没有影响。最终，VIPR作为身份机制的效用受到其对PSTN的依赖性的限制，特别是在实现VIPR的任何好处之前需要完成初始PSTN呼叫，以及VIPR实体之间创建带外连接所需的高度公开交换的缺点。因此，目前还没有明显的解决方案可以在Internet上为SIP提供安全的源站服务。
In the years since [RFC4474] was conceived, there have been a number of fundamental shifts in the communications marketplace. The most transformative has been the precipitous rise of mobile smartphones, which are now arguably the dominant communications device in the developed world. Smart phones have both a PSTN and an IP interface, as well as SMS and Multimedia Messaging Service (MMS) capabilities. This suite of tools suggests that some of the techniques proposed by VIPR could be adapted to the smartphone environment. The installed base of smartphones is, moreover, highly upgradable and permits rapid adoption of out-of-band rendezvous services for smartphones that bypass the PSTN. Mobile messaging services that use telephone numbers as identities allow smartphone users to send text messages to one another over the Internet rather than over the PSTN. Like VIPR, such services create an out-of-band connection over the Internet between smartphones; unlike VIPR, the rendezvous service is provided by a trusted centralized database rather than by a DHT, and it is the centralized database that effectively verifies and asserts the telephone number of the sender of a message. While such messaging services are specific to the users of the specific service, it seems clear that similar databases could be provided by neutral third parties in a position to coordinate between endpoints.
自[RFC4474]提出以来的几年中，通信市场发生了许多根本性的变化。最具变革性的是移动智能手机的迅猛崛起，移动智能手机现在可以说是发达国家占主导地位的通信设备。智能手机具有PSTN和IP接口，以及SMS和彩信服务（MMS）功能。这套工具表明，VIPR提出的一些技术可以适应智能手机环境。此外，智能手机的安装基础是高度可升级的，并允许绕过PSTN的智能手机快速采用带外会合服务。使用电话号码作为身份的移动消息服务允许智能手机用户通过互联网而不是PSTN相互发送文本消息。与VIPR一样，此类服务在智能手机之间通过互联网建立带外连接；与VIPR不同，集合服务由可信的集中式数据库而不是DHT提供，集中式数据库有效地验证和断言消息发送者的电话号码。虽然这种消息传递服务是特定于特定服务的用户的，但很明显，中立的第三方可以提供类似的数据库，以便在端点之间进行协调。
At the time [RFC4474] was written, the hopes for establishing a certificate authority for telephone numbers on the Internet largely rested on public ENUM deployment. The e164.arpa DNS tree established for ENUM could have grown to include certificates for telephone numbers or at least for number ranges. It is now clear, however, that public ENUM as originally envisioned has little prospect for adoption. That said, some national authorities for telephone numbers are migrating their provisioning services to the Internet and issuing credentials that express authority for telephone numbers to secure those services. These new authorities for numbers could provide to the public Internet the necessary signatory authority for securing calling party numbers. While these systems are far from universal, the authors of this document believe that a solution devised for the North American Numbering Plan could have applicability to other country codes.
在编写[RFC4474]时，在互联网上建立电话号码证书颁发机构的希望很大程度上取决于公共ENUM部署。为ENUM建立的e164.arpa DNS树可能已经扩展到包括电话号码或至少号码范围的证书。然而，现在很清楚，最初设想的公共ENUM几乎没有被采用的前景。这就是说，一些国家电话号码管理部门正在将其提供服务迁移到互联网上，并颁发证书，表明电话号码管理部门有权保护这些服务。这些新的电话号码管理机构可以向公共互联网提供必要的签名权限，以确保呼叫方号码的安全。虽然这些系统远未普及，但本文件的作者认为，为北美编号计划设计的解决方案可能适用于其他国家代码。
There have been a number of recent high-profile compromises of web certificate authorities. The presence of numerous (in some cases, hundreds) trusted certificate authorities in modern web browsers has become a significant security liability. As [RFC4474] relied on web certificate authorities, this too provides new lessons for any work on revising [RFC4474], namely, that innovations like DNS-Based Authentication of Named Entities (DANE) [RFC6698], which designate a specific certificate preferred by the owner of a DNS name, could greatly improve the security of a SIP Identity mechanism and, moreover, that when considering new certificate authorities for telephone numbers, we should be wary of excessive pluralism. While a chain of delegation with a progressively narrowing scope of authority (e.g., from a regulatory entity, to a carrier, to a reseller, to an end user) is needed to reflect operational practices, there is no need to have multiple roots or peer entities that both claim authority for the same telephone number or number range.
web证书颁发机构最近出现了一些引人注目的妥协。现代web浏览器中存在大量（在某些情况下，数百个）可信证书颁发机构，这已成为一项重大的安全责任。由于[RFC4474]依赖于web证书颁发机构，这也为修订[RFC4474]的任何工作提供了新的经验教训，即基于DNS的命名实体身份验证（DANE）[RFC6698]等创新，指定DNS名称所有者首选的特定证书，可以大大提高SIP身份机制的安全性，而且，在考虑电话号码的新证书颁发机构时，我们应该警惕过度多元化。虽然需要授权范围逐渐缩小的授权链（例如，从监管实体到运营商、到经销商、到最终用户）来反映运营实践，但不需要有多个根实体或对等实体，它们都声称拥有相同电话号码或号码范围的授权。
Given the prevalence of established B2BUA deployments, we may have a further opportunity to review the elements signed using the SIP Identity mechanism [RFC4474] and to decide on the value of alternative signature mechanisms. Separating the elements necessary for (a) securing the From header field value and preventing replays from (b) the elements necessary to prevent men-in-the-middle from tampering with messages may also yield a strategy for identity that will be practicable in some highly mediated networks. Solutions in this space must, however, remain mindful of the requirements for securing cryptographic material necessary to support Datagram Transport Layer Security for Secure RTP (DTLS-SRTP) or future security mechanisms.
考虑到已建立的B2BUA部署的普遍性，我们可能有进一步的机会审查使用SIP身份机制[RFC4474]签名的元素，并决定替代签名机制的价值。将（a）确保来自报头字段值的安全和防止重播所需的元素与（b）防止中间人篡改消息所需的元素分离，还可以产生一种身份策略，该策略在一些高度中介的网络中是可行的。然而，该领域的解决方案必须注意保护加密材料的要求，这些加密材料是支持安全RTP（DTLS-SRTP）或未来安全机制的数据报传输层安全所必需的。
One thing that has not changed, and is not likely to change in the future, is the transitive nature of trust in the PSTN. When a call from the PSTN arrives at a SIP gateway with a calling party number, the gateway will have little chance of determining whether the originator of the call was authorized to claim that calling party number. Due to roaming and countless other factors, calls on the PSTN may emerge from administrative domains that were not assigned the originating number. This use case will remain the most difficult to tackle for an identity system and may prove beyond repair. It does, however, seem that with the changes in the solution space, and
有一件事没有改变，将来也不太可能改变，那就是PSTN中信任的传递性。当来自PSTN的呼叫到达具有主叫方号码的SIP网关时，网关将几乎没有机会确定呼叫的发起人是否被授权声明该主叫方号码。由于漫游和无数其他因素，PSTN上的呼叫可能来自未分配始发号码的管理域。对于身份识别系统来说，这个用例仍然是最难处理的，并且可能无法修复。然而，随着解决方案空间的变化
a better understanding of the limits of [RFC4474] and VIPR, we are today in a position to reexamine the problem space and find solutions that can have a significant impact on the secure origins problem.
为了更好地理解[RFC4474]和VIPR的局限性，我们今天能够重新审视问题空间，并找到能够对安全起源问题产生重大影响的解决方案。
While spoofing the origins of communication is a source of numerous security concerns, solutions for identifying communications must also be mindful of the security risks of pervasive monitoring (see [RFC7258]). Identifying information, once it is attached to communications, can potentially be inspected by parties other than the intended recipient and collected for any number of reasons. As stated above, the purpose of this work is not to eliminate anonymity; furthermore, to be viable and in the public interest, solutions should not facilitate the unauthorized collection of calling data.
尽管欺骗通信来源是众多安全问题的根源，但识别通信的解决方案还必须注意普适监控的安全风险（参见[RFC7258]）。识别信息一旦附加到通信中，可能会被预期接收人以外的其他方检查，并出于各种原因收集。如上所述，这项工作的目的不是消除匿名性；此外，为了可行并符合公共利益，解决方案不应促进未经授权的呼叫数据收集。
Currently, telephone numbers are typically managed in a loose delegation hierarchy. For example, a national regulatory agency may task a private, neutral entity with administering numbering resources, such as area codes, and a similar entity with assigning number blocks to carriers and other authorized entities, who in turn then assign numbers to customers. Resellers with looser regulatory obligations can complicate the picture, and in many cases, it is difficult to distinguish the roles of enterprises from carriers. In many countries, individual numbers are portable between carriers, at least within the same technology (e.g., wireline-to-wireline). Separate databases manage the mapping of numbers to switch identifiers, companies, and textual Caller ID information.
目前，电话号码通常在松散的委托层次结构中进行管理。例如，国家监管机构可以委托私人中立实体管理编号资源，如区号，并委托类似实体向承运人和其他授权实体分配号码块，然后由后者向客户分配号码。监管义务较宽松的经销商可能会使情况复杂化，在许多情况下，很难区分企业和运营商的角色。在许多国家，至少在相同技术（例如，有线到有线）内，单个号码可在运营商之间移动。独立的数据库管理号码到交换机标识符、公司和文本呼叫者ID信息的映射。
As the PSTN transitions to using VoIP technologies, new assignment policies and management mechanisms are likely to emerge. For example, it has been proposed that geography could play a smaller role in number assignments, that individual numbers could be assigned to end users directly rather than only to service providers, and that the assignment of numbers does not have to depend on providing actual call delivery services.
随着PSTN过渡到使用VoIP技术，新的分配策略和管理机制可能会出现。例如，有人提议，地理位置在号码分配中的作用较小，单个号码可以直接分配给最终用户，而不仅仅是服务提供商，号码的分配不必依赖于提供实际的呼叫传递服务。
Databases today already map telephone numbers to entities that have been assigned the number, e.g., through the LERG (Local Exchange Routing Guide) in the United States. Thus, the transition to IP-based networks may offer an opportunity to integrate cryptographic bindings between numbers or number ranges and service providers into databases.
今天的数据库已经将电话号码映射到已分配号码的实体，例如通过美国的LERG（本地交换路由指南）。因此，向基于IP的网络过渡可能会提供一个机会，将数字或数字范围与服务提供商之间的加密绑定集成到数据库中。
This section describes only the high-level requirements of the STIR effort, which we expect will be further articulated as work continues:
本节仅描述了STIR工作的高层次要求，我们希望随着工作的继续，这些要求将得到进一步阐述：
Generation: Intermediaries as well as end systems must be able to generate the source identity information.
生成：中介机构和终端系统必须能够生成源身份信息。
Validation: Intermediaries as well as end systems must be able to validate the source identity information.
验证：中介机构和终端系统必须能够验证源标识信息。
Usability: Any validation mechanism must work without human intervention, for example, without mechanisms like CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart).
可用性：任何验证机制都必须在没有人为干预的情况下工作，例如，没有CAPTCHA（区分计算机和人类的完全自动化公共图灵测试）等机制。
Deployability: Must survive transition of the call to the PSTN and the presence of B2BUAs.
可部署性：必须在呼叫转移到PSTN和存在B2BUA的情况下生存。
Reflecting existing authority: Must stage credentials on existing national-level number delegations, without assuming the need for an international golden root on the Internet.
反映现有权威：必须在现有国家级代表团的基础上提交全权证书，而不必假设需要互联网上的国际金根。
Accommodating current practices: Must allow number portability among carriers and must support legitimate usage of number spoofing (e.g., doctors' offices and call centers).
适应当前做法：必须允许运营商之间的号码可移植性，并且必须支持合法使用号码欺骗（例如，医生办公室和呼叫中心）。
Minimal payload overhead: Must lead to minimal expansion of SIP header fields to avoid fragmentation in deployments that use UDP.
最小负载开销：必须使SIP头字段的扩展最小，以避免在使用UDP的部署中出现碎片。
Efficiency: Must minimize RTTs for any network lookups and minimize any necessary cryptographic operations.
效率：必须最小化任何网络查找的RTT，并最小化任何必要的加密操作。
Privacy: A solution must minimize the amount of information that an unauthorized party can learn about what numbers have been called by a specific caller and what numbers have called a specific called party.
隐私：解决方案必须最大限度地减少未经授权方可以了解的关于特定呼叫方呼叫了哪些号码以及特定被叫方呼叫了哪些号码的信息量。
Some requirements specifically outside the scope of the effort include:
明确超出工作范围的一些要求包括：
Display name: This effort does not consider how the display name of the caller might be validated.
显示名称：此努力不考虑调用方的显示名称如何验证。
Response authentication: This effort only considers the problem of providing secure telephone identity for requests, not for responses to requests; no solution is proposed for the problem of determining to which number a call has connected [RFC4916].
响应身份验证：这项工作只考虑为请求提供安全电话身份的问题，而不考虑对请求的响应；对于确定呼叫连接到哪个号码的问题，没有提出解决方案[RFC4916]。
We would like to thank Sanjay Mishra, Fernando Mousinho, David Frankel, Penn Pfautz, Mike Hammer, Dan York, Andrew Allen, Philippe Fouquart, Hadriel Kaplan, Richard Shockey, Russ Housley, Alissa Cooper, Bernard Aboba, Sean Turner, Brian Rosen, Eric Burger, and Eric Rescorla for the discussion and input that contributed to this document.
我们要感谢Sanjay Mishra、Fernando Mousino、David Frankel、Penn Pfautz、Mike Hammer、Dan York、Andrew Allen、Philippe Fouquart、Hadriel Kaplan、Richard Shockey、Russ Housley、Alissa Cooper、Bernard Aboba、Sean Turner、Brian Rosen、Eric Burger和Eric Rescorla对本文件的讨论和投入。
This document is about improving the security of call origin identification; security considerations for specific solutions will be discussed in solutions documents.
本文件旨在提高呼叫来源识别的安全性；具体解决方案的安全注意事项将在解决方案文档中讨论。
[CONCERNS] Rosenberg, J., "Concerns around the Applicability of RFC 4474", Work in Progress, February 2008.
[关注]Rosenberg，J.，“对RFC 4474适用性的关注”，正在进行的工作，2008年2月。
[NEWS-HACK] Wikipedia, "News International phone hacking scandal", June 2014, <http://en.wikipedia.org/w/index.php?title=News _International_phone_hacking_scandal&oldid=614607591>.
[新闻黑客]维基百科，“新闻国际电话黑客丑闻”，2014年6月<http://en.wikipedia.org/w/index.php?title=News _国际电话窃听丑闻&oldid=614607591>。
[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月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，2002年6月。
[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月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[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月。
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.
[RFC4916]Elwell，J.，“会话启动协议（SIP）中的连接身份”，RFC 4916，2007年6月。
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol (SIP) and Spam", RFC 5039, January 2008.
[RFC5039]Rosenberg，J.和C.Jennings，“会话启动协议（SIP）和垃圾邮件”，RFC 5039，2008年1月。
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real- time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.
[RFC5727]Peterson，J.，Jennings，C.，和R.Sparks，“会话启动协议（SIP）和实时应用程序和基础设施领域的变更过程”，BCP 67，RFC 5727，2010年3月。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，2012年8月。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，2014年5月。
[ROBOCALL-CHALLENGE] Federal Trade Commission (FTC), "FTC Robocall Challenge", <http://robocall.challenge.gov/>.
[ROBOCALL-CHALLENGE]联邦贸易委员会（FTC），“FTC ROBOCALL CHALLENGE”<http://robocall.challenge.gov/>.
[ROBOCALL-FCC] Federal Communications Commission (FCC), "Robocalls", April 2013, <http://www.fcc.gov/guides/robocalls>.
[ROBOCALL-FCC]联邦通信委员会（FCC），“Robocalls”，2013年4月<http://www.fcc.gov/guides/robocalls>.
[SECURE-ORIGIN] Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba, "Secure Call Origin Identification", Work in Progress, November 2012.
[SECURE-ORIGIN]Cooper，A.，Tschofenig，H.，Peterson，J.，和B.Aboba，“安全呼叫来源识别”，正在进行的工作，2012年11月。
[SIP-SECURITY] Peterson, J., "Retargeting and Security in SIP: A Framework and Requirements", Work in Progress, February 2005.
[SIP-SECURITY]Peterson，J.，“SIP中的重定目标和安全：框架和要求”，正在进行的工作，2005年2月。
[SWATTING] The Federal Bureau of Investigation (FBI), "Don't Make the Call: The New Phenomenon of 'Swatting'", February 2008, <http://www.fbi.gov/news/stories/2008/february/ swatting020408>.
[拍打]联邦调查局（FBI），“不要打电话：拍打的新现象”，2008年2月<http://www.fbi.gov/news/stories/2008/february/ 拍打020408>。
[TDOS] Krebs, B., "DHS Warns of 'TDoS' Extortion Attacks on Public Emergency Networks", April 2013, <http://krebsonsecurity.com/2013/04/dhs-warns-of-tdos-extortion-attacks-on-public-emergency-networks/>.
[TDOS]Krebs，B.，“国土安全部警告公共应急网络受到“TDOS”勒索攻击”，2013年4月<http://krebsonsecurity.com/2013/04/dhs-warns-of-tdos-extortion-attacks-on-public-emergency-networks/>.
[VIPR-OVERVIEW] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-Huguenin, "Verification Involving PSTN Reachability: Requirements and Architecture Overview", Work in Progress, December 2013.
[VIPR-概述]Barnes，M.，Jennings，C.，Rosenberg，J.，和M.Petit Huguenin，“涉及PSTN可达性的验证：需求和架构概述”，正在进行的工作，2013年12月。
Authors' Addresses
作者地址
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
EMail: jon.peterson@neustar.biz
EMail: jon.peterson@neustar.biz
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
美国纽约州纽约市哥伦比亚大学计算机科学系计算机科学大楼450号
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Hannes Tschofenig Hall, Tirol 6060 Austria
奥地利泰罗尔市汉内斯·茨霍芬尼大厅6060
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at