RFC 5039

The Session Initiation Protocol (SIP) and Spam

📅 published January 2008, from ietf

RFC 5039: The Session Initiation Protocol (SIP) and Spam ✨

Part 1 of 7 🎀

Okay bestie, here's the deets 💅

  • Title: The Session Initiation Protocol (SIP) and Spam
  • Authors: J. Rosenberg and C. Jennings, both from Cisco 🦋
  • Category: Informational
  • Date: January 2008
  • Obsoletes/Updates: The title block doesn't list anything it obsoletes or updates 🌸

Status of This Memo 📜

Okay so this memo is just giving info to the Internet community 💖 It is NOT a standard of any kind, no cap. Distribution is unlimited, so share it with everyone 🫶

Abstract ✨

Okay so spam (aka bulk unsolicited messages) has totally wrecked Internet email 😭 But it's not just an email problem. Any system where users talk to each other can get hit, and that includes SIP 🙈 SIP is the protocol for user-to-user multimedia calls, so it's just as vulnerable as email is 💀

This doc breaks down how spam shows up in SIP. First, it looks at what's the same as email and what's totally different 🔥 Then it checks out the solutions people have already tried for email and figures out whether they'd even work for SIP 👑

Table of Contents 🧚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Problem Definition . . . . . . . . . . . . . . . . . . . . . .  3
  2.1.  Call Spam  . . . . . . . . . . . . . . . . . . . . . . . .  4
  2.2.  IM Spam  . . . . . . . . . . . . . . . . . . . . . . . . .  7
  2.3.  Presence Spam  . . . . . . . . . . . . . . . . . . . . . .  7
3.  Solution Space . . . . . . . . . . . . . . . . . . . . . . . .  8
  3.1.  Content Filtering  . . . . . . . . . . . . . . . . . . . .  8
  3.2.  Black Lists  . . . . . . . . . . . . . . . . . . . . . . .  9
  3.3.  White Lists  . . . . . . . . . . . . . . . . . . . . . . .  9
  3.4.  Consent-Based Communications . . . . . . . . . . . . . . . 10
  3.5.  Reputation Systems . . . . . . . . . . . . . . . . . . . . 12
  3.6.  Address Obfuscation  . . . . . . . . . . . . . . . . . . . 14
  3.7.  Limited-Use Addresses  . . . . . . . . . . . . . . . . . . 14
  3.8.  Turing Tests . . . . . . . . . . . . . . . . . . . . . . . 15
  3.9.  Computational Puzzles  . . . . . . . . . . . . . . . . . . 17
  3.10. Payments at Risk . . . . . . . . . . . . . . . . . . . . . 17
  3.11. Legal Action . . . . . . . . . . . . . . . . . . . . . . . 18
  3.12. Circles of Trust . . . . . . . . . . . . . . . . . . . . . 19
  3.13. Centralized SIP Providers  . . . . . . . . . . . . . . . . 19
4.  Authenticated Identity in Email  . . . . . . . . . . . . . . . 20
  4.1.  Sender Checks  . . . . . . . . . . . . . . . . . . . . . . 21
  4.2.  Signature-Based Techniques . . . . . . . . . . . . . . . . 21
5.  Authenticated Identity in SIP  . . . . . . . . . . . . . . . . 22
6.  Framework for Anti-Spam in SIP . . . . . . . . . . . . . . . . 23
7.  Additional Work  . . . . . . . . . . . . . . . . . . . . . . . 24
8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
10. Informative References . . . . . . . . . . . . . . . . . . . . 25

1. Introduction 💫

Okay so spam (bulk unsolicited email, to be precise) has been a total plague on the Internet email system 😭 People have documented and deployed a ton of fixes, but honestly? None of them are ideal 💀 Still, one thing is super clear: the spam problem would be WAY less of a mess if solutions had been rolled out everywhere before it got out of hand 🙈

The Session Initiation Protocol (SIP) [2] is what handles multimedia calls between users. That covers voice, video, instant messaging, and presence 🎀 So honestly, it can be just as much of a target as email. Solutions need to be defined and recommendations need to be put in place for spam ASAP 🔥

This doc is here to make that happen 🦋 It defines the problem space more concretely, analyzes how well email solutions would apply, identifies SIP protocol mechanisms that could help with the problem, and makes recommendations for implementors 💅

2. Problem Definition 🧚

Okay so the spam problem in email is well understood, and we're not going to go over it again here 💁‍♀️ The real question is: what does spam even mean when it's applied to SIP? 🤔 SIP covers a huge range of stuff, so there seem to be three related but different versions of spam 🌈

Call Spam: This is a bulk unsolicited set of session initiation attempts (i.e., INVITE requests) that try to set up a voice, video, instant messaging [1], or other type of communications session 📞 If the user picks up, the spammer goes ahead and relays their message over the real-time media. This is the classic telemarketer spam, but on SIP 🙄 People often call this SPam over Ip Telephony, or SPIT 💜

IM Spam: This one is a lot like email 💌 It's a bulk unsolicited set of instant messages, where the content has the message the spammer is trying to get across. IM spam is most naturally sent using the SIP MESSAGE [3] request ✨ But honestly, any other request that automatically puts content on the user's screen works too 👀 That could be INVITE requests with big Subject headers (since the Subject is sometimes shown to the user), or INVITE requests with text or HTML bodies 🍓 People often call this SPam over Instant Messaging, or SPIM 🫠

Presence Spam: This is kind of like IM spam 🌸 It's a bulk unsolicited set of presence requests (i.e., SUBSCRIBE requests [4] for the presence event package [6]). The goal is to get onto a user's "buddy list" or "white list" so the spammer can send them IM or start other kinds of communication 🦋 This is sometimes called SPam over Presence Protocol, or SPPP 😤

There are a bunch of other SIP messages a spammer could send 🤷‍♀️ But most of them don't deliver any content to a user, and they don't ask the user for input either 🙅‍♀️ Instead, automata answer them. OPTIONS is a great example of this. There's basically no point for a spammer to send an OPTIONS request, because the User Agent Server (UAS) answers it automatically 🤖 No content gets delivered to the user, and they never get consulted 💀

In the sections below, we look at how likely each of these forms of SIP spam is 📊 In some cases that's done with a rough cost analysis. Just a heads up: all of these analyses are approximate. They're only there to give a rough sense of the order of magnitude of the problem 🫶✨

2.1. Call Spam ✨

okay so the big question is: will call spam actually happen? 🙈 Yes, it already does on the regular phone network in the form of telemarketer calls. They're super annoying, but they don't show up in the same kind of volume as email spam. The difference is cost. It costs the spammer more to make a phone call than to send an email 💸. That cost shows up as the cost of the systems that can perform telemarketer calls, and as the cost per call.

SIP makes both of those costs way lower 🫶. A SIP call spam app is easy to write. It's just a SIP User Agent that starts a huge number of calls at the same time (in parallel). If a call connects, the spam app sends an ACK and plays a recorded announcement, then ends the call. This can be built entirely in software using readily available (and honestly, free) off-the-shelf components 🖥️. It can run on a low-end PC and needs zero special expertise. bestie, that's giving "anyone can do this" energy 💀.

The cost per call drops too. A normal home phone line only lets you place one call at a time 📞. If you need more lines, you have to pay for much pricier connectivity. Usually that means a T1 or T3 for a big telemarketing operation. That kind of access is super expensive and way out of reach for an average person. A T1 line is roughly US $250 per month, plus about 1.5 cents per minute for calls. T1 lines used only for outbound calls (like in this case) cost even more than inbound trunks, because of the reciprocal termination charges that a provider pays and receives 😤.

There are two parts to the capacity: the call attempt rate, and how many successful calls can be going at once 🦋. A T1 lets a spammer have, at most, 24 simultaneous calls. If each call attempt takes about 10 seconds, that's about 2.4 call attempts per second. At high volume, the per-minute rates blow past the flat monthly fee for the T1 🔥. The result is a cost of 250,000 microcents for each successful spam delivery, assuming 10 seconds of content.

With SIP, the cost is way lower 🌸. Picture a spammer on a typical broadband connection with 500 Kbps of upstream bandwidth. Starting a call only takes a single INVITE message. Assuming, for simplicity's sake, that this is 1 KB, a 500 Kbps upstream DSL or cable modem connection can handle about 62 call attempts per second 🧚. A successful call needs enough bandwidth to send a message to the receiver. Assuming a low compression codec (say, G.723.1 at 5.3 Kbps), that's approximately 16 Kbps after RTP, UDP, and IP overheads. With 500 Kbps of upstream bandwidth, as many as 31 simultaneous calls can be in progress. With 10 seconds of content per call, that's 3.1 successful call attempts per second 💅. If broadband costs around $50/month, each successful voice spam costs about 6.22 microcents. This assumes calls can run 24 hours a day, 30 days a month, which may or may not be true 🤷‍♀️.

So these figures show that SIP call spam is roughly four orders of magnitude cheaper to send than traditional circuit-based telemarketer calls 😭. That low cost is going to be super attractive to spammers. Plus, lots of spammers borrow computing and bandwidth from other people by infecting their machines with viruses that turn them into "zombies" that can be used to send spam 🧟. That can drop the cost of call spam to nearly zero.

Even without the zombie thing, the savings are even bigger for international calls 🌍. Right now there aren't many telemarketing calls across international borders, mostly because international calls cost a lot. This is one reason the "do not call list" (a United States national list of numbers that telemarketers can't call) has worked well. The law only affects U.S. companies, but since most telemarketing calls are domestic, it has been effective. Unfortunately (and fortunately), the IP network has no boundaries like that, so calls to any SIP URI are possible from anywhere in the world 🌏. That makes international spam way cheaper.

International spam is probably even more annoying than national spam, since it might arrive in languages the recipient doesn't even speak 🙃.

These figures assume the main limit is access bandwidth, not CPU, disk, or termination costs. Termination costs deserve a closer look 👀. Right now, most Voice over IP (VoIP) calls end up on the Public Switched Telephone Network (PSTN), and that termination costs the caller money. These costs are similar to the per-minute rates of a T1. They range from half a cent to three cents per minute, depending on volume and other factors. Still, the equipment costs, training, and other factors are much lower for SIP-based termination than for a T1, so it's still cheaper than circuit connectivity 💖. Also, the current VoIP trend is to make termination free for calls that never touch the PSTN, meaning calls to actual SIP endpoints. So as more and more SIP endpoints come online, termination costs will probably drop 📉. Until then, SIP spam can be combined with termination services for a cheaper version of traditional telemarketer calls, aimed at normal PSTN endpoints.

It's useful to compare these numbers with email 📧. VoIP can deliver about 3.1 successful call attempts per second. Email spam can, of course, deliver more. Assuming 1 KB per email and a 500 Kbps upstream link, a spammer can generate 62.5 messages per second. Bigger messages bring that number down, obviously. Here's the twist: spam filters delete tons of these emails, so the cost per viewed message is probably much higher 🙈. In that sense, call spam is way more attractive, because if the call connects, its content is much more likely to actually get heard by a user 📣.

Collecting addresses is another part of what spamming costs 📒. Over time, spammers have built up huge lists of email addresses, each of the form user@domain, and that's who gets the spam. SIP uses the same addressing form, so it's pretty likely that email addresses can easily be turned into valid SIP addresses 💌. Phone numbers are valid SIP addresses too. With a termination provider, a spammer can aim SIP calls at traditional PSTN devices 📱. It's not clear whether email spammers have also been collecting phone numbers during their Web sweeps, but it's probably not hard to do 🕸️. Also, unlike email addresses, phone numbers are a finite address space that's fairly densely packed. So going through phone numbers one by one is likely to get a pretty high hit rate 🎯. Overall, it seems cheap for a spammer to collect large numbers of SIP addresses to aim spam at 😤.

2.2. IM Spam 💬

