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