Internet Protocol security (IPsec) is a framework of open standards for ensuring private, secure communications over Internet Protocol (IP) networks, through the use of cryptographic security services.
IPsec can be deployed in many different ways. The purpose of this chapter is to explain what IPsec is and how to secure selected communication paths using IPsec. The chapter on Applying IPsec with the Network Isolation Utility explains a specific, more restricted, but automated way of applying IPsec to secure the entire traffic to and from the server. The Network Isolation Utility also saves you a lot of work in applying IPsec. However, if you use this utility to apply IPsec, be sure to read this chapter to understand the various IPsec deployment options and to use the one that is the most beneficial for your environment.
Implementing IPsec in a Unified ICM/Unified CCE environment means finding a balance between ease of deployment and usability, and protecting sensitive information from unauthorized access.
Finding the proper balance requires the following:
Assessing the risk and determining the appropriate level of security for your organization
Identifying valuable information
Defining security policies that use your risk management criteria and protect the identified information
Determining how the policies can best be implemented within the existing organization
Ensuring that management and technology requirements are in place
Security considerations are also influenced by the way the application will be used or deployed. For example, the required security might differ depending on whether certain Unified ICM/Unified CCE servers will be deployed in a single data center or across a number of sites that may or may not communicate across trusted networks. The security framework in Windows Server 2008 R2 is designed to fulfill the most stringent security requirements. However, software alone might be less effective without careful planning and assessment, effective security guidelines, enforcement, auditing, and sensible security policy design and assignment.
Network Address Translation (NAT) is a mechanism for conserving registered IP addresses in large networks and simplifying IP addressing management tasks. As its name implies, NAT translates IP addresses within private internal networks to legal IP addresses for transport over public external networks (such as the Internet). Incoming traffic is translated back for delivery within the inside network.
Due to increased security concerns in the deployment of data and voice networks alike, Unified ICM and Unified CCE deployments now add support for IPsec between Central Controller sites and remote Peripheral (PG) sites. This secure network implementation implies a distributed model where the WAN connection is secured via IPsec tunnels. The testing undertaken in this release was limited to the configuration of Cisco IOS IPsec in Tunnel Mode, meaning only the Cisco IP Routers (IPsec peers) between the two sites were part of the secure channel establishment. All data traffic is encrypted across the WAN link but un-encrypted on the local area networks. In Tunnel Mode, traffic flow confidentiality is ensured between IPsec peers, which in this case, are the IOS Routers connecting a central site to a remote site.
The qualified specifications for the IPsec configuration are as follows:
HMAC-SHA1 Authentication (ESP-SHA-HMAC)
3DES Encryption (ESP-3DES)
The common recommendation for QoS networks is to classify and apply QoS features based on packet header information before traffic is tunnel encapsulated and/or encrypted.
Following are the system requirements for IPsec Support in Transport Mode:
Cisco Unified ICM Release 9.0(1)
Microsoft Windows Server 2008 R2
Intel PRO/100 S Server Adapter P/N PILA8470C3
IPsec offload network adapters accelerate the cryptographic operations used to secure IPsec packets, thereby minimizing the performance costs for encryption. As a result, IPsec-secured TCP/IP connections can achieve a similar rate of throughput as TCP/IP connections that are not secured using IPsec. If the hardware acceleration cards cannot be used, IPsec encryption will increase CPU load, and decrease throughput.
Unified ICM Release 9.0(1) support for IPsec is contingent on the use of network interface cards that support IPsec offloads. The card listed in the System Requirements list has been tested and is recommended.
For more information about the benefits of using IPsec hardware offload adapters, see IntelPRO/100S Network Adapter, IPsec Offload Performance and Comparison.
Unified ICM Release 9.0(1) supports deploying IPsec in a Windows Server 2008 R2 operating environment to secure server-to-server communication. The support is limited to the following list of nodes, which exchange customer-sensitive data.
NAM Router and CICM Router
Unified ICM Router Side A and Unified ICM Logger Side A (visible path)
Unified ICM Router Side B and Unified ICM Logger Side B (visible path)
Unified ICM Router Side A and Unified ICM Router Side B (private path)
Unified ICM Logger Side A and Unified ICM Logger Side B (private path)
Unified ICM Router and Unified ICM Peripheral Gateway (PG)
Unified ICM Router Side A and Unified ICM PG Side A
Unified ICM Router Side A and Unified ICM PG Side B
Unified ICM Router Side B and Unified ICM PG Side A
Unified ICM Router Side B and Unified ICM PG Side B
Unified ICM Router and Administrator & Data Server (Primary/Secondary) with Historical Data Server (HDS)
Unified ICM Router Side A and Unified ICM Administrator & Data Server (Primary/Secondary) with HDS
Unified ICM Router Side B and Unified ICM Administrator & Data Server (Primary/Secondary) with HDS
Unified ICM Router and Unified ICM Administration Server, Real-time and Historical Data Server, and Detail Data Server (Primary/Secondary)
Unified ICM Router Side A andUnified ICM Administration Server, Real-time and Historical Data Server, and Detail Data Server (Primary/Secondary)
Unified ICM Router Side B and Unified ICM Administration Server, Real-Time and Historical Data Server, and Detail Data Server (Primary/Secondary)
Unified ICM Logger and Unified ICM Administrator & Data Server (Primary/Secondary) with HDS
Unified ICM Logger Side A andUnified ICM Administrator & Data Server (Primary/Secondary) with HDS
Unified ICM Logger Side B and Unified ICM Administrator & Data Server (Primary/Secondary) with HDS
Unified ICM Logger and Unified ICM Administration Server, Real-time and Historical Data Server, and Detail Data Server (Primary/Secondary)
Unified ICM Logger Side A and Unified ICM Administration Server, Real-time and Historical Data Server, and Detail Data Server (Primary/Secondary)
Unified ICM Logger Side B and Unified ICM Administration Server, Real-time and Historical Data Server, and Detail Data Server (Primary/Secondary)
Unified ICM PG Side A and Unified ICM PG Side B
Unified ICM PG Side A/B and Unified CM (Unified CCE)
For the preceding identified server communication paths, consider a High security level as a general basis for planning an IPsec deployment.
Be sure to consult Microsoft Knowledge Base article KB 942957 for important information about changes in Windows Server 2008 R2 IPsec support from Windows Server 2000 support of IPsec.
Windows Server 2008 R2 IPsec policy configuration is the translation of security requirements to one or more IPsec policies.
Each IPsec policy consists of one or more IPsec rules. Each IPsec rule consists of the following:
A selected filter list
A selected filter action
Selected authentication methods
A selected connection type
A selected tunnel setting
There are multiple ways to configure IPsec policies but the following is the most direct method:
Create a new policy and define the set of rules for the policy, adding filter lists and filter actions as required. With this method, you create an IPsec policy first and then you add and configure rules. Add filter lists (specifying traffic types) and filter actions (specifying how the traffic is treated) during rule creation.
An IPsec Security Policy must be created for each communication path and on each end (on every server). Provide the following when creating and editing the properties of each IPsec policy using the IP Security Policy Wizard.
Do not Activate the default response rule
IP Security Rule (add Rule using the Add Wizard)
Tunnel Endpoint (do not specify a tunnel)
Network Type: All network connections
IP Filter List
Add IP Filter using the Add Wizard: Description (optional) Source address: A specific IP Address (differs based on the path) Destination address: A specific IP Address (differs based on the path) IP Protocol type: Any
Add Filter Action using the Add Wizard: Name Description (optional) Filter Action General Options: Negotiate security Do not communicate with computers that do not support IPsec IP Traffic Security: Integrity and encryption - Integrity algorithm: SHA1 - Encryption algorithm: 3DES
Authentication Method: Active Directory _Kerberos V5 protocol (Default)
X509 certificates can also be used in a production environment depending on customer preference. With Unified ICM requiring Active Directory in all deployment models, relying on Kerberos as the authentication method will not require any extra security credential management. For PG to Cisco Call Manager (CCM) connections use an X509 preshared key.
For enhanced security, the use of preshared key authentication is not recommended because it is a relatively weak authentication method. In addition, preshared keys are stored in plain text. It is recommended that you use preshared keys only for testing. For more information, see Preshared key authentication at http://technet.microsoft.com/en-us/library/cc782582(WS.10).aspx.
Key Exchange Security Method - IKE Security Algorithms (Defaults)
Integrity algorithm: SHA1
Encryption algorithm: 3DES
Diffie-Hellman group: Medium (DH Group 2, 1024-bit key)
For enhanced security, do not use Diffie-Hellman Group 1, which provides 768 bits of keying strength. For maximum security, use Group 2048 (high), which provides 2,048 bits of keying strength. Strong Diffie-Hellman groups combined with longer key lengths increase the computational difficulty of determining a secret key. For more information, see Key exchange methods at http://technet.microsoft.com/en-us/library/cc759504(WS.10).aspx.
IP Security Monitor (ipsecmon) can be used to monitor IPsec on a Windows Server 2008 R2 operating system. The details about the IPsec Monitor can be found in Microsoft article KB 324269.
Enable IPsec logging
If your policies do not work correctly, you might need to enable the logging of the IPsec security association process. This is called an Oakley log. The log is difficult to read, but it can help you track down the location of the failure in the process. The following steps enable IPsec logging.
Choose Start > Run.
Type Regedt32 and click OK to get into the Registry Editor.
Navigate to System\CurrentControlSet\Services\PolicyAgent.
Double-click Policy Agent.
Right-click in the right-hand pane and choose Edit > Add Key.
Enter Oakley as the key name (case sensitive).
Right-click in the left-hand pane and choose New > DWORD Value.
Enter the value name EnableLogging (case sensitive).
Double-click the value and set the DWORD to 1.
Go to a command prompt and type net stop policyagent & net start policyagent.
Find the log in %windir%\debug\Oakley.log.
The Network Monitor component (netmon) that ships with Windows Server 2008 R2 can capture frames that are sent to or from the computer on which Network Monitor is installed. For more information, see Microsoft documentation at http://support.microsoft.com/kb/933741.
The built-in Performance console (perfmon) provides the ability to monitor network activity along with the other performance data on the system. Treat network components as another set of hardware resources to observe as part of your normal performance-monitoring routine.
Network activity can influence the performance not only of your network components but also of your system as a whole. Be sure to monitor other resources along with network activity, such as disk, memory, and processor activity. System Monitor enables you to track network and system activity using a single tool. Use the following counters as part of your normal monitoring configuration:
Cache\Data Map Hits %
Cache\Lazy Write Pages/sec
Logical Disk\% Disk Space
Memory\Nonpaged Pool Allocs
Memory\Nonpaged Pool Bytes
Memory\Paged Pool Allocs
Memory\Paged Pool Bytes
Processor(_Total)\% Processor Time
System\Processor Queue Length
NAT is a mechanism for conserving registered IP addresses in large networks and simplifying IP addressing management tasks. NAT translates IP addresses within private internal networks to legal IP addresses for transport over public external networks (such as the Internet). NAT also translates the incoming traffic legal delivery addresses to the IP addresses within the inside network.
Release 8.0(1) continues support for deployment of IP Phones (Unified CCE) across NAT. Cisco has also tested locating remote Peripheral (PG) servers on a NAT network remote from the Central Controller servers (Routers and Loggers). The qualification of NAT support for PG servers was limited to a network infrastructure implementing Cisco IP Routers with NAT functionality.
Agent Desktops are supported in a NAT environment, except when silent monitoring is used. Silent Monitoring is not supported under NAT; see the section on NAT and CTI OS below.
CTI OS Silent Monitor does not work in a production environment when all of the servers of the Unified CCE (Administration & Data Server, PG, CTI OS Server and Unified CM) are located on a remote data center with a private addressing scheme and the agent/supervisor desktops and hard IP phones are on the call center network that also has its own address scheme while both networks (data center and call center) are joined together using NAT.
The two main problems that are identified in this environment are as follows:
The CTI toolkit Agent Desktop cannot sniff any VoIP packets from the PC port on the IP phone, because the IP address used on the packet filter is the translated address sent by Unified CM. The problem is that the address belongs to the address scheme at the data center network and not on the call center network space. Note that this problem is not particular to CTI OS but also affects applications written using GED-188 directly that rely on the RTP Stated/Stop events.
The IP address the CTI toolkit Supervisor Desktop provides the CTI toolkit Agent Desktop for it to forward sniffed VoIP packets is an address on the data center address space. The CTI toolkit Supervisor Desktop obtains its IP address from the eClientIdentifyEvent sent by CTI OS Server to the supervisor workstation when it initiates its session with CTI OS Server. The IP address included in the event is the translated address in the data center network, not that of the call center network.
IPsec and NAT Transparency
The IPsec NAT Transparency feature introduces support for IPsec traffic to travel through NAT or Port Address Translation (PAT) points in the network by addressing many known incompatibilities between NAT and IPsec. NAT Traversal (NAT-T) is a feature that is autodetected by VPN devices. There are no configuration steps for a router running Cisco IOS Software Release 12.2(13)T and later. If both VPN devices are NAT-T capable, then NAT-T is autodetected and autonegotiated.
Additional IPsec references
Additional IPsec references can be found on the web at: