Virtual Private Networks Chen-Nee Chuah Network Reading Group, Spring 99
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
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.
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
CPE Vs. Network Based VPNs
Most current VPN implementations are based on CPE devices:
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.
Different VPN types
Virtual Leased Lines (VLLs)
Virtual Private Routed Networks (VPRNs)
Virtual Private LAN Segment (VPLSs)
Virtual Private Dial Networks (VPDNs)
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
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
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
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.
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 ISP ISP ISP CPE ISP edge router IP tunnel Stub link Backup link Backdoor link CPE
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.
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.
VPRN Generic Requirements
Unique VPN identifier to refer to a particular VPN
unique across different ASs
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.
VPRN Generic Requirements (continued)
Intra-VPRN reachability information
need to be disseminated to other edge routers via one of the following ways
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
VPRNs: Multicast support
Multicast & broadcast traffic can be supported by
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.
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.
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 ISP CPE ISP edge router IP tunnel Backdoor link CPE CPE
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.
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)
Support compulsory tunneling
a dial or network access server (LAC), extends a PPP session across a backbone using L2TP to a remote LNS.
Support for large MTUs
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
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.
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
scalability of membership configuration and dissemination mechanism
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.
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
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)
IPSec is recommended. The only limitation is scalability.