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