home
NEWS       BLOGS       FORUMS       NEWSLETTERS       RESEARCH       EVENTS       DIGITAL LIBRARY       CAREERS  
Network Computing Network Computing Powered by InformationWeek Business Technology Network

IMMERSE YOURSELF:

SOA

  |

Data Center

  |

802.11n

  |

Data Privacy

  |
APO  |

Virtualization

  |

NAC

  |

Security

  |

Network Mgmt

  |

Enterprise Apps

  |

Storage & Servers



  W O R K S H O P

The Trouble With Multivendor IPsec

March 20, 2000
By Mike Fratto

Supporting remote users over different connectivity strategies--cable, DSL or modems--or from a LAN-attached network becomes more complicated and more necessary every day. It's the need to secure communications to end users regardless of their location that makes remote access so complex. VPNs solve this problem to a large extent, but not without some headaches.

More important, in the world of outsourced and temporary workers, consultants and fleeting trading partners--all of whom may be geographically dispersed--the need to secure communications over public networks becomes mission-critical. In a single vendor environment, VPN solutions connect users easily and securely from the remote desktop to the local network. But in most cases, you can't dictate specific software packages for use by external organizations.

Unlike LAN-to-LAN VPNs, an IPsec (IP security) VPN is particularly onerous (for more on IPsec interoperation, see "Making IPsec Work for You," at www.networkcomputing.com/922/922ws2.html). Although the core IPsec protocols are standardized, widely supported and interoperable, problems with remote-access support, such as remote-user authentication and client configuration, make client IPsec VPN interoperability difficult to implement and support.

A new IETF working group, IPSRA (IPsec Remote Access), is addressing secure remote access. The group is working on several drafts focused on client network configuration and authentication. These protocol drafts (which can be found at www.ietf.org/html. charters/ipsec-charter.html) are still in the early stages, with some interoperability work being done. Certain products, including Cisco Systems' IOS, IRE's SafeNet line and Newbridge Networks Corp.'s 130 Secure VPN Client (formerly TimeStep Permit/Client), are shipping with these new protocols, but we expect wider adoption next quarter and throughout the year. And the IETF isn't forging ahead alone. Microsoft Corp. is in the fray with Windows 2000 and L2TP (Layer 2 Tunneling Protocol) secured by IPsec.

Although IPsec products can use certificates during negotiation, a number of interoperability issues limit certificate use to single-vendor environments. Multivendor situations call for preshared IKE, which uses a secret, or password, to mutually authenticate IPsec devices. Because preshared secrets need to be distributed and managed, this solution isn't as secure or scalable as certificates, but preshared secret IKE is a viable alternative for limited-size implementations.

For this workshop, we used shipping products--including Cisco's 4700 with IOS 12.0(2a)T1, Newbridge's 234 Secure VPN Gateway (formerly TimeStep Permit/Gate 4520), IRE's SoftPK 2.1.0 (Build 15) and F-Secure Corp.'s VPN+--to see just what interoperable IPSec means and what you need to make it happen. Setting the Policy
Using an IPsec VPN solution from a single vendor has many advantages: Vendors can support more options in a proprietary fashion than are currently supported as standards. Client network configuration, remote-user authentication and data compression all are implemented in numerous solutions. But these advantages disappear in a multivendor environment. IPsec vendors recognize the need to interoperate and support the standards, but they also need to meet customer demands. So just forget about automatic configuration for the moment. It may be possible to create and distribute profiles to your end users, but doing so is vendor-dependent. As we all know, manual configuration doesn't scale beyond a handful of users.

Setting up client IPsec VPN is similar to setting up a LAN-to-LAN VPN. Security and networking parameters must match on both ends. We created a very simple network with a Newbridge 130 Secure VPN Client and a SoftPK client, both of which talked to the Cisco router and 234 Secure VPN Gateway (see "Network Map" on to the right). Our security policy was simple: All connections passing from the public network to the private network were to be secured with ESP (Encapsulating Security Payload) using 3DES encryption and MD5 authentication. Setting up the Cisco router and Newbridge 130 Secure VPN Client/234 Secure VPN was a snap. The only problem was that each peer name and shared secret, which function as a user name/password for each individual client, had to be entered manually. Currently, the only supported peer name in interoperable preshared secret VPN devices is the host IP address, and knowledge of the corresponding shared secret ensures authentication.

