10.2 VPN Solutions


10.2 VPN Solutions

A VPN will only encrypt data. To make a VPN part of a comprehensive security plan, a number of other factors must be considered. In this section we examine the different types of VPNs available and also examine the parts required to make a VPN fully functional and an effective countermeasure against threats.

Thus far, the discussion has concentrated on the common perception of the VPN: encrypted traffic over an IP backbone. This is not the only alternative, however. If a private connection between sites is required, then there are other choices to select as countermeasures. A brief discussion of each follows, along with the specific pros and cons of each solution.

10.2.1 Private Lines

Originally, when a company wanted to connect two remote locations together in a private fashion, it had two choices. The first was to install and maintain a private long-haul network. This was an option for only the largest companies or governments and was only used when connectivity and privacy were paramount. If privacy were the ultimate goal, then encryption was still required because it would be very difficult for any entity to protect every mile of a WAN that spanned the country.

More commonly, circuits were leased from phone companies. This was a virtual network only in that the facilities that connected two remote locations together were not actually a very long wire but a collection of circuits that were circuit switched in the central offices of the phone companies. The network at that time was private in the same way a phone call was private. From the point of view of two parties speaking on the phone, they have access to the entire bandwidth of the link, whether or not they are speaking.

As far as VPNs go, this is the "Cadillac" of service. Because the data is not multiplexed with data from other sites or networks, it truly is private — just as a voice conversation is. The bandwidth between the two locations is fixed and does not suffer from congestion or delay because the bandwidth is reserved for the party that is leasing the circuits. Encryption is not needed to protect data from the rest of the Internet because there is no "rest of" with which to mix up the data. From the point of view of the two remote locations, the circuit between two sites is simply an extension of the LAN.

This is also the most expensive of solutions. Due to the high costs of leasing private lines between sites, when less expensive options became available, the newer options were quickly seized upon by the networking community. Private-line networks also become very expensive, very quickly when they scale. Both full and partial mesh networks require a great many private lines to provide any-to-any or any-to-many connectivity.

10.2.2 Packet-Switched Services

The primary reason that leased lines are so expensive is because they require the service provider to dedicate resources to a particular connection. Because service providers make their money when data is traveling over their links, a leased line essentially takes facilities out of the general pool of available income generating resources.

Packet-switched networks were developed to allow multiple parties to share the same resources by multiplexing multiple datastreams, in the form of packets, across the service provider backbone. Because service providers could now, in effect, sell the same link over and over again, they were able to reduce the costs they charged customers.

The concept of multiplexing data is not new. Phone companies have been doing it for years over their digital backbone using time division multiplexing (TDM). This means that a circuit is broken up into a number of time slots, each of which is capable of holding 8K of data. This timeslot becomes available 8000 times a second, producing a total bandwidth of 64 Kbps. Incidentally, a single voice call uses 64 Kbps of bandwidth. Odd coincidence, no? [1] There are other types of multiplexing as well. Analog communications systems such as FM radio use frequency division multiplexing (FDM). In the case of FDM each channel is assigned a frequency space in the radio spectrum. Our radio receiver is able to de-multiplex and tune into only the signal in which we are interested.

The multiplexing techniques in the above paragraph are both examples of multiplexing at the physical layer. Packet switching takes the concept of multiplexing to the data-link layer. Examples of packet-switched networks are X.25, Frame Relay, and ATM.

While the frame formats and implementations of each are different, these data-link technologies all share some common characteristics. The first is that X.25, Frame Relay, and ATM are all interface definitions. This means that what they really define are the "hand-offs" between devices. A company will typically lease a circuit from a telco only to their local site. That circuit is generally the same type they would use for a private line, meaning that the physical layer of the circuit uses T-1 encoding of data and has 24 TDM slots that can be concatenated to appear to be a single link to higher layers of the OSI Model. The customer edge device will be configured to use a certain type of frame format; lets say Frame Relay for this example, to send data to the service provider access device.

