idnits 2.17.1 draft-ietf-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 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 332. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. 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 (October 15, 2004) is 7133 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '3') (Obsoleted by RFC 6665) == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-00 == Outdated reference: A later version (-01) exists of draft-rosenberg-sipping-spam-00 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 9 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: April 15, 2005 G. Camarillo 4 Ericsson 5 D. Willis 6 dynamicsoft 7 October 15, 2004 9 Requirements for Consent-Based Communications in the Session 10 Initiation Protocol (SIP) 11 draft-ietf-sipping-consent-reqs-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 15, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 The Session Initiation Protocol (SIP) supports communications across 47 many media types, including real-time audio, video, text, instant 48 messaging, and presence. In its current form, it allows session 49 invitations, instant messages, and other requests to be delivered 50 from one party to another without requiring explicit consent of the 51 recipient. Without such consent, it is possible for SIP to be used 52 for malicious purposes, including spam and denial-of-service attacks. 53 This document identifies a set of requirements for extensions to SIP 54 that add consent-based communications. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 6 64 5.2 Informational References . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 66 Intellectual Property and Copyright Statements . . . . . . . . 9 68 1. Introduction 70 The Session Initiation Protocol (SIP) [1] supports communications 71 across many media types, including real-time audio, video, text, 72 instant messaging, and presence. This communication is established 73 by the transmission of various SIP requests (such as INVITE and 74 MESSAGE [4]) from an initiator to the recipient, with whom 75 communication is desired. Although a recipient of such a SIP request 76 can reject the request, and therefore decline the session, a SIP 77 network will deliver a SIP request to the recipient without their 78 explicit consent. 80 Receipt of these requests without explicit consent can cause a number 81 of problems in SIP networks. These include spam and DoS (Denial of 82 Service) attacks. These problems have plagued email. Fortunately, 83 most SIP networks, at time of writing, were not interconnected with 84 each other, and so the incidences of such problems have been lower. 85 However, once such broad interconnection occurs, these problems will 86 arise. Therefore, it is important to address them proactively, 87 before it is too late. 89 This document elaborates on the problems posed by the current open 90 model in which SIP was designed, and then goes on to define a set of 91 requirements for adding a consent framework to SIP. 93 2. Problem Statement 95 In SIP networks designed according to the principles of RFC 3261 [1] 96 and RFC 3263 [2], anyone on the Internet can create and send a SIP 97 request to any other SIP user, by identifying that user with a SIP 98 URI. The SIP network will usually deliver this request to the user 99 identified by that URI. It is possible, of course, for network 100 services, such as call screening, to block such messaging from 101 occuring, but this is not widespread and certainly not a systematic 102 solution to the problem under consideration here. 104 Once the SIP request is received by the recipient, the user agent 105 typically takes some kind of automated action to alert the user about 106 receipt of the message. For INVITE requests, this usually involves 107 "ringing the phone", or creating a screen pop. These indicators 108 frequently convey the subject of the call and the identity of the 109 caller. Due to the real-time nature of the session, these alerts are 110 typically disruptive in nature, so as to get the attention of the 111 user. 113 For MESSAGE requests, the content of the message is usually rendered 114 to the user. 116 SUBSCRIBE [3] requests do not normally get delivered to the user 117 agents residing on a user's devices. Rather, they are normally 118 processed by network-based state agents. The watcher information 119 event package allows a user to find out that such requests were 120 generated for them, affording the user the opportunity to approve or 121 deny the request. As a result, SUBSCRIBE processing, and most 122 notably presence, already has a consent-based operation. 123 Nevertheless, this already-existing consent mechanism for SIP 124 subscriptions does not protect network agents against DoS attacks. 126 There are two principal problems that arise when MESSAGE and INVITE 127 requests can be delivered to user agents directly, without their 128 consent. The first is spam. For INVITE requests, this takes the 129 form of typical "telemarketer" calls. A user might receive a stream 130 of never-ending requests for communications, each of them disrupting 131 the user and demanding their attention. For MESSAGE requests, the 132 problem is even more severe. The user might receive a never-ending 133 stream of screen pops that deliver unwanted, malicious, or otherwise 134 undesired content. 136 The second problem is DoS attacks. SIP proxies provide a convenient 137 relay point for targeting a message to a particular user or IP 138 address, and in particular, relaying to a recipient which is often 139 not directly reachable without usage of the proxy. Worse, some 140 proxies or back to back user agents generate multiple outgoing 141 requests upon receipt of an incoming request. This occurs in forking 142 proxies, and in URI-list services. Examples of URI-list services are 143 subscriptions to resource lists, dial out conference servers, and 144 MESSAGE URI-list services. These SIP elements can be used as an 145 amplifier, allowing the transmission of a single SIP request to flood 146 packets to a single recipient or network. For example, a user can 147 create a buddy list with 100 entries, each of which is a URI of the 148 form "sip:identifier@target-IP", where target-IP is the IP address to 149 which the attack is to be directed. Sending a single SIP SUBSCRIBE 150 request to such a list will cause the resource list server to 151 generate 100 SUBSCRIBE requests, each to the IP address of the 152 target, which does not even need to be a SIP node. 154 Note that the target-IP does not need to be the same in all the 155 URIs in order to attack a single machine. For example, the 156 target-IP addresses may all belong to the same subnetwork, in 157 which case the target of the attack would be the access router of 158 the subnetwork. 160 Though the spam and DoS problems are not quite the same, both can be 161 alleviated by adding a consent-based communications framework to SIP. 162 Such a framework keeps servers from relaying messages to users 163 without their consent. 165 The framework for SIP URI-list services [5] identifies these two 166 problems (spam and DoS attacks) in the context of URI-list 167 services. That framework mandates the use of opt-in lists, which 168 are a form of consent-based communications. The reader can find 169 an analysis on how a consent-based framework help alleviating 170 spam-related problems in [6]. 172 3. Requirements 174 The following identify requirements for a solution that provides 175 consent-based communications in SIP. 177 REQ 1: The solution must keep relays from delivering a SIP message to 178 a recipient unless the recipient has explicitly granted permission 179 for receipt of that type of message. 181 REQ 2: The solution shall prevent SIP servers from generating more 182 than one outbound request in response to an inbound request, 183 unless permission to do so has been granted by the resource to 184 whom the outbound request was to be targeted. 186 REQ 3: The permissions shall be capable of specifying that messages 187 from a specific user, identified by a SIP AoR, are permitted. 189 REQ 4: It shall be possible for a user with a particular AoR to 190 specify permissions separately for each resource that wishes to 191 relay requests to that AOR. 193 REQ 5: The permissions shall be capable of specifying that only 194 certain types of messages, such as INVITE or MESSAGE request, are 195 permitted from a user. 197 REQ 6: It shall be possible for a user to revoke permissions at any 198 time. 200 REQ 7: It shall be possible for the users to specify that permissions 201 are time limited, and must be refreshed after expiration. 203 REQ 8: It shall not be required for a user or user agent to store 204 information in order to be able to revoke permissions that were 205 previously granted for a relay resource. 207 REQ 9: The solution shall work in an inter-domain context, without 208 requiring pre-established relationships between domains. 210 REQ 10: The solution shall work for all current and future SIP 211 methods. 213 REQ 11: The solution shall be applicable to forking proxies. 215 REQ 12: The solution shall be applicable to URI-list services, such 216 as resource list servers, MESSAGE URI-list services, and 217 conference servers performing dial-out functions. 219 REQ 13: The solution shall be applicable to both stored and 220 request-contained URI-list services. 222 REQ 14: The solution shall allow anonymous communications, as long as 223 the recipient is willing to accept anonymous communications. 225 REQ 15: If the recipient of requests wishes to be anonymous, it shall 226 be possible for them to grant permissions without a sender knowing 227 their identity. 229 REQ 16: The solution shall prevent against attacks that seek to 230 undermine the underlying goal of consent. That is, it should not 231 be possible to "fool" the system into delivering a request for 232 which permission was not, in fact, granted. 234 REQ 17: The solution shall not require the recipient of the 235 communications to be connected to the network at the time 236 communications is attempted. 238 REQ 18: The solution shall note require the sender of a 239 communications to be connected at the time that a recipient 240 provides permission. 242 REQ 19: The solution should not, in and of itself, create substantial 243 additional messaging. Doing so defeats some of the purpose of the 244 solution. 246 REQ 20: The solution should scale to Internet-wide deployment. 248 4. Security Considerations 250 Security has been discussed throughout this specification. 252 5. References 254 5.1 Normative References 256 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 257 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 259 Session Initiation Protocol", RFC 3261, June 2002. 261 [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 262 (SIP): Locating SIP Servers", RFC 3263, June 2002. 264 5.2 Informational References 266 [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 267 Notification", RFC 3265, June 2002. 269 [4] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. 270 Gurle, "Session Initiation Protocol (SIP) Extension for Instant 271 Messaging", RFC 3428, December 2002. 273 [5] Camarillo, G., "Requirements and Framework for Session 274 Initiation Protocol (SIP)Uniform Resource Identifier (URI)-List 275 Services", draft-ietf-sipping-uri-services-00 (work in 276 progress), July 2004. 278 [6] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol 279 (SIP) and Spam", draft-rosenberg-sipping-spam-00 (work in 280 progress), July 2004. 282 Authors' Addresses 284 Jonathan Rosenberg 285 dynamicsoft 286 600 Lanidex Plaza 287 Parsippany, NJ 07054 288 US 290 Phone: +1 973 952-5000 291 EMail: jdrosen@dynamicsoft.com 292 URI: http://www.jdrosen.net 294 Gonzalo Camarillo 295 Ericsson 296 Hirsalantie 11 297 Jorvas 02420 298 Finland 300 EMail: Gonzalo.Camarillo@ericsson.com 301 Dean Willis 302 dynamicsoft 303 5100 Tennyson Parkway 304 Suite 1200 305 Plano, TX 75028 306 USA 308 EMail: dean.willis@softarmor.com 310 Intellectual Property Statement 312 The IETF takes no position regarding the validity or scope of any 313 Intellectual Property Rights or other rights that might be claimed to 314 pertain to the implementation or use of the technology described in 315 this document or the extent to which any license under such rights 316 might or might not be available; nor does it represent that it has 317 made any independent effort to identify any such rights. Information 318 on the procedures with respect to rights in RFC documents can be 319 found in BCP 78 and BCP 79. 321 Copies of IPR disclosures made to the IETF Secretariat and any 322 assurances of licenses to be made available, or the result of an 323 attempt made to obtain a general license or permission for the use of 324 such proprietary rights by implementers or users of this 325 specification can be obtained from the IETF on-line IPR repository at 326 http://www.ietf.org/ipr. 328 The IETF invites any interested party to bring to its attention any 329 copyrights, patents or patent applications, or other proprietary 330 rights that may cover technology that may be required to implement 331 this standard. Please address the information to the IETF at 332 ietf-ipr@ietf.org. 334 Disclaimer of Validity 336 This document and the information contained herein are provided on an 337 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 338 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 339 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 340 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 341 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 342 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 344 Copyright Statement 346 Copyright (C) The Internet Society (2004). This document is subject 347 to the rights, licenses and restrictions contained in BCP 78, and 348 except as set forth therein, the authors retain all their rights. 350 Acknowledgment 352 Funding for the RFC Editor function is currently provided by the 353 Internet Society.