Speaking of Standards

As 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

One of the livelier sessions at the IETF meeting in Vancouver, BC was the segment having to do with SPIT. No I am not talking about what comes out of your mouth but rather the internet telephony version of SPAM. While it’s not a big problem yet, folks in the industry are indeed concerned about it and how to prevent it before it gets to be one.

The problem (or really the good news in this case) is that for the most part SPIT does not really exist yet in the wild. This being the case however we really don’t yet know what it looks like or how to detect it.

Currently some of the work is going into figuring out what SIP header we would transmit SPIT information to clients in. The problem is that at this point I don’t think that it’s clear that we know what SPIT scores need to look like. Is a simple number from 1-100 the right way to measure this? Or do we need a more complex way of delivering multiple scores and information to explain to the user agent what the SPIT detectors have discovered.

All of this however does not yet touch on the MUCH bigger problem of how to detect SPIT. As with e-mail the problem is that much depends on the context and permissions involved in the actual message. You can not simply decide that something is SPIT based on the fact that they place a lot of calls in a short amount of time (as I have heard suggested by some people). An example of a use-case where this does not work is emergency outbound notification. For systems like this platforms NEED to be able to place very large numbers of phone calls in a short amount of time. While some might say that white listing can help with some of these cases I think e-mail has shown that for this most part this does not not work. I don’t want to miss a call telling me that something horrible when on at my child school because I forgot to enter my school’s phone number into my office PBX.

Anyway there is still much work to be done in the space and there are sure to be many more heated discussions at the IETF and elsewhere on this subject.