draft-ietf-sipping-consent-reqs-01.txt   draft-ietf-sipping-consent-reqs-02.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: January 19, 2006 G. Camarillo, Ed. Expires: May 30, 2006 G. Camarillo, Ed.
Ericsson Ericsson
D. Willis D. Willis
Cisco Systems Cisco Systems
July 18, 2005 November 26, 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-01.txt draft-ietf-sipping-consent-reqs-02.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 January 19, 2006. This Internet-Draft will expire on May 30, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
5.1 Normative References . . . . . . . . . . . . . . . . . . . 7 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2 Informational References . . . . . . . . . . . . . . . . . 7 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Informational References . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 9 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 [4]) 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 spam and DoS (Denial of
Service) attacks. These problems have plagued email. Fortunately, Service) attacks. These problems have plagued email. Fortunately,
most SIP networks, at time of writing, were not interconnected with most SIP networks, at time of writing, were not interconnected with
each other, and so the incidences of such problems have been lower. each other, and so the incidences of such problems have been lower.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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 "ringing the phone", or creating a screen pop. 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 [3] 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 There are two principal problems that arise when MESSAGE and INVITE
skipping to change at page 5, line 17 skipping to change at page 5, line 17
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 [6].
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.
REQ 1: The solution must keep relays from delivering a SIP message 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
for receipt of that type of message. to the relay.
REQ 2: The solution shall prevent SIP servers from generating more REQ 2: The solution shall prevent relays from generating more than
than one outbound request in response to an inbound request, one outbound request in response to an inbound request, unless
unless permission to do so has been granted by the resource to permission to do so has been granted by the resource to whom the
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 AoR, are permitted.
REQ 4: It shall be possible for a user with a particular AoR to REQ 4: It shall be possible for a user with a particular AoR to
specify permissions separately for each resource that wishes to specify permissions separately for each resource that wishes to
relay requests to that AOR. relay requests to that AOR.
REQ 5: The permissions shall be capable of specifying that only REQ 5: It shall be possible for a user to revoke permissions at any
certain types of messages, such as INVITE or MESSAGE request, are
permitted from a user.
REQ 6: It shall be possible for a user to revoke permissions at any
time. time.
REQ 7: It shall be possible for the users to specify that permissions REQ 6: It shall not be required for a user or user agent to store
are time limited, and must be refreshed after expiration.
REQ 8: 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 9: 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 10: 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 11: The solution shall be applicable to forking proxies. REQ 9: The solution shall be applicable to forking proxies.
REQ 12: 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, MESSAGE URI-list services, and
conference servers performing dial-out functions. conference servers performing dial-out functions.
REQ 13: The solution shall be applicable to both stored and request- REQ 11: The solution shall be applicable to both stored and request-
contained URI-list services. contained URI-list services.
REQ 14: 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 15: If the recipient of requests wishes to be anonymous, it shall REQ 13: If the recipient of requests wishes to be anonymous, it shall
be possible for them to grant permissions without a sender knowing be possible for them to grant permissions without a sender knowing
their identity. their identity.
REQ 16: 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 17: 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 18: The solution shall note require the sender of a REQ 16: The solution shall not require the sender of a SIP request to
communications to be connected at the time that a recipient be connected at the time that a recipient provides permission.
provides permission.
REQ 19: The solution should not, in and of itself, create substantial
additional messaging. Doing so defeats some of the purpose of the
solution.
REQ 20: 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 specification.
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.
5.2 Informational References [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[4] 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] Camarillo, G. and A. Roach, "Requirements and Framework for 5.2. Informational References
Session Initiation Protocol (SIP)Uniform Resource Identifier
(URI)-List Services", draft-ietf-sipping-uri-services-03 (work [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
in progress), April 2005. Notification", RFC 3265, June 2002.
[5] Camarillo, G. and A. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) Uniform
Resource Identifier (URI)-List Services",
draft-ietf-sipping-uri-services-04 (work in progress),
October 2005.
[6] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol [6] 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
 End of changes. 28 change blocks. 
56 lines changed or deleted 50 lines changed or added

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