IM spam is very much like email when it comes to the costs of deploying and generating spam 🧃. Assuming, for the sake of argument, a 1KB message and 500 Kbps of upstream bandwidth, that's 62.5 messages per second. At $50/month, the result is .31 microcents per message. That's less than voice spam, but not by a lot. The cost is probably on par with email spam. However, IM is way more intrusive than email 😳. In today's systems, IMs pop up and show themselves to the user automatically. Email has to be deliberately selected and opened. Still, most popular IM systems use white lists, which only let an IM through if the sender is on the white list 🛡️. So whether IM spam will be useful seems to depend a lot on how these systems look as the network opens up. If they're deployed everywhere with white-list access, the value of IM spam is likely to be low 📉.

It's important to point out that there are two types of IM systems: page mode and session mode 🎀. Page mode IM systems work a lot like email, with each IM sent as a separate message. In session mode IM, there's signaling before the communication to set up a session, and then IMs are exchanged as part of that session, maybe point-to-point 🤝. The mode changes which spam techniques can be used. Techniques for email can be applied the same way to page mode IM. Session mode IM is more like telephony, though, so lots of techniques (like content filtering) are harder to apply 🫠.

2.3. Presence Spam 👀

Like we said above, presence spam is the creation of bulk unsolicited SUBSCRIBE messages 📨. It costs within a small constant factor of IM spam, so the same cost estimates work here too. So what would this spam actually do? Most presence systems have some kind of consent framework 🔐. A watcher that hasn't been given permission to see the user's presence won't get access to it. But the presence request is usually noted and passed along to the user, so they can approve or deny it ✅. In SIP, this happens through the watcherinfo event package [7]. That package lets a user learn the identity of the watcher so they can make an authorization decision 🧠.

Here's the interesting part: this gives spammers a way to send info to a user 📬. By generating SUBSCRIBE requests from identities like sip:please-buy-my-product@spam.example.com, brief messages can reach the user, even though the sender doesn't have permission to see presence and never will 🙃. So presence spam can be seen as a form of IM spam where the amount of content is limited. That limit is the amount of information the watcher generates that gets passed to the user through the permission system 📏.

This kind of spam also shows up in consent frameworks used to stop call spam, as discussed in Section 3.4 📞.

3. Solution Space 🧩

okay now let's look at the different fixes that might work for SIP spam 🛠️. We mostly look at techniques that have been used against email spam, since that's where the experience is. Just so you know, the solutions below aren't meant to be a full, exhaustive study of email spam fixes. They're more of a representative set 🎁. We also check out a few solutions that seem specific to SIP 💜.

3.1. Content Filtering

okay so the most common anti-spam move for email is content filtering 💅 spam filters read what's inside the email and look for clues that it's spam. Bayesian spam filters live in this category 🧠

BUT, and this is a big but 😭, this kind of filtering that slays for email is totally useless for call spam. There are two reasons:

First, when the user answers the call, the call is already set up and the user is already paying attention before the content shows up. So the spam can't get analyzed before the user sees it. Bestie, that's a whole problem 💀

Second, if the content gets stored before the user checks it (like with voicemail), it's going to be recorded audio or video. Speech and video recognition aren't likely good enough yet to figure out whether it's spam 🙈 Like, if a system tried to transcribe a recording to check it, spammers could just make calls with background noise, bad grammar, and different accents. All of that throws off recognition systems, so it's easy for them to dodge. Video recognition is even harder and is still mostly a research thing 🔬

IM spam is a different story 🦋 Because it's so similar to email, content analysis tools can handle it. The same tools and techniques used for email work directly for IM spam. iconic ✨

3.2. Black Lists

Black listing is when the spam filter keeps a list of addresses that belong to spammers 🚫 These can be usernames (spammer@example.com) or entire domains (example.com).

Pure blacklists aren't very effective for email, and there are two reasons why 💀 First, email addresses are super easy to spoof, so a sender can totally pretend to be someone else. If the sender keeps changing the addresses they send from, the blacklist becomes almost completely useless 😤 The second problem: even when the sender doesn't fake the From address, email addresses are basically unlimited. Each domain has an endless supply of addresses, and new domains are cheap to get 💸 There are also public providers (think Yahoo or AOL mail accounts) that let people get identities for almost nothing 🌈 You can't blacklist a whole domain because it has so many real users in it. Blacklisting has to target individual users, and those identities are easy to swap out 🦋

So, as long as identities are easy to make, or zombies are being used, blacklists have limited power for email 🧟

Blacklists are also likely to be ineffective for SIP spam 💅 Mechanisms for inter-domain authenticated identity for email and SIP are discussed in Section 4 and Section 5. If those mechanisms are used and turned on for inter-domain communications, it gets way harder to forge sender addresses ✨ But it still stays cheap to get a nearly endless supply of addresses. Main character problem, honestly 👑

3.3. White Lists

White lists are the opposite of black lists 🎀 It's a list of valid senders that a user is willing to accept email from. Unlike black lists, a spammer can't just change identities to get around a white list 🙅‍♀️ White lists can be fooled by address spoofing, but a strong identity authentication mechanism can prevent that problem 🔒 So the combo of white lists and strong identity, as described in Section 4.2 and Section 5, is a really good defense against spam 🫶

However, white lists aren't a complete solution 😬 They would stop a user from ever getting email from someone who wasn't explicitly put on the white list. So white lists need a fix for the "introduction problem" (how do you meet someone for the first time and decide whether they should go on the list?). On top of that, white lists take up the user's time to manage 🥲

In IM systems, white lists have been super useful at stopping spam 🔥 A big reason is that the white list already exists naturally as the buddy list. Users don't have to manage it just to block spam. It has general use anyway, and it helps with spam for free 💖 Lots of popular IM systems also have strong identity mechanisms, since they don't allow communication with IM systems in other administrative domains. The introduction problem in those systems gets solved with a consent framework, which is described below 🌸

The success of white lists in IM systems also applies to SIP 🧚 SIP has a buddy list concept too, plus an advanced presence system as part of its specifications. The introduction problem is still there, though. In email, people have used things like Turing tests to deal with the introduction problem, and Turing tests get covered further in the sections below 🤖 Just like with email, a technique for the introduction problem would need to be used together with a white list.

If a user's computer gets compromised and used as a zombie, that computer can usually be used to send spam to anyone who has put that user on their white list 😭 Not it!!

