Network Working Group J. Rosenberg
Request for Comments: 4453 Cisco Systems
Category: Informational G. Camarillo, Ed.
Ericsson
D. Willis
Cisco Systems
April 2006
Network Working Group J. Rosenberg
Request for Comments: 4453 Cisco Systems
Category: Informational G. Camarillo, Ed.
Ericsson
D. Willis
Cisco Systems
April 2006
Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP)
会话启动协议（SIP）中基于同意的通信要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks. This document identifies a set of requirements for extensions to SIP that add consent-based communications.
会话启动协议（SIP）支持跨多种媒体类型的通信，包括实时音频、视频、文本、即时消息和状态。在其当前形式中，它允许会话邀请、即时消息和其他请求从一方传递到另一方，而无需接收方的明确同意。如果没有此类同意，SIP可能被用于恶意目的，包括垃圾邮件和拒绝服务攻击。本文档确定了添加基于同意的通信的SIP扩展的一组需求。
Table of Contents
目录
1. Introduction ....................................................2
2. Problem Statement ...............................................2
3. Requirements ....................................................4
4. Security Considerations .........................................5
5. References ......................................................6
5.1. Normative References .......................................6
5.2. Informational References ...................................6
1. Introduction ....................................................2
2. Problem Statement ...............................................2
3. Requirements ....................................................4
4. Security Considerations .........................................5
5. References ......................................................6
5.1. Normative References .......................................6
5.2. Informational References ...................................6
The Session Initiation Protocol (SIP) [1] supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. This communication is established by the transmission of various SIP requests (such as INVITE and MESSAGE [3]) from an initiator to the recipient, with whom communication is desired. Although a recipient of such a SIP request can reject the request, and therefore decline the session, a SIP network will deliver a SIP request to the recipient without their explicit consent.
会话启动协议（SIP）[1]支持跨多种媒体类型的通信，包括实时音频、视频、文本、即时消息和状态。这种通信是通过从发起者向需要通信的接收者传输各种SIP请求（例如INVITE和MESSAGE[3]）来建立的。尽管这样的SIP请求的接收者可以拒绝该请求，从而拒绝会话，但是SIP网络将在没有接收者明确同意的情况下向接收者发送SIP请求。
Receipt of these requests without explicit consent can cause a number of problems in SIP networks. These include amplification attacks. These problems have plagued email. At the time of this writing, most SIP services are not interconnected, so the incidence of amplification attacks directed at SIP services is low compared to the same attacks on email services. The SIPPING working group believes it is necessary to address these attacks proactively so the attacks do not become as burdensome as attacks on email have become.
在没有明确同意的情况下接收这些请求可能会在SIP网络中引起许多问题。其中包括放大攻击。这些问题一直困扰着电子邮件。在撰写本文时，大多数SIP服务都没有相互连接，因此与针对电子邮件服务的相同攻击相比，针对SIP服务的放大攻击的发生率较低。啜饮工作组认为，有必要主动应对这些攻击，这样攻击就不会像电子邮件攻击那样繁重。
This document elaborates on the problems posed by the current open model in which SIP was designed, and then goes on to define a set of requirements for adding a consent framework to SIP.
本文档详细阐述了当前设计SIP的开放模型所带来的问题，然后定义了向SIP添加同意框架的一组要求。
In SIP networks designed according to the principles of RFC 3261 [1] and RFC 3263 [2], anyone on the Internet can create and send a SIP request to any other SIP user, by identifying that user with a SIP Uniform Resource Identifier (URI). The SIP network will usually deliver this request to the user identified by that URI. It is possible, of course, for network services, such as call screening, to block such messaging from occurring, but this is not widespread and certainly not a systematic solution to the problem under consideration here.
在根据RFC 3261[1]和RFC 3263[2]的原理设计的SIP网络中，Internet上的任何人都可以通过使用SIP统一资源标识符（URI）标识任何其他SIP用户来创建SIP请求并将其发送给该用户。SIP网络通常将此请求传递给该URI标识的用户。当然，网络服务（如呼叫屏蔽）有可能阻止此类消息传递的发生，但这并不是普遍存在的，也肯定不是本文所考虑问题的系统解决方案。
Once the SIP request is received by the recipient, the user agent typically takes some kind of automated action to alert the user about receipt of the message. For INVITE requests, this usually involves delivering an audible alert (e.g., "ringing the phone"), or a visual alert (e.g., creating a screen pop-up window). These indicators frequently convey the subject of the call and the identity of the caller. Due to the real-time nature of the session, these alerts are typically disruptive in nature, so as to get the attention of the user.
一旦接收方接收到SIP请求，用户代理通常会采取某种自动操作来提醒用户收到消息。对于INVITE请求，这通常涉及发出声音警报（例如，“电话铃响”）或视觉警报（例如创建屏幕弹出窗口）。这些指示器经常传达呼叫的主题和呼叫者的身份。由于会话的实时性，这些警报通常具有破坏性，以便引起用户的注意。
For MESSAGE requests, the content of the message is usually rendered to the user.
对于消息请求，消息的内容通常呈现给用户。
SUBSCRIBE [4] requests do not normally get delivered to the user agents residing on a user's devices. Rather, they are normally processed by network-based state agents. The watcher information event package allows a user to find out that such requests were generated for them, affording the user the opportunity to approve or deny the request. As a result, SUBSCRIBE processing, and most notably presence, already has a consent-based operation. Nevertheless, this already-existing consent mechanism for SIP subscriptions does not protect network agents against denial-of-service (DoS) attacks.
订阅[4]请求通常不会传递到驻留在用户设备上的用户代理。相反，它们通常由基于网络的状态代理处理。watcher information事件包允许用户发现这些请求是为他们生成的，从而为用户提供批准或拒绝请求的机会。因此，订阅处理，尤其是存在，已经有了基于同意的操作。然而，这种已有的SIP订阅同意机制并不能保护网络代理免受拒绝服务（DoS）攻击。
A problem that arises when requests can be delivered to user agents directly, without their consent, is amplification attacks. SIP proxies provide a convenient relay point for targeting a message to a particular user or IP address and, in particular, forwarding to a recipient that is often not directly reachable without usage of the proxy. Some SIP proxy servers forward a single request to several instances or contacts for the same user or resource. This process is called "forking". Another type of SIP server provides the SIP URI-list service [5], which sends a new copy of the same request to each recipient in the URI-list. Examples of URI-list services are subscriptions to resource lists [6], dial-out conference servers [8], and MESSAGE URI-list services [7]. A SIP URI-list service could be used as an amplifier, allowing a single SIP request to flood a single target host or network. For example, a user can create a resource list with 100 entries, each of which is a URI of the form "sip:identifier@target-IP", where target-IP is the IP address to which the attack is to be directed. Sending a single SIP SUBSCRIBE request to such a list will cause the resource list server to generate 100 SUBSCRIBE requests, each to the IP address of the target, which does not even need to be a SIP node.
当请求可以在未经用户代理同意的情况下直接传递给用户代理时，出现的一个问题是放大攻击。SIP代理提供了一个方便的中继点，用于将消息定向到特定用户或IP地址，特别是转发到通常不使用代理就无法直接访问的收件人。一些SIP代理服务器将单个请求转发给同一用户或资源的多个实例或联系人。这个过程称为“分叉”。另一种类型的SIP服务器提供SIP URI列表服务[5]，它向URI列表中的每个收件人发送同一请求的新副本。URI列表服务的示例包括对资源列表[6]、拨出会议服务器[8]和消息URI列表服务[7]的订阅。SIPURI列表服务可以用作放大器，允许单个SIP请求淹没单个目标主机或网络。例如，用户可以创建包含100个条目的资源列表，每个条目都是“sip:identifier@target-IP”，其中目标IP是攻击要指向的IP地址。向这样的列表发送单个SIP SUBSCRIBE请求将导致资源列表服务器生成100个SUBSCRIBE请求，每个请求都指向目标的IP地址，目标甚至不需要是SIP节点。
Note that the target-IP does not need to be the same in all the URIs in order to attack a single machine. For example, the target-IP addresses may all belong to the same subnetwork, in which case the target of the attack would be the access router of the subnetwork.
注意，要攻击一台机器，目标IP不需要在所有URI中都相同。例如，目标IP地址可能都属于同一子网，在这种情况下，攻击的目标将是子网的接入路由器。
In addition to launching DoS attacks, attackers could also use SIP URI-list servers as amplifiers to deliver spam. For INVITE requests, this takes the form of typical "telemarketer" calls. A user might receive a stream of never-ending requests for communications, each of them disrupting the user and demanding their attention. For MESSAGE
除了发起DoS攻击外，攻击者还可以使用SIP URI列表服务器作为放大器来传递垃圾邮件。对于邀请请求，这采用典型的“电话销售员”电话的形式。用户可能会收到源源不断的通信请求，每个请求都会中断用户并要求他们注意。留言
requests, the problem is even more severe. The user might receive a never-ending stream of visual alerts (e.g., screen pop-up windows) that deliver unwanted, malicious, or otherwise undesired content.
但是，问题更加严重。用户可能会收到源源不断的视觉警报流（例如，屏幕弹出窗口），这些警报会传递不需要的、恶意的或其他不需要的内容。
Both amplification attacks related to spam and DoS can be alleviated by adding a consent-based communications framework to SIP. Such a framework keeps servers from relaying messages to users without their consent.
通过向SIP添加基于同意的通信框架，可以减轻与垃圾邮件和拒绝服务相关的放大攻击。这种框架防止服务器在未经用户同意的情况下向用户转发消息。
The framework for SIP URI-list services [5] identifies amplification attacks as a problem in the context of URI-list services. That framework mandates the use of opt-in lists, which are a form of consent-based communications. The reader can find an analysis on how a consent-based framework helps alleviate spam-related problems in [9].
SIP URI列表服务框架[5]将放大攻击识别为URI列表服务上下文中的一个问题。该框架规定使用选择加入名单，这是一种基于同意的通信形式。读者可以在[9]中找到关于基于同意的框架如何帮助缓解垃圾邮件相关问题的分析。
The following identify requirements for a solution that provides consent-based communications in SIP. A relay is defined as any SIP server, be it a proxy, Back-to-Back User Agent (B2BUA), or some hybrid, that receives a request and translates the request URI into one or more next-hop URIs to which it then delivers a request.
以下内容确定了在SIP中提供基于同意的通信的解决方案的要求。中继被定义为任何SIP服务器，无论是代理服务器、背对背用户代理（B2BUA）还是某种混合服务器，它们接收请求并将请求URI转换为一个或多个下一跳URI，然后向其发送请求。
REQ 1: The solution must keep relays from delivering a SIP request to a recipient unless the recipient has explicitly granted permission to the relay using appropriately authenticated messages.
REQ 1：解决方案必须防止中继向收件人发送SIP请求，除非收件人使用经过适当身份验证的消息明确授予中继权限。
REQ 2: The solution shall prevent relays from generating more than one outbound request in response to an inbound request, unless permission to do so has been granted by the resource to whom the outbound request was to be targeted. This requirement avoids the consent mechanism itself becoming the focus of DoS attacks.
REQ 2：解决方案应防止中继生成多个出站请求以响应入站请求，除非出站请求的目标资源已授予这样做的许可。这一要求避免了同意机制本身成为DoS攻击的焦点。
REQ 3: The permissions shall be capable of specifying that messages from a specific user, identified by a SIP URI that is an Address-of-Record (AOR), are permitted.
REQ 3：权限应能够指定允许来自特定用户的消息，该消息由作为记录地址（AOR）的SIP URI标识。
REQ 4: Each recipient AOR must be able to specify permissions separately for each SIP service that forwards messages to the recipient. For example, Alice may authorize forwarding to her from domain A, but not from domain B.
REQ 4：每个收件人AOR必须能够为每个向收件人转发消息的SIP服务分别指定权限。例如，Alice可以授权从域A转发给她，但不能从域B转发。
REQ 5: It shall be possible for a user to revoke permissions at any time.
请求5：用户可以随时撤销权限。
REQ 6: It shall not be required for a user or user agent to store information in order to be able to revoke permissions that were previously granted for a relay resource.
REQ 6：不要求用户或用户代理存储信息，以便能够撤销先前授予中继资源的权限。
REQ 7: The solution shall work in an inter-domain context, without requiring preestablished relationships between domains.
请求7：解决方案应在域间上下文中工作，不需要域间预先建立的关系。
REQ 8: The solution shall work for all current and future SIP methods.
要求8：该解决方案适用于所有当前和未来的SIP方法。
REQ 9: The solution shall be applicable to forking proxies.
要求9：该解决方案应适用于分叉代理。
REQ 10: The solution shall be applicable to URI-list services, such as resource list servers [5], MESSAGE URI-list services [7], and conference servers performing dial-out functions [8].
REQ 10：该解决方案应适用于URI列表服务，如资源列表服务器[5]、消息URI列表服务[7]和执行拨号功能的会议服务器[8]。
REQ 11: In SIP, URI-lists can be stored on the URI-list server or provided in a SIP request. The consent framework must work in both cases.
REQ 11：在SIP中，URI列表可以存储在URI列表服务器上，也可以在SIP请求中提供。同意框架必须在这两种情况下都起作用。
REQ 12: The solution shall allow anonymous communications, as long as the recipient is willing to accept anonymous communications.
请求12：只要接收方愿意接受匿名通信，解决方案应允许匿名通信。
REQ 13: If the recipient of a request wishes to be anonymous with respect to the original sender, it must be possible for the recipient to grant permission for the sender without the original sender learning the recipient's identity.
请求13：如果请求的接收者希望对原始发送者匿名，则接收者必须能够在原始发送者不了解接收者身份的情况下为发送者授予权限。
REQ 14: The solution shall prevent attacks that seek to undermine the underlying goal of consent. That is, it should not be possible to "fool" the system into delivering a request for which permission was not, in fact, granted.
请求14：解决方案应防止试图破坏同意基本目标的攻击。也就是说，不应该“愚弄”系统，使其交付实际上未授予许可的请求。
REQ 15: The solution shall not require the recipient of the communications to be connected to the network at the time communications are attempted.
REQ 15：解决方案不应要求通信接收者在尝试通信时连接到网络。
REQ 16: The solution shall not require the sender of a SIP request to be connected at the time that a recipient provides permission.
REQ 16：解决方案不应要求SIP请求的发送方在接收方提供许可时连接。
REQ 17: The solution should scale to Internet-wide deployment.
需求17：解决方案应扩展到Internet范围的部署。
Security has been discussed throughout this document.
本文件中已讨论了安全问题。
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[2] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[3] Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4] Roach，A.B.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[5] Camarillo, G. and A.B. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services", Work in Progress, January 2006.
[5] Camarillo，G.和A.B.Roach，“会话启动协议（SIP）统一资源标识符（URI）-列表服务的框架和安全考虑”，正在进行的工作，2006年1月。
[6] Roach, A.B., Rosenberg, J., and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", Work in Progress, January 2005.
[6] Roach，A.B.，Rosenberg，J.和B.Campbell，“资源列表的会话启动协议（SIP）事件通知扩展”，正在进行的工作，2005年1月。
[7] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", Work in Progress, February 2006.
[7] Garcia Martin，M.和G.Camarillo，“会话启动协议（SIP）中的多收件人消息请求”，正在进行的工作，2006年2月。
[8] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", Work in Progress, February 2006.
[8] Camarillo，G.和A.Johnston，“使用会话启动协议（SIP）中包含的请求列表建立会议”，正在进行的工作，2006年2月。
[9] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", Work in Progress, July 2005.
[9] Rosenberg，J.，“会话启动协议（SIP）和垃圾邮件”，正在进行的工作，2005年7月。
Authors' Addresses
作者地址
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Cisco Systems 600美国新泽西州帕西帕尼拉尼德广场07054号
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Gonzalo Camarillo (Editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
冈萨洛·卡马里洛（编辑）爱立信·赫萨兰蒂11号乔瓦斯02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Dean Willis Cisco Systems 2200 E. Pres. George Bush Turnpike Richardson, TX 75082 USA
迪安·威利斯·思科系统公司2200 E.主席乔治·布什收费公路理查森，德克萨斯州75082
EMail: dean.willis@softarmor.com
EMail: dean.willis@softarmor.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。