Search This Blog

Tuesday, January 3, 2006

SPAM over Internet Telephony (SPIT, SPIM)

Happy New Year !!!
here to get your FREE iPod Nano !

No Wait ! This is not a SPAM post. Rather its a post about SPAM !

There has been a lot of discussion in the past on how serious of a problem spam for Internet Telephony (SPIT) and Spam for Instant Messaging (SPIM) is as VoIP deployments increase their market share. Spam itself as we all know is all-pervasive in the email world. I was reading an interesting report from Symantec which reports that 67% of email is spam these days. While the percentage is staggering, there is some(?) comfort in knowing that this percentage has ‘stabilized’, which might mean that spam filters/gateways are maturing at a rate that is able to cope with the mutation of spam tricks.

The interesting thing is that even though pundits scream about the problem of spam over Internet Telephony, not too many carriers are biting, at least, for now. It’s not that they don’t think its important, but it just seems that they have other problems to solve (like it or not, security is the hardest and the last solved problem in real life).

So here is my perspective of SPIT/SPIM: I am going to make sure I pepper this article with enough 4 lettered acronyms so that you are left dazed and impressed.

Incidentally, here is a screenshot of IM SPAM I received today:

Is SPIT a real problem ?

In short, I feel that SPIT is a problem, that will eventually surface. The logic: the infrastructure needed for SPIT is very similar to the infrastructure needed for spam. The cost is very low, and there are no ‘Do-not-call’ registry’s on the internet (at least for now). In addition, it is harder to detect a valid IP address of source as compared to an originating phone number. All in all, the Internet offers SPITers better anonymity and lower costs – so why not ? Infact, there are companies who already think it’s a big problem and have products out. Not to mention that this space will soon be chock-a-block with patents.

However, I must mention that I really don’t think SPIT is a huge problem for ‘walled-garden’ networks – it’s a much bigger problem when you have peer2peer neworks.

Why is SPIT a bigger challenge than SPAM ?

There are a few reasons for this:

a) More Intrusive: a telephone is intrusive by nature where as email is not: When you get a phone call, it rings, and loud. You cannot just ignore the ring, nor can you ‘move on to the next call’ – you need to answer it. Compare that to a spam email, which you can choose to ignore and move ahead and eventually move to junk

b) Harder to detect: Today’s spam filters are fairly advanced. In addition to white and black lists, a lot of them implement heuristics which try and detect the language patter to filter out possible spam guised as valid content. With SPIT, you are not looking at text – it’s a voice. Detecting heuristics in a voice stream is much harder – add to that the fact that a single sentence can sound very different depending on who is speaking (accent, amongst other things)

SPIT in Walled Garden vs. Peer2Peer networks

One of the strongest and most effective ways to avoid SPIT is by good authentication. In an ideal world, if every user could be authenticated for its identity, the chances that a spam bot gets to you reduces greatly. Walled garden networks usually operate in ‘circles of trust’. Let me explain: lets suppose were to call via SIP. For the proxy to accept the call from bob, it would most likely expect a digital authentication certificate from Verizon’s proxy telling the at&t proxy that this call actually came from verizon. In other words, AT&T trusts the Verizon network and expects the Verizon network to have authenticated its users. This sort of ‘trust circles’ between service providers is common. AT&T cannot go ahead and authenticate each and every user on a foreign domain, so instead it decides to trust the network, based on strong authentication. It is verizon’s responsibility to make sure that bob is a valid user. For a spammer to break such a network would require that a) It manages to successfully authenticate with verizon (which may well be an identity theft case) ,or, b) Manage to hijack the network authentication certificate and key to be able to ‘fake its network identity’ (which is not easy to do), or c) Be able to reach sue’s phone directly, bypassing both the proxies.

Case c) works if the UA itself accepts calls from any source. A secure UA should be configured to reject any calls that are not passed on to them from their inbound proxy via TLS. In other words, if were to call, Sue’s UA should detect if it came along with credentials from its authorized inbound SIP proxy and if not, it should be rejected, prompting the caller to go through the proxy.

