Can legitimate SIP traffic be mistaken as SPIT? (voice spam)
January 16th, 2008 by Dan YorkAs more systems get connected using VoIP and over time security systems come into use to help prevent voice spam, a.k.a. “SPam for Internet Telephony” or “SPIT”, what happens if you have an application that makes a very large number of outbound calls? For instance, a notification system? Might the traffic from that application not look like the beginning of a flood of SPIT?
Within the IETF there’s been a bit of discussion in the past months about voice spam/SPIT and just recently RFC 5039 from Jonathan Rosenberg and Cullen Jennings was published that specifically addresses the issue of SIP and Spam.
The RFC is an excellent summary of the current thinking about the SPIT problem and potential solutions to address it. If you haven’t read the document, I would *highly* recommend it.
A concern I had, though, was that it did not appear to me that existing documents address the issue of what SPIT could look like at a network level. For instance, if a network administrator monitoring network traffic suddenly saw a large flood of SIP INVITE packets coming into his/her network, it could be:
1. a telemarketer/spammer launching a flood of SIP connections to
deliver SPIT;
2. an attacker launching a DoS attack through one of the various SIP
attack tools out there; or
3. a legitimate notification system starting to notify a range of SIP
endpoints.
I could very easily see existing network tools that look at traffic and perform anomaly detection (and potentially source suppression) being modified to suppress large flows of SIP traffic. This last case of legitimate traffic concerned me and so I put together an Internet- Draft talking about the types of legitimate systems that might generate a significant volume of traffic that could resemble SPIT (or a DoS attack).
I put the document out primarily to stimulate discussion. Are these legitimate scenarios being addressed in current thinking about SPIT? If not, my point really is that they need to be considered.
Comments about the document are very definitely welcome. Are there other scenarios I should include? Am I accurate? Am I overstating the case? or what?
Technorati Tags: ietf, security, sip, standards, voip, voip security
RSS Feed
January 21st, 2008 at 2:48 pm
Thanks for providing this document. I think you are right on the money with this concern. We have been setting up emergency notification systems on campus (e-mail and SMS, no SIP yet) and have been seeing blocking issues on those systems, so the issue is very real.
You should probably expand your inbound scenarios. Using the Virginia Tech example, what did their call profile look like on the day of the shootings? What about natural disasters? In the TDM world, these are traffic engineering issues but in the IP world they look like (and are to some extent) DDOS attacks. While traffic will need to be shaped, but a generic DDOS response would not be appropriate.
I also worry about testing the inbound scenario. We do periodic testing of our outbound emergency broadcast systems so we have a reasonable assurance they will perform when we need them (of course, no assurances that we won’t get blocked if we send several in one day). But, how do you test your enterprise system for this flood of INVITES? And how you test your ISP(s) to be sure they do not treat the calls like a DDOS attack?
January 26th, 2008 at 6:45 am
Larry, Thanks for your comments. Yes, indeed, traffic from an inbound scenario could very much look like a DDoS attack! I’ve had some other feedback as well suggesting I expand the inbound scenarios and I probably will do that for the next version.
As to the testing of inbound scenarios, I, too, don’t know exactly how you could do that. Generating a flood of INVITEs is relatively trivial given some of the tools out there, but getting it to originate from a wide range of IP addresses to simulate such a scenario would be the challenge. (It’s almost like someone needs to run a “white hat” botnet out there for testing these type of scenarios… but of course keeping such a botnet from being used for malicious purposes would be the added challenge.)
Thanks for your comments, Dan