draft-ietf-sipping-spam-03.txt   draft-ietf-sipping-spam-04.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft C. Jennings Internet-Draft C. Jennings
Expires: April 25, 2007 Cisco Expires: August 30, 2007 Cisco
October 22, 2006 February 26, 2007
The Session Initiation Protocol (SIP) and Spam The Session Initiation Protocol (SIP) and Spam
draft-ietf-sipping-spam-03 draft-ietf-sipping-spam-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2007. This Internet-Draft will expire on August 30, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Spam, defined as the transmission of bulk unsolicited messages, has Spam, defined as the transmission of bulk unsolicited messages, has
plagued Internet email. Unfortunately, spam is not limited to email. plagued Internet email. Unfortunately, spam is not limited to email.
It can affect any system that enables user to user communications. It can affect any system that enables user to user communications.
The Session Initiation Protocol (SIP) defines a system for user to The Session Initiation Protocol (SIP) defines a system for user to
user multimedia communications. Therefore, it is susceptible to user multimedia communications. Therefore, it is susceptible to
spam, just as email is. In this document, we analyze the problem of spam, just as email is. In this document, we analyze the problem of
spam in SIP. We first identify the ways in which the problem is the spam in SIP. We first identify the ways in which the problem is the
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Call Spam . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Call Spam . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. IM Spam . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. IM Spam . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Presence Spam . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Presence Spam . . . . . . . . . . . . . . . . . . . . . . 7
3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Content Filtering . . . . . . . . . . . . . . . . . . . . 8 3.1. Content Filtering . . . . . . . . . . . . . . . . . . . . 8
3.2. Black Lists . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Black Lists . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. White Lists . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. White Lists . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Consent-Based Communications . . . . . . . . . . . . . . . 10 3.4. Consent-Based Communications . . . . . . . . . . . . . . . 10
3.5. Reputation Systems . . . . . . . . . . . . . . . . . . . . 12 3.5. Reputation Systems . . . . . . . . . . . . . . . . . . . . 12
3.6. Address Obfuscation . . . . . . . . . . . . . . . . . . . 13 3.6. Address Obfuscation . . . . . . . . . . . . . . . . . . . 13
3.7. Limited Use Addresses . . . . . . . . . . . . . . . . . . 14 3.7. Limited Use Addresses . . . . . . . . . . . . . . . . . . 14
3.8. Turing Tests . . . . . . . . . . . . . . . . . . . . . . . 14 3.8. Turing Tests . . . . . . . . . . . . . . . . . . . . . . . 15
3.9. Computational Puzzles . . . . . . . . . . . . . . . . . . 16 3.9. Computational Puzzles . . . . . . . . . . . . . . . . . . 16
3.10. Payments at Risk . . . . . . . . . . . . . . . . . . . . . 17 3.10. Payments at Risk . . . . . . . . . . . . . . . . . . . . . 17
3.11. Legal Action . . . . . . . . . . . . . . . . . . . . . . . 18 3.11. Legal Action . . . . . . . . . . . . . . . . . . . . . . . 18
3.12. Circles of Trust . . . . . . . . . . . . . . . . . . . . . 18 3.12. Circles of Trust . . . . . . . . . . . . . . . . . . . . . 19
3.13. Centralized SIP Providers . . . . . . . . . . . . . . . . 19 3.13. Centralized SIP Providers . . . . . . . . . . . . . . . . 19
4. Authenticated Identity in Email . . . . . . . . . . . . . . . 20 4. Authenticated Identity in Email . . . . . . . . . . . . . . . 20
4.1. Sender Checks . . . . . . . . . . . . . . . . . . . . . . 20 4.1. Sender Checks . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Signature-Based Techniques . . . . . . . . . . . . . . . . 20 4.2. Signature-Based Techniques . . . . . . . . . . . . . . . . 21
5. Authenticated Identity in SIP . . . . . . . . . . . . . . . . 21 5. Authenticated Identity in SIP . . . . . . . . . . . . . . . . 21
6. Framework for Anti-Spam in SIP . . . . . . . . . . . . . . . . 22 6. Framework for Anti-Spam in SIP . . . . . . . . . . . . . . . . 23
7. Additional Work . . . . . . . . . . . . . . . . . . . . . . . 23 7. Additional Work . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Informative References . . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
11. Informative References . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
Spam, defined as the transmission of bulk unsolicited email, has been Spam, defined as the transmission of bulk unsolicited email, has been
a plague on the Internet email system, rendering it nearly useless. a plague on the Internet email system, rendering it nearly useless.
Many solutions have been documented and deployed to counter the Many solutions have been documented and deployed to counter the
problem. None of these solutions is ideal. However, one thing is problem. None of these solutions is ideal. However, one thing is
clear: the spam problem would be much less significant had solutions clear: the spam problem would be much less significant had solutions
skipping to change at page 6, line 24 skipping to change at page 6, line 24
for SIP-based termination than a T1, making the cost still lower than for SIP-based termination than a T1, making the cost still lower than
circuit connectivity. Furthermore, the current trend in VoIP systems circuit connectivity. Furthermore, the current trend in VoIP systems
is to make termination free for calls that never touch the PSTN, that is to make termination free for calls that never touch the PSTN, that
is, calls to actual SIP endpoints. Thus, as more and more SIP is, calls to actual SIP endpoints. Thus, as more and more SIP
endpoints come online (there are probably around 5 million endpoints come online (there are probably around 5 million
addressable SIP endpoints on the Internet as of writing), termination addressable SIP endpoints on the Internet as of writing), termination
costs will probably drop. Until then, SIP spam can be used in costs will probably drop. Until then, SIP spam can be used in
concert with termination services for a lower cost form of concert with termination services for a lower cost form of
traditional telemarketer calls, made to normal PSTN endpoints. traditional telemarketer calls, made to normal PSTN endpoints.
This number (9 deliveries per second) is below the successful message It is useful to compare these figures with email. VoIP can deliver
delivery rate of email [[NOTE: is there a figure for this]]. approximately 9 successful call attempts per second. Email spam can,
However, many spam messages are automatically deleted by filters or of course, deliver more. Assuming 1 kB per email, and an upstream
users without ever being read. It is far more likely that a call link of 500 kbps, a spammer can generate 62.5 messages per second.
spam will be examined by a user if its delivered, due to the This number goes down with larger messages of course. Interestingly,
difficulty in automated content filtering (see below). Thus, when spam filters delete large numbers of these mails, so the cost per
one examines the final figure of importance - the number of new viewed message is likely to be much higher. In that sense, call spam
customers attracted per spam delivered, it is far from clear whether is much more attractive, since its content is much more likely to be
call spam or email spam will be more effective. examined by a user if a call attempt is successful.
Another part of the cost of spamming is collecting addresses. Another part of the cost of spamming is collecting addresses.
Spammers have, over time, built up immense lists of email addresses, Spammers have, over time, built up immense lists of email addresses,
each of the form user@domain, to which spam is directed. SIP uses each of the form user@domain, to which spam is directed. SIP uses
the same form of addressing, making it likely that email addresses the same form of addressing, making it likely that email addresses
can easily be turned into valid SIP addresses. Telephone numbers can easily be turned into valid SIP addresses. Telephone numbers
also represent valid SIP addresses, in that, in concert with a also represent valid SIP addresses; in concert with a termination
termination provider, a spammer can direct SIP calls at traditional provider, a spammer can direct SIP calls at traditional PSTN devices.
PSTN devices. It is not clear whether email spammers have also been It is not clear whether email spammers have also been collecting
collecting phone numbers as they perform their web sweeps, but it is phone numbers as they perform their web sweeps, but it is probably
probably not hard to do so. Furthermore, unlike email addresses, not hard to do so. Furthermore, unlike email addresses, phone
phone numbers are a finite address space and one that is fairly numbers are a finite address space and one that is fairly densely
densely packed. As a result, going sequentially through phone packed. As a result, going sequentially through phone numbers is
numbers is likely to produce a fairly high hit rate. Thus, it seems likely to produce a fairly high hit rate. Thus, it seems like the
like the cost is relatively low for a spammer to obtain large numbers cost is relatively low for a spammer to obtain large numbers of SIP
of SIP addresses to which spam can be directed. addresses to which spam can be directed.
2.2. IM Spam 2.2. IM Spam
IM spam is very much like email, in terms of the costs for deploying IM spam is very much like email, in terms of the costs for deploying
and generating spam. Assuming, for the sake of argument, a 1kB and generating spam. Assuming, for the sake of argument, a 1kB
message to be sent and 500 Kbps of upstream bandwidth, thats 62 message to be sent and 500 Kbps of upstream bandwidth, thats 62
messages per second. At $50/month, the result is 31 microcents per messages per second. At $50/month, the result is 31 microcents per
message. This is less than voice spam, but not substantially less. message. This is less than voice spam, but not substantially less.
The cost is probably on par with email spam. However, IM is much The cost is probably on par with email spam. However, IM is much
more intrusive than email. In today's systems, IMs automatically pop more intrusive than email. In today's systems, IMs automatically pop
up and present themselves to the user. Email, of course, must be up and present themselves to the user. Email, of course, must be
deliberately selected and displayed. However, many IM systems employ deliberately selected and displayed. However, many IM systems employ
white lists, which only allow spam to be delivered if the sender is white lists, which only allow IM to be delivered if the sender is on
on the white list. Thus, whether or not IM spam will be useful seems the white list. Thus, whether or not IM spam will be useful seems to
to depend a lot on the nature of the systems as the network is opened depend a lot on the nature of the systems as the network is opened
up. If they are ubiquitously deployed with white-list access, the up. If they are ubiquitously deployed with white-list access, the
value of IM spam is likely to be low. value of IM spam is likely to be low.
It is important to point out that there are two different types of IM It is important to point out that there are two different types of IM
systems. Page mode IM systems work much like email, with each IM systems. Page mode IM systems work much like email, with each IM
being sent as a separate message. In session mode IM, there is being sent as a separate message. In session mode IM, there is
signaling in advance of communication to establish a session, and signaling in advance of communication to establish a session, and
then IMs are exchanged, perhaps point-to-point, as part of the then IMs are exchanged, perhaps point-to-point, as part of the
session. The modality impacts the types of spam techniques that can session. The modality impacts the types of spam techniques that can
be applied. Techniques for email can be applied identically to page be applied. Techniques for email can be applied identically to page
skipping to change at page 8, line 25 skipping to change at page 8, line 25
a representative set. We also consider some solutions that appear to a representative set. We also consider some solutions that appear to
be SIP-specific. be SIP-specific.
3.1. Content Filtering 3.1. Content Filtering
The most common form of spam protection used in email is based on The most common form of spam protection used in email is based on
content filtering. These spam filters analyze the content of the content filtering. These spam filters analyze the content of the
email, and look for clues that the email is spam. Bayesian spam email, and look for clues that the email is spam. Bayesian spam
filters are in this category. filters are in this category.
Unfortunately, this type of spam filtering is almost completely Unfortunately, this type of spam filtering, while successful for
useless for call spam. There are two reasons. First, in the case email spam, is completely useless for call spam. There are two
where the user answers the call, the call is already established and reasons. First, in the case where the user answers the call, the
the user is paying attention before the content is delivered. The call is already established and the user is paying attention before
spam cannot be analyzed before the user sees it. Second, if the the content is delivered. The spam cannot be analyzed before the
content is stored before the user accesses it (e.g., with voicemail), user sees it. Second, if the content is stored before the user
the content will be in the form of recorded audio or video. Speech accesses it (e.g., with voicemail), the content will be in the form
and video recognition technology is not likely to be good enough to of recorded audio or video. Speech and video recognition technology
analyze the content and determine whether or not it is spam. Indeed, is not likely to be good enough to analyze the content and determine
if a system tried to perform speech recognition on a recording in whether or not it is spam. Indeed, if a system tried to perform
order to perform such an analysis, it would be easy for the spammers speech recognition on a recording in order to perform such an
to make calls with background noises, poor grammar and varied analysis, it would be easy for the spammers to make calls with
accents, all of which will throw off recognition systems. Video background noises, poor grammar and varied accents, all of which will
recognition is even harder to do and remains primarily an area of throw off recognition systems. Video recognition is even harder to
research. do and remains primarily an area of research.
Therefore, our conclusion is that the most successful form of anti-
spam measures used in email are almost useless for call spam.
IM spam, due to its similarity to email, can be countered with IM spam, due to its similarity to email, can be countered with
content analysis tools. Indeed, the same tools and techniques used content analysis tools. Indeed, the same tools and techniques used
for email will directly work for IM spam. for email will directly work for IM spam.
Content filtering will not help for presence spam because by
definition, a request subscribing for the presence of a user will be
devoid of any content.
3.2. Black Lists 3.2. Black Lists
Black listing is an approach whereby the spam filter maintains a list Black listing is an approach whereby the spam filter maintains a list
of addresses that identify spammers. These addresses include both of addresses that identify spammers. These addresses include both
usernames (spammer@domain.com) and entire domains (spammers.com). usernames (spammer@example.com) and entire domains (example.com).
Pure blacklists are not very effective in email for two reasons. Pure blacklists are not very effective in email for two reasons.
First, email addresses are easy to spoof, making it easy for the First, email addresses are easy to spoof, making it easy for the
sender to pretend to be someone else. If the sender varies the sender to pretend to be someone else. If the sender varies the
addresses they send from, the black list becomes almost completely addresses they send from, the black list becomes almost completely
useless. The second problem is that, even if the sender doesn't useless. The second problem is that, even if the sender doesn't
forge the from address, email addresses are in almost limitless forge the from address, email addresses are in almost limitless
supply. Each domain contains an infinite supply of email addresses, supply. Each domain contains an infinite supply of email addresses,
and new domains can be obtained for very low cost. Furthermore, and new domains can be obtained for very low cost. Furthermore,
there will always be public providers that will allow users to obtain there will always be public providers that will allow users to obtain
identities for almost no cost (for example, Yahoo or AOL mail identities for almost no cost (for example, Yahoo or AOL mail
skipping to change at page 11, line 19 skipping to change at page 11, line 23
call spam? At first glance, it would seem to help a lot. However, call spam? At first glance, it would seem to help a lot. However,
it might just change the nature of the spam. Instead of being it might just change the nature of the spam. Instead of being
bothered with content, in the form of call spam or IM spam, users are bothered with content, in the form of call spam or IM spam, users are
bothered with consent requests. A user's "communications inbox" bothered with consent requests. A user's "communications inbox"
might instead be filled with requests for communications from a might instead be filled with requests for communications from a
multiplicity of users. Those requests for communications don't multiplicity of users. Those requests for communications don't
convey much useful content to the user, but they can convey some. At convey much useful content to the user, but they can convey some. At
the very least, they will convey the identity of the requester. The the very least, they will convey the identity of the requester. The
user part of the SIP URI allows for limited freeform text, and thus user part of the SIP URI allows for limited freeform text, and thus
could be used to convey brief messages. One can imagine receiving could be used to convey brief messages. One can imagine receiving
consent requests with identities like, consent requests with identities like
"sip:please-buy-my-product-at-this-website@spam.example.com", for "sip:please-buy-my-product-at-this-website@spam.example.com", for
example. Fortunately, traditional content-based filtering can be example. Fortunately, it is possible to apply traditional content
applied to this type of information. filtering systems to the header fields in the SIP messages, thus
blocking these kinds of consent requests.
In order for the spammer to convey more extensive content to the In order for the spammer to convey more extensive content to the
user, the user must explicitly accept the request, and only then can user, the user must explicitly accept the request, and only then can
the spammer convey the full content. This is unlike email spam, the spammer convey the full content. This is unlike email spam,
where, even though much spam is automatically deleted, some where, even though much spam is automatically deleted, some
percentage of the content does get through, and is seen by users, percentage of the content does get through, and is seen by users,
without their explicit consent that they want to see it. Thus, if without their explicit consent that they want to see it. Thus, if
consent is required first, and nearly all users do not give consent consent is required first, and nearly all users do not give consent
to spammers, the value in sending spam is reduced, and perhaps it to spammers, the value in sending spam is reduced, and perhaps it
will cease. will cease.
As such, the real question is whether or not the consent system would As such, the real question is whether or not the consent system would
make it possible for a user to give consent to non-spammers and make it possible for a user to give consent to non-spammers and
reject spammers. Authenticated identity can help. A user in an reject spammers. Authenticated identity can help. A user in an
enterprise would know to give consent to senders in other enterprises enterprise would know to give consent to senders in other enterprises
in the same industry, for example. However, in the consumer space, in the same industry, for example. However, in the consumer space,
if sip:bob@example.com tries to communicate with a user, how does if sip:bob@example.com tries to communicate with a user, how does
that user determine whether bob is a spammer or a long-lost friend that user determine whether bob is a spammer or a long-lost friend
from high school? There is no way based on the identity alone. In from high school? There is no way based on the identity alone. In
such a case, a useful technique is to grant permission for bob to such a case, a useful technique is to grant permission for bob to
communicate but to make the permission is extremely limited. In communicate but to ensure that the permission is extremely limited.
particular, bob may be granted permission to send no more than 200 In particular, bob may be granted permission to send no more than 200
words of text in a single IM, which he can use to identify himself, words of text in a single IM, which he can use to identify himself,
so that the user can determine whether or not more permissions are so that the user can determine whether or not more permissions are
appropriate. However, this 200 words of text may be enough for a appropriate. However, this 200 words of text may be enough for a
spammer to convey their message, in much the same way they might spammer to convey their message, in much the same way they might
convey it in the user part of the SIP URI. convey it in the user part of the SIP URI.
Thus, it seems that a consent-based framework, along with white lists Thus, it seems that a consent-based framework, along with white lists
and black lists, cannot fully solve the problem for SIP, although it and black lists, cannot fully solve the problem for SIP, although it
does appear to help. does appear to help.
3.5. Reputation Systems 3.5. Reputation Systems
A reputation system is also used in conjunction with white or black A reputation system is also used in conjunction with white or black
lists. Assume that user A is not on user B's white list, and they lists. Assume that user A is not on user B's white list, and A
attempt to contact user B. If a consent-based system is used, B is attempts to contact user B. If a consent-based system is used, B is
prompted to consent to communications from A, a reputation score prompted to consent to communications from A, and along with the
might be displayed in order to help B decide whether or not they consent, a reputation score might be displayed in order to help B
should accept communications from A. decide whether or not they should accept communications from A.
Traditionally, reputation systems are implemented in highly Traditionally, reputation systems are implemented in highly
centralized messaging architectures; the most widespread reputation centralized messaging architectures; the most widespread reputation
systems in messaging today have been deployed by monolithic instant systems in messaging today have been deployed by monolithic instant
messaging providers (though many web sites with a high degree of messaging providers (though many web sites with a high degree of
interactivity employ very similar concepts of reputation). interactivity employ very similar concepts of reputation).
Reputation is calculated based on user feedback. For example, a Reputation is calculated based on user feedback. For example, a
button on the user interface of the messaging client might empower button on the user interface of the messaging client might empower
users to inform the system that a particular user is abusive. Of users to inform the system that a particular user is abusive. Of
course, the input of any single user has to be insufficient to ruin course, the input of any single user has to be insufficient to ruin
one's reputation, but consistent negative feedback would give the one's reputation, but consistent negative feedback would give the
abusive user a negative reputation score. abusive user a negative reputation score.
Reputation systems have not enjoyed much success outside of the Reputation systems have been successful in systems where
instant messaging space. This is in part because few other centralization of resources (user identities, authentication, etc.)
communications systems admit of the same degree of centralization and and monolithic control dominate. Examples of these include the large
monolithic control. That control, first of all, provides a instant messaging providers that run closed, proprietary networks.
relatively strong identity assertion for users (since all users trust That control, first of all, provides a relatively strong identity
a common provider, and the common provider is the arbiter of assertion for users (since all users trust a common provider, and the
authentication and identity). Secondly, it provides a single place common provider is the arbiter of authentication and identity).
where reputation can be managed. Secondly, it provides a single place where reputation can be managed.
Reputation systems based on negative reputation scores suffer from Reputation systems based on negative reputation scores suffer from
many of the same problems as black lists, since effectively the many of the same problems as black lists, since effectively the
consequence of having a negative reputation is that you are consequence of having a negative reputation is that you are
blacklisted. If identities are very easy to acquire, a user with a blacklisted. If identities are very easy to acquire, a user with a
negative reputation will simply acquire a new one. Moreover, negative reputation will simply acquire a new one. Moreover,
negative reputation is generated by tattling, which requires users to negative reputation is generated by tattling, which requires users to
be annoyed enough to click the warning button. Additionally, it can be annoyed enough to click the warning button. Additionally, it can
be abused. In some reputation systems, "reputation mafias" be abused. In some reputation systems, "reputation mafias"
consisting of large numbers of users routinely bully or extort consisting of large numbers of users routinely bully or extort
victims by threatening collectively to grant victims a negative victims by threatening collectively to grant victims a negative
reputation. reputation.
Reputation systems based on positive reputation, where users praise Reputation systems based on positive reputation, where users praise
each other for being good, rather than tattling on each other for each other for being good, rather than tattling on each other for
being bad, have some similar drawbacks. Collectives of spammers, or being bad, have some similar drawbacks. Collectives of spammers, or
just one spammer who acquires a large number identities, could praise just one spammer who acquires a large number identities, could praise
one another in order to create an artifical positive reputation. one another in order to create an artificial positive reputation.
Users similarly have to overcome the inertia required to press the Users similarly have to overcome the inertia required to press the
"praise" button. Unlike negative reputation systems, however, "praise" button. Unlike negative reputation systems, however,
positive reputation is not circumvented when users require a new positive reputation is not circumvented when users require a new
identity, since basing authorization decisions on positive reputation identity, since basing authorization decisions on positive reputation
is essentially a form of whitelisting. is essentially a form of whitelisting.
So, while positive reputation systems are superior to negative So, while positive reputation systems are superior to negative
reputation systems, they are far from perfect. Intriguingly, though, reputation systems, they are far from perfect. Intriguingly, though,
combining presence-based systems with reputation systems leads to an combining presence-based systems with reputation systems leads to an
interesting fusion. The "buddy-list" concept of presence is, in interesting fusion. The "buddy-list" concept of presence is, in
skipping to change at page 14, line 6 skipping to change at page 14, line 10
begun placing email addresses in an obfuscated form, usable to humans begun placing email addresses in an obfuscated form, usable to humans
but difficult for an automata to read as an email address. Examples but difficult for an automata to read as an email address. Examples
include forms such as, "user at example dot com" or "j d r o s e n a include forms such as, "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". t e x a m p l e d o t c o m".
These techniques are equally applicable to prevention of SIP spam, These techniques are equally applicable to prevention of SIP spam,
and are likely to be as equally effective or ineffective in its and are likely to be as equally effective or ineffective in its
prevention. prevention.
It is worth mentioning that the source of addresses need not be a web It is worth mentioning that the source of addresses need not be a web
site - any publically accessible service containing addresses will site - any publicly accessible service containing addresses will
suffice. As a result, ENUM [9] has been cited as a potential gold suffice. As a result, ENUM [9] has been cited as a potential gold
mine for spammers. It would allow a spammer to collect SIP and other mine for spammers. It would allow a spammer to collect SIP and other
URIs by traversing the tree in e164.arpa and mining it for data. URIs by traversing the tree in e164.arpa and mining it for data.
This problem is mitigated in part if only number prefixes, as opposed This problem is mitigated in part if only number prefixes, as opposed
to actual numbers, appear in the DNS. Even in that case, however, it to actual numbers, appear in the DNS. Even in that case, however, it
provides a technique for a spammer to learn which phone numbers are provides a technique for a spammer to learn which phone numbers are
reachable through cheaper direct SIP connectivity. reachable through cheaper direct SIP connectivity.
3.7. Limited Use Addresses 3.7. Limited Use Addresses
A related technique to address obfuscation is limited use addresses. A related technique to address obfuscation is limited use addresses.
In this technique, a user has a large number of email addresses at In this technique, a user has a large number of email addresses at
their disposal. They give out different email addresses to different their disposal, each of which has constraints on its applicability.
people. Once spam begins arriving at an address, the user terminates A limited use address can be time-bound, so that it expires after a
the address and replaces it with another. fixed period. Or, a different email address can be given to each
correspondent. When spam arrives from that correspondent, the
limited use address they were given is terminated. In another
variation, the same limited use address is given to multiple users
that share some property; for example, all work colleagues, all
coworkers from different companies, all retailers, and so on. Should
spam begin arriving on one of the addresses, it is invalidated,
preventing communications from anyone else that received the limited
use address.
This technique is equally applicable to SIP. One of the drawbacks of This technique is equally applicable to SIP. One of the drawbacks of
the approach is that it can make it hard for people to reach you; if the approach is that it can make it hard for people to reach you; if
an email address you hand out to a friend becomes spammed, changing an email address you hand out to a friend becomes spammed, changing
it requires you to inform your friend of the new address. SIP can it requires you to inform your friend of the new address. SIP can
help solve this problem in part, by making use of presence [6]. help solve this problem in part, by making use of presence [6].
Instead of handing out your email address to your friends, you would Instead of handing out your email address to your friends, you would
hand out your presence URI. When a friend wants to send you an hand out your presence URI. When a friend wants to send you an
email, they subscribe to your presence (indeed, they are likely email, they subscribe to your presence (indeed, they are likely
continuously subscribed from a buddy list application). The presence continuously subscribed from a buddy list application). The presence
skipping to change at page 14, line 43 skipping to change at page 15, line 6
email address can be obfuscated and be of single use, different for email address can be obfuscated and be of single use, different for
each buddy who requests your presence. They can also be constantly each buddy who requests your presence. They can also be constantly
changed, as these changes are pushed directly to your buddies. In a changed, as these changes are pushed directly to your buddies. In a
sense, the buddy list represents an automatically updated address sense, the buddy list represents an automatically updated address
book, and would therefore eliminate the problem. book, and would therefore eliminate the problem.
Another approach is to give a different address to each and every Another approach is to give a different address to each and every
correspondent, so that it is never necessary to tell a "good" user correspondent, so that it is never necessary to tell a "good" user
that an address needs to be changed. This is an extreme form of that an address needs to be changed. This is an extreme form of
limited use addresses, which can be called a single-use address. limited use addresses, which can be called a single-use address.
Mechanisms are available in SIP for the generation of [25] an Mechanisms are available in SIP for the generation of [17] an
infinite supply of single use addresses. However, the hard part infinite supply of single use addresses. However, the hard part
remains a useful mechanism for distribution and management of those remains a useful mechanism for distribution and management of those
addresses. addresses.
3.8. Turing Tests 3.8. Turing Tests
In email, Turing tests are those solutions whereby the sender of the In email, Turing tests are those solutions whereby the sender of the
message is given some kind of puzzle or challenge, which only a human message is given some kind of puzzle or challenge, which only a human
can answer. If the puzzle is answered correctly, the sender is can answer. These tests are also known as captchas (Completely
placed on the user's white list. These puzzles frequently take the Automated Public Turing test to tell Computers and Humans Apart). If
form of recognizing a word or sequence of numbers in an image with a the puzzle is answered correctly, the sender is placed on the user's
lot of background noise. Automata cannot easily perform the image white list. These puzzles frequently take the form of recognizing a
recognition needed to extract the word or number sequence, but a word or sequence of numbers in an image with a lot of background
human user usually can. Since Turing tests rely on video or audio noise. The tests need to be designed such that automata cannot
puzzles, they sometimes cannot be solved by individuals with easily perform the image recognition needed to extract the word or
handicaps. number sequence, but a human user usually can. Designing such tests
is not easy, since ongoing advances in image processing an artificial
intelligence continually raise the bar. Consequently, the
effectiveness of captchas are tied to whether spammers can come up
with or obtain algorithms for automatically solving them. Since
Turing tests rely on video or audio puzzles, they sometimes cannot be
solved by individuals with handicaps.
Like many of the other email techniques, Turing tests are dependent Like many of the other email techniques, Turing tests are dependent
on sender identity, which cannot easily be authenticated in email. on sender identity, which cannot easily be authenticated in email.
Turing tests can be used to prevent IM spam, in much the same way Turing tests can be used to prevent IM spam, in much the same way
they can be used to prevent email spam. Indeed, the presence strong they can be used to prevent email spam. Indeed, the presence strong
authenticated identity techniques in SIP will make such a Turing test authenticated identity techniques in SIP will make such a Turing test
approach more effective in SIP than in email. approach more effective in SIP than in email.
Turing tests can be applied to call spam as well, although not Turing tests can be applied to call spam as well, although not
skipping to change at page 15, line 46 skipping to change at page 16, line 16
of media, such as video and text, and user interfaces by making use of media, such as video and text, and user interfaces by making use
of the SIP application interaction framework [14]. This framework of the SIP application interaction framework [14]. This framework
allows client devices to interact with applications in the network, allows client devices to interact with applications in the network,
where such interaction is done with stimulus signaling, including where such interaction is done with stimulus signaling, including
keypads (supported with the Keypad Markup Language [15]), but also keypads (supported with the Keypad Markup Language [15]), but also
including web browsers, voice recognition, and so on. The framework including web browsers, voice recognition, and so on. The framework
allows the application to determine the media capabilities of the allows the application to determine the media capabilities of the
device (or user, in cases where they are handicapped) and interact device (or user, in cases where they are handicapped) and interact
with them appropriately. with them appropriately.
In the case of voice, there are problems with the Turing test In the case of voice, the Turing test would need to be made to run in
described above. First, it is language specific. The application the language of the caller. This is possible in SIP, using the
could be made to run in different languages, if the caller indicates Accept-Language header field, though this is not widely used at the
their supported languages. This is possible in SIP, using the moment, and meant for languages of SIP message components, not the
Accept-Language header field, but this is not widely used at the media streams.
moment.
The other problem with this Turing test is the same one that email The primary problem with the voice Turing test is the same one that
tests have: instead of having an automata process the test, a spammer email tests have: instead of having an automata process the test, a
can pay cheap workers to take the tests. Assuming cheap labor in a spammer can pay cheap workers to take the tests. Assuming cheap
poor country can be obtained for about 60 cents per hour, and labor in a poor country can be obtained for about 60 cents per hour,
assuming a Turing test of 30 second duration, this is about 50 cents and assuming a Turing test of 30 second duration, this is about 50
per test and thus 50 cents per message to send an IM spam. Lower cents per test and thus 50 cents per message to send an IM spam.
labor rates would reduce this further; the number quoted here is Lower labor rates would reduce this further; the number quoted here
based on real online bids in September of 2006 made for actual work is based on real online bids in September of 2006 made for actual
of this type. work of this type.
As an alternative to paying cheap workers to take the tests, the As an alternative to paying cheap workers to take the tests, the
tests can be taken by human users that are tricked into completing tests can be taken by human users that are tricked into completing
the tests in order to gain access to what they believe is a the tests in order to gain access to what they believe is a
legitimate resource. This was done by a spambot that posted the legitimate resource. This was done by a spambot that posted the
tests on a pornography site, and required users to complete the tests tests on a pornography site, and required users to complete the tests
in order to gain access to content. in order to gain access to content.
Due to these limitations, turing tests may never completely solve the Due to these limitations, Turing tests may never completely solve the
problem. problem.
3.9. Computational Puzzles 3.9. Computational Puzzles
This technique is similar to Turing tests. When user A tries to This technique is similar to Turing tests. When user A tries to
communicate with user B, user B asks user A to perform a computation communicate with user B, user B asks user A to perform a computation
and pass the result back. This computation has to be something a and pass the result back. This computation has to be something a
human user cannot perform and something expensive enough to increase human user cannot perform and something expensive enough to increase
user A's cost to communicate. This cost increase has to be high user A's cost to communicate. This cost increase has to be high
enough to make it prohibitively expensive for spammers but enough to make it prohibitively expensive for spammers but
skipping to change at page 16, line 44 skipping to change at page 17, line 12
One of the problems with the technique is that there is wide One of the problems with the technique is that there is wide
variation in the computational power of the various clients that variation in the computational power of the various clients that
might legitimately communicate. The CPU speed on a low end cell might legitimately communicate. The CPU speed on a low end cell
phone is around 50 MHz, while a high end PC approaches 5 GHz. This phone is around 50 MHz, while a high end PC approaches 5 GHz. This
represents almost two orders of magnitude difference. Thus, if the represents almost two orders of magnitude difference. Thus, if the
test is designed to be reasonable for a cell phone to perform, it is test is designed to be reasonable for a cell phone to perform, it is
two orders of magnitude cheaper to perform for a spammer on a high two orders of magnitude cheaper to perform for a spammer on a high
end machine. Recent research has focused on defining computational end machine. Recent research has focused on defining computational
puzzles that challenge the CPU/memory bandwidth, as opposed to just puzzles that challenge the CPU/memory bandwidth, as opposed to just
the CPU [22]. It seems that there is less variety in the CPU/memory the CPU [23]. It seems that there is less variety in the CPU/memory
bandwidth across devices, roughly a single order of magnitude. bandwidth across devices, roughly a single order of magnitude.
Recent work [24] suggests that, due to the ability of spammers to use Recent work [25] suggests that, due to the ability of spammers to use
virus-infected machines (also known as zombies) to generate the spam, virus-infected machines (also known as zombies) to generate the spam,
the amount of computational power available to the spammers is the amount of computational power available to the spammers is
substantial, and it may be impossible to have them compute a puzzle substantial, and it may be impossible to have them compute a puzzle
that is sufficiently hard that will not also block normal emails. that is sufficiently hard that will not also block normal emails.
However, if combined with white listing, the computational puzzles However, if combined with white listing, the computational puzzles
only become needed for validating new communication partners. The only become needed for validating new communication partners. The
frequency of communications with new partners is arguably higher for frequency of communications with new partners is arguably higher for
email than for multimedia, and thus the computational puzzle email than for multimedia, and thus the computational puzzle
techniques may be more effective for SIP than for email in dealing techniques may be more effective for SIP than for email in dealing
with the introduction problem. with the introduction problem.
These techniques are an active area of research right now, and any These techniques are an active area of research right now, and any
results for email are likely to be usable for SIP. Of course, it is results for email are likely to be usable for SIP.
likely that these techniques will come with a lot of patents and
other intellectual property constraints.
3.10. Payments at Risk 3.10. Payments at Risk
This approach has been proposed for email [23]. When user A sends to This approach has been proposed for email [24]. When user A sends
user B, user A deposits a small amount of money (say, one dollar) email to user B, user A deposits a small amount of money (say, one
into user B's account. If user B decides that the message is not dollar) into user B's account. If user B decides that the message is
spam, user B refunds this money back to user A. If the message is not spam, user B refunds this money back to user A. If the message is
spam, user B keeps the money. This technique requires two spam, user B keeps the money. This technique requires two
transactions to complete: a transfer from A to B, and a transfer from transactions to complete: a transfer from A to B, and a transfer from
B back to A. The first transfer has to occur before the message can B back to A. The first transfer has to occur before the message can
be received in order to avoid reuse of "pending payments" across be received in order to avoid reuse of "pending payments" across
several messages, which would eliminate the utility of the solution. several messages, which would eliminate the utility of the solution.
The second one then needs to occur when the message is found not to The second one then needs to occur when the message is found not to
be spam. be spam.
This technique appears just as applicable to call spam and IM spam as This technique appears just as applicable to call spam and IM spam as
it is to email spam. Like many of the other techniques, this it is to email spam. Like many of the other techniques, this
exchange would only happen the first time you talk to people. Its exchange would only happen the first time you talk to people. Its
proper operation therefore requires a good authenticated identity proper operation therefore requires a good authenticated identity
infrastructure. infrastructure.
This technique has the potential to truly make it prohibitively This technique has the potential to truly make it prohibitively
expensive to send spam of any sort. However, it relies on cheap expensive to send spam of any sort. However, it relies on cheap
micro-payment techniques on the Internet. Traditional costs for micro-payment techniques on the Internet. Traditional costs for
internet payments are around 25 cents per transaction, which would internet payments are around 25 cents per transaction, which would
probably be prohibitive. However, recent providers have been willing probably be prohibitive. However, recent providers have been willing
to charge 15% of the transaction for small transactions, for to charge 15% of the transaction for small transactions, as small as
transactions as small as one cent. This cost would have to be one cent. This cost would have to be shouldered by users of the
shouldered by users of the system. The cost that would need to be system. The cost that would need to be shouldered per user is equal
shouldered per user is equal to the number of messages from unknown to the number of messages from unknown senders (that is, senders not
senders (that is, senders not on the white list) that are received. on the white list) that are received. For a busy user, assume about
For a busy user, assume about 10 new senders per day. If the deposit 10 new senders per day. If the deposit is 5 cents, the transaction
is 5 cents, the transaction provider would take .75 cents and deliver provider would take .75 cents and deliver 4.25 cents. If the sender
4.25 cents. If the sender is allowed, the recipient returns 4.25 is allowed, the recipient returns 4.25 cents, the provider takes 64
cents, the provider takes 64 cents, and returns 3.6 cents. This cents, and returns 3.6 cents. This costs the sender .65 cents on
costs the sender .65 cents on each transaction, if it was legitimate. each transaction, if it was legitimate. If there are ten new
If there are ten new recipients per day, thats US $1.95 per month, recipients per day, thats US $1.95 per month, which is relatively
which is relatively inexpensive. 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, regardless if it is spam. Similarly, a
poor person might not be willing to include money in an email, even
if legitimate, for fear that the recipient might keep it. If the
amount of money is lowered to help handle these problems, it might
become sufficiently small that spammers can just afford to spend it.
3.11. Legal Action 3.11. Legal Action
In this solution, countries pass laws that prohibit spam. These laws In this solution, countries pass laws that prohibit spam. These laws
could apply to IM or call spam just as easily as they could apply to could apply to IM or call spam just as easily as they could apply to
email spam. email spam. There is a lot of debate about whether these laws would
really be effective in preventing spam.
There is a lot of debate about whether these laws would really be
effective in preventing spam. Whether they are or are not effective,
they would appear to be equally effective (or ineffective, as the
case may be) in preventing SIP spam.
As a recent example in the US, "do not call" lists seem to be As a recent example in the US, "do not call" lists seem to be
effective. However, due to the current cost of long distance phone effective. However, due to the current cost of long distance phone
calls, the telemarketing is coming from companies within the US. As calls, the telemarketing is coming from companies within the US. As
such, calls from such telemarketers can be traced. If a telemarketer such, calls from such telemarketers can be traced. If a telemarketer
violates the "do not call" list, the trace allows legal action to be violates the "do not call" list, the trace allows legal action to be
taken against them. A similar "do not irritate" list for VoIP or for 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 email would be less likely to work because the spam is likely to come
from international sources. This problem could be obviated if there from international sources. This problem could be obviated if there
was a strong way to identify the sender's legal entity, and then was a strong way to identify the sender's legal entity, and then
determine whether it was in a jurisdiction where it was practical to determine whether it was in a jurisdiction where it was practical to
take legal action against them. If the spammer is not in such a take legal action against them. If the spammer is not in such a
jurisdiction, the SIP spam could be rejected. jurisdiction, the SIP spam could be rejected.
There are also schemes that cause laws other than anti-spam laws to There are also schemes that cause laws other than anti-spam laws to
be broken if spam is sent. This does not inherently reduce SPAM, but be broken if spam is sent. This does not inherently reduce SPAM, but
it allows more legal options to be brought to bear against the it allows more legal options to be brought to bear against the
spammer. For example, Habeas <http://www.habeas.com> inserts spammer. For example, Habeas <http://www.habeas.com> inserts
material in the header that, if a spammer inserted it without an material in the header that, if it was inserted by a spammer without
appropriate license, allegedly causes the spammer to be violating US an appropriate license, would allegedly causes the spammer to violate
copyright and trademark laws, possibly reciprocal laws, and similar US copyright and trademark laws, possibly reciprocal laws, and
laws in many countries. similar laws in many countries.
3.12. Circles of Trust 3.12. Circles of Trust
In this model, a group of domains (e.g., a set of enterprises) all In this model, a group of domains (e.g., a set of enterprises) all
get together. They agree to exchange SIP calls amongst each other, get together. They agree to exchange SIP calls amongst each other,
and they also agree to introduce a fine should any one of them be and they also agree to introduce a fine should any one of them be
caught spamming. Each company would then enact measures to terminate caught spamming. Each company would then enact measures to terminate
employees who spam from their accounts. employees who spam from their accounts.
This technique relies on secure inter-domain authentication - that This technique relies on secure inter-domain authentication - that
skipping to change at page 19, line 14 skipping to change at page 19, line 35
This kind of technique works well for small domains or small sets of This kind of technique works well for small domains or small sets of
providers, where these policies can be easily enforced. However, it providers, where these policies can be easily enforced. However, it
is unclear how well it scales up. Could a very large domain truly is unclear how well it scales up. Could a very large domain truly
prevent its users from spamming? Would a very large enterprise just prevent its users from spamming? Would a very large enterprise just
pay the fine? How would the pricing be structured to allow both pay the fine? How would the pricing be structured to allow both
small and large domains alike to participate? small and large domains alike to participate?
3.13. Centralized SIP Providers 3.13. Centralized SIP Providers
In this technique, a small number of providers get established as This technique is a variation on the circles of trust described in
"inter-domain SIP providers". These providers act as a SIP- Section 3.12. A small number of providers get established as "inter-
equivalent to the interexchange carriers in the PSTN. Every domain SIP providers". These providers act as a SIP-equivalent to
enterprise, consumer SIP provider or other SIP network (call these the interexchange carriers in the PSTN. Every enterprise, consumer
the local SIP providers) connects to one of these inter-domain SIP provider or other SIP network (call these the local SIP
providers. The local SIP providers only accept SIP messages from providers) connects to one of these inter-domain providers. The
their chosen inter-domain provider. The inter-domain provider local SIP providers only accept SIP messages from their chosen inter-
charges the local provider, per SIP message, for the delivery of SIP domain provider. The inter-domain provider charges the local
messages to other local providers. The local provider can choose to provider, per SIP message, for the delivery of SIP messages to other
pass on this cost to its own customers if it so chooses. 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 The inter-domain SIP providers then form bi-lateral agreements with
each other, exchanging SIP messages according to strict contracts. each other, exchanging SIP messages according to strict contracts.
These contracts require that each of the inter-domain providers be These contracts require that each of the inter-domain providers be
responsible for charging a minimum per-message fee to their own responsible for charging a minimum per-message fee to their own
customers. Extensive auditing procedures can be put into place to customers. Extensive auditing procedures can be put into place to
verify this. Besides such contracts, there may or may not be a flow verify this. Besides such contracts, there may or may not be a flow
of funds between the inter-domain providers. of funds between the inter-domain providers.
The result of such a system is that a fixed cost can be associated The result of such a system is that a fixed cost can be associated
skipping to change at page 19, line 51 skipping to change at page 20, line 25
email, because inter-domain SIP connectivity has not yet been broadly email, because inter-domain SIP connectivity has not yet been broadly
established. In email, there already exists a no-cost form of inter- established. In email, there already exists a no-cost form of inter-
domain connectivity that cannot be eliminated without destroying the domain connectivity that cannot be eliminated without destroying the
utility of email. If, however, SIP inter-domain communications get utility of email. If, however, SIP inter-domain communications get
established from the start using this structure, there is a path to established from the start using this structure, there is a path to
deployment. deployment.
This structure is more or less the same as the one in place for the 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 PSTN today, and since there is relatively little spam on the PSTN
(compared to email!), there is some proof that this kind of (compared to email!), there is some proof that this kind of
arrangement can work. However, it puts back into SIP much of the arrangement can work. However, centralized architectures as these
complexity and monopolistic structures that SIP promised to are deliberately eschewed because they put back into SIP much of the
eliminate. As such, it is a solution that the authors find complexity and monopolistic structures that the protocol aims to
distasteful and contrary to the SIP design and architecture. eliminate.
4. Authenticated Identity in Email 4. Authenticated Identity in Email
Though not a form of anti-spam in and of itself, authenticated or Though not a form of anti-spam in and of itself, authenticated or
verifiable identities are a key part of making other anti-spam verifiable identities are a key part of making other anti-spam
mechanisms work. Many of the techniques described above are most mechanisms work. Many of the techniques described above are most
effective when combined with a white or black list, which itself effective when combined with a white or black list, which itself
requires a strong form of identity. requires a strong form of identity.
In email, two types of authenticated identity have been developed - In email, two types of authenticated identity have been developed -
sender checks and signature-based solutions. sender checks and signature-based solutions.
4.1. Sender Checks 4.1. Sender Checks
In email, DNS resource records have been defined that will allow a 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 domain that receives a message to verify that the sender is a valid
MTA for the sending domain [18] [19] [20] [21]. They don't prevent Message Transfer Agent (MTA) for the sending domain [19] [20] [21]
spam by themselves, but may help in preventing spoofed emails. As [22]. They don't prevent spam by themselves, but may help in
has been mentioned several times, a form of strong authenticated preventing spoofed emails. As has been mentioned several times, a
identity is key in making many other anti-spam techniques work. 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 these techniques useful for SIP? They can be used for SIP but
are not necessary. In email, there are no standards established for are not necessary. In email, there are no standards established for
securely identifying the identity of the sending domain of a message. securely identifying the identity of the sending domain of a message.
In SIP, however, TLS with mutual authentication can be used inter- In SIP, however, TLS with mutual authentication can be used inter-
domain. A provider receiving a message can then reject any message domain. A provider receiving a message can then reject any message
coming from a domain that does not match the asserted identity of the 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" 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 model of SIP, whereby there are only two domains in any call - the
sending domain, which is where the originator resides, and the sending domain, which is where the originator resides, and the
skipping to change at page 20, line 49 skipping to change at page 21, line 27
However, the authenticated identity mechanism for SIP, discussed However, the authenticated identity mechanism for SIP, discussed
below, does work in more complex network configurations and provides below, does work in more complex network configurations and provides
fairly strong assertion of identity. fairly strong assertion of identity.
4.2. Signature-Based Techniques 4.2. Signature-Based Techniques
Domain Keys Identified Mail (DKIM) [16] (and several non-standard Domain Keys Identified Mail (DKIM) [16] (and several non-standard
techniques that preceded it) provide stronger identity assertions by techniques that preceded it) provide stronger identity assertions by
allowing the sending domain to sign an email, and then providing allowing the sending domain to sign an email, and then providing
mechanisms by which the receiving MTA or MUA can validate the mechanisms by which the receiving MTA or Mail User Agent (MUA) can
signature. validate the signature.
Unfortunately, when used with blacklists, this kind of authenticated Unfortunately, when used with blacklists, this kind of authenticated
identity is only as useful as the fraction of the emails which identity is only as useful as the fraction of the emails which
utilize it. This is partly true for whitelists as well; if any utilize it. This is partly true for whitelists as well; if any
unauthenticated email is accepted for an address on a white list, a unauthenticated email is accepted for an address on a white list, a
spammer can spoof that address. However a white list can be spammer can spoof that address. However a white list can be
effective with limited deployment of DKIM if all of the people on the effective with limited deployment of DKIM if all of the people on the
white list are those whose domains are utilizing the mechanism. white list are those whose domains are utilizing the mechanism.
This kind of identity mechanism is also applicable to SIP, and is in This kind of identity mechanism is also applicable to SIP, and is in
fact exactly what is defined by SIP's authenticated identity fact exactly what is defined by SIP's authenticated identity
mechanism [17] mechanism [18]
5. Authenticated Identity in SIP 5. Authenticated Identity in SIP
One of the key parts of many of the solutions described above is the One of the key parts of many of the solutions described above is the
ability to securely identify the identity of a sender of a SIP ability to securely identify the identity of a sender of a SIP
message. SIP provides a secure solution for this problem, and it is message. SIP provides a secure solution for this problem, and it is
important to discuss it here. important to discuss it here.
The solution starts by having each domain authenticate its own users. The solution starts by having each domain authenticate its own users.
SIP provides HTTP digest authentication as part of the core SIP SIP provides HTTP digest authentication as part of the core SIP
skipping to change at page 21, line 41 skipping to change at page 22, line 18
client verifies the server identity using TLS, and then authenticates client verifies the server identity using TLS, and then authenticates
itself to the server using a digest exchange over TLS. This itself to the server using a digest exchange over TLS. This
technique, which is also documented in RFC 3261, is very secure but technique, which is also documented in RFC 3261, is very secure but
not widely deployed yet. In the long term, this approach will be not widely deployed yet. In the long term, this approach will be
necessary for the security properties needed to prevent SIP spam. necessary for the security properties needed to prevent SIP spam.
Once a domain has authenticated the identity of a user, when it Once a domain has authenticated the identity of a user, when it
relays a message from that user to another domain, the sending domain relays a message from that user to another domain, the sending domain
can assert the identity of the sender, and include a signature to can assert the identity of the sender, and include a signature to
validate that assertion. This is done using the SIP identity validate that assertion. This is done using the SIP identity
mechanism [17]. mechanism [18].
A weaker form of identity assertion is possible using the P-Asserted- A weaker form of identity assertion is possible using the P-Asserted-
Identity header field [5], but this technique requires mutual trust Identity header field [5], but this technique requires mutual trust
among all domains. Unfortunately, this becomes exponentially harder among all domains. Unfortunately, this becomes exponentially harder
to provide as the number of interconnected domains grows. As that to provide as the number of interconnected domains grows. As that
happens, the value of the identity assertion becomes equal to the happens, the value of the identity assertion becomes equal to the
trustworthiness of the least trustworthy domain. Since spam is a trustworthiness of the least trustworthy domain. Since spam is a
consequence of untrusted domains and users that get connected to the consequence of untrusted domains and users that get connected to the
network, the P-Asserted-Identity technique becomes ineffective at network, the P-Asserted-Identity technique becomes ineffective at
exactly the same levels of interconnectness that introduce spam. exactly the same levels of interconnectness that introduce spam.
Consider the following example to help illustrate this fact. A Consider the following example to help illustrate this fact. A
malicious domain, let us call them spammers.com, would like to send malicious domain, let us call them spam.example.com, would like to
SIP INVITE requests with false P-Asserted-Identity, indicating users send SIP INVITE requests with false P-Asserted-Identity, indicating
outside of its own domain. Spammers.com finds a regional SIP users outside of its own domain. spam.example.com finds a regional
provider in a small country who, due to its small size and SIP provider in a small country who, due to its small size and
disinterest in spam, accepts any P-Asserted-Identity from its disinterest in spam, accepts any P-Asserted-Identity from its
customers without verification. This provider, in turn, connects to customers without verification. This provider, in turn, connects to
a larger, interconnect provider. They do ask each of their customers a larger, interconnect provider. They do ask each of their customers
to verify P-Asserted-Identity but have no easy way of enforcing it. to verify P-Asserted-Identity but have no easy way of enforcing it.
This provider, in turn, connects to everyone else. As a consequence, This provider, in turn, connects to everyone else. As a consequence,
the spammers.com domain is able to inject calls with a spoofed called the spam.example.com domain is able to inject calls with a spoofed
ID. This request can be directed to any recipient reachable through called ID. This request can be directed to any recipient reachable
the network (presumably everyone due to the large size of the root through the network (presumably everyone due to the large size of the
provider). There is no way for a recipient to know that this root provider). There is no way for a recipient to know that this
particular P-Asserted-Identity came from this bad spammers.com particular P-Asserted-Identity came from this bad spam.example.com
domain. As the example shows, even though the central provider's domain. As the example shows, even though the central provider's
policy is good, the overall effectiveness of P-Asserted-Identity is 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. 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 SIP also defines the usage of TLS between domains, using mutual
authentication, as part of the base specification. This technique authentication, as part of the base specification. This technique
provides a way for one domain to securely determine that it is provides a way for one domain to securely determine that it is
talking to a server that is a valid representative of another domain. talking to a server that is a valid representative of another domain.
6. Framework for Anti-Spam in SIP 6. Framework for Anti-Spam in SIP
Unfortunately, there is no magic bullet for preventing SIP spam, just Unfortunately, there is no magic bullet for preventing SIP spam, just
as there is none for email spam. However, the combination of several as there is none for email spam. However, the combination of several
techniques can provide a framework for dealing with spam in SIP. techniques can provide a framework for dealing with spam in SIP.
This section provides recommendations for network designers in order This section provides recommendations for network designers in order
to help mitigate the risk of spam. to help mitigate the risk of spam.
There are three core recommendations that can be made. There are four core recommendations that can be made:
Firstly, in almost all of the solutions discussed above, there is a Strong Identity: Firstly, in almost all of the solutions discussed
dependency on the ability to authenticate the sender of a SIP message above, there is a dependency on the ability to authenticate the
inter-domain. Consent, reputation systems, computational puzzles, sender of a SIP message inter-domain. Consent, reputation
and payments at risk, amongst others, all work best when applied only systems, computational puzzles, and payments at risk, amongst
to new requests, and successful completion of an introduction results others, all work best when applied only to new requests, and
in the placement of a user on a white list. However, usage of white successful completion of an introduction results in the placement
lists depends on strong identity assertions. Consequently, any of a user on a white list. However, usage of white lists depends
network that interconnects with others should make use of strong SIP on strong identity assertions. Consequently, any network that
identity as described in RFC 4474. P-Asserted-Identity is not strong interconnects with others should make use of strong SIP identity
as described in RFC 4474. P-Asserted-Identity is not strong
enough. enough.
Secondly, with a strong identity system in place, networks are White Lists: Secondly, with a strong identity system in place,
recommended to make use of white lists. These are ideally built off networks are recommended to make use of white lists. These are
of the existing buddy lists if present. If not, separate white lists ideally built off of the existing buddy lists if present. If not,
can be managed for spam. Placement on these lists can be manual or separate white lists can be managed for spam. Placement on these
based on the successful completion of one or more introduction lists can be manual or based on the successful completion of one
mechanisms. or more introduction mechanisms.
This in turn leads to the final recommendation to be made. Network Solve the Introduction Problem: This in turn leads to the final
designers should make use of one or more mechanisms meant to solve recommendation to be made. Network designers should make use of
the introduction problem. Indeed, it is possible to use more than one or more mechanisms meant to solve the introduction problem.
one and combine the results through some kind of weight. A user that Indeed, it is possible to use more than one and combine the
successfully completes the introduction mechanism can be results through some kind of weight. A user that successfully
automatically added to the white list. Of course, that can only be completes the introduction mechanism can be automatically added to
done usefully if their identity is verified by RFC 4474. The set of the white list. Of course, that can only be done usefully if
mechanisms for solving the introduction problem, as described in this their identity is verified by RFC 4474. The set of mechanisms for
document, are based on some (but not all) of the techniques known and solving the introduction problem, as described in this document,
used at the time of writing. Providers of SIP services should keep are based on some (but not all) of the techniques known and used
at the time of writing. Providers of SIP services should keep
tabs on solutions in email as they evolve, and utilize the best of tabs on solutions in email as they evolve, and utilize the best of
what those techniques have to offer. what those techniques have to offer.
But perhaps most importantly, providers should not ignore the spam Don't Wait Until its Too Late: But perhaps most importantly,
problem until it happens! That is the pitfall email fell into. As providers should not ignore the spam problem until it happens!
soon as a provider inter-connects with other providers, or allows SIP That is the pitfall email fell into. As soon as a provider inter-
messages from the open Internet, that provider must consider how they connects with other providers, or allows SIP messages from the
will deal with spam. open Internet, that provider must consider how they will deal with
spam.
7. Additional Work 7. Additional Work
Though the above framework serves as a good foundation on which to Though the above framework serves as a good foundation on which to
deal with spam in SIP, there are gaps, some of which can be addressed deal with spam in SIP, there are gaps, some of which can be addressed
by additional work that has yet to be undertaken. by additional work that has yet to be undertaken.
One of the difficulties with the strong identity techniques is that a One of the difficulties with the strong identity techniques is that a
receiver of a SIP request without an authenticated identity cannot receiver of a SIP request without an authenticated identity cannot
know whether the request lacked such an identity because the know whether the request lacked such an identity because the
originating domain didn't support it, or because a man-in-the-middle originating domain didn't support it, or because a man-in-the-middle
removed it. As a result, transition mechanisms should be put in removed it. As a result, transition mechanisms should be put in
place to allow these to be differentiated. Without it, the value of place to allow these to be differentiated. Without it, the value of
the identity mechanism is much reduced. the identity mechanism is much reduced.
8. Security Considerations 8. Security Considerations
This memo is entirely devoted to issues relating to secure usage of This memo is entirely devoted to issues relating to secure usage of
SIP services on the Internet. SIP services on the Internet.
9. Acknowledgements 9. IANA Considerations
There are no IANA considerations associated with this specification.
10. Acknowledgements
The authors would like to thank Rohan Mahy for providing information The authors would like to thank Rohan Mahy for providing information
on Habeas, Baruch Sterman for providing costs on VoIP termination on Habeas, Baruch Sterman for providing costs on VoIP termination
services, and Gonzalo Camarillo for his review. Useful comments and services, and Gonzalo Camarillo and Vijay Gurbani for their reviews.
feedback were provided by Nils Ohlmeir, Tony Finch, Randy Gellens and Useful comments and feedback were provided by Nils Ohlmeir, Tony
Yakov Shafranovich. Jon Peterson wrote some of the text in this Finch, Randy Gellens and Yakov Shafranovich. Jon Peterson wrote some
document and has contributed to the work as it has moved along. of the text in this document and has contributed to the work as it
has moved along.
10. Informative References 11. Informative References
[1] Campbell, B., "The Message Session Relay Protocol", [1] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-15 (work in progress), draft-ietf-simple-message-sessions-18 (work in progress),
July 2006. December 2006.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002. Instant Messaging", RFC 3428, December 2002.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
skipping to change at page 24, line 48 skipping to change at page 25, line 38
[8] Rosenberg, J., "An Extensible Markup Language (XML) Based [8] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information", RFC 3858, August 2004. Format for Watcher Information", RFC 3858, August 2004.
[9] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource [9] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004. Application (ENUM)", RFC 3761, April 2004.
[10] Rosenberg, J., "The Extensible Markup Language (XML) [10] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-11 (work in progress), May 2006. draft-ietf-simple-xcap-12 (work in progress), October 2006.
[11] Rosenberg, J., "Presence Authorization Rules", [11] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-07 (work in progress), draft-ietf-simple-presence-rules-08 (work in progress),
June 2006. October 2006.
[12] Rosenberg, J., "A Framework for Consent-Based Communications in [12] Rosenberg, J., "A Framework for Consent-Based Communications in
the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sip-consent-framework-00 (work in progress), draft-ietf-sip-consent-framework-01 (work in progress),
September 2006. November 2006.
[13] Camarillo, G., "A Document Format for Requesting Consent", [13] Camarillo, G., "A Document Format for Requesting Consent",
draft-ietf-sipping-consent-format-00 (work in progress), draft-ietf-sipping-consent-format-01 (work in progress),
September 2006. November 2006.
[14] Rosenberg, J., "A Framework for Application Interaction in the [14] Rosenberg, J., "A Framework for Application Interaction in the
Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)",
draft-ietf-sipping-app-interaction-framework-05 (work in draft-ietf-sipping-app-interaction-framework-05 (work in
progress), July 2005. progress), July 2005.
[15] Dolly, M. and E. Burger, "A Session Initiation Protocol (SIP) [15] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP)
Event Package for Key Press Stimulus (KPML)", Event Package for Key Press Stimulus (KPML)", RFC 4730,
draft-ietf-sipping-kpml-08 (work in progress), July 2006. November 2006.
[16] Hansen, T., "DomainKeys Identified Mail (DKIM) Service [16] Hansen, T., "DomainKeys Identified Mail (DKIM) Service
Overview", draft-ietf-dkim-overview-01 (work in progress), Overview", draft-ietf-dkim-overview-03 (work in progress),
June 2006. October 2006.
[17] Peterson, J. and C. Jennings, "Enhancements for Authenticated [17] Rosenberg, J., "Applying Loose Routing to Session Initiation
Protocol (SIP) User Agents (UA)",
draft-rosenberg-sip-ua-loose-route-00 (work in progress),
October 2006.
[18] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006. RFC 4474, August 2006.
[18] Allman, E. and H. Katz, "SMTP Service Extension for Indicating [19] Allman, E. and H. Katz, "SMTP Service Extension for Indicating
the Responsible Submitter of an E-Mail Message", RFC 4405, the Responsible Submitter of an E-Mail Message", RFC 4405,
April 2006. April 2006.
[19] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", [20] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006. RFC 4406, April 2006.
[20] Lyon, J., "Purported Responsible Address in E-Mail Messages", [21] Lyon, J., "Purported Responsible Address in E-Mail Messages",
RFC 4407, April 2006. RFC 4407, April 2006.
[21] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for [22] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for
Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, Authorizing Use of Domains in E-Mail, Version 1", RFC 4408,
April 2006. April 2006.
[22] Abadi, M., Burrows, M., Manasse, M., and T. Wobber, "Moderately [23] Abadi, M., Burrows, M., Manasse, M., and T. Wobber, "Moderately
Hard, Memory Bound Functions, NDSS 2003", February 2003. Hard, Memory Bound Functions, NDSS 2003", February 2003.
[23] Abadi, M., Burrows, M., Birrell, A., Dabek, F., and T. Wobber, [24] Abadi, M., Burrows, M., Birrell, A., Dabek, F., and T. Wobber,
"Bankable Postage for Network Services, Proceedings of the 8th "Bankable Postage for Network Services, Proceedings of the 8th
Asian Computing Science Conference, Mumbai, India", Asian Computing Science Conference, Mumbai, India",
December 2003. December 2003.
[24] Clayton, R. and B. Laurie, "Proof of Work Proves not to Work, [25] Clayton, R. and B. Laurie, "Proof of Work Proves not to Work,
Third Annual Workshop on Economics and Information Security", Third Annual Workshop on Economics and Information Security",
May 2004. May 2004.
[25] Rosenberg, J., "User Agent Loose Routing in the Session
Initiation Protocol (SIP)",
draft-rosenberg-sip-ua-loose-route-00 (work in progress),
October 2006.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
Cisco Cisco
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
skipping to change at page 28, line 5 skipping to change at page 28, line 5
Cullen Jennings Cullen Jennings
Cisco Cisco
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
US US
Phone: +1 408 527-9132 Phone: +1 408 527-9132
Email: fluffy@cisco.com Email: fluffy@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 28, line 29 skipping to change at page 28, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 70 change blocks. 
246 lines changed or deleted 277 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/