ECE 646 Final Project · ECE 646 Final Project Analysis of VPN Protocols Touhid Satiar, Tamer Mabrouk Department of Electrical and Computer Engineering George Mason University

ECE 646 Final Project

Analysis of VPN Protocols

Touhid Satiar, Tamer Mabrouk

Department of Electrical and Computer Engineering George Mason University

Fairfax, VA 22202


TABLE OF CONTENTS

I. INTRODUCTION.................................................................................. 4 II. EMERGENCE OF VPNS ..................................................................... 4

A. Background of VPN............................................................................................... 4 B. Timeline of Networking ......................................................................................... 5

III. CONCEPT OF TUNNELING .............................................................. 6 IV. DIFFERENT TYPES OF TUNNELING TECHNOLOGIES........... 7

A. Customer Premise Equipment (CPE) based VPN...................................................... 8 1. Point to Point Tunneling Protocol (PPTP).............................................................. 8 2. Layer 2 Forwarding Protocol (L2F)........................................................................ 8 3. Layer 2 Tunneling Protocol (L2TP) ....................................................................... 9 4. Internet Protocol Security (IPSec) Tunnel .............................................................. 9

B. Provider Provisioned based VPN............................................................................. 10 1. MPLS Layer-3 VPNs............................................................................................ 11 2. MPLS Layer 2 VPNs ............................................................................................ 13

a. Point-to-Point Connectivity .............................................................................. 13 b. Multi-Point Connectivity .................................................................................. 15

V. COMPARISON OF PROTOCOLS................................................... 17 A. Customer Premise Equipment (CPE) based Protocols ............................................ 17

1. Security Issues ..................................................................................................... 17 2. Authentication...................................................................................................... 17 3. Encryption............................................................................................................. 18 4. Key Management ................................................................................................. 21 5. Vulnerability ........................................................................................................ 21 7. Interoperability..................................................................................................... 26 8. Performance ......................................................................................................... 27 9. MultiProtocol Support ......................................................................................... 27

B. Provider Provisioned VPN Protocol Comparison................................................... 28 1. Security Issues ..................................................................................................... 28 2. Deployment Considerations:................................................................................ 28 3. Interoperability..................................................................................................... 29 4. Performance ......................................................................................................... 31 5. Muti-protocol support ........................................................................................... 31

VI. OSI MODEL AND VPN PROTOCOLS ........................................... 31 VII. FUTURE OF VPN............................................................................ 32

A. Voice and Video over VPN .................................................................................... 32 B. Cellular Telephony and VPNs.................................................................................. 33 C. SSL VPN.................................................................................................................. 33

VIII. CONCLUSION................................................................................. 34 IX. References ............................................................................................. 35

Page 2


TABLE OF FIGURES

FIG.1 PRIMARY VPN USE MARKET POLL ............................................................................. 4 FIG. 2 TUNNEL...................................................................................................................... 7 FIG.3 VPN FAMILY TREE ...................................................................................................... 8 FIG.4 THE BGP/MPLS VPN APPROACH. ............................................................................... 12 FIG.5 TWO LABELS ARE ATTACHED TO AN IP DATAGRAM TO BE FORWARDED TO ITS

DESTINATION ............................................................................................................ 13 FIG.6 A MARTINI ENCAPSULATED ETHERNET FRAME GETS TWO LABELS ATTACHED TO IT

................................................................................................................................... 14FIG.7 A TUNNEL LSP CARRIES MULTIPLE VCS, A VC CARRIES A GIVEN CUSTOMER'S

TRAFFIC..................................................................................................................... 15 FIG.8 THE VPLS APPROACH................................................................................................ 16 FIG. 9 L2TP SECUIRTY WITH IPSEC..................................................................................... 19 FIG.10 NON-IP ENABLED AND IP ENABLED DESTINATIONS ............................................... 20 FIG. 11 IPSEC AND MPLS INTEGRATED VPN ARCHITECTURE. ........................................... 30 FIG. 12 HOW SSL WORKS.................................................................................................... 34

Page 3


I. INTRODUCTION A virtual private network (VPN) is a private network that uses a public network (usually the Internet) to connect remote sites or users together. Instead of using a dedicated, real-world connection such as leased line, a VPN uses "virtual" connections routed through the Internet from the company's private network to the remote site or employee. The main goal of companies adapting VPN solutions (Figure1) is to minimize telecommunication costs. According to a Gartner Consulting study, “ A T1 to Belgium is about $18,000 a year compared to virtually free with the use of a VPN”[1]. Also a VPN Research Report by Infonetics Research Inc. estimates savings from 20% to 47% of wide area network costs by replacing leased lines to remote sites with VPNs. Remote access VPN savings can be 60% to 80% of corporate remote access dial-up costs. In order to extend the reach of a company's Intranet(s) VPN over the Internet guarantees two main benefits: cost efficiency and global reachability. This paper will explore the fundamentals of VPNs, VPN components, technologies, protocols, tunneling and security[2].

FIG.1 PRIMARY VPN USE MARKET POLL

II. EMERGENCE OF VPNS A. Background of VPN There is growing interest in the use of VPNs as a more cost effective means of building and deploying private communication networks for multi-site communication . Existing private networks can be generally categorized into two types: dedicated WANs that

Page 4

http://computer.howstuffworks.com/router.htm


permanently connect together multiple sites, and dial networks, that allow on-demand connections through the Public Switched Telephone Network (PSTN) to one or more sites in the private network. WANs are typically implemented using leased lines or dedicated circuits, for instance, Frame Relay or ATM connections between the multiple sites. Customer Premise Equipment (CPE) routers or switches at the various sites connect these dedicated facilities together and allow for connectivity across the network. Given the cost and complexity of such dedicated facilities and the complexity of CPE device configuration, such networks are generally not fully meshed, but instead have some form of hierarchical topology. For example remote offices could be connected directly to the nearest regional office, with the regional offices connected together in some form of full or partial mesh. Private dial networks are used to allow remote users to connect into an enterprise network using PSTN or Integrated Services Digital Network (ISDN) links. Typically, this is done through the deployment of Network Access Servers (NAS) at one or more central sites. Users dial into such NASs, which interact with Authentication, Authorization, and Accounting (AAA) servers to verify the identity of the user, and the set of services that the user is authorized to receive. In recent times, as more businesses have found the need for high speed Internet connections to their private corporate networks, there has been significant interest in the deployment of CPE based VPNs running across the Internet. This has been driven typically by the ubiquity and distance insensitive pricing of current Internet services, that can result in significantly lower costs than typical dedicated or leased line services. The notion of using the Internet for private communications is not new, and many techniques have been used for this purpose. Only in recent times, however, have the appropriate IP mechanisms needed to meet customer requirements for VPNs all come together. The timeline below illustrates the emergency of VPNs. B. Timeline of Networking 1960-1970: During this period telecommunication was monolithic and vertically integrated. The voice and computing communication, application, database were localized. There was no concept of interconnection between any of these. At the end of this era, the concept of mainframe and Private Branch Exchange (PBX) came into picture and clients started to communicate to a vertically integrated fashion to each other. This is the first birth of telecommunications. 1980: This is the timeframe when the concept of client and servers came into the picture. During this era mainframes were being connected through clients and servers. Information was transmitted over wire line through the use of client, servers and mainframe. The local area protocol and concepts of System Network Archietecture (SNA) was invented and was in the process of being widely distributed.

