idnits 2.17.1 draft-rosenberg-sipping-spam-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 884. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 861. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 874. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 890), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 732: '... messaging MUST use the technique...' 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 11, 2004) is 7229 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) == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-06 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '4') (Obsoleted by RFC 6665) == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-02 == Outdated reference: A later version (-10) exists of draft-ietf-simple-presence-rules-00 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-app-interaction-framework-01 == Outdated reference: A later version (-08) exists of draft-ietf-sipping-kpml-03 == Outdated reference: A later version (-03) exists of draft-ietf-marid-core-01 == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-02 Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING J. Rosenberg 2 Internet-Draft dynamicsoft 3 Expires: January 9, 2005 C. Jennings 4 Cisco 5 July 11, 2004 7 The Session Initiation Protocol (SIP) and Spam 8 draft-rosenberg-sipping-spam-00 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 9, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 Spam, defined as the transmission of bulk unsolicited messages, has 42 plagued Internet email. Unfortunately, spam is not limited to email. 43 It can affect any system that enables user to user communications. 44 The Session Initiation Protocol (SIP) defines a system for user to 45 user multimedia communications. Therefore, it is susceptible to 46 spam, just as email is. In this document, we analyze the problem of 47 spam in SIP. We first identify the ways in which the problem is the 48 same and the ways in which it is different from email. We then 49 examine the various possible solutions that have been discussed for 50 email and consider their applicability to SIP. Discussions on this 51 draft should be directed at sipping@ietf.org. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Problem Definition . . . . . . . . . . . . . . . . . . . . . 3 57 2.1 Call Spam . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2 IM Spam . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.3 Presence Spam . . . . . . . . . . . . . . . . . . . . . . 7 60 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1 Content Filtering . . . . . . . . . . . . . . . . . . . . 7 62 3.2 Black Lists . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.3 White Lists . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.4 Consent-Based Communications . . . . . . . . . . . . . . . 9 65 3.5 Turing Tests . . . . . . . . . . . . . . . . . . . . . . . 10 66 3.6 Computational Puzzles . . . . . . . . . . . . . . . . . . 11 67 3.7 Payments at Risk . . . . . . . . . . . . . . . . . . . . . 12 68 3.8 Legal Action . . . . . . . . . . . . . . . . . . . . . . . 13 69 3.9 Circles of Trust . . . . . . . . . . . . . . . . . . . . . 13 70 3.10 Centralized SIP Providers . . . . . . . . . . . . . . . 14 71 3.11 Sender Checks . . . . . . . . . . . . . . . . . . . . . 15 72 4. Authenticated Identity in SIP . . . . . . . . . . . . . . . 15 73 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 16 74 6. Security Considerations . . . . . . . . . . . . . . . . . . 16 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 76 8. Informative References . . . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 78 Intellectual Property and Copyright Statements . . . . . . . 20 80 1. Introduction 82 Spam, defined as the transmission of bulk unsolicited email, has been 83 a plague on the Internet email system, rendering it nearly useless. 84 Many solutions have been documented and deployed to counter the 85 problem. None of these solutions is ideal. However, one thing is 86 clear: the spam problem would be much less significant had solutions 87 been deployed ubiquitously before the problem became widespread. 89 The Session Initiation Protocol (SIP) [2] is used for multimedia 90 communications between users, including voice, video, instant 91 messaging and presence. Although it has seen widespread deployment, 92 the deployments today have mostly been in disconnected islands. 93 Providers have not yet connected to each other in significant ways, 94 nor have they yet opened up access so as to allow receipt of SIP 95 messaging from the open Internet. Possibly as a result of this, SIP 96 networks have not yet been the target of any significant amount of 97 spam. However, we believe that it is just a matter of time. 99 It is important that the SIP community react now, rather than later, 100 and define and deploy anti-spam measures before the problem arises. 101 This document serves to help frame the problem of spam in SIP and 102 analyze the solution space in order to help determine a path forward. 104 2. Problem Definition 106 The spam problem in email is well understood, and we make no attempt 107 to further elaborate on it here. The question, however, is what is 108 the meaning of spam when applied to SIP? Since SIP covers a broad 109 range of functionality, there appear to be three related but 110 different manifestations: 111 Call Spam: This type of spam is defined as a bulk unsolicited set of 112 session initiation attempts (i.e., INVITE requests), attempting to 113 establish a voice, video, instant messaging [1] or other type of 114 communications session. If the user should answer, the spammer 115 proceeds to relay their message over the real time media. This is 116 the classic telemarketer spam, applied to SIP. 117 IM Spam: This type of spam is similar to email. It is defined as a 118 bulk unsolicited set of instant messages, whose content contains 119 the message that the spammer is seeking to convey. IM spam is 120 most naturally sent using the SIP MESSAGE [3] request. However, 121 any other request which causes content to automatically appear on 122 the user's display will also suffice. That might include INVITE 123 requests with large Subject headers (since the Subject is 124 sometimes rendered to the user), or INVITE requests with text or 125 HTML bodies. 127 Presence Spam: This type of spam is similar to IM spam. It is 128 defined as a bulk unsolicited set of presence requests (i.e., 129 SUBSCRIBE requests [4] for the presence event package [7]), in an 130 attempt to get on the "buddy list" or "white list" of a user in 131 order to send them IM or initiate other forms of communications. 132 Unlike IM spam, presence spam does not actually convey content in 133 the messages. As such, it is not clear how useful or valuable 134 this kind of spam is. 136 There are many other SIP messages that a spammer might send. 137 However, most of the other ones do not result in content being 138 delivered to a user, nor do they seek input from a user. Rather, 139 they are answered by automata. OPTIONS is a good example of this. 140 There is little value for a spammer in sending an OPTIONS request, 141 since it is answered automatically by the UAS. No content is 142 delivered to the user, and they are not consulted. 144 In the sections below, we consider the likelihood of these various 145 forms of SIP spam. This is done in some cases by a rough cost 146 analysis. It should be noted that all of these analyses are 147 approximate, and serve only to give a rough sense of the order of 148 magnitude of the problem. 150 2.1 Call Spam 152 Will call spam occur? That is an important question to answer. 153 Clearly, it does occur in the existing telephone network, in the form 154 of telemarketer calls. Although these calls are annoying, they do 155 not arrive in the same kind of volume as email spam. The difference 156 is cost; it costs more for the spammer to make a phone call than it 157 does to send email. This cost manifests itself in terms of the cost 158 for systems which can perform telemarketer call, and in cost per 159 call. 161 Unfortunately, both of these costs are substantially reduced by SIP. 162 A SIP call spam application is easy to write. It is just a UAC that 163 initiates, in parallel, a large number of calls. If a call connects, 164 the spam application generates an ACK and proceeds to play out a 165 recorded announcement, and then it terminates the call. This kind of 166 application can be built entirely in software, using readily 167 available (and indeed, free) off the shelf components. It can run on 168 a low end PC and requires no special expertise to execute. 170 The cost per call is also substantially reduced. A normal 171 residential phone line allows only one call to be placed at a time. 172 If additional lines are required, a user must purchase more expensive 173 connectivity. Typically, a T1 or T3 would be required for a large 174 volume telemarketing service. That kind of access is very expensive 175 and well beyond the reach of an average user. A T1 line is 176 approximately US $250 per month, and about 1.5 cents per minute for 177 calls. T1 lines used only for outbound calls (such as in this case) 178 are even more expensive than inbound trunks due to the reciprocal 179 termination charges that a provider pays and receives. 181 There are two aspects to the capacity: the call attempt rate, and the 182 number of simultaneous successful calls that can be in progress. A 183 T1 would allow a spammer at most 24 simultaneous calls, and assuming 184 about 10s for each call attempt, about 2.4 call attempts per second. 185 At high volume calling, the per-minute rates far exceed the flat 186 monthly fee for the T1. The result is a cost of 250,000 microcents 187 for each successful spam delivery, assuming 10s of content. 189 With SIP, this cost is much reduced. Consider a spammer using a 190 typical broadband Internet connection that provides 500Kbps of 191 upstream bandwidth. Initiating a call requires just a single INVITE 192 message. Assuming, for simplicity's sake, that this is 1kB, a 193 500Kbps upstream DSL or cable modem connection will allow about 62 194 call attempts per second. A successful call requires enough 195 bandwidth to transmit a message to the receiver. Assuming a low 196 compression codec (say, G.723.1 at 5.6 Kbps), as many as 90 197 simultaneous calls can be in progress. With 10s of content per call, 198 that allows for 9 successful call attempts per second. This means 199 that a system could deliver a voice message successfully to users at 200 a rate of around 9 per second. If broadband access is around $50/ 201 month, the cost per successful voice spam is about 215 microcents 202 each. This assumes that calls can be made 24 hours a day, which may 203 or may not be the case. 205 These figures indicate that SIP call spam is roughly three orders of 206 magntiude cheaper to send than traditional circuit-based telemarketer 207 calls. This low cost is certainly going to be very attractive to 208 spammers. 210 These figures assume that the primary limitation is the access 211 bandwidth and not CPU, disk, or termination costs. Termination costs 212 merit further discussion. Currently, most VoIP calls terminate on 213 the Public Switched Telephone Network (PSTN), and this termination 214 costs the originator of the call money. These costs are similar to 215 the per-minute rates of a T1. It ranges anywhere from half a cent to 216 three cents per minute, depending on volume and other factors. 217 However, equipment costs, training and other factors are much lower 218 for SIP-based termination than a T1, making the cost still lower than 219 circuit connectivity. Furthermore, the current trend in VoIP systems 220 is to make termination free for calls that never touch the PSTN, that 221 is, calls to actual SIP endpoints. Thus, as more and more SIP 222 endpoints come online (there are probably around 5 million 223 addressable SIP endpoints on the Internet as of writing), termination 224 costs will probably drop. Until then, SIP spam can be used in 225 concert with termination services for a lower cost form of 226 traditional telemarketer calls, made to normal PSTN endpoints. 228 This number (9 deliveries per second) is below the successful message 229 delivery rate of email [[NOTE: is there a figure for this]]. 230 However, many spam messages are automatically deleted by filters or 231 users without ever being read. It is far more likely that a call 232 spam will be examined by a user if its delivered, due to the 233 difficulty in automated content filtering (see below). Thus, when 234 one examines the final figure of importance - the number of new 235 customers attracted per spam delivered, it is far from clear whether 236 call spam or email spam will be more effective. 238 Another part of the cost of spamming is collecting addresses. 239 Spammers have, over time, built up immense lists of email addresses, 240 each of the form user@domain, to which spam is directed. SIP uses 241 the same form of addressing, making it likely that email addresses 242 can easily be turned into valid SIP addresses. Telephone numbers 243 also represent valid SIP addresses, in that, in concert with a 244 termination provider, a spammer can direct SIP calls at traditional 245 PSTN devices. It is not clear whether email spammers have also been 246 collecting phone numbers as they perform their web sweeps, but it is 247 probably not hard to do so. Furthermore, unlike email addresses, 248 phone numbers are a finite address space and one that is fairly 249 densely packed. As a result, going sequentially through phone 250 numbers is likely to produce a fairly high hit rate. Thus, it seems 251 like the cost is relatively low for a spammer to obtain large numbers 252 of SIP addresses to which spam can be directed. 254 2.2 IM Spam 256 IM spam is very much like email, in terms of the costs for deploying 257 and generating spam. Assuming, for the sake of argument, a 1kB 258 message to be sent and 500 Kbps of upstream bandwidth, thats 62 259 messages per second. At $50/month, the result is 31 microcents per 260 message. This is less than voice spam, but not substantially less. 261 The cost is probably on par with email spam. However, IM is much 262 more intrusive than email. In today's systems, IMs automatically pop 263 up and present themselves to the user. Email, of course, must be 264 deliberately selected and displayed. However, many IM systems employ 265 white lists, which only allow spam to be delivered if the sender is 266 on the white list. Thus, whether or not IM spam will be useful seems 267 to depend a lot on the nature of the systems as the network is opened 268 up. If they are ubiquitously deployed with white-list access, the 269 value of IM spam is likely to be low. 271 2.3 Presence Spam 273 Since the value of presence spam is unclear to the authors at this 274 moment, we do not comment on it further here. 276 3. Solution Space 278 In this section, we consider the various solutions that might be 279 possible to deal with SIP spam. We primarily consider techniques 280 that have been employed to deal with email spam. It is important to 281 note that the solutions documented below are not meant to be an 282 exhaustive study of the spam solutions used for email but rather just 283 a representative set. We also consider some solutions that appear to 284 be SIP-specific. 286 3.1 Content Filtering 288 The most common form of spam protection used in email is based on 289 content filtering. These spam filters analyze the content of the 290 email, and look for clues that the email is spam. Bayesian spam 291 filters are in this category. 293 Unfortunately, this type of spam filtering is almost completely 294 useless for call spam. There are two reasons. First, in the case 295 where the user answers the call, the call is already established and 296 the user is paying attention before the content is delivered. The 297 spam cannot be analyzed before the user sees it. Second, if the 298 content is stored before the user accesses it (e.g., with voicemail), 299 the content will be in the form of recorded audio or video. Speech 300 and video recognition technology is not likely to be good enough to 301 analyze the content and determine whether or not it is spam. Indeed, 302 if a system tried to perform speech recognition on a recording in 303 order to perform such an analysis, it would be easy for the spammers 304 to make calls with background noises, poor grammar and varied 305 accents, all of which will throw off recognition systems. Video 306 recognition is even harder to do and remains primarily an area of 307 research. 309 Therefore, our conclusion is that the most successful form of 310 anti-spam measures used in email are almost useless for call spam. 312 IM spam, due to its similarity to email, can be countered with 313 content analysis tools. Indeed, the same tools and techniques used 314 for email will directly work for IM spam. 316 3.2 Black Lists 318 Black listing is an approach whereby the spam filter maintains a list 319 of addresses that identify spammers. These addresses include both 320 usernames (spammer@domain.com) and entire domains (spammers.com). 321 Pure blacklists are not very effective in email for two reasons. 322 First, email addresses are easy to spoof, making it easy for the 323 sender to pretend to be someone else. If the sender varies the 324 addresses they send from, the black list becomes almost completely 325 useless. The second problem is that, even if the sender doesn't 326 forge the from address, email addresses are in almost limitless 327 supply. Each domain contains an infinite supply of email addresses, 328 and new domains can be obtained for very low cost. Furthermore, 329 there will always be public providers that will allow users to obtain 330 identities for almost no cost (for example, Yahoo or AOL mail 331 accounts). The entire domain cannot be blacklisted because it 332 contains so many valid users. Blacklisting needs to be for 333 individual users. Those identities are easily changed. 335 Blacklists are also likely to be ineffective for SIP spam. 336 Fortunately, SIP has much stronger mechanisms for inter-domain 337 authenticated identity than email has (see Section 4). Assuming 338 these mechanisms are used and enabled in inter-domain communications, 339 it becomes nearly impossible to forge sender addresses. However, it 340 still remains cheap to obtain a nearly infinite supply of addresses. 342 3.3 White Lists 344 White lists are the opposite of black lists. It is a list of valid 345 senders that a user is willing to accept email from. In the email 346 world, white lists alone are not useful, since they would prohibit a 347 user from ever being able to receive email from someone who was not 348 explicitly put on the white list. It is also too easy for spammers 349 to forge sender addresses. White lists also demand time from the 350 user to manage them. 352 Fortunately, white lists are much more useful in preventing SIP spam. 353 This is for several reasons. First, there is a natural "white list" 354 in SIP systems - the buddy list. Many SIP clients use the buddy list 355 concept as the center point for communications. This trend is likely 356 to continue. Because of its common usage in SIP communications, 357 users have been willing to invest the time in managing their lists, 358 growing them, and keeping them up to date. This is because they have 359 utility in many ways, not just as a form of white list. 361 Second, because SIP can provide a much more secure form of 362 authenticated identity, even for inter-domain communications, the 363 problem of forged senders can be eliminated, making the white list 364 more useful. 366 There is still the problem of how to communicate with users who are 367 not known ahead of time. In email, techniques like the Turing tests 368 have been employed for this purpose. Those are considered further in 369 the sections below. Since white lists alone are not a solution, 370 because of the "initial communication" problem, one of these 371 techniques will need to be used in conjunction with any white list 372 solution in SIP. 374 3.4 Consent-Based Communications 376 A consent-based solution is used in conjunction with white or black 377 lists. That is, if user A is not on user B's white or black list, 378 and user A attempts to communicate with user B, user A's attempt is 379 initially rejected, and they are told that consent is being 380 requested. Next time user B connects, user B is informed that user A 381 attempted to communicate, and then user B can authorize user A. 383 These kinds of consent-based systems are used widely in presence and 384 IM but not in email. This is likely due to the need for a secure 385 authenticated identity mechanism, which is a pre-requisite for this 386 kind of solution. Since most of today's IM systems are closed, 387 sender identities can be authenticated. 389 This kind of consent-based communications has been standardized in 390 SIP for presence, using the watcher information event package [8] and 391 data format [9], which allow a user to find out that someone has 392 subscribed. Then, the XML Configuration Access Protocol (XCAP) [10] 393 is used, along with the XML format for presence authorization [11] to 394 provide permission for the user to communicate. However, to date, 395 these techniques have been applied strictly for presence. 397 If they were extended to cover IM and calling, would it help? It is 398 hard to say. At first glance, it would seem to help a lot. However, 399 it might just change the nature of the spam. Instead of being 400 bothered with content, in the form of call spam or IM spam, users are 401 bothered with consent requests. A user's "communications inbox" 402 might instead be filled with requests for communications from a 403 multiplicity of users. On the flip side, those requests for 404 communications don't convey any useful content to the user. In order 405 for the spammer to convey content to the user, the user must 406 explicitly accept the request, and only then can the spammer convey 407 the content. This is unlike email spam, where, even though much spam 408 is automatically deleted, some percentage of the content does get 409 through, and is seen by users, without their explicit consent that 410 they want to see it. Thus, if consent is required first, and nearly 411 all users do not give consent to spammers, the value in sending spam 412 is reduced, and perhaps it will cease. 414 As such, the real question is whether or not the consent system would 415 make it possible for a user to give consent to non-spammers and 416 reject spammers. Authenticated identity can help. A user in an 417 enterprise would know to give consent to senders in other enterprises 418 in the same industry, for example. However, in the consumer space, 419 if sip:bob@aol.com tries to communicate with a user, how does that 420 user determine whether bob is a spammer or a long-lost friend from 421 high school? There is no way based on the identity alone. In such a 422 case, a useful technique is to grant permission for bob to 423 communicate but to make the permission is extremely limited. In 424 particular, bob may be granted permission to send no more than 200 425 words of text in a single IM, which he can use to identify himself, 426 so that the user can determine whether or not more permissions are 427 appropriate. However, this 200 words of text may be enough for a 428 spammer to convey their message. 430 Thus, it seems that a consent-based framework, along with white lists 431 and black lists, cannot fully solve the problem for SIP, although it 432 does appear to help. 434 3.5 Turing Tests 436 In email, Turing tests are those solutions whereby the sender of the 437 message is given some kind of puzzle or challenge, which only a human 438 can answer. If the puzzle is answered correctly, the sender is 439 placed on the user's white list. These puzzles frequently take the 440 form of recognizing a word or sequence of numbers in an image with a 441 lot of background noise. Automata cannot easily perform the image 442 recognition needed to extract the word or number sequence, but a 443 human user can. 445 Like many of the other email techniques, Turing tests are dependent 446 on sender identity, which cannot easily be authenticated in email. 448 Turing tests can be used to prevent IM spam, in much the same way 449 they can be used to prevent email spam. Indeed, the presence strong 450 authenticated identity techniques in SIP will make such a Turing test 451 approach more effective in SIP than in email. 453 Turing tests can be applied to call spam as well, although not 454 directly, because call spam does not usually involve the transfer of 455 images and other content that can be used to verify that a human is 456 on the other end. If most of the calls are voice, the technique 457 needs to be adapted to voice. This is not that difficult to do. 458 Here is how it could be done. User A calls user B and is not on user 459 B's white or black list. User A is transferred to an IVR system. 460 The IVR system tells the user that they are going to hear a series of 461 numbers (say 5 of them), and that they have to enter those numbers on 462 the keypad. The IVR system reads out the numbers while background 463 music is playing, making it difficult for an automated speech 464 recognition system to be applied to the media. The user then enters 465 the numbers on their keypad. If they are entered correctly, the user 466 is added to the whitelist. 468 This kind of voice-based Turing test is easily extended to a variety 469 of media, such as video and text, and user interfaces by making use 470 of the SIP application interaction framework [12]. This framework 471 allows client devices to interact with applications in the network, 472 where such interaction is done with stimulus signaling, including 473 keypads (supported with the Keypad Markup Language [13]), but also 474 including web browsers, voice recognition, and so on. The framework 475 allows the application to determine the media capabilities of the 476 device and interact with them appropriately. 478 In the case of voice, there are problems with the Turing test 479 described above. First, it is language specific. The application 480 could be made to run in different languages, if the caller indicates 481 their supported languages. This is possible in SIP, using the 482 Accept-Language header field, but this is not widely used at the 483 moment. 485 The other problem with this Turing test is the same one that email 486 tests have: instead of having an automata process the test, a spammer 487 can pay cheap workers to take the tests. Assuming cheap labor in a 488 poor country can be obtained for about $100 US dollars per year, and 489 assuming a Turing test of 30 second duration, this ends up being 490 about ten thousand messages per dollar, or about 10,000 microcents 491 per message. Though much more expensive than the 31 microcents per 492 message to send an IM spam, it is still relatively inexpensive. 493 Turing tests may never completely solve the problem. 495 3.6 Computational Puzzles 497 This technique is similar to Turing tests. When user A tries to 498 communicate with user B, user B asks user A to perform a computation 499 and pass the result back. This computation has to be something a 500 human user cannot perform and something expensive enough to increase 501 user A's cost to communicate. This cost increase has to be high 502 enough to make it prohibitively expensive for spammers but 503 inconsequential for legitimate users. 505 This technique works for email, and it can also work for all forms of 506 SIP spam. However, one of the problems is that there is wide 507 variation in the computational power of the various clients that 508 might legitimately communicate. The CPU speed on a low end cell 509 phone is around 50 MHz, while a high end PC approaches 5 GHz. This 510 represents almost two orders of magnitude difference. Thus, if the 511 test is designed to be reasonable for a cell phone to perform, it is 512 two orders of magnitude cheaper to perform for a spammer on a high 513 end machine. Recent research has focused on defining computational 514 puzzles that challenge the CPU/memory bandwidth, as opposed to just 515 the CPU [16]. It seems that there is less variety in the CPU/memory 516 bandwidth across devices, roughly a single order of magnitude. 518 These techniques might work. They are an active area of research 519 right now, and any results for email are likely to be directly 520 applicable to SIP. Of course, it is likely that these techniques 521 will come with a lot of patents and other intellectual property 522 constraints. 524 3.7 Payments at Risk 526 This approach has been proposed for email [17]. When user A sends to 527 user B, user A deposits a small amount of money (say, one dollar) 528 into user B's account. If user B decides that the message is not 529 spam, user B refunds this money back to user A. If the message is 530 spam, user B keeps the money. This technique requires two 531 transactions to complete: a transfer from A to B, and a transfer from 532 B back to A. The first transfer has to occur before the message can 533 be received in order to avoid reuse of "pending payments" across 534 several messages, which would eliminate the utility of the solution. 535 The second one then needs to occur when the message is found not to 536 be spam. 538 This technique appears just as applicable to call spam and IM spam as 539 it is to email spam. Like many of the other techniques, this 540 exchange would only happen the first time you talk to people. Its 541 proper operation therefore requires a good authenticated identity 542 infrastructure. 544 This technique has the potential to truly make it prohibitively 545 expensive to send spam of any sort. However, it relies on cheap 546 micro-payment techniques on the Internet. Traditional costs for 547 internet payments are around 25 cents per transaction, which would 548 probably be prohibitive. However, recent providers have been willing 549 to charge 15% of the transaction for small transactions, for 550 transactions as small as one cent. This cost would have to be 551 shouldered by users of the system. The cost that would need to be 552 shouldered per user is equal to the number of messages from unknown 553 senders (that is, senders not on the white list) that are received. 554 For a busy user, assume about 10 new senders per day. If the deposit 555 is 5 cents, the transaction provider would take .75 cents and deliver 556 4.25 cents. If the sender is allowed, the recipient returns 4.25 557 cents, the provider takes 64 cents, and returns 3.6 cents. This 558 costs the sender .65 cents on each transaction, if it was legitimate. 560 If there are ten new recipients per day, thats US $1.95 per month, 561 which is relatively inexpensive. 563 3.8 Legal Action 565 In this solution, countries pass laws that prohibit spam. These laws 566 could apply to IM or call spam just as easily as they could apply to 567 email spam. 569 There is a lot of debate about whether these laws would really be 570 effective in preventing spam. Whether they are or are not effective, 571 they would appear to be equally effective (or ineffective, as the 572 case may be) in preventing SIP spam. 574 As a recent example in the US, "do not call" lists seem to be 575 effective. However, due to the current cost of long distance phone 576 calls, the telemarketing is coming from companies within the US. As 577 such, calls from such telemarketers can be traced. If a telemarketer 578 violates the "do not call" list, the trace allows legal action to be 579 taken against them. A similar "do not irritate" list for VoIP or for 580 email would be less likely to work because the spam is likely to come 581 from international sources. This problem could be obviated if there 582 was a strong way to identify the sender's legal entity, and then 583 determine whether it was in a jurisdiction where it was practical to 584 take legal action against them. If the spammer is not in such a 585 jurisdiction, the SIP spam could be rejected. 587 There are also schemes that cause laws other than anti-spam laws to 588 be broken if spam is sent. This does not inherently reduce SPAM, but 589 it allows more legal options to be brought to bear against the 590 spammer. For example, Habeas [18] inserts material in the header 591 that, if a spammer inserted it without an appropriate license, 592 allegedly causes the spammer to be violating US copyright and 593 trademark laws, possibly reciprocal laws, and similar laws in many 594 countries. 596 3.9 Circles of Trust 598 In this model, a group of domains (e.g., a set of enterprises) all 599 get together. They agree to exchange SIP calls amongst each other, 600 and they also agree to introduce a fine should any one of them be 601 caught spamming. Each company would then enact measures to terminate 602 employees who spam from their accounts. 604 This technique relies on secure inter-domain authentication - that 605 is, domain B can know that messages are received from domain A. In 606 SIP, this is readily provided by usage of the mutually authenticated 607 TLS between providers. Email does not have this kind of secure 608 domain identification, although new techniques are being investigated 609 to add it using reverse DNS checks (see below). 611 This kind of technique works well for small domains or small sets of 612 providers, where these policies can be easily enforced. However, it 613 is unclear how well it scales up. Could a very large domain truly 614 prevent its users from spamming? Would a very large enterprise just 615 pay the fine? How would the pricing be structured to allow both small 616 and large domains alike to participate? 618 3.10 Centralized SIP Providers 620 In this technique, a small number of providers get established as 621 "inter-domain SIP providers". These providers act as a 622 SIP-equivalent to the interexchange carriers in the PSTN. Every 623 enterprise, consumer SIP provider or other SIP network (call these 624 the local SIP providers) connects to one of these inter-domain 625 providers. The local SIP providers only accept SIP messages from 626 their chosen inter-domain provider. The inter-domain provider 627 charges the local provider, per SIP message, for the delivery of SIP 628 messages to other local providers. The local provider can choose to 629 pass on this cost to its own customers if it so chooses. 631 The inter-domain SIP providers then form bi-lateral agreements with 632 each other, exchanging SIP messages according to strict contracts. 633 These contracts require that each of the inter-domain providers be 634 responsible for charging a minimum per-message fee to their own 635 customers. Extensive auditing procedures can be put into place to 636 verify this. Besides such contracts, there may or may not be a flow 637 of funds between the inter-domain providers. 639 The result of such a system is that a fixed cost can be associated 640 with sending a SIP message, and that this cost does not require 641 micro-payments to be exchanged between local providers, as it does in 642 Section 3.7. Since all of the relationships are pre-established and 643 negotiated, cheaper techniques for monetary transactions (such as 644 monthly post-paid transactions) can be used. 646 This technique can be made to work in SIP, whereas it cannot in 647 email, because inter-domain SIP connectivity has not yet been 648 established. In email, there already exists a no-cost form of 649 inter-domain connectivity that cannot be eliminated without 650 destroying the utility of email. If, however, SIP inter-domain 651 communications get established from the start using this structure, 652 there is a path to deployment. 654 This structure is more or less the same as the one in place for the 655 PSTN today, and since there is relatively little spam on the PSTN 656 (compared to email!), there is some proof that this kind of 657 arrangement can work. However, it puts back into SIP much of the 658 complexity and monopolistic structures that SIP promised to 659 eliminate. As such, it is a solution that the authors find somewhat 660 distasteful, though it may be a viable one. 662 3.11 Sender Checks 664 In email, there has been a lot of interest in defining new DNS 665 resource records that will allow a domain that receives a message to 666 verify that the sender is a valid MTA for the sending domain. 667 Standards are now being developed for this within the MARID working 668 group in the IETF [14]. 670 Are these techniques useful for SIP? They can be used for SIP but are 671 not necessary. In email, there are no standards established for 672 securely identifying the identity of the sending domain of a message. 673 In SIP, however, TLS with mutual authentication can be used 674 inter-domain. A provider receiving a message can then reject any 675 message coming from a domain that does not match the asserted 676 identity of the sender of the message. Such a policy only works in 677 the "trapezoid" model of SIP, whereby there are only two domains in 678 any call - the sending domain, which is where the originator resides, 679 and the receiving domain. 681 Thus, instead of creating DNS entries containing the IP address of 682 each legitimate relay for a domain, the provider can give each 683 legitimate relay a certificate that allows them to authenticate 684 themselves as coming from that domain. Such a technique would work 685 even in the face of IP address spoofing, which the marid techniques 686 are susceptible to. 688 4. Authenticated Identity in SIP 690 One of the key parts of many of the solutions described above is the 691 ability to securely identify the identity of a sender of a SIP 692 message. SIP provides a secure solution for this problem, and it is 693 important to discuss it here. 695 The solution starts by having each domain authenticate its own users. 696 SIP provides HTTP digest authentication as part of the core SIP 697 specification, and all clients and servers are required to support 698 it. Indeed, digest is widely deployed for SIP. However, digest 699 alone has many known vulnerabilities, most notably offline dictionary 700 attacks. These vulnerabilities are all resolved by having each 701 client maintain a persistent TLS connection to the server. The 702 client verifies the server identity using TLS, and then authenticates 703 itself to the server using a digest exchange over TLS. This 704 technique, which is also documented in RFC 3261, is very secure but 705 not widely deployed yet. In the long term, this approach will be 706 necessary for the security properties needed to prevent SIP spam. 708 Once a domain has authenticated the identity of a user, when it 709 relays a message from that user to another domain, the sending domain 710 can assert the identity of the sender, and include a signature to 711 validate that assertion. This is done using the SIP identity 712 mechanism [15]. A weaker form of identity assertion is possible 713 using the P-Asserted-Identity header field [6], but this technique 714 requires mutual trust among all domains, and therefore has limited 715 applicability. Privacy is also possible, so that a user can request 716 that their identity not be conveyed [5]. 718 SIP also defines the usage of TLS between domains, using mutual 719 authentication, as part of the base specification. This technique 720 provides a way for one domain to securely determine that it is 721 talking to a server that is a valid representative of another domain. 723 5. Recommendations 725 Unfortunately, there is no magic bullet for preventing SIP spam, just 726 as there is none for email spam. However, some concrete 727 recommendations can be made. 728 Strong Authenticated Identity is Key: In almost all of the solutions 729 discussed above, there is a dependency on the ability to 730 authenticate the sender of a SIP message inter-domain. As such, 731 we would argue that any provider that performs inter-domain SIP 732 messaging MUST use the techniques described in Section 4. 733 Extend the Consent Framework in Presence: The consent framework 734 developed for presence, if applied to other aspects of SIP 735 communications, would appear to be a useful tool in combating 736 spam. It doesn't seem likely that it can completely solve the 737 problem, but it has worked well in presence systems so far. Thus, 738 we would recommend that the IETF proceed to develop such a 739 framework for SIP. 740 Leverage What Email has to Offer: Providers of SIP services should 741 keep tabs on solutions in email as they evolve, and utilize the 742 best of what those techniques have to offer. But perhaps most 743 importantly, providers should not ignore the spam problem until it 744 happens! That is the pitfall email fell into. As soon as a 745 provider inter-connects with other providers, or allows SIP 746 messages from the open Internet, that provider must consider how 747 they will deal with spam. 749 6. Security Considerations 751 This memo is entirely devoted to issues relating to secure usage of 752 SIP services on the Internet. 754 7. Acknowledgements 756 The authors would like to thank Rohan Mahy for providing information 757 on Habeas, Baruch Sterman for providing costs on VoIP termination 758 services, and Gonzalo Camarillo for his review and comments. 760 8 Informative References 762 [1] Campbell, B., "The Message Session Relay Protocol", 763 draft-ietf-simple-message-sessions-06 (work in progress), May 764 2004. 766 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 767 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 768 Session Initiation Protocol", RFC 3261, June 2002. 770 [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 771 D. Gurle, "Session Initiation Protocol (SIP) Extension for 772 Instant Messaging", RFC 3428, December 2002. 774 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 775 Notification", RFC 3265, June 2002. 777 [5] Peterson, J., "A Privacy Mechanism for the Session Initiation 778 Protocol (SIP)", RFC 3323, November 2002. 780 [6] Jennings, C., Peterson, J. and M. Watson, "Private Extensions 781 to the Session Initiation Protocol (SIP) for Asserted Identity 782 within Trusted Networks", RFC 3325, November 2002. 784 [7] Rosenberg, J., "A Presence Event Package for the Session 785 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 786 in progress), January 2003. 788 [8] Rosenberg, J., "A Watcher Information Event Template-Package 789 for the Session Initiation Protocol (SIP)", 790 draft-ietf-simple-winfo-package-05 (work in progress), January 791 2003. 793 [9] Rosenberg, J., "An Extensible Markup Language (XML) Based 794 Format for Watcher Information", 795 draft-ietf-simple-winfo-format-04 (work in progress), January 796 2003. 798 [10] Rosenberg, J., "The Extensible Markup Language (XML) 799 Configuration Access Protocol (XCAP)", 800 draft-ietf-simple-xcap-02 (work in progress), February 2004. 802 [11] Rosenberg, J., "Presence Authorization Rules", 803 draft-ietf-simple-presence-rules-00 (work in progress), May 804 2004. 806 [12] Rosenberg, J., "A Framework for Application Interaction in the 807 Session Initiation Protocol (SIP)", 808 draft-ietf-sipping-app-interaction-framework-01 (work in 809 progress), February 2004. 811 [13] Burger, E., "A Session Initiation Protocol (SIP) Event Package 812 for Key Press Stimulus (KPML)", draft-ietf-sipping-kpml-03 813 (work in progress), May 2004. 815 [14] Lyon, J., "MTA Authentication Records in DNS", 816 draft-ietf-marid-core-01 (work in progress), June 2004. 818 [15] Peterson, J., "Enhancements for Authenticated Identity 819 Management in the Session Initiation Protocol (SIP)", 820 draft-ietf-sip-identity-02 (work in progress), May 2004. 822 [16] Abadi, M., Burrows, M., Manasse, M. and T. Wobber, "Moderately 823 Hard, Memory Bound Functions, NDSS 2003", February 2003. 825 [17] Abadi, M., Burrows, M., Birrell, A., Dabek, F. and T. Wobber, 826 "Bankable Postage for Network Services, Proceedings of the 8th 827 Asian Computing Science Conference, Mumbai, India", December 828 2003. 830 [18] 832 Authors' Addresses 834 Jonathan Rosenberg 835 dynamicsoft 836 600 Lanidex Plaza 837 Parsippany, NJ 07054 838 US 840 Phone: +1 973 952-5000 841 EMail: jdrosen@dynamicsoft.com 842 URI: http://www.jdrosen.net 843 Cullen Jennings 844 Cisco 845 170 West Tasman Dr. 846 San Jose, CA 95134 847 US 849 Phone: +1 408 527-9132 850 EMail: fluffy@cisco.com 852 Intellectual Property Statement 854 The IETF takes no position regarding the validity or scope of any 855 Intellectual Property Rights or other rights that might be claimed to 856 pertain to the implementation or use of the technology described in 857 this document or the extent to which any license under such rights 858 might or might not be available; nor does it represent that it has 859 made any independent effort to identify any such rights. Information 860 on the procedures with respect to rights in RFC documents can be 861 found in BCP 78 and BCP 79. 863 Copies of IPR disclosures made to the IETF Secretariat and any 864 assurances of licenses to be made available, or the result of an 865 attempt made to obtain a general license or permission for the use of 866 such proprietary rights by implementers or users of this 867 specification can be obtained from the IETF on-line IPR repository at 868 http://www.ietf.org/ipr. 870 The IETF invites any interested party to bring to its attention any 871 copyrights, patents or patent applications, or other proprietary 872 rights that may cover technology that may be required to implement 873 this standard. Please address the information to the IETF at 874 ietf-ipr@ietf.org. 876 Disclaimer of Validity 878 This document and the information contained herein are provided on an 879 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 880 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 881 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 882 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 883 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 884 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 886 Copyright Statement 888 Copyright (C) The Internet Society (2004). This document is subject 889 to the rights, licenses and restrictions contained in BCP 78, and 890 except as set forth therein, the authors retain all their rights. 892 Acknowledgment 894 Funding for the RFC Editor function is currently provided by the 895 Internet Society.