First, understand that there are a number of types of DoS attacks to which VoIP is vulnerable. One problem is generic bandwidth starvation attacks, which are likely targeting your network as a whole, not specifically your VOIP systems. Many of the recent worms/viri blast out such a huge amount of traffic that your WAN, to say nothing of your LAN, grinds to a halt. To stop this, obviously, you need to implement some of the usual defenses: Internet firewalls, and inbound and outbound access-control lists on screening routers. And, of course, keep your hosts patched and run anti-virus software. Duh.
Curiously though, you have likely already solved this problem in your LAN and WAN. That's because you probably deployed QoS prior to rolling out VOIP solutions to prevent your time-sensitive voice traffic from being overwhelmed by normal user traffic. It doesn't really matter whether it's web surfing or millions of ICMP packets, if your QoS is working, it should protect you from either.
The next type of DoS attack uses the control protocols. For example, miscreants can forge H.323 or SIP signaling packets that tell an endpoint to disconnect. Unfortunately, there is little you can do about this from a network perspective, as most of this traffic won't be passing through firewalls, and even if it is, your firewalls may not be able to distinguish between real and forged packets.
The solution then, is to configure authentication so that the voice applications know to whom they're talking. Although some the authentication mechanisms are likely vendor-specific at this time, because you may want to integrate it into your Active Directory or other LDAP, or perhaps a RADIUS server, the SIP protocol itself has a header used for authentication. As an example, Cisco's SIP-based IP Phones and SIP Proxy Servers support HTTP Digest and CHAP.
For details, read RFC 2543, section fourteen, which explains how SIP uses basic authentication, digest authentication (which uses MD5) and proxy authentication. These authentication methods are described in RFC 2617.
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.