Once the data has reached the service provider, the private line stops and the frame that the customer has sent enters the service provider backbone. That backbone multiplexes the customer data along with the data from other customers along a series of high-bandwidth trunks. Based on an address attached to each frame, the packet is forwarded throughout the service provider network until it reaches the point at which it is sent to the customer remote location. This remote location is provisioned with a private line that uses the Frame Relay frame format just as the sending site does. The frame is forwarded from the service provider access point to the customer edge device.

Thus far, this sounds a lot like what would happen to an IP packet — and it is. There are a few significant differences, however. The first is that this is a layer 2 technology. Only like networks can communicate. If you wanted to communicate with a remote location and you used Frame Relay, the remote location would also have to use Frame Relay. If you wanted to use ATM to communicate with the remote location, then you would have to make sure the remote location had access to an ATM network to pass data to. IP, on the other hand, being a layer 3 technology, does not care what the layer 2 protocols are. As long as the other side is speaking IP, dissimilar networks at layer 2 can communicate using layer 3.

How is this private? From the customer edge router to the service provider access router, the service is private. Inside the service provider network, layer 2 frames are switched through the network following a predefined path. In Frame Relay, frames are switched according to the Data Link Connector Identifier (DLCI) and in ATM cells (a particular type of frame) are switched according to their Virtual Path Indicator (VPI)/Virtual Channel Indicator (VCI). These identifiers are simply addresses, like IP addresses, that are used to identify Frame Relay and ATM point-to-point connections through a network backbone. Unlike IP addresses, where the numbering scheme is global, in Frame Relay and ATM, the addresses are only relevant between any two network nodes, much like the MAC address is only relevant to a particular LAN segment. From the point of view of the customer devices that send data into and receive data from the network, the connection is a private layer 2 connection. This is no different, other than the encapsulation method used, than a private line from the customer's point of view. Privacy is assured in the service provider backbone because the labels that are attached to user data keep frames from user A from becoming confused with frames from user B — although they both share the same physical facilities.

Frame Relay became very popular by companies looking to connect remote sites together in a "private" fashion. It offers the same service as an actual private line but because the service provider is able to sell the same backbone bandwidth multiple times to customers, it is offered at a cheaper price than the private line solution.

What does Frame Relay provide as far as VPN services go? It is a virtual network for sure. Sites employing Frame Relay connections essentially have a private backbone that they are leasing from a service provider. Privacy is gained through the addressing and switching mechanisms employed by the service provider.

That said, Frame Relay does not do a lot of other things we expect our VPNs to do for us. First, the only way you can create a Frame Relay network is if you have access to a service provider that provides Frame Relay access. This seems obvious, but it means that dial-in users cannot (easily) enjoy Frame Relay access and your average SOHO (small office/home office) user with a DSL or cable modem cannot create a VPN using Frame Relay. Frame Relay only works on Frame Relay networks. The same restrictions apply to X.25, a predecessor to Frame Relay and ATM, a one-time Frame Relay replacement technology.

Layer 2 VPNs, like Frame Relay and ATM, also do not encrypt data. A company's data is only protected by the integrity and security policies of the service provider from which it leases services. Because the virtual circuits, called permanent virtual circuits (PVCs), [2] that Frame Relay and ATM create are manually created by employees of the service provider, they are at a risk of "fat-fingering" the switching tables. That said, I have worked with many service providers and, while I have witnessed mistakes being made, I have never seen nor heard of customers actually receiving each other's data because of a switch configuration. Inside the service provider backbone, if someone were able to install a packet sniffer on a port, all data from all Frame Relay circuits would be readable in plaintext.

While these layer 2 VPNs do not encrypt data, the network can still be considered a VPN and, in some cases, depending on the security policy of the company interested in the service, this may be adequate. Remember that unnoticed sniffers and circuit misconfigurations are few and far between in your average national service provider. Because Frame Relay does not need to encrypt data to ensure privacy on the network, key distribution and encryption/decryption issues are not factors as well. Furthermore, this is a technology that only the service provider can configure. Other than a nominal configuration on the customer edge router, all of the provisioning of this service is done in the service provider backbone. This could be an advantage if a company has realized that, to effectively use IPSec encryption, an expensive hardware upgrade would be required and additional resources committed to the administration of the IPSec configurations.

