July 30, 2005
IAX, ClueCon and T-shirts
I've just finished checking a whole bunch of new code into the CVS. This code came from long-time contributor Derek Smithies who has performed the amazing feat of implementing the IAX2 protocol as part of OPAL, and did it with the support and permission of his employer ClueCon in Chicago in the context of OPAL. I'll also be talking about Woomera, and learning from the other speakers. I know of quite a few OpenH323 and OPAL developers who will be there - if you are going to be there then please email me and let me know so we can arrange for everyone to get together.
If you are looking for me, I'll be the one wearing the Open Source VoIP t-shirt :)
Posted by CraigS at 09:08 PM | Comments (0)
July 29, 2005
VoIP security
Yesterday, a Slashdot article was carrying the following quote in an article titled "Voip Security":
The fact that VoIP operates across standard networks makes it vulnerable to all manner of IP hacking - including man in the middle attacks,sniffing, session hijacking, etc.
This seems to be saying that VoIP is somehow less secure because it operates across networks that use standards. This is an interesting conclusion, because the implication is that this is somehow different from the situation with the existing telephone network that VoIP is replacing.
There are so many holes in this argument that it is hard to know where to start, but I'm going to try anyway.
The most obvious flaw in this statement is that the networks that VoIP operates on (including the Internet) only exist because there are standards. Without these standards, which act as treaties beween all of the people who want interconnect, there would be no way to build the network in the first place. To use an analogy, this is kind of like complaining about the fact that air pollution is a problem because we breath air. There's not a lot we can do about it.
Looking past this statement, the concern seems to be that VoIP networks are somehow more susceptible to interception or hacking than the technology it is replacing. Again, this argument does not hold water, because PSTN networks can be hacked in just as many ways as IP networks. As was pointed out by responders to the Slashdot article, any kid with a phone handset and a pair of alligator clips can clip onto a phone line and intercept calls, or make unlimited calls on someone else's account until they do something stupid and get caught.
So what's the problem?
As usual, I think it's all about perceptions. For some reason, VoIP networks are perceived as being less secure. And this is because the technology behind VoIP (i.e. the Internet) is understood to some extent by the the people making the claims. Those same people have little understanding of the PSTN network, because that has just become part of the invisible fabric of society. The reality is that both technologies currently have much the same problems and vulnerabilities. But there is on major difference - VoIP has much more room to actually address the issue of security.
The word "secure" tends to get used as a catch-all label for a grab bag of issues including call interception, phone fraud, and billing problems. As far as VoIP in concerned, the solution comes down to two issues: authentication, which means knowing that you are talking to the person you think you are talking to; and privacy, which relates to the ability to ensure that communication between two parties cannot be intercepted by an untrusted third party.
The two concepts of authentication and privacy are theoretically independent, but in practice there is little point in having privacy without authentication. This is because defeating a "man-in-the-middle" attack requires authentication, and there is little point in having private communications if it can be subverted by simply interposing a third party. So authentication is the first requirement, and then privacy will follow.
The PSTN network implements authentication by enforcing a relationship between a billing entity and a piece of wire or fibre. This works because the PSTN switches (which are under the control of servicde provider) are actually physical connected to a piece of network cable that goes to the customer. In the case of cell phones, authentication relies on a number embedded in the handset. Neither of these are particularly strong methods of authentication - cloning of cell phone handsets is rife and anybody who has seen a telephone technician attach a test handset to wire pairs in a street phone switch panel cannot possibly see this as being secure. Privacy is achieved by the same physical means, which in the end all comes down to security through obscurity, which we all know is a totally outmoded concept.
VoIP technology will change this. Not might change, but will change. I predict that the next few years will see cryptographically authenticated and encrypted VoIP networks become the standard. This technology will be based on exactly the same methods used by secure web sites, namely certificates and encryption. In fact, the standards already exist for authentication and privacy for both SIP and H.323 and the only reason they have not been widely implemented to date is just a matter of maturity (in the networks) and lack of demand (from consumers). That is already changing.
Apart from consumer demand, there are several factors driving the service providers towards fully authenticated and private VoIP communications. Emergency 911 support is one of them. There is also the desire to move to post-billing for VoIP which will require much more robust authentication than the simple account number and PIN that most vendors use currently.
A fully authenticated VoIP network requires an infrastructure to distribute issue, maintain and distribute certificates (or equivalent) to endpoints. I see this as being piggybacked onto some other authentication system, such as the keyring concept used by Phil Zimmerman's PGP network. It could also be done by the Passport system from Microsoft, or the similar offerings from any of the major portals such as Yahoo or AOL. Within a corporate environment, it could be done using smartcards or hardware built-in to the endpoint itself.
Regardless, there is no reason to believe that VoIP is any less secure than PSTN, and lots of reasons to see why it can be far more secure than PSTN could ever be. I'm looking forward to seeing it happen, and if possible, making it happen via OPAL :)
Posted by CraigS at 12:01 AM | Comments (1)
July 28, 2005
The history of OPAL
The history of OPAL as a piece of software development is a long story. A verrryyy loooong story. And a lot of it isn't even my story, as Robert has been the prime mover behind the development of OPAL even though the idea was originally conceived by both of us. But as I am going to be talking about OPAL next week at ClueCon in Chicago, I think it is time that I wrote down a coherent version of the history of this software, especially as I am intending to be using it for new VoIP projects looking going forward into the future.
OPAL has it's roots, obviously, in OpenH323. To understand exactly how OpenH323 spawned OPAL, we need to go back to late 1999. Robert and I had just got the first release of OpenH323 working (mostly) and we were looking at the problems we had with the code and what we wanted to do next. Robert and I used to meet in person once a week (we used to, and still do, live 100km away from each other in different cities) to spend an entire day just discussing code architecture and other issues we wanted to address. We covered a lot of ground in those discussions, and we came up with s few major issues we wanted to resolve for the next version of OpenH323, which we called OPAL for Open Phone Abstract Library. OPAL is also a gemstone which is found mainly in Australia, so it had a nice ring to it :)
The major issues we wanted to resolve were:
- We wanted to support a new protocol called SIP that everyone was talking about. It seemed obvious to us that as it was under the control of the IETF, it would only be a matter of time before it would be pushed as the successor to H.323 (which was administered by the ITU)
- In OpenH323, different types of connection were difficult to join together even though they had almost the same characteristics. For example, a H.323 connection, a sound card, and a PSTN termination device all have an audio channel, and some signalling controls, but look completely different to each other in terms of API. Wouldn't it make sense to have them all look the same (or at least, very similar) so that programs that handled one device type could handle them all?
- the directory structure of OpenH323 meant that filename collisions were possible. This was due to OpenH323 having a single layered include file hierarchy.
- OpenH323 did not provide abstract classes for concepts like "connection" and "endpoint", which meant that similar concepts in new protocols would not share any common ancestor with their H.323 equivalents.
- The implementation of shareable blocks of code such the RTP stack and codecs were not very well modularised.
- The video code in OpenH323 worked well, but did not seem to be a clean design. We felt it is needed to be streamlined and made easier to use.
Our plan was that Robert would start working on the reorganisation of OpenH323 to create OPAL, while I started on an implementation of SIP using PWLib and whatever parts of OpenH323 I could use. In the mean time, we would continue to support OpenH323 and backport changes to OPAL whenever needed.
We attacked the code with gusto, with Robert creating a new directory structure and implementing the idea of "streams" that we agreed would be the abstraction that normalised devices and protocols into interchangeable entities. Robert developed the idea of a "manager" that served to control the various protocol specific endpoints and provided the mechanism whereby an application could control various features from a single class instance regardless of the number of different protocols or devices that were being used. My SIP implementation was proceeding well, with simple calls working well and we were fixing SIP compatibility issues with equipment from various vendors. The single biggest missing feature at this stage was video, and that was next on Robert's hit list.
Then we decided to do the deal with Quicknet in early 2000, and OPAL effectively went into hibernation for four years. This was an immense source of frustration to Robert, as he had done the lion's share of the work on OPAL to date, but the simple fact was that neither of us were unable to spare time to work on OPAL when we needed to work on OpenH323 to earn money.
During this time, other people continued to work on OPAL but Robert and I did added almost no new code. Several times, Robert merged the OpenH323 source tree back to into OPAL, which helped to keep the code more or less at the same level as OpenH323. During this time, people like Damien Sandras (of GnomeMeeting fame) kept the flame alive by continuing to ask about the future of OPAL. But the reality was that OPAL was, if not dead, then certainly gravely ill.
Then, in mid 2003, we left Quicknet, and the picture changed again. Robert was able to find the time to do some work on OPAL, but he was now working somewhere else and was not working with either OpenH323 or OPAL at all in his professional life. I was working with OpenH323 at least some of the time, but there did not seem to be much interest in OPAL at all.
And then in the last 12 months, the picture has changed again. Thanks again to Damien Sandras, and other people like Ted Szoczei, interest in OPAL has resurfaced. Robert has also found the time to work on video again, and I have talked to many people who are interested in seeing OPAL become a fully working stack.
So that's how we got to where we are. OPAL is being actively developed and used by many different people and I expect that it will become the principal vehicle for many new VoIP projects in the near future. If you are interested in being part of that process, or have some ideas on how to help, then join the OpenH323 mailing list and let everyone know what you think. Or email me if you want to talk about it more in private - either way please speak up and make difference.
Posted by CraigS at 01:11 AM | Comments (1)
July 27, 2005
Links of the Day
From time to time I get asked what web sites I check on a regular basis for news. I posted on this back in December 2003, and it was interesting to see what has and hasn't changed
I'm still checking SlashDot on a daily basis. IMHO, it's still the best place for geek news. But I also check out Bruce Simpson's Daily Aardvaark site for a more Australiasian skew on things. BTW, Bruce in an interesting guy - anyone who builds and tests his own jet engines is a serious geek!
The Sydney Morning Herald is still my source of normal-world news. The daily Column-8 column provides a light-hearted way to start the day.
APOD is worth checking every couple of days, because a few times every week they slip in something new between the repeats. Same with IMDB and Dark Horizons - as a long time movie geek these help me stay up to date with the latest gossip. And I'm still reading Penny-Arcade every few days as well to keep up with the latest news in the gamer world. This helps me to stay in tune with my two sons who are both semi-serious gamers :)
James Randi's weekly commentaries provide me with dose of rationality in an increasingly irrational world. I've yet to find anything him say anything that I seriously disagree with. Which is very different from The Alpha Patriot with whom I can find sometimes find common ground, but who ocassionaly disappears into some alternate reality. Still, it provides a useful comparison to the usual bland fare offered by most new sites
After writing this, seems my tastes have not changed all that much over the past few years. Not sure if that is good or bad...
Posted by CraigS at 01:58 AM | Comments (0)
July 26, 2005
New site....
Welcome to Craig's new RoaSM blog.
I know it has been a long time coming, but life kept getting in the way. But now that I have MovableType re-installed, I can get back to my semi-occasional discourses on a variety of topics.
A static version of my old blog will continue to be available until I can migrate entries I think are worth keeping.
Posted by CraigS at 01:11 AM | Comments (0)