Voice of VOIPSA

I wrote previously about new Internet-Drafts out about a “framework” for combating Spam for Internet Telephony, a.k.a. “SPIT”. With the IETF 69 meeting coming up in a few weeks in Chicago, Hannes Tschofenig is really looking for some feedback on these docs so that he can incorporate any feedback before the IETF 69 meeting. We would strongly encourage people to take a look at these docs and send comments directly to Hannes Tschofenig.  I have commented… please add your voices.  (He’s looking for all kinds of feedback… for instance, I gave some input on an earlier draft that a section needed to have more details added because I didn’t understand it overly well.) 

The Truth in Caller ID Act of 2007 (HR 251) passed in the U.S. House of Representatives on June 12th. It’ll be interesting to see if it makes it through the Senate this time, as last Congress the Senate basically sat on it until it was dropped at the end of the 109th Congress as not having passed.

If you’re interested in tracking this (or any other) bill as it makes it’s way through the U.S. Legislation process, I’ve found GovTrack.us to be invaluable.

One aspect of VoIP security that keeps coming to my attention in recent weeks is that of location privacy, or in other words, does the call recipient (or others ‘listening on the line’) know where you are?

At a VON Europe panel this week, Cullen Jennings, Distinguished Engineer at Cisco, was talking about peer-to-peer (P2P) SIP, and how the P2P approach definitely helps with location privacy. He gave the example of emergency procedures in the USA, which require the country’s President and Vice President to be in different physical locations from each other yet still be able to communicate. At the same time, they must prevent eavesdropping enemies from locating the Vice President physically.

I said that ‘P2P helps’, but perhaps I should say ‘can help’, with the right systems in place. In the UK last week, Sky News ran a story about how criminals might use encrypted VoIP to run circles around the police, due to the difficulty of tapping and listening to the calls. I hope to be able to write in more detail in the next few weeks why this is basically untrue, but the information I have received is that the VoIP providers “can be very helpful” to the police in these cases. Even if a VoIP stream cannot be decrypted, it is often possible to obtain a list of times, durations, and IP addresses that can easily provide both location and evidence. Also, if a VoIP call breaks out onto the PSTN, a service offered by many or most VoIP telcos, then once again you have a location (albeit the call destination rather than the source), and you have the opportunity to monitor the call.

No-one likes to think that all their calls are being tracked, or that their location is known at all times, but of course in democratic countries we assume that there are enough checks and balances to ensure that this information is available to few and will not be abused. At the same time, criminals and terrorists should not assume that new technologies like VoIP and IM give them a cloak of anonymity, because this is definitely not the case.

As systems become increasingly interconnected, how do we prevent Spam for Internet Telephony, a.k.a. “SPIT” or “VoIP spam”. As we talked about in this blog and on the Blue Box podcast, SPIT today is not really a huge issue because the PSTN serves as a de facto firewall between companies/entities.  But as we move toward increasing interconnection and to the point where a random SIP user could make a SIP connection across the Internet to any other random SIP user, we definitely do have to worry about SPIT and how to prevent it.

Within the IETF, a group has been working on the issue and now has two documents available for review:

• A Framework for Reducing Spam for Internet Telephony
• Requirements for Authorization Policies to tackle Spam for Internet    Telephony and Unwanted Traffic

This is the initial release of both documents and the authors are definitely seeking feedback.  Speaking of the authors, they include many of the names we have mentioned here in the past involved with VoIP security within the IETF space:  Hannes Tschofenig of Nokia Siemens, Henning Shulzrinne of Columbia University, Dan Wing of Cisco, Jonathan Rosenberg of Cisco and David Schwartz of Kayote.  (Geoffrey Dawirs of University of Namur and Thomas Froment of Alcatel-Lucent are also authors of one, but I don’t believe we’ve spoken of either of them here before.)  They are definitely people who understand the space and have put some thought into it.

I would encourage everyone to take a look at those documents and send in feedback, either to the IETF mailing lists or directly to Hannes Tschofenig (editor of both docs).  We have an opportunity here to make sure that interconnected VoIP does NOT become the utter cesspool of spam that email has become.  Let’s make sure we do it right!

Today at Spring VON Europe in Stockholm, one of the panel sessions covered the issue of the proliferation of codecs, both for video and voice.  Industy veteran Henry Sinnreich of Adobe rasied an interesting topic for the panel regarding compromised or evil codecs.  An evil codec could provide a stream of audio designed in such a way to crash or destabilize an endpoint, with the aim of putting the endpoint in a mode where the conversation could then be monitored.  Some researchers have already shown that such attacks are in principle possible.

So the question is what to do about this, and how to test systems to prevent this kind of attack?  There were no real answers were forthcoming today, but I shall certainly revisit the topic in my panel session tomorrow,  The Real Risks of VoIP Security, and see if my experts fare better.

From my own point of view, I think it could be a nightmare to have to scan every RTP stream in real time for ‘evil’ signatures, much like in email scanners.  The CPU required to do this for all audio could be disabling.  If the codec software can be ‘hardened’ and made robust enough to withstand such an attack, this would seem a better solution.