Pulling all this together, when should you consider a Frame Relay or ATM VPN as the solution to your needs?

  • Your security policy does not mandate the encryption of data.

  • Your VPN connections will be gateway-to-gateway in nature.

  • You lack the resources to configure and maintain your own IPSec infrastructure.

  • You have concerns with throughput or latency due to the encryption or decryption of IPSec data.

  • You do not wish to upgrade your hardware at all sites if they do not currently support the IPSec options you require.

A layer 2 VPN is not the solution you are looking for if:

  • Your security policy requires encryption; however, IPSec encryption can be run concurrently with Frame Relay or ATM.

  • You have many sites that you need to include in your VPN; however, IPSec also has serious scaling issues that make mesh configurations complicated.

  • You have users who will need to work remotely and thus need host-to-gateway connectivity.

10.2.3 Multi-Protocol Label Switching (MPLS)

Multi-protocol label switching (MPLS) is a technology that has been around since the mid-1990s. At the time of its development, MPLS had several goals, none of which were related to VPNs. The original goals of MPLS were to:

  • Improve the speed of routing in comparison to switching. Routers were hampered by the need to perform software forwarding on IP packets. Compared to the operations on a layer 2 header, IP packets at layer 3 required much more overhead and processing.

  • Improve the performance of Internet routing tables. Routing tables on the Internet were growing rapidly. If router performance and memory could not keep up with the growth of the routing tables, then parts of the Internet would begin to disappear from each other. Combine this with instabilities in the routing table and the constant process of convergence, or updating the routing tables, and there was a definite need to redefine how packets were forwarded to avoid the size and complexity of Internet routing tables.

  • Improve the control of network traffic. The IP network lacked the management abilities of ATM networks that were competing with IP in the mid-1990s. Although there is the concept of QoS (quality of service) that can be applied to IP traffic, it is not nearly as flexible as that found in ATM. Most IP traffic simply takes the shortest path between two points according to the routers. What was needed was a way to easily control IP so that less than optimal paths could be engineered as well to make better use of network resources.

Today, the original need for MPLS (i.e., faster packet forwarding) has been taken care of through increases in router technology. By performing much of the forwarding process in the hardware interface caches, routers can compete favorably with switches and offer more control as well. The work in solving the other problems of the Internet, however, created the MPLS technology and it was a short time later that engineers realized that MPLS could be used to provide a robust, secure, and scalable VPN technology.

10.2.3.1 MPLS Overview.

MPLS is called a layer 2.5 technology. That means that the header information, called a label, is applied between the layer 2 frame header and the layer 3 packet header. This label is used by MPLS-enabled routers to forward frames much like the DLCI or VPI/VCI headers are used at layer 2 to forward frames. To summarize what MPLS does for a network; it provides the same services as Frame Relay and ATM networks over any type of network. While that may not have caused you to gasp in astonishment, when the implications of this are considered, they are quite profound.

First and most related to VPNs is that a network using MPLS can create the same type of service as an ATM network. [3] This means that virtual circuits can be created; and traffic engineering, the process of moving traffic around the network contrary to what the normal routing process would choose, is easily enabled. This ability, however, does not require an ATM network to work. Indeed, the entire point of MPLS is that it can create virtual circuits over any type of infrastructure that can support IP traffic. It would be possible to create an MPLS virtual circuit, called a label-switched path, between a dial-up user and a corporate site using OC-48 SONET access-links. [4] This type of flexibility is impossible on a traditional Frame Relay or ATM network.