Page 5


1988-1998 During this timeframe the concept of Application servers, database servers and communication storage was being accessed through the wide area network with through x.25, frame relay, and ATM. Around this time the client and users were using this private networks over the WAN and accessing their private network. This is the timeframe when the concept of an Internet was widely taking its shape. 1999: At this timeframe the aggregation of IP telephony, Database server Storage, and application servers all began emerging. During this time, the Voice and Data networks started to converge. New Millenium: During the start of the new millenium the telecommunication industry started to see a migration of WAN towards the Public infrastructure. The old concept of remote dial and dedicated frame relay, leased lines and ATM was shifted towards the Remote Access VPN, DSL, and cable line. The shift was towards utilizing the public network with IP WAN services and VPN.

III. CONCEPT OF TUNNELING

A tunnel is a virtual connection between locations that uses the internet infrastructure to transfer data from one network to another. A VPN can be created by using this concept of "tunneling". The key idea is that "tunneling" is a technology that allows a network transport protocols to carry information for other protocols within its own packets. A tunnel connecting two VPN endpoints is a basic building block from which a variety of different VPN services can be constructed. A distinguishing characteristic of different types of VPNs, is the manner in which packets are forwarded between interfaces. Using the tunnel connection, packets constructed in a specific VPN protocol format are encapsulated within some other base or carrier protocol, transmitted between VPN client and server, and finally de-encapsulated on the receiving side. The protocol of the outer packet is understood by the network and both points, called tunnel interfaces, where the packet enters and exits the network. The logical path through which the encapsulated packets travel through the internet is called a tunnel (Figure2)[3].

Page 6


FIG. 2 TUNNEL The data being transferred can be frames (or packets) of another protocol. Instead of sending a frame as it is produced by the originating node, the tunneling protocol encapsulates the frame in an additional header. The additional header provides routing information so that the encapsulated payload can traverse the intermediate internet. The encapsulated packets are then routed between tunnel endpoints over the internet. Tunneling includes this entire process (encapsulation, transmission, and de-capsulation of packets). Tunneling requires three different protocols:

Carrier protocol - The protocol used by the network that the information is traveling over.

Encapsulating protocol - The protocol that is wrapped around the original data. (GRE, IPSec, L2F, PPTP, L2TP, MPLS)

Passenger protocol - The original data (IPX, NetBeui, IP) being carried

IV. DIFFERENT TYPES OF TUNNELING TECHNOLOGIES This paper will examine the different tunneling protocols through two segmented categories: Customer Premise Equipment (CPE) based VPN and Provider Provisioned based VPN.

Page 7


FIG.3 VPN FAMILY TREE

A. Customer Premise Equipment (CPE) based VPN “CPE-based” VPNs, are implemented within customer premises equipment, using these techniques a customer can create their own VPN across an Internet connection without any specific knowledge or cooperation from the service provider. This is good for the customers because privacy issues are solved over an inexpensive Internet connection. It may be bad for the ISP because it is not generating any additional revenue from VPN services. The following protocols are evaluated under this category:

Point to Point Tunneling Protocol (PPTP) Layer 2 Forwarding Protocol (L2F) Layer 2 Tunneling Protocol (L2TP) Internet Protocol Security (IPSec)

1. Point to Point Tunneling Protocol (PPTP) PPTP was created by a consortium of companies including Microsoft, 3Com, U.S. robotics, and Ascend Communications. It is an extension of the Internet's Point-to-Point Protocol (PPP), any user of a PC with PPP client support is able to use an independent service provider (ISP) to connect securely to a server elsewhere in the user's company. PPTP is flexible protocol because it can run over the dial-up lines, LANs or WANs. PPTP uses a TCP connection for tunnel maintenance and a modified version of Generic Routing Encapsulation (GRE) to encapsulate PPP frames for tunneled data. The payloads of the encapsulated PPP frames can be encrypted and/or compressed. Figure 2 shows the structure of a PPTP packet containing user data[4]. 2. Layer 2 Forwarding Protocol (L2F)

Page 8

http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci214311,00.html

http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci214028,00.html


The L2F protocol was created by CISCO, (specified in RFC 2341). It is not specifically a VPN protocol, because it does not provide any encryption services. Recently, Microsoft and Cisco agreed to merge their respective protocols into a single, standard protocol called Layer Two Tunneling Protocol (L2TP). L2F is being fazed out of the market, and is being replaced by L2TP. For this reason this paper will not evaluate this protocol as significantly as the remaining practical protocols. 3. Layer 2 Tunneling Protocol (L2TP)

L2TP is a combination of Point to Point Tunneling Protocol (PPTP) and Layer 2 Forwarding (L2F). L2TP represents the best features of PPTP and L2F. L2TP encapsulates PPP frames to be sent over IP, X.25, Frame Relay, or Asynchronous Transfer Mode (ATM) networks. When configured to use IP as its datagram transport, L2TP can be used as a tunneling protocol over the Internet. The two main components that make up L2TP are the L2TP Access Concentrator (LAC), which is the device that physically terminates a call and the L2TP Network Server (LNS), which is the device that terminates and possibly authenticates the PPP stream. PPP defines a means of encapsulation to transmit multiprotocol packets over layer two (L2) point-to-point links. Generally, a user connects to a network access server (NAS) through ISDN, ADSL, and dialup POTS or other service and runs PPP over that connection. In this configuration, the L2 and PPP session endpoints are both on the same NAS. L2TP uses packet-switched network connections to make it possible for the endpoints to be located on different machines. The user has an L2 connection to an access concentrator, which then tunnels individual PPP frames to the NAS, so that the packets can be processed separately from the location of the circuit termination. This means that the connection can terminate at a local circuit concentrator, eliminating possible long-distance charges, among other benefits. From the user's point of view, there is no difference in the operation[3].

4. Internet Protocol Security (IPSec) Tunnel

Internet Protocol Security (IPSec) is a set of protocols developed by the IETF to support secure exchange of packets at the IP layer. IPsec has been deployed widely to implement VPNs. It can be used as a complete VPN protocol solution, or it can used simply as the encryption scheme within L2TP or PPTP. Ipsec exists at the network layer (layer three) in OSI. So IPSec is a Layer 3 protocol standard. IPsec supports two encryption modes: Transport and Tunnel. Transport mode encrypts only the data portion (payload) of each packet, but leaves the header untouched. The more secure Tunnel mode encrypts both the header and the payload. On the receiving side, an IPSec-compliant device decrypts each packet. For IPsec to work, the sending and receiving devices must share a public key. This is accomplished through a protocol known as Internet Security Association and Key Management Protocol/Oakley (ISAKMP/Oakley), which allows the receiver to obtain a public key and authenticate the sender using digital certificates. However, one aspect of IPSec should be discussed in the context of tunneling protocols. In addition to its definition of encryption mechanisms for IP traffic, IPSec defines the packet format for an IP over IP tunnel mode, generally referred to as IPSec tunnel mode. An IPSec tunnel

Page 9

http://www.webopedia.com/TERM/L/L2TP.html

http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci214311,00.html

http://www.webopedia.com/TERM/I/protocol.html

http://www.webopedia.com/TERM/I/IETF.html

http://www.webopedia.com/TERM/I/packet.html

http://www.webopedia.com/TERM/I/IP.html

http://www.webopedia.com/TERM/I/header.html

http://www.webopedia.com/TERM/I/public_key_cryptography.html

http://www.webopedia.com/TERM/I/authentication.html

http://www.webopedia.com/TERM/I/digital_certificate.html


consists of a tunnel client and a tunnel server, which are both configured to use IPSec tunneling and a negotiated encryption mechanism.

IPSec tunnel mode uses the negotiated security method (if any) to encapsulate and encrypt entire IP packets for secure transfer across a private or public IP internet. The encrypted payload is then encapsulated again with a plain-text IP header and sent on the internet for delivery to the tunnel server. Upon receipt of this datagram, the tunnel server processes and discards the plain-text IP header, and then decrypts its contents to retrieve the original payload IP packet. The payload IP packet is then processed normally and routed to its destination on the target network. IPSec tunnel mode has the following features and limitations: • It supports IP traffic only. • It functions at the bottom of the IP stack; therefore, applications and higher-level

protocols inherit its behavior. • It is controlled by a security policy—a set of filter-matching rules. This security

policy establishes the encryption and tunneling mechanisms available, in order of preference, and the authentication methods available, also in order of preference. As soon as there is traffic, the two computers perform mutual authentication, and then negotiate the encryption methods to be used. Thereafter, all traffic is encrypted using the negotiated encryption mechanism, and then wrapped in a tunnel header[5].

B. Provider Provisioned based VPN Provider provisioned VPN is an application of MPLS. These types of VPNs are implemented over the infrastructure that runs MPLS in the Service Provider core. Using MPLS for implementing VPNs is a viable alternative to using a pure layer-2 solution, a pure layer-3 solution, or any of the tunneling methods commonly used for implementing VPNs. There are two types of solution for IP/MPLS-based VPN, for service provider : • A layer-3 approach, commonly referred to as MPLS Layer-3 VPNs • A layer-2 approach, commonly referred to as MPLS Layer-2 VPNs The main characteristics of MPLS VPN include:

• Privacy: MPLS VPN offers privacy over a shared (public) network infrastructure. • IP Addressing Freedom: enables the use of overlapping private IP addresses.

Provided that the sites do not need to access the global network, sites that belong to different VPNs can use overlapping IP addresses.

• Security: MPLS VPN security is comparable to that of ATM and Frame Relay. • Outstanding Scalability: RFC2547 calls for over 100,000 sites. It also serves as

a management tool for Service Providers to control access to services (ie: closed

Page 10


user groups for data and voice services). Controlled access places performance limits upon authorized programs, processes, or other systems in a network.

• Access or Backbone technology independent: support a mix of media, including ATM, LL, FR, Ethernet, and GE.

• Flexibility: MPLS VPN is a connectionless service. Any-to-any traffic patterns are easily accommodated without the set up of complex mesh of sites. New sites can be easily added or removed without affecting communication with existing sites. It also supports Hub and Spoke setup or any-any (full mesh) models are also supported.

• Predictable performance/SLAs: Intranet applications that use MPLS VPN support different classes of service. The service-level performance between customer sites could be mapped to differentiate classes of service across the backbone, providing the bandwidth guarantees and sustained performance that is required by interactive intranet applications in branch offices.

• Simplified Provisioning: VPNs can be quickly configured with the Cisco provisioning and management tool VPN Solutions Center (VPNSC).

• Flexible Services: Service Providers can offer centralized shared services for VPNs. Enterprise customers can purchase all or some of the services from the Service Provider. Service examples: VoIP/IP Telephony, WEB hosting, Multicast, Telecommuter, E-commerce, Virtual ISP, Unified communication, Internet connectivity, IP address translation, and Cisco IOS Firewall [6].

1. MPLS Layer-3 VPNs The layer-3 approach to creating MPLS-based VPNs offers a routed solution to the problem. The de facto standard for implementing such VPNs is described in "RFC 2547", with a new version, currently, under development referred to as 2547bis which is described in "draft-ietf-ppvpn-rfc2547bis-01.txt". The approach is also referred to as BGP/MPLS VPNs. The approach relies on taking customer IP datagram from a given site, looking up the destination IP address of the datagram in a forwarding table, then sending that datagram to its destination across the provider's network using an LSP. In order for the service provider routers to acquire reachability information about a given customer's networks, the provider edge (PE) routers exchange routes with the customer edge (CE) routers. Hence, the BGP/MPLS VPNs approach follows the peer to peer model of VPNs. These routes are propagated to other PE routers carrying the same VPN(s) via BGP. However, they are never shared with the provider's core routers (P), since the PEs use LSPs to forward packets from one PE to the other. P routers do not need to know about the customer's networks in order to perform their label switching functions. A PE router receiving routes of a given VPN site from another PE, propagates the routes to the CE router of the connected site belonging to that same VPN, so that the CE will also learn about the networks in the remote site. The mechanisms behind BGP/MPLS VPNs were designed to address some of the shortcomings of the pure layer-3 VPNs (without tunneling) that preceded it. Some of the main goals were:

Page 11


• Supporting globally unique IP addresses on the customer side, as well as private non-unique - and hence, overlapping - addresses.

• Supporting overlapping VPNs, where one site could belong to more than one VPN

Since this type of VPNs relies on routing, achieving the abovementioned goals could be a challenge. To address the problem of overlapping address spaces in customer VPNs, multiple routing and forwarding tables, referred to as VPN Routing and Forwarding (VRF) tables, are created on each PE router, in order to separate the routes belonging to different VPNs on a PE router.

FIG.4 THE BGP/MPLS VPN APPROACH.

When a PE receives a packet with a destination in a remote site, it attaches two MPLS labels to the packet in order to forward it to its destination. The outer label is for the LSP leading to the BGP NEXT_HOP. The inner label is the label associated with that destination, learned previously from a BGP update received from a peer. The PE, then, sends the frame out the port associated with that LSP. The frame gets label switched all the way to the remote PE, which then, pops the outer label, and examines the inner label. The inner label, in most cases, uniquely identifies the destination, therefore, it is popped and the packet is forwarded to its destination. In some cases, where route summarization

Page 12


is done on the PE, the receiving PE uses the inner label to determine which VRF to look into in order to know where to send the packet.

FIG.5 TWO LABELS ARE ATTACHED TO AN IP DATAGRAM TO BE FORWARDED TO

ITS DESTINATION 2. MPLS Layer 2 VPNs The layer-2 approach is the newer approach to implementing MPLS-based VPNs, and it offers a layer-2 switched solution. The layer-2 approach provides complete separation between the provider's network and the customer's network, i.e., there is no route exchange between the PE devices and the CE devices. Hence, the approach follows the overlay model of VPNs. The separation between the provider's network and the customer's networks provides simplicity. MPLS layer-2 VPNs provide emulated services capable of carrying customer layer-2 frames from one site to the other. This is done in a manner that is totally transparent to the CE devices. Handling customer layer-2 frames allows the service provider to offer a service that is independent of the layer-3 protocols in use by the customers, i.e., the provider would be able to carry IPv4, IPv6, IPX, DECNet, OSI, etc. The layer-2 approach addresses two connectivity problems:

• Providing Point-to-Point connectivity • Providing Multi-Point Connectivity

a. Point-to-Point Connectivity The de facto standard for establishing point-to-point connectivity in MPLS layer-2 VPNs is described in the Martini drafts:

• "draft-martini-l2circuit-trans-mpls-08.txt" • "draft-martini-l2circuit-encap-mpls-04.txt"

Page 13


In order to carry layer-2 frames across an MPLS cloud, the Martini drafts introduce the concept of Virtual Circuits (VCs). An LSP acts as a tunnel carrying multiple VCs, whereas a VC acts like the actual circuit carrying customer layer-2 frames. A VC, actually, is just another LSP within the original tunnel LSP. The tunnel LSP provides the tunnel between two PE routers, while the VC carries frames of a given customer only. VCs are uni-directional just like normal LSPs. Hence, for bi-directional communication, a pair of VCs - one in each direction - is need. In order to create this hierarchy, an encapsulated customer frame traversing the service provider network has two labels attached to it: • A label pertaining to the tunnel LSP leading to a destination PE. This is called the "tunnel label". • A label pertaining to the VC that carries the frame and leads to a certain site attached to the destination PE. This is called the "VC label".

FIG.6 A MARTINI ENCAPSULATED ETHERNET FRAME GETS TWO LABELS ATTACHED

TO IT Tunnel LSPs between the PE routers could be created using any protocol like RSVP/TE or LDP. PE routers exchange the VC labels via LDP in downstream unsolicited mode. At the edge of the provider network, the PE router encapsulates the subscriber layer-2 frame as per the Martini drafts, attaches a VC label and a tunnel label, then sends the frame over the tunnel LSP. At the other end of the tunnel LSP, the receiving PE router pops the tunnel label, determines which customer port the packet should go to based on the VC label, extracts the original layer-2 frame, and sends it out the port determined above.

Page 14


FIG.7 A TUNNEL LSP CARRIES MULTIPLE VCS, A VC CARRIES A GIVEN CUSTOMER'S

TRAFFIC

Using this approach, a service provider could offer a service that resembles leased lines or Frame Relay PVCs, while using cheaper building blocks in the infrastructure: IP, Packet Over Sonet (PoS), Ethernet, etc. b. Multi-Point Connectivity Currently, there are several proposals within the IETF that address the problem of multiple site connectivity at layer-2. The goal here is a solution that facilitates carrying customer layer-2 frames - specifically, Ethernet - over the service provider's IP/MPLS network from and to multiple sites that belong to a given VPN (customer). For efficient use of the provider's network bandwidth, a frame should be sent only to the PE that connects to the target site of the frame whenever possible, instead of being flooded. This is accomplished by switching the customer frames based on their destination MAC address. The end result is a simple service that emulates connecting the sites constituting the VPN via a layer-2 switch. The popular approach to implementing such a solution is called Virtual Private LAN Services (VPLS). The core of the technology is described in "draft-lasserre-vkompella-ppvpn-vpls-00.txt", with several enhancements described in other drafts. The VPLS approach expands on the concepts introduced by the Martini drafts that were used for establishing point-to-point connectivity. It builds the VPN by creating a full mesh of VCs between the PEs facing the sites that make the VPN. Note that VCs are uni-

Page 15


directional, therefore, between any pair of PEs there should be a pair of VCs to carry bi-directional traffic. VPLS as described in the aforementioned draft relies on LDP for the exchange of VC labels between the PE routers. However, other methods of signaling could be used, and are described in other drafts. Customer VPNs are identified via a unique VPN ID, currently, a 32 bit value. Several proposals exist for expanding that ID to a 56 or a 64 bit value. Another proposal was made to use simple descriptive text strings as VPN IDs that can be stored in the DNS system to ease provisioning. A PE router maintains a separate layer-2 forwarding table, called Virtual Forwarding Instance (VFI), for each VPN that it carries. Figure 8 illustrates the basic concepts behind the VPLS approach.

FIG.8 THE VPLS APPROACH

As seen in Figure 8, overlapping VPNs could be implemented using VPLS. Customer A,

e

Site 1 lies in both VPN 1 and VPN 2. To separate traffic belonging to each VPN, the customer site could be connected to the PE router using two access links, one for eachVPN. Alternatively, traffic belonging to both VPNs could be multiplexed over the sameaccess link using two different VLAN IDs, where one VLAN ID maps to VPN 1, the other ID maps to VPN 2. The use of more than one 802.1Q tag within a frame helps thservice provider and the customer use the required service tag (VLAN ID) without having any impact on the customer's choice of their own VLAN IDs.

Page 16


In contrast with the layer-3 approach, the task of controlling the routes that get advertised

V. COMPARISON OF PROTOCOLS

A. Customer Premise Equipment (CPE) based Protocols

. Security Issues irtual private networks" is private therefore security is a fundamental

. Authentication unneled sessions is the same for L2F, PPTP, and L2TP. All three rely

r ate

pon agreement, a Security Association (SA) is created that specifies the parameters for

tion algorithm SP

eys

equence number

in each VPN remains the customer's responsibility-since the PE router does not handle any customer routes [7].

This section will compare CPE protocols. 1The key word in "vpart of all VPNs. Only IPSec provides the complete built-in security mechanisms. PPTP and L2TP do not provide data security functions but rely on PPP for their authentication and encryption services. This paper will explore specific considerations internal to security including authentication, encryption key management and vulnerabilities. 2Authentication of ton the PPP authentication schemes: PAP, CHAP, and EAP for providing user authentication. IPSec uses two security protocols for authentication: Authentication Header (AH) and Encapsulating Security Payload (ESP). AH and ESP can be used together. ESP is the most popular implementation today, since it provides privacy foinformation that AH does not. When an IPSec VPN session is started, both ends negotiall parameters through the Internet Key Exchange (IKE) protocol. IKE is an automatic keying mechanism, requiring two phases in establishment of a VPN tunnel. Phase 1 establishes the Internet Security Association Key Management Protocol (ISAKMP) tunnel that manages one or more Phase 2 IPSec data tunnels [5]. Ueach VPN tunnel. There may be several tunnels active at any point in time on a server, each one with a different SA. A random parameter called a Security Parameter Index (SPI) is set up to uniquely identify the particular VPN tunnel. An SA specifies the following: • The authentica• The encryption algorithm for E• The encryption and authentication k• The lifetime of the encryption keys • The lifetime of the SA • The replay prevention s

Page 17


The AH provides authentication, integrity and replay protection for all packets. However, it does not provide for privacy/confidentiality protection. The AH provides its features by using a keyed hash (or MAC) for each packet created, which can then be validated at the receiving end. The ESP also provides data authentication. Authentication that occurs during the creation of the L2TP tunnels must use the same authentication mechanisms as PPP connections such as EAP, MS-CHAP, CHAP, SPAP, and PAP as mentioned before. L2TP tunnel maintenance and tunneled data have the same packet structure. L2TP control messages over IP are sent over UDP datagrams. They are sent as encrypted payload of IPSec ESP as shown below [4]. 3. Encryption

IPSec is the only protocol has inherent encryption mechanisms. Microsoft Point-to-Point Encryption (MPPE) may be used with PPTP to provide an encrypted connection but PPTP itself doesn’t use encryption. For data encryption, PPTP uses the RAS “shared-secret” encryption process. It is referred to as a shared-secret because both ends of the connection share the encryption key. PPTP uses the PPP encryption and PPP compression schemes. The Compression Control Protocol (CCP) used by PPP is used to negotiate encryption. The user name and password of the PPTP client is available to the PPTP server and supplied by the PPTP client. An encryption key is derived from the hashed password stored on both the client and server. The RSA RC4 standard is used to create this 40-bit session key based on the client password. This key is used to encrypt all data that is passed over the Internet, keeping the remote connection private and secure. L2TP requires that the underline transport make available encryption, L2TP can inherit encryption capabilities when uses with IPSec [5]. RFC 3193 discusses how L2TP may utilize IPSec to provide for tunnel authentication, encryption, privacy protection, and integrity checking and replay protection. IPSec protocols AH or ESP can be used to protect the L2TP tunnel through the following ways:

• Provides authentication and /or Encryption for the user data including the PPP and L2TP header within the Internet.

• Protects the entire connection from the remote client to the LNS gateway in voluntary tunnel mode through intervening network

• In compulsory tunnel mode, the PPP header between the remote client and the ISP is not protected by IPSec.

• Protection ends at the LNS gateway on the corporate site End to End protection for IPSec enabled destinations

• Provides end-to-end protection for IPSec enabled hosts in the corporate network and the remote client.

Page 18


Eth

erne

t

FIG. 9 L2TP SECUIRTY WITH IPSEC

The IPSec protocols Authentication Header (AH) and/or Encapsulated Security protocol is used to protect a L2TP tunnel. There are little differences in the protection level, depending on the tunnel mode used. In voluntary tunnel mode, all the traffic including the L2TP and virtual PPP header is protected by IPSec. In the compulsory tunnel mode all traffic is protected except the PPP header between the remote client and the ISP. If the destination host in the corporate network is also IPSec enabled, the client can establish a second VPN connection to the destination host. This provides the end to end security [5].

Page 19


FIG.10 NON-IP ENABLED AND IP ENABLED DESTINATIONS

IPSec uses the Encapsulating Security Payload (ESP) as an authenticating and encrypting protocol that uses cryptographic mechanisms to provide data confidentiality, authentication, integrity, replay protection and limited traffic flow confidentiality. This is accomplished by encrypting and hashing data as specified by the SA.

There are two modes of operation for ESP:

a. Transport mode, in which the protocol operates primarily on the payload of the original datagram. b. Tunnel mode, which puts an existing IP packet inside a new IP packet that is sent to a tunnel end point in the IPSec format. In this mode, the source and destination IP address are often, but not always, different from those in the header of the original datagram.

Page 20


4. Key Management IPSec provides key management and managing the distribution of secret keys between the users of a network through the IKE protocol. However PPTP, L2TP, L2F provide no key management services. 5. Vulnerability In this section we will discuss different types of vulnerabilities that VPN elements are open to. At the end of this section, attacks against PPTP and IPSec protocol area also discussed. VPN operating system Vulnerabilities: VPN can be installed on operating systems, routers, black boxes – almost any device in a network. Therefore, the vulnerabilities that exists on certain platforms is a vulnerability for that platform. In any computing system, the operating system needs to be secure. Attacks that occur on operating system do not occur through the front door but by a side entrance or backdoor. The keys are the security in VPNS. If the key gets compromised, then the VPN framework has been compromised. So a VPN vulnerability would be any vulnerability that would allow this to happen. Some of the examples of VPN operating system vulnerabilities are as follows: Buffer overflows (when the root can be accessed) Sendmail exploits (where attackers could mail copies of the key to themselves) Insecure file systems (where the directory that contains the key could be remotely mounted) VPN Security Attacks: In this portion of the essay, we will talk about any attack that could eventually lead to VPN data being revealed as a VPN attack. If attackers break the algorithm, if they get into the server and read keys or if they mount an attack on the tunnel – these all will be VPN attacks. Cryptographic Algorithm attack: There are generally three ways to attack a cryptographic algorithm: Attack against protocol Attack against algorithm Attack against implementation Attack against protocol: A cryptographic system is only as strong as the encryption algorithms and the hash functions it is based on. By breaking any of these, the whole system can be broke into. By

Page 21


not using the right random-number generators, reusing values, and so forth hurt the integrity of a cryptographic system – allowing someone to potentially break into the system. Attack against the Algorithm: The algorithm, or the mathematical operations that are performed on the data, could make the whole system break. Up until now that proprietary encryption, previously secret algorithm which were reverse engineered and proven to be ineffective. Using weak keys, insufficient amount of data size, and altering hash functions all contribute to the weakening of the systems. Attack against the Implementation: In recent days, there are so many different ways of implementing cryptographic algorithms. But the basics of these implementations might be faulty. For example, some implementations leave temporary files, plain-text messages, and data stored in buffers where they can be easily retrieved. Using combination of weak keys along with strong key can also be compromised. The vulnerabilities of key recovery are a major contributor to implementation attacks. Common attacks on cryptographic algorithms: Following are several of the common categories of algorithm attacks and the corresponding information known to the attackers Type of Attack Known to Attacker Ciphertext Only • Encryption Algorithm

• Ciphertext to be decoded Known Plaintext • Encryption Algorithm

• Ciphertext to be decoded • One or more plaintext-ciphertext pairs formed with the secret

key. Chosen Plaintext • Encryption Algorithm

• Ciphertext to be decoded • Plaintext message chosen by cryptanalyst, together with its

corresponding ciphertext generated with the secret key. Chosen Ciphertext

• Encryption Algorithm • Ciphertext to be decoded • Purported Ciphertext chosen by the cryptanalyst , together

with its corresponding decrypted plaintext generated with the secret key.

Man-in-the-middle attack:

Page 22


In this case, two parties exchange their keys for later communications. The ‘man-in-the-middle’ hijacks the sender’s and receiver’s keys and substitutes his or her own, thereby giving the attacker the ability to intercept all future communication without either the sender or receiver knowing about it. Timing attack: This type of attack is based measuring the execution times of a modular exponentiation operation that is used in cryptographic algorithms. Cryptosystems takes slightly different amounts of time to process different inputs. It is known that during these timing channels, data is leaked, although a minimal amount. Attackers can exploit timing measurements from vulnerable systems to find the entire secret key. Apparently, it can be used on RSA, Diffie-Hellman, and the elliptic curve algorithms. Brute-force attack: A brute-force attack can be launched when an attacker has lot of computing power. In simple terms a brute-force attack would be, for example: if f(x) = y where y is the ciphertext , f(x) is the plaintext, and x is the key. The strongest algorithm available few years ago was cracked in record time by the Electronic Frontier Foundation (EFF) by using a brute-force method. Differential cryptanalysis: In differential cryptanalysis attacks, an attacker uses an iterative mapping process – the mapping that is based on a repeated process. By basing the results on a large number of ciphertext pairs whose counterpart plaintext pairs satisfy a known component-wise XOR difference, the attacker then can determine the key. IPSec Attacks: IPSec is a paradigm in which other algorithms protect data. By implementing IPSec, it only means that it is a system that is able to do the encryption and authentication algorithms that are specified in the RFC, along with some other particular conditions specified in the IPSec RFC. Therefore, like any other security protocol, IPSec can be attacked and compromised. Following is a description of type of attacks on IPSec. Implementation Attacks - The IPSec standard only calls for one encryption algorithm (DESCBC) and two authentication modes (HMAC-MD5 and HMAC-SHA-1); however it calls for the additional “NULL” algorithms, since AH and ESP may be optional. When a standard calls for an optional algorithm, it is trying to balance flexibility with security. The interpretation is that even if one end of the communication was to use DES-CBC, the other end should still be able to use the NULL, or no, algorithm and still communicate. The receiving end usually specifies the SA, but in order to be compatible with other systems, it must allow the NULL algorithm. Vendors could decide on how to implement this choice, thereby increasing the security exposure. In the IPSec key-management protocol IKE component, both ends of the communications channel decide on how often the encryption keys should be changed. Given that many vendors support weaker, 40 –bit keys for backward compatibility, changing these keys

