New Directions in Virtual Private Networking Lisa Phifer Core Competence, Inc. [email protected] State of the VPN Market Healthy Outlook • Revenue > $4B by 2007 Growth Factors •
Download ReportTranscript New Directions in Virtual Private Networking Lisa Phifer Core Competence, Inc. [email protected] State of the VPN Market Healthy Outlook • Revenue > $4B by 2007 Growth Factors •
New Directions in Virtual Private Networking Lisa Phifer Core Competence, Inc. [email protected] State of the VPN Market Healthy Outlook • Revenue > $4B by 2007 Growth Factors • 9/11 increased spending on cybersecurity overall • Privacy mandates are promoting VPN use • Worms and Trojans are stimulating firewall sales • Risks associated with growing network technologies like WLANs Not Yet Saturated • Just 59% of mobile workers now use remote access VPNs • Expected to reach 74% by 2005 Source: Infonetics 6/03 Copyright 2004 © Core Competence, Inc. Phifer 2 No Longer A Separate Market? Today’s security appliances, software, and managed services offer many integrated security functions Internet VPN Tunnel Perimeter VPN Content AntiVirus Firewall Gateway Inspect Gateway Most companies now use multi-function hardware to consolidate security admin/enforcement • • • • 64% use VPN/Firewall appliances 47% use VPN-enabled Routers VPN Software represents just 15% of revenue Many large companies still use VPN-only appliances (e.g., RA VPN Concentrators), but just 11% of SMBs do Source: Infonetics 06/03 Copyright 2004 © Core Competence, Inc. Phifer 3 VPNs Use Many Different Approaches Common tunneling protocols used by VPNs • Site-to-Site (S2S) VPNs interconnect private office networks – Using Hub-and-Spoke or Mesh topology • Remote Access (RA) VPNs connect remote users – Travelers, Teleworkers, Day Extenders, Mobile Workers Acronym Name Layer S2S RA MPLS Multi-Protocol Layer Switching 2/3 PPTP Point to Point Tunneling Protocol 2 L2TP Layer Two Tunneling Protocol 2 IPsec IP Security (extensions to IP) 3 SSL (TLS) SSH Secure Sockets Layer (aka Transport Layer Security) Secure Shell Copyright 2004 © Core Competence, Inc. 4 4 Phifer 4 IPsec VPNs IP Security (IPsec) tunnels and encrypts IP packets exchanged between gateways, hosts Router, Firewall, or VPN Server Internet Host or Gateway ISP Subnet IPsec + IKE IETF standards cover Corporate LAN X • Authentication Header (AH) • Encapsulating Security Payload (ESP) • Internet Key Exchange (IKE) Virtually all IPsec VPNs now use IKE and ESP in tunnel mode Copyright 2004 © Core Competence, Inc. Phifer 5 IPsec Trend: Stronger Faster Encryption Advanced Encryption Standard (AES) • NIST (US government) encryption standard to replace 3DES • Previously known as Rijndael • Improves computational efficiency, uses less memory AES and new IPsec Standards • AES is just the cipher – IPsec Standards define how ESP uses AES • RFC 3602: AES Cipher Block Chaining (CBC) confidentiality – RFC 3566: AES-XCBC-MAC-96 data integrity • Draft: AES Counter Mode (CTR) confidentiality – Draft: Counter Mode with CBC-MAC (CCM) offers both confidentiality and data integrity Copyright 2004 © Core Competence, Inc. Phifer 6 IPsec AES Status VPNC AES Interoperability Testing • Used 128-bit AES-CBC (RFC 3602) in IKE Phase 1 • See http://www.vpnc.org/detail-aes-interop.html • 12 Products passing VPNC AES tests as of 10/2003 AES-CBC option in ISCA v1.0D certification criteria As with 3DES, look for AES hardware acceleration • Particularly in VPN Gateways where demand is high Copyright 2004 © Core Competence, Inc. Phifer 7 One Example: AES vs. 3DES Performance AES 3DES Source: C. Karg, Research Establishment for Applied Science http://www.dodccrp.org/Activities/Symposia/7thICCRTS Copyright 2004 © Core Competence, Inc. Phifer 8 IPsec Trend: NAT Traversal Network Address Translation (NAT)* often breaks IPsec • No problem when NAT is applied before IPsec (or at same point) • Plenty of problems when NAT is applied after IPsec – Common remote access VPN scenario! Host 192.168.0.2 Src: 192.168.0.2 : 1108 Dst: 207.28.194.84 : 80 Src: 206.245.160.1 : 61001 Dst: 207.28.194.84 : 80 NAT Device 206.245.160.1 192.168.0.1 Public Private Internet Web Server 207.29.194.84 Host 192.168.0.3 Src: 192.168.0.3 :1108 Dst: 207.28.194.84 : 80 Src: 206.245.160.1 : 61002 Dst: 207.28.194.84 : 80 * AKA NAPT or NAT/PAT. We’ll just say “NAT.” Copyright 2004 © Core Competence, Inc. Phifer 9 How NAT “Breaks” IPsec and IKE NAT invalidates IPsec message authentication code in Transport Mode • ESP encryption obscures TCP ports and checksum needed for PAT • “IPsec pass-through” allows one ESP tunnel through NAT without PAT NAT devices quickly delete UDP port mappings - breaks IKE re-keying • NAT can sometimes work with ESP Tunnel Mode... Some implementations avoid this using IKE “keep alives” NAT devices that multiplex IKE can get confused • • New IP Hdr Vendor tricks based on IKE cookies or IPsec indices Problem for multi-user NATs (e.g., hospitality LANs, wireless hotspots) ESP Hdr Original IP Hdr TCP/UDP Hdr Original Payload ESP Trail ESP Auth Encrypted Authenticated TCP Check Summed Copyright 2004 © Core Competence, Inc. Phifer 10 NAT Traversal (NAT-T) Solves ESP Problem Firewalls must pass IKE (UDP port 500) anyway, so… • Encapsulate IPsec inside UDP packet using port 500 or 4500 New IP Hdr UDP Hdr Zero Pad ESP Hdr Orig IP Hdr TCP/ UDP Original Payload ESP Trail ESP Auth Encrypted Authenticated NAT modifications here unaffected by encryption and do not break ESP authentication NAT-T Negotiation and Processing • Use IKE to discover if NAT present & both ends support NAT-T • 1-byte UDP “keepalive” maintains mapping and firewall state • Fix or zero UDP checksum in encapsulated packets Copyright 2004 © Core Competence, Inc. Phifer 11 NAT Traversal Status Most IPsec RA Concentrators now implement NAT-T • Internet Draft mostly stable for two years now • Some vendors still have their own “special sauce” • In theory, NAT-T is invisible to existing NAT boxes; in practice, this is not always true NAT-T does not solve everything • • • • Mostly useful to resolve ESP-thru-NAT problems Some IKE multiplexing issues remain in NAT devices Overlapping private addresses still possible NAT still can't modify encrypted application payload (embedded IPs in FTP, IRC, SNMP, LDAP, H.323…) Copyright 2004 © Core Competence, Inc. Phifer 12 IPsec Trend: Endpoint Security Problem • • • • Tunnel can be abused by Trojans, viruses, spyware on client VPN clients need to run personal firewall software (and most do) But many remote hosts do not have current OS patches, AV files Centralized control over remote hosts is difficult – Always outside company, on the road, at home Solution • Integrate IPsec VPN Clients & desktop security measures, e.g.: • • • • Cisco VPN Client + ZoneLabs Integrity CheckPoint VPN-1 SecureClient + PestPatrol Nortel EAC + InfoExpress Microsoft Windows Server 2003 Quarantine • Similar measures now also being applied to SSL VPNs Copyright 2004 © Core Competence, Inc. Phifer 13 One Example: PestPatrol Source: PestPatrol, Inc. Copyright 2004 © Core Competence, Inc. Phifer 14 IPsec Future: IKEv2 Original IKE is overly complex • Too many options: modes, protocols, groups, algorithms • Too many messages to create just one IPsec association • Insufficient support for common remote access needs (e.g., user authentication, dynamic addressing, NAT) Consequences • • • • Harder to configure than needs to be Interoperability problems, especially beyond basic options Vendor extensions to facilitate remote access Complexity and extensions increase risk – Example: Extended Authentication (XAUTH) & IKEcrack Copyright 2004 © Core Competence, Inc. Phifer 15 How IKEv2 Might Help Some improvements included in IKEv2 draft • • • • • • • • Often just 4 messages to set up 1st IPsec (child) SA Better DoS deflection with stateless cookies Identities always hidden Supports internal address delivery over IKE Adds asymmetric IKE authentication using EAP Facilitates NAT traversal via UDP encapsulation Versioning enables backwards compatibility Smaller set of named cryptographic suites Current Status • Draft 12 distributed to IETF WG for review 1/6/04 • Will vendors implement it? Copyright 2004 © Core Competence, Inc. Phifer 16 Emerging Trend: SSL VPNs Use the Secure Sockets Layer (SSL)* protocol to tunnel application data from remote host to VPN gateway • Gateway is a proxy that gives user access to private resources Permitted Subnet(s) Internet IPsec Tunnel Remote User With IPsec Client IPsec Gateway VPN+Firewall Corporate Network User’s Mailbox Internet SSL/TLS Tunnel Remote User With Any Browser * Here, “SSL” refers to either SSL 3.0 or TLS 1.0 Copyright 2004 © Core Competence, Inc. Firewall SSL VPN Gateway Exchange Server Intranet Server Permitted URLs/Objects Phifer 17 How Payload Protection Differs IPsec ESP encrypts IP packet (TCP header, payload) SSL encrypts transport payload (application data) Transport Layer Security (TLS) Message IP Header TCP Header TLS Record Header Application Payload TLS HMAC Confidentiality Integrity IPsec Encapsulating Security Payload (ESP) in Tunnel Mode New IP Header IPsec ESP Original IP Hdr Original IP Payload IPsec ESP ESP HMAC Confidentiality Integrity Copyright 2004 © Core Competence, Inc. Phifer 18 Growth Market (F5) (Symantec) (Netscreen) Other SSL VPN Products & Services: • Array • Permeo • Aventail • Lemon Planet • CheckPoint • Motivus • Cisco • Nokia • Citrix • OpenReach • Fiberlink • Rainbow • Netsilica • Seagull • Nokia • Tarantella • Nortel • V-ONE Copyright 2004 © Core Competence, Inc. Phifer 19 Why Are SSL VPNs On The Rise? Web browser is ubiquitous, familiar to users, and easier to administer than IPsec VPN Clients • Not truly “Clientless,” but usually no added software Asymmetric mutual authentication without overhead(ache) of PKI for user certificates • With IPsec today, typically done by XAUTH or L2TP Minimizes network addressing and routing impact • Remote hosts do not join private network as with IPsec Fine-grained access controls can be applied to application stream (server, page, embedded objects) • Easier than IPsec policies based on IPs/protocols/ports? Copyright 2004 © Core Competence, Inc. Phifer 20 What’s An SSL VPN Gateway? Some are Application-level reverse proxy (e.g., SafeWeb) or HTTP reverse proxy (e.g., Aventail) • Client application is Webified, sends data via SSL • Client’s SSL session is terminated at the proxy • The proxy establishes native connections to private servers Others are Circuit-level proxy (e.g., Aventail) or Session-layer proxy (e.g., Nokia, Permeo) • Remote agent establishes tunnel (circuit) to proxy using SSL or protocol carrying SSL (e.g., SOCKS) • Native application traffic is port-forwarded over tunnel • Proxy relays traffic to private servers Copyright 2004 © Core Competence, Inc. Phifer 21 Some SSL VPNs Use Temporary Clients Teleworker SSL VPN Appliance Authentication Server Internet Back Office App Server User establishes SSL session Typically, agents that provide Native User Interfaces are “temporary” Java or ActiveX controls Agents that provide generic port forwarding can be “temporary” Java or ActiveX controls, or Win32 apps Copyright 2004 © Core Competence, Inc. Phifer 22 Example: Using Web-Enabled Application User • Launch browser • Authenticate appliance • Supply credentials • Issue page requests over SSL • Receive responses over SSL Business Partner SSL VPN appliance • Verify user’s credentials • Confirm user is authorized to access resource requested • Map between external and internal names • Forward HTTP requests to server in clear • Accept server’s HTTP response • Map between internal and external names • Forward responses over SSL to user in clear SSL VPN Appliance Mobile Worker Internet Authentication Server HTTP Back Office App Servers Teleworker User’s SSL Session to proxy Copyright 2004 © Core Competence, Inc. Phifer 23 Example: Using Transformed Application SSL VPN appliance User • Verify user’s credentials • Launch browser • Confirm user authorized to access • Authenticate appliance file server and share requested • Supply credentials • Map between external and internal names • Issue share requests over SSL • Send share request using native protocol • Access file share through • Obtain requested resource from file server web interface over SSL • Transform share into a web resource • Map between internal and external names • Forward transformed share over SSL to user Mobile Worker Teleworker User’s SSL Session to proxy SSL VPN Appliance Authentication Server Internet Transformed NFS, SMB/CIFS Copyright 2004 © Core Competence, Inc. File Server SMB/CIFS, NFS… Phifer 24 SSL VPN Endpoint Security Users may access secured sites from non-work computers • Desirable to leave no trace of VPN access at browser host SSL VPNs products may provide – – – – – – – – Secure log-off (inactivity or maximum duration exceeded) Login failure handling (abandon, suspend, lockout) Forced periodic re-authentication Delete cached credentials, browser history, temporary Internet files, offline content, cookies, downloaded program files Block auto completion, personal information profile, cookies Client security scan (ports, applications, services) Content scan (for malicious code) Application and application command filtering Desktop Security Integration underway for SSL VPNs too • Neoteris + InfoExpress • Aventail + Sygate Copyright 2004 © Core Competence, Inc. Phifer 25 Determining Best Fit SSL is not suited for site-to-site VPNs • Use IPsec or MPLS or both for S2S tunneling IPsec and SSL both have roles as remote access VPNs • Neither are perfect for every application mix and user community • Both require careful planning and deployment When choosing RA VPN product(s), consider • • • • • • • What does user’s application mix look like? Broad or narrow? Which resources does user need to access? Granularity? Which authentication method(s) does user need? From which locations will user access your VPN? How much control do you have over remote host(s)? What are user’s throughput, latency requirements? If user already has IPsec VPN Client, is migration warranted? Copyright 2004 © Core Competence, Inc. Phifer 26 Comparing SSL and IPsec for Remote Access SSL Remote Access User Level Process No change to OS, but requires app-level support Apps can make decisions based on what SSL communicates Cannot handle malicious data modification - SSL rejects data but cannot tell TCP stack, so TCP drops correct data arriving with same sequence number IPsec Remote Access OS Level Process OS change allows all applications to benefit Unchanged apps know nothing about IPsec, so glean no app benefit Unchanged apps still require app-level authentication since cannot access certs already provided to IKE/IPsec Source: Perlman and Kaufman, "Analysis of the IPsec Key Exchange Standard," from the Proceedings of WET ICE 2001, http://sec.femto.org/wetice-2001/papers/radia-paper.pdf Copyright 2004 © Core Competence, Inc. Phifer 27 Emerging Trend: Wireless VPNs Wireless networks heighten security concerns • WWANs: CDMA, iDEN, GSM, CDPD, GPRS, 3G • WLANs: 802.11b, 802.11a, 802.11g (WiFi) VPNs now being (re)used to secure wireless traffic Tunnel prevents eavesdropping, tampering, forgery, and replay Permit access only by authenticated clients WinXP L2TP / IPsec 802.11 WLAN VPN GW Firewall PalmOS IPsec Protected Network Internet Pocket PC SSL Copyright 2004 © Core Competence, Inc. Travelers already using VPN Clients for RA Phifer 28 Wireless VPN Alternatives Deploy more of what you already have • Drop small / branch office VPN-firewalls behind AP clusters • Pro: consistency, Con: scalability, mobility Invest in “smart” Access Points • Deploy APs that act as VPN Gateways • Pro: distributes load, Con: AP maturity, evolution Consolidate VPN at Wireless Gateway/Switch • Roll out security servers specifically designed for wireless • Pro: central control, mobility, Con: longevity of new paradigm Use Secure Application Protocols instead • For example, web-enabled enterprise apps using SSL • Pro: no client software, Con: ad hoc protection Copyright 2004 © Core Competence, Inc. Phifer 29 Wireless VPNs vs. Mobility Layer 2 and 3 VPNs bind tunnel endpoints to IPs • When WLAN client roams, it may get new IP addresses • Can require VPN tunnel re-establishment, session disconnection Some new Wireless VPN products enable mobility • Proprietary wireless gateways and switches share IPsec state, may avoid changing IP or reestablishing tunnel – Examples: Bluesocket, Vernier, Airespace • Some wireless VPNs provide tunnel / session persistence for users that roam between wireless LANs and WANs – Examples: NetMotion, Columbitech, AppGate Even after 802.11i, VPN will continue to play role in wireless • Especially hotspots, hospitality WLANs, WAN-LAN roaming • Must become more transparent to mobile users! Copyright 2004 © Core Competence, Inc. Phifer 30 Emerging Trend: Managed VPN Services Most MSSPs now offer Managed VPNs • • Most common VPN Gateways • • • 87% S2S 87% RA CheckPoint Cisco Nortel (RA) VPN Protocols • • • • • 87% IPsec 70% L2TP 52% PPTP 35% SSL 22% MPLS Source: ISP-Planet 2003 MSSP Survey Copyright 2004 © Core Competence, Inc. Phifer 31 Why Managed VPN Services? Reduce cost by leveraging provider resources • Provider may bundle CPE, lease CPE, or use network switch – Low / no up-front capital equipment expense • Provider responsible for – CPE installation, configuration – Platform maintenance, upgrade – 24/7 monitoring and alerting Delegate routine / labor-intensive tasks • Retain control over security policy – Some providers review / advise change requests • Retain control over incident response – Most providers offer add-on IR assistance, forensics • In some cases, interface with existing user database(s) The Catch: You must trust your MSSP Copyright 2004 © Core Competence, Inc. Phifer 32 Yet Another Growth Market Managed Security Services market has started to contract • Several MSSPs have closed up shop or been acquired • But survivors are benefiting from increased security spending Outsourcing VPN services isn’t for everyone • SMBs more likely to offload security services • Enterprises have in-house security expertise & budget, but of course are still driven to reduce cost of operation Copyright 2004 © Core Competence, Inc. Phifer 33 Conclusion Virtual Private Networking has many faces • Movement from private FR / dial-up to VPN well underway – But what you moved to in 2000 may be very different from what you’ll deploy in 2004 Overall trends • • • • Increase VPN throughput, capacity, flexibility Reduce total cost of operation Work around past IT pain-points (e.g., NAT, software install) Tighter integration with other security measures Ultimately, success depends on • How well you match products/services to business needs • How reliable and secure your chosen products are • How competently you implement your overall security policy Copyright 2004 © Core Competence, Inc. Phifer 34 Questions? You can submit your questions by entering them in the white field on the lower left corner of your screen, and clicking the Submit button. Copyright 2004 © Core Competence, Inc. Phifer 35 Thank you For more information on VPNs and a copy of this presentation, visit our Featured Topic: searchsecurity.com/featuredtopic/vpn The presentation will be added within the next 24 hours. Copyright 2004 © Core Competence, Inc. Phifer 36