Security

Voice and video traffic that you send over a WAN has unique security issues. For one thing, the traffic might be exposed to all the inherent dangers of the Internet. This is especially true for IP telephony services offered by Internet service providers (ISPs). Managed VoIP services are available in which the service provider owns and maintains the call control equipment. Another service allows companies to have just a WAN connection to an MPLS networkno local PSTN connections. All voice traffic is sent as VoIP to the provider network, where calls that are bound for the PSTN are split out from calls that are bound to a company site across the MPLS cloud. Both service providers and companies who use these services must be aware of security issues and cooperate to mitigate them. The tools that are covered in this section help with that.

For companies that manage their own VoIP network, another consideration is the security policies and devices on the network. Will the internal IP addresses be translated by Network Address Translation (NAT) as they exit the local network? Will voice traffic have to traverse a firewall? These are issues you do not normally face when using VoIP on a LAN.

Fortunately, because voice is carried over an IP network, you can use the same tools to protect it as you use to protect your data network. Firewalls, intrusion detection and prevention systems, encryption, authentication, replay protection, and voice-enabled VPNs all work together to provide a secure voice network. The Cisco firewall devices and Cisco IOS firewalls can look into the payload section of packets and recognize voice protocols. They can then maintain stateful information for voice connections. In addition, you should configure the firewall to allow only voice traffic into the voice portion of the network.

This section discusses four security areas that relate to voice gateways:

• Securing voice media and signaling
• V3PN
• NAT and VoIP
• Firewalls and VoIP

Securing Voice Media and Signaling

Consider the various types of voice traffic that are traversing your LAN and WAN if your network uses a centralized Cisco CallManager design.

• Real-Time Control Protocol (RTCP) voice control
• RTP voice media
• SCCP signaling between phones and CallManager
• MGCP, H.323, or SIP signaling between the gateway and CallManager, and between gateways

Cisco routers can encrypt RTP voice traffic between the gateway and IP phones, and between two gateways. They can also authenticate and encrypt their communications with Cisco CallManager. Encryption of voice media and control payload is done via SRTP. Encrypting communication with CallManager is accomplished by IPsec for MGCP and H.323 gateways, and by Transport Layer Security (TLS) for SIP gateways. Encryption of the signaling between CallManager or an SRST router and IP phones uses TLS.

Securing Voice Media with Secure RTP

Media encryption and authentication using SRTP are included for MGCP gateways in the Advanced IP Services and the Advanced Enterprise Services IOS software, beginning with version 12.3(11)T1. They are included for H.323 and IP-to-IP gateways beginning in Cisco IOS version 12.4(6)T. SRTP was designed just for IP voice (not video) packets, and it was standardized in RFC 3711. SRTP encrypts the RTP payload using Advanced Encryption Standard (AES) encryption. It does not encrypt the RTP header. You can use IPsec along with, or instead of, SRTP if you need header encryption. RTP header and payload contents are authenticated by the sender computing a one-way HMAC-SHA1 hash and placing the results in an authentication tag at the end of the packet. The receiver runs the same computation and compares its result to the contents of the authentication tag. If they do not match, the packet is dropped. SRTP also includes a replay protection process to avoid denial of service (DoS) attacks.

Most of the recent Cisco IP phones used with at least version 4.1 of Cisco CallManager can use SRTP to encrypt their signaling and voice traffic. By configuring both the phones and the gateways for encryption, you can have end-to-end security for your voice traffic. Encryption on the gateway also allows the encryption of voice traffic from analog phones and fax machines inside the network.

You must configure both the gateway and the CallManager to enable the capability for SRTP on the gateway. Negotiation of SRTP is part of the call setup process. All devices along the path must support it; otherwise, RTP is used (called SRTP-to-RTP fallback). After you negotiate encryption for a call, the encryption keys are sent over the signaling path, for use with the SRTP stream. Keys are sent clear text unless the signaling path is secured with IPsec (described in the next section).

To enable SRTP on an MGCP gateway, give the mgcp package-capability srtp-package command from global configuration mode. You must also configure the CallManager to support SRTP. After you negotiate encryption for a call, the CallManager sends an encryption key to the gateway for use with the SRTP stream. Configure IPsec protection for the encryption key exchange before enabling SRTP if the communication will traverse an untrusted network.

For H.323 gateways, you must configure a trunk from the gateway to CallManager. On the gateway, add the srtp [fallback] command under the dial peers that point to your CallManagers. The fallback option allows secure calls to fall back to unsecure when SRTP is not supported on the call path. Alternatively, this same command can be given under the voice service voip configuration mode. All VoIP calls then use SRTP. When you configure the trunk on CallManager, check the SRTP Allowed check box. CallManager tries to negotiate SRTP for any calls over that trunk. The H.323 gateway generates media encryption keys, which are passed to CallManager in the signaling path.