A consent-based solution gets used together with white or black lists 🤝 So if user A isn't on user B's white or black list, and user A tries to communicate with user B, user A's attempt gets rejected at first, and they're told that consent is being requested. The next time user B connects, user B gets told that user A tried to reach them. Then user B can authorize or reject user A 💜

These consent-based systems are used a lot in presence and IM ✨ Since most of the popular IM systems only allow communication within a single administrative domain, sender identities can be authenticated 🔐 Email often uses similar consent-based systems for mailing lists. They use a form of authentication where cookies get sent to an email address to check that a user can actually receive mail there 🍪

This kind of consent-based communication has been standardized in SIP for presence. It uses the watcher information event package [7] and data format [8], which let a user find out that someone has subscribed. Then the XML Configuration Access Protocol (XCAP) [10] is used, along with the XML format for presence authorization [11], to give the user permission to communicate 🎀

A consent framework has also been built that works for other forms of SIP communication [12] 🌈 But this framework focuses on authorizing people to be added to "mailing lists," which are called exploders in SIP terms. Spammers typically use exploder functions, but presumably one run by a spammer wouldn't use this technique 🙃 So this consent framework isn't directly useful for the spam problem. It is useful as a tool for managing a white list, though 📝 Through the PUBLISH mechanism, a user can upload a permission document [13] saying they'll only accept incoming calls from a particular sender 📲

Can a consent framework, like the ones used for presence, help solve call spam? At first glance, it seems like it would help a lot 👀 But it might just change the nature of the spam 😩 Instead of being bugged with content, in the form of call spam or IM spam, users get bugged with consent requests. A user's "communications inbox" could get flooded with requests for communication from tons of different users 📥 Those requests don't carry much useful content, but they can carry some. At the very least, they show the identity of the requester. The user part of the SIP URI allows limited free-form text, so it could be used to send short messages ✍️ You can imagine getting consent requests with identities like sip:please-buy-my-product-at-this-website@spam.example.com, for example 💀 Luckily, it's possible to apply traditional content filtering to the header fields in SIP messages, which cuts down on these kinds of consent request attacks 🛡️

For a spammer to send more detailed content, the user has to explicitly accept the request first, and only then can the spammer send the full content 🙅‍♀️ This is different from email spam. Even though lots of spam gets automatically deleted, some of it still gets through and gets seen by users without them ever saying they wanted to see it 😤 So if consent is required first, the value of sending spam goes down, and maybe it'll stop for the spam cases where consent isn't given to spammers 📉

So the real question is whether a consent system would let a user give consent to non-spammers and reject spammers 🤔 Authenticated identity can help with that. Someone in an enterprise would know to give consent to senders from other enterprises in the same industry, for example 🏢 But in the consumer space, if sip:bob@example.com tries to communicate with a user, how does that user figure out whether Bob is a spammer or a long-lost friend from high school? There's no way to tell from the identity alone 😭 In a case like that, a useful technique is to give Bob permission to communicate but make that permission extremely limited ✨

Specifically, Bob might be allowed to send no more than 200 words of text in a single IM, which he can use to introduce himself, so the user can decide whether more permissions are appropriate 💬 It might even be possible for an automated system to do some form of content analysis on that initial short message 🤖 Still, 200 words of text might be enough for a spammer to get their message across, in much the same way they could use the user part of the SIP URI 🙈

So it seems like a consent-based framework, along with white lists and black lists, can't fully solve the problem for SIP, although it does appear to help 💖

3.5. Reputation Systems 🌸

okay so reputation systems are also used alongside white lists and black lists 👑 say user A isn't on user B's white list and A tries to contact B. If a consent-based system is in play, B gets prompted to consent to A, and right next to that prompt a reputation score might show up to help B decide whether to accept A's messages 💖

Traditionally, reputation systems live in highly centralized messaging architectures. The most widespread ones in messaging today were deployed by monolithic instant messaging providers (though lots of interactive Web sites use very similar reputation ideas too 🌈). Reputation is calculated from user feedback. For example, a button in the messaging client's UI might let users tell the system that someone is abusive. Obviously one person's input has to be not enough to ruin someone's reputation, but consistent negative feedback would give the abusive user a negative reputation score 🙈

Reputation systems work best where resources like user identities and authentication are centralized, and one company controls everything 🔥 Think of the big instant messaging providers that run IM systems which don't exchange messages with other administrative domains. That control gives you a relatively strong identity assertion for users, because everyone trusts the same provider and that provider is the referee for authentication and identity. It also gives you one single place to manage reputation ✨

Now, negative reputation systems have a big problem: they basically have the same issues as black lists, because having a negative reputation just means you're blacklisted 💀 If identities are super easy to get, an abusive user will just make a brand new one. And negative reputation comes from tattling, which only happens when people are annoyed enough to click the warning button. That process can be abused 😭 Some reputation systems even get "reputation mafias," which are big groups of users who routinely bully or extort victims by threatening to collectively give them a negative reputation. Not it. 🙅‍♀️

Positive reputation systems, where users praise each other for being good instead of tattling on each other for being bad, have some similar drawbacks 🫶 Groups of spammers, or even one spammer who gets a ton of identities, could praise each other to fake a positive reputation. Users also have to push past the inertia it takes to actually press the "praise" button. The good news is that positive reputation doesn't get dodged just by making a new identity, unlike the negative kind. That's because basing authorization decisions on positive reputation is basically a form of white listing 🦋

So yeah, positive reputation systems are superior to negative ones, but they're still far from perfect 😅 Here's the iconic part though: combining presence-based systems with reputation systems creates a really interesting fusion ⭐ The "buddy-list" concept of presence is, in effect, a white list. You can infer that the people on your buddy list are people you're "praising." This fixes the user inertia problem with the "praise" button and automates how reputation gets established at the start 🧚

And of course, your buddies have buddies of their own 💅 Together, you and your buddies (and their buddies, and so on) make up a social network of reputation. If you could leverage that social network, you wouldn't need centralization for the reputation system anymore 👑 Your view of someone's reputation could depend on how you're connected to them in the network. Are they one buddy removed (strong reputation), four buddies removed (weaker reputation), or three buddies removed but linked to you through several of your buddies? This web of trust has a very desirable property. Circles of spammers adding each other to their buddy lists wouldn't change your view of their reputation, unless their circle connected to your own social network 🌸

