A multitude of security technologies have been discussed in this book, and many features specific to Cisco equipment were highlighted. This chapter pulls all of the information together and provides comprehensive design considerations and examples for securing VPN, wireless, and Voice over IP (VoIP) networks when using Cisco-based equipment for your network infrastructures. Specific configurations are not shown because the products to implement the designs vary greatly and have different syntax depending on the products and software versions used. However, references for relevant commands and detailed configuration examples are provided to simplify searching through the Cisco website. Security technologies and features for both wireless networks and VoIP networks are still under development, and the considerations for securing these types of networks in a Cisco-based environment are detailed as much as possible given the information available at the time of this writing.
The security technologies used to create virtual private networks (VPNs) were discussed in Chapter 3, “Applying Security Technologies to Real Networks.” VPNs are used to establish secure, end-to-end private network connections over a public network infrastructure. VPNs are not by nature secure. Take, for example, Multiprotocol Label Switching (MPLS) VPNs, which are gaining deployment momentum. MPLS VPN-based services are starting to replace some of the more traditional Layer 2 VPNs, such as ATM or Frame Relay networks. Although security is mainly touted through the use of address and routing separation and the hiding of core infrastructure and network topology, MPLS VPNs and other Layer 2 VPN scenarios should not be thought of as secure. MPLS itself does not provide encryption, integrity, or authentication services. If these features are required, IPsec should be used over the MPLS infrastructure, firewalls should be deployed between different VPNs, and neighbor authentication should be deployed between peer routers. A detailed description of MPLS is beyond the scope of this book. However, for readers who want to deploy MPLS VPNs and are looking for more detailed information regarding MPLS networks, refer MPLS and VPN Architectures, Volume II (Cisco Press, 2003). For detailed security considerations specific to MPLS networks, refer to the white paper titled “Security of the MPLS Architecture” at http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/mxinf_ds.htm.
For any VPN, only after the appropriate security controls have been put into place can you state that you have a secured VPN. Chapter 11, “Securing Remote Dial-In Access,” covers securing remote dial-in environments, which the savvy reader has recognized as being part of an access VPN. Access VPNs can impose security over the analog, dial, ISDN, digital subscriber line (DSL), mobile IP, and cable technologies that connect mobile users, telecommuters, and branch offices. In this section, some more complex scenarios are shown, including the use of Network Address Translation (NAT) and IPsec with legacy user authentication mechanisms.
The design methodology for creating secure VPNs is in large parts constrained by the security policy. Before any network can be designed or configured, you need to understand what you are trying to protect and from what. Let's start by looking at a typical corporate VPN requirement that consists of three parts: a remote-access VPN for telecommuters and traveling corporate personnel, an intranet VPN to interconnect the branch office and corporate headquarters, and an extranet VPN to connect any third-party manufacturer or corporate partner to the corporate network.
The questions that first need to be asked are similar to the ones that someone would ask regarding a basic security policy because the VPN policy is close to, if not the same as, the corporate security policy. The corporate security policy should be reviewed to determine whether there any special considerations and modifications are needed for VPN users. The answers to the following questions need to be determined:
What do I want to authenticate, devices or users or both?
Will specific application access be authenticated? (Which ones?)
Will there be restrictions on what a specific authenticated entity will have access to?
How will access control be provided?
What communication should be kept confidential?
What are the origin and destination points for confidentiality? (That is, will the communication be kept confidential from sender to recipient or will there be intermediary encryption/decryption points?)
How will confidentiality be provided?
How many different users will need to be supported?
Will there be any requirement to use private addresses and therefore NAT?
Are there any routing considerations?
How critical is it for the VPN to be available all the time? (That is, are short downtimes acceptable?)
Where are potential points of infrastructure attacks?
After the answers to these questions are ascertained, the next set of questions can be tackled:
What technology do I use to authenticate the devices, users, applications?
What technologies are under potential consideration for other security services?
How difficult is the configuration of a particular technology?
What are the maintenance and management issues?
Are there multiple mechanisms that may accomplish similar security services?
What are the security versus usability and implementation trade-offs?
You want to make sure that the mechanisms you put in place are effective from an administrative point of view versus the trade-off in security that they provide.
Let's look at the potential answers and how they will affect the VPN design.
Identity in this book has coupled together the functions of authentication and access control. The following sections consider them individually because not all authentication is always coupled with access control—the situations in which this may be the case are pointed out.
The decisions on how to implement authentication mechanisms depend first on what you want to authenticate followed by how the authentication will be provided—that is, which technology will be used.
For most VPN networks, there needs to be a combination of entities that need to be authenticated. These include devices and individual users:
Device authentication—. Devices will always be authenticated because all VPN-related security protocols were designed with the inherent belief that devices need to be authenticated.
User authentication for network access—. In earlier VPN deployments, it was common to only authenticate devices, mostly because in many situations there weren't any capabilities in products to support an additional user authentication mechanism. If user authentication was supported, the functionality was hard to maintain and control. This has drastically changed in recent years as more and more VPNs are being deployed for remote user access, where authentication of the user is a critical component before any network access is granted.
User authentication for application access—. Some companies have specialized applications that are restricted and require user authentication. The most common application that requires user authentication is the World Wide Web.
NOTE
In the remaining sections of this chapter, any reference to the term user authentication refers to user authentication for network access, and any reference to the term application authentication refers to user authentication for application access.
Most VPNs, whether access, intranet, or extranet use some mechanism of device authentication because the functionality is an inherent part of all security-related protocols such as Layer 2 Tunnel Protocol (L2TP), IPsec, or Transport Layer Security (TLS). Access VPNs, where a remote user is trying to gain access to corporate resources, should always require that both the device and the individual user be authenticated. By standardizing on this policy, it will make it easier to do access control. For intranet VPNs, where the network is a logical extension of the corporate environment, user authentication is not always required.
If all users first need to authenticate before gaining access to any corporate resource, it may not be necessary to authenticate users again when they access particular applications. The biggest problem in requiring a user to authenticate twice is the issue of a user having to enter his or her credentials multiple times, which isn't usually an acceptable procedure. This problem of double authentication has been recognized as being a hindrance for deploying effective VPNs in environments where there is a critical need to also authenticate critical application access. Many products now support automated mechanisms such that the user only has to enter his or her credentials once. Therefore, if you have specific restricted applications that also require authentication, you should have a policy that requires both user and application authentication.
A matrix of what to authenticate and recommendations as to where the authentication will prove useful is shown in Table 12-1.
There exist numerous technologies for authentication. Chapter 2, “Security Technologies,” discussed the technical details of many mechanisms, and this chapter attempts to give some reasonable consideration options. The choice will depend on administration tasks versus the security the technologies provide.
For underlying communication protocols that require devices to authenticate each other, the features usually have a variety of mechanisms that can be used. Devices typically use their IP address or host name in conjunction with a credential to authenticate to each other. The following list identifies the typical credential forms:
Statically configured password—. A statically configured password is easy to configure but hard to maintain in a scalable manner. Even if AAA mechanisms can be used, there is the added task of modifying this password on a regular basis and redistributing it to all necessary devices. It is also not very secure if a statically configured password is sent in the clear and any mechanism that sends its password in the clear should be avoided (such as Password Authentication Protocol [PAP] authentication). Many protocols that use a statically configured password for its credential will use some sort of encryption technology to protect the password in transit, usually MD5 or SHA-1. If multiple devices require the same password to be configured, it is essentially a shared group key, which causes security risks if the key is compromised. A unique shared password (key) should be configured between each communication device, and they should be changed on a regular basis.
Public key cryptography—. This requires the use of public key encryption where a public/private key pair is generated and the private key is used to encrypt a credential known to both devices. For IPsec, this is the encrypted nonce device authentication. New public/private keys can be generated automatically in a user configurable timeframe. This automates the task of providing new secure credentials but also takes up device CPU cycles. The longer the key used, because many times the key length is also a consideration, the more CPU resources are taken. This method is more secure than a statically configured password, and even if short keys are used, this is a good middle ground.
Digital signatures—. This mechanism also uses public key encryption and requires the use of a public key infrastructure to exchange digital certificates. The digital certificates are used to securely exchange the public keys. Public Key Infrastructure (PKI) is not yet widely deployed due to the complexity of setting up the infrastructure and some technology hurdles that are still in the process of getting resolved. The main issue is how to bootstrap the system and initially enroll the public keys into a secure certificate authority (CA). Some vendors have proprietary mechanisms to make this process easier. Digital certificates provide the most scalable mechanism for device authentication, and larger corporations should look to deploy this method.
Kerberos authentication—. This requires the use of a Kerberos infrastructure where clients are members of a single trusted domain or mutually trusted domains. If an existing Kerberos infrastructure exists, this method of authentication can be easily incorporated as part of a VPN device authentication method. For corporations that do not have an existing Kerberos infrastructure, deploying a PKI infrastructure rather than Kerberos proves more useful because more vendors are supporting digital certificate-based authentication.
The L2TP protocol by itself only has simplistic device authentication via a Challenge Handshake Authentication Protocol (CHAP)-like protocol that requires a preconfigured shared password between the L2TP endpoints. When used with IPsec, however, the devices use more extensive authentication mechanisms, which usually include preshared keys, public key technology, or digital signatures. A few vendors also use Kerberos-based device authentication for IPsec, but it is not required in the standard and may cause interoperability problems in multivendor situations.
Many deployments use a preshared key because it is easy to configure and has in the past been the most interoperable IPsec device authentication method. It is an acceptable method for small corporations but does not necessarily provide strong device authentication. A preshared secret is problematic in larger environments if a shared group key is used and many entities share the same key. This causes severe security ramifications if the key is compromised. Using an encrypted nonce with public key cryptography is a more secure solution and is the one that Cisco IPsec implementations use as a default (using RSA signatures).
Digital signature-based authentication is the most scalable device authentication mechanism and should be seriously considered in large VPN deployments. What is large can be quite subjective, but I consider more than 30 devices a good candidate for digital, signature-based device authentication. Digital certificates are tied to unique, signed information on the device that is validated by the enterprise's CA. If a device is compromised, the certificate can be revoked and is added to a certificate revocation list (CRL). When using digital, signature-based authentication, CRL checking should always be used. On Cisco devices, it is a configurable parameter and not turned on by default. Cisco has a certificate enrollment protocol (the Simple Certificate Enrollment Protocol [SCEP]) that simplifies the certificate enrollment and renewal process. In addition, many CA vendors support web-based PKI enrollment services.
You can access a number of useful documents on the Cisco website that describe VPN device authentication features and configuration details:
Step-by-step instructions on how to configure the Cisco VPN 3000 series concentrators to authenticate using digital certificates can be found at http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_configuration_example09186a00800946f1.shtml.
A document that describes how to configure Cisco IOS CA interoperability, which is provided in support of the IP Security (IPsec) protocol, can be found at http://www.cisco.com/en/US/products/sw/iosswrel/ps1835products_configuration_guide_chapter09186a00800ca7b2.html.
The manual certificate enrollment (TFTP and Cut-and-Paste) feature enables users to generate a certificate request and accept CA certificates as well as the router's certificates; these tasks are accomplished via a TFTP server or manual cut-and-paste operations. You can find this feature description at http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bd1.html.
The certificate auto-enrollment feature enables you to configure your router to automatically request a certificate from the CA that is using the parameters in the configuration. Before the certificate auto-enrollment feature, certificate enrollment required complicated, interactive commands that had to be executed on every router. This feature enables you to preload all the necessary information into the configuration and cause each router to obtain certificates automatically when it is booted. You can find this feature description at http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087cc2.html.
A document that demonstrates the use of enhanced certificate auto-enrollment commands can be found at http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00801405ac.shtml. These commands provide new options for certificate requests and enable users to specify fields in the configuration instead of having to go through prompts. However, the prompting behavior remains the default if this feature is not enabled. Users can preload all necessary information into the configuration, allowing each router to obtain its certificate automatically when it is booted.
The trusted root certification authority feature allows a router to be configured with multiple root CAs that it trusts. Therefore, the router can use a configured root CA (a trusted root) to verify certificates offered by a peer that were not issued by the same CA defined in the identity of the router. When a trusted root is configured in a router, the router does not have to enroll with the CA that issued the certificate to the peer. You can find more information on this feature at http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/products_feature_guide09186a008007fecf.html.
The exporting and importing RSA keys feature enables you to transfer security credentials between devices by exporting and importing RSA keys. The key pair that is shared between two devices will allow one device to immediately and transparently take over the functionality of the other router. The feature is described in greater detail at http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00801541cf.html.
A document that describes how to configure CA interoperability for a PIX firewall can be found at http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_user_guide_chapter09186a00801aed7a.html.
A document that describes configuring Kerberos can be found at http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca7ad.html.
Two important issues that need to be considered are dynamic addressing through the use of Dynamic Host Configuration Protocol (DHCP) and private addresses using NAT. Because most device authentication is done using an IP address, if the IP addresses change, this can be problematic and additional considerations need to be taken into account.
For environments with DHCP addressing, a specific pool of addresses should be allocated for VPN devices. This will greatly simplify access control issues and authentication issues for devices that use IP addresses for identification. In addition, more recent IPsec implementations incorporate the extensions that allow an IP address to be assigned to a remote client and use two addresses; the one from the VPN gateway is the source address for packets it inserts into the IPsec tunnel, and the one from the ISP is the source for the tunnel itself. Cisco devices use the mode configuration extension, which was discussed in Chapter 2.
In NAT environments, whether IPsec is used before or after NAT is important. The IPsec NAT Traversal extension provides a solution for IKE and Encapsulating Security Payload (ESP) UDP encapsulation for passing IPsec ESP transport or tunneled traffic across NATs that exist between the IPsec peers. It is not a solution when using NAT for traffic from a remote private address after IPsec encapsulation. Generally, one should do NAT followed by IPsec on outbound traffic and reverse the process on the receiving end. When using NAT before IPsec, the addresses should be mapped into a unique address range that will not interfere with IPsec tunnel establishment. In addition, application protocol-aware devices should be used to perform the NAT translation to ensure that the address translation is also carried out in the data portion of the packet for protocols that embed IP addresses in the data portion.
Cisco IOS Software features that prove useful in NAT VPN environments include the following:
The IPsec NAT Transparency feature, which introduces support for IPsec traffic to travel through NAT or Port Address Translation (PAT) points in the network. The feature was introduced in 12.2(13)T. You can find the command reference here:
http://cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bca.html
The NAT Support for IPsec ESP—Phase II feature allows multiple concurrent IPsec ESP tunnels or connections through a Cisco IOS NAT device configured in PAT mode. This feature can be used only if both VPN endpoints are Cisco devices running Cisco IOS Software Release 12.2(15)T or later. You can find the command reference here:
http://cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00801541de.html
User authentication refers to what individual users will use to identify themselves and what credentials they will supply. The credential typically associated with the authenticator's identity can be a static password, one-time password, Kerberos token, or public key. Static passwords should be avoided because they are the most insecure method of providing a user credential. A one-time password mechanism is the minimum form in which user authentication should be performed for any VPN environment. L2TP/IPsec VPNs can authenticate both machine and user independently. First an IPsec tunnel is established (Microsoft uses a machine certificate if it exists and negotiates Internet Key Exchange (IKE) tunnels with machine certificates) followed by the L2TP control channel setup. User authentication is done using PPP authentication methods during establishment of the L2TP control channel. All other L2TP traffic is protected using the IPsec security association (SA). The L2TP user authentication support for legacy authentication is flexible enough to support many existing authentication methods via EAP, which preserves any existing authentication infrastructures. The following document provides a sample configuration for L2TP authentication with RADIUS:
For VPNs that don't require L2TP but use IPsec, the issue to look out for with user authentication is interoperability, because not all vendors support the same user authentication mechanisms. However, the IPsec Xauth extension is widely supported by many vendors even though the draft document itself expired and never reached standard status. The following references show varying configuration examples for user authentication based on Xauth:
A document that describes how to configure a host-to-router easy VPN solution based on the Cisco VPN client and Cisco IOS remote-access server. Xauth is used to identify the user who requests the IPsec connection. http://www.cisco.com/en/US/netsol/ns110/ns170/ns171/ns27/networking_solutions_white_paper09186a00801890e4.shtml
A document that describes how to configure a router-to-router easy VPN solution based on the Cisco IOS easy VPN client and Cisco IOS remote-access server features. The Cisco easy VPN negotiates tunnel parameters and establishes IPsec tunnels. Xauth adds another level of authentication that identifies the user who requests the IPsec connection. http://www.cisco.com/en/US/netsol/ns110/ns170/ns171/ns27/networking_solutions_white_paper09186a0080189111.shtml
Examples that show how to configure interoperability between a PIX firewall and PIX firewall-supported VPN clients. http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_user_guide_chapter09186a0080106f8b.html
A document that shows sample configurations for TACACS+ and RADIUS used with Xauth. http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_configuration_example09186a0080094848.shtml
Note that the 802.1x wireless community has added user password-based authentication inside a VPN server-authenticated TLS session (EAP-TLS). User authentication is done using user ID/password via CHAP, PAP, MSCHAP, MSCHAPv2, and so on, and using EAP-TLS (RFC 2716), which provides certificate user authentication, either using smart cards or certificates in the user's account on a disk. The following three references describe how to configure IEEE 802.1x port-based authentication on the Catalyst 2940 switch, Catalyst 4000 series switches, and Catalyst 6500 series switches, respectively:
Application authentication mechanisms can vary greatly, but in many networking environments they are based on username and password. The following features that provide application authentication should be considered when using Cisco-based equipment:
The Cisco IOS ip auth-proxy command is used to enable a named authentication proxy rule at the Cisco IOS firewall interface. Traffic passing through the interface from hosts with an IP address matching the standard access list and protocol type (HTTP) is intercepted for authentication if no corresponding authentication cache entry exists. If no access list is defined, the authentication proxy intercepts traffic from all hosts whose connection initiating packets are received at the configured interface. The command reference can be found at http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a008017cf1a.html#1069569.
The ip auth-proxy command was enhanced in Cisco IOS Software Release 12.3(1) to include a firewall authentication proxy for FTP and Telnet access. Authentication proxy for FTP and Telnet sessions functions like authentication proxy for HTTP; that is, FTP and Telnet are independent components in the Cisco IOS Software and can be enabled or disabled on the interface of an unauthenticated host. A comprehensive document that describes the feature and configuration steps can be found at http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_feature_guide09186a00801b0683.html.
The Cisco IOS ip trigger-authentication command is used to enable automated double authentication for a device. The command reference can be found at http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_chapter09186a008017cf1b.html#1069489. A comprehensive document for configuring automated double authentication can be found at http://www.cisco.com/en/US/products/sw/iosswrel/ps1826/products_feature_guide09186a00800d9df4.html.
The PIX firewall provides the virtual http command that redirects the browser's initial connection to another IP address, authenticates the user, and then redirects the browser back to the URL that the user originally requested. The virtual telnet command allows the Virtual Telnet server to provide a way to pre-authenticate users who require connections through the PIX firewall using services or protocols that do not support authentication. The command reference for these commands can be found at http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_command_reference_chapter09186a0080104256.html#1037665.
Authentication is by far one of the most critical aspects of a secure network infrastructure. As such, it is important to understand all the subtle nuances when using a particular authentication mechanism.
When considering using L2TP with IPsec as a VPN tunneling solution, you need to carefully consider what is being authenticated. Although PPP provides initial authentication, it does not provide per-packet authentication. With IPsec, when the asserted identity in IKE is authenticated, the resulting derived keys are used to provide per-packet authentication and as a result the identity verified in the IKE conversation is subsequently verified on receipt of each packet.
If PPP uses user identity but IKE uses machine identity, only the machine identity is verified on a packet-by-packet basis and there is no way to verify that only the user authenticated within PPP is using the tunnel. Any user on a multi-user machine will be able to send traffic down the tunnel. If IPsec also uses user authentication, the problem goes away and provides segregation of traffic between users.
Certificate credentials, when used, must be adequately managed. Both machine certificate enrollment and user certificate enrollment should be strictly controlled. For user certificates, if a username/password is used by individuals to obtain a certificate, the security is as valuable as the password. Therefore, it is also useful to limit the user certificate enrollment time. This will prevent an attacker obtaining the password of an unused account and obtaining a user certificate after the enrollment process has expired.
Table 12-2 summarizes the authentication methods available for the VPN protocols that are to be considered.
After an entity has been authenticated, restrictions may apply as to which parts of the network or which applications the entity may access.
Access control is necessary to protect the resources that are critical, and the decision needs to be made to determine what resources are open for whom. VPNs that are a logical extension to the corporate network may sufficiently trust the authenticated entity such that all corporate resources are available to them. A major consideration is how likely is it that the authenticated entity is an imposter. If very secure authentication mechanisms are used, the likelihood is lessened. However, impersonation is always a possibility, and a risk assessment is crucial in the event that imposters were successfully authenticated. What potential damage could they cause to the network? In many situations, it is best to restrict access from any VPN to specific network subnets to which the necessary network resources that need to be accessed are connected to. Perimeter network points should always be the point where access control is applied. This is the demarcation point between a trusted and an untrusted network. In addition, internal security instances are continuing to be a large issue and access control mechanisms are needed inside the trusted network. This can require a secondary authentication mechanism once inside the trusted network.
Allowing any VPN traffic through a corporate perimeter network firewall is a serious consideration. Chapter 10, “Securing Internet Access,” discussed a number of firewall scenarios, the most effective being a combination of a screening router and stateful firewall. If VPN traffic is defined to be end-to-end between devices, firewalls will need to allow the tunneled traffic through without performing any stateful inspection. This could be reasonable if the VPN is an extension of the corporate network and there is greater trust in the participants of the VPN. In many extranet and remote-access VPN scenarios, however, a design where a VPN concentrator is deployed between a perimeter screening router and a stateful firewall should be considered. This will allow the VPN concentrator to decrypt any incoming traffic, which will then traverse the stateful firewall to ensure that any corporate firewall policy is not bypassed.
Access control can be provided by using filters at perimeter devices that can include any of the following parameters: MAC source address, MAC destination address, IP source address, IP destination address, protocol type, protocol source port number, and protocol destination port number.
When filtering, the following are some guidelines to adhere to:
Allow only users on specific subnets to specified corporate subnets.
Use port number filtering to allow specific VPN tunnel traffic.
Table 12-3 lists the more common protocols and port numbers that should be allowed through a network perimeter firewall device.
IPsec traffic selectors are defined by access lists. The granularity of these access lists will depend largely on what traffic is protected by the VPN. In some cases, the VPN protects specific subnets; in others, it may protect certain hosts and specific applications. This is very much site dependent.
NOTE
It is important to understand how addresses and port numbers are used in your VPN. IP addresses and port numbers may change during L2TP tunnel negotiation to accommodate load balancing and quality of service (QoS). In addition, IPsec tunnel mode may cause IP addresses to change. Be careful when constructing your filters to make sure you use the appropriate IP addresses and port numbers.
Access control can also be applied using the authorization function of a AAA server, as discussed in Chapter 11, “Securing Remote Access.” This proves a useful function in environments where it is a requirement to restrict access to network devices or applications per individually authenticated users.
In very small corporations, it may be easy to manage passwords and access control by individually configuring every device. As the VPN gets beyond 5 devices and 20 users, however, it can be difficult to effectively manage these functions. AAA functionality provides a scalable mechanism to keep track of passwords and authorization attempts.
More recent developments have added access control via the use of digital certificates. Under the IPsec protocol, CA interoperability permits Cisco IOS devices and a CA to communicate so that the Cisco IOS device can obtain and use digital certificates from the CA. Certificates contain several fields that are used to determine whether a device or user is authorized to perform a specified action. For Cisco IOS devices, the certificate security attribute-based access control feature adds fields to the certificate that allow specifying an access control list, to create a certificate-based access control list. You can find a description of this feature at http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00801541ce.html.
Integrity in this context pertains to having traffic be verified that it hasn't been modified in transit and is origin authenticated. IPsec inherently provides this capability. The problem is that environments with NAT will cause a problem if IP addresses are included in the integrity check and usually mechanisms are used where the IP addresses are not part of the integrity check computation. In IPsec, for instance, Authentication Header (AH) is hardly ever used for the integrity check. Instead, ESP is used with MD5 or SHA1, which provides an integrity check on the packet and most of the original header but not the outer IP header when tunnel mode is used.
If an IP address is spoofed for VPN-type traffic, typically the traffic can cause only a limited denial-of-service (DoS) attack and take up limited resources. In many cases, the IP address is assumed to be trusted and other mechanisms are used to protect against potential DoS attacks.
Secure VPNs almost always require that some of the data be encrypted. You need to be selective as to the traffic to be encrypted only if there is a severe constraint in processing power. It is common to either encrypt all traffic going to a specific destination or to encrypt only certain application traffic. IPsec ESP is generally used to encrypt traffic. L2TP can use PPP encryption, but it is a weak form of encryption, and L2TP is therefore most often used in conjunction with IPsec when confidentiality services are required.
NOTE
In some cases, it may be required to modify the maximum transmission unit (MTU) on the PC/host side to avoid receiving devices perceiving the packets as oversized. If this is necessary, adjust the total maximum size that the packet can take so that it does not exceed the normal size of a nonencrypted Ethernet packet (1400 bytes). VPN applications typically provides the option of customizing the MTU size.
The devices that you must configure for IPsec or L2TP/IPsec in a VPN network infrastructure include the Cisco IOS routers, PIX firewall, VPN concentrators, and IPsec clients. The following web pages show numerous configuration examples for a variety of IPsec and L2TP/IPsec scenarios using user-based authentication, digital certificate authentication, and multiple combinations of devices:
VPNs have the same requirement as any other network, which is minimal downtime. Availability refers to having redundancy in place as well as having the capability to forward packets in the event of an attack. How much redundancy is in place depends on the decisions made when a risk assessment was done—remember that it is sometimes not necessary to overly protect network devices or information when the cost of protecting it far exceeds the cost of what the information is worth. Smaller corporations will probably not have the monetary resources to buy redundant devices, but larger corporations should definitely deploy redundancy in all critical VPN infrastructures. For any redundant configurations, the features should be enabled that provide for automated failover scenarios in the event of a link or device failure.
An auditing function is necessary to determine that the VPN has been appropriately configured. If encrypted traffic is being used, don't just rely on a device counter to show that traffic is being encrypted. Put an actual traffic analyzer on the network to verify that the traffic is indeed confidential and that anyone inadvertently sniffing the network can't see the traffic. A network intrusion detection system should be used at the network perimeter points to detect a potential attack to the corporate network at the earliest possible moment.
Intrusion detection was discussed extensively in Chapter 10, and you should refer to that chapter for specific configuration details. In addition, Cisco IOS Software has an IPsec VPN accounting feature, introduced in Release 12.2(15)T, which allows for a session to be accounted for by indicating when the session starts and when it stops. A VPN session is defined as an IKE SA and the one or more SA pairs that are created by the IKE SA. The session starts when the first IPsec SA pair is created and stops when all IPsec SAs are deleted. Session-identifying information and session-usage information is passed to the Remote Authentication Dial-In User Service (RADIUS) server via standard RADIUS attributes and vendor-specific attributes (VSAs). You can find more specific information about this feature at the following website:
It can also prove useful to audit your VPN networks using freely or commercially available software to emulate some common attacks and to verify that your VPN infrastructure is indeed secure from at least the more commonly known exploits.
This section shows two common designs. The first scenario is shown in Figure 12-1 and is for a small corporate VPN that has a remote branch office as well as a number of telecommuters and traveling personnel who will access the corporate network. Therefore, the VPN is a mixture of an access VPN and intranet VPN. Device authentication is performed using preshared keys for Ipsec, and remote users are individually authenticated using the IPsec Xauth extension and one-time passwords. A Cisco IOS router is used as the VPN firewall, which is also an IPsec peer. The router is also used as a network intrusion system to audit any incoming traffic and provide first-level defense against any potential network attacks.
The second example is for a larger corporation that has a number of remote offices and telecommuters as well as corporate personnel who travel and need access back to the corporate resources. In addition. a number of third-party places need access back to the corporate network. Figure 12-2 shows this scenario. Device authentication in this scenario is via digital certificates, and remote user authentication is performed using one-time passwords and the IPsec Xauth extension. At the perimeter, a screening router is used to perform access list checks. The VPN termination point is at the VPN concentrator, which acts as an IPsec peer. All traffic is subsequently passed to the stateful firewall before being allowed to pass to the corporate network. An important point here is that access lists configured on the screening router may potentially check different IP addresses than the filters on the stateful firewall because the screening router may be using tunnel mode. A network-based intrusion system is also used to audit any incoming traffic and to provide first-level defense against any potential network attacks.
To deploy secure wireless networks, you need to apply the same kind of design methodology as for VPN networks. In many cases, the wireless networks are actually part of a remote-access VPN. The following sections do not repeat any of the previous discussion relating to VPNs, and only the features and configuration examples relevant to wireless network access are referenced. Therefore, use this section as an extension of the previous VPN discussion.
Identity considerations for wireless LANs also encompass both authentication and access control functionality. The 802.1x standard, which uses EAP for authentication, is gaining wide acceptance and should be considered in conjunction with AAA to provide identity protection.
Authentication for wireless networks can be device-based through the use of a shared WEP key. It can also be user-based through the use EAP. As discussed in Chapter 3, “Applying Security Technologies to Real Networks,” wireless EAP authentication can be used in many ways (EAP-TLS, EAP-TTLS, LEAP, and PEAP). Because not all vendors are using all these mechanisms, the decision as to which to use depends mostly on interoperability constraints. Both device and user authentication should be deployed in wireless networks to most effectively secure them. User authentication should be carried out through a secure tunnel so that the authentication exchange is encrypted. Therefore, for all environments, I recommend the use of EAP-TTLS or PEAP.
You can find information about setting up PEAP on the Aironet 1200 series at the following website:
You can find information about setting up PEAP on the Aironet 350 series at the following website:
Restricting access to who is allowed to connect to the wireless network is primarily carried out through the use of a AAA server, such as the Cisco Secure Access Control Server (ACS). The Cisco Secure ACS version 3.2 has features that include EAP enhancements to support Protected EAP (PEAP) for Microsoft Windows clients. PEAP retains the security benefits of Cisco EAP wireless (LEAP) while providing more extensibility and support for one-time token authentication. Cisco Secure ACS version 3.2 also supports machine authentication (using EAP-TLS or PEAP) on secure 802.1x ports. This capability is crucial for device control access in an 802.1x secure environment where port access is blocked until a user has successfully been identified behind an 802.1x-provisioned port. You can find configuration examples showing the setup EAP-TLS and EAP-PEAP with Cisco Secure ACS at the following website:
In addition, MAC address filtering can be used in environments that want to impose stricter controls, although it is important to keep in mind that MAC addresses can be spoofed and additional access controls should be used as well.
To make access control at perimeter firewalls easier for wireless networks, wireless clients can be allocated a DHCP address from a specified pool of addresses. Traffic from the wireless subnet can then have specific filtering rules applied that apply only to wireless VPN traffic. These rules are site-specific depending on the defined security policy. In most instances, it is prudent to follow the rule of “deny all and permit only what is needed.”
Wireless networks provide packet origin integrity through the use of Wired Equivalent Privacy (WEP) or Temporal Key Integrity Protocol (TKIP). Because WEP has limited capabilities, deployment of wireless networks should look to have updated software on the wireless APs and clients to use TKIP.
WEP provides confidentiality but uses a weak algorithm that can easily be exploited. Again, through the use of TKIP, which provides for an enhanced encryption scheme, better confidentiality of traffic can be ensured. In addition, some deployments may consider using IPsec ESP to provide a secure VPN tunnel. A wireless client would need to have IPsec enabled, and an IPsec transport mode tunnel would be created between the client and a VPN concentrator:
You can find information about how to configure WEP, Message Integrity Check (MIC), and TKIP on the Aironet 1400 series at the following website:
You can find information about how to configure WEP and WEP features on the Cisco Aironet 1100 series at the following website:
For examples on how to configure IPsec, refer to the references under the “Confidentiality” section in the previous discussion about VPN networks.
Wireless networks have the same requirement as any other network, which is minimal downtime. Whether due to a DoS attack or equipment failure, critical pieces of a wireless infrastructure need to be made available for wireless client access. The amount of effort and money spent on providing this availability depends on how important it is to keep the wireless network access up and running. In some environments, such as airport lounge or coffee shop wireless access, the event of limited downtime may just be an inconvenience to clients. However, some corporations are starting to rely on wireless access for more critical business operations and need to provide greater resiliency to avoid network downtime.
In addition to any redundancy and failover features discussed in previous chapters, such as load balancing and hot standby, wireless networks have additional availability considerations that largely relate to issues surrounding loss of signal strength and losing connectivity with an associated access point (AP). Having the capability to quickly and securely re-associate with another AP can greatly increase availability by reducing lost sessions.
The Cisco Aironet products support fast secure roaming, which allows authenticated client devices to roam securely from one AP to another without any perceptible delay during re-association. For more information about how to configure a Cisco AP for fast re-association of roaming client devices, access the following website:
Availability issues can also arise from having the authentication server be unavailable when a client is trying to associate to a given AP. Sometimes this is due to congested links that can prevent the authentication exchange, such as RADIUS packet exchanges, from taking place. This issue can be overcome by giving the RADIUS packets priority on transmissions both from the AP to the RADIUS server and from the RADIUS server to the AP. When priority is given to the RADIUS packets, the WAN routers service them before lower-priority traffic. The end result is that LEAP clients can authenticate successfully during times of WAN link congestion. The Cisco document, “802.1x and EAP-Based Authentication Across Congested WAN Links,” shows how to configure RADIUS packets to have higher priority. You can find this document at the following website:
In addition, the Aironet series devices support an IEEE 802.1x local authentication service that allows the wireless AP to act as a local RADIUS server to authenticate wireless clients when the AAA server is not available. This provides remote site survivability and backup authentication services during a WAN link or server failure, allowing users in remote site deployments with nonredundant WAN links access to local resources such as file servers or printers. How to configure the AP as a local authenticator to serve as a standalone authenticator for a small wireless LAN or to provide backup authentication service is shown at the website:
An auditing function is necessary to determine that the wireless network has been appropriately configured. If encrypted traffic is being used, don't just rely on a device counter to show that traffic is being encrypted. As with VPN networks, place an actual traffic analyzer on the network to verify that the traffic is indeed confidential and that anyone inadvertently sniffing the network can't see the traffic.
To address auditing needs, network administrators need a centralized method of configuring, gathering, storing, and retrieving information about all the APs and bridges on their network. They must be able to configure many APs and bridges, monitor the performance and availability of the wireless LAN (WLAN) infrastructure, and generate reports for capacity planning and client tracking. The ability to upgrade or downgrade software on many APs at one time is also essential. The CiscoWorks network management applications offer solutions for managing the Cisco WLAN infrastructure. CiscoWorks Wireless LAN Solution Engine (WLSE) is a specialized appliance for managing the Cisco WLAN infrastructure and, in conjunction with the CiscoWorks Resource Manager Essentials (RME), can greatly simplify many auditing tasks. The WLSE provides centralized template-based configuration, security misconfiguration detection, fault/performance monitoring, AP/bridge reports, and wireless client reports. CiscoWorks WLSE and CiscoWorks RME are complementary products that together offer a complete management solution for the Cisco WLAN. A document that describes how network administrators can use CiscoWorks WLSE and RME to help manage Cisco Aironet APs and bridges and describes configuration can be found at the following website:
Figure 12-3 shows an example of a typical secured wireless network scenario. The wireless network is essentially an extension of a remote-access VPN, in which IP addresses are assigned from a specific network access block obtained from the RADIUS server after the client has been successfully authenticated. The wireless clients and AP have 802.1x and EAP software to provide for device and user authentication prior to connecting to the switch and obtaining access to the corporate network. In addition, if confidentiality were desired, IPsec would be used between the wireless clients and a VPN concentrator. Smaller networks may opt to just use WEP encryption between the AP and the wireless client, but IPsec would give a more robust solution. The CiscoWorks WLSE/RMS solutions are used to manage the WLAN. Also, as with any network perimeter, an intrusion detection device can be used to help audit network traffic and detect a potential attack to the corporate network.
Voice over IP networks also have similar design methodology as VPN networks and the same questions need to be considered as were discussed for VPN networks. Security features in VoIP networks are still under development, and this section focuses on features that are currently available and that should be considered. However, you should follow the latest developments from Cisco in this area.
Identity considerations for VoIP networks also encompass both authentication and access control functionality.
Most IP phones currently only provide device authentication, although user authentication will be available in ongoing developments. The Cisco H.323 gateways support the use of a crypto token for authentication that uses the “password-with-hashing” security scheme as described in Chapter 3, “Applying Security Technologies to Real Networks.” A crypto token can be included in any RAS message between the VoIP gateway and a gatekeeper and is used to authenticate the sender of the message. It is possible to use a separate database for user ID and password verification.
As of Cisco IOS Software Release 12.2, Cisco H.323 gateways support three levels of authentication:
Endpoint—. The RAS channel used for gateway-to-gatekeeper signaling is not a secure channel. To ensure secure communication, H.235 allows gateways to include an authentication key in their RAS messages. The gatekeeper uses this key to authenticate the source of the messages. At the endpoint level, validation is performed on all messages from the gateway. The crypto tokens are validated using the password configured for the gateway.
Per call—. When the gateway receives a call over the telephony leg, it prompts the user for an account number and personal identification number (PIN). These two numbers are included in certain RAS messages sent from the endpoint and are used to authenticate the originator of the call.
All—. This option is a combination of the other two. With this option, the validation of crypto tokens in call initiation messages is based on an the account number and PIN of the user making a call, and the validation of crypto tokens sent in all the other RAS messages is based on the password configured for the gateway.
Crypto tokens for registration request (RRQ), unregistration request (URQ), disengage request (DRQ), and the terminating side of admission request (ARQ) messages contain information about the gateway that generated the token, including the gateway ID (which is the H.323 ID configured on the gateway) and the gateway password. Crypto tokens for the originating-side ARQ messages contain information about the user who is placing the call, including the user ID and PIN. This feature provides sender validation by using an authentication key in the gateway's RAS messages. The gatekeeper uses this key to authenticate the source of the messages and ensure secure communication.
Use the following Cisco IOS Software features for H.323 authentication/authorization:
The interdomain gatekeeper security enhancement feature, introduced in Cisco IOS Software Release 12.2(2)XA and Cisco IOS Software Release 12.2(4)T, provides a means of authenticating and authorizing H.323 calls between the administrative domains of Internet telephone service providers (ITSPs). An Interzone ClearToken (IZCT) is generated in the originating gatekeeper when a location request (LRQ) is initiated or an admission confirmation (ACF) is about to be sent for an intrazone call within an ITSP's administrative domain. As the IZCT traverses through the routing path, each gatekeeper stamps the IZCT's destination gatekeeper ID with its own ID. This identifies when the IZCT is being passed over to another ITSP's domain. The IZCT is then sent back to the originating gateway in the location confirmation (LCF) message. The originating gateway passes the IZCT to the terminating gateway in the setup message. The terminating gatekeeper forwards the IZCT in the ARQ answerCall field to the terminating gatekeeper, which then validates it. You can find more detailed information about this feature at the following website:
http://cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00800879e4.html
The gatekeeper-to-gatekeeper authentication feature provides additional security for H.323 networks by introducing the capability to validate intradomain and interdomain gatekeeper-to-gatekeeper LRQ messages on a per-hop basis. This feature provides a Cisco access token (CAT) to carry authentication within zones. The CAT is used by adjacent gatekeepers to authenticate each other and is configured on a per-zone basis. In addition, service providers can specify inbound passwords to authenticate LRQ messages that come from foreign domains and outbound passwords to be included in LRQ messages to foreign domains. You can find more information about this feature at the following website:
http://cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00800b5d6e.html
Because dynamic Real-Time Transport Protocol / RTP Control Protocol (RTP/RTCP) ports are used by the endpoints for voice calls, firewalls can be problematic unless they have some capability to recognize voice traffic and dynamically allow traffic. You can use the fixup protocol command on Cisco devices to give them the capability to look into the Layer 4 through Layer 7 information within the IP payload and make the necessary changes to the embedded IP address and ports used. If encryption is involved, such as TLS or IPsec, this feature will not work.
On a PIX firewall, the commands for stateful firewall VoIP intelligence are as follows:
fixup protocol h323 {h225 | ras} port [-port] fixup protocol sip [5060] fixup protocol skinny [2000] fixup protocol skinny port [-port]
fixup protocol h323 h225 1720 fixup protocol h323 ras 1718-1719 fixup protocol sip 5060 fixup protocol skinny 2000
Table 12-4 shows a matrix of Cisco solutions for firewall and NAT when used with the VoIP fixup protocol feature.
Table 12-4. VoIP fixup protocol Feature Support for Various Cisco Firewall Solutions
VoIP Protocol | PIX Firewall | Cisco IOS Firewall | Cisco IOS NAT |
|---|---|---|---|
H.323v2 | 5.2 | 12.1(5) T | 12.1(5) T |
H.323 RAS | 5.2 | No support | 12.2 (2) T |
H.323 w/NAT | 5.2 | No support | No support |
H.323 w/PAT | 6.2 | No support | No support |
SIP | 6.0 / 6.1 | No support | Near future |
SIP w/NAT | 6.0 / 6.1 | No support | Near future |
SIP w/PAT | 6.2 | No support | Near future |
MGCP | No support | No support | No support |
SCCP (Skinny) | 6.0 / 6.1 | No support | 12.1(5) T |
Table 12-5 lists the more common protocols and port numbers that should be allowed through a network perimeter firewall device in VoIP networks. It is recommended that the RTP audio stream ports listed here be constrained to a specified range of port numbers for media communication and then to specifically permit that range through the firewall as deemed necessary for proper VoIP communication.
Table 12-5. Common VoIP Protocols and Port Numbers
VoIP Protocol | Protocol and Port Number |
|---|---|
Unicast gatekeeper discovery | UDP port 1718 |
Multicast gatekeeper discovery | UDP port 1718 (to address 224.0.1.41) |
RAS | UDP port 1719 |
H.225 call signaling for hosts | TCP 1720 |
TLS for H.225 | TCP port 1300 |
H.245 capability exchange | negotiates TCP ports 11000 through 65535 |
RTP audio stream | UDP ports 16,384 through 32,767 |
SIP | |
|---|---|
Signaling | UDP/TCP port 5060 |
RTP audio stream | UDP ports 16,384 through 32,767 |
User agent registration | Multicast address 224.0.1.175 |
MGCP version 0.1 | |
|---|---|
Media gateway and call agent signaling | UDP port 2427 |
RTP audio stream | UDP ports 16,384 through 32,767 |
MGCP version 1.0 | |
|---|---|
Signaling to call agent | UDP port 2727 |
Signaling to media gateway | UDP port 2427 |
RTP audio stream | UDP ports 16,384 through 32,767 |
When using the Cisco secure PIX firewall with SIP, be aware of the following:
If a firewall proxy is placed outside the firewall in the demilitarized zone (DMZ) network with Record-Route enabled, the list of allowed IP addresses from the outside SIP proxy server's IP address should be small and manageable, thus allowing for manageable security.
Outside callers cannot make calls to inside the firewall unless they have been defined as an allowed device.
In addition, the following features in Cisco IOS Software can be useful to provide access control in VoIP networks.
The Cisco IOS firewall extends the concept of static access control lists (ACLs) by introducing dynamic ACL entries that open on the basis of the necessary application ports on a specific application and close these ports at the end of the application session. The Cisco IOS firewall achieves this functionality by inspecting the application data, checking for conformance of the application protocol, extracting the relevant port information to create the dynamic ACL entries, and closing these ports at the end of the session as determined through a timeout value. This feature supports only the SIP UDP format for signaling; the TCP format is not supported. The feature is available in Cisco IOS Software Release 12.2(11)YU and 12.2(15)T.
The firewall for SIP support feature allows SIP signaling requests to traverse directly between gateways or through a series of proxies to the destination gateway or phone. After the initial request, if the Record-Route header field is not used, subsequent requests can traverse directly to the destination gateway address as specified in the Contact header field. Therefore, the Cisco IOS firewall is aware of all surrounding proxies and gateways and allows the following functionality:
More information for the firewall for SIP feature is available at the following website:
The tokenless call authentication feature uses a statically configured ACL of authorized H.323 endpoints for the Cisco IOS gatekeeper. The gatekeeper accepts calls from endpoints on the list. This security feature is an alternative to Interzone ClearTokens (IZCTs) and Cisco access tokens (CATs), and can be used with Cisco Call Manager (CCM). More detailed information on the tokenless call authentication feature can be found at the following website:
The current Media Gateway Control Protocol (MGCP) implementation does not allow the assignment of particular IP addresses for sourcing MGCP commands and media packets, which can cause firewall and security problems. This feature enables you to configure interfaces on which control and media packets can be exchanged. This new functionality enables you to separate signaling from voice by binding control (MGCP signaling) and media (RTP voice, fax, and modem) to specific gateway interfaces.
This feature includes a new command-line interface (CLI) that you can use to configure the required interface for MGCP control and control of the required media packets. The feature was introduced in 12.2(13)T and more specific information on it can be found at the following website:
The h323-gateway voip bind srcaddr x.x.x.x command enables you to bind the source IP address for the signaling and media traffic. This allows the downstream firewall to know where the source signaling is coming from, which allows it to set up the trust associations or policy for the VoIP traversal through the firewall. It forces the signaling and media traffic source IP address to be defined specifically and doesn't allow the router to randomly choose an IP address from one of its interfaces.
With Cisco IOS Software Release 12.2(2)XB, there is support for SIP bind addresses with the bind all source-interface x.x.x.x command.
VoIP networks provide packet origin integrity through the use of inherent protocol features. H.323 uses a crypto token, which in Cisco devices is currently based on a hashed password. The passwords should be configured on all gateways and gatekeepers that are part of the VoIP network.
Confidentiality for VoIP traffic can be accomplished, but a number of pitfalls need to be taken into consideration. If NAT is being used and there are firewalls in the path, TLS and, or IPsec encryption is not an option for voice traffic. You should consider each leg of the VoIP network to ascertain where it is feasible to use encryption and then decide whether there is a large risk in someone eavesdropping on the signaling or voice traffic. It may prove useful to just encrypt some parts of the network. If you have an environment that could handle hop-by-hop encryption, IPsec should be configured. Consider this carefully, however, because at each hop the encryption/decryption can be problematic and cause too much latency.
The SIP extensions for caller identity and privacy feature provides support for privacy indication, network verification, and screening of a call participant name and number. This feature was introduced in 12.2(13)T.
Cisco implements this feature on SIP trunking gateways by supporting a new header, Remote-Party-ID, as defined in the IETF specification, draft-ietf-privacy-.02.txt, “SIP Extensions for Caller Identity and Privacy.” The Remote-Party-ID header identifies the calling party and carries presentation and screening information. In previous SIP implementations, the From header was used to indicate calling party identity, and once defined in the initial invite request, could not be modified for that session. Implementing the Remote-Party-ID header, which can be modified, added, or removed as a call session is being established, overcomes previous limitations and enables call participant privacy indication, screening, and verification. The new feature uses the Remote-Party-ID header to support translation capability between Integrated Services Digital Networks (ISDN) messages and Remote-Party-ID SIP tags. The new SIP header also enables support for certain telephony services, and some regulatory and public safety requirements, by providing screening and presentation indicators. Detailed information on this feature can be found at the following website:
VoIP networks have the same requirement as any other network, which is minimal downtime and the capability to still make calls in the event of a DoS attack. There should never exist a single point of failure in the VoIP network infrastructure if the VoIP service becomes a critical mechanism of communication in a given network environment. Smaller corporations will probably not have the monetary resources to buy redundant devices, but larger corporations should definitely deploy redundancy for the networking infrastructure. For any redundant configurations, the features should be enabled that provide for automated failover scenarios in the event of a device failure.
Cisco provides for a specific telephony-based feature for redundancy. The Survivable Remote Site (SRS) telephony feature provides Cisco Call Manager (CCM) with fallback support for Cisco IP phones attached to a Cisco router on your local network. The SRS telephony feature enables routers to provide call-handling support for Cisco IP phones when they lose connection to remote primary, secondary, or tertiary CCM installations, or when the WAN connection is down.
CCM supports Cisco IP phones at remote sites attached to Cisco multiservice routers across the WAN. Prior to the SRS telephony feature, when the WAN connection between a router and CCM failed, or connectivity with CCM was lost for some reason, Cisco IP phones on the network became unusable for the duration of the failure. The SRS telephony feature overcomes this problem and ensures that the Cisco IP phones offer continuous (yet, minimal) service by providing call-handling support for Cisco IP phones directly from the SRS telephony router. The system automatically detects a failure and uses Simple Network Auto Provisioning (SNAP) technology to autoconfigure the branch office router to provide call processing for Cisco IP phones registered with the router. When the WAN link or connection to the primary CCM is restored, call handling reverts to the primary CCM.
When Cisco IP phones lose contact with primary, secondary, and tertiary CCMs, they must establish a connection to a local SRS telephony router to ensure call-processing capability necessary to place and receive calls. The Cisco IP phone retains the IP address of the local SRS telephony router as a default router in the Network Configuration area of the Settings menu. This list supports a maximum of five default router entries; however, CCM accommodates a maximum of three entries. When a secondary CCM is not available on the network, the local SRS telephony router's IP address is retained as the standby connection for CCM during normal operation.
When the WAN link between the router and the CCM fails, calls in progress are sustained for the duration of the call so long as the WAN link is not part of the call connection itself. Calls in transition and calls that have not yet connected are dropped and must be re-initiated after Cisco IP phones reestablish connection to their local SRS telephony router. Telephone service remains unavailable from the time connection to the remote CCM is lost until the Cisco IP phone establishes connection to the SRS telephony router.
You can find more information about the tasks and commands necessary to configure and maintain Cisco SRS telephony for systems with Cisco Call Manager v3.0.5 and higher at the following website:
An auditing function is necessary to determine that the VoIP network has been appropriately configured and that the proper security services are being effectively deployed. Accounting is an important part of many voice networks to keep track of calls—who originated calls, what the call destinations were, and what were the call durations.
A specific feature to look at is gateway accounting for SIP, which is configured with the command gw-accounting {voip | syslog | h323 [syslog]}. The voip keyword sends the call data record (CDR) to the RADIUS server. Use this keyword with the SIP feature. The h323 keyword sends the call data record (CDR) to the RADIUS server. The syslog keyword uses the system logging facility to record the CDRs.
In addition, all the other auditing functions mentioned in earlier parts of this chapter, such as making sure that encrypted traffic is indeed encrypted through the use of traffic analyzers and traffic monitoring for potential network attacks through the use of intrusion detection systems, should be used.
Because practical security in VoIP networks is still largely evolving, two relevant papers written by Cisco that detail currently available security design solutions are referenced here. The first paper is titled “Security in SIP-Based Networks” and describes network security solutions based on Cisco SIP-enabled products. It is located at the following website:
The second paper is titled “Stealth VPN” and details a Cisco IOS Software site-to-site and small office / home office remote-access VPN solution. It encompasses myriad Cisco IOS technologies, including security and voice. This paper can be found at the following website:
This chapter focused on providing comprehensive design considerations and examples for securing VPN, wireless, and VoIP networks when using Cisco equipment. Useful features and references to configuration examples were given. Many of the security features for wireless and VoIP networks are still evolving, and newer software releases should be considered in these networks to deploy the latest security functionalities.
You can find a comprehensive Cisco IOS Software security Command Reference for Release 12.2 at the following website:
The following questions provide you with an opportunity to test your knowledge of the topics covered in this chapter. You can find the answers to these questions in Appendix E, “Answers to Review Questions.”