<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-york-sipping-spit-similarity-scenarios-01" ipr="full3978">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title>SIP Usage Scenarios Similar to SPIT</title>
<author fullname="Dan York" initials="D.Y." surname="York">
<organization abbrev="Voxeo">Voxeo Corporation</organization>
<address>
<postal>
<street></street>
<city>Keene</city>
<region>NH</region>
<code></code>
<country>USA</country>
</postal>
<phone>+1-407-455-5859</phone>
<email>dyork@voxeo.com</email>
<uri>http://www.voxeo.com/</uri>
</address>
</author>
<date month="July" year="2008" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>SIPPING</workgroup>
<keyword>spit, sip, spam</keyword>
<abstract>
<t>This document outlines scenarios in which legitimate SIP traffic
may appear similar to traffic associated with voice spam, also known as
"SPIT" or "Spam for Internet Telephony. This document is created to
provide input into the current discussions about how best to address
the issue of SPIT.</t>
</abstract>
</front>
<middle>
<section anchor="AuthorsNote" title="Author's Note">
<t>After review in the RUCUS mailing list, it was determined that
this document should be folded into a larger document, most likely
either the existing RUCUS problem statement or another yet-to-be-created
document on a reference scenario. Given that direction by the
mailing list, this will most likely be the final submission of this
document as a standalone document.</t>
<t>While this document may be folded into a larger document in the
future, comments and feedback are definitely welcome.</t>
</section>
<section title="Introduction">
<t>If the administrator of a VoIP network suddenly noticed 10,000
outbound SIP INVITE messages traversing the network in the space of
a minute or two, could this be a spammer generating voice spam on
the network? Or could this be the legitimate triggering of an
emergency notification system?</t>
<t>As outlined in the recently published RFC 5039 <xref
target="RFC5039"/>, communication using the Session Iniatiation Protocol
(SIP) could be a target for a form of spam commonly known as either
"voice spam", "Spam for Internet Telephony" or simply "SPIT".
Essentially, SPIT is the transmission of bulk unsolicited messages
via SIP. It is telemarketing brought to the world of IP where the
traditional costs and delays associated with telemarketing in the
PSTN world are removed. Telemarketers can now very rapidly and
inexpensively send out a very high volume of calls, which we might
see as "spam". For reasons outlined in RFC 5039, SPIT attacks are
not yet widely seen, but can
be expected as further interconnections occur between SIP systems.</t>
<t>RFC 5039 and related Internet Drafts (<xref
target="I-D.tschofenig-sipping-framework-spit-reduction"/> and
<xref target="I-D.niccolini-sipping-spitstop"/>) outline the
potential threat of SPIT and also lay out suggestions for possible
solutions. Beyond the potential solutions offered thus far, it is
very conceivable that traditional network security vendors will
seek to use existing tools to combat SPIT at a network traffic
level. For instance, a system designed to monitor network traffic
and trigger alerts based on anomolies seen in network traffic could
be modified to look for anomolies in the base rate of SIP traffic.</t>
<t>The purpose of this document is to provide input into the
ongoing discussions around preventing SPIT that highlights the fact that
there are cases where legitimate SIP traffic may in fact look like SPIT.
If the administrator of a VoIP network suddenly noticed 10,000
outbound SIP INVITE messages traversing the network in the space of a
minute or two, this could be SPIT being generated by a system
connected to that VoIP network - or it could be an emergency
notification system.</t>
<t> Solutions to the potential problem of SPIT do
need to take into account that some legitimate uses of SIP
communication might resemble the launch of a SPIT session or indeed
might resemble a Denial of Service (DoS) attack. This document
outlines some of those scenarios.</t>
<t>It should be noted that most of the solutions suggested thus far
within the IETF to address the issue of SPIT do not use behaviorial
techniques that may run into the issues addressed in this draft.
However, as noted earlier, it is to be expected that other
solutions will be put forward by vendors, some of which may use
techniques that do not work well with the scenarios listed here. It
is primarily for those solutions that this draft is aimed.</t>
<t>It should also be noted that the concern addressed in this document is
for the spammer who may generate a large amount of SIP traffic in a
short period of time and thus potentially come to the attention of
network monitoring tools.
This may be the case, for instance, when a spammer connects to
another party's network (for instance, one using unprotected WiFi) and
wants to send out the most messages in the least amount of time. A
spammer may also simply be trying to send the messages out as fast
as possible for one client in order to move on to other
clients.</t><t>Obviously a spammer could simply slow down the rate
of sending SIP messages to evade this type of detection. In that
case the SPIT traffic would resemble normal SIP traffic and be
subject to the concerns and potential solutions suggested in RFC
5039 and other Internet-Drafts.</t>
<t>NOTE: Reflecting the fact that SIP can be used for far more
than voice, RFC 5039 discusses call spam, IM spam and presence
spam. This document, however, primarily focuses on call spam.</t>
</section>
<section anchor="outbound" title="Outbound SIP Scenarios">
<t>Given the ease with which SIP systems can be connected to existing
applications such as databases, creating a system to do large scale
initiation of SIP messages is easy to do and both commercial and open
source implementations of such functionality exist today.</t>
<t>Any system that generated a large amount of outbound SIP traffic
might potentially be viewed as a generator of SPIT. This section
breaks down those systems into several categories.</t>
<section anchor="outbound-emergency" title="Emergency Notification
Systems">
<t>In the wake of recent school shootings in the USA,
particularly the April 2007 event at Virginia Tech, academic
institutions at all levels are seeking technical solutions
which will allow them to do "emergency notification" on a
massive scale. Such systems can be triggered by school
administrators or potentially public safety officials and
immediately begin notifying students, faculty and now even
parents. Notification may take the form of phone calls, text
messages (SMS), IM messages or all of the above.</t>
<t>Were such a system to be SIP-based, the triggering of the
system might result in the immediate flow of:<list
style="symbols">
<t>SIP INVITE messages to phones, conceivably to every known
SIP endpoint on the campus</t>
<t>SIP messages to PSTN gateways to initiate outbound calls
to regular phones</t>
<t>SIP messages to SMS gateways to initiate outbound text
messages</t>
<t>SIP messages to IM networks</t>
</list>If a university were to have, for instance, 10,000
students and several thousand more staff and faculty, an
extremely large number of SIP messages would be sent in a very
short time.</t>
<t>It is important to note that in the case of an emergency
notification system, messages are typically extremely
time-sensitive and are looking for immediate delivery. There
also may be health, legal or at least public relations
ramifications if the messages are blocked from delivery. There
will also typically be no notification of the triggering of
such a system and, hopefully, the system will almost never be
used. To the unaware system administrator just routinely monitoring
network traffic, this would be an extremely surprising event.</t>
<t>Beyond usage in educational settings, emergency notification
systems like this are also be established in a variety of other
situations such as government alerts about impending weather
or natural events (ex. tornados, fires).</t>
</section>
<section anchor="outbound-urgent" title="Urgent Notification Systems">
<t>While not rising to the same level of criticality as
"emergency" systems, there are other "urgent" notification
systems that follow a similar profile. Examples include:<list
style="symbols">
<t>Airline systems notifying travelers of delayed or
cancelled flights</t>
<t>School systems notifying families of school delays or
cancellations</t>
<t>Stock price change notifications</t>
</list>Again, the notification system may trigger on an
infrequent basis or go through seasonal cycles and may involve
a large number of calls. In some situations, such as a school
notification, the number of calls may be close to the same in each
event. For example, the number of student families to notify may
fluctuate slightly but typically not by much. In other
situations the number of calls may vary widely. For example,
the number of calls to be made by an airline notification
system may depend upon how many people are traveling and how
many of those travelers provided contact information or
requested to be notified.. </t>
</section>
<section anchor="outbound-event" title="Event-Driven Notification Systems">
<t>In a similar fashion to the previous scenarios, it is quite
conceivable that automated systems will be used by a wide
variety of organizations to alert people to impending events.
For instance, a professional sports team might use a system to
alert all the members of a fan club about an upcoming game. A
business group might remind all of its members about an
upcoming conference. A political campaign might call a list
reminding people to go out and vote. The list of potential
users of such a system could be quite lengthy. Some examples
might be:<list style="symbols">
<t>Professional sports teams</t>
<t>School events</t>
<t>Local theatres</t>
<t>Business groups</t>
<t>Town/city governments/associations</t>
<t>Political campaigns</t>
</list>The key element here is that the calls might happen
on an infrequent basis. There might be a large number of
calls made in a short period of time - and once the event
is over there are no more calls made by that entity until
the next similar event.</t>
</section>
<section anchor="outbound-routine" title="Routine Notification Systems">
<t>While the previous scenarios have outlined situations where
a large amount of traffic was generated with no warning, there
also exist a class of scenarios where a large amount of traffic
might be generated on a regular interval. For instance, some
school systems in the USA are starting to use notification
systems to alert parents to events that have occurred that day
or will be occurring. They might receive a phone call each day stating
what homework their child had and/or informing them of a school
meeting occuring later in the week. With a large school district,
the automated notification system might initiate thousands of calls
every day at, for example, 3pm.</t>
<t>Similarly, a movie theater might call every subscriber in a
special promotional club on every Thursday afternoon to let
them know what movies might be premiering during the upcoming
weekend.</t>
<t>Again, there are a large number of potential users of such a
system. The key difference in this scenario is that the
traffic may occur at a regular time and period. Security
systems that monitor network traffic might flag these
notification systems as potential sources of SPIT but conceivably
those systems could be configured in such a way that this
notification traffic is incorporated into a network
"baseline" as known and expected traffic.</t>
</section>
</section>
<section anchor="inbound" title="Inbound SIP Scenarios">
<t>In a similar fashion to outbound SIP scenarios, it is possible
that sufficient legitimate inbound traffic to a SIP system/network might cause
administrators or automated systems to believe they are receiving a
large amount of voice spam/SPIT. For instance, if a system were on
the receiving end of an emergency notification system (ex. an
IP-PBX operated by a department within a university) a high level
of SIP INVITE messages would be received that might go to all
extensions on the system.</t> <t>Similarly, the system/network might be
receiving calls due to a contest or other event (ex. an "American
Idol"-type of show where people call in and vote or a radio station
contest). Note, though, that in this situation the calls might be
coming in from a range of different endpoints and could also
resemble a Denial of Service (DoS) or Distributed Denial of Service
(DDos) attack.</t>
<t>The primary difference from outbound scenarios is that with the
inbound scenario the destination of all the traffic would typically
be the SIP proxy/gateway for a given network. Again, this may make
differentiation between legitimate traffic and SPIT - or a DoS or
DDoS - difficult.</t>
<section anchor="inbound-expected" title="">
<t>Similar to the Event-Driven outbound systems, there may be
legitimate inbound calling due to specific *known* events. Examples
include:<list style="symbols">
<t>"American Idol"-style TV shows</t>
<t>Radio station listener contests, ticket giveaways, etc.</t>
<t>Interview shows (Ex. "Call now to ask your mayor
questions about the school budget.")</t>
<t>Advertising (Ex. "Call in the next 5 minutes to obtain
your copy of ____ for only $19.95!")</t>
</list>The major distinction here is that at some point it
is known that this traffic will be generated, in comparison to the
section below. For instance, the time when callers may be calling in
to vote in the TV show will be known in advance. (Whether or not all
systems in the path of the call will be alerted to this is a separate
matter.)</t>
</section>
<section anchor="inbound-unexpected" title="">
<t>Unexpected events such as those that might cause a significant
amount of outbound calling (as outlined in the Emergency Notification
Systems earlier) may also create a significant amount of *inbound*
calling. Such events include, but are certainly not limited to, such
things as:<list style="symbols">
<t>Natural disasters</t>
<t>School shootings</t>
<t>Large traffic accidents</t>
<t>Bombings</t>
</list>Again the issue here is that these events are
entirely unexpected and therefore the traffic entering a SIP network
could very easily be viewed as a Distributed Denial-of-Service attack.</t>
</section>
</section>
<section anchor="networkfailures" title="Network Failures">
<t>Another scenario to consider is the case where excessive amounts of SIP
traffic are not the result of exceptional amounts of inbound or outbound
calling but rather a failure in the actual network infrastructure. For
instance, consider the case where there is a wide area network with
multiple SIP-to-PSTN gateways and a large distributed infrastructure. An
outage at specific points in the network might result in all the traffic
for the larger network being routed through a single SIP signaling node.
To the administrators of that node, the sudden influx of additional
traffic might cause concern of a DoS or SPIT attack. One might hope that the
administrators would also be able to easily ascertain the network status
and understand why they are receiving this traffic, but that might not be
possible in all network configurations.</t>
</section>
<section anchor="Considerations" title="Other Considerations">
<t>One logical reaction to these scenarios might be to suggest that
the legitimate senders simply reduce their send rate to be below
any timing thresholds that might trigger automated systems. For
instance, if a system needing to contact 10,000 endpoints were to
send one SIP INVITE every half-second, the INVITEs would then all
go out over the space of a bit under 1.5 hours. For some
systems, such the "Routine Notification Systems" identified
earlier, spacing out the INVITE messages might be fine and in fact
might actually be required in order for the media servers to keep
with streaming the outbound media to all the invited endpoints.
However, in other situations, such as emergency notification
systems, some spacing out of INVITE messages may be possible but at
some threshold any further delays may be unacceptable and indeed in
some cases could be life-threatening.</t>
</section>
<section anchor="Summary" title="Summary">
<t>Voice spam, also known as "SPIT", has the potential to be a
serious problem if we move to a space where we have interconnected
systems where any SIP endpoint can call any other SIP endpoint -
and we do not have any mechanisms in place to prevent abuse of the
system to generate large volumes of unsolicited calls. Solutions
are being discussed and such work needs to be continued.</t>
<t>In looking at potential solutions, it is important to
recognize that there are legitimate cases where SIP systems may
generate large volumes of calls in a rapid timeframe. Any
solutions to addressing the problem of SPIT do need to take into
account these legitimate scenarios.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The author is grateful for the work done by the SPITSTOP
mailing list and the authors of the associated drafts as well as the
authors of RFC 5039. The author thanks Dan Burnett for feedback on an
initial version of this document.</t>
<t>Comments were appreciated on the initial draft from Dan Wing,
Hannes Tschofenig, Brian Rosen, Harsha Ramanagoudra, Raphael Tryster and
others.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document relates entirely to security considerations for
potential voice spam.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-niccolini-sipping-spitstop-00.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-tschofenig-sipping-framework-spit-reduction-02.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5039.xml"?>
</references>
</back>
</rfc>
