Transcript VPN Directions

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