Disruptive Telephony

Over on the Voice of VOIPSA weblog, I just posted "Ready or not... here come the IRC-controlled SIP/VoIP attack bots!" Given the sheer number of VoIP security tools out there, I think I and most others involved with VOIPSA figured it was only a matter of time before someone automated the attacks.  Did I hope that the creation of "bots" could have held off for a bit longer?  Definitely... but we have to play with the cards we are dealt.

I tried in the article not to hype the threat... that we are aware of, there are not massive botnets out there waiting to attack VoIP systems.  But there is now a proof-of-concept "bot" out there and those of us dealing with VoIP security have to look at how that could impact us.

And it's definitely a sign that we as an industry really have to get security locked down on SIP systems!

In the usual (and ongoing) flurry of IETF announcements, there was one notice that caught my attention.  It announces that an Internet Draft document about "dialstrings" has been approved to become a standards-track RFC.  So what, you say?  Well here's a bit more info:

This document provides a way of incorporating a dial string into the SIP or SIPS URI scheme. A dial string is a cousin of a telephone number, but rather than taking the form of a fully-qualified E.164 or national-specific telephone number, it is a description of a literal set of dialed digits that would be delivered over a POTS line. As such, it may include pauses, omit prefixes like area codes, and its applicability is necessarily restricted to a particular context (an enterprise, a LATA, etc). Support for dialstrings was formerly a feature of the tel: URI scheme specification (back in RFC2806); since that functionality did not make it into the revision (RFC3966), it is provided here specifically for the SIP and SIPS case.

Think of it as extra digits you have to type when making a call... or extra keys you have to press to start a service.  The challenge is that SIP proxies and other services need to know that it is a string of numbers that should be handled in a special manner, rather than just thought of as part of a SIP address or something like that.  I mention it here only because it's one of those really low-level things that you can do on the PSTN but until now haven't had a (standard) way to do in SIP. It's also one that ultimately anyone implementing SIP will need to implement.  No RFC number yet, but that will come soon.  Note the nice security warning:

Dialstrings exposed to the Internet may reveal information about internal network details or service invocations that could allow attackers to use the PSTN or the Internet to attack such internal systems. Dialstrings normally SHOULD NOT be sent beyond the domain of the UAC. If they are sent across the Internet, they SHOULD be protected against eavesdropping with TLS per the procedures in [RFC3261].

Yep... as we've been saying over at VOIPSA and Blue Box, you definitely need to think about encrypting SIP if you are sending it across the Internet.  If not, bad things will happen eventually.

In my incredibly long queue of things I've wanted to write about for the past few weeks, one item was the Mitel news release about making a direct SIP connection to Microsoft Exchange Server 2007 Unified Messaging. The cool part is that you can just use our basic 3300 ICP communications platform (or IP-PBX, or whatever you want to call it) and connect it directly into a Microsoft Exchange Server to use the Exchange Server for a unified inbox (email, voicemail, fax, etc.).  No other boxes or gateways necessary.  Just a nice, standard SIP trunk.  As a long-time proponent of open standards and general "standards geek", it really can't get much better.  It's great to see.

 So you'd like your SIP phones to all work together, eh?  And you'd like your SIP phone from Vendor A to work with the SIP phone of Vendor B and yet give you the business functionality that you used to have in the PBX from Vendor C?

Good luck.

Yes, they will (or should!) all work together for basic call functions, but if you want to do more than just the very basics, you rapidly wind up in the realm of incompatible SIP implementations.  Different vendors support different RFCs... or interpret RFCs differently.  It's a challenge to go beyond basic functionality.

Enter "BLISS", one of the latest working groups coming out of  the IETF. It stands for "Basic Level of Interoperability for SIP Services" and, as noted in its charter, the intent is to define a basic set of functionality ("minimum interoperability requirements") to allow SIP endpoints to interoperate on 4 specific telephony services:

1. Bridged/Shared Line Appearance (BLA/SLA)
2. Call Park/Pickup
3. Do Not Disturb (DND)
4. Call Completion to Busy Signal/Call Completion on No Reply

More details are on the charter page.  These are just the initial four issues chosen to be addressed and Internet-Draft documents are already circulating on some of the items.  I see it as a necessary group if we are to actually have real interoperability between SIP endpoints, and I commend the group organizers on scoping it to an initial 4 issues (rather than making it wide open).

