idnits 2.17.1 draft-ietf-sipping-spam-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1315. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 9, 2007) is 6107 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '4') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 3761 (ref. '9') (Obsoleted by RFC 6116, RFC 6117) == Outdated reference: A later version (-10) exists of draft-ietf-simple-presence-rules-09 == Outdated reference: A later version (-04) exists of draft-ietf-sip-consent-framework-01 == Outdated reference: A later version (-08) exists of draft-ietf-sipping-consent-format-03 == Outdated reference: A later version (-02) exists of draft-rosenberg-sip-ua-loose-route-01 -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '17') (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4408 (ref. '21') (Obsoleted by RFC 7208) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. '22') (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 4871 (ref. '23') (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 3851 (ref. '24') (Obsoleted by RFC 5751) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING J. Rosenberg 3 Internet-Draft C. Jennings 4 Intended status: Informational Cisco 5 Expires: January 10, 2008 July 9, 2007 7 The Session Initiation Protocol (SIP) and Spam 8 draft-ietf-sipping-spam-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 20 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 10, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Call Spam . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. IM Spam . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.3. Presence Spam . . . . . . . . . . . . . . . . . . . . . . 7 59 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1. Content Filtering . . . . . . . . . . . . . . . . . . . . 8 61 3.2. Black Lists . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.3. White Lists . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.4. Consent-Based Communications . . . . . . . . . . . . . . . 10 64 3.5. Reputation Systems . . . . . . . . . . . . . . . . . . . . 12 65 3.6. Address Obfuscation . . . . . . . . . . . . . . . . . . . 14 66 3.7. Limited Use Addresses . . . . . . . . . . . . . . . . . . 14 67 3.8. Turing Tests . . . . . . . . . . . . . . . . . . . . . . . 15 68 3.9. Computational Puzzles . . . . . . . . . . . . . . . . . . 17 69 3.10. Payments at Risk . . . . . . . . . . . . . . . . . . . . . 17 70 3.11. Legal Action . . . . . . . . . . . . . . . . . . . . . . . 18 71 3.12. Circles of Trust . . . . . . . . . . . . . . . . . . . . . 19 72 3.13. Centralized SIP Providers . . . . . . . . . . . . . . . . 19 73 4. Authenticated Identity in Email . . . . . . . . . . . . . . . 20 74 4.1. Sender Checks . . . . . . . . . . . . . . . . . . . . . . 21 75 4.2. Signature-Based Techniques . . . . . . . . . . . . . . . . 21 76 5. Authenticated Identity in SIP . . . . . . . . . . . . . . . . 22 77 6. Framework for Anti-Spam in SIP . . . . . . . . . . . . . . . . 23 78 7. Additional Work . . . . . . . . . . . . . . . . . . . . . . . 24 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 82 11. Informative References . . . . . . . . . . . . . . . . . . . . 25 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 84 Intellectual Property and Copyright Statements . . . . . . . . . . 28 86 1. Introduction 88 Spam, defined as the transmission of bulk unsolicited email, has been 89 a plague on the Internet email system. Many solutions have been 90 documented and deployed to counter the problem. None of these 91 solutions is ideal. However, one thing is clear: the spam problem 92 would be much less significant had solutions been deployed 93 ubiquitously before the problem became widespread. 95 The Session Initiation Protocol (SIP) [2] is used for multimedia 96 communications between users, including voice, video, instant 97 messaging and presence. Consequently, it can be just as much of a 98 target for spam as email. To deal with this, solutions need to be 99 defined and recommendations put into place for dealing with spam as 100 soon as possible. 102 This document serves to meet those goals by defining the problem 103 space more concretely, analyzing the applicability of solutions used 104 in the email space, identifying protocol mechanisms that have been 105 defined for SIP which can help the problem, and making 106 recommendations for implementors. 108 2. Problem Definition 110 The spam problem in email is well understood, and we make no attempt 111 to further elaborate on it here. The question, however, is what is 112 the meaning of spam when applied to SIP? Since SIP covers a broad 113 range of functionality, there appear to be three related but 114 different manifestations: 116 Call Spam: This type of spam is defined as a bulk unsolicited set of 117 session initiation attempts (i.e., INVITE requests), attempting to 118 establish a voice, video, instant messaging [1] or other type of 119 communications session. If the user should answer, the spammer 120 proceeds to relay their message over the real time media. This is 121 the classic telemarketer spam, applied to SIP. This is often 122 called SPam over Ip Telephony or SPIT. 124 IM Spam: This type of spam is similar to email. It is defined as a 125 bulk unsolicited set of instant messages, whose content contains 126 the message that the spammer is seeking to convey. IM spam is 127 most naturally sent using the SIP MESSAGE [3] request. However, 128 any other request which causes content to automatically appear on 129 the user's display will also suffice. That might include INVITE 130 requests with large Subject headers (since the Subject is 131 sometimes rendered to the user), or INVITE requests with text or 132 HTML bodies. This is often called SPam over Instant Messaging or 133 SPIM. 135 Presence Spam: This type of spam is similar to IM spam. It is 136 defined as a bulk unsolicited set of presence requests (i.e., 137 SUBSCRIBE requests [4] for the presence event package [6]), in an 138 attempt to get on the "buddy list" or "white list" of a user in 139 order to send them IM or initiate other forms of communications. 140 This is occasionally called SPam over Presence Protocol or SPPP. 142 There are many other SIP messages that a spammer might send. 143 However, most of the other ones do not result in content being 144 delivered to a user, nor do they seek input from a user. Rather, 145 they are answered by automata. OPTIONS is a good example of this. 146 There is little value for a spammer in sending an OPTIONS request, 147 since it is answered automatically by the UAS. No content is 148 delivered to the user, and they are not consulted. 150 In the sections below, we consider the likelihood of these various 151 forms of SIP spam. This is done in some cases by a rough cost 152 analysis. It should be noted that all of these analyses are 153 approximate, and serve only to give a rough sense of the order of 154 magnitude of the problem. 156 2.1. Call Spam 158 Will call spam occur? That is an important question to answer. 159 Clearly, it does occur in the existing telephone network, in the form 160 of telemarketer calls. Although these calls are annoying, they do 161 not arrive in the same kind of volume as email spam. The difference 162 is cost; it costs more for the spammer to make a phone call than it 163 does to send email. This cost manifests itself in terms of the cost 164 for systems which can perform telemarketer call, and in cost per 165 call. 167 Both of these costs are substantially reduced by SIP. A SIP call 168 spam application is easy to write. It is just a SIP User Agent that 169 initiates, in parallel, a large number of calls. If a call connects, 170 the spam application generates an ACK and proceeds to play out a 171 recorded announcement, and then it terminates the call. This kind of 172 application can be built entirely in software, using readily 173 available (and indeed, free) off the shelf software components. It 174 can run on a low end PC and requires no special expertise to execute. 176 The cost per call is also substantially reduced. A normal 177 residential phone line allows only one call to be placed at a time. 178 If additional lines are required, a user must purchase more expensive 179 connectivity. Typically, a T1 or T3 would be required for a large 180 volume telemarketing service. That kind of access is very expensive 181 and well beyond the reach of an average user. A T1 line is 182 approximately US $250 per month, and about 1.5 cents per minute for 183 calls. T1 lines used only for outbound calls (such as in this case) 184 are even more expensive than inbound trunks due to the reciprocal 185 termination charges that a provider pays and receives. 187 There are two aspects to the capacity: the call attempt rate, and the 188 number of simultaneous successful calls that can be in progress. A 189 T1 would allow a spammer at most 24 simultaneous calls, and assuming 190 about 10 seconds for each call attempt, about 2.4 call attempts per 191 second. At high volume calling, the per-minute rates far exceed the 192 flat monthly fee for the T1. The result is a cost of 250,000 193 microcents for each successful spam delivery, assuming 10 seconds of 194 content. 196 With SIP, this cost is much reduced. Consider a spammer using a 197 typical broadband Internet connection that provides 500 Kbps of 198 upstream bandwidth. Initiating a call requires just a single INVITE 199 message. Assuming, for simplicity's sake, that this is 1 KB, a 500 200 Kbps upstream DSL or cable modem connection will allow about 62 call 201 attempts per second. A successful call requires enough bandwidth to 202 transmit a message to the receiver. Assuming a low compression codec 203 (say, G.723.1 at 5.6 Kbps), as many as 46 simultaneous calls can be 204 in progress. With 10 seconds of content per call, that allows for 205 4.6 successful call attempts per second. This means that a system 206 could deliver a voice message successfully to users at a rate of 207 around 9 per second. If broadband access is around $50/month, the 208 cost per successful voice spam is about 415 microcents each. This 209 assumes that calls can be made 24 hours a day, which may or may not 210 be the case. 212 These figures indicate that SIP call spam is roughly three orders of 213 magnitude cheaper to send than traditional circuit-based telemarketer 214 calls. This low cost is certainly going to be very attractive to 215 spammers. Indeed, many spammers utilize computational and bandwidth 216 resources provided by others, by infecting their machines with 217 viruses that turn them into "zombies" that can be used to generate 218 spam. This can reduce the cost of call spam to nearly zero. 220 Even ignoring the zombie issue, this reduction in cost is even more 221 amplified for international calls. Currently, there is very little 222 telemarketing calls across international borders, largely due to the 223 large cost of making international calls. This is one of the reasons 224 why the "do not call list", a United States national list of numbers 225 that telemarketers cannot call - has been effective. The law only 226 affects U.S. companies, but since most telemarketing calls are 227 domestic, it has been effective. Unfortunately (and fortunately), 228 the IP network provides no boundaries of these sorts, and calls to 229 any SIP URI are possible from anywhere in the world. This will allow 230 for international spam at a significantly reduced cost. 231 International spam is likely to be even more annoying that national 232 spam, since it may arrive in languages that the recipient doesn't 233 even speak. 235 These figures assume that the primary limitation is the access 236 bandwidth and not CPU, disk, or termination costs. Termination costs 237 merit further discussion. Currently, most VoIP calls terminate on 238 the Public Switched Telephone Network (PSTN), and this termination 239 costs the originator of the call money. These costs are similar to 240 the per-minute rates of a T1. It ranges anywhere from half a cent to 241 three cents per minute, depending on volume and other factors. 242 However, equipment costs, training and other factors are much lower 243 for SIP-based termination than a T1, making the cost still lower than 244 circuit connectivity. Furthermore, the current trend in VoIP systems 245 is to make termination free for calls that never touch the PSTN, that 246 is, calls to actual SIP endpoints. Thus, as more and more SIP 247 endpoints come online, termination costs will probably drop. Until 248 then, SIP spam can be used in concert with termination services for a 249 lower cost form of traditional telemarketer calls, made to normal 250 PSTN endpoints. 252 It is useful to compare these figures with email. VoIP can deliver 253 approximately 9 successful call attempts per second. Email spam can, 254 of course, deliver more. Assuming 1 KB per email, and an upstream 255 link of 500 Kbps, a spammer can generate 62.5 messages per second. 256 This number goes down with larger messages of course. Interestingly, 257 spam filters delete large numbers of these mails, so the cost per 258 viewed message is likely to be much higher. In that sense, call spam 259 is much more attractive, since its content is much more likely to be 260 examined by a user if a call attempt is successful. 262 Another part of the cost of spamming is collecting addresses. 263 Spammers have, over time, built up immense lists of email addresses, 264 each of the form user@domain, to which spam is directed. SIP uses 265 the same form of addressing, making it likely that email addresses 266 can easily be turned into valid SIP addresses. Telephone numbers 267 also represent valid SIP addresses; in concert with a termination 268 provider, a spammer can direct SIP calls at traditional PSTN devices. 269 It is not clear whether email spammers have also been collecting 270 phone numbers as they perform their web sweeps, but it is probably 271 not hard to do so. Furthermore, unlike email addresses, phone 272 numbers are a finite address space and one that is fairly densely 273 packed. As a result, going sequentially through phone numbers is 274 likely to produce a fairly high hit rate. Thus, it seems like the 275 cost is relatively low for a spammer to obtain large numbers of SIP 276 addresses to which spam can be directed. 278 2.2. IM Spam 280 IM spam is very much like email, in terms of the costs for deploying 281 and generating spam. Assuming, for the sake of argument, a 1KB 282 message to be sent and 500 Kbps of upstream bandwidth, thats 62 283 messages per second. At $50/month, the result is 31 microcents per 284 message. This is less than voice spam, but not substantially less. 285 The cost is probably on par with email spam. However, IM is much 286 more intrusive than email. In today's systems, IMs automatically pop 287 up and present themselves to the user. Email, of course, must be 288 deliberately selected and displayed. However, most popular IM 289 systems employ white lists, which only allow IM to be delivered if 290 the sender is on the white list. Thus, whether or not IM spam will 291 be useful seems to depend a lot on the nature of the systems as the 292 network is opened up. If they are ubiquitously deployed with white- 293 list access, the value of IM spam is likely to be low. 295 It is important to point out that there are two different types of IM 296 systems: page mode and session mode. Page mode IM systems work much 297 like email, with each IM being sent as a separate message. In 298 session mode IM, there is signaling in advance of communication to 299 establish a session, and then IMs are exchanged, perhaps point-to- 300 point, as part of the session. The modality impacts the types of 301 spam techniques that can be applied. Techniques for email can be 302 applied identically to page mode IM, but session mode IM is more like 303 telephony, and many techniques (such as content filtering) are harder 304 to apply. 306 2.3. Presence Spam 308 As defined above, presence spam is the generation of bulk unsolicited 309 SUBSCRIBE messages. The cost of this is within a small constant 310 factor of IM spam so the same cost estimates can be used here. What 311 would be the effect of such spam? Most presence systems provide some 312 kind of consent framework. A watcher that has not been granted 313 permission to see the user's presence will not gain access to their 314 presence. However, the presence request is usually noted and 315 conveyed to the user, allowing them to approve or deny the request. 316 In SIP, this is done using the watcherinfo event package [7]. This 317 package allows a user to learn the identity of the watcher, in order 318 to make an authorization decision. 320 Interestingly, this provides a vehicle for conveying information to a 321 user. By generating SUBSCRIBE requests from identities such as 322 sip:please-buy-my-product@spam.example.com, brief messages can be 323 conveyed to the user, even though the sender does not have, and never 324 will receive, permission to access presence. As such, presence spam 325 can be viewed as a form of IM spam, where the amount of content to be 326 conveyed is limited. The limit is equal to the amount of information 327 generated by the watcher that gets conveyed to the user through the 328 permission system. 330 This type of spam also shows up in consent frameworks used to prevent 331 call spam, as discussed in Section 3.4. 333 3. Solution Space 335 In this section, we consider the various solutions that might be 336 possible to deal with SIP spam. We primarily consider techniques 337 that have been employed to deal with email spam. It is important to 338 note that the solutions documented below are not meant to be an 339 exhaustive study of the spam solutions used for email but rather just 340 a representative set. We also consider some solutions that appear to 341 be SIP-specific. 343 3.1. Content Filtering 345 The most common form of spam protection used in email is based on 346 content filtering. These spam filters analyze the content of the 347 email, and look for clues that the email is spam. Bayesian spam 348 filters are in this category. 350 Unfortunately, this type of spam filtering, while successful for 351 email spam, is completely useless for call spam. There are two 352 reasons. First, in the case where the user answers the call, the 353 call is already established and the user is paying attention before 354 the content is delivered. The spam cannot be analyzed before the 355 user sees it. Second, if the content is stored before the user 356 accesses it (e.g., with voicemail), the content will be in the form 357 of recorded audio or video. Speech and video recognition technology 358 is not likely to be good enough to analyze the content and determine 359 whether or not it is spam. Indeed, if a system tried to perform 360 speech recognition on a recording in order to perform such an 361 analysis, it would be easy for the spammers to make calls with 362 background noises, poor grammar and varied accents, all of which will 363 throw off recognition systems. Video recognition is even harder to 364 do and remains primarily an area of research. 366 IM spam, due to its similarity to email, can be countered with 367 content analysis tools. Indeed, the same tools and techniques used 368 for email will directly work for IM spam. 370 Content filtering is unlikely to help for presence spam because it 371 can only be applied to the relative name being used to display the 372 requester of the presence information. 374 3.2. Black Lists 376 Black listing is an approach whereby the spam filter maintains a list 377 of addresses that identify spammers. These addresses include both 378 usernames (spammer@example.com) and entire domains (example.com). 379 Pure blacklists are not very effective in email for two reasons. 380 First, email addresses are easy to spoof, making it easy for the 381 sender to pretend to be someone else. If the sender varies the 382 addresses they send from, the black list becomes almost completely 383 useless. The second problem is that, even if the sender doesn't 384 forge the from address, email addresses are in almost limitless 385 supply. Each domain contains an infinite supply of email addresses, 386 and new domains can be obtained for very low cost. Furthermore, 387 there will always be public providers that will allow users to obtain 388 identities for almost no cost (for example, Yahoo or AOL mail 389 accounts). The entire domain cannot be blacklisted because it 390 contains so many valid users. Blacklisting needs to be for 391 individual users. Those identities are easily changed. 393 As a result, as long as identities are easy to manufacture, or 394 zombies are used, black lists will have limited effectiveness for 395 email. 397 Blacklists are also likely to be ineffective for SIP spam. 398 Mechanisms for inter-domain authenticated identity for email and sip 399 are discussed in Section 4 and Section 5. Assuming these mechanisms 400 are used and enabled in inter-domain communications, it becomes 401 difficult to forge sender addresses. However, it still remains cheap 402 to obtain a nearly infinite supply of addresses. 404 3.3. White Lists 406 White lists are the opposite of black lists. It is a list of valid 407 senders that a user is willing to accept email from. Unlike black 408 lists, a spammer can not change identities to get around the white 409 list. White lists are susceptible to address spoofing, but a strong 410 identity authentication mechanism can prevent that problem. As a 411 result, the combination of white lists and strong identity, as 412 described in Section 4.2 and Section 5, are a good form of defense 413 against spam. 415 However, they are not a complete solution, since they would prohibit 416 a user from ever being able to receive email from someone who was not 417 explicitly put on the white list. As a result, white lists require a 418 solution to the "introduction problem" - how to meet someone for the 419 first time, and decide whether they should be placed in the white 420 list. In addition to the introduction problem, white lists demand 421 time from the user to manage. 423 In IM systems, white lists have proven exceptionally useful at 424 preventing spam. This is due, in no small part, to the fact that the 425 white list exists naturally in the form of the buddy list. Users 426 don't have to manage this list just for the purposes of spam 427 prevention; it provides general utility, and assists in spam 428 prevention for free. Many popular IM systems also have strong 429 identity mechanisms since they do not allow communications with IM 430 systems in other administrative domains. The introduction problem in 431 these systems is solved with a consent framework, described below. 433 The success of white lists in IM systems has applicability to SIP as 434 well. This is because SIP also provides a buddy list concept and has 435 an advanced presence system as part of its specifications. The 436 introduction problem remains. In email, techniques like the Turing 437 tests have been employed for this purpose. Those are considered 438 further in the sections below. As with email, a technique for 439 solving the introduction problem would need to be applied in 440 conjunction with a white list. 442 If a user's computer is compromised and used a zombie, that computer 443 can usually be used to send spam to anyone that has put the user on 444 their white list. 446 3.4. Consent-Based Communications 448 A consent-based solution is used in conjunction with white or black 449 lists. That is, if user A is not on user B's white or black list, 450 and user A attempts to communicate with user B, user A's attempt is 451 initially rejected, and they are told that consent is being 452 requested. Next time user B connects, user B is informed that user A 453 had attempted communications. User B can then authorize or reject 454 user A. 456 These kinds of consent-based systems are used widely in presence and 457 IM. Since most of today's popular IM systems only allow 458 communications within a single administrative domain, sender 459 identities can be authenticated. Email often uses similar consent 460 based systems for mailing lists. They use a form of authentication 461 based on sending cookies to an email address to verify that a user 462 can receive mail at that address. 464 This kind of consent-based communications has been standardized in 465 SIP for presence, using the watcher information event package [7] and 466 data format [8], which allow a user to find out that someone has 467 subscribed. Then, the XML Configuration Access Protocol (XCAP) [10] 468 is used, along with the XML format for presence authorization [11] to 469 provide permission for the user to communicate. 471 A consent framework has also been developed that is applicable to 472 other forms of SIP communications [12]. However, this framework 473 focuses on authorizing the addition of users to "mailing lists", 474 known as exploders in SIP terminology. Though spammers typically use 475 such exploder functions, presumably one run by a spammer would not 476 use this technique. Consequently, this consent framework is not 477 directly applicable to the spam problem. It is, however, useful as a 478 tool for managing a white list. Through the PUBLISH mechanism, it 479 allows a user to upload a permission document [13] which indicates 480 that they will only accept incoming calls from a particular sender. 482 Can a consent framework, like the ones used for presence, help solve 483 call spam? At first glance, it would seem to help a lot. However, 484 it might just change the nature of the spam. Instead of being 485 bothered with content, in the form of call spam or IM spam, users are 486 bothered with consent requests. A user's "communications inbox" 487 might instead be filled with requests for communications from a 488 multiplicity of users. Those requests for communications don't 489 convey much useful content to the user, but they can convey some. At 490 the very least, they will convey the identity of the requester. The 491 user part of the SIP URI allows for limited free form text, and thus 492 could be used to convey brief messages. One can imagine receiving 493 consent requests with identities like 494 "sip:please-buy-my-product-at-this-website@spam.example.com", for 495 example. Fortunately, it is possible to apply traditional content 496 filtering systems to the header fields in the SIP messages, thus 497 reducing these kinds of consent request attacks. 499 In order for the spammer to convey more extensive content to the 500 user, the user must explicitly accept the request, and only then can 501 the spammer convey the full content. This is unlike email spam, 502 where, even though much spam is automatically deleted, some 503 percentage of the content does get through, and is seen by users, 504 without their explicit consent that they want to see it. Thus, if 505 consent is required first, the value in sending spam is reduced, and 506 perhaps it will cease for those spam cases where consent is not given 507 to spammers. 509 As such, the real question is whether or not the consent system would 510 make it possible for a user to give consent to non-spammers and 511 reject spammers. Authenticated identity can help. A user in an 512 enterprise would know to give consent to senders in other enterprises 513 in the same industry, for example. However, in the consumer space, 514 if sip:bob@example.com tries to communicate with a user, how does 515 that user determine whether bob is a spammer or a long-lost friend 516 from high school? There is no way based on the identity alone. In 517 such a case, a useful technique is to grant permission for bob to 518 communicate but to ensure that the permission is extremely limited. 520 In particular, bob may be granted permission to send no more than 200 521 words of text in a single IM, which he can use to identify himself, 522 so that the user can determine whether or not more permissions are 523 appropriate. It may even be possible that an automated system could 524 do some form of content analysis on this initial short message. 525 However, this 200 words of text may be enough for a spammer to convey 526 their message, in much the same way they might convey it in the user 527 part of the SIP URI. 529 Thus, it seems that a consent-based framework, along with white lists 530 and black lists, cannot fully solve the problem for SIP, although it 531 does appear to help. 533 3.5. Reputation Systems 535 A reputation system is also used in conjunction with white or black 536 lists. Assume that user A is not on user B's white list, and A 537 attempts to contact user B. If a consent-based system is used, B is 538 prompted to consent to communications from A, and along with the 539 consent, a reputation score might be displayed in order to help B 540 decide whether or not they should accept communications from A. 542 Traditionally, reputation systems are implemented in highly 543 centralized messaging architectures; the most widespread reputation 544 systems in messaging today have been deployed by monolithic instant 545 messaging providers (though many web sites with a high degree of 546 interactivity employ very similar concepts of reputation). 547 Reputation is calculated based on user feedback. For example, a 548 button on the user interface of the messaging client might empower 549 users to inform the system that a particular user is abusive. Of 550 course, the input of any single user has to be insufficient to ruin 551 one's reputation, but consistent negative feedback would give the 552 abusive user a negative reputation score. 554 Reputation systems have been successful in systems where 555 centralization of resources (user identities, authentication, etc.) 556 and monolithic control dominate. Examples of these include the large 557 instant messaging providers that run IM system that do not exchange 558 messages with other administrative domains. That control, first of 559 all, provides a relatively strong identity assertion for users (since 560 all users trust a common provider, and the common provider is the 561 arbiter of authentication and identity). Secondly, it provides a 562 single place where reputation can be managed. 564 Reputation systems based on negative reputation scores suffer from 565 many of the same problems as black lists, since effectively the 566 consequence of having a negative reputation is that you are 567 blacklisted. If identities are very easy to acquire, a user with a 568 negative reputation will simply acquire a new one. Moreover, 569 negative reputation is generated by tattling, which requires users to 570 be annoyed enough to click the warning button. Additionally, it can 571 be abused. In some reputation systems, "reputation mafias" 572 consisting of large numbers of users routinely bully or extort 573 victims by threatening collectively to give victims a negative 574 reputation. 576 Reputation systems based on positive reputation, where users praise 577 each other for being good, rather than tattling on each other for 578 being bad, have some similar drawbacks. Collectives of spammers, or 579 just one spammer who acquires a large number identities, could praise 580 one another in order to create an artificial positive reputation. 581 Users similarly have to overcome the inertia required to press the 582 "praise" button. Unlike negative reputation systems, however, 583 positive reputation is not circumvented when users require a new 584 identity, since basing authorization decisions on positive reputation 585 is essentially a form of white listing. 587 So, while positive reputation systems are superior to negative 588 reputation systems, they are far from perfect. Intriguingly, though, 589 combining presence-based systems with reputation systems leads to an 590 interesting fusion. The "buddy-list" concept of presence is, in 591 effect, a white list - and one can therefore probably infer that the 592 users on one's buddy list are people whom you are "praising". This 593 eliminates the problem of user inertia in the use of the "praise" 594 button, and automates the initial establishment of reputation. 596 And of course, your buddies in turn have buddies. Collectively, you 597 and your buddies (and their buddies, and so on) constitute a social 598 network of reputation. If there were a way to leverage this social 599 network, it would eliminate the need for centralization of the 600 reputation system. Your perception of a particular user's reputation 601 might be dependent on your relationship to them in the social 602 network: are they one buddy removed (strong reputation), four buddies 603 removed (weaker reputation), three buddies removed but connected to 604 you through several of your buddies, etc. This web of trust 605 furthermore would have the very desirable property that circles of 606 spammers adding one another to their own buddy lists would not affect 607 your perception of their reputation unless their circle linked to 608 your own social network. 610 If a users machine is compromised and turned into a zombie, this 611 allows SPAM to be sent and may impact their reputation in a negative 612 way. Once their reputation decreases, it becomes extremely difficult 613 to reestablish a positive reputation. 615 3.6. Address Obfuscation 617 Spammers build up their spam lists by gathering email addresses from 618 web sites and other public sources of information. One way to 619 minimize spam is to make your address difficult or impossible to 620 gather. Spam bots typically look for text in pages of the form 621 "user@domain", and assume that anything of that form is an email 622 address. To hide from such spam bots, many websites have recently 623 begun placing email addresses in an obfuscated form, usable to humans 624 but difficult for an automata to read as an email address. Examples 625 include forms such as, "user at example dot com" or "j d r o s e n a 626 t e x a m p l e d o t c o m". 628 These techniques are equally applicable to prevention of SIP spam, 629 and are likely to be as equally effective or ineffective in its 630 prevention. 632 It is worth mentioning that the source of addresses need not be a web 633 site - any publicly accessible service containing addresses will 634 suffice. As a result, ENUM [9] has been cited as a potential gold 635 mine for spammers. It would allow a spammer to collect SIP and other 636 URIs by traversing the tree in e164.arpa and mining it for data. 637 This problem is mitigated in part if only number prefixes, as opposed 638 to actual numbers, appear in the DNS. Even in that case, however, it 639 provides a technique for a spammer to learn which phone numbers are 640 reachable through cheaper direct SIP connectivity. 642 3.7. Limited Use Addresses 644 A related technique to address obfuscation is limited use addresses. 645 In this technique, a user has a large number of email addresses at 646 their disposal, each of which has constraints on its applicability. 647 A limited use address can be time-bound, so that it expires after a 648 fixed period. Or, a different email address can be given to each 649 correspondent. When spam arrives from that correspondent, the 650 limited use address they were given is terminated. In another 651 variation, the same limited use address is given to multiple users 652 that share some property; for example, all work colleagues, all 653 coworkers from different companies, all retailers, and so on. Should 654 spam begin arriving on one of the addresses, it is invalidated, 655 preventing communications from anyone else that received the limited 656 use address. 658 This technique is equally applicable to SIP. One of the drawbacks of 659 the approach is that it can make it hard for people to reach you; if 660 an email address you hand out to a friend becomes spammed, changing 661 it requires you to inform your friend of the new address. SIP can 662 help solve this problem in part, by making use of presence [6]. 664 Instead of handing out your email address to your friends, you would 665 hand out your presence URI. When a friend wants to send you an 666 email, they subscribe to your presence (indeed, they are likely 667 continuously subscribed from a buddy list application). The presence 668 data can include an email address where you can be reached. This 669 email address can be obfuscated and be of single use, different for 670 each buddy who requests your presence. They can also be constantly 671 changed, as these changes are pushed directly to your buddies. In a 672 sense, the buddy list represents an automatically updated address 673 book, and would therefore eliminate the problem. 675 Another approach is to give a different address to each and every 676 correspondent, so that it is never necessary to tell a "good" user 677 that an address needs to be changed. This is an extreme form of 678 limited use addresses, which can be called a single-use address. 679 Mechanisms are available in SIP for the generation of [16] an 680 infinite supply of single use addresses. However, the hard part 681 remains a useful mechanism for distribution and management of those 682 addresses. 684 3.8. Turing Tests 686 In email, Turing tests are those solutions whereby the sender of the 687 message is given some kind of puzzle or challenge, which only a human 688 can answer (since Turing tests rely on video or audio puzzles, they 689 sometimes cannot be solved by individuals with handicaps). These 690 tests are also known as captchas (Completely Automated Public Turing 691 test to tell Computers and Humans Apart). If the puzzle is answered 692 correctly, the sender is placed on the user's white list. These 693 puzzles frequently take the form of recognizing a word or sequence of 694 numbers in an image with a lot of background noise. The tests need 695 to be designed such that automata cannot easily perform the image 696 recognition needed to extract the word or number sequence, but a 697 human user usually can. Designing such tests is not easy, since 698 ongoing advances in image processing and artificial intelligence 699 continually raise the bar. Consequently, the effectiveness of 700 captchas are tied to whether spammers can come up with or obtain 701 algorithms for automatically solving them. 703 Like many of the other email techniques, Turing tests are dependent 704 on sender identity, which cannot easily be authenticated in email. 706 Turing tests can be used to prevent IM spam in much the same way they 707 can be used to prevent email spam. 709 Turing tests can be applied to call spam as well, although not 710 directly, because call spam does not usually involve the transfer of 711 images and other content that can be used to verify that a human is 712 on the other end. If most of the calls are voice, the technique 713 needs to be adapted to voice. This is not that difficult to do. 714 Here is how it could be done. User A calls user B and is not on user 715 B's white or black list. User A is transferred to an Interactive 716 Voice Response (IVR) system. The IVR system tells the user that they 717 are going to hear a series of numbers (say 5 of them), and that they 718 have to enter those numbers on the keypad. The IVR system reads out 719 the numbers while background music is playing, making it difficult 720 for an automated speech recognition system to be applied to the 721 media. The user then enters the numbers on their keypad. If they 722 are entered correctly, the user is added to the white list. 724 This kind of voice-based Turing test is easily extended to a variety 725 of media, such as video and text, and user interfaces by making use 726 of the SIP application interaction framework [14]. This framework 727 allows client devices to interact with applications in the network, 728 where such interaction is done with stimulus signaling, including 729 keypads (supported with the Keypad Markup Language [15]), but also 730 including web browsers, voice recognition, and so on. The framework 731 allows the application to determine the media capabilities of the 732 device (or user, in cases where they are handicapped) and interact 733 with them appropriately. 735 In the case of voice, the Turing test would need to be made to run in 736 the language of the caller. This is possible in SIP, using the 737 Accept-Language header field, though this is not widely used at the 738 moment, and meant for languages of SIP message components, not the 739 media streams. 741 The primary problem with the voice Turing test is the same one that 742 email tests have: instead of having an automata process the test, a 743 spammer can pay cheap workers to take the tests. Assuming cheap 744 labor in a poor country can be obtained for about 60 cents per hour, 745 and assuming a Turing test of 30 second duration, this is about 0.50 746 cents per test and thus 0.50 cents per message to send an IM spam. 747 Lower labor rates would reduce this further; the number quoted here 748 is based on real online bids in September of 2006 made for actual 749 work of this type. 751 As an alternative to paying cheap workers to take the tests, the 752 tests can be taken by human users that are tricked into completing 753 the tests in order to gain access to what they believe is a 754 legitimate resource. This was done by a spambot that posted the 755 tests on a pornography site, and required users to complete the tests 756 in order to gain access to content. 758 Due to these limitations, Turing tests may never completely solve the 759 problem. 761 3.9. Computational Puzzles 763 This technique is similar to Turing tests. When user A tries to 764 communicate with user B, user B asks user A to perform a computation 765 and pass the result back. This computation has to be something a 766 human user cannot perform and something expensive enough to increase 767 user A's cost to communicate. This cost increase has to be high 768 enough to make it prohibitively expensive for spammers but 769 inconsequential for legitimate users. 771 One of the problems with the technique is that there is wide 772 variation in the computational power of the various clients that 773 might legitimately communicate. The CPU speed on a low end cell 774 phone is around 50 MHz, while a high end PC approaches 5 GHz. This 775 represents almost two orders of magnitude difference. Thus, if the 776 test is designed to be reasonable for a cell phone to perform, it is 777 two orders of magnitude cheaper to perform for a spammer on a high 778 end machine. Recent research has focused on defining computational 779 puzzles that challenge the CPU/memory bandwidth, as opposed to just 780 the CPU [26]. It seems that there is less variety in the CPU/memory 781 bandwidth across devices, roughly a single order of magnitude. 783 Recent work [28] suggests that, due to the ability of spammers to use 784 virus-infected machines (also known as zombies) to generate the spam, 785 the amount of computational power available to the spammers is 786 substantial, and it may be impossible to have them compute a puzzle 787 that is sufficiently hard that will not also block normal emails. If 788 combined with white listing, computational puzzles would only be 789 utilized for new communications partners. Of course, if the partner 790 on the white list is a zombie, spam will come from that source. The 791 frequency of communications with new partners is arguably higher for 792 email than for multimedia, and thus the computational puzzle 793 techniques may be more effective for SIP than for email in dealing 794 with the introduction problem. 796 These techniques are an active area of research right now, and any 797 results for email are likely to be usable for SIP. 799 3.10. Payments at Risk 801 This approach has been proposed for email [27]. When user A sends 802 email to user B, user A deposits a small amount of money (say, one 803 dollar) into user B's account. If user B decides that the message is 804 not spam, user B refunds this money back to user A. If the message is 805 spam, user B keeps the money. This technique requires two 806 transactions to complete: a transfer from A to B, and a transfer from 807 B back to A. The first transfer has to occur before the message can 808 be received in order to avoid reuse of "pending payments" across 809 several messages, which would eliminate the utility of the solution. 810 The second one then needs to occur when the message is found not to 811 be spam. 813 This technique appears just as applicable to call spam and IM spam as 814 it is to email spam. Like many of the other techniques, this 815 exchange would only happen the first time you talk to people. Its 816 proper operation therefore requires a good authenticated identity 817 infrastructure. 819 This technique has the potential make it arbitrarily expensive to 820 send spam of any sort. However, it relies on cheap micro-payment 821 techniques on the Internet. Traditional costs for internet payments 822 are around 25 cents per transaction, which would probably be 823 prohibitive. However, recent providers have been willing to charge 824 15% of the transaction for small transactions, as small as one cent. 825 This cost would have to be shouldered by users of the system. The 826 cost that would need to be shouldered per user is equal to the number 827 of messages from unknown senders (that is, senders not on the white 828 list) that are received. For a busy user, assume about 10 new 829 senders per day. If the deposit is 5 cents, the transaction provider 830 would take 0.75 cents and deliver 4.25 cents. If the sender is 831 allowed, the recipient returns 4.25 cents, the provider takes 0.64 832 cents, and returns 3.6 cents. This costs the sender 0.65 cents on 833 each transaction, if it was legitimate. If there are ten new 834 recipients per day, thats US $1.95 per month, which is relatively 835 inexpensive. 837 Assuming a micro-payment infrastructure exists, another problem with 838 payment-at-risk is that it loses effectiveness when there are strong 839 inequities in the value of currency between sender and recipient. 840 For example, a poor person in a third world country might keep the 841 money in each mail message, regardless if it is spam. Similarly, a 842 poor person might not be willing to include money in an email, even 843 if legitimate, for fear that the recipient might keep it. If the 844 amount of money is lowered to help handle these problems, it might 845 become sufficiently small that spammers can just afford to spend it. 847 3.11. Legal Action 849 In this solution, countries pass laws that prohibit spam. These laws 850 could apply to IM or call spam just as easily as they could apply to 851 email spam. There is a lot of debate about whether these laws would 852 really be effective in preventing spam. 854 As a recent example in the US, "do not call" lists seem to be 855 effective. However, due to the current cost of long distance phone 856 calls, the telemarketing is coming from companies within the US. As 857 such, calls from such telemarketers can be traced. If a telemarketer 858 violates the "do not call" list, the trace allows legal action to be 859 taken against them. A similar "do not irritate" list for VoIP or for 860 email would be less likely to work because the spam is likely to come 861 from international sources. This problem could be obviated if there 862 was a strong way to identify the sender's legal entity, and then 863 determine whether it was in a jurisdiction where it was practical to 864 take legal action against them. If the spammer is not in such a 865 jurisdiction, the SIP spam could be rejected. 867 There are also schemes that cause laws other than anti-spam laws to 868 be broken if spam is sent. This does not inherently reduce SPAM, but 869 it allows more legal options to be brought to bear against the 870 spammer. For example, Habeas inserts 871 material in the header that, if it was inserted by a spammer without 872 an appropriate license, would allegedly causes the spammer to violate 873 US copyright and trademark laws, possibly reciprocal laws, and 874 similar laws in many countries. 876 3.12. Circles of Trust 878 In this model, a group of domains (e.g., a set of enterprises) all 879 get together. They agree to exchange SIP calls amongst each other, 880 and they also agree to introduce a fine should any one of them be 881 caught spamming. Each company would then enact measures to terminate 882 employees who spam from their accounts. 884 This technique relies on secure inter-domain authentication - that 885 is, domain B can know that messages are received from domain A. In 886 SIP, this is readily provided by usage of the mutually authenticated 887 Transport Level Security (TLS)[22] between providers or SIP Identity. 889 This kind of technique works well for small domains or small sets of 890 providers, where these policies can be easily enforced. However, it 891 is unclear how well it scales up. Could a very large domain truly 892 prevent its users from spamming? At what point would the network be 893 large enough that it would be worthwhile to send spam and just pay 894 the fine? How would the pricing be structured to allow both small 895 and large domains alike to participate? 897 3.13. Centralized SIP Providers 899 This technique is a variation on the circles of trust described in 900 Section 3.12. A small number of providers get established as "inter- 901 domain SIP providers". These providers act as a SIP-equivalent to 902 the interexchange carriers in the PSTN. Every enterprise, consumer 903 SIP provider or other SIP network (call these the local SIP 904 providers) connects to one of these inter-domain providers. The 905 local SIP providers only accept SIP messages from their chosen inter- 906 domain provider. The inter-domain provider charges the local 907 provider, per SIP message, for the delivery of SIP messages to other 908 local providers. The local provider can choose to pass on this cost 909 to its own customers if it so chooses. 911 The inter-domain SIP providers then form bi-lateral agreements with 912 each other, exchanging SIP messages according to strict contracts. 913 These contracts require that each of the inter-domain providers be 914 responsible for charging a minimum per-message fee to their own 915 customers. Extensive auditing procedures can be put into place to 916 verify this. Besides such contracts, there may or may not be a flow 917 of funds between the inter-domain providers. 919 The result of such a system is that a fixed cost can be associated 920 with sending a SIP message, and that this cost does not require 921 micro-payments to be exchanged between local providers, as it does in 922 Section 3.10. Since all of the relationships are pre-established and 923 negotiated, cheaper techniques for monetary transactions (such as 924 monthly post-paid transactions) can be used. 926 This technique can be made to work in SIP, whereas it cannot in 927 email, because inter-domain SIP connectivity has not yet been broadly 928 established. In email, there already exists a no-cost form of inter- 929 domain connectivity that cannot be eliminated without destroying the 930 utility of email. If, however, SIP inter-domain communications get 931 established from the start using this structure, there is a path to 932 deployment. 934 This structure is more or less the same as the one in place for the 935 PSTN today, and since there is relatively little spam on the PSTN 936 (compared to email!), there is some proof that this kind of 937 arrangement can work. However, centralized architectures as these 938 are deliberately eschewed because they put back into SIP much of the 939 complexity and monopolistic structures that the protocol aims to 940 eliminate. 942 4. Authenticated Identity in Email 944 Though not a form of anti-spam in and of itself, authenticated or 945 verifiable identities are a key part of making other anti-spam 946 mechanisms work. Many of the techniques described above are most 947 effective when combined with a white or black list, which itself 948 requires a strong form of identity. 950 In email, two types of authenticated identity have been developed - 951 sender checks and signature-based solutions. 953 4.1. Sender Checks 955 In email, DNS resource records have been defined that will allow a 956 domain that receives a message to verify that the sender is a valid 957 Message Transfer Agent (MTA) for the sending domain [18] [19] [20] 958 [21]. They don't prevent spam by themselves, but may help in 959 preventing spoofed emails. As has been mentioned several times, a 960 form of strong authenticated identity is key in making many other 961 anti-spam techniques work. 963 Are these techniques useful for SIP? They can be used for SIP but 964 are not necessary. In SIP, TLS with mutual authentication can be 965 used inter-domain. A provider receiving a message can then reject 966 any message coming from a domain that does not match the asserted 967 identity of the sender of the message. Such a policy only works in 968 the "trapezoid" model of SIP, whereby there are only two domains in 969 any call - the sending domain, which is where the originator resides, 970 and the receiving domain. These techniques are discussed in Section 971 26.3.2.2 of RFC 3261 [2]. In forwarding situations, the assumption 972 no longer holds and these techniques no longer work. However, the 973 authenticated identity mechanism for SIP, discussed in Section 5, 974 does work in more complex network configurations and provides fairly 975 strong assertion of identity. 977 4.2. Signature-Based Techniques 979 Domain Keys Identified Mail (DKIM) Signatures[23] (and several non- 980 standard techniques that preceded it) provide strong identity 981 assertions by allowing the sending domain to sign an email, and then 982 providing mechanisms by which the receiving MTA or Mail User Agent 983 (MUA) can validate the signature. 985 Unfortunately, when used with blacklists, this kind of authenticated 986 identity is only as useful as the fraction of the emails which 987 utilize it. This is partly true for white lists as well; if any 988 unauthenticated email is accepted for an address on a white list, a 989 spammer can spoof that address. However a white list can be 990 effective with limited deployment of DKIM if all of the people on the 991 white list are those whose domains are utilizing the mechanism, and 992 the users on that whitelist aren't zombies. 994 This kind of identity mechanism is also applicable to SIP, and is in 995 fact exactly what is defined by SIP's authenticated identity 996 mechanism [17]. 998 Other signature based approaches for email include S/MIME[24] and 999 OpenPGP[25]. 1001 5. Authenticated Identity in SIP 1003 One of the key parts of many of the solutions described above is the 1004 ability to securely identify the sender of a SIP message. SIP 1005 provides a secure solution for this problem, called SIP Identity 1006 [17], and it is important to discuss it here. 1008 The solution starts by having each domain authenticate its own users. 1009 SIP provides HTTP digest authentication as part of the core SIP 1010 specification, and all clients and servers are required to support 1011 it. Indeed, digest is widely deployed for SIP. However, digest 1012 alone has many known vulnerabilities, most notably offline dictionary 1013 attacks. These vulnerabilities are all resolved by having each 1014 client maintain a persistent TLS connection to the server. The 1015 client verifies the server identity using TLS, and then authenticates 1016 itself to the server using a digest exchange over TLS. This 1017 technique, which is also documented in RFC 3261, is very secure but 1018 not widely deployed yet. In the long term, this approach will be 1019 necessary for the security properties needed to prevent SIP spam. 1021 Once a domain has authenticated the identity of a user, when it 1022 relays a message from that user to another domain, the sending domain 1023 can assert the identity of the sender, and include a signature to 1024 validate that assertion. This is done using the SIP identity 1025 mechanism [17]. 1027 A weaker form of identity assertion is possible using the P-Asserted- 1028 Identity header field [5], but this technique requires mutual trust 1029 among all domains. Unfortunately, this becomes exponentially harder 1030 to provide as the number of interconnected domains grows. As that 1031 happens, the value of the identity assertion becomes equal to the 1032 trustworthiness of the least trustworthy domain. Since spam is a 1033 consequence of the receiving domain not being able to trust the 1034 sending domains to disallow the hosts in the sending to send spam, 1035 the P-Asserted-Identity technique becomes ineffective at exactly the 1036 same levels of interconnectness that introduce spam. 1038 Consider the following example to help illustrate this fact. A 1039 malicious domain, let us call them spam.example.com, would like to 1040 send SIP INVITE requests with false P-Asserted-Identity, indicating 1041 users outside of its own domain. spam.example.com finds a regional 1042 SIP provider in a small country who, due to its small size and 1043 disinterest in spam, accepts any P-Asserted-Identity from its 1044 customers without verification. This provider, in turn, connects to 1045 a larger, interconnect provider. They do ask each of their customers 1046 to verify P-Asserted-Identity but have no easy way of enforcing it. 1047 This provider, in turn, connects to everyone else. As a consequence, 1048 the spam.example.com domain is able to inject calls with a spoofed 1049 called ID. This request can be directed to any recipient reachable 1050 through the network (presumably everyone due to the large size of the 1051 root provider). There is no way for a recipient to know that this 1052 particular P-Asserted-Identity came from this bad spam.example.com 1053 domain. As the example shows, even though the central provider's 1054 policy is good, the overall effectiveness of P-Asserted-Identity is 1055 still only as good as the policies of the weakest link in the chain. 1057 SIP also defines the usage of TLS between domains, using mutual 1058 authentication, as part of the base specification. This technique 1059 provides a way for one domain to securely determine that it is 1060 talking to a server that is a valid representative of another domain. 1062 6. Framework for Anti-Spam in SIP 1064 Unfortunately, there is no magic bullet for preventing SIP spam, just 1065 as there is none for email spam. However, the combination of several 1066 techniques can provide a framework for dealing with spam in SIP. 1067 This section provides recommendations for network designers in order 1068 to help mitigate the risk of spam. 1070 There are four core recommendations that can be made: 1072 Strong Identity: Firstly, in almost all of the solutions discussed 1073 above, there is a dependency on the ability to authenticate the 1074 sender of a SIP message inter-domain. Consent, reputation 1075 systems, computational puzzles, and payments at risk, amongst 1076 others, all work best when applied only to new requests, and 1077 successful completion of an introduction results in the placement 1078 of a user on a white list. However, usage of white lists depends 1079 on strong identity assertions. Consequently, any network that 1080 interconnects with others should make use of strong SIP identity 1081 as described in RFC 4474. P-Asserted-Identity is not strong 1082 enough. 1084 White Lists: Secondly, with a strong identity system in place, 1085 networks are recommended to make use of white lists. These are 1086 ideally built off existing buddy lists if present. If not, 1087 separate white lists can be managed for spam. Placement on these 1088 lists can be manual or based on the successful completion of one 1089 or more introduction mechanisms. 1091 Solve the Introduction Problem: This in turn leads to the final 1092 recommendation to be made. Network designers should make use of 1093 one or more mechanisms meant to solve the introduction problem. 1094 Indeed, it is possible to use more than one and combine the 1095 results through some kind of weight. A user that successfully 1096 completes the introduction mechanism can be automatically added to 1097 the white list. Of course, that can only be done usefully if 1098 their identity is verified by SIP Identity. The set of mechanisms 1099 for solving the introduction problem, as described in this 1100 document, are based on some (but not all) of the techniques known 1101 and used at the time of writing. Providers of SIP services should 1102 keep tabs on solutions in email as they evolve, and utilize the 1103 best of what those techniques have to offer. 1105 Don't Wait Until its Too Late: But perhaps most importantly, 1106 providers should not ignore the spam problem until it happens! As 1107 soon as a provider inter-connects with other providers, or allows 1108 SIP messages from the open Internet, that provider must consider 1109 how they will deal with spam. 1111 7. Additional Work 1113 Though the above framework serves as a good foundation on which to 1114 deal with spam in SIP, there are gaps, some of which can be addressed 1115 by additional work that has yet to be undertaken. 1117 One of the difficulties with the strong identity techniques is that a 1118 receiver of a SIP request without an authenticated identity cannot 1119 know whether the request lacked such an identity because the 1120 originating domain didn't support it, or because a man-in-the-middle 1121 removed it. As a result, transition mechanisms should be put in 1122 place to allow these to be differentiated. Without it, the value of 1123 the identity mechanism is much reduced. 1125 8. Security Considerations 1127 This document is entirely devoted to issues relating to spam in SIP 1128 and references a variety of security mechanisms in support of that 1129 goal. 1131 9. IANA Considerations 1133 There are no IANA considerations associated with this specification. 1135 10. Acknowledgements 1137 The authors would like to thank Rohan Mahy for providing information 1138 on Habeas, Baruch Sterman for providing costs on VoIP termination 1139 services, and Gonzalo Camarillo and Vijay Gurbani for their reviews. 1141 Useful comments and feedback were provided by Nils Ohlmeir, Tony 1142 Finch, Randy Gellens, Lisa Dusseault, Sam Hartman, Chris Newman, Tim 1143 Polk, Donald Eastlake, and Yakov Shafranovich. Jon Peterson wrote 1144 some of the text in this document and has contributed to the work as 1145 it has moved along. 1147 11. Informative References 1149 [1] Campbell, B., "The Message Session Relay Protocol", 1150 draft-ietf-simple-message-sessions-19 (work in progress), 1151 February 2007. 1153 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1154 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1155 Session Initiation Protocol", RFC 3261, June 2002. 1157 [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 1158 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1159 Instant Messaging", RFC 3428, December 2002. 1161 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1162 Notification", RFC 3265, June 2002. 1164 [5] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 1165 to the Session Initiation Protocol (SIP) for Asserted Identity 1166 within Trusted Networks", RFC 3325, November 2002. 1168 [6] Rosenberg, J., "A Presence Event Package for the Session 1169 Initiation Protocol (SIP)", RFC 3856, August 2004. 1171 [7] Rosenberg, J., "A Watcher Information Event Template-Package 1172 for the Session Initiation Protocol (SIP)", RFC 3857, 1173 August 2004. 1175 [8] Rosenberg, J., "An Extensible Markup Language (XML) Based 1176 Format for Watcher Information", RFC 3858, August 2004. 1178 [9] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 1179 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 1180 Application (ENUM)", RFC 3761, April 2004. 1182 [10] Rosenberg, J., "The Extensible Markup Language (XML) 1183 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1185 [11] Rosenberg, J., "Presence Authorization Rules", 1186 draft-ietf-simple-presence-rules-09 (work in progress), 1187 March 2007. 1189 [12] Rosenberg, J., "A Framework for Consent-Based Communications in 1190 the Session Initiation Protocol (SIP)", 1191 draft-ietf-sip-consent-framework-01 (work in progress), 1192 November 2006. 1194 [13] Camarillo, G., "A Document Format for Requesting Consent", 1195 draft-ietf-sipping-consent-format-03 (work in progress), 1196 April 2007. 1198 [14] Rosenberg, J., "A Framework for Application Interaction in the 1199 Session Initiation Protocol (SIP)", 1200 draft-ietf-sipping-app-interaction-framework-05 (work in 1201 progress), July 2005. 1203 [15] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) 1204 Event Package for Key Press Stimulus (KPML)", RFC 4730, 1205 November 2006. 1207 [16] Rosenberg, J., "Applying Loose Routing to Session Initiation 1208 Protocol (SIP) User Agents (UA)", 1209 draft-rosenberg-sip-ua-loose-route-01 (work in progress), 1210 June 2007. 1212 [17] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1213 Identity Management in the Session Initiation Protocol (SIP)", 1214 RFC 4474, August 2006. 1216 [18] Allman, E. and H. Katz, "SMTP Service Extension for Indicating 1217 the Responsible Submitter of an E-Mail Message", RFC 4405, 1218 April 2006. 1220 [19] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 1221 RFC 4406, April 2006. 1223 [20] Lyon, J., "Purported Responsible Address in E-Mail Messages", 1224 RFC 4407, April 2006. 1226 [21] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for 1227 Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, 1228 April 2006. 1230 [22] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 1231 Protocol Version 1.1", RFC 4346, April 2006. 1233 [23] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and 1234 M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", 1235 RFC 4871, May 2007. 1237 [24] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 1238 (S/MIME) Version 3.1 Message Specification", RFC 3851, 1239 July 2004. 1241 [25] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME 1242 Security with OpenPGP", RFC 3156, August 2001. 1244 [26] Abadi, M., Burrows, M., Manasse, M., and T. Wobber, "Moderately 1245 Hard, Memory Bound Functions, NDSS 2003", February 2003. 1247 [27] Abadi, M., Burrows, M., Birrell, A., Dabek, F., and T. Wobber, 1248 "Bankable Postage for Network Services, Proceedings of the 8th 1249 Asian Computing Science Conference, Mumbai, India", 1250 December 2003. 1252 [28] Clayton, R. and B. Laurie, "Proof of Work Proves not to Work, 1253 Third Annual Workshop on Economics and Information Security", 1254 May 2004. 1256 Authors' Addresses 1258 Jonathan Rosenberg 1259 Cisco 1260 600 Lanidex Plaza 1261 Parsippany, NJ 07054 1262 US 1264 Phone: +1 973 952-5000 1265 Email: jdrosen@cisco.com 1266 URI: http://www.jdrosen.net 1268 Cullen Jennings 1269 Cisco 1270 170 West Tasman Dr. 1271 San Jose, CA 95134 1272 US 1274 Phone: +1 408 421-9990 1275 Email: fluffy@cisco.com 1277 Full Copyright Statement 1279 Copyright (C) The IETF Trust (2007). 1281 This document is subject to the rights, licenses and restrictions 1282 contained in BCP 78, and except as set forth therein, the authors 1283 retain all their rights. 1285 This document and the information contained herein are provided on an 1286 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1287 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1288 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1289 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1290 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1291 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1293 Intellectual Property 1295 The IETF takes no position regarding the validity or scope of any 1296 Intellectual Property Rights or other rights that might be claimed to 1297 pertain to the implementation or use of the technology described in 1298 this document or the extent to which any license under such rights 1299 might or might not be available; nor does it represent that it has 1300 made any independent effort to identify any such rights. Information 1301 on the procedures with respect to rights in RFC documents can be 1302 found in BCP 78 and BCP 79. 1304 Copies of IPR disclosures made to the IETF Secretariat and any 1305 assurances of licenses to be made available, or the result of an 1306 attempt made to obtain a general license or permission for the use of 1307 such proprietary rights by implementers or users of this 1308 specification can be obtained from the IETF on-line IPR repository at 1309 http://www.ietf.org/ipr. 1311 The IETF invites any interested party to bring to its attention any 1312 copyrights, patents or patent applications, or other proprietary 1313 rights that may cover technology that may be required to implement 1314 this standard. Please address the information to the IETF at 1315 ietf-ipr@ietf.org. 1317 Acknowledgment 1319 Funding for the RFC Editor function is provided by the IETF 1320 Administrative Support Activity (IASA).