Page 23


now becomes critical, but still is a negotiated session. If it’s is a weaker implementation, it’s probably using longer time period, which in turn, gives an attacker more time to break the 40-bit key. Considering that 56-bit keys are now broken in three days, 40-bit keys shouldn’t have even been part of the standard. But again, when the IPSec standards were implemented, it was not expected that 56 bit encryption can ever be broken. Key-Management Attacks – This type of attack is similar to TCP session hijacking. The protocol (IKE) specification specifies how these keys should be exchanged, but it usually refers to the start of the communication, not the end of it. There is a “time-out” mechanism in the public-key exchanges, and it was discovered that there isn’t true interoperability between the vendors. In addition under the IKE specification, any side could terminate a session, but there is no way for the other end to know that the session has been terminated; the sending end would keep sending data. If the station is sending data, what’s to stop another station from receiving that data and, if the weak keys are used, spoofing the identity of the original host ? Key-Recovery/Export Law Attacks - There is really no such thing as a key recovery/export law attack, but if an IPSec implementation is available in an international standard, it has one of two serious weaknesses. Either it will be IPSec using 40-bit keys (although, 56-bit IPSec was being released) or it will support key recovery. Administrator and Wildcard Attacks - In IPSec there is a provision for an administrative and provision for wildcard matching. While there hasn’t been a direct attack (at least none reported), some have argued that by even having an administrative interface to the SA (security association), you can potentially increase the chance that the interface can be attacked and the SA compromised. Since there is no provision for such as interface, it is left up to the vendor’s implementation. Point-to-point Tunneling Protocol (PPTP) Attacks The PPTP protocol attack is an attack against the implementation.

•Attacking the GRE. •Attacking the Passwords.

Attacking the GRE - PPP packets are encapsulated inside the GRE and tunneled via IP to their destination. GRE uses protocol number 47. GRE packets may carry a sequence number and an acknowledgement number and may use a sliding window to avoid congestion. This has some practical implications. It means that if we want to try and spoof the PPP packets encapsulated in GRE, we just need to desynchronize the GRE channel. This may be avoided by use of the sequence number; unfortunately, originally GRE didn’t mandate the use of this sequence number, and it is therefore up to a vendor’s particular implementation. The GRE didn’t have a way for the end host to react to a bad or duplicate sequence number. It’s possible that it can be just ignored, and then the PPP packets can be spoofed. Attacking the Passwords - The PPTP authentication implementation supports three types of user authentication. The two that are concerned with security are the hashed method

Page 24


and the challenge response method. Hashed password authentication is based upon two one-way hashing functions. During the first hashing function, all passwords entered are converted to uppercase, which reduces the data space. Second, the hashing functions produce the same hash output, given the same password. Unfortunately there is no salt, so the hash outputs from the same input. Therefore in this authentication model, PPTP is open to dictionary attacks. In addition, both hash outputs are sent together in the communication string. An attacker can attack the first hash function to compromise the second hash function, thereby finding the password. The second security authentication method uses the challenge Handshake Authentication Protocol (CHAP). CHAP works by the client contacting the server and the server sending back a challenge. The client then performs a hash function, adds some extra information, and sends this back to the server. The server looks in its own database and computes the hash with the challenge. If they are the same authentication succeeds. While this eliminates the dictionary attack, the hashing functions could still be attacked. The PPTP framework calls for Microsoft’s Point-to-Point Encryption (MPPE).The encryption is based on the user’s password. After the initial communication is set up, only certain PPP packets are encrypted. RFC-1700 lists those packets that are sent in the clear and those that are encrypted. MPPE then does not encrypt all the packets. This means you can attack the PPP protocol itself – for instance, spoofing the configuration packet containing certain DNS server information. MPPE uses RC4 cipher in either 40- or 128-bit key size. One of the main security problems lies in the fact that since there are no lowercase characters, a good selection of passwords from which to choose is eliminated. Therefore, claiming that PPTP is either 40-bit or 128-bit secure is incorrect. The session key is derived from the user’s password. The password will have a much lower entropy. The only way one to reach true 40-bit or 128-bit entropy is by generating a random session key [8]. The following chart illustrates key vulnerabilities each of these protocols are susceptible to: IPSec PPTP L2TP

Implementation Attacks

Key Management Attacks

Key recovery/ Export Law Attacks

Administrator and Wild Card Attacks

Weak client authentication

Poor certificate authority

GRE attacks

Password attacks

DOS attack

Man-in-the-middle attack

Dictionary attack

PPP attack

GRE attacks Password attacks DOS attack Man-in-the-

middle attack Dictionary attack PPP attack Spoofing attack

Page 25


management Spoofing attack

6. Deployment Consideration This section can be best discussed with a brief overlook of the deployment benefits and drawbacks of CPE based VPN Primary benefits of CPE-based VPNs.

• The enterprise user retains physical possession of the devices that contain the most sensitive security information, such as user passwords, encryption keys, etc.

• Security is “end-to-end,” from the user’s location to the end destination: The data are secured prior to exiting the customer’s premises, limiting security exposures on the link(s) between the access provider(s) and the VPN provider.

• The customer premise is the natural (and only) location at which to apply bandwidth management functions to LAN-based application traffic. Once data leave the enterprise LAN and enter the WAN access link, it is too late to apply policy in order to prioritize one type of traffic over another.

• CPE-based VPN services can be implemented in conjunction with many different IP service providers, and are not tied to proprietary features that may be implemented only by one or a few providers.

The primary drawback of CPE-based VPNs is as follows:

• CPE-based VPNs may require the expense of one or more VPN service devices, each of which must be adequately housed and maintained.

In a nutshell, CPE-based VPN solutions have the most benefits for the user, e.g., they offer the greatest security, the most flexibility, and the most complete feature set, at the expense of additional equipment for the user and additional integration and service headaches [9]. 7. Interoperability

VPN interoperability is the ability to pass data through a secure VPN connection between two dissimilar vendors’ gateways.

L2F: Not implemented PPTP: Limited implementation L2TP: Interoperable with IPSec MPLS: Interoperable with IPSec IPSec: Interoperable with L2TP and MPLS

Page 26


