| TOC |
|
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 16, 2009.
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.
1.
Author's Note
2.
Introduction
3.
Outbound SIP Scenarios
3.1.
Emergency Notification
Systems
3.2.
Urgent Notification Systems
3.3.
Event-Driven Notification Systems
3.4.
Routine Notification Systems
4.
Inbound SIP Scenarios
4.1.
4.2.
5.
Network Failures
6.
Other Considerations
7.
Summary
8.
Acknowledgements
9.
IANA Considerations
10.
Security Considerations
11.
Informative References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
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.
| TOC |
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] (Rosenberg, J. and C. Jennings, “The Session Initiation Protocol (SIP) and Spam,” January 2008.), 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] (Tschofenig, H., Schulzrinne, H., Wing, D., Rosenberg, J., and D. Schwartz, “A Framework to tackle Spam and Unwanted Communication for Internet Telephony,” November 2007.) and [I‑D.niccolini‑sipping‑spitstop] (Niccolini, S. and J. Quittek, “Signaling TO Prevent SPIT (SPITSTOP) Reference Scenario,” January 2007.)) 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 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.
| TOC |
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.
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.
| TOC |
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:
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).
| TOC |
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:
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..
| TOC |
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:
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.
| TOC |
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.
| TOC |
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 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.
| TOC |
Similar to the Event-Driven outbound systems, there may be legitimate inbound calling due to specific *known* events. Examples include:
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.)
| TOC |
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:
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.
| TOC |
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.
| TOC |
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.
| TOC |
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 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.
| TOC |
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.
| TOC |
This memo includes no request to IANA.
| TOC |
This document relates entirely to security considerations for potential voice spam.
| TOC |
| [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 (TXT). |
| [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 (TXT). |
| [RFC5039] | Rosenberg, J. and C. Jennings, “The Session Initiation Protocol (SIP) and Spam,” RFC 5039, January 2008 (TXT). |
| TOC |
| Dan York | |
| Voxeo Corporation | |
| Keene, NH | |
| USA | |
| Phone: | +1-407-455-5859 |
| Email: | dyork@voxeo.com |
| URI: | http://www.voxeo.com/ |
| TOC |
Copyright © 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.
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.