How much encryption is 'enough' for VoIP?

Whenever the topic of VoIP arises, security continues to be a burning issue. For some reason there is a perception that VoIP, whether transmitted over the Internet or not, is inherently unsecure. For that reason, there likewise seems to be a perceived need for end-to-end encryption of the conversation.

While we agree that there is doubtlessly a need for an extremely secure infrastructure when implementing VoIP, we remain a bit puzzled as to why people think they need to encrypt the content of the conversation itself.

This is little historical precedence for encrypting telephony. With the exception of highly secure needs, such as those of the military and intelligence communities, traditional telephony is seldom, if ever, encrypted. The entire digital hierarchy is built on increments of 64K bit/sec DS-0s, each containing one unencrypted digital telephony conversation using Pulse Code Modulation. A T-1 (or DS-1) circuit was designed to carry 24 unencrypted phone calls, and a T-3 (or DS-3) was designed to carry 28 T-1s.

In fact, when we checked with a traditional voice service provider, we were informed that encryption of voice traffic was generally not a concern and an issue that customers seldom asked about.

In fact, we'll argue here that if anything, there is too much encryption of VoIP traffic. Why? It's easy to encrypt IP traffic using techniques like IPSec and SSL, so any IP-based traffic - like VoIP - can be encrypted with minimal effort. In fact, many free or almost-free VoIP applications even encrypt traffic by default. Our concern here is that this readily available encryption makes lawful and appropriate monitoring of traffic for national security and law enforcement much more difficult than it should be.

Bottom line: Use encryption where it's important. But don't assume that encryption is an absolute necessity for a successful VoIP implementation.

Are you using encryption for your VoIP traffic? Why or why not? Let us hear from you and we'll summarize the feedback that we receive.

Join the newsletter!

Error: Please check your email address.

More about SEC

Show Comments