MPLS also offers many benefits to service providers. Instead of many different protocols to control the operation of their networks, service providers can finally converge on a single technology. MPLS allows service providers with IP backbones over fiber optics and ATM backbones to be controlled using a single protocol. This offers considerable cost savings in the service provider arena. MPLS also has the ability to tunnel other layer 2 protocols inside it. Just as an example, imagine that you are a new service provider and wish to compete against the established, large service providers. To compete with all of their offerings, you would have to spend extensive amounts of money to create a voice network, a Frame Relay backbone, perhaps an ATM network to carry the voice traffic, and an IP backbone. With MPLS, you could create a single backbone of perhaps Gigabit Ethernet links and over that single network provide potential customers with voice, IP, Frame Relay, point-to-point links, and ATM, and provision the Ethernet in a way that makes each company think that instead of a WAN link, it simply has a long-haul Ethernet connection to a remote site. All these services over one network makes a service provider very competitive and cost effective.

In addition to cost savings, MPLS offers service providers the ability to offer new services to customers in a way that is scalable and cost effective for them. One service is the ability to provision different classes of customer traffic. It is possible for a service provider to sell your company "premium" links for one type of traffic and "best-effort" links for another type of traffic. This, of course, can be done without MPLS, but the cost difference in the provisioning for the service providers is considerable.

The other service that MPLS provides is the ability for the service provider to easily create large, scalable VPNs for the customer. An MPLS label-switched patch (LSP) creates a virtual circuit, which from the customer point of view looks very much like a Frame Relay PVC. Inside the network, however, routers are creating the path the LSP uses for the forwarding of traffic. Instead of manually provisioning of MPLS in the network core, as is typically done with ATM and Frame Relay, MPLS uses the existing IP routing tables to create the LSP. Again, with MPLS, a simple observation turns out to have profound implications in the operation of the network.

Frame Relay became a popular replacement for private lines because it was cheaper and provided nearly equivalent service. IPSec, to be discussed shortly, became a popular replacement for Frame Relay because the costs for IP-only links were even cheaper than those of Frame Relay. The disadvantage of IPSec was the setup and maintenance of the VPNs for the customer. MPLS seeks to leverage the low cost of IP connectivity and at the same time remove the complications of configuring VPNs for customers. Let us examine how that is done.

Compare the example four-site networks in Exhibit 3. The first is a network using Frame Relay to create a full mesh of connectivity. That is, each remote site is directly connected to each other site. The second network is provisioned using a service provider core that is MPLS-enabled. From a VPN point of view, both networks provide equivalent privacy. The Frame Relay network requires the provisioning of three PVCs at each site. Any routing protocols used between the remote sites are going to have to scale for the three possible paths and peers. Adding a fifth new site to the Frame Relay configuration will require the addition of four new PVCs and the reconfiguring of all of the customer edge routers to accommodate the new site. Note as well that the Internet connection for the headquarters is a separate link that also needs to be provisioned and paid for. If any of the remote sites wish to access Internet resources, each of them needs to forward its traffic to the headquarters and, in turn, headquarters will forward the traffic out to the Internet.

Exhibit 3: Frame Relay VPN versus MPLS VPN

start example

click to expand

end example

Compare this to the MPLS VPN solution. First, MPLS does not need a specific data link-layer like Frame Relay. That means that only a normal IP connection is required. Furthermore, because MPLS only runs in the service provider backbone, the customer edge routers need no special configuration whatsoever for the VPN service to be established. LSPs are created from the service provider edge router to remote service provider edge routers using the backbone routing protocols.

When a packet is sent from one customer site to another, the packet is assigned a label based on its destination as it enters the service provider edge router. For the remainder of the packet's journey through the service provider network, only the label is examined and forwarding decisions are made based on that label. When the packet reaches the remote service provider edge router, the label is removed and a normal IP packet is forwarded to the remote customer edge router.

Because it is the service provider edge router that is doing all the work, the customer needs no configuration on its site to create the VPN. And because the packets are routed using normal IP destinations, the customer site only needs a single access-link to directly connect to all other remote sites. For the Frame Relay solution, recall that a separate PVC is required for each remote VPN site.

Adding a new site to the MPLS-enabled network is also a simple matter. When the fifth site is added, no special configuration needs to be done on all of the customer edge routers or the service provider edge routers. The new site is simply added to the routing tables used by the customer VPN and the information is automatically forwarded to the other provider edge routers hosting the customer VPN. This makes scaling the VPN very straightforward for both the customer and the service provider.

Finally, MPLS will allow each site to access the Internet directly through its own access-link. This means that each site has complete VPN access and direct access to the Internet over the same link.

It is natural to wonder — because MPLS is providing service over an IP backbone and we have been taught to equate IP with "insecure" — how MPLS can provide a VPN service simply through the use of another header on an IP packet.

The primary method is that for every site on an MPLS VPN, a private section of the routing table is created, called a VPN routing and forwarding table (VRF). Of all security mechanisms, routers are perhaps one of the most overlooked, yet most important elements of security. The routing table in a router directs packets. If there is no entry in the routing table for Host A to contact Host B, then those two hosts will never communicate. The VRF creates a subset of the global routing table for each customer site that participates in a VPN. By controlling the routing table, the flow of traffic can be precisely controlled. This type of routing table control can be done without MPLS and the VRF, but it is so complicated and subject to change that it is a solution that would never scale.

Inside the service provider network, customer VPN traffic is kept distinct from other customer's VPN traffic and normal IP traffic through the use of the MPLS label. This works much like the ATM or Frame Relay layer 2 headers. For MPLS-enabled routers, the contents of the MPLS packet are irrelevant and not examined during the forwarding process. Only the label, which associates a given unit of data with a label-switched path, is examined. Like Frame Relay or ATM headers, the MPLS label space is relevant only between any two routers. This means that someone could not "inject" false labels into the network from a remote location. They would have to be physically between two routers to insert labeled packets that would be accepted by the switches. This is not a simple proposition. To prevent the improper assignment of MPLS labels, MPLS signaling protocols can also authenticate each other using hashed passwords. This ensures that someone who has gained access to the MPLS network cannot reroute LSPs by changing forwarding tables.

MPLS, Frame Relay, and ATM all provide equivalent VPN services. The advantage that MPLS holds over the other two technologies is that it scales better for the customer, is generally cheaper, and is easier for the service provider to provision. So when should your company consider using an MPLS VPN?

  • Encryption is not a required element of your security policy. MPLS does not encrypt data.

  • You have a service provider that supports MPLS in its backbone. Not all service providers offer this service.

  • You have many remote sites that would be difficult to connect using Frame Relay PVCs. MPLS enables one-to-many provisioning, unlike Frame Relay and ATM.

  • You want to avoid the configurations of IPSec. MPLS is entirely enabled on the service provider backbone. No configuration of the customer site is required.

  • You need traffic engineering or the QoS mechanisms that MPLS can provide concurrently with the VPN service.

  • Your VPN connections will be gateway-to-gateway in nature.

  • You have concerns with throughput or latency due to the encryption or decryption of IPSec data.

  • You do not wish to upgrade your hardware at all sites if they do not currently support the IPSec options you require.

MPLS is not a technology to consider if:

  • Your security policy requires encryption; however, IPSec encryption can be run concurrently with MPLS.

  • You have users that will need to work remotely and thus need host-to-gateway connectivity.

In summary, MPLS offers many of the same advantages and disadvantages of Frame Relay, with the exception of scalability and traffic engineering. The fact that it is easier for the service provider to configure should not necessarily be a deciding factor for the end user of the service — unless, of course, those cost savings are passed on to the consumer.

[1]This bandwidth itself is related to the frequency range of the human voice. The evolution of the telephone system is fascinating but beyond the scope of this book.

[2]Frame Relay also supports a switched virtual circuit (SVC) that creates on-demand virtual circuits. This product has never been widely deployed in the United States.

[3]MPLS does currently fall short compared to ATM in the ability to precisely control traffic delay and jitter as an ATM network can. MPLS, however, does offer great improvements in the provisioning of traffic engineering and quality of service in an IP network.

[4]Do not go asking your service provider for this. The example is just to point out the options that are available for provisioning MPLS and do not reflect current MPLS offerings.




Network Perimeter Security. Building Defense In-Depth
Network Perimeter Security: Building Defense In-Depth
ISBN: 0849316286
EAN: 2147483647
Year: 2004
Pages: 119
Authors: Cliff Riggs

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net