380 likes | 746 Vues
Virtual Private Networks. Ng Tock Hiong Systems Engineering Manager thng@cisco.com. Agenda. Remote Access VPN IPSec SSL Site to Site VPN Problem Statement Site to Site VPN Technologies GETVPN Summary Q & A. Remote Access VPN.
E N D
Virtual Private Networks Ng Tock Hiong Systems Engineering Manager thng@cisco.com
Agenda • Remote Access VPN • IPSec • SSL • Site to Site VPN • Problem Statement • Site to Site VPN Technologies • GETVPN • Summary • Q & A
Uses a standard web browser to access the corporate network SSL encryption native to browser provides transport security Applications accessed through browser portal Limited client/server applications accessed using applets Uses purpose-built client software for network access Client provides encryption and desktop security Client establishes seamless connection to network All applications are accessible through their native interface SSL VPN IPSEC VPN SSL VPN and IPSec Connectivity Profiles
Using a web browser for remote access enables: Anywhere access Access from non-corporate machines Customized user portals Granular access control Easy firewall traversal from any location Using an IPSec client for remote access enables: Access to any application Native application interfaces Consistent user experience Embedded security, such as personal firewall SSL VPN IPSEC VPN SSL VPN and IPSec Solution Characteristics
Comprehensive Secure ConnectivityVPN Services for Any Access Scenario Partner Access Requires “locked-down” access to specific extranet resources and applications Client-based SSL or IPSec VPN Clientless SSL VPN Company Managed Desktop Remote access users require seamless, easy to use, access to corporate network resources Public Internet Clientless SSL VPN ASA 5500 Client-based SSL or IPSec VPN Company Managed Desktops at Home Public Kiosk Remote users may require lightweight access to e-mail and web-based applications from a public machine Day extenders and mobile employees require consistent LAN-like, full-network access, to corporate resources and applications
Application Firewall and Access Control Application Inspection/Control Granular, Per-User/Group Access ControlProtocol Anomaly Detection Stateful Traffic Filtering Threat Mitigation Incident Control Virus DetectionWorm Mitigation Spyware Detection Comprehensive Endpoint Security Pre-Connection Posture Assessment Malware MitigationSession/Data Security Post-Session Clean-Up Accurate Enforcement Real-Time Correlation Risk RatingAttack Drop Session Removal and Resets Leverages Depth of Threat Defense Features to Stop Malicious Worms, Viruses, and More…and Without External Devices or Performance Loss! Cisco ASA 5500 Series: Threat Protected VPN ServicesLeveraging On-Board Security to Protect the VPN Threat Vector Remote Access VPN User Worm/Virus Spyware Exploit UnwantedApplication Illegal Access ASA 5500
Newin 8.0! Cisco ASA 5500 Software v8.0 Introduces Significant Enhancements in Clientless Access • Precise, granular access control to specific resources • Enhanced Portal Design Localizable RSS feeds Personal bookmarks AnyConnect Client access • Drag and Drop file access and webified file transport • Transformation enhancements including Flash support • Head-end deployed applets for telnet, SSH, RDP, and VNC, framework supports add’l plug-ins • Advanced port-forwarder for Windows (Smart Tunnel) accesses TCP applications without admin privileges on Client PC
New! Cisco AnyConnect Client • Next generation VPN client, available on many platforms including: • Windows Vista 32- and 64-bitt, Windows XP 32- and 64-bit, and Windows 2000 • Mac OS X 10.4 (Intel and PPC) • Intel-based Linux • Windows Mobile 5 Pocket PC Edition • Stand-alone, Web Launch, and Portal Connection Modes • Start before Login (SBL) and DTLS support • Windows 2000 and XP only
Newin 8.0! Comprehensive EndPoint Security • Cisco Secure Desktop (CSD) now supports hundreds of pre-defined products, updated frequently • Anti-virus, anti-spyware, personal firewall, and more • Administrators can define custom checks including running processes • CSD posture policy presented visually to simplify configuration and troubleshooting
Newin 8.0! Enhanced Remote Access Security • Enhanced authorization using policies and group information • Embedded Certificate Authority (CA) • Virtual keyboard option • Group/User-to-VLAN mapping support
Problem Statement • Today’s Enterprise WAN technologies force a trade-off between QoS-enabled branch interconnectivity and transport security • Networked applications such as voice, video and web-based applications drive the need for instantaneous, branch interconnected, QoS-enabled WANs • Distributed nature of network applications result in increased demands for scalable branch to branch interconnectivity • Increased network security risks and regulatory compliance have driven the need for WAN transport security • Need for balanced control of security management between enterprises and service providers • Service providers want to deliver security services on top of WANs such as MPLS without compromising their SLAs
DMVPN – How it Works • DMVPN is a Cisco IOS Software solution for building IPsec+GRE VPNs in an easy and scalable manner • Relies on two proven Cisco technologies • Next Hop Resolution Protocol (NHRP) • Hub maintains a (NHRP) database of all the spoke’s real (public interface) addresses • Each spoke registers its real address when it boots • Spokes query NHRP database for real addresses of destination spokes to build direct tunnels • Multipoint GRE Tunnel Interface • Allows single GRE interface to support multiple IPsec tunnels • Simplifies size and complexity of configuration • DMVPN does not alter the standards-based IPsec VPN tunnels, but it changes their configuration
DMVPN – How it works (Cont.) • Spokes have a permanent IPsec tunnel to the hub, but not to the spokes. They register as clients of the NHRP server • When a spoke needs to send a packet to a destination (private) subnet on another spoke, he queries the NHRP server for the real (outside) address of the destination spoke • Now the originating spoke can initiate a dynamic ipsec tunnel to the target spoke (because he knows the peer address). • The spoke-to-spoke tunnel is built over the mGRE interface
Mesh VPN issues • In a tunneled IPsec network (e.g., hub-and-spoke) system administrators can accurately predict which VPN gateways will setup VPN connections with which other VPN gateways • But this isn’t true in a partial or full mesh of IPsec connections! Connections are built in an ad-hoc basis depending on application traffic (e.g., VoIP, video) flows. • In a hub-and-spoke topology system administrators can accurately predict the cryptographic capacity needed at each VPN gateway. • But this isn’t true in a partial or full mesh! The system administrators are faced with either: • Making an educated guess (which potentially affects reliability of the VPN), or • Outfitting the the entire system with costly high-capacity VPN gateways. • Management & synchronization of IKE/IPsec state on 100s or 1000s of VPN gateways is problematic.
Mesh VPN issues • Native IP multicast may be available across the provider network, but traditional VPN technologies protect it with tunneling, which destroys the efficiency of using IP multicast! • In a hub-and-spoke topology VoIP packets are not optimally sent between spokes • Packets sent through the hub suffer from added latency • The hub takes an unnecessary load • If packets do also start flowing directly between spokes, the packets can be delivered out of order, which affects the voice quality
Pair-wise Tunnel Issues • Pair-wise authentication • Before the tunnel can be setup, the VPN Gateways must authenticate each other with IKE. • IKE is a cryptographically expensive protocol and there are limits to the number of simultaneous IPsec sessions that can be setup at a VPN gateway protecting a large enterprise network. • Note: Such a VPN Gateway must be sized not according to the maximum bandwidth load but to the number of IKE peers that it can handle!
Original IP Header ESP New IP Header Data ESP IP Header Data Pair-wise Tunnel Issues • Tunneled data packets • VPN Gateways use IP tunnel mode, with new addresses that are routed differently: • IPsec does include a transport mode: • But it is inadvisable for IPsec gateways to use transport mode to protect data packets between themselves. This can require fragment re-assembly which can overly tax the route processor. • Use of ESP transport mode is risky for group traffic since the receiver cannot detect a 3rd party changing the source and/or dest. address
Original IP Header ESP Original Src/Dst Data Using Group Security to avoid the barriers • Use a new type of IPsec tunnel mode • Recall that routers cannot use IPsec transport mode for this application. • But we can use a new tunnel mode type which uses the original source and destination addresses in the outer header. This allows IPsec gateways to encapsulate both packets and fragments, but still create packets that are routable using the host source and destination addresses This is called “tunnel mode with address preservation”. Note: Tunnel mode with preservation is required for protecting native IP multicast packets. GET VPN also applies it to unicast packets.
Any - to - Any Any - to - Any Connectivity Connectivity Cisco GET VPN Scalable Real Time Cisco Group Encrypted Transport (GET) VPN – Solution for Tunnel-less VPNs Cisco GET VPN delivers a revolutionary solution for tunnel-less, any-to-any branch confidential communications • Large-scale any-to-any encrypted communications • Native routing without tunnel overlay • Optimal for QoS and Multicast support - improves application performance • Transport agnostic - private LAN/WAN, FR/AATM, IP, MPLS • Offers flexible span of control among subscribers and providers • Available on Cisco Integrated Services Routers; Cisco 7200 and Cisco 7301 with Cisco IOS 12.4(11)T
GW3 GW4 • Step 1: VPN Gateways “register” with the GCKS GCKS authenticates & authorizes the GW GCKS returns a set of IPsec SAs for the VPN Gateways to use GW2 GW5 GW1 GW6 GCKS GW9 GW7 GW8 Basic GET VPN Architecture GW1 • Two Roles: • VPN Gateways (a.k.a. “group members”) • Group Controller/Key Server (GCKS) (a.k.a. “key server”) GCKS
GW3 • Step 2: VPN Gateways exchange encrypted traffic using the group keys. The traffic uses the “address preservation” tunnel mode. GW4 GW2 GW5 GW1 GW6 GCKS GW9 GW7 GW8 GW3 GW4 • Step 3: GCKS pushed out replacement IPsec keys when before current IPsec keys expire. This is called a “rekey”. GW2 GW5 GW1 GW6 GCKS GW9 GW7 GW8 Basic GET VPN Architecture
Bolted on Built in Complex architecture Seamless integration Investment protection Flexible design Wasted capital Rigid design Simple transport Intelligent transport GET VPN is a new Security Paradigm:Introducing new Category Tunnel-less VPNs Tunnel Based VPN Tunnel-less VPN Fueled by demand for agility within a security framework 25 © 2005 Cisco Systems, Inc. All rights reserved.
Tunnel-less VPN - A New Security ModelAny-to-Any encryption: Before and After GET VPN WAN Before: IPsec P2P Tunnels After: Tunnel-less VPN Multicast • Scalability—an issue (N^2 problem) • Overlay routing • Any-to-any instant connectivity can’t be done to scale • Limited advanced QoS • Multicast replication inefficient • Scalable architecture for any-to-any connectivity and encryption • No overlays – native routing • Any-to-any instant connectivity • Advanced QoS • Efficient Multicast replication
GET VPN Concepts and Relationship Data Protection Secure Multicast • Key Distribution GDOI--Key distribution mechanism (RFC3547) • Group Keys/Keys between Peer • Encrypted Control Plane • Routing Continuity No overlay Routing - IP Header Preservation • Multicast Data Protection • Encrypt Multicast, Retain IP Header of Original packet with IP Address preservation • Replication in the core based on (S,G) • Unicast Data Protection IPSec is a well-known RFC (RFC2401) • Encrypt Unicast with IPsec • IP Header Preservation Routing IP Header Preservation Key Distribution Group Domain Of Interpretation Data Protection Secure Unicast
Routing IP Header Preservation Original source and destination IP address encapsulated in tunnel mode New hdr with Original IP hdr encapsulated Original hdr preserved ESP header IP IP Payload IPSec packet Routing Continuity: IPsec Tunnel Mode with IP Header Preservation IP header IP Payload Original IP Packet IPSec Tunnel Mode IP Payload IP Header Preservation This mode is already necessary when encrypting IP multicast packets in order to preserve the (S,G). Mitigates the requirement for a routing overlay network
Mesh VPN issues Applying existing Site-to-Site VPN Technologies • Standard IPsec VPN • Not intended for large-scale VPNs, so management of high numbers is challenging. • Cisco Easy VPN • Hub-and-spoke technology, doesn’t support routing. • Cisco GRE-based VPN • Management of tunnels in high numbers is challenging. Spoke-to-spoke tunnels must be setup manually. • Cisco DMVPN • Hub-and-spoke technology, but has easier configuration and management. Supports spoke-to-spoke tunnels, but initial traffic flows through the hub. Uses GRE, which adds to the packet size. Will not scale to 1000s in full mesh mode Our observation: Pair-wise Tunnels are not going to solve this problem!
GW3 GW4 GW2 GW5 GW1 GW6 GW9 GW7 GW8 Motivation for GET VPNSolving the Mesh VPN problem • Enterprises are increasingly finding the need to setup a set of VPN gateways surrounding a service provider network (e.g., RFC 2547 (BGP/MPLS) networks. • In many cases, this is prompted by regulatory requirements such as HIPAA and SO. • With the inclusion of VoIP and video over IP multicast they are tending toward being a mesh rather than a traditional hub and spoke configuration • The number of VPN gateways is on the order of 100s and 1000s!