idnits 2.17.1 draft-ietf-sipping-consent-reqs-02.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 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 324. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (November 26, 2005) is 6727 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. '4') (Obsoleted by RFC 6665) == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-04 Summary: 3 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: May 30, 2006 G. Camarillo, Ed. 5 Ericsson 6 D. Willis 7 Cisco Systems 8 November 26, 2005 10 Requirements for Consent-Based Communications in the Session Initiation 11 Protocol (SIP) 12 draft-ietf-sipping-consent-reqs-02.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 May 30, 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 4.1. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 62 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 5.2. Informational References . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 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 [3]) 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 [4] 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 request to 178 a recipient unless the recipient has explicitly granted permission 179 to the relay. 181 REQ 2: The solution shall prevent relays from generating more than 182 one outbound request in response to an inbound request, unless 183 permission to do so has been granted by the resource to whom the 184 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: It shall be possible for a user to revoke permissions at any 194 time. 196 REQ 6: It shall not be required for a user or user agent to store 197 information in order to be able to revoke permissions that were 198 previously granted for a relay resource. 200 REQ 7: The solution shall work in an inter-domain context, without 201 requiring pre-established relationships between domains. 203 REQ 8: The solution shall work for all current and future SIP 204 methods. 206 REQ 9: The solution shall be applicable to forking proxies. 208 REQ 10: The solution shall be applicable to URI-list services, such 209 as resource list servers, MESSAGE URI-list services, and 210 conference servers performing dial-out functions. 212 REQ 11: The solution shall be applicable to both stored and request- 213 contained URI-list services. 215 REQ 12: The solution shall allow anonymous communications, as long as 216 the recipient is willing to accept anonymous communications. 218 REQ 13: If the recipient of requests wishes to be anonymous, it shall 219 be possible for them to grant permissions without a sender knowing 220 their identity. 222 REQ 14: The solution shall prevent against attacks that seek to 223 undermine the underlying goal of consent. That is, it should not 224 be possible to "fool" the system into delivering a request for 225 which permission was not, in fact, granted. 227 REQ 15: The solution shall not require the recipient of the 228 communications to be connected to the network at the time 229 communications is attempted. 231 REQ 16: The solution shall not require the sender of a SIP request to 232 be connected at the time that a recipient provides permission. 234 REQ 17: The solution should scale to Internet-wide deployment. 236 4. Security Considerations 238 Security has been discussed throughout this specification. 240 4.1. IANA Considerations 242 This document does not require the IANA to take any actions 244 5. References 246 5.1. Normative References 248 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 249 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 250 Session Initiation Protocol", RFC 3261, June 2002. 252 [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 253 (SIP): Locating SIP Servers", RFC 3263, June 2002. 255 [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 256 D. Gurle, "Session Initiation Protocol (SIP) Extension for 257 Instant Messaging", RFC 3428, December 2002. 259 5.2. Informational References 261 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 262 Notification", RFC 3265, June 2002. 264 [5] Camarillo, G. and A. Roach, "Framework and Security 265 Considerations for Session Initiation Protocol (SIP) Uniform 266 Resource Identifier (URI)-List Services", 267 draft-ietf-sipping-uri-services-04 (work in progress), 268 October 2005. 270 [6] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol 271 (SIP) and Spam", draft-rosenberg-sipping-spam-01 (work in 272 progress), October 2004. 274 Authors' Addresses 276 Jonathan Rosenberg 277 Cisco Systems 278 600 Lanidex Plaza 279 Parsippany, NJ 07054 280 US 282 Phone: +1 973 952-5000 283 Email: jdrosen@cisco.com 284 URI: http://www.jdrosen.net 286 Gonzalo Camarillo (editor) 287 Ericsson 288 Hirsalantie 11 289 Jorvas 02420 290 Finland 292 Email: Gonzalo.Camarillo@ericsson.com 294 Dean Willis 295 Cisco Systems 296 2200 E. Pres. George Bush Turnpike 297 Richardson, TX 75082 298 USA 300 Email: dean.willis@softarmor.com 302 Intellectual Property Statement 304 The IETF takes no position regarding the validity or scope of any 305 Intellectual Property Rights or other rights that might be claimed to 306 pertain to the implementation or use of the technology described in 307 this document or the extent to which any license under such rights 308 might or might not be available; nor does it represent that it has 309 made any independent effort to identify any such rights. Information 310 on the procedures with respect to rights in RFC documents can be 311 found in BCP 78 and BCP 79. 313 Copies of IPR disclosures made to the IETF Secretariat and any 314 assurances of licenses to be made available, or the result of an 315 attempt made to obtain a general license or permission for the use of 316 such proprietary rights by implementers or users of this 317 specification can be obtained from the IETF on-line IPR repository at 318 http://www.ietf.org/ipr. 320 The IETF invites any interested party to bring to its attention any 321 copyrights, patents or patent applications, or other proprietary 322 rights that may cover technology that may be required to implement 323 this standard. Please address the information to the IETF at 324 ietf-ipr@ietf.org. 326 Disclaimer of Validity 328 This document and the information contained herein are provided on an 329 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 330 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 331 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 332 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 333 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 334 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 336 Copyright Statement 338 Copyright (C) The Internet Society (2005). This document is subject 339 to the rights, licenses and restrictions contained in BCP 78, and 340 except as set forth therein, the authors retain all their rights. 342 Acknowledgment 344 Funding for the RFC Editor function is currently provided by the 345 Internet Society.