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.
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.
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
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.
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
Visible path
Private path
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.
Name
Description (optional)
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
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.
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.
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.
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.
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: