Setting the Playing Field

This introductory section enables you to set a level playing field with your colleagues when discussing various technologies and their implications for security. When discussing these issues with many network managers, the most challenging aspect of the meetings is answering questions about how enterprise security policies should change when moving from a Layer 2 WAN to a Layer 3 WAN. These types of questions can be difficult to answer because an "apples-to-apples" comparison is needed, in which everyone uses the same terminology. An example is comparing a WAN service over a Frame Relay network to a WAN service over a private IP network. This is different from comparing it to a WAN service over the public Internet. However, a VPN service over the public Internet requires encryption for most security concerns. It does not mean that encryption would be necessary over a private IP network to achieve the same level of security as a Frame Relay service.

The real interest is typically in making a security assessment of MPLS VPN networks compared to Frame Relay networks (in terms of exposure by the enterprise network). There are many parts to this analysis, so we'll start by comparing IP to Frame Relay. Then, we'll look at the difference that adding MPLS to the IP network makes. Studying these introductory topics will prepare you to compare MPLS VPN to Frame Relay security.

From a security perspective, the good thing about Frame Relay and other Layer 2 WAN technologies is that the WAN has no knowledge of the enterprise's IP addressing, which is the first thing an attacker needs to directly attack an enterprise. This information, however, has decreased in significance because attackers have moved their attention from attacking specific enterprises to attacking the provider network's infrastructure. This is a logical progression from the attacker perspective. If the aim is to cause disruption, attacking the provider infrastructure that affects many enterprises clearly gives a bigger bang for the attack performed.

Having said that, IP infrastructures are far more commonly the focus of intruder attacks than Frame Relay networks, because the number of IP technology students is far greater than the number of students who study Frame Relay infrastructures. If we look at the problem of susceptibility to attack for the provider WAN infrastructure, clearly many more people know how to send a packet to a given IP address than how to send something to a specific Frame Relay switch.

Frame Relay provides a defined path through the network from one endpoint to another, whereas IP networks facilitate any-to-any connectivity at Layer 3. Clearly, these have different design objectives. At first appearance, IP looks to be a protocol that helps attackers reach places and craft attacks. In part, this is true. On the public Internet, open connectivity is the goal, which gives attackers open access to public addresses. Comparing Frame Relay networks to the public Internet is not an apples-to-apples comparison. Comparing private IP networks run by providers with the express purpose of offering VPN service to Frame Relay networks is valid, however. The reason for the difference is that the controls a provider puts into place limit a user's access to only his VPN. For each technology that could be used to support VPN deployment, there are mechanisms for segregating the control (route information) and data plane (destinations accessible) operations of one customer from another. We will look at MPLS VPN mechanisms for performing those two functions later in this section. With direct Internet access, no such restrictions are in place. So clearly, it does not make sense to compare the security of a private Frame Relay to the security of the public Internet.

Similarly, comparing the security of a private Frame Relay network to a private IP network with no VPN mechanisms implemented on it is not an apples-to-apples comparison. However, it is valid to look at how effectively Frame Relay networks segregate user traffic and to compare that to MPLS VPN services.

The question of whether an IP network is public or private is not always straightforward. Service providers are motivated to reduce their operating expenses and put the same equipment to use in as many revenue-generating ways as possible. This often ends up in at least some parts of the provider infrastructure being shared between public and private services. This is not a new phenomenon. Even though Frame Relay services are considered private, in many service provider networks, public Internet traffic was carried over part of that Frame Relay infrastructure, segregated at Layer 2 from the private Frame Relay traffic. This did not cause concern because it's accepted that, if Internet traffic was on a separate data-link connection identifier (DLCI), it would not interfere with private Frame Relay traffic on another DLCI. The logical conclusion, then, is that having a separate header (in this case, the Frame Relay DLCI) is adequate to ensure separation of private and public traffic on the one infrastructure. At this level, the case for considering MPLS as secure as Frame Relay (at least in the data plane operation of forwarding traffic) is strong because, conceptually, there is little difference between a Frame Relay DLCI and an MPLS label; they are both connection identifiers appended to an IP packet. However, as previously stated, because MPLS devices are addressable via IP packets but Frame Relay switches typically are not, some further analysis is required to see whether MPLS devices can be reached from the Internet.