If a user's machine gets compromised and turned into a zombie, it can be used to send SPAM, and that may hurt the user's reputation in a negative way 💔 Once a reputation drops, it becomes extremely difficult to build a positive one back up 😭

3.6. Address Obfuscation 🦋

Spammers build up their spam lists by gathering email addresses from Web sites and other public sources of info 📬 One way to cut down on spam is to make your address difficult or impossible to gather. Spam bots usually look for text on pages in the form user@domain, and they assume anything in that form is an email address 🤖 To hide from those bots, a lot of Web sites have recently started showing email addresses in an obfuscated form. It's usable by humans but hard for an automata to read as an email address. Examples include user at example dot com or j d r o s e n a t e x a m p l e d o t c o m 🌈

These techniques are equally applicable to preventing SIP spam, and they're likely to be just as effective or ineffective against it 🎀

It's worth mentioning that the source of addresses doesn't have to be a Web site. Any publicly accessible service that contains addresses will do 👀 That's why ENUM [9] has been called a potential gold mine for spammers 💰 It would let a spammer collect SIP and other URIs by traversing the tree in e164.arpa and mining it for data. This problem is partly mitigated if only number prefixes, instead of actual numbers, appear in the DNS. Even then, though, it gives a spammer a way to learn which phone numbers are reachable through cheaper direct SIP connectivity 💀

3.7. Limited-Use Addresses 💅

Limited-use addresses are a related technique to address obfuscation 🍓 With this approach, a user has a large number of email addresses at their disposal, and each one has constraints on where it can be used. A limited-use address can be time-bound, so it expires after a fixed period. Or, you can give a different email address to each correspondent. When spam shows up from that correspondent, the limited-use address they were given gets terminated 🚫 In another variation, the same limited-use address goes to multiple users who share some property, like all work colleagues, all coworkers from different companies, all retailers, and so on. If spam starts arriving on one of those addresses, it gets invalidated, which stops communications from everyone else who received that limited-use address 🔥

This technique is equally applicable to SIP. One drawback is that it can make it hard for people to reach you. If an email address you handed to a friend gets spammed, changing it means you have to tell your friend the new address 😩 SIP can help solve this problem in part by making use of presence [6] ✨

