Virtual Private Networks

1. Virtual Private Networks Chen-Nee Chuah Network Reading Group, Spring 99

2. VPNs • Definition: A VPN is an emulation of a private wide area network (WAN) facility using IP facilities (including the public Internet, or private IP backbones). • VPNs can be implemented in many ways: • Customer Premises Equipment (CPE) based solutions • Network based solutions

3. Motivations • Need private communication networks for multiple sites => “private WANs” • Two types of existing private networks: • dedicated WANs (permanently connected) • dial network (on-demand connections through leased lines from PSTN network or dedicated ATM circuits). • Running VPNs across Internet offers a cost-effective solution.

4. Can Internet Support VPNs? • Customer requirements for VPNs • Support for opaque packet transport • Support for data security • Support for Quality of Service Guarantees • Need some form of IP tunneling

5. CPE Vs. Network Based VPNs • Most current VPN implementations are based on CPE devices: • Firewalls • WAN edge routers • Specialized VPN termination devices • Network based solution: VPN is implemented on network by Internet service provider (ISP) • Some mechanisms leverage tools that are applicable only to ISPs rather than individual customers running special CPE devices.

6. Different VPN types • Virtual Leased Lines (VLLs) • Virtual Private Routed Networks (VPRNs) • Virtual Private LAN Segment (VPLSs) • Virtual Private Dial Networks (VPDNs)

7. Type I: Virtual Leased Lines (VLLs) • VLL = IP tunnel forming a point-to-point link to emulate a physical leased line or dedicated connection. • Require IP tunneling mechanism • forwarding disjoint from the address fields of the encapsulated packets, allow opaque transport of frames as packet payload. • e.g. IP/IP, GRE tunnels, L2TP (PPP packets), MPLS, and IPSec

8. VLLs: Tunneling Protocol Requirements • Support for VLL Multiplexing • e.g. tunnel-id & call-id for L2TP, MPLS labels • Support for a Signaling protocol • to negotiate tunnel attributes such as security level, IP address of remote end points (e.g. MPLS’s LDP). • Support for Data Security • allow customers to specify levels of security • Support for Multi-protocol Transport • Support for Frame Sequencing • required to guarantee in-order delivery of packets

9. VLLs:Protocol Requirements (continued) • Support for Tunnel Maintenance • establish, maintain and delete tunnel instances • Support for Large MTUs • must allow frame fragmentation, either at IP level, or within the tunnel (tunnel sequence number) • Minimization of Tunnel Overhead • important for small, jitter and latency sensitive traffic • Flow and congestion control issues • currently only L2TP does this, still open to research • Traffic management issues • deliver guarantees e.g. loss rates, latency & bandwidth

10. VLLs: Recommendations • A modification of IKE/IPSec may be an optimal choice as a standard VLL tunneling mechanism • it has well defined signaling & multiplexing capabilities • it supports security • close competitor: MPLS • Using a single signaling protocol and associated data encapsulation is better than using multiple protocols in parallel.

11. ISP ISP IP tunnel CPE CPE ISP ISP edge router Stub link Backup link Backdoor link Type II:Virtual Private Routed Networks • A VPRN emulates a multi-site wide area routed network over IP, consisting of • a mesh of IP tunnels btw ISP routers & routing capabilities • “stub” links connecting CPE routers to ISP routers CPE

12. VPRNs (continued) • Benefit: Configuration of the CPE router is simplified. ISP edge router appears to be a “neighbor” router. • The burden of tunnel establishment, maintenance and routing is on ISPs. Forwarding is done at the network layer (Layer 3). • Each customer side CPE router is connected to an ISP edge router through one or more stub links (leased lines, ATM or Frame Relay) • Each VPRN supports only a single network layer protocol.

13. VPRNs (continued) • Issues need to be addressed • Initial configuration/topology: need to determine set of routers that have members in VPRNs • CPE routers need to determine set of IP address prefixes to be forwarded to an ISP edge router. • ISP edge routers • need to determine the set of IP address prefixes that are reachable via each stub link • need to learn and disseminate stub reachability information among themselves. • need VPN specific forwarding mechanisms to forward ingress traffic from stub links to next hop router, and to forward egress traffic from core network to stub links. • Note: similar issues applied to VPLSs.

