draft-ietf-sipping-consent-reqs-04.txt   rfc4453.txt 
SIPPING J. Rosenberg Network Working Group J. Rosenberg
Internet-Draft Cisco Systems Request for Comments: 4453 Cisco Systems
Expires: July 21, 2006 G. Camarillo, Ed. Category: Informational G. Camarillo, Ed.
Ericsson Ericsson
D. Willis D. Willis
Cisco Systems Cisco Systems
January 17, 2006 April 2006
Requirements for Consent-Based Communications in the Session Initiation
Protocol (SIP)
draft-ietf-sipping-consent-reqs-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Requirements for Consent-Based Communications
http://www.ietf.org/ietf/1id-abstracts.txt. in the Session Initiation Protocol (SIP)
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 21, 2006. 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 Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The Session Initiation Protocol (SIP) supports communications across The Session Initiation Protocol (SIP) supports communications across
many media types, including real-time audio, video, text, instant many media types, including real-time audio, video, text, instant
messaging, and presence. In its current form, it allows session messaging, and presence. In its current form, it allows session
invitations, instant messages, and other requests to be delivered invitations, instant messages, and other requests to be delivered
from one party to another without requiring explicit consent of the from one party to another without requiring explicit consent of the
recipient. Without such consent, it is possible for SIP to be used recipient. Without such consent, it is possible for SIP to be used
for malicious purposes, including spam and denial-of-service attacks. for malicious purposes, including spam and denial-of-service attacks.
This document identifies a set of requirements for extensions to SIP This document identifies a set of requirements for extensions to SIP
that add consent-based communications. that add consent-based communications.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement ...............................................2
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements ....................................................4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations .........................................5
4.1. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 5. References ......................................................6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Normative References .......................................6
5.1. Normative References . . . . . . . . . . . . . . . . . . . 7 5.2. Informational References ...................................6
5.2. Informational References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [1] supports communications The Session Initiation Protocol (SIP) [1] supports communications
across many media types, including real-time audio, video, text, across many media types, including real-time audio, video, text,
instant messaging, and presence. This communication is established instant messaging, and presence. This communication is established
by the transmission of various SIP requests (such as INVITE and by the transmission of various SIP requests (such as INVITE and
MESSAGE [3]) from an initiator to the recipient, with whom MESSAGE [3]) from an initiator to the recipient, with whom
communication is desired. Although a recipient of such a SIP request communication is desired. Although a recipient of such a SIP request
can reject the request, and therefore decline the session, a SIP can reject the request, and therefore decline the session, a SIP
skipping to change at page 3, line 35 skipping to change at page 2, line 35
This document elaborates on the problems posed by the current open 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 model in which SIP was designed, and then goes on to define a set of
requirements for adding a consent framework to SIP. requirements for adding a consent framework to SIP.
2. Problem Statement 2. Problem Statement
In SIP networks designed according to the principles of RFC 3261 [1] 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 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 request to any other SIP user, by identifying that user with a SIP
URI. The SIP network will usually deliver this request to the user Uniform Resource Identifier (URI). The SIP network will usually
identified by that URI. It is possible, of course, for network deliver this request to the user identified by that URI. It is
services, such as call screening, to block such messaging from possible, of course, for network services, such as call screening, to
occuring, but this is not widespread and certainly not a systematic block such messaging from occurring, but this is not widespread and
solution to the problem under consideration here. certainly not a systematic solution to the problem under
consideration here.
Once the SIP request is received by the recipient, the user agent Once the SIP request is received by the recipient, the user agent
typically takes some kind of automated action to alert the user about typically takes some kind of automated action to alert the user about
receipt of the message. For INVITE requests, this usually involves receipt of the message. For INVITE requests, this usually involves
delivering an audible alert (e.g., "ringing the phone"), or a visual delivering an audible alert (e.g., "ringing the phone"), or a visual
alert (e.g., creating a screen pop-up window). These indicators alert (e.g., creating a screen pop-up window). These indicators
frequently convey the subject of the call and the identity of the 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 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 typically disruptive in nature, so as to get the attention of the
user. user.
skipping to change at page 4, line 14 skipping to change at page 3, line 16
to the user. to the user.
SUBSCRIBE [4] requests do not normally get delivered 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 agents residing on a user's devices. Rather, they are normally
processed by network-based state agents. The watcher information processed by network-based state agents. The watcher information
event package allows a user to find out that such requests were event package allows a user to find out that such requests were
generated for them, affording the user the opportunity to approve or generated for them, affording the user the opportunity to approve or
deny the request. As a result, SUBSCRIBE processing, and most deny the request. As a result, SUBSCRIBE processing, and most
notably presence, already has a consent-based operation. notably presence, already has a consent-based operation.
Nevertheless, this already-existing consent mechanism for SIP Nevertheless, this already-existing consent mechanism for SIP
subscriptions does not protect network agents against DoS attacks. subscriptions does not protect network agents against denial-of-
service (DoS) attacks.
A problem that arises when requests can be delivered to user agents A problem that arises when requests can be delivered to user agents
directly, without their consent, is amplification attacks. SIP directly, without their consent, is amplification attacks. SIP
proxies provide a convenient relay point for targeting a message to a proxies provide a convenient relay point for targeting a message to a
particular user or IP address, and in particular, forwarding to a particular user or IP address and, in particular, forwarding to a
recipient which is often not directly reachable without usage of the recipient that is often not directly reachable without usage of the
proxy. Some SIP proxy servers forward a single request to several proxy. Some SIP proxy servers forward a single request to several
instances or contacts for the same user or resource. This process is instances or contacts for the same user or resource. This process is
called "forking". Another type of SIP server provides the SIP URI- 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 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 recipient in the URI-list. Examples of URI-list services are
subscriptions to resource lists [6], dial-out conference servers [8], subscriptions to resource lists [6], dial-out conference servers [8],
and MESSAGE URI-list services [7]. A SIP URI-list service could be 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 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 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 list with 100 entries, each of which is a URI of the form
skipping to change at page 4, line 43 skipping to change at page 3, line 46
request to such a list will cause the resource list server to request to such a list will cause the resource list server to
generate 100 SUBSCRIBE requests, each to the IP address of the generate 100 SUBSCRIBE requests, each to the IP address of the
target, which does not even need to be a SIP node. target, which does not even need to be a SIP node.
Note that the target-IP does not need to be the same in all the 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 URIs in order to attack a single machine. For example, the
target-IP addresses may all belong to the same subnetwork, in target-IP addresses may all belong to the same subnetwork, in
which case the target of the attack would be the access router of which case the target of the attack would be the access router of
the subnetwork. the subnetwork.
In addition to launching DoS (Denial of Service) attacks, attackers In addition to launching DoS attacks, attackers could also use SIP
could also use SIP URI-list servers as amplifiers to deliver spam. URI-list servers as amplifiers to deliver spam. For INVITE requests,
For INVITE requests, this takes the form of typical "telemarketer" this takes the form of typical "telemarketer" calls. A user might
calls. A user might receive a stream of never-ending requests for receive a stream of never-ending requests for communications, each of
communications, each of them disrupting the user and demanding their them disrupting the user and demanding their attention. For MESSAGE
attention. For MESSAGE requests, the problem is even more severe. requests, the problem is even more severe. The user might receive a
The user might receive a never-ending stream of visual alerts (e.g., never-ending stream of visual alerts (e.g., screen pop-up windows)
screen pop-up windows) that deliver unwanted, malicious, or otherwise that deliver unwanted, malicious, or otherwise undesired content.
undesired content.
Both amplification attacks related to spam and DoS can be alleviated Both amplification attacks related to spam and DoS can be alleviated
by adding a consent-based communications framework to SIP. Such a by adding a consent-based communications framework to SIP. Such a
framework keeps servers from relaying messages to users without their framework keeps servers from relaying messages to users without their
consent. consent.
The framework for SIP URI-list services [5] identifies The framework for SIP URI-list services [5] identifies
amplification attacks as a problem in the context of URI-list amplification attacks as a problem in the context of URI-list
services. That framework mandates the use of opt-in lists, which services. That framework mandates the use of opt-in lists, which
are a form of consent-based communications. The reader can find are a form of consent-based communications. The reader can find
an analysis on how a consent-based framework help alleviating an analysis on how a consent-based framework helps alleviate
spam-related problems in [9]. spam-related problems in [9].
3. Requirements 3. Requirements
The following identify requirements for a solution that provides The following identify requirements for a solution that provides
consent-based communications in SIP. A relay is defined as any SIP consent-based communications in SIP. A relay is defined as any SIP
server, be it a proxy, B2BUA (Back-to-Back User Agent), or some server, be it a proxy, Back-to-Back User Agent (B2BUA), or some
hybrid, which receives a request and translates the request URI into hybrid, that receives a request and translates the request URI into
one or more next hop URIs to which it then delivers a request. one or more next-hop URIs to which it then delivers a request.
REQ 1: The solution must keep relays from delivering a SIP request to REQ 1: The solution must keep relays from delivering a SIP request
a recipient unless the recipient has explicitly granted permission to a recipient unless the recipient has explicitly granted
to the relay using appropriately authenticated messages. permission to the relay using appropriately authenticated
messages.
REQ 2: The solution shall prevent relays from generating more than REQ 2: The solution shall prevent relays from generating more than
one outbound request in response to an inbound request, unless one outbound request in response to an inbound request, unless
permission to do so has been granted by the resource to whom the permission to do so has been granted by the resource to whom the
outbound request was to be targeted. This requirement avoids the outbound request was to be targeted. This requirement avoids the
consent mechanism itself becoming the focus of DoS attacks. consent mechanism itself becoming the focus of DoS attacks.
REQ 3: The permissions shall be capable of specifying that messages REQ 3: The permissions shall be capable of specifying that messages
from a specific user, identified by a SIP URI that is an Address- from a specific user, identified by a SIP URI that is an Address-
of-Record (AOR), are permitted. of-Record (AOR), are permitted.
skipping to change at page 6, line 6 skipping to change at page 5, line 10
from domain A, but not from domain B. from domain A, but not from domain B.
REQ 5: It shall be possible for a user to revoke permissions at any REQ 5: It shall be possible for a user to revoke permissions at any
time. time.
REQ 6: It shall not be required for a user or user agent to store 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 information in order to be able to revoke permissions that were
previously granted for a relay resource. previously granted for a relay resource.
REQ 7: The solution shall work in an inter-domain context, without REQ 7: The solution shall work in an inter-domain context, without
requiring pre-established relationships between domains. requiring preestablished relationships between domains.
REQ 8: The solution shall work for all current and future SIP REQ 8: The solution shall work for all current and future SIP
methods. methods.
REQ 9: The solution shall be applicable to forking proxies. REQ 9: The solution shall be applicable to forking proxies.
REQ 10: The solution shall be applicable to URI-list services, such REQ 10: The solution shall be applicable to URI-list services, such
as resource list servers [5], MESSAGE URI-list services [7], and as resource list servers [5], MESSAGE URI-list services [7], and
conference servers performing dial-out functions [8]. conference servers performing dial-out functions [8].
REQ 11: In SIP, URI-lists can be stored on the URI-list server or 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 provided in a SIP request. The consent framework must work in
both cases. both cases.
REQ 12: The solution shall allow anonymous communications, as long as REQ 12: The solution shall allow anonymous communications, as long
the recipient is willing to accept anonymous communications. as the recipient is willing to accept anonymous communications.
REQ 13: If the recipient of a request wishes to be anonymous with REQ 13: If the recipient of a request wishes to be anonymous with
respect to the original sender, it must be possible for the respect to the original sender, it must be possible for the
recipient to grant permission for the sender without the original recipient to grant permission for the sender without the original
sender learning the recipient's identity. sender learning the recipient's identity.
REQ 14: The solution shall prevent against attacks that seek to REQ 14: The solution shall prevent attacks that seek to undermine
undermine the underlying goal of consent. That is, it should not the underlying goal of consent. That is, it should not be
be possible to "fool" the system into delivering a request for possible to "fool" the system into delivering a request for which
which permission was not, in fact, granted. permission was not, in fact, granted.
REQ 15: The solution shall not require the recipient of the REQ 15: The solution shall not require the recipient of the
communications to be connected to the network at the time communications to be connected to the network at the time
communications is attempted. communications are attempted.
REQ 16: The solution shall not require the sender of a SIP request to REQ 16: The solution shall not require the sender of a SIP request
be connected at the time that a recipient provides permission. to be connected at the time that a recipient provides permission.
REQ 17: The solution should scale to Internet-wide deployment. REQ 17: The solution should scale to Internet-wide deployment.
4. Security Considerations 4. Security Considerations
Security has been discussed throughout this document. Security has been discussed throughout this document.
4.1. IANA Considerations
This document does not require the IANA to take any actions
5. References 5. References
5.1. Normative References 5.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002. (SIP): Locating SIP Servers", RFC 3263, June 2002.
[3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002. Instant Messaging", RFC 3428, December 2002.
5.2. Informational References 5.2. Informational References
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[5] Camarillo, G. and A. Roach, "Framework and Security [5] Camarillo, G. and A.B. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) Uniform Considerations for Session Initiation Protocol (SIP) Uniform
Resource Identifier (URI)-List Services", Resource Identifier (URI)-List Services", Work in Progress,
draft-ietf-sipping-uri-services-04 (work in progress), January 2006.
October 2005.
[6] Roach, A., Rosenberg, J., and B. Campbell, "A Session Initiation [6] Roach, A.B., Rosenberg, J., and B. Campbell, "A Session
Protocol (SIP) Event Notification Extension for Resource Initiation Protocol (SIP) Event Notification Extension for
Lists", draft-ietf-simple-event-list-07 (work in progress), Resource Lists", Work in Progress, January 2005.
January 2005.
[7] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE [7] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in the Session Initiation Protocol (SIP)", Requests in the Session Initiation Protocol (SIP)", Work in
draft-ietf-sipping-uri-list-message-04 (work in progress), Progress, February 2006.
October 2005.
[8] Camarillo, G. and A. Johnston, "Conference Establishment Using [8] Camarillo, G. and A. Johnston, "Conference Establishment Using
Request-Contained Lists in the Session Initiation Protocol Request-Contained Lists in the Session Initiation Protocol
(SIP)", draft-ietf-sipping-uri-list-conferencing-04 (work in (SIP)", Work in Progress, February 2006.
progress), October 2005.
[9] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", [9] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam",
draft-ietf-sipping-spam-01 (work in progress), July 2005. Work in Progress, July 2005.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
Email: jdrosen@cisco.com EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Gonzalo Camarillo (editor) Gonzalo Camarillo (Editor)
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com EMail: Gonzalo.Camarillo@ericsson.com
Dean Willis Dean Willis
Cisco Systems Cisco Systems
2200 E. Pres. George Bush Turnpike 2200 E. Pres. George Bush Turnpike
Richardson, TX 75082 Richardson, TX 75082
USA USA
Email: dean.willis@softarmor.com EMail: dean.willis@softarmor.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (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.
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 9, line 29 skipping to change at page 8, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
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.
Copyright Statement
Copyright (C) The Internet Society (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 33 change blocks. 
115 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/