If all UAs were indeed configured this way, then the problem of SPIT reduces a great deal (not eliminated, but significantly reduced). However, not all UAs are configured this way. In addition, while this can be enforced within a walled garden network, problems arise when:
  • The UA’s are part of a peer2peer network where there may not be any ‘central agreements of trust’
  • An adhoc-network tries to call into a walled garden network (Say, your uncle in Korea has set up his own FWD SIP phone and tried to call into you, a member of MCI’s SIP network –and MCI has no idea about – just an example)

One way around it is for UA’s to allow caller authentication. In other words, even if a call comes via unknown channels, instead of rejecting it, challenge the caller for identity, while at the same time, don’t make it cumbersome for the called user (for example, if every SPIT phone rang your phone, and then challenged it, you’d switch back to PSTN within a day ! At least in PSTN, the FCC has done an effective job with the DoNotCall registry). For example, Vonage, which is an example of a Walled Garden implementation requires authentication at the very least to let calls in.

Various ways to address SPIT

SPIT, just like its older sibling spam, is a prime example of ‘many partial solutions lend to a stronger overall solution’. In otherwords, there is no one mechanism that can effective
ly eliminate SPIT. The solution is to deploy various levels of defence in the hope that one of them catches the call before it reaches you. Here are some of them (since we mentioned, that content filtering which work with spam is mostly useless with voice)

  • Strong Authentication – is an important first step in filtering SPIT. As discussed in detail above, one of the best ways to filter spit is by network and UA participation, where the UA accepts calls only from a TLS route from its inbound proxy and the Network authenticates users. However, this is far from the current deployment situation (many UA’s don’t yet support TLS).
  • Reputation Based Systems – in addition to network identity, a reputation system works by assigning scores to sources. This score is a statistical formula based on its history. As an example, if a spit-er ‘’ makes a lot of calls to a network, and the users ‘flag’ the call as a ‘bad call’, then, depending on several factors, that identity could be marked as ‘bad’ and this reputation could be distributed across the network to warn other others. There are ofcourse several challenges to this: a) Spam agents often change identifies b) It is easy to poision such a system – for example, force negative feedback even when its not true. In other words, a good reputation system is a harder solution than it sounds
  • Central black lists – Not a complete solution, but an effective one. Spammers will keep creating new addresses while the black lists will keep adding to their repository. The lists eventually get more complete and more effective. Such lists exist today, and are very helpful.
  • Puzzles – Another mechanism is when a call arrives from an unknown source, throw an automated challenge. An example: If I receive a call for the very first time from user “Joe” instead of ringing my phone, redirect him to an IVR that asks “Joe” to press some random 4 digit sequence as a security verification. This is an irritant for Joe, especially if he is a valid user – but needs to be done only once. For this to work, however, either the called UA or the called UA’s network server needs to remember whether this is a first call, or whether Joe has called before. I personally think this is an effective solution, albeit with an irritant factor for the caller, but hopefully only once. The bigger concern, however, is who remembers this is the first call or the 1 millionth, especially when thousands call you over years. We need Google’s infinite database utilization techniques !
  • ­Payment systems – Folks like microsoft pushed this hard for emails. The idea is simple – for you to make a call, you first need to deposit a payment via some payment gateway for the called network. If the call is accepted, you get refunded, if not, you lose your money. I personally dislike this solution and don’t think it will work at all for end user voip networks – the very idea of having a credit card on file or doing a transaction per new call to a new network is a turn-off for consumers.

There are, ofcourse many more solutions and more in-depth discussions we could get into. But that would go into many more pages and a lot more of in-depth arguments. In short, it doesn't take much more than Spam's infrastructure to do SPIT effectively. The problem, as I see it, is more pronounced for de-centralized and peer2peer networks, but is also a problem that can plague walled garden networks (for example, even if the UA were to reject calls that were not routed by its trusted proxy, how many such requests are needed for a denial-of-service attack directly on the UA ?). A lot of SPIT can be avoided if an 'onion ring' spit detection and filtering mechanism is deployed, where both the network and the client participates in the effort.

Hope this whets your appetite as you read more.

Further reading: here, here, here

1 comment: