idnits 2.17.1 draft-ietf-sipping-consent-reqs-04.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 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 350. ** 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 (January 17, 2006) is 6645 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 == Outdated reference: A later version (-08) exists of draft-ietf-sipping-uri-list-message-04 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-uri-list-conferencing-04 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-spam-01 Summary: 3 errors (**), 0 flaws (~~), 6 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: July 21, 2006 G. Camarillo, Ed. 5 Ericsson 6 D. Willis 7 Cisco Systems 8 January 17, 2006 10 Requirements for Consent-Based Communications in the Session Initiation 11 Protocol (SIP) 12 draft-ietf-sipping-consent-reqs-04.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 July 21, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. Normative References . . . . . . . . . . . . . . . . . . . 7 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 amplification attacks. 82 These problems have plagued email. At the time of this writing, most 83 SIP services are not interconnected, so the incidence of 84 amplification attacks directed at SIP services is low compared to the 85 same attacks on email services. The SIPPING working group believes 86 it is necessary to address these attacks proactively so the attacks 87 do not become as burdensome as attacks on email have become. 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 delivering an audible alert (e.g., "ringing the phone"), or a visual 108 alert (e.g., creating a screen pop-up window). These indicators 109 frequently convey the subject of the call and the identity of the 110 caller. Due to the real-time nature of the session, these alerts are 111 typically disruptive in nature, so as to get the attention of the 112 user. 114 For MESSAGE requests, the content of the message is usually rendered 115 to the user. 117 SUBSCRIBE [4] requests do not normally get delivered to the user 118 agents residing on a user's devices. Rather, they are normally 119 processed by network-based state agents. The watcher information 120 event package allows a user to find out that such requests were 121 generated for them, affording the user the opportunity to approve or 122 deny the request. As a result, SUBSCRIBE processing, and most 123 notably presence, already has a consent-based operation. 124 Nevertheless, this already-existing consent mechanism for SIP 125 subscriptions does not protect network agents against DoS attacks. 127 A problem that arises when requests can be delivered to user agents 128 directly, without their consent, is amplification attacks. SIP 129 proxies provide a convenient relay point for targeting a message to a 130 particular user or IP address, and in particular, forwarding to a 131 recipient which is often not directly reachable without usage of the 132 proxy. Some SIP proxy servers forward a single request to several 133 instances or contacts for the same user or resource. This process is 134 called "forking". Another type of SIP server provides the SIP URI- 135 list service [5], which sends a new copy of the same request to each 136 recipient in the URI-list. Examples of URI-list services are 137 subscriptions to resource lists [6], dial-out conference servers [8], 138 and MESSAGE URI-list services [7]. A SIP URI-list service could be 139 used as an amplifier, allowing a single SIP request to flood a single 140 target host or network. For example, a user can create a resource 141 list with 100 entries, each of which is a URI of the form 142 "sip:identifier@target-IP", where target-IP is the IP address to 143 which the attack is to be directed. Sending a single SIP SUBSCRIBE 144 request to such a list will cause the resource list server to 145 generate 100 SUBSCRIBE requests, each to the IP address of the 146 target, which does not even need to be a SIP node. 148 Note that the target-IP does not need to be the same in all the 149 URIs in order to attack a single machine. For example, the 150 target-IP addresses may all belong to the same subnetwork, in 151 which case the target of the attack would be the access router of 152 the subnetwork. 154 In addition to launching DoS (Denial of Service) attacks, attackers 155 could also use SIP URI-list servers as amplifiers to deliver spam. 156 For INVITE requests, this takes the form of typical "telemarketer" 157 calls. A user might receive a stream of never-ending requests for 158 communications, each of them disrupting the user and demanding their 159 attention. For MESSAGE requests, the problem is even more severe. 160 The user might receive a never-ending stream of visual alerts (e.g., 161 screen pop-up windows) that deliver unwanted, malicious, or otherwise 162 undesired content. 164 Both amplification attacks related to spam and DoS can be alleviated 165 by adding a consent-based communications framework to SIP. Such a 166 framework keeps servers from relaying messages to users without their 167 consent. 169 The framework for SIP URI-list services [5] identifies 170 amplification attacks as a problem in the context of URI-list 171 services. That framework mandates the use of opt-in lists, which 172 are a form of consent-based communications. The reader can find 173 an analysis on how a consent-based framework help alleviating 174 spam-related problems in [9]. 176 3. Requirements 178 The following identify requirements for a solution that provides 179 consent-based communications in SIP. A relay is defined as any SIP 180 server, be it a proxy, B2BUA (Back-to-Back User Agent), or some 181 hybrid, which receives a request and translates the request URI into 182 one or more next hop URIs to which it then delivers a request. 184 REQ 1: The solution must keep relays from delivering a SIP request to 185 a recipient unless the recipient has explicitly granted permission 186 to the relay using appropriately authenticated messages. 188 REQ 2: The solution shall prevent relays from generating more than 189 one outbound request in response to an inbound request, unless 190 permission to do so has been granted by the resource to whom the 191 outbound request was to be targeted. This requirement avoids the 192 consent mechanism itself becoming the focus of DoS attacks. 194 REQ 3: The permissions shall be capable of specifying that messages 195 from a specific user, identified by a SIP URI that is an Address- 196 of-Record (AOR), are permitted. 198 REQ 4: Each recipient AOR must be able to specify permissions 199 separately for each SIP service that forwards messages to the 200 recipient. For example, Alice may authorize forwarding to her 201 from domain A, but not from domain B. 203 REQ 5: It shall be possible for a user to revoke permissions at any 204 time. 206 REQ 6: It shall not be required for a user or user agent to store 207 information in order to be able to revoke permissions that were 208 previously granted for a relay resource. 210 REQ 7: The solution shall work in an inter-domain context, without 211 requiring pre-established relationships between domains. 213 REQ 8: The solution shall work for all current and future SIP 214 methods. 216 REQ 9: The solution shall be applicable to forking proxies. 218 REQ 10: The solution shall be applicable to URI-list services, such 219 as resource list servers [5], MESSAGE URI-list services [7], and 220 conference servers performing dial-out functions [8]. 222 REQ 11: In SIP, URI-lists can be stored on the URI-list server or 223 provided in a SIP request. The consent framework must work in 224 both cases. 226 REQ 12: The solution shall allow anonymous communications, as long as 227 the recipient is willing to accept anonymous communications. 229 REQ 13: If the recipient of a request wishes to be anonymous with 230 respect to the original sender, it must be possible for the 231 recipient to grant permission for the sender without the original 232 sender learning the recipient's identity. 234 REQ 14: The solution shall prevent against attacks that seek to 235 undermine the underlying goal of consent. That is, it should not 236 be possible to "fool" the system into delivering a request for 237 which permission was not, in fact, granted. 239 REQ 15: The solution shall not require the recipient of the 240 communications to be connected to the network at the time 241 communications is attempted. 243 REQ 16: The solution shall not require the sender of a SIP request to 244 be connected at the time that a recipient provides permission. 246 REQ 17: The solution should scale to Internet-wide deployment. 248 4. Security Considerations 250 Security has been discussed throughout this document. 252 4.1. IANA Considerations 254 This document does not require the IANA to take any actions 256 5. References 258 5.1. Normative References 260 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 261 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 262 Session Initiation Protocol", RFC 3261, June 2002. 264 [2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 265 (SIP): Locating SIP Servers", RFC 3263, June 2002. 267 [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 268 D. Gurle, "Session Initiation Protocol (SIP) Extension for 269 Instant Messaging", RFC 3428, December 2002. 271 5.2. Informational References 273 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 274 Notification", RFC 3265, June 2002. 276 [5] Camarillo, G. and A. Roach, "Framework and Security 277 Considerations for Session Initiation Protocol (SIP) Uniform 278 Resource Identifier (URI)-List Services", 279 draft-ietf-sipping-uri-services-04 (work in progress), 280 October 2005. 282 [6] Roach, A., Rosenberg, J., and B. Campbell, "A Session Initiation 283 Protocol (SIP) Event Notification Extension for Resource 284 Lists", draft-ietf-simple-event-list-07 (work in progress), 285 January 2005. 287 [7] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE 288 Requests in the Session Initiation Protocol (SIP)", 289 draft-ietf-sipping-uri-list-message-04 (work in progress), 290 October 2005. 292 [8] Camarillo, G. and A. Johnston, "Conference Establishment Using 293 Request-Contained Lists in the Session Initiation Protocol 294 (SIP)", draft-ietf-sipping-uri-list-conferencing-04 (work in 295 progress), October 2005. 297 [9] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", 298 draft-ietf-sipping-spam-01 (work in progress), July 2005. 300 Authors' Addresses 302 Jonathan Rosenberg 303 Cisco Systems 304 600 Lanidex Plaza 305 Parsippany, NJ 07054 306 US 308 Phone: +1 973 952-5000 309 Email: jdrosen@cisco.com 310 URI: http://www.jdrosen.net 312 Gonzalo Camarillo (editor) 313 Ericsson 314 Hirsalantie 11 315 Jorvas 02420 316 Finland 318 Email: Gonzalo.Camarillo@ericsson.com 320 Dean Willis 321 Cisco Systems 322 2200 E. Pres. George Bush Turnpike 323 Richardson, TX 75082 324 USA 326 Email: dean.willis@softarmor.com 328 Intellectual Property Statement 330 The IETF takes no position regarding the validity or scope of any 331 Intellectual Property Rights or other rights that might be claimed to 332 pertain to the implementation or use of the technology described in 333 this document or the extent to which any license under such rights 334 might or might not be available; nor does it represent that it has 335 made any independent effort to identify any such rights. Information 336 on the procedures with respect to rights in RFC documents can be 337 found in BCP 78 and BCP 79. 339 Copies of IPR disclosures made to the IETF Secretariat and any 340 assurances of licenses to be made available, or the result of an 341 attempt made to obtain a general license or permission for the use of 342 such proprietary rights by implementers or users of this 343 specification can be obtained from the IETF on-line IPR repository at 344 http://www.ietf.org/ipr. 346 The IETF invites any interested party to bring to its attention any 347 copyrights, patents or patent applications, or other proprietary 348 rights that may cover technology that may be required to implement 349 this standard. Please address the information to the IETF at 350 ietf-ipr@ietf.org. 352 Disclaimer of Validity 354 This document and the information contained herein are provided on an 355 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 356 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 357 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 358 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 359 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 360 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 362 Copyright Statement 364 Copyright (C) The Internet Society (2006). This document is subject 365 to the rights, licenses and restrictions contained in BCP 78, and 366 except as set forth therein, the authors retain all their rights. 368 Acknowledgment 370 Funding for the RFC Editor function is currently provided by the 371 Internet Society.