As the use of SSL continues to grow there is a need to expand its use to other than Web-based applications. Some vendors have developed SSL gateways that are basically conversion tools to convert a browser based session to another application. In order to expand the use to other applications, SSL VPN providers are delivering client software that converts SSL to operate at the IP/Network layer. This enables security for a broader set of applications--especially important for non-TCP based applications such as VoIP that is UDP based.
However, with its placement above the transport layer, TLS/SSL requires either all applications to be "Webified" (either through protocol conversion or application change) or clients to be loaded on each end-station. Webifying all applications can be very costly. In addition, SSL technology was designed for end-client security. Many of today's needs are from remote branch to data center, data center to remote backup facility, secure communication over MPLS or Metro Ethernet. As the need to protect all data grows, protecting this traffic requires a more global approach to security and can not be solved by client to server browser-based encryption solutions.
Is there an encryption technology that can secure all applications over any network architecture?
IPSec
IPsec (IETF RFC 2401--2409) is a standard defined to secure selected traffic over an IP network. Figure 3 highlights its placement in the application stack.
The stack placement enables IPsec to secure all IP traffic, Web, non-Web, VoIP, FTP or Telnet. IPsec is well understood and provides for confidentiality (encryption), source authentication, data integrity, and anti-replay. Today, IPsec is used for remote access client access and site-to-site communication.
IPSec has advantages over the other approaches:
- IPSec can be implemented either on the client or in a gateway appliance or router. As a gateway, IPSec can be used to secure many clients with a single policy and a single set of encryption keys.
- Users can be grouped by IP addresses or Transport layer port number enabling security on a specific IP stream or specific application without any workstation impact or change.
- IPSec can secure all IP traffic, whether it is FTP, Telnet, IPTV or VoIP.
- IPSec enables a full set of security services and functions as a stateless firewall enabling or denying access to secure resources.
IPsec also comes with disadvantages:
- Network-wide IPsec implementations tend to be complex to configure and manage.
- IPsec requires client software for remote access environments.
Link layer encryption
Link layer encryption is applied to protect specific network segments. These segments could be frame relay DLCIs, DWDM wavelengths, or Ethernet segments. Link layer encryption secures all traffic and can be used in cases where traffic is not IP.
The advantages of link-layer encryption are based on ease of implementation. Everything is encrypted between two end points and usually no security policy definition is required. Link layer encryption is perfect for point-to-point applications with no IP/Network layer instance.
Therein lies the problem of link-layer encryption. Over IP networks, to implement link-layer encryption, encryptors (or encryption) would be required between each network layer device. A new draft standard IEEE 802.1AE has been defined to implement link-layer encryption between communicating devices over any link segment. In this approach, each link segment would encrypt and decrypt traffic using separate keys for each secure link operation.
The solution?
As regulations push enterprises to rethink security strategy, and securing traffic in motion becomes a requirement, multiple encryption methods will be implemented to satisfy specific encryption standards. However, a new model is necessary to implement and manage a cohesive security strategy.
First and foremost, security policy must be consolidated to one entity. Today, security policy is split between all the technologies providing security services: firewalls; IDS/IPS; data protection; and, identity management. For data protection, common security policy should be in place to implement encryption whether application, SSL or IPSec. A common policy platform would enable a global set of rules such as resource entitlement (access based on groups of users, applications, or devices and implementation specifics).
Secondly, for data protection, key negotiation and exchange can not limit network or application services. Encryption implementation today requires two end points to authenticate each other and exchange keying material. This sets up a point-to-point communications tunnel between the end points. As the need for data protection implementation grows the scalability of this approach is questionable. Imagine point-to-point tunnels to hundreds, if not thousands, of end points. Point-to-point key management is extremely difficult at best, and impossible in large mesh networks tying together thousands of end users.
The security model must separate key management from the end point devices. Key management should: leverage policy rules to enable grouping of end points, storing and archiving keys; generate and distribute keys to end points; and, provide the security policy interface to the end points.
Third, we need to start looking at security end points as any device or application (PDA, cell phone, software, router or switch). As we move to a security model where all end points are security enforcement points, the model needs to accommodate any type of device or software and reduce complexity as much as possible.
This security model would appear as:
The model leverages a common policy of separate encryption key management, thus improving data protection. New technologies and an improved enterprise data protection architecture are necessary to provide this model of data protection.
About the Author
Rod Starrett has over 30 years experience in data networking and security in technical, marketing and sales roles. Prior to joining CipherOptics, he helped develop Cisco's Internet content strategy for service providers and led the delivery of Cisco's first content offerings. In earlier product management roles at Cisco, Mr. Starrett was responsible for product strategy and development of IBM SNA/IP migration solutions. Prior to Cisco, Mr. Starrett was the Director of Sales at Netlink Inc. where he led an international sales team, including technical sales and business development. Prior to Netlink, he held a number of product development and engineering management roles in startups in the Raleigh, NC area. He can be reached at: [email protected]
See recent related articles by Rod Starrett at Network Systems DesignLine:
Protect critical customer data in 15 minutes
How to protect data in an IP world