8. Performance Performance is measured in terms of throughput and latency. Latency is essentially the communication delay, an expression of how much time it takes for a packet of data to get from one designated point to another. Encryption in a packet-based protocol further increases the latency, as the packets need to be reassembled in the correct order before decryption can occur. Encapsulation requires adding information to each packet, which increases the packet size. This in turn increases the likelihood that internet routers will find the packets oversized and fragment them, further degrading performance. Packet fragmentation and data encryption can reduce dial-in system performance to unacceptable levels. Data compression can help solve this problem. However, the combination of compression and encapsulation requires additional computational power beyond that needed for security. The cryptographic algorithm used also adds overhead. Cryptographic algorithm overhead is created by padding that must be added to packets for encryption and authentication algorithms before processing. PPTP uses UDP to carry the data packets and TCP to carry the command control packets. L2TP does not distinguish between packet types. All L2TP packets are UDP encapsulated. As a connection-oriented protocol TCP requires an acknowledgment packet to come back for each chunk of data it sends out. A packet’s TCP header is 12 bytes larger than a UDP Header. This results in degradation of throughput of PPTP as compared with L2TP that uses connectionless UDP. PPTP may also have performance issues over high-latency networks. There are a couple of reasons for this. Here again, the first is the use of TCP for PPTP control packets. TCP is a session-oriented protocol, meaning a session exists between the PPTP client and the PPTP server during the lifecycle of the tunnel. TCP implements flow control based on configurable send and receive window sizes. The window size is the number of input or output buffers available for sending data. Usually, larger window sizes lead to higher performance on faster networks. The problem is that performance over the Internet can fluctuate widely so it is difficult to predict an optimal window size. We can summarize the performance features as follows:

L2TP utilizes more command and control messages than PPTP, because of the connection-less aspect of L2TP, but will also perform better over high latency networks.

IPSec Performance degredation due to AH and ESP security features PPTP may have performance issues over high-latency networks due to use of TCP

for control packets. 9. MultiProtocol Support Some of the VPN tunnel modes support all different types of desktop protocol, when some others were developed on just one protocol in mind which is usually IP. Below is a table that briefly shows the different protocol support of different VPN tunnel modes.

Page 27


IPSec

L2TP (LTF + PPTP)

IP IP, IPX, NetBEUI, AppleTalk

B. Provider Provisioned VPN Protocol Comparison In the following headline, we will discuss the similarities and differences of MPLS layer 3 VPN and MPLS layer 2 VPN: 1. Security Issues Both type of MPLS VPN architecture offers customer security in a manner similar to a trusted Frame Relay or ATM network environment. None of them gives any option for encryption or key management. VPN membership is determined by service providers – a provisioning function based on logical port and unique route descriptors. Unauthorized access to a VPN group is denied by device configuration. 2. Deployment Considerations: Deployment of a layer-3 solution usually requires high end Label Switch Routers (LSR) capable of handling multiple routing and forwarding tables at the provider edge. It also requires that BGP peering be set up between these routers. If the service provider is already using BGP so extensively throughout there network, as in the case of ISPs or large IP carriers, then they might prefer going with a layer-3 solution since it allows them to take advantage of the already available BGP sessions, and the already available BGP know how. A layer-2 solution, typically, would require simpler PE routers, and without the requirement of having BGP peering sessions set up between the PEs. For service providers who don't rely on BGP or are unwilling to deploy BGP for the new VPN service to avoid the complexity, the layer-2 solution might be more attractive. Use of BGP for VPN signaling between the PEs remains as an option1 to the provider, in case they already have BGP deployed and would like to take advantage of it. As in the layer-3 case, LSPs between the PEs have to be set up for carrying traffic from one PE to the other.

Page 28


When managing a layer-3 solution, doing configuration changes, or troubleshooting problems, the service provider engineers would mainly be dealing with BGP peering sessions, BGP routes with different extended communities, their propagation, and selection by the PE, peering with customer CE routers, etc. As in many large scale IP networks, route reflection clusters or a confederation with multiple member-ASes might be in use which could contribute to the complexity of the task at hand. Also, dealing with a large number of routes belonging to multiple routing and forwarding table in addition to the global table is certainly more demanding than dealing with a single table. Finally, configuration files on the PE routers could grow so large which makes it harder to spot a misconfigured statement. A layer-2 solution is simpler since the provider does not retain any customer routes, control their distribution, or peer with any customer CE routers. Also, since BGP is not required, management and troubleshooting become even simpler - unless the provider is using BGP for VPN signaling as in some variants of the VPLS approach described above. When performing management or troubleshooting, the service provider engineers deal with the simpler concepts of the VCs making the VPN, and the ports assigned to the VPN. On a given PE, the engineers deal with only one routing table while the VFI tables get dynamically populated via source MAC address learning. As in the layer-3 case, when the configuration file grows so large it becomes more challenging to recognize misconfigurations. As mentioned before, the use of auto-discovery will help keep the size of the configuration file to an absolute minimum [9]. Comparing deployment costs, it is more likely that a layer-3 solution would cost slightly more than a layer-2 solution, due to the fact that the layer-3 approach relies on more sophisticated routers capable of handling multiple VRFs. Management and maintenance costs of a given solution are directly related to the complexity that solution. A layer-3 solution is more likely to cost more due to its higher complexity. The complexity of the solution demands a certain level of technical know-how, and might translate into more man hours required to accomplish any task related to the solution. 3. Interoperability Several connectivity scenarios for customer sites could be implemented using both approaches. Both approaches could be used to implement the following connectivity scenarios: • Point-to-Point. • Hub and Spoke. • Partial Mesh. • Full Mesh.

Page 29


The layer-3 approach performs well at implementing scenarios 1and 4 in a manner that is transparent to the CE devices. However, the layer-3 approach could get a bit more complicated when implementing scenarios 2 and 3. The layer-2 approach performs well at implementing scenarios 1, 2, 3, and 4. It is worth noting that when implementing scenarios 2 and 3, it is more straight forward to build the topology using VCs as in the layer-2 approach, than to build the topology by controlling BGP routes as in the layer-3 approach. A well-executed, comprehensive VPN service offering may leverage both IPsec and MPLS. Service providers may choose IPsec for traffic that needs strong authentication and confidentiality and choose MPLS for its broader connectivity, traffic engineering, and QoS compared with traditional Layer 2 private data networking. With both architectures this combination enables service providers to offer differentiated New World services that cover the spectrum of customer requirements for security, QoS, and traffic prioritization.

FIG. 11 IPSEC AND MPLS INTEGRATED VPN ARCHITECTURE. When considering the scalability of a layer-3 solution vs. a layer-2 solution, one could find some similarities. A limiting factor for both solutions would be the maximum number of LSPs and/or VCs that could be supported by a given LSR. Another limiting factor that is common to both is the maximum configuration file size that could be stored, specifically, on a PE router. This is due to the fact that the configuration file contains all the information related to the customers' VPNs. For a layer-3 solution, the configuration file contains definitions for the VRFs, RDs, extended communities, and route filtering policies. For a layer-2 solution, the configuration file contains definitions for the VPN peer PEs, and the ports associated with the customer VPNs. The use of auto-discovery in conjunction with a layer-2 solution obviates the

Page 30


