idnits 2.17.1 draft-ietf-sipping-spam-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1158. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1165. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1171. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2006) is 6624 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) == Unused Reference: '5' is defined on line 1052, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-14 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '4') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 3761 (ref. '10') (Obsoleted by RFC 6116, RFC 6117) == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-08 == Outdated reference: A later version (-10) exists of draft-ietf-simple-presence-rules-04 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-consent-framework-04 == Outdated reference: A later version (-08) exists of draft-ietf-sipping-kpml-07 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 9 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: September 7, 2006 Cisco 5 J. Peterson 6 Neustar 7 March 6, 2006 9 The Session Initiation Protocol (SIP) and Spam 10 draft-ietf-sipping-spam-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 7, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Spam, defined as the transmission of bulk unsolicited messages, has 44 plagued Internet email. Unfortunately, spam is not limited to email. 45 It can affect any system that enables user to user communications. 46 The Session Initiation Protocol (SIP) defines a system for user to 47 user multimedia communications. Therefore, it is susceptible to 48 spam, just as email is. In this document, we analyze the problem of 49 spam in SIP. We first identify the ways in which the problem is the 50 same and the ways in which it is different from email. We then 51 examine the various possible solutions that have been discussed for 52 email and consider their applicability to SIP. Discussions on this 53 draft should be directed at sipping@ietf.org. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Problem Definition . . . . . . . . . . . . . . . . . . . . . 3 59 2.1 Call Spam . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2 IM Spam . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 2.3 Presence Spam . . . . . . . . . . . . . . . . . . . . . . 7 62 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.1 Content Filtering . . . . . . . . . . . . . . . . . . . . 8 64 3.2 Black Lists . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.3 White Lists . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.4 Consent-Based Communications . . . . . . . . . . . . . . . 10 67 3.5 Reputation Systems . . . . . . . . . . . . . . . . . . . . 11 68 3.6 Address Obfuscation . . . . . . . . . . . . . . . . . . . 13 69 3.7 Limited Use Addresses . . . . . . . . . . . . . . . . . . 14 70 3.8 Turing Tests . . . . . . . . . . . . . . . . . . . . . . . 14 71 3.9 Computational Puzzles . . . . . . . . . . . . . . . . . . 16 72 3.10 Payments at Risk . . . . . . . . . . . . . . . . . . . . 16 73 3.11 Legal Action . . . . . . . . . . . . . . . . . . . . . . 17 74 3.12 Circles of Trust . . . . . . . . . . . . . . . . . . . . 18 75 3.13 Centralized SIP Providers . . . . . . . . . . . . . . . 18 76 3.14 Sender Checks . . . . . . . . . . . . . . . . . . . . . 19 77 4. Authenticated Identity in SIP . . . . . . . . . . . . . . . 20 78 5. Framework for Anti-Spam in SIP . . . . . . . . . . . . . . . 21 79 6. Additional Work . . . . . . . . . . . . . . . . . . . . . . 22 80 7. Security Considerations . . . . . . . . . . . . . . . . . . 22 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 82 9. Informative References . . . . . . . . . . . . . . . . . . . 22 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24 84 Intellectual Property and Copyright Statements . . . . . . . 26 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. Although it has seen widespread deployment, 98 the deployments today have mostly been in disconnected islands. 99 Providers have not yet connected to each other in significant ways, 100 nor have they yet opened up access so as to allow receipt of SIP 101 messaging from the open Internet. Possibly as a result of this, SIP 102 networks have not yet been the target of any significant amount of 103 spam. However, we believe that it is just a matter of time. 105 It is important that the SIP community react now, rather than later, 106 and define and deploy anti-spam measures before the problem arises. 107 This document serves to help frame the problem of spam in SIP and 108 analyze the solution space in order to help determine a path forward. 110 2. Problem Definition 112 The spam problem in email is well understood, and we make no attempt 113 to further elaborate on it here. The question, however, is what is 114 the meaning of spam when applied to SIP? Since SIP covers a broad 115 range of functionality, there appear to be three related but 116 different manifestations: 118 Call Spam: This type of spam is defined as a bulk unsolicited set of 119 session initiation attempts (i.e., INVITE requests), attempting to 120 establish a voice, video, instant messaging [1] or other type of 121 communications session. If the user should answer, the spammer 122 proceeds to relay their message over the real time media. This is 123 the classic telemarketer spam, applied to SIP. 125 IM Spam: This type of spam is similar to email. It is defined as a 126 bulk unsolicited set of instant messages, whose content contains 127 the message that the spammer is seeking to convey. IM spam is 128 most naturally sent using the SIP MESSAGE [3] request. However, 129 any other request which causes content to automatically appear on 130 the user's display will also suffice. That might include INVITE 131 requests with large Subject headers (since the Subject is 132 sometimes rendered to the user), or INVITE requests with text or 133 HTML bodies. 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 [7]), 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. 141 There are many other SIP messages that a spammer might send. 142 However, most of the other ones do not result in content being 143 delivered to a user, nor do they seek input from a user. Rather, 144 they are answered by automata. OPTIONS is a good example of this. 145 There is little value for a spammer in sending an OPTIONS request, 146 since it is answered automatically by the UAS. No content is 147 delivered to the user, and they are not consulted. 149 In the sections below, we consider the likelihood of these various 150 forms of SIP spam. This is done in some cases by a rough cost 151 analysis. It should be noted that all of these analyses are 152 approximate, and serve only to give a rough sense of the order of 153 magnitude of the problem. 155 2.1 Call Spam 157 Will call spam occur? That is an important question to answer. 158 Clearly, it does occur in the existing telephone network, in the form 159 of telemarketer calls. Although these calls are annoying, they do 160 not arrive in the same kind of volume as email spam. The difference 161 is cost; it costs more for the spammer to make a phone call than it 162 does to send email. This cost manifests itself in terms of the cost 163 for systems which can perform telemarketer call, and in cost per 164 call. 166 Both of these costs are substantially reduced by SIP. A SIP call 167 spam application is easy to write. It is just a UAC that initiates, 168 in parallel, a large number of calls. If a call connects, the spam 169 application generates an ACK and proceeds to play out a recorded 170 announcement, and then it terminates the call. This kind of 171 application can be built entirely in software, using readily 172 available (and indeed, free) off the shelf components. It can run on 173 a low end PC and requires no special expertise to execute. 175 The cost per call is also substantially reduced. A normal 176 residential phone line allows only one call to be placed at a time. 177 If additional lines are required, a user must purchase more expensive 178 connectivity. Typically, a T1 or T3 would be required for a large 179 volume telemarketing service. That kind of access is very expensive 180 and well beyond the reach of an average user. A T1 line is 181 approximately US $250 per month, and about 1.5 cents per minute for 182 calls. T1 lines used only for outbound calls (such as in this case) 183 are even more expensive than inbound trunks due to the reciprocal 184 termination charges that a provider pays and receives. 186 There are two aspects to the capacity: the call attempt rate, and the 187 number of simultaneous successful calls that can be in progress. A 188 T1 would allow a spammer at most 24 simultaneous calls, and assuming 189 about 10s for each call attempt, about 2.4 call attempts per second. 190 At high volume calling, the per-minute rates far exceed the flat 191 monthly fee for the T1. The result is a cost of 250,000 microcents 192 for each successful spam delivery, assuming 10s of content. 194 With SIP, this cost is much reduced. Consider a spammer using a 195 typical broadband Internet connection that provides 500Kbps of 196 upstream bandwidth. Initiating a call requires just a single INVITE 197 message. Assuming, for simplicity's sake, that this is 1kB, a 198 500Kbps upstream DSL or cable modem connection will allow about 62 199 call attempts per second. A successful call requires enough 200 bandwidth to transmit a message to the receiver. Assuming a low 201 compression codec (say, G.723.1 at 5.6 Kbps), as many as 90 202 simultaneous calls can be in progress. With 10s of content per call, 203 that allows for 9 successful call attempts per second. This means 204 that a system could deliver a voice message successfully to users at 205 a rate of around 9 per second. If broadband access is around $50/ 206 month, the cost per successful voice spam is about 215 microcents 207 each. This assumes that calls can be made 24 hours a day, which may 208 or may not be the case. 210 These figures indicate that SIP call spam is roughly three orders of 211 magntiude cheaper to send than traditional circuit-based telemarketer 212 calls. This low cost is certainly going to be very attractive to 213 spammers. Indeed, many spammers utilize computational and bandwidth 214 resources provided by others, by infecting their machines with 215 viruses that turn them into "zombies" that can be used to generate 216 spam. This can reduce the cost of call spam to nearly zero. 218 Even ignoring the zombie issue, this reduction in cost is even more 219 amplified for international calls. Currently, there is very little 220 telemarketing calls across international borders, largely due to the 221 large cost of making international calls. This is one of the reasons 222 why the "do not call list", a United States national list of numbers 223 that telemarketers cannot call - has been effective. The law only 224 affects U.S. companies, but since most telemarketing calls are 225 domestic, it has been effective. Unfortunately (and fortunately), 226 the IP network provides no boundaries of these sorts, and calls to 227 any SIP URL are possible from anywhere in the world. This will allow 228 for international spam at a significantly reduced cost. 229 International spam is likely to be even more annoying that national 230 spam, since it may arrive in languages that the recipient doesn't 231 even speak. 233 These figures assume that the primary limitation is the access 234 bandwidth and not CPU, disk, or termination costs. Termination costs 235 merit further discussion. Currently, most VoIP calls terminate on 236 the Public Switched Telephone Network (PSTN), and this termination 237 costs the originator of the call money. These costs are similar to 238 the per-minute rates of a T1. It ranges anywhere from half a cent to 239 three cents per minute, depending on volume and other factors. 240 However, equipment costs, training and other factors are much lower 241 for SIP-based termination than a T1, making the cost still lower than 242 circuit connectivity. Furthermore, the current trend in VoIP systems 243 is to make termination free for calls that never touch the PSTN, that 244 is, calls to actual SIP endpoints. Thus, as more and more SIP 245 endpoints come online (there are probably around 5 million 246 addressable SIP endpoints on the Internet as of writing), termination 247 costs will probably drop. Until then, SIP spam can be used in 248 concert with termination services for a lower cost form of 249 traditional telemarketer calls, made to normal PSTN endpoints. 251 This number (9 deliveries per second) is below the successful message 252 delivery rate of email [[NOTE: is there a figure for this]]. 253 However, many spam messages are automatically deleted by filters or 254 users without ever being read. It is far more likely that a call 255 spam will be examined by a user if its delivered, due to the 256 difficulty in automated content filtering (see below). Thus, when 257 one examines the final figure of importance - the number of new 258 customers attracted per spam delivered, it is far from clear whether 259 call spam or email spam will be more effective. 261 Another part of the cost of spamming is collecting addresses. 262 Spammers have, over time, built up immense lists of email addresses, 263 each of the form user@domain, to which spam is directed. SIP uses 264 the same form of addressing, making it likely that email addresses 265 can easily be turned into valid SIP addresses. Telephone numbers 266 also represent valid SIP addresses, in that, in concert with a 267 termination provider, a spammer can direct SIP calls at traditional 268 PSTN devices. It is not clear whether email spammers have also been 269 collecting phone numbers as they perform their web sweeps, but it is 270 probably not hard to do so. Furthermore, unlike email addresses, 271 phone numbers are a finite address space and one that is fairly 272 densely packed. As a result, going sequentially through phone 273 numbers is likely to produce a fairly high hit rate. Thus, it seems 274 like the cost is relatively low for a spammer to obtain large numbers 275 of SIP addresses to which spam can be directed. 277 2.2 IM Spam 279 IM spam is very much like email, in terms of the costs for deploying 280 and generating spam. Assuming, for the sake of argument, a 1kB 281 message to be sent and 500 Kbps of upstream bandwidth, thats 62 282 messages per second. At $50/month, the result is 31 microcents per 283 message. This is less than voice spam, but not substantially less. 284 The cost is probably on par with email spam. However, IM is much 285 more intrusive than email. In today's systems, IMs automatically pop 286 up and present themselves to the user. Email, of course, must be 287 deliberately selected and displayed. However, many IM systems employ 288 white lists, which only allow spam to be delivered if the sender is 289 on the white list. Thus, whether or not IM spam will be useful seems 290 to depend a lot on the nature of the systems as the network is opened 291 up. If they are ubiquitously deployed with white-list access, the 292 value of IM spam is likely to be low. 294 It is important to point out that there are two different types of IM 295 systems. Page mode IM systems work much like email, with each IM 296 being sent as a separate message. In session mode IM, there is 297 signaling in advance of communication to establish a session, and 298 then IMs are exchanged, perhaps point-to-point, as part of the 299 session. The modality impacts the types of spam techniques that can 300 be applied. Techniques for email can be applied identically to page 301 mode IM, but session mode IM is more like telephony, and many 302 techniques (such as content filtering) are harder to apply. 304 2.3 Presence Spam 306 As defined above, presence spam is the generation of bulk unsolicited 307 SUBSCRIBE messages. What would be the effect of such spam? Most 308 presence systems provide some kind of consent framework. A watcher 309 that has not been granted permission to see the user's presence will 310 not gain access to their presence. However, the presence request is 311 usually noted and conveyed to the user, allowing them to approve or 312 deny the request. In SIP, this is done using the watcherinfo event 313 package [8]. This package allows a user to learn the identity of the 314 watcher, in order to make an authorization decision. 316 Interestingly, this provides a vehicle for conveying information to a 317 user. By generating SUBSCRIBE requests from identities such as 318 sip:please-buy-my-product@spam.example.com, brief messages can be 319 conveyed to the user, even though the sender does not have, and never 320 will receive, permission to access presence. As such, presence spam 321 can be viewed as a form of IM spam, where the amount of content to be 322 conveyed is limited. The limit is equal to the amount of information 323 generated by the watcher that gets conveyed to the user through the 324 permission system. 326 This type of spam also shows up in consent frameworks used to prevent 327 call spam, as discussed in Section 3.4. 329 3. Solution Space 331 In this section, we consider the various solutions that might be 332 possible to deal with SIP spam. We primarily consider techniques 333 that have been employed to deal with email spam. It is important to 334 note that the solutions documented below are not meant to be an 335 exhaustive study of the spam solutions used for email but rather just 336 a representative set. We also consider some solutions that appear to 337 be SIP-specific. 339 3.1 Content Filtering 341 The most common form of spam protection used in email is based on 342 content filtering. These spam filters analyze the content of the 343 email, and look for clues that the email is spam. Bayesian spam 344 filters are in this category. 346 Unfortunately, this type of spam filtering is almost completely 347 useless for call spam. There are two reasons. First, in the case 348 where the user answers the call, the call is already established and 349 the user is paying attention before the content is delivered. The 350 spam cannot be analyzed before the user sees it. Second, if the 351 content is stored before the user accesses it (e.g., with voicemail), 352 the content will be in the form of recorded audio or video. Speech 353 and video recognition technology is not likely to be good enough to 354 analyze the content and determine whether or not it is spam. Indeed, 355 if a system tried to perform speech recognition on a recording in 356 order to perform such an analysis, it would be easy for the spammers 357 to make calls with background noises, poor grammar and varied 358 accents, all of which will throw off recognition systems. Video 359 recognition is even harder to do and remains primarily an area of 360 research. 362 Therefore, our conclusion is that the most successful form of anti- 363 spam measures used in email are almost useless for call spam. 365 IM spam, due to its similarity to email, can be countered with 366 content analysis tools. Indeed, the same tools and techniques used 367 for email will directly work for IM spam. 369 3.2 Black Lists 371 Black listing is an approach whereby the spam filter maintains a list 372 of addresses that identify spammers. These addresses include both 373 usernames (spammer@domain.com) and entire domains (spammers.com). 375 Pure blacklists are not very effective in email for two reasons. 376 First, email addresses are easy to spoof, making it easy for the 377 sender to pretend to be someone else. If the sender varies the 378 addresses they send from, the black list becomes almost completely 379 useless. The second problem is that, even if the sender doesn't 380 forge the from address, email addresses are in almost limitless 381 supply. Each domain contains an infinite supply of email addresses, 382 and new domains can be obtained for very low cost. Furthermore, 383 there will always be public providers that will allow users to obtain 384 identities for almost no cost (for example, Yahoo or AOL mail 385 accounts). The entire domain cannot be blacklisted because it 386 contains so many valid users. Blacklisting needs to be for 387 individual users. Those identities are easily changed. 389 As a result, as long as identities are easy to manufacture, black 390 lists will have limited effectiveness for email. 392 Blacklists are also likely to be ineffective for SIP spam. 393 Fortunately, SIP has much stronger mechanisms for inter-domain 394 authenticated identity than email has (see Section 4). Assuming 395 these mechanisms are used and enabled in inter-domain communications, 396 it becomes nearly impossible to forge sender addresses. However, it 397 still remains cheap to obtain a nearly infinite supply of addresses. 399 3.3 White Lists 401 White lists are the opposite of black lists. It is a list of valid 402 senders that a user is willing to accept email from. Unlike black 403 lists, a spammer can not change identities to get around the white 404 list. White lists are susceptible to address spoofing, but a strong 405 identity authentication mechanism can prevent that problem. As a 406 result, the combination of white lists and strong identity are a good 407 form of defense against spam. 409 However, they are not a complete solution, since they would prohibit 410 a user from ever being able to receive email from someone who was not 411 explicitly put on the white list. As a result, white lists require a 412 solution to the "introduction problem" - how to meet someone for the 413 first time, and decide whether they should be placed in the white 414 list. In addition to the introduction problem, white lists demand 415 time from the user to manage. 417 In IM systems, white lists have proven exceptionally useful at 418 preventing spam. This is due, in no small part, to the fact that the 419 white list exists naturally in the form of the buddy list. Users 420 don't have to manage this list just for the purposes of spam 421 prevention; it provides general utility, and assists in spam 422 prevention for free. IM systems also have strong identity mechanisms 423 due to their closed nature. The introduction problem in these 424 systems is solved with a consent framework, described below. 426 The success of white lists in IM systems has applicability to SIP as 427 well, more so than email. This is because SIP also provides a buddy 428 list concept and has an advanced presence system as part of its 429 specifications. Second, unlike email, but like IM systems, SIP can 430 provide a much more secure form of authenticated identity, even for 431 inter-domain communications. As a result, the problem of forged 432 senders can be eliminated, making the white list solution feasible. 434 The introduction problem remains, however. In email, techniques like 435 the Turing tests have been employed for this purpose. Those are 436 considered further in the sections below. As with email, a technique 437 for solving the introduction problem would need to be applied in 438 conjunction with a white list. 440 3.4 Consent-Based Communications 442 A consent-based solution is used in conjunction with white or black 443 lists. That is, if user A is not on user B's white or black list, 444 and user A attempts to communicate with user B, user A's attempt is 445 initially rejected, and they are told that consent is being 446 requested. Next time user B connects, user B is informed that user A 447 had attempted communications. User B can then authorize or reject 448 user A. 450 These kinds of consent-based systems are used widely in presence and 451 IM but not in email. This is likely due to the need for a secure 452 authenticated identity mechanism, which is a pre-requisite for this 453 kind of solution. Since most of today's IM systems are closed, 454 sender identities can be authenticated. 456 This kind of consent-based communications has been standardized in 457 SIP for presence, using the watcher information event package [8] and 458 data format [9], which allow a user to find out that someone has 459 subscribed. Then, the XML Configuration Access Protocol (XCAP) [11] 460 is used, along with the XML format for presence authorization [12] to 461 provide permission for the user to communicate. However, to date, 462 these techniques have been applied strictly for presence. 464 If they were extended to cover IM and calling, would it help? It is 465 hard to say. At first glance, it would seem to help a lot. However, 466 it might just change the nature of the spam. Instead of being 467 bothered with content, in the form of call spam or IM spam, users are 468 bothered with consent requests. A user's "communications inbox" 469 might instead be filled with requests for communications from a 470 multiplicity of users. Those requests for communications don't 471 convey much useful content to the user, but they can convey some. At 472 the very least, they will convey the identity of the requester. The 473 user part of the SIP URI allows for limited freeform text, and thus 474 could be used to convey brief messages. One can imagine receiving 475 consent requests with identities like, 476 "sip:please-buy-my-product-at-this-website@spam.example.com", for 477 example. Fortunately, traditional content-based filtering can be 478 applied to this type of information. 480 In order for the spammer to convey more extensive content to the 481 user, the user must explicitly accept the request, and only then can 482 the spammer convey the full content. This is unlike email spam, 483 where, even though much spam is automatically deleted, some 484 percentage of the content does get through, and is seen by users, 485 without their explicit consent that they want to see it. Thus, if 486 consent is required first, and nearly all users do not give consent 487 to spammers, the value in sending spam is reduced, and perhaps it 488 will cease. 490 As such, the real question is whether or not the consent system would 491 make it possible for a user to give consent to non-spammers and 492 reject spammers. Authenticated identity can help. A user in an 493 enterprise would know to give consent to senders in other enterprises 494 in the same industry, for example. However, in the consumer space, 495 if sip:bob@example.com tries to communicate with a user, how does 496 that user determine whether bob is a spammer or a long-lost friend 497 from high school? There is no way based on the identity alone. In 498 such a case, a useful technique is to grant permission for bob to 499 communicate but to make the permission is extremely limited. In 500 particular, bob may be granted permission to send no more than 200 501 words of text in a single IM, which he can use to identify himself, 502 so that the user can determine whether or not more permissions are 503 appropriate. However, this 200 words of text may be enough for a 504 spammer to convey their message, in much the same way they might 505 convey it in the user part of the SIP URI. 507 Thus, it seems that a consent-based framework, along with white lists 508 and black lists, cannot fully solve the problem for SIP, although it 509 does appear to help. 511 3.5 Reputation Systems 513 A reputation system is also used in conjunction with white or black 514 lists. Assume that user A is not on user B's white list, and they 515 attempt to contact user B. If a consent-based system is used, B is 516 prompted to consent to communications from A, a reputation score 517 might be displayed in order to help B decide whether or not they 518 should accept communications from A. 520 Traditionally, reputation systems are implemented in highly 521 centralized messaging architectures; the most widespread reputation 522 systems in messaging today have been deployed by monolithic instant 523 messaging providers (though many web sites with a high degree of 524 interactivity employ very similar concepts of reputation). 525 Reputation is calculated based on user feedback. For example, a 526 button on the user interface of the messaging client might empower 527 users to inform the system that a particular user is abusive. Of 528 course, the input of any single user has to be insufficient to ruin 529 one's reputation, but consistent negative feedback would give the 530 abusive user a negative reputation score. 532 Reputation systems have not enjoyed much success outside of the 533 instant messaging space. This is in part because few other 534 communications systems admit of the same degree of centralization and 535 monolithic control. That control, first of all, provides a 536 relatively strong identity assertion for users (since all users trust 537 a common provider, and the common provider is the arbiter of 538 authentication and identity). Secondly, it provides a single place 539 where reputation can be managed. 541 Reputation systems based on negative reputation scores suffer from 542 many of the same problems as black lists, since effectively the 543 consequence of having a negative reputation is that you are 544 blacklisted. If identities are very easy to acquire, a user with a 545 negative reputation will simply acquire a new one. Moreover, 546 negative reputation is generated by tattling, which requires users to 547 be annoyed enough to click the warning button. Additionally, it can 548 be abused. In some reputation systems, "reputation mafias" 549 consisting of large numbers of users routinely bully or extort 550 victims by threatening collectively to grant victims a negative 551 reputation. 553 Reputation systems based on positive reputation, where users praise 554 each other for being good, rather than tattling on each other for 555 being bad, have some similar drawbacks. Collectives of spammers, or 556 just one spammer who acquires a large number identities, could praise 557 one another in order to create an artifical positive reputation. 558 Users similarly have to overcome the inertia required to press the 559 "praise" button. Unlike negative reputation systems, however, 560 positive reputation is not circumvented when users require a new 561 identity, since basing authorization decisions on positive reputation 562 is essentially a form of whitelisting. 564 So, while positive reputation systems are superior to negative 565 reputation systems, they are far from perfect. Intriguingly, though, 566 combining presence-based systems with reputation systems leads to an 567 interesting fusion. The "buddy-list" concept of presence is, in 568 effect, a white list - and one can therefore probably infer that the 569 users on one's buddy list are people whom you are "praising". This 570 eliminates the problem of user inertia in the use of the "praise" 571 button, and automates the initial establishment of reputation. 573 And of course, your buddies in turn have buddies. Collectively, you 574 and your buddies (and their buddies, and so on) constitute a social 575 network of reputation. If there were a way to leverage this social 576 network, it would eliminate the need for centralization of the 577 reputation system. Your perception of a particular user's reputation 578 might be dependent on your relationship to them in the social 579 network: are they one buddy removed (strong reputation), four buddies 580 removed (weaker reputation), three buddies removed but connected to 581 you through several of your buddies, etc. This web of trust 582 furthermore would have the very desirable property that circles of 583 spammers adding one another to their own buddylists would not affect 584 your perception of their reputation unless their circle linked to 585 your own social network. 587 3.6 Address Obfuscation 589 Spammers build up their spam lists by gathering email addresses from 590 web sites and other public sources of information. One way to 591 prevent spam is to make your address difficult or impossible to 592 gather. Spam bots typically look for text in pages of the form 593 "user@domain", and assume that anything of that form is an email 594 address. To hide from such spam bots, many websites have recently 595 begun placing email addresses in an obfuscated form, usable to humans 596 but difficult for an automata to read as an email address. Examples 597 include forms such as, "user at example dot com" or "j d r o s e n a 598 t e x a m p l e d o t c o m". 600 These techniques are equally applicable to prevention of SIP spam, 601 and are likely to be as equally effective or ineffective in its 602 prevention. 604 It is worth mentioning that the source of addresses need not be a web 605 site - any publically accessible service containing addresses will 606 suffice. As a result, ENUM [10] has been cited as a potential gold 607 mine for spammers. It would allow a spammer to collect SIP and other 608 URIs by traversing the tree in e164.arpa and mining it for data. 609 This problem is mitigated in part if only number prefixes, as opposed 610 to actual numbers, appear in the DNS. Even in that case, however, it 611 provides a technique for a spammer to learn which phone numbers are 612 reachable through cheaper direct SIP connectivity. 614 3.7 Limited Use Addresses 616 A related technique to address obfuscation is limited use addresses. 617 In this technique, a user has a large number of email addresses at 618 their disposal. They give out different email addresses to different 619 people. Once spam begins arriving at an address, the user terminates 620 the address and replaces it with another. 622 This technique is equally applicable to SIP. One of the drawbacks of 623 the approach is that it can make it hard for people to reach you; if 624 an email address you hand out to a friend becomes spammed, changing 625 it requires you to inform your friend of the new address. SIP can 626 help solve this problem in part, by making use of presence [7]. 627 Instead of handing out your email address to your friends, you would 628 hand out your presence URI. When a friend wants to send you an 629 email, they subscribe to your presence (indeed, they are likely 630 continuously subscribed from a buddy list application). The presence 631 data can include an email address where you can be reached. This 632 email address can be obfuscated and be of single use, different for 633 each buddy who requests your presence. They can also be constantly 634 changed, as these changes are pushed directly to your buddies. In a 635 sense, the buddy list represents an automatically updated address 636 book, and would therefore eliminate the problem. 638 3.8 Turing Tests 640 In email, Turing tests are those solutions whereby the sender of the 641 message is given some kind of puzzle or challenge, which only a human 642 can answer. If the puzzle is answered correctly, the sender is 643 placed on the user's white list. These puzzles frequently take the 644 form of recognizing a word or sequence of numbers in an image with a 645 lot of background noise. Automata cannot easily perform the image 646 recognition needed to extract the word or number sequence, but a 647 human user usually can. Since Turing tests rely on video or audio 648 puzzles, they sometimes cannot be solved by individuals with 649 handicaps. 651 Like many of the other email techniques, Turing tests are dependent 652 on sender identity, which cannot easily be authenticated in email. 654 Turing tests can be used to prevent IM spam, in much the same way 655 they can be used to prevent email spam. Indeed, the presence strong 656 authenticated identity techniques in SIP will make such a Turing test 657 approach more effective in SIP than in email. 659 Turing tests can be applied to call spam as well, although not 660 directly, because call spam does not usually involve the transfer of 661 images and other content that can be used to verify that a human is 662 on the other end. If most of the calls are voice, the technique 663 needs to be adapted to voice. This is not that difficult to do. 664 Here is how it could be done. User A calls user B and is not on user 665 B's white or black list. User A is transferred to an IVR system. 666 The IVR system tells the user that they are going to hear a series of 667 numbers (say 5 of them), and that they have to enter those numbers on 668 the keypad. The IVR system reads out the numbers while background 669 music is playing, making it difficult for an automated speech 670 recognition system to be applied to the media. The user then enters 671 the numbers on their keypad. If they are entered correctly, the user 672 is added to the whitelist. 674 This kind of voice-based Turing test is easily extended to a variety 675 of media, such as video and text, and user interfaces by making use 676 of the SIP application interaction framework [14]. This framework 677 allows client devices to interact with applications in the network, 678 where such interaction is done with stimulus signaling, including 679 keypads (supported with the Keypad Markup Language [15]), but also 680 including web browsers, voice recognition, and so on. The framework 681 allows the application to determine the media capabilities of the 682 device (or user, in cases where they are handicapped) and interact 683 with them appropriately. 685 In the case of voice, there are problems with the Turing test 686 described above. First, it is language specific. The application 687 could be made to run in different languages, if the caller indicates 688 their supported languages. This is possible in SIP, using the 689 Accept-Language header field, but this is not widely used at the 690 moment. 692 The other problem with this Turing test is the same one that email 693 tests have: instead of having an automata process the test, a spammer 694 can pay cheap workers to take the tests. Assuming cheap labor in a 695 poor country can be obtained for about $100 US dollars per year, and 696 assuming a Turing test of 30 second duration, this ends up being 697 about ten thousand messages per dollar, or about 10,000 microcents 698 per message. Though much more expensive than the 31 microcents per 699 message to send an IM spam, it is still relatively inexpensive. 701 As an alternative to paying cheap workers to take the tests, the 702 tests can be taken by human users that are tricked into completing 703 the tests in order to gain access to what they believe is a 704 legitimate resource. This was done by a spambot that posted the 705 tests on a pornography site, and required users to complete the tests 706 in order to gain access to content. 708 Due to these limitations, turing tests may never completely solve the 709 problem. 711 3.9 Computational Puzzles 713 This technique is similar to Turing tests. When user A tries to 714 communicate with user B, user B asks user A to perform a computation 715 and pass the result back. This computation has to be something a 716 human user cannot perform and something expensive enough to increase 717 user A's cost to communicate. This cost increase has to be high 718 enough to make it prohibitively expensive for spammers but 719 inconsequential for legitimate users. 721 One of the problems with the technique is that there is wide 722 variation in the computational power of the various clients that 723 might legitimately communicate. The CPU speed on a low end cell 724 phone is around 50 MHz, while a high end PC approaches 5 GHz. This 725 represents almost two orders of magnitude difference. Thus, if the 726 test is designed to be reasonable for a cell phone to perform, it is 727 two orders of magnitude cheaper to perform for a spammer on a high 728 end machine. Recent research has focused on defining computational 729 puzzles that challenge the CPU/memory bandwidth, as opposed to just 730 the CPU [19]. It seems that there is less variety in the CPU/memory 731 bandwidth across devices, roughly a single order of magnitude. 733 Recent work [21] suggests that, due to the ability of spammers to use 734 virus-infected machines (also known as zombies) to generate the spam, 735 the amount of computational power available to the spammers is 736 substantial, and it may be impossible to have them compute a puzzle 737 that is sufficiently hard that will not also block normal emails. 738 However, if combined with white listing, the computational puzzles 739 only become needed for validating new communication partners. The 740 frequency of communications with new partners is arguably higher for 741 email than for multimedia, and thus the computational puzzle 742 techniques may be more effective for SIP than for email in dealing 743 with the introduction problem. 745 These techniques are an active area of research right now, and any 746 results for email are likely to be usable for SIP. Of course, it is 747 likely that these techniques will come with a lot of patents and 748 other intellectual property constraints. 750 3.10 Payments at Risk 752 This approach has been proposed for email [20]. When user A sends to 753 user B, user A deposits a small amount of money (say, one dollar) 754 into user B's account. If user B decides that the message is not 755 spam, user B refunds this money back to user A. If the message is 756 spam, user B keeps the money. This technique requires two 757 transactions to complete: a transfer from A to B, and a transfer from 758 B back to A. The first transfer has to occur before the message can 759 be received in order to avoid reuse of "pending payments" across 760 several messages, which would eliminate the utility of the solution. 761 The second one then needs to occur when the message is found not to 762 be spam. 764 This technique appears just as applicable to call spam and IM spam as 765 it is to email spam. Like many of the other techniques, this 766 exchange would only happen the first time you talk to people. Its 767 proper operation therefore requires a good authenticated identity 768 infrastructure. 770 This technique has the potential to truly make it prohibitively 771 expensive to send spam of any sort. However, it relies on cheap 772 micro-payment techniques on the Internet. Traditional costs for 773 internet payments are around 25 cents per transaction, which would 774 probably be prohibitive. However, recent providers have been willing 775 to charge 15% of the transaction for small transactions, for 776 transactions as small as one cent. This cost would have to be 777 shouldered by users of the system. The cost that would need to be 778 shouldered per user is equal to the number of messages from unknown 779 senders (that is, senders not on the white list) that are received. 780 For a busy user, assume about 10 new senders per day. If the deposit 781 is 5 cents, the transaction provider would take .75 cents and deliver 782 4.25 cents. If the sender is allowed, the recipient returns 4.25 783 cents, the provider takes 64 cents, and returns 3.6 cents. This 784 costs the sender .65 cents on each transaction, if it was legitimate. 785 If there are ten new recipients per day, thats US $1.95 per month, 786 which is relatively inexpensive. 788 3.11 Legal Action 790 In this solution, countries pass laws that prohibit spam. These laws 791 could apply to IM or call spam just as easily as they could apply to 792 email spam. 794 There is a lot of debate about whether these laws would really be 795 effective in preventing spam. Whether they are or are not effective, 796 they would appear to be equally effective (or ineffective, as the 797 case may be) in preventing SIP spam. 799 As a recent example in the US, "do not call" lists seem to be 800 effective. However, due to the current cost of long distance phone 801 calls, the telemarketing is coming from companies within the US. As 802 such, calls from such telemarketers can be traced. If a telemarketer 803 violates the "do not call" list, the trace allows legal action to be 804 taken against them. A similar "do not irritate" list for VoIP or for 805 email would be less likely to work because the spam is likely to come 806 from international sources. This problem could be obviated if there 807 was a strong way to identify the sender's legal entity, and then 808 determine whether it was in a jurisdiction where it was practical to 809 take legal action against them. If the spammer is not in such a 810 jurisdiction, the SIP spam could be rejected. 812 There are also schemes that cause laws other than anti-spam laws to 813 be broken if spam is sent. This does not inherently reduce SPAM, but 814 it allows more legal options to be brought to bear against the 815 spammer. For example, Habeas inserts 816 material in the header that, if a spammer inserted it without an 817 appropriate license, allegedly causes the spammer to be violating US 818 copyright and trademark laws, possibly reciprocal laws, and similar 819 laws in many countries. 821 3.12 Circles of Trust 823 In this model, a group of domains (e.g., a set of enterprises) all 824 get together. They agree to exchange SIP calls amongst each other, 825 and they also agree to introduce a fine should any one of them be 826 caught spamming. Each company would then enact measures to terminate 827 employees who spam from their accounts. 829 This technique relies on secure inter-domain authentication - that 830 is, domain B can know that messages are received from domain A. In 831 SIP, this is readily provided by usage of the mutually authenticated 832 TLS between providers. Email does not have this kind of secure 833 domain identification, although new techniques are being investigated 834 to add it using reverse DNS checks (see below). 836 This kind of technique works well for small domains or small sets of 837 providers, where these policies can be easily enforced. However, it 838 is unclear how well it scales up. Could a very large domain truly 839 prevent its users from spamming? Would a very large enterprise just 840 pay the fine? How would the pricing be structured to allow both 841 small and large domains alike to participate? 843 3.13 Centralized SIP Providers 845 In this technique, a small number of providers get established as 846 "inter-domain SIP providers". These providers act as a SIP- 847 equivalent to the interexchange carriers in the PSTN. Every 848 enterprise, consumer SIP provider or other SIP network (call these 849 the local SIP providers) connects to one of these inter-domain 850 providers. The local SIP providers only accept SIP messages from 851 their chosen inter-domain provider. The inter-domain provider 852 charges the local provider, per SIP message, for the delivery of SIP 853 messages to other local providers. The local provider can choose to 854 pass on this cost to its own customers if it so chooses. 856 The inter-domain SIP providers then form bi-lateral agreements with 857 each other, exchanging SIP messages according to strict contracts. 858 These contracts require that each of the inter-domain providers be 859 responsible for charging a minimum per-message fee to their own 860 customers. Extensive auditing procedures can be put into place to 861 verify this. Besides such contracts, there may or may not be a flow 862 of funds between the inter-domain providers. 864 The result of such a system is that a fixed cost can be associated 865 with sending a SIP message, and that this cost does not require 866 micro-payments to be exchanged between local providers, as it does in 867 Section 3.10. Since all of the relationships are pre-established and 868 negotiated, cheaper techniques for monetary transactions (such as 869 monthly post-paid transactions) can be used. 871 This technique can be made to work in SIP, whereas it cannot in 872 email, because inter-domain SIP connectivity has not yet been 873 established. In email, there already exists a no-cost form of inter- 874 domain connectivity that cannot be eliminated without destroying the 875 utility of email. If, however, SIP inter-domain communications get 876 established from the start using this structure, there is a path to 877 deployment. 879 This structure is more or less the same as the one in place for the 880 PSTN today, and since there is relatively little spam on the PSTN 881 (compared to email!), there is some proof that this kind of 882 arrangement can work. However, it puts back into SIP much of the 883 complexity and monopolistic structures that SIP promised to 884 eliminate. As such, it is a solution that the authors find 885 distasteful and contrary to the SIP design and architecture. 887 3.14 Sender Checks 889 In email, there has been a lot of interest in defining new DNS 890 resource records that will allow a domain that receives a message to 891 verify that the sender is a valid MTA for the sending domain [18] 892 [16]. 894 Are these techniques useful for SIP? They can be used for SIP but 895 are not necessary. In email, there are no standards established for 896 securely identifying the identity of the sending domain of a message. 897 In SIP, however, TLS with mutual authentication can be used inter- 898 domain. A provider receiving a message can then reject any message 899 coming from a domain that does not match the asserted identity of the 900 sender of the message. Such a policy only works in the "trapezoid" 901 model of SIP, whereby there are only two domains in any call - the 902 sending domain, which is where the originator resides, and the 903 receiving domain. These techniques are discussed in Section 26.3.2.2 904 of RFC 3261 [2]. These techinques, however, are only applicable in 905 the trapezoid model where there is a sending and a receiving domain 906 only. In forwarding situations, the assumption no longer holds and 907 these techniques no longer work. 909 Thus, instead of creating DNS entries containing the IP address of 910 each legitimate relay for a domain, the provider can give each 911 legitimate relay a certificate that allows them to authenticate 912 themselves as coming from that domain. Such a technique would work 913 even in the face of IP address spoofing, which the marid techniques 914 are susceptible to. 916 4. Authenticated Identity in SIP 918 One of the key parts of many of the solutions described above is the 919 ability to securely identify the identity of a sender of a SIP 920 message. SIP provides a secure solution for this problem, and it is 921 important to discuss it here. 923 The solution starts by having each domain authenticate its own users. 924 SIP provides HTTP digest authentication as part of the core SIP 925 specification, and all clients and servers are required to support 926 it. Indeed, digest is widely deployed for SIP. However, digest 927 alone has many known vulnerabilities, most notably offline dictionary 928 attacks. These vulnerabilities are all resolved by having each 929 client maintain a persistent TLS connection to the server. The 930 client verifies the server identity using TLS, and then authenticates 931 itself to the server using a digest exchange over TLS. This 932 technique, which is also documented in RFC 3261, is very secure but 933 not widely deployed yet. In the long term, this approach will be 934 necessary for the security properties needed to prevent SIP spam. 936 Once a domain has authenticated the identity of a user, when it 937 relays a message from that user to another domain, the sending domain 938 can assert the identity of the sender, and include a signature to 939 validate that assertion. This is done using the SIP identity 940 mechanism [17]. 942 A weaker form of identity assertion is possible using the P-Asserted- 943 Identity header field [6], but this technique requires mutual trust 944 among all domains. Unfortunately, this becomes expontentially harder 945 to provide as the number of interconnected domains grows. As that 946 happens, the value of the identity assertion becomes equal to the 947 trustworthiness of the least trustworthy domain. Since spam is a 948 consequence of untrusted domains and users that get connected to the 949 network, the P-Asserted-Identity technique becomes ineffective at 950 exactly the same levels of interconnectness that introduce spam. 952 A further weakness of P-Asserted-ID is that the actual domain which 953 asserted the identity cannot be known. If that domain could be 954 reliably known, then its assertions could be tempered based on user 955 or domain-wide policiies. This weakness is not present in [17], 956 which allows the recipient of a message to cryptographically 957 determine the identity of the asserting domain. 959 SIP also defines the usage of TLS between domains, using mutual 960 authentication, as part of the base specification. This technique 961 provides a way for one domain to securely determine that it is 962 talking to a server that is a valid representative of another domain. 964 5. Framework for Anti-Spam in SIP 966 Unfortunately, there is no magic bullet for preventing SIP spam, just 967 as there is none for email spam. However, the combination of several 968 techniques can provide a framework for dealing with spam in SIP. 970 Strong Authenticated Identity is Key: In almost all of the solutions 971 discussed above, there is a dependency on the ability to 972 authenticate the sender of a SIP message inter-domain. As such, 973 we would argue that any provider that performs inter-domain SIP 974 messaging must use the techniques described in Section 4, and in 975 particular, depend on the strong identity techniques in [17]. 977 Whitelists: With a strong identity mechanism in place, whitelists can 978 facilitate communications from known callers. That reduces the 979 scope of the problem to the introduction problem. 981 Consent Framework: The SIP consent framework [13] extends the 982 presence framework for consent to all communications. Consent 983 plays an important role in helping address the introduction 984 problem. 986 Leverage What Email has to Offer: With the consent framework in 987 place, spammers have only a small window through which they can 988 introduce content to recipients. Fortunately, that problem is 989 similar to traditional email spam, and can be addressed using the 990 various email-based anti-spam techniques. Providers of SIP 991 services should keep tabs on solutions in email as they evolve, 992 and utilize the best of what those techniques have to offer. But 993 perhaps most importantly, providers should not ignore the spam 994 problem until it happens! That is the pitfall email fell into. 995 As soon as a provider inter-connects with other providers, or 996 allows SIP messages from the open Internet, that provider must 997 consider how they will deal with spam. 999 6. Additional Work 1001 Though the above framework serves as a good foundation on which to 1002 deal with spam in SIP, there are gaps, some of which can be addressed 1003 by additional work that has yet to be undertaken. 1005 One of the difficulties with the strong identity techniques is that a 1006 receiver of a SIP request without an authenticated identity cannot 1007 know whether the request lacked such an identity because the 1008 originating domain didn't support it, or because a man-in-the-middle 1009 removed it. As a result, transition mechanisms should be put in 1010 place to allow these to be differentiated. Without it, the value of 1011 the identity mechanism is much reduced. 1013 The consent framework depends on the ability for users to make a 1014 determination about whether to grant consent for unknown senders. In 1015 order for that framework to be useful, it needs to be coupled with 1016 techniques to ascertain trustworthiness. Reputation systems, for 1017 example, can help with that. At this time, reputation systems have 1018 seen implementation only within single domains, and using proprietary 1019 techniques. A standards-based inter-domain solution would be a 1020 valuable part of this framework. 1022 7. Security Considerations 1024 This memo is entirely devoted to issues relating to secure usage of 1025 SIP services on the Internet. 1027 8. Acknowledgements 1029 The authors would like to thank Rohan Mahy for providing information 1030 on Habeas, Baruch Sterman for providing costs on VoIP termination 1031 services, and Gonzalo Camarillo for his review. Useful comments and 1032 feedback were provided by Nils Ohlmeir, Tony Finch, Randy Gellens and 1033 Yakov Shafranovich. 1035 9. Informative References 1037 [1] Campbell, B., "The Message Session Relay Protocol", 1038 draft-ietf-simple-message-sessions-14 (work in progress), 1039 February 2006. 1041 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1042 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1043 Session Initiation Protocol", RFC 3261, June 2002. 1045 [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 1046 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1047 Instant Messaging", RFC 3428, December 2002. 1049 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1050 Notification", RFC 3265, June 2002. 1052 [5] Peterson, J., "A Privacy Mechanism for the Session Initiation 1053 Protocol (SIP)", RFC 3323, November 2002. 1055 [6] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 1056 to the Session Initiation Protocol (SIP) for Asserted Identity 1057 within Trusted Networks", RFC 3325, November 2002. 1059 [7] Rosenberg, J., "A Presence Event Package for the Session 1060 Initiation Protocol (SIP)", RFC 3856, August 2004. 1062 [8] Rosenberg, J., "A Watcher Information Event Template-Package 1063 for the Session Initiation Protocol (SIP)", RFC 3857, 1064 August 2004. 1066 [9] Rosenberg, J., "An Extensible Markup Language (XML) Based 1067 Format for Watcher Information", RFC 3858, August 2004. 1069 [10] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 1070 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 1071 Application (ENUM)", RFC 3761, April 2004. 1073 [11] Rosenberg, J., "The Extensible Markup Language (XML) 1074 Configuration Access Protocol (XCAP)", 1075 draft-ietf-simple-xcap-08 (work in progress), October 2005. 1077 [12] Rosenberg, J., "Presence Authorization Rules", 1078 draft-ietf-simple-presence-rules-04 (work in progress), 1079 October 2005. 1081 [13] Rosenberg, J., "A Framework for Consent-Based Communications in 1082 the Session Initiation Protocol (SIP)", 1083 draft-ietf-sipping-consent-framework-04 (work in progress), 1084 March 2006. 1086 [14] Rosenberg, J., "A Framework for Application Interaction in the 1087 Session Initiation Protocol (SIP)", 1088 draft-ietf-sipping-app-interaction-framework-05 (work in 1089 progress), July 2005. 1091 [15] Burger, E., "A Session Initiation Protocol (SIP) Event Package 1092 for Key Press Stimulus (KPML)", draft-ietf-sipping-kpml-07 1093 (work in progress), December 2004. 1095 [16] Lyon, J., "Sender ID: Authenticating E-Mail", 1096 draft-ietf-marid-core-03 (work in progress), August 2004. 1098 [17] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1099 Identity Management in the Session Initiation Protocol (SIP)", 1100 draft-ietf-sip-identity-06 (work in progress), October 2005. 1102 [18] Danisch, H., "The RMX DNS RR and method for lightweight SMTP 1103 sender authorization", draft-danisch-dns-rr-smtp-04 (work in 1104 progress), May 2004. 1106 [19] Abadi, M., Burrows, M., Manasse, M., and T. Wobber, "Moderately 1107 Hard, Memory Bound Functions, NDSS 2003", February 2003. 1109 [20] Abadi, M., Burrows, M., Birrell, A., Dabek, F., and T. Wobber, 1110 "Bankable Postage for Network Services, Proceedings of the 8th 1111 Asian Computing Science Conference, Mumbai, India", 1112 December 2003. 1114 [21] Clayton, R. and B. Laurie, "Proof of Work Proves not to Work, 1115 Third Annual Workshop on Economics and Information Security", 1116 May 2004. 1118 Authors' Addresses 1120 Jonathan Rosenberg 1121 Cisco 1122 600 Lanidex Plaza 1123 Parsippany, NJ 07054 1124 US 1126 Phone: +1 973 952-5000 1127 Email: jdrosen@cisco.com 1128 URI: http://www.jdrosen.net 1130 Cullen Jennings 1131 Cisco 1132 170 West Tasman Dr. 1133 San Jose, CA 95134 1134 US 1136 Phone: +1 408 527-9132 1137 Email: fluffy@cisco.com 1138 Jon Peterson 1139 Neustar 1140 1800 Sutter Street 1141 Suite 570 1142 Concord, CA 94520 1143 US 1145 Phone: +1 925 363-8720 1146 Email: jon.peterson@neustar.biz 1147 URI: http://www.neustar.biz 1149 Intellectual Property Statement 1151 The IETF takes no position regarding the validity or scope of any 1152 Intellectual Property Rights or other rights that might be claimed to 1153 pertain to the implementation or use of the technology described in 1154 this document or the extent to which any license under such rights 1155 might or might not be available; nor does it represent that it has 1156 made any independent effort to identify any such rights. Information 1157 on the procedures with respect to rights in RFC documents can be 1158 found in BCP 78 and BCP 79. 1160 Copies of IPR disclosures made to the IETF Secretariat and any 1161 assurances of licenses to be made available, or the result of an 1162 attempt made to obtain a general license or permission for the use of 1163 such proprietary rights by implementers or users of this 1164 specification can be obtained from the IETF on-line IPR repository at 1165 http://www.ietf.org/ipr. 1167 The IETF invites any interested party to bring to its attention any 1168 copyrights, patents or patent applications, or other proprietary 1169 rights that may cover technology that may be required to implement 1170 this standard. Please address the information to the IETF at 1171 ietf-ipr@ietf.org. 1173 Disclaimer of Validity 1175 This document and the information contained herein are provided on an 1176 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1177 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1178 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1179 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1180 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1181 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1183 Copyright Statement 1185 Copyright (C) The Internet Society (2006). This document is subject 1186 to the rights, licenses and restrictions contained in BCP 78, and 1187 except as set forth therein, the authors retain all their rights. 1189 Acknowledgment 1191 Funding for the RFC Editor function is currently provided by the 1192 Internet Society.