idnits 2.17.1 draft-rosenberg-sipping-consent-reqs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 315. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 331), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2004) is 7194 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '3') (Obsoleted by RFC 6665) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIP J. Rosenberg 2 Internet-Draft dynamicsoft 3 Expires: January 6, 2005 G. Camarillo 4 Ericsson 5 D. Willis 6 dynamicsoft 7 July 8, 2004 9 Requirements for Consent-Based Communications in the Session 10 Initiation Protocol (SIP) 11 draft-rosenberg-sipping-consent-reqs-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 6, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 The Session Initiation Protocol (SIP) supports communications across 44 many media types, including real-time audio, video, text, instant 45 messaging, and presence. In its current form, it allows session 46 invitations, instant messages, and other requests to be delivered 47 from one party to another without requiring explicit consent of the 48 recipient. Without such consent, it is possible for SIP to be used 49 for malicious purposes, including spam and denial-of-service attacks. 50 This document identifies a set of requirements for extensions to SIP 51 that add consent-based communications. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 5. Informative References . . . . . . . . . . . . . . . . . . . . 6 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 61 Intellectual Property and Copyright Statements . . . . . . . . 8 63 1. Introduction 65 The Session Initiation Protocol (SIP) [1] supports communications 66 across many media types, including real-time audio, video, text, 67 instant messaging, and presence. This communication is established by 68 the transmission of various SIP requests (such as INVITE and MESSAGE 69 [4]) from an initiator to the recipient, with whom communication is 70 desired. Although a recipient of such a SIP request can reject the 71 request, and therefore decline the session, a SIP network will 72 deliver a SIP request to the recipient without their explicit 73 consent. 75 Receipt of these requests without explicit consent can cause a number 76 of problems in SIP networks. These include spam and DoS (Denial of 77 Service) attacks. These problems have plagued email. Fortunately, 78 most SIP networks, at time of writing, were not interconnected with 79 each other, and so the incidences of such problems have been lower. 80 However, once such broad interconnection occurs, these problems will 81 arise. Therefore, it is important to address them proactively, before 82 it is too late. 84 This document elaborates on the problems posed by the current open 85 model in which SIP was designed, and then goes on to define a set of 86 requirements for adding a consent framework to SIP. 88 2. Problem Statement 90 In SIP networks designed according to the principles of RFC 3261 [1] 91 and RFC 3263 [2], anyone on the Internet can create and send a SIP 92 request to any other SIP user, by identifying that user with a SIP 93 URI. The SIP network will usually deliver this request to the user 94 identified by that URI. It is possible, of course, for network 95 services, such as call screening, to block such messaging from 96 occuring, but this is not widespread and certainly not a systematic 97 solution to the problem under consideration here. 99 Once the SIP request is received by the recipient, the user agent 100 typically takes some kind of automated action to alert the user about 101 receipt of the message. For INVITE requests, this usually involves 102 "ringing the phone", or creating a screen pop. These indicators 103 frequently convey the subject of the call and the identity of the 104 caller. Due to the real-time nature of the session, these alerts are 105 typically disruptive in nature, so as to get the attention of the 106 user. 108 For MESSAGE requests, the content of the message is usually rendered 109 to the user. 111 SUBSCRIBE [3] requests do not normally get delivered to the user 112 agents residing on a user's devices. Rather, they are normally 113 processed by network-based state agents. The watcher information 114 event package allows a user to find out that such requests were 115 generated for them, affording the user the opportunity to approve or 116 deny the request. As a result, SUBSCRIBE processing, and most notably 117 presence, already has a consent-based operation. Nevertheless, this 118 already-existing consent mechanism for SIP subscriptions does not 119 protect network agents against DoS attacks. 121 There are two principal problems that arise when MESSAGE and INVITE 122 requests can be delivered to user agents directly, without their 123 consent. The first is spam. For INVITE requests, this takes the form 124 of typical "telemarketer" calls. A user might receive a stream of 125 never-ending requests for communications, each of them disrupting the 126 user and demanding their attention. For MESSAGE requests, the problem 127 is even more severe. The user might receive a never-ending stream of 128 screen pops that deliver unwanted, malicious, or otherwise undesired 129 content. 131 The second problem is DoS attacks. SIP proxies provide a convenient 132 relay point for targeting a message to a particular user or IP 133 address, and in particular, relaying to a recipient which is often 134 not directly reachable without usage of the proxy. Worse, some 135 proxies or back to back user agents generate multiple outgoing 136 requests upon receipt of an incoming request. This occurs in forking 137 proxies, and in URI-list services. Examples of URI-list services are 138 subscriptions to resource lists, dial out conference servers, and 139 MESSAGE URI-list services. These SIP elements can be used as an 140 amplifier, allowing the transmission of a single SIP request to flood 141 packets to a single recipient or network. For example, a user can 142 create a buddy list with 100 entries, each of which is a URI of the 143 form "sip:identifier@target-IP", where target-IP is the IP address to 144 which the attack is to be directed. Sending a single SIP SUBSCRIBE 145 request to such a list will cause the resource list server to 146 generate 100 SUBSCRIBE requests, each to the IP address of the 147 target, which does not even need to be a SIP node. 149 Note that the target-IP does not need to be the same in all the 150 URIs in order to attack a single machine. For example, the 151 target-IP addresses may all belong to the same subnetwork, in 152 which case the target of the attack would be the access router of 153 the subnetwork. 155 Though the spam and DoS problems are not quite the same, both can be 156 alleviated by adding a consent-based communications framework to SIP. 157 Such a framework keeps servers from relaying messages to users 158 without their consent. 160 The framework for SIP URI-list services 161 [draft-ietf-sipping-uri-services-00.txt] identifies these two 162 problems (spam and DoS attacks) in the context of URI-list 163 services. That framework mandates the use of opt-in lists, which 164 are a form of consent-based communications. The reader can find an 165 analysis on how a consent-based framework help alleviating 166 spam-related problems in [draft-rosenberg-sipping-spam-00.txt] 168 3. Requirements 170 The following identify requirements for a solution that provides 171 consent-based communications in SIP. 173 REQ 1: The solution must keep relays from delivering a SIP message to 174 a recipient unless the recipient has explicitly granted permission 175 for receipt of that type of message. 177 REQ 2: The solution shall prevent SIP servers from generating more 178 than one outbound request in response to an inbound request, 179 unless permission to do so has been granted by the resource to 180 whom the outbound request was to be targeted. 182 REQ 3: The permissions shall be capable of specifying that messages 183 from a specific user, identified by a SIP AoR, are permitted. 185 REQ 4: It shall be possible for a user with a particular AoR to 186 specify permissions separately for each resource that wishes to 187 relay requests to that AOR. 189 REQ 5: The permissions shall be capable of specifying that only 190 certain types of messages, such as INVITE or MESSAGE request, are 191 permitted from a user. 193 REQ 6: It shall be possible for a user to revoke permissions at any 194 time. 196 REQ 7: It shall be possible for the users to specify that permissions 197 are time limited, and must be refreshed after expiration. 199 REQ 8: It shall not be required for a user or user agent to store 200 information in order to be able to revoke permissions that were 201 previously granted for a relay resource. 203 REQ 9: The solution shall work in an inter-domain context, without 204 requiring pre-established relationships between domains. 206 REQ 10: The solution shall work for all current and future SIP 207 methods. 209 REQ 11: The solution shall be applicable to forking proxies. 211 REQ 12: The solution shall be applicable to URI-list services, such 212 as resource list servers, MESSAGE URI-list services, and 213 conference servers performing dial-out functions. 215 REQ 13: The solution shall be applicable to both stored and 216 request-contained URI-list services. 218 REQ 14: The solution shall allow anonymous communications, as long as 219 the recipient is willing to accept anonymous communications. 221 REQ 15: If the recipient of requests wishes to be anonymous, it shall 222 be possible for them to grant permissions without a sender knowing 223 their identity. 225 REQ 16: The solution shall prevent against attacks that seek to 226 undermine the underlying goal of consent. That is, it should not 227 be possible to "fool" the system into delivering a request for 228 which permission was not, in fact, granted. 230 REQ 17: The solution shall not require the recipient of the 231 communications to be connected to the network at the time 232 communications is attempted. 234 REQ 18: The solution shall note require the sender of a 235 communications to be connected at the time that a recipient 236 provides permission. 238 REQ 19: The solution should not, in and of itself, create substantial 239 additional messaging. Doing so defeats some of the purpose of the 240 solution. 242 REQ 20: The solution should scale to Internet-wide deployment. 244 4. Security Considerations 246 Security has been discussed throughout this specification. 248 5 Informative References 250 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 251 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 252 Session Initiation Protocol", RFC 3261, June 2002. 254 [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 255 (SIP): Locating SIP Servers", RFC 3263, June 2002. 257 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 258 Notification", RFC 3265, June 2002. 260 [4] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. 261 Gurle, "Session Initiation Protocol (SIP) Extension for Instant 262 Messaging", RFC 3428, December 2002. 264 Authors' Addresses 266 Jonathan Rosenberg 267 dynamicsoft 268 600 Lanidex Plaza 269 Parsippany, NJ 07054 270 US 272 Phone: +1 973 952-5000 273 EMail: jdrosen@dynamicsoft.com 274 URI: http://www.jdrosen.net 276 Gonzalo Camarillo 277 Ericsson 278 Hirsalantie 11 279 Jorvas 02420 280 Finland 282 EMail: Gonzalo.Camarillo@ericsson.com 284 Dean Willis 285 dynamicsoft 286 5100 Tennyson Parkway 287 Suite 1200 288 Plano, TX 75028 289 USA 291 EMail: dean.willis@softarmor.com 293 Intellectual Property Statement 295 The IETF takes no position regarding the validity or scope of any 296 Intellectual Property Rights or other rights that might be claimed to 297 pertain to the implementation or use of the technology described in 298 this document or the extent to which any license under such rights 299 might or might not be available; nor does it represent that it has 300 made any independent effort to identify any such rights. Information 301 on the IETF's procedures with respect to rights in IETF Documents can 302 be found in BCP 78 and BCP 79. 304 Copies of IPR disclosures made to the IETF Secretariat and any 305 assurances of licenses to be made available, or the result of an 306 attempt made to obtain a general license or permission for the use of 307 such proprietary rights by implementers or users of this 308 specification can be obtained from the IETF on-line IPR repository at 309 http://www.ietf.org/ipr. 311 The IETF invites any interested party to bring to its attention any 312 copyrights, patents or patent applications, or other proprietary 313 rights that may cover technology that may be required to implement 314 this standard. Please address the information to the IETF at 315 ietf-ipr@ietf.org. 317 Disclaimer of Validity 319 This document and the information contained herein are provided on an 320 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 321 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 322 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 323 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 324 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 325 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 327 Copyright Statement 329 Copyright (C) The Internet Society (2004). This document is subject 330 to the rights, licenses and restrictions contained in BCP 78, and 331 except as set forth therein, the authors retain all their rights. 333 Acknowledgment 335 Funding for the RFC Editor function is currently provided by the 336 Internet Society.