Published on

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Paper also mention constructing VPNs using native mappings onto switched backbones - e.g. VPNs constructed using, for instance, the LAN emulation over ATM or Multiprotocol over ATM over ATM backbones. This draft doesn't cover that.
  • Working from home, e.g. PPP connections More and more businesses have found then need for high speed Internet connections, in addition to previous private networks, there has been significant interest in the deployment of CPE based VPNs running across the Internet. Can leverage the existing IP backbone, packet switched network.
  • Although the idea of using Internet for private communication is not new, it's only recently that many IP mechanisms needed to meet customer requirements for VPNs all come together. Traffic carried within VPN may have no relation to the traffic on IP backbone (multiprotocol, private IP addressing etc.) Recent VPNs implementations converge to the use of IPSec latency and bandwidth guarantees (like ATM & Frame Relay)
  • 2nd solution motivated by users seeking to reduce costs and ISPs seeking new revenues Some techniques are only applicable to Network based solutions Some mechanisms leverage tools that are only applicable to ISPs like routing protocols etc. as opposed to customers
  • I switched the order of the last two VPN types while I go over it, because VPRNs and VPLSs are very similar and both share some common issues that need to be addressed.
  • VLLs can also be thought of the “basis” for the remaining three types of VPNs Of all these protocols, MPLS is different. It is a specific link layer for IP, so the MPLS specific mechanisms apply only within the scope of an MPLS network, whereas IP based mechanisms extend to the extent of IP reachability.
  • Multiple VLLs may be needed between the same two IP endpoints. Traffic for different customers travels over separate VLLs between the same two physical devices. Have to distinguish which packets belong to which VLL. Actual tunnel establishment could be completed in two ways: management operation or signaling protocol that allows tunnels to be established dynamically. Using signaling protocol significantly reduce the management burden. It is used to negotiate tunneling attributes, not to specify how the tunnel is used (not to limit to specific link layer protocol). MPLS label distribution protocol. All the protocols except IPSec rely on the security of the underlying IP backbone at present only L2TP has such a sequencing field. IPSEC has a sequence number field, but is used by receiver to perform an anti-reply check, not to guarantee in-order delivery of packets
  • VLL tunnel instance occurs as a result of signaling exchange. It needs to be maintained until terminated either (a) when VLL tunnel is deleted or (b) when tunnel instance is not being used/idle timeout => reallocate resources from inactive tunnel Traffic sent through a VLL may often be opaque to the underlying IP backbone. Fragmentation can be done within the tunnel using tunnel sequence number and an end of message marker to avoid IP fragmentation. Security mechanism impose their own overhead Flow and congestion control are needed to provide performance over lossy networks, to accommodate devices with very little buffering. The mechanism used in L2TP are largely specific to the use of PPP and devices that terminate low speed dial-up lines. Customers may require VLLS yield similar behavior to physical leased lines or dedicated connections with respects to parameters like loss rates, latency and bandwidth guarantees. So, all the capabilities currently developed for traffic management (link sharing, differentiated services, and fair scheduling ) could be applied to the VLL.
  • IKE = Internet Key Exchange signaling protocol within IPSec that could be used to negotiate IP tunnel attributes, user authentication and specify security levels.
  • Paper also mention constructing VPNs using native mappings onto switched backbones - e.g. VPNs constructed using, for instance, the LAN emulation over ATM or Multiprotocol over ATM over ATM backbones. This draft doesn't cover that.
  • burden are pushed to ISP, and all forwarding are done at Layer 3. For multiprotocol support, a separate VPRN for each network layer protocol could be used, or one protocol could be tunneled over another, or alternatively, the ISP network could be used to provide layer 2 connectivity only such as with VPLS. Multiple VPRNs may be instantiated over the same set of physical devices, and they might use the same or overlapping address spaces.
  • Since VPRN operates at the internetwork layer, the IP packets send over a tunnel will have their TTL field decrement in the normal manner, to prevent packets circulating indefinitely in the event of a routing loop within the VPRN.
  • Network based VPRNs may potentially span multiple autonomous systems, and multiple management domains. Need a unique VPN identifier that is unique across multiple Ass. Each stub link must be configured with the identify of the particular VPRN to which it belongs. Dissemination of this information can be done in different ways: Directory lookup put all information into a directory that other edge routers could query e.g. LDAP Explicit management configuration: A VPRN management information base (MIB) could be defined to allow a central management system to configure each edge router. Piggybacking in routing protocols: VPRN membership information could be piggybacked into the routing protocols run by each edge router across the IP backbone. Include at the minimum set of VPN identifiers associated with each edge router. Benefit: efficient way of disseminating information. Disadvantage: security issues. Everyone can read the piggybacked information. ISP only needs to know set of VPRN addresses reachable at the customer side. CPE case is more complicated need to know VPRN default route v.s. normal default route (for Internet connection)
  • Along with VPRN membership information, a central directory could maintain a listing of the address prefixes associated with each end point. Explicit configuration is a non-scalable solution. Because the address spaces associated with each edge router is explicitly configured into each other router. Each edge router runs a routing protocol per VPRN, running across VPRN tunnels to each peer edge router. Variation of MPLS LDP: send VPN ID and reachability information of each VPRN running across the tunnel between the two edge routers. Only good if it is a full mesh topology. Set of address prefixes associated with each stub interface is piggybacked into the routing advertisements from each edge router and propagated through the network. Tunneling: manual configuration is NOT scalable multipoint to point tunnels like MPLS.
  • AS with CPE routers, multicast routing protocols could be run on each VPRN edge router to determine the distribution tree for multicast traffic and reduce unnecessary flood traffic. Can run standard multicast routing protocols like PIM (Protocol Independent Multicast), Distance Vector Multicast Routing Protocol (DVMRP). For example, VPRN router could prefix multicast group address within each VPRN with the VPN ID of that VPRN, and then redistribute these, essentially treating this VPNID/Intra-VPRN multicast address tuple as a normal multicast address, within the backbone multicast routing protocols. Then MPLS labeldistribution mechanisms could be used to set up the appropriate multicast LSPs to interconnect those sites within each VPRN supporting particular multicast group addresses.
  • Paper also mention constructing VPNs using native mappings onto switched backbones - e.g. VPNs constructed using, for instance, the LAN emulation over ATM or Multiprotocol over ATM over ATM backbones. This draft doesn't cover that.
  • Packet encapsulation CPE bridge: packets send to and from VPLS across stub links are link layer frames. CPE router: allow for alternative encapsulation Addressing and address resolution bridge CPE: packets forwarded based on link layer addresses (MAC addresses) Router CPE: same as previous case in VPRNs Edge node forwarding an reachability mechanisms bridge: link layer flooding and Mac address learning router: same as VPRNs
  • Right now, such connections are made through PSTN. PPP sessions are authenticated using AAAA systems running such standard protocols as RADIUS.
  • Call routing for compulsory tunnels requires that some aspect of initial PPP call set up can be used to allow the LAC to determine the identity of the LNS. Security: interaction between L2tP with AAAA systems L2TP support flow control. Multiple calls within a tunnel, identified by a call-id. LNS needs to support forwarding mechanisms to route traffic to and from the remote host. MTU of the VPDN tunnel is not necessarily less than or equal to that of the underlying IP route.
  • resources associated within each individual VPN are managed locally, by the customer. Traffic that has a specific QoS needs to use a share of the resources for that VPN. Mark packets and schedule within the core (hierarchical scheduling). Network provides a single hose. Allow customer to control the scheduling of resources by cooperating with the network for serving the different QoS classes. And end point can mark packets with an identifier for the individual QoS. Whenever a scheduling decision for a QoS class within the VPN hose has to be made, the QoS identifier is employed to make the appropriate decision (which one to be transmitted/dropped).
  • Full mesh connectivity in an MPLS environment can be provided by creating a sink tree (LSP tree) to each hose endpoint, from all other hose endpoints.
  • Vpn1

    1. 1. Virtual Private Networks Chen-Nee Chuah Network Reading Group, Spring 99
    2. 2. VPNs <ul><li>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). </li></ul><ul><li>VPNs can be implemented in many ways: </li></ul><ul><ul><li>Customer Premises Equipment (CPE) based solutions </li></ul></ul><ul><ul><li>Network based solutions </li></ul></ul>
    3. 3. Motivations <ul><li>Need private communication networks for multiple sites => “private WANs” </li></ul><ul><li>Two types of existing private networks: </li></ul><ul><ul><li>dedicated WANs (permanently connected) </li></ul></ul><ul><ul><li>dial network (on-demand connections through leased lines from PSTN network or dedicated ATM circuits). </li></ul></ul><ul><li>Running VPNs across Internet offers a cost-effective solution. </li></ul>
    4. 4. Can Internet Support VPNs? <ul><li>Customer requirements for VPNs </li></ul><ul><ul><li>Support for opaque packet transport </li></ul></ul><ul><ul><li>Support for data security </li></ul></ul><ul><ul><li>Support for Quality of Service Guarantees </li></ul></ul><ul><li>Need some form of IP tunneling </li></ul>
    5. 5. CPE Vs. Network Based VPNs <ul><li>Most current VPN implementations are based on CPE devices: </li></ul><ul><ul><li>Firewalls </li></ul></ul><ul><ul><li>WAN edge routers </li></ul></ul><ul><ul><li>Specialized VPN termination devices </li></ul></ul><ul><li>Network based solution: VPN is implemented on network by Internet service provider (ISP) </li></ul><ul><ul><li>Some mechanisms leverage tools that are applicable only to ISPs rather than individual customers running special CPE devices. </li></ul></ul>
    6. 6. Different VPN types <ul><li>Virtual Leased Lines (VLLs) </li></ul><ul><li>Virtual Private Routed Networks (VPRNs) </li></ul><ul><li>Virtual Private LAN Segment (VPLSs) </li></ul><ul><li>Virtual Private Dial Networks (VPDNs) </li></ul>
    7. 7. Type I: Virtual Leased Lines (VLLs) <ul><li>VLL = IP tunnel forming a point-to-point link to emulate a physical leased line or dedicated connection. </li></ul><ul><li>Require IP tunneling mechanism </li></ul><ul><ul><li>forwarding disjoint from the address fields of the encapsulated packets, allow opaque transport of frames as packet payload. </li></ul></ul><ul><ul><li>e.g. IP/IP, GRE tunnels, L2TP (PPP packets), MPLS, and IPSec </li></ul></ul>
    8. 8. VLLs: Tunneling Protocol Requirements <ul><li>Support for VLL Multiplexing </li></ul><ul><ul><li>e.g. tunnel-id & call-id for L2TP, MPLS labels </li></ul></ul><ul><li>Support for a Signaling protocol </li></ul><ul><ul><li>to negotiate tunnel attributes such as security level, IP address of remote end points (e.g. MPLS’s LDP). </li></ul></ul><ul><li>Support for Data Security </li></ul><ul><ul><li>allow customers to specify levels of security </li></ul></ul><ul><li>Support for Multi-protocol Transport </li></ul><ul><li>Support for Frame Sequencing </li></ul><ul><ul><li>required to guarantee in-order delivery of packets </li></ul></ul>
    9. 9. VLLs:Protocol Requirements (continued) <ul><li>Support for Tunnel Maintenance </li></ul><ul><ul><li>establish, maintain and delete tunnel instances </li></ul></ul><ul><li>Support for Large MTUs </li></ul><ul><ul><li>must allow frame fragmentation, either at IP level, or within the tunnel (tunnel sequence number) </li></ul></ul><ul><li>Minimization of Tunnel Overhead </li></ul><ul><ul><li>important for small, jitter and latency sensitive traffic </li></ul></ul><ul><li>Flow and congestion control issues </li></ul><ul><ul><li>currently only L2TP does this, still open to research </li></ul></ul><ul><li>Traffic management issues </li></ul><ul><ul><li>deliver guarantees e.g. loss rates, latency & bandwidth </li></ul></ul>
    10. 10. VLLs: Recommendations <ul><li>A modification of IKE/IPSec may be an optimal choice as a standard VLL tunneling mechanism </li></ul><ul><ul><li>it has well defined signaling & multiplexing capabilities </li></ul></ul><ul><ul><li>it supports security </li></ul></ul><ul><ul><li>close competitor: MPLS </li></ul></ul><ul><li>Using a single signaling protocol and associated data encapsulation is better than using multiple protocols in parallel. </li></ul>
    11. 11. Type II:Virtual Private Routed Networks <ul><li>A VPRN emulates a multi-site wide area routed network over IP, consisting of </li></ul><ul><ul><li>a mesh of IP tunnels btw ISP routers & routing capabilities </li></ul></ul><ul><ul><li>“stub” links connecting CPE routers to ISP routers </li></ul></ul>CPE ISP ISP ISP CPE ISP edge router IP tunnel Stub link Backup link Backdoor link CPE
    12. 12. VPRNs (continued) <ul><li>Benefit: Configuration of the CPE router is simplified. ISP edge router appears to be a “neighbor” router. </li></ul><ul><li>The burden of tunnel establishment, maintenance and routing is on ISPs. Forwarding is done at the network layer (Layer 3). </li></ul><ul><li>Each customer side CPE router is connected to an ISP edge router through one or more stub links (leased lines, ATM or Frame Relay) </li></ul><ul><li>Each VPRN supports only a single network layer protocol. </li></ul>
    13. 13. VPRNs (continued) <ul><li>Issues need to be addressed </li></ul><ul><ul><li>Initial configuration/topology: need to determine set of routers that have members in VPRNs </li></ul></ul><ul><ul><li>CPE routers need to determine set of IP address prefixes to be forwarded to an ISP edge router. </li></ul></ul><ul><ul><li>ISP edge routers </li></ul></ul><ul><ul><ul><li>need to determine the set of IP address prefixes that are reachable via each stub link </li></ul></ul></ul><ul><ul><ul><li>need to learn and disseminate stub reachability information among themselves. </li></ul></ul></ul><ul><ul><ul><li>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. </li></ul></ul></ul><ul><li>Note: similar issues applied to VPLSs. </li></ul>
    14. 14. VPRN Generic Requirements <ul><li>Unique VPN identifier to refer to a particular VPN </li></ul><ul><ul><li>unique across different ASs </li></ul></ul><ul><li>VPRN membership </li></ul><ul><ul><li>configuration </li></ul></ul><ul><ul><li>dissemination (directory lookup, explicit management configuration, piggybacking in routing protocols). </li></ul></ul><ul><li>Stub link reachability information </li></ul><ul><ul><li>edge router must learn set of addresses/address prefixes reachable via each stub link. </li></ul></ul><ul><ul><li>Each CPE router needs to learn the destinations reachable by each stub link. </li></ul></ul>
    15. 15. VPRN Generic Requirements (continued) <ul><li>Intra-VPRN reachability information </li></ul><ul><ul><li>need to be disseminated to other edge routers via one of the following ways </li></ul></ul><ul><ul><ul><li>directory lookup </li></ul></ul></ul><ul><ul><ul><li>explicit configuration </li></ul></ul></ul><ul><ul><ul><li>local intra-VPRN routing instantiations </li></ul></ul></ul><ul><ul><ul><li>link reachability protocol </li></ul></ul></ul><ul><ul><ul><li>piggybacking in IP backbone routing protocols. </li></ul></ul></ul><ul><li>Tunneling mechanism (like VLLs) </li></ul><ul><ul><li>Edge router must construct necessary tunnels to other routers in the VPRN, encapsulate/decapsulate and send/receive packets over the tunnel </li></ul></ul>
    16. 16. VPRNs: Multicast support <ul><li>Multicast & broadcast traffic can be supported by </li></ul><ul><li>Edge replication: </li></ul><ul><ul><li>edge router replicates multicast traffic for transmission across each link in the VPRN </li></ul></ul><ul><li>Native multicast support </li></ul><ul><ul><li>VPRN edge routers map intra-VPN multicast traffic onto a native IP multicast distribution mechanism across the backbone. </li></ul></ul>
    17. 17. VPRNs: Recommendations <ul><li>There are proposals to adapt routing protocols to carry VPN information to support router piggybacking mechanisms. (e.g. MPLS) </li></ul><ul><li>Downside: some ISPs prefer not to couple VPN membership and reachability with backbone routing protocols. </li></ul>
    18. 18. Type III:Virtual Private LAN Segment <ul><li>A VPLS emulates a LAN segment over IP. </li></ul><ul><ul><li>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). </li></ul></ul>ISP ISP ISP CPE ISP edge router IP tunnel Backdoor link CPE CPE
    19. 19. VPLS: Requirements & Recommendations <ul><li>Very similar to VPRNs </li></ul><ul><li>Unlike VPRNs, CPE nodes can either be bridges or routers </li></ul><ul><ul><li>nature of CPE (bridge Vs router) impacts nature of encapsulation, addressing, forwarding and reachability protocols within the VPLS. </li></ul></ul><ul><li>Advantage: protocol transparency. </li></ul><ul><li>Commonality btw VPRNs and VPLSs can be exploited to reduce complexity. </li></ul>
    20. 20. Type IV: Virtual Private Dial Networks <ul><li>A VPDN allows for remote users to connect on demand into remote sites through an hoc tunnels. </li></ul><ul><ul><li>E.g. PPP connections to network access server </li></ul></ul><ul><li>Strong binding btw a particular user and a central side requires authentication & security </li></ul><ul><li>L2TP (Layer 2 Tunneling Protocol) allows user PPP sessions from L2TP access concentrator (LAC) to a remote L2TP network server (LNS) </li></ul>
    21. 21. VPDNs (continued) <ul><li>Support compulsory tunneling </li></ul><ul><ul><li>a dial or network access server (LAC), extends a PPP session across a backbone using L2TP to a remote LNS. </li></ul></ul><ul><li>Other issues: </li></ul><ul><ul><li>Call Routing </li></ul></ul><ul><ul><li>Security mechanism </li></ul></ul><ul><ul><li>Traffic management </li></ul></ul><ul><ul><li>Call multiplexing </li></ul></ul><ul><ul><li>Address management </li></ul></ul><ul><ul><li>Support for large MTUs </li></ul></ul>
    22. 22. VPDNs (continued) <ul><li>Voluntary Tunnels </li></ul><ul><ul><li>an individual host connects to a remote site using a tunnel originating on the host, with no involvement from intermediate network nodes. </li></ul></ul><ul><li>Networked Host Support </li></ul><ul><ul><li>existing PPP based dial model assumes connection oriented dial access network </li></ul></ul><ul><ul><li>want to accommodate existing AAAA infrastructure within service providers </li></ul></ul><ul><ul><ul><li>extend PPP to hosts through L2TP </li></ul></ul></ul><ul><ul><ul><li>extend PPP directly to hosts </li></ul></ul></ul><ul><ul><ul><li>use of IPSec </li></ul></ul></ul>
    23. 23. VPDNs: Recommendation <ul><li>L2TP specifications are being finalized to support VPDNs using compulsory tunneling. </li></ul><ul><li>Further study need to be done to determine the best solution for voluntary tunneling </li></ul><ul><ul><li>PPP based solution or </li></ul></ul><ul><ul><li>IPSec based mechanism. </li></ul></ul>
    24. 24. Summary <ul><li>Further standardization efforts needed in defining </li></ul><ul><ul><li>a generic VPN tunneling protocol </li></ul></ul><ul><ul><li>a globally unique VPN identifier </li></ul></ul><ul><ul><li>a VPN membership information configuration and dissemination mechanism </li></ul></ul><ul><li>Further study is needed to address </li></ul><ul><ul><li>security issues </li></ul></ul><ul><ul><li>scalability of membership configuration and dissemination mechanism </li></ul></ul>
    25. 25. QoS Guarantees in VPNs <ul><li>Goal: obtain differentiated & dependable QoS for flows belonging to a VPN </li></ul><ul><li>2 performance service abstractions: Pipe & Hose </li></ul><ul><ul><li>A pipe provides performance guarantees for traffic btw A specific origin and destination pair </li></ul></ul><ul><ul><li>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. </li></ul></ul>
    26. 26. QoS Support <ul><li>Service Level Agreement (SLA) btw a customer & a service provider </li></ul><ul><ul><li>traffic characteristics and QoS requirements </li></ul></ul><ul><li>Two ways to support different QoS classes within VPN: </li></ul><ul><ul><li>resources are managed on a VPN specific basis, i.e. SLAs would be for the overall VPN rather than for each specific QoS class </li></ul></ul><ul><ul><ul><li>Schedule only at the edges </li></ul></ul></ul><ul><ul><ul><li>Mark packets and schedule within the core </li></ul></ul></ul><ul><ul><li>resources are managed on an individual QoS basis </li></ul></ul>
    27. 27. Summary <ul><li>Different choices for the implementation of hoses in VPNs </li></ul><ul><ul><li>integrated service framework (controlled load, guaranteed load) with signaling protocol like RSVP </li></ul></ul><ul><ul><li>differentiated service framework (DS byte of IP header) </li></ul></ul><ul><ul><li>MPLS environment (LSP tree) </li></ul></ul><ul><li>Security </li></ul><ul><ul><li>IPSec is recommended. The only limitation is scalability. </li></ul></ul>