If you receive errors when attempting to view this white paper, please install the latest version of
Adobe Reader.
"At CipherOptics, we make data protection simple. Whether you need to secure
data flows over your application environment or encrypt data in motion across the network, CipherOptics makes it easy."
Source : CipherOptics
Network Security Best Practices: Competitive Analysis
Network Security is also known as :
Network Security Best Practices,
Computer Network Security,
Network Security Assessment,
Network Security Basics,
Network Security Business,
Network Security Companies,
Network Security Definition,
Network Security Guide,
Network Security Hardware,
Network Security Information,
Network Security Infrastructure,
Network Security Issues,
Network Security Management,
Network Security Market,
Network Security Monitoring,
Network Security Protection,
Network Security Protocols,
Network Security Report,
Network Security Risks,
Network Security Software,
Network Security Solutions,
Network Security Specialist.
Introduction
The purpose of this whitepaper is to provide background about the present state of key distribution
technologies and in particular:
- Recent RFCs from the IETF MSec Working Group (RFCs); in particular RFC 3547, Group
Domain of Interpretation (GDOI) and RFC 4335, Group Secure Association Group
Management (GSAKMP);
- Cisco’s Dynamic Multipoint Virtual Private Network (DMVPN), with the additional requirement
of Multipoint GRE (mGRE) and Next Hop Resolution Protocol (NHRP) as detailed in RFC
2332.
From a comparative perspective, a description of CipherOptics’ CipherEngine is provided as a comparison
between CipherEngine and these other key distribution technologies, including the benefits and advantages that
CipherEngine is bringing to the marketplace.
Previous Key Distribution Technologies
In order to better understand CipherOptics’ CipherEngine, a quick review of present centralized key
distribution mechanisms such as Key Distribution Center (KDC) is in order.
For networks with a large number of nodes, KDCs were conceived to enable the authentication and the
confidentiality of communications between these nodes. Any new node being added to the network that needs
to establish a secure channel with another node needs to first contact a KDCs for a shared secret key. A wellknown
protocol for KDC is the Needham and Schroeder secret key authentication protocol. Based on the
Needham and Schroeder protocol, Kerberos provides security services to nodes and clients that access servers
over secure channels.
PKI, for public-key certificates, is another obvious form of centralized security services which was billed as
providing a universal key distribution capability for the network, but which has generally failed to fulfill many
of the original benefits and capabilities initially promised with this approach.
IETF MSec Working Group RFCs
More recently, the IETF MSec Working Group has been working toward key distribution from a single entity
called a group controller or key server, usually for protection of an IP multicast1 communication to members of
a multicast group.
Group Domain of Interpretation (GDOI)
The IETF MSec Working Group has proposed GDOI as defined in RFC 3547 as a method of creating and
identifying groups within a network; this effort is being led by Cisco Systems. GDOI requires Internet Key
Exchange (IKE) phase I in order to establish a secure channel for distribution of the key and replaces IKE
phase II for the generation of the keys for the members of the multicast group.
When using these technologies, group members first register with the key server, which authenticates and
authorizes them and then downloads the IPSec policy and keys needed to encrypt and decrypt the IP Multicast
packets. Group members can then exchange IP Multicast packets that are encrypted using IPSec tunnel mode.
As needed, the key server may push a re-key message to the group members in order to rotate keys at specified
times during the transmission or to de-authorize a particular group member.
GDOI Components
Cisco has implemented the GDOI’s key server capability in its Cisco 1800, 2800 and 3800 Series ISR and Cisco
7206 VXR and has enabled the Cisco 830 through 7200 VXR/7300 routers to participate as GDOI group
members.
Group Secure Association Group Management (GSAKMP)
The IETF MSec Working Group also has proposed GSAKMP as defined in RFC 4535. With GSAKMP, a
group controller generates the keys, but the distribution of these keys is defined in a completely new protocol
that does not rely on IKE. GSAKMP provides a new framework for creating and managing cryptographic
keys for multicast groups in a network.
GSAKMP’s major protocol features include:
- Dissemination of group policy and the authentication of nodes/users;
- Performing access control decisions during group establishment and recovery,
- Recovering from the compromise of group members;
- Delegation of group security functions;
- Destruction of the group when required;
- Generation of group keys.
Both GDOI and GSAKMP are currently limited to IP multicast security.
Cisco’s Dynamic Multipoint Virtual Private Network
(DMVPN)
Cisco DMVPN approach is aimed primarily at keeping routing protocols operating over an encrypted IPSec
network.
Cisco’s Generic Routing Encapsulation (GRE), initial RFC 1701, provides a simple and stateless mechanism
over an IP network to encapsulate other network protocols (IP as well as legacy protocols). GRE tunnels can
be secured using IPSec tunnels when operating IPSec in transport mode. Cisco has been implementing IPSec
with GRE for the securing of:
- Mesh networks: Setting up IPSec Security Associations (SAs) between every meshed
point/spoke in the network using the hub;
- Hub and Spoke networks: Setting up IPSec SAs between each spoke and the hub in the
network. All traffic between spokes must be routed through the hub.
IPSec and GRE work if traffic patterns are well known, but are very difficult, and operationally complex, to
enable connectivity for partial meshes and for spoke-to-spoke connectivity. Cisco’s DMVPN attempts to
overcome the limitations of using IPSec with GRE for dynamic mesh connectivity and for spoke-to-spoke
connectivity.
DMVPN provides a configuration for a mesh VPN based on the premise that the only relationship configured
are those between the hub and each spoke. DMVPN relies on Cisco’s:
- Multipoint GRE (mGRE);
- Next Hop Resolution Protocol (NHRP) as detailed in RFC 2332.
mGRE provides a point-to-multipoint interface for DMVPN. It enables a single interface to terminate
multiple GRE tunnels and therefore allows a single GRE interface to support multiple IPSec tunnels.
NHRP associates a spoke’s public IP address with its private configured mGRE interface address. When a
spoke initiates a connection to the hub, it registers with the hub via NHRP. This process binds the spoke
mGRE interface to that spoke’s dynamic public IP address. The spoke can then establish a unidirectional
tunnel with another spoke. For the other spoke to return traffic it must go through the same process, which
can have a dramatic effect on latency sensitive applications such as VoIP and video.
CipherOptics’ CipherEngine
CipherOptics’ CipherEngine is a tiered security architecture that provides security services - confidentiality,
authentication and entitlement - between communicating entities. CipherEngine is based on centralized policy
definition, scalable key and policy distribution, and support of a variety of secure end points. The secure end
points can be servers, workstations, cell phones, PDAs, data storage devices, applications, etc. in addition to
the traditional network elements.
Key to the CipherEngine architecture is the concept of secure end point grouping. Grouping end points that
share a common security policy is central to delivering a global security solution that both scales and is
manageable while still offering entitlement control and enforcement.
CipherEngine utilizes a three-tier approach to provide its security services:
- MAP: The Management and Policy Server (MAP) is the central policy server. Policies define
how end points are grouped and which groups are entitled to communicate with each other.
Policies can be generated manually, but can also be automated through an interface to Active
Directory, LDAP, or customer billing system, for instance.
- KAP: The Key Authority Point (KAP) generates SAs and encryption keys, according to the
security policies, and then distributes these to PEPs and peer KAP devices as needed. The KAPs
recognize end point groups and will distribute shared SA content to multiple end points within
the same group. KAPs also synchronize the re-keying of existing SAs when key lifetimes expire
and need to be refreshed or when a node has been compromised and a re-key is required to
exclude that node from the group.
- PEP: The Policy Enforcement Points (PEPs) are the security end points managed by the KAPs.
The PEP devices exist in the network to protect traffic that flow between them, but rather than
exchanging keys on a one-to-one basis with other PEPs, as with traditional IPSec using IKE for
instance, they receive their SAs and key information externally from the KAP over a secure
connection.
Within the CipherEngine architecture, the KAP can be viewed as the control plane and the MAP as the
management plane as represented in a traditional encryption architecture. The MAP and the KAP together
create a transparent overlay to an existing network that provides end-to-end security services using PEPs as
enforcement end points within the network.
Within the CipherEngine architecture, a MAP and a KAP are required at minimum, but multiple KAPs can be
distributed throughout the network. This is an advantage over other key server technologies, as a backup key
server (KAP) can be deployed in a federated fashion in order to assure operational uptime and scalability. For
a large enterprise with multiple remote sites, multiple MAPs can also be deployed to manage specific segments
or sites within the network. This distributed architecture, coupled with the grouping of end points (PEPs),
allows the CipherEngine solution to scale for extremely large network deployments.
Each individual component of the CipherEngine solution is secured using similar technologies found in other
network security appliances, but the entire system as a whole (MAPs, KAPs and PEPs) is also secured. Each
component engaged by another component in the solution authenticates each other prior to establishing
communications. The CipherEngine solution also ensures that no compromised unit can continue to
participate in the security association. And furthermore, all communications between components of the
CipherEngine solution are encrypted.
The CipherEngine solution provides as a key feature resilient key generation and distribution operations. The
KAP can either be used singly or in a resilient manner with a back-up stateful KAP. Every PEP in the solution
maintains a primary association with one KAP and a backup association with a back-up KAP, with each KAP
being able to provide all policy and keying information to its PEP. In addition, the KAPs communicate with
each other, creating grouped peers and enabling network-wide scalability down to the node point.
CipherOptics’ CipherEngine solution provides policies and keys for various network topologies such as pointto-
point between two sites, a full mesh-of–sites or nodes, and hub-and-spoke site topologies. Policies may also
be defined for multicast or broadcast application if multicast or broadcast communications are enabled
between the sites.
CipherEngine Benefits versus other Key Distribution
Technologies
Cisco’s DMVPN is a network-based technology that has been developed to enable IPSec to scale over large
meshed networks. Consider how difficult it was to use existing IPSec technology to secure a mesh network
prior to DMVPN:
- With multiple network sites and multiple networks to secure, policy definitions simply don’t scale
- Network routers need to support thousands, if not tens of thousands, of policies
- Routers don’t have the capacity to handle the policy load or the performance required
With DMVPN:
- Policies are stored in hub routers
- Peer addresses are stored in hub routers
- Spoke routers use the hub to dynamically set up mesh communications
- mGRE is used to support multicast communication
- IPSec and IKE are used to set up point-to-point tunnels
So, DMVPN was a step forward over traditional IPSec technologies, enabling additional scale to the problem
of securing larger mesh IP networks. But DMVPN created significant problems as well:
- A hub and spoke network was forced on top of the existing IP architecture
- It added significant complexity to remote routers – requiring the use of NHRP and mGRE to
even make it work
- Extremely complex Hub router configurations were required
- It increased setup time for establishing secure sessions
- GRE setup for multicast traffic doesn’t scale
DMVPN, though better, has simply created too much complexity for the technology to be employed on a
general basis to secure large, fully meshed networks.
GDOI and GSAKMP are yet additional technologies employed to allow multicast to be used and scale within a
DMVPN deployment. The DMVPN solution by itself simply could not satisfy these additional requirements.
While these combined technologies do employ centralized key distribution, they are limited to solving a very
specific problem, namely multicast.
Advantages of CipherEngine
A comparison between DMVPM/GDOI and CipherEngine illustrates very significant differences and
advantages. The major advantages of CipherEngine are:
- CipherEngine is a security architecture that overlays any type of network topology and is not
itself a specific network technology
- CipherEngine uses groups to simplify deployment and implementation of this security overlay
and uses these groups to simplify the definition and enforcement of security policies
- CipherEngine reduces the complexity of security implementation by an order of magnitude (in
side by side comparisons for example, a router configuration can be reduced by up to 75% when
using CipherEngine versus DMVPN; it even further reduces the configuration requirement
versus DMVPN when using GDOI and mCAST)
- CipherEngine reduces the total cost of ownership (TCO) by significantly reducing the
Operational Expense (OpEx) associated with managing the deployment and any futures moves,
add or deletes in the router configuration
- CipherEngine is a transparent overlay to the network – no change to the network is required in
order to implement the security overlay
CipherEngine is a Security Architecture
One primary difference between CipherEngine and DMVPN/GDOI is that CipherEngine is a scalable security
architecture that can be applied to a broad set of security needs:
- CipherEngine provides centralized policy definition to enable network-wide policies and policy
definition
- CipherEngine delivers inherent scalability to secure even the largest meshed networks
- CipherEngine secures, yet does not break, any IP network services such as multicast, broadcast,
load balancing, and resiliency
- CipherEngine secures IP networks in hub and spoke, full mesh, point-to-point, and multicast
designs
- CipherEngine secures communications between groups of gateways, devices, applications, data
storage, or users connected to the network
As a security architecture, CipherEngine can be applied to end user security needs. Today many IP security
solutions are router based. In the future, as security end points move closer to the user, a more expansive
architecture is needed, one that can be expanded to satisfy an end user’s security needs. CipherEngine is being
offered as just such an architecture. Today’s DMVPN and GDOI/GSAKMP products are network
technologies that attempt to solve specific network configuration problems, but lack the ability to scale their
capabilities out to the end point due to their inherent complexity and lack of scalability.
CipherEngine uses Security Groups
A cornerstone of the CipherEngine architecture is the use of security groups. The following diagram depicts a
network design that has two groups defined. These groups may be structured based on functional boundaries
such as HR, Finance and Engineering or by specific location – Dallas, New York, etc. A PEP can be part of
one or multiple groups. By grouping secure endpoints together, global security policies can be defined that can
easily implement entitlement and security services for all members of the group. This greatly simplifies the
configuration of the solution and allows for the use of group policies and keys to solve the issues of scale and
manageability.
In this network design example, different locations are grouped together as defined in the MAP. Traffic is
separated by group designations and security policies and keys are applied accordingly. For instance, a member
of the green group can’t talk to a member of the red group and vice versa, without also being a member of the
other group. Also, in this basic example, traffic can flow easily and without interruption between sites that
have redundant access. For example, traffic flowing between the redundant sites can flow through any PEP
because they are members of the same group and share the same SA information and keys. The support for
redundant access and load balancing is yet another advantage of using groups for security implementation.
Multicast applications are supported natively within this design. A multicast IP service, IPTV for instance,
simply uses a group policy and key for that multicast address.
To further highlight the IPTV example as part of a Service Provider (SP) design, a set top box would act as the
PEP with the integration of a very basic and inexpensive encryption capability. The authentication and
entitlement system in use for this solution is the SP’s subscriber billing system, which interfaces to the MAP
where the SP’s group and subscriber entitlement are correlated to CipherEngine security policies. The MAP
then pushes these policies to each of the KAPs in the network, which in turn distribute both policies and the
associated keys to each set top box as dictated by the policy.
For basic IPTV broadcast, a broadcast group policy and key are pushed to each subscriber of the basic IPTV
channel offering. A multicast group policy and key are created for each of the premium services that are
offered (such as HBO, Disney and Showtime) and are pushed only to the set top boxes of those subscribers
purchasing these premium-viewing services. A unicast policy and key are used for special one-time services
such as pay-per-view and are only pushed to the set top box of the subscriber signing up to view these special
one-time services. Unicast policies and groups are also used to secure and segment the traffic for a subscriber’s
data and telephony services, securing these transmission to/from their set top box back to the SP’s central
office.
CipherEngine Dramatically Reduces Complexity Versus DMVPN
Another real advantage of CipherEngine is the dramatic reduction in complexity associated with the
implementation of the security policy. Consider the earlier diagram that highlighted the grouping concept:
Using DMVPN
- First requires the implementation of a Hub and Spoke network with Hub site running NHRP to
each of the spokes
- mGRE tunnels are required between all spokes and the Hub
- mGRE tunnels are required between each of the spokes
- Crypto commands (security policy) must be configured into each of the hub and spoke routers
- Policies then need defined for traffic between hub and spokes and between each of the spokes to
create a mesh
- IKE sessions are also required between the spokes and hub and between each of the spokes to
create a mesh
- Router policy complexity – four to five times the configuration information are required for just a
basic mesh and even more to implement a multicast capability
- The time required to set up the basic network in this example – days or even weeks
- The time required to set up for a very large network - almost impossible to achieve, much less to
quantify
Using CipherEngine
- Only two network policies needed to be defined – one for each group
- Depending on the specific requirement, these could be either mesh or hub and spoke
policies
- The solution is scalable to any number of sites with just these two policies.
- Hundreds or even thousands of sites could be added to either group, but there would still
only need to be these original two policies
- Multiple KAPs can be added throughout the network to scale to any number of PEPs and to
provide for stateful failover
- Policy setup time – less than 5 minutes
- Greatly reduced complexity in router configurations and no change to an existing routed network
would be required to implement this security overlay
- No dependence on GRE, NHRP, IKE or other complex and less scaleable and manageable
technologies
CipherEngine Reduces TCO
CipherEngine greatly reduces the ongoing costs of day-to-day operations and reduces the downtime associated
with changes in the security infrastructure. Take for example, adding a new site to the network. With
CipherEngine, that site is simply added to the appropriate group. Policies and keys are then distributed to the
new PEP and that site is immediately operational and secure. This process would only take minutes and
involve a simple group entry within the MAP.
In the DMVPN case, hubs and spokes in the network would each need updates with new NHRP and mGRE
commands. If this were a large mesh network, this task would be prone to error and would be extremely time
consuming to implement.
CipherEngine is Transparent to the Network
CipherEngine is implemented with no impact or required change to the network configuration or design.
Using today’s CipherEngine implementation, gateways installed as PEPs are neither routers nor switches and
maintain the original IP addressing on packets being secured and forwarded. CipherOptics’ PEPs are bump-inthe
wire devices that maintain theoretical IPSec wire rate throughput with extremely low latency, and do not
require the change any next-hop or default gateway settings.
The goal of CipherEngine is to be a transparent security overlay on top of an existing network. If IPSec is
already implemented on the network, the router configurations could be greatly simplified by using
CipherEngine, allowing the routers to perform just their intended function - routing. Of course, this would
mean pulling commands out of the router configurations, but the resulting reduction in complexity and
maintainability alone would be immensely valuable to the network operator.
Conclusion
CipherOptics’ CipherEngine is a bold new concept and revolutionary approach in the delivery of security
services for IP networks. Compared to existing network technologies, CipherEngine greatly reduces the
complexity and cost of applying security to an existing IP backbone. At the same time it accomplishes this,
CipherEngine enables new levels of scalability and manageability while delivering the additional advantage of
being completely transparent to the network. Furthermore, CipherEngine is a security architecture that can be
the framework for new security services in the future that encompass a broad range of end user devices and
applications.
About CipherOptics
CipherOptics, the leading innovator of Compliance-Grade™ network security, delivers peace of mind to the
most security conscious enterprises, financial institutions and government agencies in the world. CipherOptics’
method of decoupling network security from network infrastructure enables unparalleled Secure Information
Sharing. Our Safe Passage ™ data protection solutions are transparent to any network topology and offer the
shortest time to protection and the lowest management overhead.
For more information: www.CipherOptics.com
A Comparison with IETF’s MSec and Cisco’s DMVPN
A perspective on the differences in deployment and
complexity between CipherOptics’ CipherEngine versus
IETF MSec Working Group’s RFCs and Cisco’s DMVPN for
building, scaling and managing large deployments
Table of Contents
- Introduction
- Previous Key Distribution Technologies
- IETF MSec Working Group RFCs
- Group Domain of Interpretation (GDOI)
- Group Secure Association Group Management (GSAKMP)
- Cisco’s Dynamic Multipoint Virtual Private Network (DMVPN)
- CipherOptics’ CipherEngine
- CipherEngine Benefits versus other Key Distribution Technologies
- Advantages of CipherEngine
- CipherEngine is a Security Architecture
- CipherEngine uses Security Groups
- CipherEngine Dramatically Reduces Complexity Versus DMVPN
- CipherEngine Reduces TCO
- CipherEngine is Transparent to the Network
- Conclusion
- About CipherOptics