If you work with SIP, I'd encourage you to check out the BLISS web site, read the "problem statement" and charter... and then join the mailing list (and please read the archives to see what's happened so far).  I've joined the list... and would encourage others to consider doing so.  If we do want real SIP interoperability, we need to hammer some of these things out.

For more information, you can download the set of slides presented by Jonathan Rosenberg of Cisco at the IETF 68 meeting stating the problem and why the BLISS working group is needed.  To make it easy to see them, I'm going to embed a SlideShare version here:

See you on the list...

Noticed today that Tom Keating has a review up on "pbxnsip", which has the interesting twist of being a low-cost PBX solution running on Microsoft Windows.   Most other inexpensive or open-source software-only PBX solutions tend to run on Linux, and indeed, pbxnsip does have Linux versions (and apparently NetBSD although they are not listed... perhaps they just run the Linux version).  I first actually learned of pbxnsip some time ago at one of the various VoIP tradeshows when I was struck by the fact that they were advertising security as the main point in big letters on the background to their booth. In fact, security is #2 on their list of "reasons to buy":

It addresses security. The pbxnsip PBX uses https, sips, SRTP and sdes to make the communication to your PBX secure. Using sdes-capable devices, your voice calls will stay as secure as your https traffic.

Well, gee, given my background, it's not hard to imagine that any vendor that basically leads with security gets some extra points in my book.  (Especially since doing so has the potential to paint a big red target on your back to all the attackers out there who like to debunk claims about security.)  I've not played with it myself, but Tom's review does indeed make it sound interesting.

I guess I'll have to add it to the (huge) list of things to check out...

Thanks, Tom, for as usual providing your very thorough reviews - you definitely help a lot of the rest of us.

UPDATE: I knew there was another reason I knew of pbxnsip... CEO Christian Stredicke has been on the VOIPSEC mailing list for quite some time, although I recall hearing from him primarily when he was with snom technology.

Dean Elwood over at VoIPuser.org has taken up the question about Open ID with his post "Why SIP Doesn't Need OpenID".  Dean suggests that the problem really lies between servers:

The problem of identity authentication actually resides in the server to server realm in a peered environment. How does sip.fwd.com know for sure that a peered call request is really coming from sip.voipuser.org?

Good question... and one that Dean believes can be solved through the use of the already-standardized Open Settlement Protocol (OSP).

The conversation continues...

Scanning RSS feeds early this morning, I was pleased to see that Rich Tehrani will be speaking at our "Presence 2007" event in Costa Mesa, CA, today. I've known the tour was going on, but wasn't tracking who was speaking at the various stops.  Glad to see Rich there... I'm sure he'll give a great talk for whoever attends.  The good news for Rich, too, is that at least he was flying out of the New York area yesterday instead of the day before when the glorious storm played havoc with air travel all over the northeast.

(Originally posted at http://dyork.livejournal.com/256998.html)

Tom Cross over at Techtionary.com dropped a note to let me know that his team had released a 'fastcast' on the topic of "SIP Essentials". Not having a clue what a "fastcast" was, I found the answer in Tom's news release:

Fastcasts are fast-track audio/video animated 10-60 second advertorials for web, webseminar, PC and iPod formats.

Not sure how much traction the word will really get, but there you have it. Tom's SIP tutorial looked quite interesting in the bit that I explored, with sections on:

• SIP Basics
• SIP Trunking
• SIP QoS
• SIP Firewalls and Security
• SIP Applications
• SIP TCO-Total Cost of Ownership
• Integrated/Converged Access
• Key VoIP Options – IAS, Hosted, Managed
• SIP Total Tutorial with Future Outlook

(Gee, any guesses as to which one I chose first?) Clicking each link takes you to a flash-based tutorial with audio and animation. The ones I looked at were quite good. A nice contribution to the education around SIP... and definitely good for folks trying to figure out what SIP is all about.

Tom's making it available at no cost right now so I'd recommend people check it out.

Just one note of caution... once you enter one of the tutorials, you do need to listen to all of the audio for a page before pressing "Next". If you simply press the Next button to move through the slides, you suddenly find yourself with multiple streams of audio all mashing on top of each other! (And yes, this is the voice of experience writing this...) Kind of neat if you need the effect of people talking over each other, but not terribly helpful otherwise. Outside of that issue, otherwise I found the sessions quite useful. (At least, the ones I went through... I did not go through them all yet.)

Technorati Tags: sip, techtionary, tutorials, voip, voip security