Once our VPN gateways were properly configured, we set up the clients. Although manually configuring IPsec isn't difficult for users familiar with IPsec and networking, those unfamiliar with the underpinnings of IPsec will need more support. The goal is to match the security proposals and network addresses for both IKE and IPsec with the accepted VPN gateway proposals. Typically you need only one security policy definition on the client that contains all the acceptable security configurations. For example, a remote user may need to use 3DES with HMAC-MD5 when forming a VPN with the corporate network, but a trading partner requires DES with HMAC-MD5. When the client negotiates the VPN, it will send both proposals to the remote IPsec device. The remote IPsec device will typically select the first proposal it finds acceptable--so order is important. Once the security profile is defined, the destination network and gateway must be defined.

Configuration may become confusing when it comes to IP addressing. IP addresses are used to identify the SA (Security Association) to which an incoming packet belongs. An ID or destination address can be a host address or a subnet address. If the addresses of the two IPsec devices do not match correctly, the IPsec phase two negotiation may fail. The IPsec client will use the desktop's IP address as its identity by default, but the remote destination address must be configured manually. Vendors are flexible in their ID syntax implementations, so make sure your specific products let you dictate your syntax. In some IPsec VPN gateways, 10.1.1.1/24 may not equal 10.1.1.1/255.255.255.0, even though logically these statements seem equivalent, because the latter uses a fully qualified IP address/ subnet mask pair while the former uses shorthand. Using identical IP address/ subnet mask pairs in the IPsec VPN is always best.



PAGE: 1 I 2 I 3 I NEXT PAGE
 





Ready to take that job and shove it?

Function:

Keyword(s):

State:
SPONSOR
RECENT JOB POSTINGS
CAREER NEWS
Go beyond Google and get vertical. These specialized search sites will help you find the business information you need -- fast.

Ari Balogh was named to the post of chief technology officer as the companys for a "realignment" of employees.










InformationWeek U.S. IT Salary Survey 2008
Salaries for business technology professionals are falling. Here's what you need to know in order to make good hiring decisions and personal career choices. Download Today
 
ROLLING RIGHT ALONG
Follow key Network Computing Reviews from conception to completion. This Week: Holistic APM.



Network Computing Reports Emerging Enterprise Podcast Series: Secrets to Success








TechSearch


Microsite of the Week


Powerful Information at Your Fingertips



InformationWeek Business Technology Network
InformationWeekInformationWeek 500InformationWeek 500 ConferenceInformationWeek AnalyticsInformationWeek CIO
InformationWeek EventsInformationWeek ReportsInformationWeek MagazinebMightyByte and SwitchDark Reading
Digital LibraryIntelligent EnterpriseInternet EvolutionNetwork ComputingNo JitterPlug Into The Cloud
space
Techweb Events Network
InteropVoiceConWeb 2.0 ExpoWeb 2.0 SummitEnterprise 2.0 ConferenceMobile Business ExpoSoftware ConferenceCSI - Computer Security Institute
Black HatGTECEnergy CampMashup CampStartup Camp
space
Light Reading Communications Network
Light ReadingLight Reading EuropeUnstrungLight Reading's Cable Digital NewsConstantinopleInternet EvolutionPyramid Research
Heavy ReadingLight Reading Live!Light Reading InsiderEthernet ExpoOptical ExpoTeleco TVTower Technology Summit
space
Financial Technology Network
Advanced TradingBank Systems & TechnologyInsurance & TechnologyWall Street & TechnologyAccelerating Wall StreetBank Systems & Technology Executive SummitBuyside Trading SummitInsurance & Technology Executive Summit
space
Microsoft Technology Network
MSDN MagazineTechNetThe Architecture Journal
space


App Infrastructure   |   Messaging & Collaboration   |   Network & Systems Mgmt   |   Network Infrastructure   |   Security  |   Storage & Servers   |   Wireless   |   Enterprise Apps
About Us  |  Contact Us  |  Site Map  |  Technology Marketing Solutions  |  Advertising Contacts  |   Briefing Centers
Copyright © 2008  United Business Media LLC  |  Privacy Statement  |  Terms of Service  |  Your California Privacy Rights