Internet DRAFT - draft-york-sipping-spit-similarity-scenarios
draft-york-sipping-spit-similarity-scenarios
SIPPING D. York
Internet-Draft Voxeo
Intended status: Informational July 14, 2008
Expires: January 15, 2009
SIP Usage Scenarios Similar to SPIT
draft-york-sipping-spit-similarity-scenarios-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
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.
York Expires January 15, 2009 [Page 1]
Internet-Draft SIP Usage Scenarios Similar to SPIT July 2008
Table of Contents
1. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Outbound SIP Scenarios . . . . . . . . . . . . . . . . . . . . 4
3.1. Emergency Notification Systems . . . . . . . . . . . . . . 5
3.2. Urgent Notification Systems . . . . . . . . . . . . . . . 6
3.3. Event-Driven Notification Systems . . . . . . . . . . . . 6
3.4. Routine Notification Systems . . . . . . . . . . . . . . . 7
4. Inbound SIP Scenarios . . . . . . . . . . . . . . . . . . . . 7
4.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Network Failures . . . . . . . . . . . . . . . . . . . . . . . 9
6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Informative References . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
York Expires January 15, 2009 [Page 2]
Internet-Draft SIP Usage Scenarios Similar to SPIT July 2008
1. Author's Note
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.
While this document may be folded into a larger document in the
future, comments and feedback are definitely welcome.
2. Introduction
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?
As outlined in the recently published RFC 5039 [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.
RFC 5039 and related Internet Drafts
([I-D.tschofenig-sipping-framework-spit-reduction] and
[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.
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
York Expires January 15, 2009 [Page 3]
Internet-Draft SIP Usage Scenarios Similar to SPIT July 2008
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.
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.
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.
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.
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.
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.
3. Outbound SIP Scenarios
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.
York Expires January 15, 2009 [Page 4]
Internet-Draft SIP Usage Scenarios Similar to SPIT July 2008
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.
3.1. Emergency Notification Systems
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.
Were such a system to be SIP-based, the triggering of the system
might result in the immediate flow of:
o SIP INVITE messages to phones, conceivably to every known SIP
endpoint on the campus
o SIP messages to PSTN gateways to initiate outbound calls to
regular phones
o SIP messages to SMS gateways to initiate outbound text messages
o SIP messages to IM networks
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.
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.
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).
York Expires January 15, 2009 [Page 5]
Internet-Draft SIP Usage Scenarios Similar to SPIT July 2008
3.2. Urgent Notification Systems
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:
o Airline systems notifying travelers of delayed or cancelled
flights
o School systems notifying families of school delays or
cancellations
o Stock price change notifications
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..
3.3. Event-Driven Notification Systems
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:
o Professional sports teams
o School events
o Local theatres
o Business groups
o Town/city governments/associations
York Expires January 15, 2009 [Page 6]
Internet-Draft SIP Usage Scenarios Similar to SPIT July 2008
o Political campaigns
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.
3.4. Routine Notification Systems
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.
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.
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.
4. Inbound SIP Scenarios
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.
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
York Expires January 15, 2009 [Page 7]
Internet-Draft SIP Usage Scenarios Similar to SPIT July 2008
different endpoints and could also resemble a Denial of Service (DoS)
or Distributed Denial of Service (DDos) attack.
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.
4.1.
Similar to the Event-Driven outbound systems, there may be legitimate
inbound calling due to specific *known* events. Examples include:
o "American Idol"-style TV shows
o Radio station listener contests, ticket giveaways, etc.
o Interview shows (Ex. "Call now to ask your mayor questions about
the school budget.")
o Advertising (Ex. "Call in the next 5 minutes to obtain your copy
of ____ for only $19.95!")
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.)
4.2.
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:
o Natural disasters
o School shootings
o Large traffic accidents
o Bombings
Again the issue here is that these events are entirely unexpected and
therefore the traffic entering a SIP network could very easily be
York Expires January 15, 2009 [Page 8]
Internet-Draft SIP Usage Scenarios Similar to SPIT July 2008
viewed as a Distributed Denial-of-Service attack.
5. Network Failures
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.
6. Other Considerations
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.
7. Summary
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.
In looking at potential solutions, it is important to recognize that
York Expires January 15, 2009 [Page 9]
Internet-Draft SIP Usage Scenarios Similar to SPIT July 2008
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.
8. Acknowledgements
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.
Comments were appreciated on the initial draft from Dan Wing, Hannes
Tschofenig, Brian Rosen, Harsha Ramanagoudra, Raphael Tryster and
others.
9. IANA Considerations
This memo includes no request to IANA.
10. Security Considerations
This document relates entirely to security considerations for
potential voice spam.
11. Informative References
[I-D.niccolini-sipping-spitstop]
Niccolini, S. and J. Quittek, "Signaling TO Prevent SPIT
(SPITSTOP) Reference Scenario",
draft-niccolini-sipping-spitstop-00 (work in progress),
January 2007.
[I-D.tschofenig-sipping-framework-spit-reduction]
Tschofenig, H., Schulzrinne, H., Wing, D., Rosenberg, J.,
and D. Schwartz, "A Framework to tackle Spam and Unwanted
Communication for Internet Telephony",
draft-tschofenig-sipping-framework-spit-reduction-02 (work
in progress), November 2007.
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, January 2008.
York Expires January 15, 2009 [Page 10]
Internet-Draft SIP Usage Scenarios Similar to SPIT July 2008
Author's Address
Dan York
Voxeo Corporation
Keene, NH
USA
Phone: +1-407-455-5859
Email: dyork@voxeo.com
URI: http://www.voxeo.com/
York Expires January 15, 2009 [Page 11]
Internet-Draft SIP Usage Scenarios Similar to SPIT July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
York Expires January 15, 2009 [Page 12]
