draft-ietf-sipping-consent-reqs-02.txt   draft-ietf-sipping-consent-reqs-03.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: May 30, 2006 G. Camarillo, Ed. Expires: June 13, 2006 G. Camarillo, Ed.
Ericsson Ericsson
D. Willis D. Willis
Cisco Systems Cisco Systems
November 26, 2005 December 10, 2005
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-02.txt draft-ietf-sipping-consent-reqs-03.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 May 30, 2006. This Internet-Draft will expire on June 13, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
4.1. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . 7 5.2. Informational References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9 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
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 spam and DoS (Denial of of problems in SIP networks. These include unwanted, unsolicited
Service) attacks. These problems have plagued email. Fortunately, communications (spam) and DoS (Denial of Service) attacks. These
most SIP networks, at time of writing, were not interconnected with problems have plagued email. At the time of this writing, most SIP
each other, and so the incidences of such problems have been lower. services are not interconnected, so the incidence of spam and DoS
However, once such broad interconnection occurs, these problems will attacks directed at SIP services is low compared to the same attacks
arise. Therefore, it is important to address them proactively, on email services. The SIPPING working group believes it is
before it is too late. necessary to address these attacks proactively so the attacks do not
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
skipping to change at page 4, line 27 skipping to change at page 4, line 28
consent. The first is spam. For INVITE requests, this takes the consent. The first is spam. For INVITE requests, this takes the
form of typical "telemarketer" calls. A user might receive a stream form of typical "telemarketer" calls. A user might receive a stream
of never-ending requests for communications, each of them disrupting of never-ending requests for communications, each of them disrupting
the user and demanding their attention. For MESSAGE requests, the the user and demanding their attention. For MESSAGE requests, the
problem is even more severe. The user might receive a never-ending problem is even more severe. The user might receive a never-ending
stream of screen pops that deliver unwanted, malicious, or otherwise stream of screen pops that deliver unwanted, malicious, or otherwise
undesired content. undesired content.
The second problem is DoS attacks. SIP proxies provide a convenient The second problem is DoS attacks. SIP proxies provide a convenient
relay point for targeting a message to a particular user or IP relay point for targeting a message to a particular user or IP
address, and in particular, relaying to a recipient which is often address, and in particular, forwarding to a recipient which is often
not directly reachable without usage of the proxy. Worse, some not directly reachable without usage of the proxy. Some SIP proxy
proxies or back to back user agents generate multiple outgoing servers forward a single request to several instances or contacts for
requests upon receipt of an incoming request. This occurs in forking the same user or resource. This process is called "forking".
proxies, and in URI-list services. Examples of URI-list services are Another type of SIP server provides the SIP URI-list service [5],
subscriptions to resource lists, dial out conference servers, and which sends a new copy of the same request to each recipient in the
MESSAGE URI-list services. These SIP elements can be used as an URI-list. Examples of URI-list services are subscriptions to
amplifier, allowing the transmission of a single SIP request to flood resource lists [6], dial-out conference servers [8], and MESSAGE URI-
packets to a single recipient or network. For example, a user can list services [7] A SIP URI-list service could be used as an
create a buddy list with 100 entries, each of which is a URI of the amplifier, allowing a single SIP request to flood a single target
form "sip:identifier@target-IP", where target-IP is the IP address to 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 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.
skipping to change at page 5, line 10 skipping to change at page 5, line 15
Though the spam and DoS problems are not quite the same, both can be Though the spam and DoS problems are not quite the same, both can be
alleviated by adding a consent-based communications framework to SIP. alleviated by adding a consent-based communications framework to SIP.
Such a framework keeps servers from relaying messages to users Such a framework keeps servers from relaying messages to users
without their consent. without their consent.
The framework for SIP URI-list services [5] identifies these two The framework for SIP URI-list services [5] identifies these two
problems (spam and DoS attacks) in the context of URI-list problems (spam and DoS attacks) 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 [6]. 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. 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
hybrid, which receives a request and translates the request URI into
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.
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.
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 AoR, are permitted. from a specific user, identified by a SIP URI that is an Address-
of-Record (AOR), are permitted.
REQ 4: It shall be possible for a user with a particular AoR to REQ 4: Each recipient AOR must be able to specify permissions
specify permissions separately for each resource that wishes to separately for each SIP service that forwards messages to the
relay requests to that AOR. recipient. For example, Alice may authorize forwarding to her
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 pre-established 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, MESSAGE URI-list services, and as resource list servers [5], MESSAGE URI-list services [7], and
conference servers performing dial-out functions. conference servers performing dial-out functions [8].
REQ 11: The solution shall be applicable to both stored and request- REQ 11: In SIP, URI-lists can be stored on the URI-list server or
contained URI-list services. provided in a SIP request. The consent framework must work in
both cases.
REQ 12: The solution shall allow anonymous communications, as long as REQ 12: The solution shall allow anonymous communications, as long as
the recipient is willing to accept anonymous communications. the recipient is willing to accept anonymous communications.
REQ 13: If the recipient of requests wishes to be anonymous, it shall REQ 13: If the recipient of a request wishes to be anonymous with
be possible for them to grant permissions without a sender knowing respect to the original sender, it must be possible for the
their identity. recipient to grant permission for the sender without the original
sender learning the recipient's identity.
REQ 14: The solution shall prevent against attacks that seek to REQ 14: The solution shall prevent against attacks that seek to
undermine the underlying goal of consent. That is, it should not undermine the underlying goal of consent. That is, it should not
be possible to "fool" the system into delivering a request for be possible to "fool" the system into delivering a request for
which permission was not, in fact, granted. which 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 is 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 to
be connected at the time that a recipient provides permission. 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 specification. Security has been discussed throughout this document.
4.1. IANA Considerations 4.1. IANA Considerations
This document does not require the IANA to take any actions 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.,
skipping to change at page 7, line 20 skipping to change at page 7, line 31
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [4] Roach, A., "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. 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",
draft-ietf-sipping-uri-services-04 (work in progress), draft-ietf-sipping-uri-services-04 (work in progress),
October 2005. October 2005.
[6] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol [6] Roach, A., Rosenberg, J., and B. Campbell, "A Session Initiation
Protocol (SIP) Event Notification Extension for Resource
Lists", draft-ietf-simple-event-list-07 (work in progress),
January 2005.
[7] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-uri-list-message-04 (work in progress),
October 2005.
[8] Camarillo, G. and A. Johnston, "Conference Establishment Using
Request-Contained Lists in the Session Initiation Protocol
(SIP)", draft-ietf-sipping-uri-list-conferencing-04 (work in
progress), October 2005.
[9] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol
(SIP) and Spam", draft-rosenberg-sipping-spam-01 (work in (SIP) and Spam", draft-rosenberg-sipping-spam-01 (work in
progress), October 2004. 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
 End of changes. 16 change blocks. 
39 lines changed or deleted 64 lines changed or added

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