The first stage of this analysis is to look at how a plain MPLS network operates compared to an IP network. This refers to the single-label imposition of MPLS forwarding rather than to the two-label imposition of MPLS VPN. In a plain MPLS environment, MPLS-enabled routers assign a label to each prefix held in their routing table that is not from Border Gateway Protocol (BGP). Should a packet need to be forwarded to any of these non-BGP destinations, the label is appended to the packet and forwarded to the next hop (the reason for not supplying labels for BGP destinations will become apparent soon). As the packet traverses the MPLS-enabled portion of the network, the label value is examined and swapped at each hop, based on the label database.

Figure 7-1 shows this process. The values for labels at each hop are determined by the label distribution protocol. (The "References" section at the end of this chapter lists resources that further explain this operation.)

Figure 7-1. Single-Label MPLS Imposition

This single-label operation shows that within an MPLS core network, the mechanism of forwarding a packet is similar to the mechanism for forwarding in ATM or Frame Relay switches, and this is by design. One of the original drivers behind the development of MPLS was to find a way to leverage the cheap and fast Layer 2 switching paradigm employed by these switches for the benefit of IP traffic. However, by the time MPLS technologies were available in router products, IP forwarding based on ASIC technology (often called hardware-based forwarding, as compared to the original and slower software-based forwarding) had advanced in speed to match these label-switching approaches. For that reason, MPLS did not take off as a technology until the MPLS VPN service was defined. The fact that switching in the core is based on MPLS labels rather than IP addresses has a nice benefit. For an infrastructure that supports public and private traffic, the core routers do not need to run BGP to be able to forward public Internet traffic. Figure 7-2 helps clarify this point.

Figure 7-2. Getting BGP off Core Routers with MPLS

In Figure 7-2, the enterprise PCs want to contact the web hosts on the right. For the web hosts to be contacted, packets need to be sent to them addressed to their publicly routable Internet addresses. In normal IP forwarding, each hop looks up the destination address and makes a routing decision. This requires the provider to run BGP on each of the routers labeled P in Figure 7-2, because no internal routing protocols are designed to hold the number of routes that exist on the Internet.

To recap, P means provider core router and PE means provider edge router. P routers perform label switching, whereas PE routers perform label push and pop operations to add labels to or extract labels from an IP packet.

The provider no longer has to run BGP on the provider (P) routers, because the provider edge (PE) routers append a label based on the value of the BGP next hop, not the destination IP address. This BGP next-hop value is normally the /32 loopback address of the edge router that can reach the route advertised to the network by BGP. Because MPLS labels do not extend outside the provider network in this case, there is no need to define labels for each of the end customer networks. All that's needed is a label for the provider network's exit point. As soon as the packet arrives and the label is stripped, the PE router can perform an IP lookup to decide where to send the packet. So, by this mechanism, BGP is restricted to the edge routers, and clearly there is no need to define labels for BGP destinations in the MPLS-enabled part of the network.

What does all this mean for security? Well, the end result in a scenario like this is that the P routers end up looking a lot like Frame Relay switches from the perspective of forwarding traffic. The conclusion is that if the P routers do not hold Internet addresses, and no devices external to the provider network can send packets to the P routers, the security of the P router is similar to that of a Frame Relay or ATM switch.

The conclusion is that with MPLS, the core P routers can deliver secure transport to both private MPLS VPN and public Internet traffic. The remaining issue, however, is the PE routers. If they are addressable from the Internet, they are susceptible to denial of service (DoS) attacks from anywhere on the Internet. Therefore, they are a concern and need additional protection to offer secure service. Some providers go the extra mile and offer MPLS VPN service on separate PE routers to their Internet PE routers. In these cases, the enterprise can be fairly confident that security loopholes have been minimized. For enterprises considering service from providers that choose to have both Internet and private VPN customers on the same PE, some additional checks are required, as described in the section "Issues for Enterprises to Resolve When Connecting at Layer 3 to Provider Networks."