SIP gateways did not support SRTP media encryption at the time this book was written.

To enable SRTP on the IP phones and thus have end-to-end encryption, make sure that CallManager has the Certificate Trust List (CTL) client loaded. This allows for authentication between the phones and CallManager. Also verify that all the appropriate phones are set up for encrypted mode in CallManager. When a secure call is in progress, a lock icon is displayed on the phone.

Some caveats are involved in using encryption for voice traffic. One caveat is that it makes the packets a little larger. SRTP adds from 4 to 10 bytes to each packet for an authentication tag. Encryption is not used for Music on Hold (MoH) or conferencing. It only supports G.711 and G.729 codecs. When you use G.711, the number of calls supported per c5510 DSP drops from 16 to 10. The number does not change for G.729it is still 6 for G.729 and 8 for G.729A. When you are using modules with c549 and c5421 DSPs, such as the NM-HDV and AIM-VOICE-30 modules, SRTP supports only two calls per DSP.

By default, SRTP does not operate when the gateway is in SRST mode. However, you can configure the gateway and CallManager to support Secure SRST, which uses SRTP. Detailed instructions for configuring Secure SRST can be found in Chapter 13, "SRST and MGCP Gateway Fallback."

Securing Voice Signaling with IPsec

Encrypting the signaling traffic between CallManager and its gateways is optional but highly recommended in a secure environment. If you are encrypting the media and control traffic, it makes sense to protect signaling traffic also. Otherwise, such things as passwords, dual tone multifrequency (DTMF) tones, call setup signals, and encryption keys are sent across the network in the clear. You can protect signaling traffic by using IPsec with MGCP and H.323 gateways. TLS is used for SIP gateways.

You can configure IPsec encryption between the gateway and the CallManager server; you might do this if you need to secure signaling on a LAN, but it is not recommended if the gateway is at a remote site across the WAN. For remote sites, a more scalable solution is to configure an IPsec tunnel between the gateway and another device in the trusted network, such as a firewall or VPN concentrator. Terminating the connection on a firewall means that the tunnel will not drop if a CallManager goes out of service. It also allows the firewall to examine and perhaps manipulate the traffic. IPsec configuration varies depending on the firewall, gateway, or concentrator used, and it is beyond the scope of this book. Go to Cisco.com for information on configuring it for Cisco devices.

If you decide to use IPsec between the gateway and CallManager, you must set up an IPsec association between the two. See the Cisco IP Telephony Platform Administration Guide at Cisco.com for information on configuring CallManager.

Securing Voice Signaling with TLS

SIP trunks use TLS to secure the call setup and teardown signaling sent over them. TLS is a protocol that provides authentication and encryption of the SIP signaling data.

When configuring the SIP trunk in CallManager, you must configure a trunk security profile. Select TLS as both the Incoming and Outgoing Transport Type, and then select Encrypted as the Device Security Mode. Apply the profile to the trunk. The security negotiation and key exchange are done in the clear, so be sure to secure that communication using IPsec if it will go over an untrusted network.

