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