Can IPSec work over a voice network?

In How to... run voice using broadband, we looked at the bandwidth and QoS implications of trying to use DSL to pass VoIP traffic. But there are also some security-related issues that you are likely to come up against. These aren’t directly related to DSL, although it’s here that you’re most likely to encounter them, but can appear anywhere you’re running IPSec to connect your remote users.

Bandwidth optimisation
If you’re connecting a small remote office or homeworker back to your main office, it’s unlikely you’re going to throw loads of bandwidth at them. Chances are you’ll be using dial-up or DSL if you can’t justify a leased line, or if you need to provide for mobile users. In this case, there’s every possibility that you’ll be insisting that they use IPSec to make sure your data is secure as it crosses over the public network.

That’s as it should be. But suppose you’d like them to be able to use that same connection to make voice calls too, to save on mobile phone bills? If you have IP telephony in head office, they could work as if they were in the office by plugging a USB handset in the back of their PC, or using an IP (or analogue) phone connected to the office router.

You’re going to want to minimise the bandwidth used by the calls, so it’s probable you’ll configure up G.729 rather than G.711. But that will still require about 24kbps per call. If you’ve been listening to the vendors, they will tell you that by compressing the RTP headers, this can be brought down to about 12kbps, which is what you want if you’re pushed for bandwidth.

Except that this won’t work over IPSec. Using IPSec means that the IP, UDP and RTP headers are encrypted before they get to the cRTP engine, so it can’t run its compression algorithm. Not only that, but the additional headers added by the IPSec process will make the header about twice the size it was, so instead of 24kbps per call, you’re probably looking at about 50kbps (and well over 100kbps for a standard G.711 call). There are various projects going on to look at a way of dealing with this but nothing in production yet.

QoS issues
There are also problems to do with the interaction of QoS mechanisms and IPSec. Some of these have been dealt with by some manufacturers: some haven’t.

The DSCP value assigned to a VoIP packet has to be copied into the new IP header created by the IPSec process so that it can be honoured throughout its passage over the network. This is vendor-dependant on how well this is done. You should also query your supplier on the queuing process used for the output from the crypto engine - does it still honour a strict priority queue, or does everything get lumped together in one FIFO queue, which would break the QoS prioritisation for the voice traffic. You may have to upgrade hardware or software to get the functionality you need.

Another issue relates to the anti-replay functionality within IPSec. To protect against Man-In-The-Middle attacks, IPSec will cause out-of-order packets to be dropped. The whole point of QoS when used with a strict priority queue for voice is to re-order packets to give voice precedence. As it happens, it’s likely that it’s the lower priority data traffic that will be re-ordered and so dropped, so it’s not a huge problem at present. But for now the only way to avoid this completely is to create two separate IPSec Security Associations (tunnels): one for voice and one for data, to keep one from affecting the other.

As long as you understand the restrictions, there is no reason why you can’t run voice over an IPSec environment, and people are doing it today. But trial it thoroughly and make sure you understand all the implications before you decide if it’s suitable for your business.