14. VPRN Generic Requirements • Unique VPN identifier to refer to a particular VPN • unique across different ASs • VPRN membership • configuration • dissemination (directory lookup, explicit management configuration, piggybacking in routing protocols). • Stub link reachability information • edge router must learn set of addresses/address prefixes reachable via each stub link. • Each CPE router needs to learn the destinations reachable by each stub link.

15. VPRN Generic Requirements (continued) • Intra-VPRN reachability information • need to be disseminated to other edge routers via one of the following ways • directory lookup • explicit configuration • local intra-VPRN routing instantiations • link reachability protocol • piggybacking in IP backbone routing protocols. • Tunneling mechanism (like VLLs) • Edge router must construct necessary tunnels to other routers in the VPRN, encapsulate/decapsulate and send/receive packets over the tunnel

16. VPRNs: Multicast support Multicast & broadcast traffic can be supported by • Edge replication: • edge router replicates multicast traffic for transmission across each link in the VPRN • Native multicast support • VPRN edge routers map intra-VPN multicast traffic onto a native IP multicast distribution mechanism across the backbone.

17. VPRNs: Recommendations • There are proposals to adapt routing protocols to carry VPN information to support router piggybacking mechanisms. (e.g. MPLS) • Downside: some ISPs prefer not to couple VPN membership and reachability with backbone routing protocols.

18. Type III:Virtual Private LAN Segment • A VPLS emulates a LAN segment over IP. • equivalent to VPRN, except now IP tunnels extend all the way to CPE routers, and ISP edge routers provide Link Layer bridging (layer 2 connectivity alone). ISP ISP IP tunnel CPE CPE ISP ISP edge router Backdoor link CPE

19. VPLS: Requirements & Recommendations • Very similar to VPRNs • Unlike VPRNs, CPE nodes can either be bridges or routers • nature of CPE (bridge Vs router) impacts nature of encapsulation, addressing, forwarding and reachability protocols within the VPLS. • Advantage: protocol transparency. • Commonality btw VPRNs and VPLSs can be exploited to reduce complexity.

20. Type IV: Virtual Private Dial Networks • A VPDN allows for remote users to connect on demand into remote sites through an hoc tunnels. • E.g. PPP connections to network access server • Strong binding btw a particular user and a central side requires authentication & security • L2TP (Layer 2 Tunneling Protocol) allows user PPP sessions from L2TP access concentrator (LAC) to a remote L2TP network server (LNS)

21. VPDNs (continued) • Support compulsory tunneling • a dial or network access server (LAC), extends a PPP session across a backbone using L2TP to a remote LNS. • Other issues: • Call Routing • Security mechanism • Traffic management • Call multiplexing • Address management • Support for large MTUs

22. VPDNs (continued) • Voluntary Tunnels • an individual host connects to a remote site using a tunnel originating on the host, with no involvement from intermediate network nodes. • Networked Host Support • existing PPP based dial model assumes connection oriented dial access network • want to accommodate existing AAAA infrastructure within service providers • extend PPP to hosts through L2TP • extend PPP directly to hosts • use of IPSec

23. VPDNs: Recommendation • L2TP specifications are being finalized to support VPDNs using compulsory tunneling. • Further study need to be done to determine the best solution for voluntary tunneling • PPP based solution or • IPSec based mechanism.

24. Summary • Further standardization efforts needed in defining • a generic VPN tunneling protocol • a globally unique VPN identifier • a VPN membership information configuration and dissemination mechanism • Further study is needed to address • security issues • scalability of membership configuration and dissemination mechanism

25. QoS Guarantees in VPNs • Goal: obtain differentiated & dependable QoS for flows belonging to a VPN • 2 performance service abstractions: Pipe & Hose • A pipe provides performance guarantees for traffic btw A specific origin and destination pair • A hose provides performance guarantees btw an origin and a set of destinations, and btw a node and a set of origins, i.e. it’s characterized by the “aggregate” traffic coming from or going into the VPN.

26. QoS Support • Service Level Agreement (SLA) btw a customer & a service provider • traffic characteristics and QoS requirements • Two ways to support different QoS classes within VPN: • resources are managed on a VPN specific basis, i.e. SLAs would be for the overall VPN rather than for each specific QoS class • Schedule only at the edges • Mark packets and schedule within the core • resources are managed on an individual QoS basis

27. Summary • Different choices for the implementation of hoses in VPNs • integrated service framework (controlled load, guaranteed load) with signaling protocol like RSVP • differentiated service framework (DS byte of IP header) • MPLS environment (LSP tree) • Security • IPSec is recommended. The only limitation is scalability.