Security Best Practices Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted Release 9.0
IPsec and NAT support
Downloads: This chapterpdf (PDF - 516.0KB) The complete bookPDF (PDF - 3.48MB) | Feedback

IPsec and NAT support

IPsec and NAT support

About IPsec

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.


Note


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.

For more information, see http://www.cisco.com/go/ipsec and http://technet.microsoft.com/en-us/network/bb531150.aspx.

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.

About NAT

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.

The section in this chapter beginning with Support for NAT (Network Address Translation) describes the Unified ICM and Unified CCE NAT support.

Support for IPsec in Tunnel Mode

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.

For more detailed resources on Cisco IOS IPsec functionality, see http://www.cisco.com/go/ipsec.

Support for IPsec in Transport Mode

System requirements

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

Note


  • 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.

Supported communication paths

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.

  1. NAM Router and CICM Router
  2. Unified ICM Router Side A and Unified ICM Logger Side A (visible path)
  3. Unified ICM Router Side B and Unified ICM Logger Side B (visible path)
  4. Unified ICM Router Side A and Unified ICM Router Side B (private path)
  5. Unified ICM Logger Side A and Unified ICM Logger Side B (private path)
  6. Unified ICM Router and Unified ICM Peripheral Gateway (PG)
    1. Unified ICM Router Side A and Unified ICM PG Side A
    2. Unified ICM Router Side A and Unified ICM PG Side B
    3. Unified ICM Router Side B and Unified ICM PG Side A
    4. Unified ICM Router Side B and Unified ICM PG Side B
  7. Unified ICM Router and Administrator & Data Server (Primary/Secondary) with Historical Data Server (HDS)
    1. Unified ICM Router Side A and Unified ICM Administrator & Data Server (Primary/Secondary) with HDS
    2. Unified ICM Router Side B and Unified ICM Administrator & Data Server (Primary/Secondary) with HDS
  8. Unified ICM Router and Unified ICM Administration Server, Real-time and Historical Data Server, and Detail Data Server (Primary/Secondary)
    1. Unified ICM Router Side A and Unified ICM Administration Server, Real-time and Historical Data Server, and Detail Data Server (Primary/Secondary)
    2. Unified ICM Router Side B and Unified ICM Administration Server, Real-Time and Historical Data Server, and Detail Data Server (Primary/Secondary)
  9. Unified ICM Logger and Unified ICM Administrator & Data Server (Primary/Secondary) with HDS
    1. Unified ICM Logger Side A and Unified ICM Administrator & Data Server (Primary/Secondary) with HDS
    2. Unified ICM Logger Side B and Unified ICM Administrator & Data Server (Primary/Secondary) with HDS
  10. Unified ICM Logger and Unified ICM Administration Server, Real-time and Historical Data Server, and Detail Data Server (Primary/Secondary)
    1. Unified ICM Logger Side A and Unified ICM Administration Server, Real-time and Historical Data Server, and Detail Data Server (Primary/Secondary)
    2. Unified ICM Logger Side B and Unified ICM Administration Server, Real-time and Historical Data Server, and Detail Data Server (Primary/Secondary)
  11. Unified ICM PG Side A and Unified ICM PG Side B
    1. Visible path
    2. Private path
  12. 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.

Related Information

IPsec policy configuration

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.

  1. Name
  2. Description (optional)
  3. Do not Activate the default response rule
  4. IP Security Rule (add Rule using the Add Wizard)
    • Tunnel Endpoint (do not specify a tunnel)
    • Network Type: All network connections
  5. IP Filter List
    • Name
    • Description (optional)
    • 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)

      Note


      • 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.

  6. Key Exchange Security Method - IKE Security Algorithms (Defaults)
    • Integrity algorithm: SHA1
    • Encryption algorithm: 3DES
    • Diffie-Hellman group: Medium (DH Group 2, 1024-bit key)

      Note


      • 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.
      • For information about general best practices for security, see best practices for security at http://technet.microsoft.com/en-us/library/dd560764(WS.10).aspx.
      • Using longer key lengths results in more CPU processing overhead.

IPsec connection to Unified CM

On Unified CCE Systems, when the Unified CM is not in the same domain as the Unified ICM system, you are unable to use Kerberos for authentication. You must use X.509 certificates.

IPsec activity

IPsec Monitor

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.

Procedure
    Step 1   Choose Start > Run.
    Step 2   Type Regedt32 and click OK to get into the Registry Editor.
    Step 3   Double-click HKEY_LOCAL_MACHINE.
    Step 4   Navigate to System\CurrentControlSet\Services\PolicyAgent.
    Step 5   Double-click Policy Agent.
    Step 6   Right-click in the right-hand pane and choose Edit > Add Key.
    Step 7   Enter Oakley as the key name (case sensitive).
    Step 8   Double-click Oakley.
    Step 9   Right-click in the left-hand pane and choose New > DWORD Value.
    Step 10   Enter the value name EnableLogging (case sensitive).
    Step 11   Double-click the value and set the DWORD to 1.
    Step 12   Click OK.
    Step 13   Go to a command prompt and type net stop policyagent & net start policyagent.
    Step 14   Find the log in %windir%\debug\Oakley.log.

    Network monitoring

    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.

    System monitoring

    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\Fast Reads/sec
    • Cache\Lazy Write Pages/sec
    • Logical Disk\% Disk Space
    • Memory\Available Bytes
    • Memory\Nonpaged Pool Allocs
    • Memory\Nonpaged Pool Bytes
    • Memory\Paged Pool Allocs
    • Memory\Paged Pool Bytes
    • Processor(_Total)\% Processor Time
    • System\Context Switches/sec
    • System\Processor Queue Length
    • Processor(_Total)\Interrupts/sec

    NAT support

    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.

    For more detailed resources on how to configure NAT, see http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094e77.shtml.

    For more details on how to deploy IP Phones across NAT, see http://cisco.com/en/US/products/sw/iosswrel/ps1834/products_feature_guides_list.html.

    NAT and CTI OS

    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: