By replacing private dial modem pools with inexpensive Internet-based access, VPNs can reduce the cost of remote access for travelers, teleworkers, and day extenders. In studies conducted last year by TeleChoice and Lucent NetCare, respondents cited remote access as their top reason for adopting VPN technology. But, in a May 2000 Infonetics report, two of the top 10 barriers to implementing VPNs were difficulty supporting remote access VPN users and difficulty managing authentication mechanisms.
What's the problem? When deploying a remote access VPN, challenges that must be mastered include client software installation and configuration, dynamically assigned addresses, and reliable user authentication. In today's column, we'll focus on issues associated with user authentication—the mechanisms used to verify user identity.
Device-level authentication
IP Security (IPsec) was designed for secure site-to-site (gateway-to-gateway) and remote access (client-to-gateway) tunneling between mutually authenticated devices. IPsec can protect tunneled packets against spoofing, modification, replay, eavesdropping, and other man-in-the-middle attacks. But, in order to trust anything received over an IPsec tunnel, one must first verify the sender's identity.
The standard used to accomplish this is called the Internet Key Exchange (IKE). IKE authenticates devices: the security gateway or client host at each end of an IPsec tunnel. Several authentication methods are supported; the most basic is pre-shared key. In this method, devices "A" and "B" are configured with the same key. Device "A" uses the key to encrypt and send a known value to Device "B". Host "B" decrypts the incoming packet, using the key associated the packet's source address. If successful, Host "B" believes that Host "A" is authentic.
Pre-shared keys are easy to deploy on a limited scale—for example, a modest site-to-site VPN. In larger VPNs, assigning unique keys to each gateway-gateway or gateway-client device pair becomes unwieldy. Furthermore, with IKE "main mode", a group of devices that share a pool of dynamic addresses—a very common remote access scenario—must use the same pre-shared key. But any key, known to an entire group, is more easily compromised.
Stronger authentication can be accomplished through public key cryptography. Public keys may be used alone ("raw") or embedded in X.509 digital certificates. In small VPNs, public/private key pairs and certificates can be configured manually or with simple device management tools. In larger VPNs—such as those involving many remote users—a Public Key Infrastructure (PKI) can be used to manage certificate enrollment, distribution, and verification.
Why can't I just use RADIUS?
Few companies are anxious to build their own PKI or purchase a managed PKI service solely for remote access. Instead, many would like to continue "legacy" authentication methods that are almost universally employed for direct-dial remote access today. In a survey of 175 companies conducted by Lucent NetCare, 57 percent wanted to use RADIUS authentication with their remote access VPN. Other popular legacy methods include TACACS+, two-factor tokens like SecurID, and one-time passwords.
Unfortunately, none of these legacy methods are directly compatible with standard IKE. Recall that IKE provides mutual (two-way) device-level authentication. Legacy methods like RADIUS provide one-way user-level authentication. Typically, the user provides his credentials (e.g., name and password) through some type of challenge-response interaction—open-ended interaction that is not supported by the current IKE standard.
Square peg, round hole
Fitting legacy authentication into IKE is like trying to insert a square peg into a round hole. They weren't made for each other, but you can pound the peg into the hole if you try hard enough.
The IETF didn't really overlook legacy user authentication. It started working on this challenge years ago, when the IKE standard was still underway. XAUTH, an IKE extension to accommodate legacy authentication, was first proposed in December 1997. Another approach called Hybrid was proposed in June 1998. But there was little industry consensus on the best solution, or even the problem. Some expected PKI to be deployed faster than it has been. Others argued that IKE should not be (further) complicated by legacy authentication. In March 2000, after a full year of charter debate, a new IPsec Remote Access (IPSRA) working group was formed to focus on remote access requirements.
http://www.isp-planet.com/technology/remote_access_conundrum-1-1.html
Friday, October 5, 2007
Speeding Deployment from the Center:eTunnels VPN-on-Demand
In September, eTunnels launched VPN-On-Demand, a unique "instant VPN" service. According to CEO Dimitri Sirota, VPN-On-Demand was designed to meet the top challenges involved in high volume service deployment. "The principals who formed this company worked with carriers that used CheckPoint FireWall-1 and Cisco PIX to build VPNs," said Sirota. "These CPE solutions were complex to deploy and didn't support Extranet very well. They were also hard to budget. This is the origin of VPN-On-Demand."
VPN-On-Demand 1.0 is aimed at providers who want to offer remote access VPN services to the SME market. The fundamental premise: keep VPN simple by making the network smart. eTunnels centralizes enrollment, provisioning, and policy enforcement to speed delivery and reduce cost. The upcoming 2.0 release (now in beta) adds centrally-managed CPE for site-to-site and Extranet VPN services.
Intrigued by this pitch, we took VPN-On-Demand 1.0 for a test drive. We found that this service lived up to its name: with an on-line wizard and software, we created a 3-member PC-to-PC VPN in about an hour. While this service is very simple to use and deploy, there are also limitations. Here's what we found.
The Foundation: eNS
As with other IPsec-based services, customer networks created by VPN-On-Demand provide encrypted communication between authenticated members. In release 1.0, IPsec ESP DES or 3DES tunnels carry traffic between client and server PCs. Release 2.0 adds software and hardware IPsec gateways—devices that terminate WAN tunnels, providing secure access to entire LANs.
But VPN-On-Demand places unusual emphasis on centralized, automated provisioning. Tunnel endpoints don't have to be individually configured with security policies, as in many VPNs today. Configuration and software updates flow from a central source: the eNS (eTunnels Network Server). "eNS operates as a service—like DNS, but for security," explained Sirota.
The eNS tracks VPN membership, state, security parameters, network topology, and resource locations. "Some customers want a worker visiting a customer site to be able to connect into their home network using the customer's network—sort of a hybrid of remote access and Extranet," said Sirota. "In this case, the client may be behind DHCP and a firewall, and eNS needs to understand network topology to make this all work."
The eNS is also a policy enforcer—a traffic cop. Each member of the VPN—client, server, or gateway—initiates an SSL connection to the eNS. The eNS authenticates the member, generates session keys, and orchestrates tunnel setup. An IPsec tunnel is established between the new member and every other active member (a fully-meshed VPN). There are no filters for specific protocols or source/destination pairs—every member is granted full access to the entire VPN. The eNS tracks element status and works to keep this fully-meshed network afloat at all times.
After setup, traffic is tunneled directly between VPN elements, using a point-to-point rather than hub-and-spoke tunnel topology. "This gets us out of the call, and lets us avoid the trust and latency issues that have impacted some other Extranets, like ANX," said Sirota. "If the eNS should go down, tunnels would not be impacted."
Nonetheless, placing so much control and real-time processing at the network center does raise reliability and scalability concerns. Naturally, the eNS is not just one monolithic server. It is a set of servers, hosted at multiple data centers for geographic redundancy. eNS servers are front-ended by L4 switches and back-ended by an Oracle 8 database. With VPN-On-Demand's centralized architecture, eTunnels must clearly do everything possible to prevent the eNS from becoming a single-point-of-failure—and to protect this juicy target from being hacked.
http://www.isp-planet.com/technology/etunnels1.html
VPN-On-Demand 1.0 is aimed at providers who want to offer remote access VPN services to the SME market. The fundamental premise: keep VPN simple by making the network smart. eTunnels centralizes enrollment, provisioning, and policy enforcement to speed delivery and reduce cost. The upcoming 2.0 release (now in beta) adds centrally-managed CPE for site-to-site and Extranet VPN services.
Intrigued by this pitch, we took VPN-On-Demand 1.0 for a test drive. We found that this service lived up to its name: with an on-line wizard and software, we created a 3-member PC-to-PC VPN in about an hour. While this service is very simple to use and deploy, there are also limitations. Here's what we found.
The Foundation: eNS
As with other IPsec-based services, customer networks created by VPN-On-Demand provide encrypted communication between authenticated members. In release 1.0, IPsec ESP DES or 3DES tunnels carry traffic between client and server PCs. Release 2.0 adds software and hardware IPsec gateways—devices that terminate WAN tunnels, providing secure access to entire LANs.
But VPN-On-Demand places unusual emphasis on centralized, automated provisioning. Tunnel endpoints don't have to be individually configured with security policies, as in many VPNs today. Configuration and software updates flow from a central source: the eNS (eTunnels Network Server). "eNS operates as a service—like DNS, but for security," explained Sirota.
The eNS tracks VPN membership, state, security parameters, network topology, and resource locations. "Some customers want a worker visiting a customer site to be able to connect into their home network using the customer's network—sort of a hybrid of remote access and Extranet," said Sirota. "In this case, the client may be behind DHCP and a firewall, and eNS needs to understand network topology to make this all work."
The eNS is also a policy enforcer—a traffic cop. Each member of the VPN—client, server, or gateway—initiates an SSL connection to the eNS. The eNS authenticates the member, generates session keys, and orchestrates tunnel setup. An IPsec tunnel is established between the new member and every other active member (a fully-meshed VPN). There are no filters for specific protocols or source/destination pairs—every member is granted full access to the entire VPN. The eNS tracks element status and works to keep this fully-meshed network afloat at all times.
After setup, traffic is tunneled directly between VPN elements, using a point-to-point rather than hub-and-spoke tunnel topology. "This gets us out of the call, and lets us avoid the trust and latency issues that have impacted some other Extranets, like ANX," said Sirota. "If the eNS should go down, tunnels would not be impacted."
Nonetheless, placing so much control and real-time processing at the network center does raise reliability and scalability concerns. Naturally, the eNS is not just one monolithic server. It is a set of servers, hosted at multiple data centers for geographic redundancy. eNS servers are front-ended by L4 switches and back-ended by an Oracle 8 database. With VPN-On-Demand's centralized architecture, eTunnels must clearly do everything possible to prevent the eNS from becoming a single-point-of-failure—and to protect this juicy target from being hacked.
http://www.isp-planet.com/technology/etunnels1.html
The Remote Access Conundrum Part 2:Tunneling at Layer Two
To offer a successful remote access VPN service, an ISP must master many challenges, ranging from trouble-free client software installation to back-end user database integration. In a previous column, we discussed issues associated with remote access VPNs based on IPsec, the standard network-layer tunneling protocol. In today's column, we'll examine another alternative: the standard Layer Two Tunneling Protocol (L2TP).
Tunneling PPP
L2TP is a standard method for tunneling PPP across the Internet or any intervening IP or non-IP network. Unlike IPsec, L2TP was designed specifically to support traditional remote access.
L2TP creates a "virtual modem connection" from a dial-up client to an enterprise network. Physically, the client's call is terminated by an L2TP access concentrator at the provider's POP. But, logically, the client is connected to the customer's own network server, back at corporate headquarters. In between, L2TP encapsulates PPP and tunnels it transparently across the provider's backbone. L2TP lets the enterprise retain control over traditional RAS functions like user authentication and dynamic address assignment, while outsourcing call termination and transport functions to a service provider.
The L2TP standard was derived, in part, from Cisco's Layer 2 Forwarding (L2F) protocol and Microsoft's Point-to-Point Tunneling Protocol (PPTP). Today, there are many service providers that offer remote access VPN services based on L2TP, L2F, and/or PPTP. For example, AT&T's Managed VPN Tunneling Service supports L2TP, L2F, and IPsec. We asked Jonathan Cohen, Director of AT&T's Advanced IP Network Services, why AT&T offers so many alternatives.
Meeting customer requirements
"No one solution is going to work for all customers; there are different requirements," said Cohen. Today, over 50 percent of the data network market runs over AT&T's ATM, Frame Relay, dial, or broadband transport services. Offering value-added services like VPN to a large, diverse customer base can be quite a challenge.
"We support several tunneling protocols because we've had to meet existing customer needs," said Cohen. "We're in a different position than green-field carriers. AT&T has been offering multiprotocol tunneling for a very long time now, and we know that you have to examine each application to determine the best approach. Ultimately, VPN is an implementation, not a service. Protocol selection is a matter of deciding how to implement the VPN for a specific customer."
Choosing a tunneling protocol
To appreciate what's involved, let's examine some of the fundamental differences between these tunneling protocols.
IPsec provides digitally-signed, encrypted communication between mutually authenticated devices. IPsec is great for securing site-to-site (gateway-to-gateway) traffic over an IP backbone. It can also support secure host-to-host connections. Although IPsec can tunnel from client to gateway, extensions are usually needed to satisfy user authentication and dynamic addressing requirements.
Layer two tunneling protocols (L2F and L2TP) leverage functions provided by PPP: data-independent framing, ability to multiplex IP and non-IP network protocols, user-level PAP/CHAP authentication, dynamic address assignment, and the ability to negotiate session attributes like compression.
Cisco's L2F provides controlled, authenticated access to an entire network, reached through a "home gateway". L2F tunnels are compulsory: a client dials into a network access server (NAS). The NAS recognizes that tunneling is required and multiplexes PPP over UDP to the home gateway. L2F tunnels are completely transparent to clients, but require NAS support.
http://www.isp-planet.com/technology/remote_access_conundrum-2-1.html
Tunneling PPP
L2TP is a standard method for tunneling PPP across the Internet or any intervening IP or non-IP network. Unlike IPsec, L2TP was designed specifically to support traditional remote access.
L2TP creates a "virtual modem connection" from a dial-up client to an enterprise network. Physically, the client's call is terminated by an L2TP access concentrator at the provider's POP. But, logically, the client is connected to the customer's own network server, back at corporate headquarters. In between, L2TP encapsulates PPP and tunnels it transparently across the provider's backbone. L2TP lets the enterprise retain control over traditional RAS functions like user authentication and dynamic address assignment, while outsourcing call termination and transport functions to a service provider.
The L2TP standard was derived, in part, from Cisco's Layer 2 Forwarding (L2F) protocol and Microsoft's Point-to-Point Tunneling Protocol (PPTP). Today, there are many service providers that offer remote access VPN services based on L2TP, L2F, and/or PPTP. For example, AT&T's Managed VPN Tunneling Service supports L2TP, L2F, and IPsec. We asked Jonathan Cohen, Director of AT&T's Advanced IP Network Services, why AT&T offers so many alternatives.
Meeting customer requirements
"No one solution is going to work for all customers; there are different requirements," said Cohen. Today, over 50 percent of the data network market runs over AT&T's ATM, Frame Relay, dial, or broadband transport services. Offering value-added services like VPN to a large, diverse customer base can be quite a challenge.
"We support several tunneling protocols because we've had to meet existing customer needs," said Cohen. "We're in a different position than green-field carriers. AT&T has been offering multiprotocol tunneling for a very long time now, and we know that you have to examine each application to determine the best approach. Ultimately, VPN is an implementation, not a service. Protocol selection is a matter of deciding how to implement the VPN for a specific customer."
Choosing a tunneling protocol
To appreciate what's involved, let's examine some of the fundamental differences between these tunneling protocols.
IPsec provides digitally-signed, encrypted communication between mutually authenticated devices. IPsec is great for securing site-to-site (gateway-to-gateway) traffic over an IP backbone. It can also support secure host-to-host connections. Although IPsec can tunnel from client to gateway, extensions are usually needed to satisfy user authentication and dynamic addressing requirements.
Layer two tunneling protocols (L2F and L2TP) leverage functions provided by PPP: data-independent framing, ability to multiplex IP and non-IP network protocols, user-level PAP/CHAP authentication, dynamic address assignment, and the ability to negotiate session attributes like compression.
Cisco's L2F provides controlled, authenticated access to an entire network, reached through a "home gateway". L2F tunnels are compulsory: a client dials into a network access server (NAS). The NAS recognizes that tunneling is required and multiplexes PPP over UDP to the home gateway. L2F tunnels are completely transparent to clients, but require NAS support.
http://www.isp-planet.com/technology/remote_access_conundrum-2-1.html
Subscribe to:
Posts (Atom)