Executive Summary
Protecting data in motion has become a high priority for a growing number of companies. As more companies face the real and growing threat of data theft, along with increased regulatory pressure to protect their data, encryption of data in motion has gone from a “nice to have” technology to a budgeted project. However, companies that have deployed IPsec VPNs across their network have discovered that while encryption is a great mode of data protection, the deployment and management of network encryption is difficult, time consuming and largely incompatible with other network requirements, such as flexibility, performance and intelligent traffic routing.
The heart of the problem is that organizations are trying to use a method managing encryption that was only designed to secure point-to-point links, not the any-to-any network in use today. Originally defined in 1998, IKE was and is a remarkably efficient and creative method for enabling shared encryption keys between two routers or VPN encryption blades.
It is, however, very inefficient and complicated when it comes to encrypting data over modern networks.
Encryption often gets the blame for poor network performance (in terms of bandwidth and latency) and time-consuming management, but upon closer examination, one finds that the issue is not encryption, but encryption set-up and management. This white paper discusses the underlying issues with using a point-to-point policy and key management system for network encryption. It also introduces a policy and key management solution that makes network encryption quick to set up, easy to manage, and transparent to network and application performance and behavior.
The Challenges of Securing Any-to-Any Networks with a Point-to-Point solution
Protecting data in motion has been a best practice since the introduction of networking. As networking technologies have changed, so has the data in motion security technology. With today’s IP based networks, the data in motion standard is IPSec for data packet protection and Internet Key Exchange (IKE) for point-to-point key management.
IPSec was designed to provide encryption and authentication of IP packets and IKE was designed to exchange keys between two points across an untrusted connection. To use IKE for key management, a connection is initiated, each endpoint authenticates the other, and the peers negotiate symmetric keys for the connection. The result is a point-to-point secure tunnel through the network.
IPSec packet protection requires the configuration of traffic policies at each endpoint or gateway for all other potential peer destinations. For each connection, the algorithms for protection, authentication, key exchange, gateway addresses, and numerous other parameters must be defined. Each end of the tunnel must have the exact same configurations or the IKE negotiation will fail. In configuring an IPSec deployment, most systems require each unit to receive a painstakingly generated set of policies, carefully crafted and manually installed on each system.
The point-to-point nature of an IKE-created IPSec tunnel precludes effective use of IPSec for multicast traffic, latency sensitive traffic, or to protect multi-path data flows because IKE views all connections as point-to-point. The point-to-point orientation of IKE-created IPSec tunnels also makes the concept of status monitoring and error detection problematic, as there is typically no centralized management for the secured network. This also makes auditing the secure network a challenge.
Finally, the nature of statically created point-to-point tunnels makes scalability an inherent problem. From a set up and management perspective, the complexity of a deploying a fully meshed network encryption deployment is staggering. For example, in a network with 30 sites and 20 subnets at each site deploying a full meshed encryption solution would require as many as 20,000 policy rules on every edge router. In addition to the likelihood of configuration errors for such a large task, the loading, reviewing, and monitoring of the tens of thousands of policies on each machine would quickly become overwhelming to the security administrator.
In addition, a large meshed system where each IKE negotiation takes 200mS and re-keys occur once a day (reasonable numbers for enterprise systems), the IPSec gateway would spend at least 10% of its time just on the IKE negotiations. In fact, the overlapping negotiations would increase this load significantly with timeout, resends, and dropped packets, effectively putting a choke on the router’s performance. This diminishes the investment made in the router and wastes bandwidth, which cost money in terms of application performance and access costs.
A Smarter Approach to Policy and Key Management
Given that the management costs and performance issues associated with network encryption are a direct result of using IKE, it stands to reason that a policy and key management solution designed specifically for network encryption deployments would eliminate the issues noted above. A purpose built solution would greatly reduce the complexity of configuration, remove the current challenge of scale, and eliminate the limitations for multicast or multiple path encryption.
In order to accomplish this goal, the solution should:
• Expand IPSec protection to multicast and multiple nodes through centralized management of distributed keys and policies.
• Duplicate the inner IP addressing information to the outer IPSec header to preserve routing information.
• Simplify the management of secure networks through centralized, straightforward policy definition, distribution and management.
• Provide scalable distribution and monitoring for policies, status, auditing, and secure key management.
• Use IPSec standard-based policies and AES 256- bit keys to provide Layer 2 Ethernet encryption, Layer 3 IP encryption or Layer 4 payload-only encryption.
These parameters are the same features that were designed into CipherEngine, the policy and key management solution. This solution has been deployed in a number of enterprise networks and proves that by taking a network approach to policy and key management, encryption set-up and management can be accomplished with minimal effort. It also shows that encryption can operate on a large network with virtually no impact to network and application performance. Current CipherEngine deployments include:
- A multi-national network operating 30 sites in seven countries over multiple service providers where all data traveling to and from overseas branches is encrypted. The solution was deployed in the absence of local technical resource and keys are refreshed daily without manual intervention.
- A 250 site, fully meshed MPLS network encrypting VoIP and other traffic without adding latency or jitter to the call quality.
- A large financial institution with a layer 2 WAN, where each VLAN is encrypted with a separate key.
- A Metro Ethernet deployment with multipoint-to-multipoint requirements that was set up and deployed by a single network administrator in less than two days.
These deployments, along with several others, have proven that by taking a network centric approach to policy and key management, encryption can be easily deployed and managed without compromising performance. The next section takes a closer look at how CipherEngine works.
How CipherEngine Works
CipherEngine has three primary components, each with a distinct function. The components include a policy administrator, a key server and an endpoint configuration and management tool. Specifically the components are:
− The Management and Policy Server (MAP), where data traffic security policies are defined
− The Key Authority Point (KAP), which generates encryption keys based on the policies it received from the MAP and pushes the policies and associated keys to the enforcement points.
− CipherView, an appliance management tool used for configuration, software updates, and maintenance functions for the CipherEngine Enforcement Points (CEPs).
Figure 1 below illustrates how CipherEngine works. The sections that follow cover each function in detail.
CipherEngine MAP: Policy Definition and Management
CipherEngine’s Management and Policy server is a rich-client application running on a Windows XP system. MAP is the user interface where security policies defining how and where the encryption will take place are created and managed.
A MAP policy defines networks to be protected and groups these networks into Network Sets. A policy can have one or more Network Set associated with it and the CEPs in each Network Set are treated as one single entity and given the same key. The Network Set view in MAP allows the user to create, edit, delete, and view the status of all Network Sets.
To create a Network Set, the user defines the name and can enter notes about the Network Set. The user then adds CEPs to the Network Set by dragging them from the CEP view into the new Network Set.
Once the Network Sets are created, the security policies governing them are then defined. MAP allows four type of policies to be created, but more than one type of policy can exist on the same network. MAP policy types are:
− Hub-and-Spoke- creates a point-to-point connection between each hub Network Set and each spoke Network Set.
− Point-to-Point- creates a connection between two Network Sets.
− Mesh- any-to any connectivity.
− Multicast- allows each Network Set to be part of a multicast network as sender, receiver or both.
Each policy also specifies the re-key periods, encryption and hash algorithms to be used and whether the key generation technique being used is per Network Set or global. Policy filtering criteria can be high level, such as “encrypt everything,” or more granular, specifying traffic based on IP addresses, protocols, or VLAN IDs.
The MAP enables the security administrator to monitor the working status of all KAP and CEP units in the deployment. This monitoring capability includes information about units that are not responding, are in error or where policy deployments have not been completed.
The MAP also provides a set of user roles to support role-based access and auditing responsibilities.
CipherEngine KAP: Key Creation and Deployment
Once the security policy is defined, the MAP sends a metapolicy to each KAP. The metapolicy contains all of the information regarding each policy, including the action (encrypt, clear, or drop), the lifetime of the policy, the encryptors that enforce the policies, and what kind of traffic the policy acts on. The KAP then generates the required encryption keys and sends the appropriate policies along with the shared keys to each of the encryptors.
A KAP can be a local KAP that runs as a separate application on the same workstation as the MAP software or an external KAP installed on your network. All policy and key distribution is protected through TLS and occurs through the management port of the KAP and CEP. All KAP units receive their policy definition from a single MAP. This tells the KAP which CEP units it is responsible for and which networks it protects. It also reveals to the KAP other Network Sets used in the policies and which associated KAP units they use.
When the keys that have already been deployed are nearing expiration, the KAP automatically generates new keys and pushes these out to replace the expiring keys. This auto renew feature for the keys can be set to occur at specified intervals or at specific times, all being set by the security administrator.
The KAP operates continuously, generating new keys, responding to MAP requests, and resending failed messages. In deployments where redundancy is a must, a backup KAP can monitor the primary KAP policies. In the event of a failure, the backup KAP will perform a network rekey and take over operation automatically until the primary KAP returns to operational status. The KAP reports status information to the MAP not only for itself, but also for its protected CEP units.
CipherEngine CipherView: CEP Configuration and Management
CipherView is the appliance management feature of CipherEngine. It provides configuration, software updates, maintenance functions and troubleshooting capabilities for the CEPs. CipherView provides the ability to provision and manage multiple CEPs from a central location. The primary tasks that CipherView supports are:
- Defining CEP configuration
- Pushing configurations to CEPs
- Upgrading CEP software
- Comparing configurations
- CEP maintenance and troubleshooting
The family of network encryptors are wire-speed encryption appliances providing flexible IP packet encryption, Ethernet Frame encryption or TCP/UDP payload-only encryption in a single appliance.
The CEPs operate in what is called “Network Mode”. Network Mode actually includes a number of functions, including:
- Copying the inner IP addresses on a packet to the outer tunnel addresses
- Copying the original MAC addresses to the outbound packet
- Disregarding the anti-replay count check on inbound traffic as multiple sources may be generating the packet for the same data flow
The CEPs are available in three models, offering full-duplex wire-speed encryption at 10Mbps, 100Mbs or 1Gbps.
The Future of CipherEngine
In the next version of CipherEngine, many new features will be added that will ensure that CipherEngine will continue to meet the needs of any-to-any networks. The next release, critical items that rarely change (policies, keys) will be stored in a centralized, networked "space" with fully redundant backup. Access to this core space will be through a number of distributed, dynamic instances that maintain cached information. With this new “spaces” concept, endpoints can request information either as needed (rekey), on a periodic basis (policy check), or will have policies and keys pushed to them.
Providing access to the Space is a collection of services that implement the actions required by CipherEngine. These services may coexist on the same platform as the Space or can be on independent platforms for scalability. If on two platforms, the second acts as a backup to the first providing failure redundancy. The platform hosting the services and a Space implementation is referred to the CipherEngine Services Platform (CSP). A CSP may host all services and a Space, only the services, or only a subset of the services as needed.
In order to support this dramatic increase in scale, CipherEngine will also provide dynamic status monitoring that updates as the state of an endpoint changes (as when a CEP fails on a rekey or a policy is successfully delivered when a CEP comes online). This status monitoring will occur even if the MAP is offline, but is reflected dynamically when the MAP is running.
The MAP will also provide additional support for larger policies - sorting, filtering, named locations, and a dashboard display of status.
To address the needs of the enterprise customers, CipherEngine has also added identity-based user access and auditing. There can be multiple MAP viewers who can monitor the network but not modify it, and there is a MAP administration capability for configuring the system.
CipherEngine will also provide an internal Certificate Authority, which interfaces to clients in the MAP, CSP and CipherView. From CipherView, the administrator will be able to connect to the CA and log in. Then the system will generate a certificate request from the CEP. The CA signs and returns the signed certificate and trusted root certificate to be installed at the CEP.
Managing the policies and monitoring the status will still be performed via the MAP. The MAP will be a standalone application that communicates with the services and CEPs via the Space. The MAP will no longer maintain any local information on the policies or network this will now be stored in the Space and accessed by the MAP for display or modification.
Conclusion
Adding data security to today’s networks does not have to be overly complicated. While one could get the job done by spending the time and expense necessary to configure an IKE tunnel for each possible connection from each endpoint router, the availability of CipherEngine makes that option unnecessary and impractical. Hopefully, this whitepaper has provided its’ readers with an understanding of the real issues that come from using IKE for network encryption and how CipherEngine eliminates these issues.
Whether you have an MPLS network, Layer 2 Carrier Ethernet network, or even a network that is internal to the private enterprise network itself, CipherEngine provides a highly scalable, easy to implement and low-cost solution to protect your data in motion.
CipherEngine has been successfully deployed in a number of network scenarios and has proven that network encryption can be easily deployed and managed and can operate in a network environment without impacting performance. Simply put- when you need to encrypt your data, CipherEngine is the right tool for the job.
