Upon beginning my new job, I’ve been thrown head-first into the world of Internet Telephony security, a sector that I’ve not really paid much attention to, much less followed. I’m currently in the process of getting acquainted with all of the various protocols and technologies involved, and in doing so I’ve signed up to the VoIPSec mailing list. After following the current discussion threads there for a few weeks, I see a recurring problem that I’ve seen in other growth sectors before, and unfortunately will probably see again.

As the minds on that list, and presumably some of the top VoIP minds in the industry, attempt to design security and new functionality into the existing technologies, they also struggle to maintain backwards compatibility with existing devices and infrastructure which can be quite difficult. Due to the fact that any number of the elements in any given VoIP infrastructure may be hardware based with embedded OS, it’s not as cost-effective as a software environment to just upgrade all the devices to support the new features or function, so there’s a significant cost investment in legacy systems, warranting this effort for backward compatibility. In Internet Telephony, you also have to factor in the possibility that the user may have their own device, and it resides squarely outside the realm of your management domain. In this sector it’s a little more obvious why backwards-compatibility is attempted, but what about in other sectors?

In my opinion, based on my observations over the years, as a budding industry develops technology and then attempts to maintain some semblance of backward-compatibility with it’s earlier versions of that technology, innovation and progress tend to slow and eventually come to a crawl. As new security features or functionality is devised, it’s similarly shot down by community run industry groups like the IETF because it won’t inter-operate with protocol X or it’ll put company Y out of business because they make a living providing a solution to a symptom of a problem rather than anyone actually fixing the problem itself. Too many feel that everything these days needs “community ratification” to be viable. No one is willing these days to say “Screw protocol X, it’s broken. We’re making a new one.” or “Company Y shouldn’t have chosen to build a business around addressing a symptom.”

Take SMTP for example; Numerous next-gen mail protocols have been put to death because every time they begin the long process through a standards body arguments such as “everyone uses SMTP and the barrier to entry is too high” arise, even though SMTP as it was originally designed and as it stands today is inherently insecure. If you don’t know what I’m talking about, take a look at your SPAM folder in your mail client. An entire industry exists that is built around SPAM, so of course no one is really interested in solving the actual problem, the lack of security features in SMTP. Instead, everyone focuses on solving the symptom of the problem, namely a cluttered inbox full of prescription pill and penis enlargement ads. Another example of a business model addressing a symptom and not the root problem is Anti-Virus; They have built an industry around cleaning infected systems and repairing damage from viruses, and at this point not much research is being done in preventing the virus from ever infecting the system in the first place. There is simply too much revenue at stake in the current business model.

The state of technology development in the open community today is cluttered and slow to progress. While community involvement is good and I’m a proponent of it, sometimes the individual or the corporate entity needs to say “We’ve heard the community’s input, we’ve made our decision, and now we’re going to get it done.”, and then not sell-out to a company built around the symptom of the problem they’re intending to fix.