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 arent directly related to DSL, although its here that youre most likely to encounter them, but can appear anywhere youre running IPSec to connect your remote users.
If youre connecting a small remote office or homeworker back to your main office, its unlikely youre going to throw loads of bandwidth at them. Chances are youll be using dial-up or DSL if you cant justify a leased line, or if you need to provide for mobile users. In this case, theres every possibility that youll be insisting that they use IPSec to make sure your data is secure as it crosses over the public network.
Thats as it should be. But suppose youd 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.
Youre going to want to minimise the bandwidth used by the calls, so its probable youll configure up G.729 rather than G.711. But that will still require about 24kbps per call. If youve 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 youre pushed for bandwidth.
Except that this wont work over IPSec. Using IPSec means that the IP, UDP and RTP headers are encrypted before they get to the cRTP engine, so it cant 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, youre 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.
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 havent.
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, its likely that its the lower priority data traffic that will be re-ordered and so dropped, so its 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 cant 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 its suitable for your business.