You must configure the gateway to use TLS for its communication with CallManager (or other SIP endpoints that support TLS). First, configure the use of the public key infrastructure (PKI) certificate management. This requires generating a key pair, configuring a PKI trustpoint, and enrolling the trustpoint with a CA. This configuration is beyond the scope of this book; see the Cisco IOS Security Configuration Guide at Cisco.com for detailed instructions. After that configuration is complete, configure the gateway to use TLS. If both the gateway and CallManager share the same CA, configure the gateway to use the trustpoint when initiating or accepting TLS connections. In sip-ua configuration mode, use the cypto signaling [(remote-addr (ipv4:address | dns:hostname) default] trustpoint string [strict-cipher] command, where

• remote-addr ipv4:address Lists an IP address for the trustpoint
• remote-addr dns:hostname Lists a DNS name for the trustpoint
• default Tells the router to use this trustpoint as the default one
• trustpoint string Lists the name of the certificate generated during PKI enrollment
• strict-cipher Configures the gateway to use only TLS_RSA_with_AES_128_CBC_SHA

In addition, configure the gateway to use TLS as its transport method. This is shown in Example 8-27, along with the trustpoint configuration.

V3PN

When you use SRTP, the IP phones and CallManagers participate in encrypting voice traffic. Another option is to use a voice and video-enabled VPN, or V3PN. When you set up a V3PN, the encryption is transparent to the end devices, including CallManager. Encryption is not end to end, however. It is just over the WAN, between the two ends of the VPN tunnel.

To use V3PN, site-to-site VPN tunnels are created between the voice gateways in each site. This is typical in a hub-and-spoke design, with the hub being the location of the CallManager. After the tunnels are up, you can send voice, video, and signaling traffic over them. SRTP traffic can also traverse a V3VPN. V3PN provides security for voice where it is the most vulnerablein the Internet.

You can use IPsec in Transport or Tunnel mode, use it to encrypt a GRE tunnel, or use it just by itself. If you plan to send only IP unicast traffic over the VPN, and no multicast video or routing protocols, a straight IPsec tunnel (with no Generic Routing Encapsulation [GRE]) is sufficient. Only IP unicast traffic is then encrypted. This implementation uses fewer router resources and a smaller header but requires static routing. If you plan to carry multicast video or routing protocols over the VPN, use IPsec in tunnel mode to encrypt a GRE tunnel. This has a larger header and more resource overhead than the first option, but it allows more flexibility in the traffic it carries.

Note

For further details on designing and configuring V3PNs, see the Solution Reference Network Design Guide at http://www.cisco.com/go/srnd.

NAT and VoIP

Typical NAT does its translation based on the IP addresses in the Layer 3 header and the port numbers in the Layer 4 header. This is usually enough to identify a stream of traffic. One problem with some of the voice protocols is that they include essential information in the packet payload; thus, NAT does not see it. For instance, H.323 RAS might include an IP address in the message body when a device is registering with a gatekeeper or seeking another registered device. You must translate that address, in addition to the Layer 3 addresses. SIP and its SDP send IP addresses embedded in the packet payload. Traditional NAT and even Port Address Translation (PAT) would never see these addresses.

To solve this limitation, Cisco has an Application Layer Gateway (ALG) feature that looks inside the packets to be translated and finds embedded IP addresses. Then it can translate them properly. ALG can handle all H.323 message types, SIP messages, SCCP, and even Real Time Streaming Protocol (RTSP). Support for these protocols in the Cisco IOS has developed over time, but all are supported as of version 12.3(7)T.

You can change the port that SCCP uses if another application in your network is already using that port. If the port is already occupied, you must tell NAT the new port number. NAT on Cisco routers assumes that traffic bound to TCP port 2000 is SCCP traffic, and it uses ALG to look for embedded information. Use the following command at global configuration mode to change the port that NAT associates with SCCP:

ip nat service skinny tcp port port-number

Configure static translations for the CallManager and Unity server addresses, because you need to specify their IP addresses in the TFTP download. Alternatively, you can use Domain Name System (DNS) to resolve the IP addresses of these servers.

Firewalls and VoIP

Cisco firewall devices and Cisco IOS firewalls can look inside the payload, or data, portion of a packet to recognize voice protocols and identify voice sessions. They can maintain stateful information even when the protocols are using dynamically negotiated ports, such as with RTP. In addition, you should configure your firewalls to allow only voice traffic onto the voice network.

Voice has various protocols that it might use. RTP and RTCP together use a range of more than 16,000 UDP ports. Other protocols, such as H.323, SCCP, SIP, and MGCP, can be used in the voice network. Table 8-1, earlier in this chapter, shows the ports that the most common voice protocols use. If these protocols must traverse the WAN, the firewall must allow the appropriate ports.

Although not every network will use every port, that is still potentially a lot of ports to have open in a firewall. Your network security administrator might prefer voice to be sent over an IPsec tunnel, as already outlined in the "V3PN" section of this chapter. When you do that, only ports that support the tunnel need to be opened. This has the added benefit of encrypting the voice traffic, preventing anyone who is capturing packets from listening to your phone calls.

Termination of the IPsec connection, when using V3PN or SRTP, affects the ability of a firewall to protect the network.

• If the IPsec tunnel terminates on one of the CallManagers, or on a VPN concentrator placed on the LAN side of the firewall, the firewall will only see IPsec traffic. It will not decrypt or look further into the packets. Thus, it will not recognize that this is voice traffic. If the firewall is also performing NAT, the embedded IP addresses will not be translated properly. If the remote voice gateway has been compromised and is sending malicious data, the firewall will not see it. This solution also does not scale well in large VoIP deployments. A benefit to terminating on the CallManager is that the traffic is protected as it travels on the LAN.
• If the IPsec connection terminates on a VPN concentrator that is placed on the WAN side of the firewall, the packet will be decrypted and the original packet will be sent to the firewall. It will be recognized as voice traffic, and any inspection or filtering rules will be applied. NAT can be done on the embedded IP addresses, and internal session information can be recognized.
• If the IPsec tunnel terminates on the firewall, the firewall will decrypt the traffic and apply any necessary rules to it. The firewall can look into the data portion of the packet and take appropriate action based on its contents.

Keeping these considerations in mind when designing your network is important, especially if you plan to secure voice traffic carried over the WAN.