Instead of handing out your email address to friends, you hand out your presence URI. When a friend wants to email you, they subscribe to your presence (they're actually likely to be continuously subscribed from a buddy list application 🫶). The presence data can include an email address where you can be reached. That email address can be obfuscated and single-use, different for each buddy who requests your presence. It can also be constantly changed, since those changes get pushed directly to your buddies 🦋 In a sense, the buddy list is an automatically updated address book, so this would eliminate the problem 👑

Another approach is to give a different address to each and every correspondent, so you never have to tell a "good" user that an address needs to change 🌷 This is an extreme form of limited-use addresses, and it can be called a single-use address. SIP has mechanisms for generating [16] an infinite supply of single-use addresses. The hard part, though, is still having a useful mechanism for distributing and managing those addresses 😭

3.8. Turing Tests ✨

Okay so in email, Turing tests are a puzzle or challenge the sender has to beat, and it's something only a human can answer 💅. Since they lean on video or audio puzzles, they sometimes can't be solved by individuals with handicaps 🥺. People also call them captchas (Completely Automated Public Turing test to tell Computers and Humans Apart) 🤖. If the sender gets the puzzle right, the sender gets put on the user's white list 🎀. The puzzles usually look like spotting a word or number sequence in a picture that's full of background noise 🌸. The tests have to be built so bots can't easily do the image recognition needed to pull out the word or number sequence, but a human usually can 👀. Designing them is not easy bestie, because image processing and AI keep leveling up and raising the bar 😭. So how well captchas work really comes down to whether spammers can come up with, or get their hands on, algorithms that solve them automatically 💀.

Like a lot of the other email techniques, Turing tests depend on sender identity, and that can't easily be authenticated in email 🙈.

Turing tests can be used to stop IM spam in pretty much the same way they can be used to stop email spam ✨.

Turing tests can be applied to call spam too, just not directly 🧚. Call spam usually doesn't involve sending images or other content that could confirm a human is on the other end 📞. If most of the calls are voice, the technique has to be adapted to voice, and honestly that's not that hard 🫶. Here's how it could go. User A calls user B and isn't on user B's white or black list. User A gets transferred to an Interactive Voice Response (IVR) system 📞. The IVR tells the user they're about to hear a series of numbers (say 5 of them) and that they have to enter those numbers on the keypad 🔢. The IVR reads the numbers out while background music plays, which makes it hard for an automated speech recognition system to be applied to the media 🎶. The user then enters the numbers on their keypad, and if they're entered correctly, the user gets added to the white list 💖.

This kind of voice-based Turing test is easily extended to a variety of media, like video and text, and to user interfaces, by using the SIP application interaction framework [14] 🦋. The framework lets client devices interact with applications in the network, and that interaction runs on stimulus signaling. That includes keypads (supported with the Keypad Markup Language [15]), but also Web browsers, voice recognition, and so on 🌈. The framework also lets the application figure out the media capabilities of the device (or of the user, in cases where they're handicapped) and interact with them appropriately 👑.

For voice, the Turing test would need to run in the language of the caller 🗣️. This is possible in SIP using the Accept-Language header field, though it isn't widely used at the moment, and it's meant for the languages of SIP message components, not the media streams 🤓.

The main problem with the voice Turing test is the same one email tests have. Instead of an automata processing the test, a spammer can pay cheap workers to take the tests 😤. Say cheap labor in a poor country can be obtained for about 60 cents per hour, and say a Turing test takes 30 seconds. That works out to about 0.50 cents per test, and so about 0.50 cents per message to send an IM spam 💸. Lower labor rates would push that number down even further. The number here is based on real online bids made in September of 2006 for actual work of this type 📅.

Spammers can also skip paying workers and instead trick human users into completing the tests so they can get into what they think is a legit resource 🎣. A spambot did exactly this, posting the tests on a pornography site and requiring users to complete them to get access to the content 🙈.

Because of these limitations, Turing tests may never completely solve the problem 😔.

3.9. Computational Puzzles 🧩

This technique is similar to Turing tests. When user A tries to communicate with user B, user B asks user A to do a computation and pass the result back 🔁. The computation has to be something a human user can't perform, and it has to be expensive enough to raise user A's cost of communicating 💭. That cost increase has to be high enough to make it prohibitively expensive for spammers, but inconsequential for legitimate users ⚖️.

One problem with this technique is that there's wide variation in the computational power of the various clients that might legitimately communicate 📱. The CPU speed on a low-end cell phone is around 50 MHz, while a high-end PC approaches 5 GHz 💻. That's almost two orders of magnitude of difference. So if the test is designed to be reasonable for a cell phone to perform, it's two orders of magnitude cheaper for a spammer on a high-end machine to perform 😬. Recent research has focused on defining computational puzzles that challenge the CPU/memory bandwidth, as opposed to just the CPU [26] 🧠. There seems to be less variety in CPU/memory bandwidth across devices, roughly a single order of magnitude 🙌.

Recent work [28] suggests that spammers can use virus-infected machines (also known as zombies) to generate the spam 🧟. Because of that, the amount of computational power available to spammers is substantial. It may be impossible to have them compute a puzzle that's hard enough to stop them without also blocking normal emails 🚫. If it's combined with white listing, computational puzzles would only be used for new communications partners 🤝. Of course, if the partner on the white list is a zombie, spam will come from that source 💀. The frequency of communications with new partners is arguably higher for email than for multimedia, so computational puzzle techniques may be more effective for SIP than for email when it comes to the introduction problem 🌟.

These techniques are an active area of research right now, and any results for email are likely to be usable for SIP 🔬✨.

3.10. Payments at Risk 💸

This approach has been proposed for email [27] 💌. When user A sends an email to user B, user A deposits a small amount of money (say, one dollar) into user B's account 🏦. If user B decides the message isn't spam, user B refunds the money back to user A 🥰. If the message is spam, user B keeps the money 😈. This technique needs two transactions to complete: a transfer from A to B, and a transfer from B back to A. The first transfer has to happen before the message can be received, so that "pending payments" can't be reused across several messages, which would wreck the whole point 🙅. The second one then needs to happen when the message is found not to be spam 💅.

This technique seems just as applicable to call spam and IM spam as it is to email spam 📞💬. Like a lot of the other techniques, this exchange would only happen the first time you talk to people. So it only works properly with a good authenticated identity infrastructure 🔐.

This technique could make it arbitrarily expensive to send spam of any sort 🤑. But it relies on cheap micro-payment techniques on the Internet 🪙. Traditional costs for Internet payments are around 25 cents per transaction, which would probably be prohibitive 😩. Recently though, some providers have been willing to charge 15% of the transaction for small transactions, as small as one cent 📉. Users of the system would have to shoulder that cost. The cost per user is equal to the number of messages from unknown senders (that is, senders not on the white list) that they receive 📬. For a busy user, assume about 10 new senders per day. If the deposit is 5 cents, the transaction provider takes 0.75 cents and delivers 4.25 cents 🧾. If the sender is allowed, the recipient returns 4.25 cents, the provider takes 0.64 cents, and returns 3.6 cents 🔄. That costs the sender 0.65 cents on each transaction, if it was legitimate 🥲. If there are ten new recipients per day, that's US $1.95 per month, which is relatively inexpensive 💖.

Assuming a micro-payment infrastructure exists, another problem with payment-at-risk is that it loses effectiveness when there are strong inequities in the value of currency between sender and recipient 🌍. For example, a poor person in a Third World country might keep the money in each mail message, whether or not it's spam 🥺. Similarly, a poor person might not be willing to include money in an email, even a legitimate one, for fear the recipient might keep it 😟. If the amount of money is lowered to help with these problems, it might become small enough that spammers can just afford to spend it 📉.

In this solution, countries pass laws that prohibit spam 📜. These laws could apply to IM or call spam just as easily as they could to email spam 📱. There's a lot of debate about whether these laws would actually be effective at preventing spam 🤷‍♀️.

As a recent example in the US, "do not call" lists seem to be effective 📵. However, because of the current cost of long-distance phone calls, the telemarketing is coming from companies within the US 🇺🇸. That means calls from these telemarketers can be traced. If a telemarketer violates the "do not call" list, the trace lets legal action be taken against them 🕵️‍♀️. A similar "do not irritate" list for VoIP or for email would be less likely to work, because the spam is likely to come from international sources 🌏. This problem could be avoided if there was a strong way to identify the sender's legal entity, and then figure out whether it was in a jurisdiction where taking legal action against them is practical 🧐. If the spammer isn't in such a jurisdiction, the SIP spam could be rejected 🚫.

There are also schemes that cause laws other than anti-spam laws to be broken if spam is sent 🤯. This doesn't inherently reduce spam, but it lets more legal options be brought to bear against the spammer 🗡️. For example, Habeas http://www.habeas.com inserts material into the header. If a spammer inserts it without an appropriate license, that would allegedly cause the spammer to violate US copyright and trademark laws, possibly reciprocal laws, and similar laws in many countries 🎀💅.

3.12. Circles of Trust 🫶

okay so picture this: a group of domains (think a set of enterprises) all get together 💅. They agree to exchange SIP calls amongst each other, and they also agree to introduce a fine if any one of them gets caught spamming 😭. Then each company enacts measures to terminate employees who spam from their accounts 💀. Main character accountability energy 👑.

This technique relies on secure inter-domain authentication, which means domain B can know that messages are received from domain A. In SIP, this is readily provided by usage of the mutually authenticated Transport Level Security (TLS)[22] between providers or SIP Identity [17] 🔐.

This kind of technique works well for small domains or small sets of providers, where these policies can be easily enforced 🌸. However, it is unclear how well it scales up. Could a very large domain truly prevent its users from spamming? At what point would the network be large enough that it would be worthwhile to send spam and just pay the fine? How would the pricing be structured to allow both small and large domains alike to participate? Honestly these are the questions keeping me up at night 🙈

3.13. Centralized SIP Providers 🧚

this technique is a variation on the circles of trust described in Section 3.12 ✨. A small number of providers get established as "inter-domain SIP providers". These providers act as a SIP-equivalent to the interexchange carriers in the PSTN. Every enterprise, consumer SIP provider, or other SIP network (call these the local SIP providers) connects to one of these inter-domain providers. The local SIP providers only accept SIP messages from their chosen inter-domain provider. The inter-domain provider charges the local provider, per SIP message, for the delivery of SIP messages to other local providers. The local provider can choose to pass on this cost to its own customers if it so chooses 💖.

The inter-domain SIP providers then form bi-lateral agreements with each other, exchanging SIP messages according to strict contracts. These contracts require that each of the inter-domain providers be responsible for charging a minimum per-message fee to their own customers. Extensive auditing procedures can be put into place to verify this. Besides such contracts, there may or may not be a flow of funds between the inter-domain providers 🧾.

The result of such a system is that a fixed cost can be associated with sending a SIP message, and that this cost does not require micro-payments to be exchanged between local providers, as it does in Section 3.10. Since all of the relationships are pre-established and negotiated, cheaper techniques for monetary transactions (such as monthly post-paid transactions) can be used 🦋.

This technique can be made to work in SIP, whereas it cannot in email, because inter-domain SIP connectivity has not yet been broadly established. In email, there already exists a no-cost form of inter-domain connectivity that cannot be eliminated without destroying the utility of email. If, however, SIP inter-domain communications get established from the start using this structure, there is a path to deployment 🛣️.

This structure is more or less the same as the one in place for the PSTN today, and since there is relatively little spam on the PSTN (compared to email!), there is some proof that this kind of arrangement can work 🤭. However, centralized architectures as these are deliberately eschewed because they put back into SIP much of the complexity and monopolistic structures that the protocol aims to eliminate. Not me being the one bringing back monopolies 🙅‍♀️

4. Authenticated Identity in Email 💌

Though not a form of anti-spam in and of itself, authenticated or verifiable identities are a key part of making other anti-spam mechanisms work. Many of the techniques described above are most effective when combined with a white or black list, which itself requires a strong form of identity 🪪.

In email, two types of authenticated identity have been developed: sender checks and signature-based solutions 🎀.

4.1. Sender Checks 📬

In email, DNS resource records have been defined that will allow a domain that receives a message to verify that the sender is a valid Message Transfer Agent (MTA) for the sending domain [18] [19] [20] [21]. They don't prevent spam by themselves, but may help in preventing spoofed emails. As has been mentioned several times, a form of strong authenticated identity is key in making many other anti-spam techniques work 🔑.

Are these techniques useful for SIP? They can be used for SIP but are not necessary. In SIP, TLS with mutual authentication can be used inter-domain. A provider receiving a message can then reject any message coming from a domain that does not match the asserted identity of the sender of the message. Such a policy only works in the "trapezoid" model of SIP, whereby there are only two domains in any call: the sending domain, which is where the originator resides, and the receiving domain. These techniques are discussed in Section 26.3.2.2 of RFC 3261 [2]. In forwarding situations, the assumption no longer holds and these techniques no longer work. However, the authenticated identity mechanism for SIP, discussed in Section 5, does work in more complex network configurations and provides fairly strong assertion of identity 🧠.

4.2. Signature-Based Techniques ✍️

Domain Keys Identified Mail (DKIM) Signatures [23] (and several non-standard techniques that preceded it) provide strong identity assertions by allowing the sending domain to sign an email, and then providing mechanisms by which the receiving MTA or Mail User Agent (MUA) can validate the signature 💖.

Unfortunately, when used with blacklists, this kind of authenticated identity is only as useful as the fraction of the emails that utilize it. This is partly true for white lists as well; if any unauthenticated email is accepted for an address on a white list, a spammer can spoof that address. However, a white list can be effective with limited deployment of DKIM if all the people on the white list are those whose domains are utilizing the mechanism, and the users on that white list aren't zombies 🧟‍♀️.

This kind of identity mechanism is also applicable to SIP, and is in fact exactly what is defined by SIP's authenticated identity mechanism [17] 🎯.

Other signature-based approaches for email include S/MIME[24] and OpenPGP[25] 🌈.

5. Authenticated Identity in SIP 🪄

One of the key parts of many of the solutions described above is the ability to securely identify the sender of a SIP message. SIP provides a secure solution for this problem, called SIP Identity [17], and it is important to discuss it here 🔍.

The solution starts by having each domain authenticate its own users. SIP provides HTTP digest authentication as part of the core SIP specification, and all clients and servers are required to support it. Indeed, digest is widely deployed for SIP. However, digest alone has many known vulnerabilities, most notably offline dictionary attacks. These vulnerabilities are all resolved by having each client maintain a persistent TLS connection to the server. The client verifies the server identity using TLS, and then authenticates itself to the server using a digest exchange over TLS. This technique, which is also documented in RFC 3261, is very secure but not widely deployed yet. In the long term, this approach will be necessary for the security properties needed to prevent SIP spam 🔒.

Once a domain has authenticated the identity of a user, when it relays a message from that user to another domain, the sending domain can assert the identity of the sender, and include a signature to validate that assertion. This is done using the SIP identity mechanism [17] ✅.

A weaker form of identity assertion is possible using the P-Asserted-Identity header field [5], but this technique requires mutual trust among all domains. Unfortunately, this becomes exponentially harder to provide as the number of interconnected domains grows. As that happens, the value of the identity assertion becomes equal to the trustworthiness of the least trustworthy domain. Since spam is a consequence of the receiving domain not being able to trust the sending domains to disallow the hosts in the sending to send spam, the P-Asserted-Identity technique becomes ineffective at exactly the same levels of interconnectedness that introduce spam 😩.

Consider the following example to help illustrate this fact. A malicious domain (let us call them spam.example.com) would like to send INVITE requests with false P-Asserted-Identity, indicating users outside of its own domain. spam.example.com finds a regional SIP provider in a small country who, due to its small size and disinterest in spam, accepts any P-Asserted-Identity from its customers without verification. This provider, in turn, connects to a larger, interconnect provider. They do ask each of their customers to verify P-Asserted-Identity but have no easy way of enforcing it. This provider, in turn, connects to everyone else. As a consequence, the spam.example.com domain is able to inject calls with a spoofed caller ID. This request can be directed to any recipient reachable through the network (presumably everyone due to the large size of the root provider). There is no way for a recipient to know that this particular P-Asserted-Identity came from this bad spam.example.com domain. As the example shows, even though the central provider's policy is good, the overall effectiveness of P-Asserted-Identity is still only as good as the policies of the weakest link in the chain 🚨.

SIP also defines the usage of TLS between domains, using mutual authentication, as part of the base specification. This technique provides a way for one domain to securely determine that it is talking to a server that is a valid representative of another domain 🤝.

6. Framework for Anti-Spam in SIP ✨

Okay bestie, bad news first: there's no magic bullet for SIP spam 😭, same as email spam. 💀 But stacking a few techniques together gives you a real framework for handling it 💅. This section is the recommendations list for network designers who want to lower their spam risk 🫶.

There are four core recommendations 👑:

Strong Identity: Almost every solution we've covered depends on being able to authenticate who sent a SIP message across domains 🔐. Consent, reputation systems, computational puzzles, payments at risk, and a few others all work best when they only kick in for new requests, and when someone finishes an introduction, they get placed on a white list 🎀. But white lists only work if the identities are strong, so any network that talks to other networks should use strong SIP identity as described in RFC 4474 🦋. P-Asserted-Identity is not strong enough, sorry not sorry 🙈.

White Lists: Once you have a strong identity system, networks are recommended to use white lists 🌸. Ideally you build them off existing buddy lists if you've got those. If not, you can manage separate white lists just for spam ✨. People can be added manually, or automatically after they finish one or more introduction mechanisms 🧚.

Solve the Introduction Problem: This leads to the last recommendation 💜. Network designers should use one or more mechanisms built to solve the introduction problem. You can even use more than one and combine the results using some kind of weighting ⭐. A user who successfully completes the introduction mechanism can be added to the white list automatically, but that only works properly if their identity is verified by SIP Identity 🔥. The mechanisms in this document are based on some (not all!) of the techniques known and used when this was written 🍓. Providers should keep an eye on what's happening in email as it evolves and use the best of those techniques 👀.

Don't Wait Until It's Too Late: Most importantly, providers should not ignore the spam problem until it hits them 😭🚨. The second you interconnect with other providers, or let SIP messages in from the open Internet, you have to figure out how you're going to deal with spam 💅.

7. Additional Work 🌈

The framework above is a solid foundation for dealing with SIP spam, but there are still gaps 🧩. Some of them could be fixed by future work that hasn't been started yet 🔮.

Here's the big one. With strong identity techniques, if a receiver gets a SIP request with no authenticated identity, they can't tell why it's missing. Maybe the originating domain just doesn't support identity at all 🤷‍♀️, or maybe a man-in-the-middle stripped it off 😱. That's why transition mechanisms should be put in place so those two cases can be told apart 🕵️‍♀️. Without that, the value of the identity mechanism is much reduced 💔.

Bestie, this is the kind of gap that makes the whole identity plan wobble, so keep it on your radar 👀.

8. Security Considerations 🔐

This document is entirely about spam in SIP 🚫📞. It also references a bunch of security mechanisms that help reach that goal, so the security story is tied to all of them 💜.

9. Acknowledgements 🫶

The authors want to thank Rohan Mahy for sharing information on Habeas 🙌, and Baruch Sterman for providing costs on VoIP termination services 💸. Gonzalo Camarillo and Vijay Gurbani get big thanks for their reviews 🌟. Useful comments and feedback came from Nils Ohlmeir, Tony Finch, Randy Gellens, Lisa Dusseault, Sam Hartman, Chris Newman, Tim Polk, Donald Eastlake, and Yakov Shafranovich 💖. Jon Peterson wrote some of the text in this document and kept contributing as the work moved along 👑.

10. Informative References 📚

  • [1] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
  • [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
  • [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
  • [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
  • [5] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
  • [6] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
  • [7] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
  • [8] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004.
  • [9] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
  • [10] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
  • [11] Rosenberg, J., "Presence Authorization Rules", RFC 5025, October 2007.
  • [12] Rosenberg, J., "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)", Work in Progress, October 2007.
  • [13] Camarillo, G., "A Document Format for Requesting Consent", Work in Progress, October 2007.
  • [14] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", Work in Progress, October 2005.
  • [15] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006.
  • [16] Rosenberg, J., "Applying Loose Routing to Session Initiation Protocol (SIP) User Agents (UA)", Work in Progress, June 2007.
  • [17] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
  • [18] Allman, E. and H. Katz, "SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message", RFC 4405, April 2006.
  • [19] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
  • [20] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
  • [21] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
  • [22] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
  • [23] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
  • [24] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
  • [25] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
  • [26] Abadi, M., Burrows, M., Manasse, M., and T. Wobber, "Moderately Hard, Memory Bound Functions, NDSS 2003", February 2003.
  • [27] Abadi, M., Burrows, M., Birrell, A., Dabek, F., and T. Wobber, "Bankable Postage for Network Services, Proceedings of the 8th Asian Computing Science Conference, Mumbai, India", December 2003.
  • [28] Clayton, R. and B. Laurie, "Proof of Work Proves not to Work, Third Annual Workshop on Economics and Information Security", May 2004.

Authors' Addresses 🎀

Jonathan Rosenberg
Cisco
Edison, NJ
US

EMail: jdrosen@cisco.com
URI:   http://www.jdrosen.net


Cullen Jennings
Cisco
170 West Tasman Dr.
San Jose, CA  95134
US

Phone: +1 408 421-9990
EMail: fluffy@cisco.com

Copyright (C) The IETF Trust (2008). 💖

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 🦋

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭

Intellectual Property 🧠

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the technology described in this document 🤐, or on whether any license under such rights might be available 🔑. It also doesn't claim to have independently searched for any such rights 🔍. Information about the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📖.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users of this specification can be found at the IETF online IPR repository: http://www.ietf.org/ipr 🌐.

The IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard 💅. Send that information to the IETF at ietf-ipr@ietf.org 📬✨.

📦 where this page comes from