explicit configuration of the VPN peer PEs, and hence, decreases the impact of the maximum configuration file size on the scalability of the solution. For a layer-3 solution, the maximum number of routes that could be stored on a given PE is also a constraint. This is due to the fact that a PE router stores routes from all the VPNs that it carries. To alleviate the impact of this factor on the scalability of the solution, route summarization could be used whenever possible. For a layer-2 solution, the maximum number of layer-2 forwarding table entries supported on a PE routes is also a constraint. The PE router has to create those entries in order to be able to perform its layer-2 switching functionality. The impact of this factor on scalability could be alleviated by requiring that CE devices be routers, and/or applying limits to the number of (MAC) entries created for each VPN - to avoid having a customer VPN overwhelm the PE routers with a large number of source MAC addresses. 4. Performance From the performance prospective both type of MPLS works almost similarly. Even then, layer 2 solution is faster then layer 3 MPLS VPNS because of less encapsulation and less route look-ups and overall less complexity. But also layer 3 only handles IP traffic but layer 2 forwards any type of traffic without any layer 3 information. So there is less encapsulation related header and trailer, which translates to more throughput. 5. Muti-protocol support Comparing both approaches described above, it is clear that the layer-3 approach offers transport of IP traffic only. On the other hand, the layer-2 approach allows transporting any customer layer-3 protocol packets: IPv4, IPv6, IPX, DECNet, etc. Many enterprise customers still use other protocols than IP in their IT infrastructure, hence, a layer-2 service is less restricting for them. Also, with IPv6 on the horizon, some organizations are already experimenting with IPv6, and in the near future, many will be migrating to it. To continue providing connectivity for those organizations using a layer-3 solution would require some enhancement to the current standard - like creating a VPN-IPv6 address family - and might require some upgrades to the provider's routers. A layer-2 solution could continue to serve those organizations, even when the provider network has not yet been upgraded to use IPv6 internally.

VI. OSI MODEL AND VPN PROTOCOLS Some of the VPN protocols fit into the OSI model. But there is some protocols may not neatly fit in the one layer or the others. Also, as we move down through the stack, implementation of these protocols are becomes easier, while securing them becomes more of a challenge.

Page 31


7. Application

c

SSL 6. Presentation SOCKS v.5 5. Session

Sun.Net, TCP 4. Transport IPSec 3. Network
IPSe L2TP, PPTP,L2F 2. Data link
KG, KIV 1.Physical

VII. FUTURE OF VPN

VPN services are a prime example of value-added services on top of basic network connectivity. However, VPNs today are not transparent; the technology components are not seamlessly integrated, and performance often suffers. Until the four VPN technologies - tunneling, authentication, access-control, data integrity and confidentiality - are themselves integrated into the Internet infrastructure rather than assembled as ad-on components with compatibility and interoperability issues, VPNs will be neither ubiquitous nor transparent. Many factors will affect current and future developments of VPN: the continued evolution of the underlying network infrastructure, and advances in the VPN enabling technologies and the ways they are assembled and managed. Below we discuss some of the emerging trends in VPN technologies.

A. Voice and Video over VPN Just as Enterprise implementers expect to run Voice, Video and integrated data applications over a private WAN, such as Frame Relay or ATM, they also expect to run Voice and Video across their VPN implementation with the same quality and level of service. Further, the Enterprise implementer should be able to do so and have the VPN be fairly transparent to these applications. To provide these capabilities, Cisco designed the Voice and Video Enabled IPSec VPN (V3PN), which integrates three core technologies: IP Telephony, Quality of Service (QoS), and IP Security (IPSec) VPN. The result is an end-to-end VPN service that can guarantee the timely delivery of latency-sensitive applications such as Voice and Video. This trend saves a significant amount of cost for the corporations.

Page 32


B. Cellular Telephony and VPNs Data communication over Cellular telephone network is a big wave now a days. This facility gives access to internet based VPNs. User can use their wireless devices to access any information over the public network. There is a new standard called GPRS, General Packet Radio Services which deploys a packet model between the mobile station and the cellular network. This GPRS system uses tunneling protocols to shunt data between the number of serving GPRS support nodes providing wireless data services to a group of cells and a Gateway GPRS support node (GGSN) providing access to the Internet or other data networks. Eventually , the GGSN may provide tunneling services directly into VPN servers on enterprise intranets.

C. SSL VPN SSL VPNs are an increasingly popular technology for providing remote users with access to network resources such as e-mail, software applications and network file servers. The SSL standard is not a single protocol, but rather a set of accepted data transfer routines that are designed to protect the integrity of transmitted messages. SSL relies on certificates - digital identification cards - and keys. Certificates include the name of the certificate authority that issued the certificate, the name of the entity to which the certificate was issued, the entity's public key, and time stamps that indicate the certificate's expiration date. Two types of keys are used as ciphers to encrypt and decrypt data. Private keys are issued to entities and are never given out. Public keys are given out freely. Both keys are necessary for authentication routines. Data encrypted with the public key cannot be decrypted with the same key: The private key must be used. As opposed to VPNs that use IPSec, SSL VPNs are typically "clientless," meaning they do not require a separate software application to be installed on the remote user's machine. They also rely on the SSL protocol, which is a part of most common Web servers and Web browsers and widely used to secure e-commerce transactions. Companies using SSL VPN pass connections through port 443, which most firewalls automatically allow traffic to. In contrast, IPSec requires multiple ports to be opened on firewalls to handle different elements of the IPsec VPN exchange such as message authentication headers and IKE (Internet Key Exchange) traffic. Because they use clients, IPSec VPNs can be more difficult to manage for large numbers of users. Also, business travelers who rely on IPSec VPNs often find that Internet providers such as hotels have not modified their firewalls to allow IPSec connections, denying them VPN access to their company network from the road, Kosiur said.

Page 33


FIG. 12 HOW SSL WORKS

IPSec vendors have made progress in resolving such integration problems, but left a window open that SSL VPN vendors have used to grab market share.

VIII. CONCLUSION As the Internet continues to evolve from novelty to utility, VPN technologies will continue to evolve, enabling more comprehensive, integrated, and transparent VPN solutions. Improvement in its infrastructure, especially in its ability to provide quality of service and security guarantees, will make the distinctions between Virtual private networks and physically separated private networks increasingly less significant. For all practical purposes, a virtual private network will offer the same quality and security as a private network but with more flexibility.

Page 34


IX. References [1] Gartner Consulting Market Study, “An Introduction to IP VNP’s”, 25 February 2003, http://www3.gartner.com/Init [2] Infonetics Market Research, http://www.infonetics.com, 2002, http://www.infonetics.com/service/2002Services/2002vpn.htm[3] Dennis Fowler, “Virtual private networks : making the right connection”, Morgan Kaufmann Publishers, c1999. [4] David McDysan, “VPN applications guide : real solutions for enterprise networks”, John Wiley, 2000. [5] Carlton R. Davis, “IPSec : securing VPNs” , Osborne/McGraw-Hill, c2001. [6] RFC 2547bis : BGP/MPLS VPN Fundamentals : From Juniper Networks Archive [7] Chuck Semeria, “Multiprotocol Label Switching : Enhancing routing in the New Public Network.” [8] Steven brown, “Implementing Virtual Private Network”.Page 422 – 435. [9] “Managed VPN services: A guide for enterprises and service providers with Market forecasts provided by Infonetics Research” [10] Virtual Private Network Consortium, http://www.vpnc.org.

Page 35

http://www.infonetics.com/

http://www.infonetics.com/service/2002Services/2002vpn.htm

http://www.vpnc.org/

Documents

ECE 646 Final Project · ECE 646 Final Project Analysis of VPN Protocols Touhid Satiar, Tamer Mabrouk Department of Electrical and Computer Engineering George Mason University