draft-ietf-sipping-consent-reqs-03.txt   draft-ietf-sipping-consent-reqs-04.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: June 13, 2006 G. Camarillo, Ed. Expires: July 21, 2006 G. Camarillo, Ed.
Ericsson Ericsson
D. Willis D. Willis
Cisco Systems Cisco Systems
December 10, 2005 January 17, 2006
Requirements for Consent-Based Communications in the Session Initiation Requirements for Consent-Based Communications in the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipping-consent-reqs-03.txt draft-ietf-sipping-consent-reqs-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 13, 2006. This Internet-Draft will expire on July 21, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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.
skipping to change at page 3, line 18 skipping to change at page 3, line 18
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
network will deliver a SIP request to the recipient without their network will deliver a SIP request to the recipient without their
explicit consent. explicit consent.
Receipt of these requests without explicit consent can cause a number Receipt of these requests without explicit consent can cause a number
of problems in SIP networks. These include unwanted, unsolicited of problems in SIP networks. These include amplification attacks.
communications (spam) and DoS (Denial of Service) attacks. These These problems have plagued email. At the time of this writing, most
problems have plagued email. At the time of this writing, most SIP SIP services are not interconnected, so the incidence of
services are not interconnected, so the incidence of spam and DoS amplification attacks directed at SIP services is low compared to the
attacks directed at SIP services is low compared to the same attacks same attacks on email services. The SIPPING working group believes
on email services. The SIPPING working group believes it is it is necessary to address these attacks proactively so the attacks
necessary to address these attacks proactively so the attacks do not do not become as burdensome as attacks on email have become.
become as burdensome as attacks on email have become.
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 URI. The SIP network will usually deliver this request to the user
identified by that URI. It is possible, of course, for network identified by that URI. It is possible, of course, for network
services, such as call screening, to block such messaging from services, such as call screening, to block such messaging from
occuring, but this is not widespread and certainly not a systematic occuring, but this is not widespread and certainly not a systematic
solution to the problem under consideration here. 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
"ringing the phone", or creating a screen pop. These indicators 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 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.
For MESSAGE requests, the content of the message is usually rendered For MESSAGE requests, the content of the message is usually rendered
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 DoS attacks.
There are two principal problems that arise when MESSAGE and INVITE A problem that arises when requests can be delivered to user agents
requests can be delivered to user agents directly, without their directly, without their consent, is amplification attacks. SIP
consent. The first is spam. For INVITE requests, this takes the proxies provide a convenient relay point for targeting a message to a
form of typical "telemarketer" calls. A user might receive a stream particular user or IP address, and in particular, forwarding to a
of never-ending requests for communications, each of them disrupting recipient which is often not directly reachable without usage of the
the user and demanding their attention. For MESSAGE requests, the proxy. Some SIP proxy servers forward a single request to several
problem is even more severe. The user might receive a never-ending instances or contacts for the same user or resource. This process is
stream of screen pops that deliver unwanted, malicious, or otherwise called "forking". Another type of SIP server provides the SIP URI-
undesired content. 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
The second problem is DoS attacks. SIP proxies provide a convenient subscriptions to resource lists [6], dial-out conference servers [8],
relay point for targeting a message to a particular user or IP and MESSAGE URI-list services [7]. A SIP URI-list service could be
address, and in particular, forwarding to a recipient which is often used as an amplifier, allowing a single SIP request to flood a single
not directly reachable without usage of the proxy. Some SIP proxy target host or network. For example, a user can create a resource
servers forward a single request to several instances or contacts for list with 100 entries, each of which is a URI of the form
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 "sip:identifier@target-IP", where target-IP is the IP address to
which the attack is to be directed. Sending a single SIP SUBSCRIBE which the attack is to be directed. Sending a single SIP SUBSCRIBE
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.
Though the spam and DoS problems are not quite the same, both can be In addition to launching DoS (Denial of Service) attacks, attackers
alleviated by adding a consent-based communications framework to SIP. could also use SIP URI-list servers as amplifiers to deliver spam.
Such a framework keeps servers from relaying messages to users For INVITE requests, this takes the form of typical "telemarketer"
without their consent. 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 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.
The framework for SIP URI-list services [5] identifies these two Both amplification attacks related to spam and DoS can be alleviated
problems (spam and DoS attacks) in the context of URI-list by adding a consent-based communications framework to SIP. Such a
framework keeps servers from relaying messages to users without their
consent.
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 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 help alleviating
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, B2BUA (Back-to-Back User Agent), or some
hybrid, which receives a request and translates the request URI into hybrid, which 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 to
a recipient unless the recipient has explicitly granted permission a recipient unless the recipient has explicitly granted permission
to the relay. 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. outbound request was to be targeted. This requirement avoids the
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.
REQ 4: Each recipient AOR must be able to specify permissions REQ 4: Each recipient AOR must be able to specify permissions
separately for each SIP service that forwards messages to the separately for each SIP service that forwards messages to the
recipient. For example, Alice may authorize forwarding to her recipient. For example, Alice may authorize forwarding to her
from domain A, but not from domain B. from domain A, but not from domain B.
skipping to change at page 7, line 46 skipping to change at page 7, line 46
[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)",
draft-ietf-sipping-uri-list-message-04 (work in progress), draft-ietf-sipping-uri-list-message-04 (work in progress),
October 2005. 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)", draft-ietf-sipping-uri-list-conferencing-04 (work in
progress), October 2005. progress), October 2005.
[9] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol [9] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam",
(SIP) and Spam", draft-rosenberg-sipping-spam-01 (work in draft-ietf-sipping-spam-01 (work in progress), July 2005.
progress), October 2004.
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
skipping to change at page 9, line 41 skipping to change at page 9, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 14 change blocks. 
50 lines changed or deleted 51 lines changed or added

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