Comparing MPLS VPN Security to Frame Relay Networks
| The preceding section gave an overview of how P routers can provide secure transport of packets in the simple MPLS topology. The more interesting case is considering the two-label imposition of MPLS VPN and how that compares to Frame Relay security. In 2001, the network technology tester Meircom completed a report that analyzed the security characteristics of MPLS VPN networks compared to Frame Relay services. It concluded that security was equivalent. (You can locate this report at http://www.miercom.com/?url=reports/&v=16&tf=-3&st=v.) This report validated the following:
The approach used in the Meircom report is to define the components that allow an MPLS VPN to function and analyze the possibility for an attack on or intrusion to both components of the MPLS VPN. The two primary components are
VRF is a customer-specific routing table; think of it as a low-function virtual router for each customer within the PE router. Its purpose is purely to separate control traffic (route information) between multiple enterprise customers on the same PE. The abbreviated configuration shown in Example 7-1 identifies how these things are created in PE router devices. Example 7-1. VRF Configuration in PE Routers
The first part of this configuration creates a VRF called Customer_1, and a route distinguisher (RD) of 300:300 is defined for this customer. This becomes the identifier for this customer's VPN routes within the provider network. MPLS VPNs are designed to allow for overlapping address space between multiple customers. The provider network differentiates between these similarly addressed networks by appending the RD to these routes and using multiprotocol BGP (MP-BGP) within its network to advertise these RD plus IPv4 routes to all other PE routers supporting the VPN. The combination of an RD and IPv4 address is called a VPNv4 address. This covers the control plane distribution of what were identical IP addresses in different customers but are now customer-unique addresses by the addition of the RD. Forwarding, however, is a different story. No routing table holds VPNv4 addresses and performs lookups on them to determine forwarding decisions. Instead, MP-BGP distributes a label along with the VPNv4 route, which defines the label value for any other PE that wants to forward data to that destination. If that label value were the only value label for forwarding data to this VPN destination, all routers within the provider network would have to know about that set of VPN destinations. To avoid this, two labels are appended to any packets that are to be forwarded in an MPLS VPN network: one to take the packet to the next-hop PE router, and an inner label to identify where within that PE router the packet needs to end up. This means that no forwarding based on an IPv4 address happens within the provider network; therefore, IP addresses between customers can overlap. Having created the VRF and defined the unique customer RD, routes are exported from the VRF to MP-BGP with the defined extended community value 200:2000. Next, routes with the same extended community value are imported to this VRF. This means that MP-BGP marks the routes from this VRF with the defined route-target value. Should any routes from other PE routers send an update that also have that extended community (this happens only if those PEs have also been configured with this route-target value, implying that they have connections to the same customer VPN), they are imported to this VRF. It is possible to configure the RD and the route target to be the same value. However, the additional flexibility of configuring them to be different enables the possibility of extranet connectivity. Refer to Jim Guichard's book MPLS and VPN Architectures (ISBN 1587050811, published by Cisco Press) for further discussion of this topic. The final part of Example 7-1 shows how specific enterprise-facing interfaces are associated with specific VRFs. In effect, the ip vrf forwarding configuration assigns a specific interface to the VRF virtual router. Security Concerns Specific to MPLS VPNsIf everything is separated, where are the possible security compromises? Well, the first concern is that the P and PE routers within the provider network are secure themselves. At the most basic level, you would expect access control to the core routers from Telnet and Simple Network Management Protocol (SNMP) to be locked to specific source addresses via access control lists. There are concerns that potentially false routing information can be injected into the network. These concerns can be addressed by implementing Message Digest 5 (MD5) authentication on the network. MD5 is a method to ensure that only predefined routers can send routing information to a given P router. The next security concern comes from looking at the forwarding path and analyzing the potential for inserting spoofed labeled packets into the network. This is actually impossible, because a potential attacker can gain access to a network interface only if he is a customer and has an interface on a PE router. These interfaces accept only IPv4 packets, so sending labeled packets to an MPLS VPN PE device just causes that PE device to drop the packet. It is possible for a customer to send packets to the PE that will be dropped, with the intent of exhausting the PE router's CPU. However, those forms of attacks are naturally limited to the speed on the access link connecting the customer. Given that each customer's control and data plane traffic is segregated in an MPLS VPN environment, what concerns are there? First, no customer can directly address core network routers on the network. One of the simplest ways to check if an MPLS VPN provider is hiding P router addresses from customer edge (CE) devices is to issue a traceroute from one CE to another CE on the VPN network. When the traceroute report comes back, no addresses of the P router devices should be viewable; the P router portion of the network should just appear as if it is one hop to the traceroute report. Providers can simply hide their P router addresses from VPN users by turning off time-to-live (TTL) propagation. Additionally, it is common practice for the provider to implement ACLs on the ingress to the PE devices to deny packets with destination addresses within the P portion of the network from entering the network. Note Chapter 9 discusses the options for the provider delivering Internet access as part of the MPLS VPN service. Implying that the PE device has Internet connectivity, this provides the greatest level of enterprise network simplification but opens the PE device to potential DoS attacks. Therefore, it presents a higher security risk. For the most secure service, separate VPN and Internet links are the best option. The next section addresses the generic issues of securing an interface connecting at Layer 3 to a third party. The next concern is whether the MPLS VPN service can be denied by one customer who overwhelms the resources of the shared PE device. This customer can be either a valid customer or someone hijacking a PE-to-CE connection. The first generic recommendation for protecting the PE control plane to traffic generated by valid customers is to implement static routing between the PE and CE or to use MD5 authentication if a routing protocol is implemented on that link. As well as MD5, it is possible to explicitly rate-limit any kind of traffic on the PE-to-CE link, including routing protocol traffic. The second recommendation is to limit the number of routes any given PE accepts from a CE to protect PE resources should something catastrophic happen on one CE router (such as a software bug generating spurious route updates). In the case where spurious routes are sent to the PE, the route limit protects PE resources from being consumed. An enterprise can verify with its VPN provider that these and other provider-defined security features are implemented before signing up for the MPLS VPN service. Figure 7-3 summarizes where these features should be implemented within the network. This gives the enterprise a checklist to confirm with potential providers concerning their security preparedness. Figure 7-3. Securing the MPLS Core with Authentication for Routing and ACLs for the Data Plane Note Although Chapter 9 discusses some of the options for connecting the enterprise to the provider to enable Internet access, a fuller treatment of this subject is presented here. In this analysis, it is assumed that the core P routers support Internet connectivity, and different options for shared and dedicated PE routers, PE-to-CE links, and firewall locations are provided. The safest option is to insist that the provider give VPN service that is delivered by a PE device not addressable from the Internet. This might cost more, because it costs the provider to supply a separate PE router dedicated to the two services and manage them separately. Additionally, a second access line at each location that needs Internet access is required, because each remote site has a separate connection for VPN access that does not have direct connectivity to the Internet. Each site that requires Internet access would look something like the topology shown in Figure 7-4. Figure 7-4. Separate CE, PE, and PE-CE Links for Internet and VPN Access With this option, router 1 has full knowledge of VPN routes, plus a default route for accessing Internet locations. The default route, which directs traffic to the firewall/Network Address Translation (NAT) device, incurs substantial extra costs from both the provider and enterprisenot only in PE, CE, and PE-to-CE links, but also in firewall/NAT and IDS devices at each enterprise site because of this separate Internet access. However, this option provides the strongest separation between Internet and VPN services over the WAN and the strongest resistance from Internet DoS attacks. A variation of this approach that does save some costs is to allow the PE device to carry Internet routes and therefore be reachable via the Internet, but still retain two links from the enterprise to the provider network. Essentially, the topology is the same as what's shown in Figure 7-4, except that PE1 and PE2 are combined, and the two PE-to-CE links terminate on this one combined PE router. Some cost savings for the provider can be passed on to the enterprise by having to supply only one PE; however, the trade-off is that a DoS attack from the Internet could affect the VPN service on this shared PE. The next level of compromise in the choice between security and cost is reducing the number of CEs to one and consolidating the PE-to-CE link to one, as shown in Figure 7-5. Figure 7-5. Shared Access Line In this case, consider the enterprise VPN being addressed with the private 10.0.0.0 network. All interfaces on router 1, its connection to the CE, and the PE-to-CE link on the subinterface connecting to the PE subinterface associated with the VPN VRF are all addressed on this private address space. Public Internet addresses are configured on the PE-to-CE link for the subinterface on the PE dedicated to Internet service, as on the CE, which also uses public addresses on the interfaces connecting the CE to the NAT device. Routing is set up for outbound traffic such that router 1 knows about all VPN routes in the 10.0.0.0 space and a default to the firewall/NAT device for Internet connectivity. The same routing arrangement is configured for the CE device, with 10.0.0.0 routes for the internal VPN and a default for Internet routes. The only difference is that the CE also knows about the public addresses on the CE-to-firewall link so that packets arriving from the Internet are forwarded to the firewall device rather than back out to the Internet. With a simple setup like this, routing operates acceptably. A modification to this basic setup is to use policy-based routing on the CE to force any traffic coming in from the Internet subinterface to go to the firewall/NAT device. The reason for this is just to add some extra protection for the internal network, at the cost of some additional processing by the CE router. This protection is useful if an attack or intrusion to the CE comes via the Internet connection, with addresses destined for the 10.0.0.0 network. Without policy-based routing, those packets would be forwarded directly to the internal network. With policy-based routing, the firewall/NAT device can stop those packets from making it into the internal network. This use of policy-based routing is highly recommended if, for example, the internal network has been addressed with publicly routable address space. A design alternative to policy-based routing, which can have performance implications on some software-based platforms, is a feature called multi-VRF CE. This feature creates VRFs on a CE router and assigns interfaces to those VRFs to create multiple virtual routing instances within the one router. They segregate the control information and forwarding for different services, such as Internet and VPN, without the need for policy-based routing. In the example shown in Figure 7-5, two VRFs are created on the CE, with two interfaces assigned to each VRF. The Internet VRF has the CE-to-firewall/NAT device and the subinterface on the PE-to-CE link used for Internet traffic associated with it. Similarly, the VPN VRF has the CE-to-router 1 interface and VPN subinterface on the PE-to-CE link associated with it. The CE is not required to carry full Internet routes in its Internet VRF, just a default pointing toward the subinterface on the PE used to carry Internet traffic. Clearly, these compromises save costs, and separation between the Internet and VPN traffic is maintained; however, the primary security concerns are that the PE is addressable from the Internet and therefore may be subject to a DoS attack. Additionally, the DoS attack may not incapacitate the PE but may saturate the PE-to-CE link, thus denying service for both VPN and Internet service to the enterprise. If the enterprise wants to outsource the firewall and NAT responsibilities to the provider, the enterprise network manager must consider a number of options. Figure 7-6 shows the first and most simple option. Figure 7-6. Per-Customer Firewalls in the Provider Network In this topology, each customer just needs its own VPN routes within its network and within its VRF in the provider PEs, along with a default route for Internet access. PE 4 has VRFs for all customers configured, with a single outbound interface toward the per-customer firewall/NAT device. This has many advantages from both the provider's and enterprise's perspectives:
The drawback to the provider, however, is that there is one firewall per customer, which could become a management headache for the provider and does not provide a backup in case of firewall failure. A modification to this topology is to split the NAT and firewall responsibilities, moving NAT on a per-VRF basis to PE4. This is basically the same topology as shown in Figure 7-6, except that the customer NAT and firewall devices are replaced with one larger firewall device and NAT now operates on PE4. This also leaves the CEs untouched, which is simpler to provision and manage from the provider perspective. However, clearly, the enterprise can no longer select which firewall the provider delivers service on. One further modification to this is moving NAT to the CE devices. This has additional drawbacks to the NAT for each VRF implementation in that each CE needs to be configured, and they may or may not belong to the provider. As soon as the connectivity to the MPLS VPN is chosen and placement of firewalls and so on is made, the next issue to consider is how such topologies can be attacked. From the enterprise perspective, there are two cases to consider:
The first concern is impossible in theory, because plain IP packets are restricted to each user's VPN by use of the VRF and LSPs created on the network, and MPLS-labeled packets are not allowed in from outside of the provider network. However, this does assume some fundamental conditions. It is assumed that the vendor implementation of these technologies does not provide some loopholes and that the provider operates the network correctly and does not misconfigure. No evidence to date suggests anything other than a correct implementation of MPLS VPN on Cisco equipment, meaning that there are no known cases of an implementation being responsible for an intrusion attack in the more than 200 provider networks where the technology has been deployed. Regarding misconfiguration, that is a matter between the provider and the enterprise and is a common concern for any technologyMPLS, Frame Relay, ATM, or anything else. The more interesting security issue is the one of DoS attacks. Attackers use many approaches to achieve DoS; however, they are centered around achieving one of the following:
Within an MPLS VPN deployment, these issues are most pertinent to examine for the PE and CE devices. The P devices must be secure, just as they must be in any other technology for secure service to be offered. It is assumed that the techniques described in the next section have been applied to secure these P devices. Essentially, the CE-facing interfaces of the PEs are the only access points for any attacker to use on the network. It is assumed that core routers do not offer physical insertion points, because they are in secured facilities. Tapping into optical fibers at rates of up to OC-192, which connects these P routers, is not feasible. The first question to answer is, can an attacker from outside a VPN reach one of your CEs? The answer is that if the network is operated without device misconfiguration, only if it is an Internet CE and has an Internet-routable address. Attackers cannot reach VPN-only CEs. If the CE can be reached from the Internet, security as described in the next section should be applied to it to minimize the possibility of attack. The same applies to accessibility of the PE-to-CE link: It is addressable only if it also carries Internet traffic. To protect the VPN service when it shares an access line with Internet traffic, VPN service can be maintained in the presence of a DOS attack if the Internet traffic is policed at the egress of the PE toward the CE. No matter what is sent, it cannot consume all the shared link bandwidth. The next area of concern is whether another user of your shared PE can exhaust the PE resources by exhausting its resources. This is a matter for the provider. It must ensure protection against things such as too many updates being sent from a customer, too many SNMP queries, disabling the services of small servers, and so on. The debate over security issues related specifically to MPLS VPN continues in the IETF mailing lists, with draft-behringer-mpls-security-05.txt cataloging the current thinking. As this document progresses, expect the 05 to change to 06 and so on if you search for this in the drafts section of http://www.ietf.org. A more general draft that identifies generic provider-supplied VPN security requirements is draft-ietf-l3vpn-security-framework-00.txt. |
EAN: 2147483647
Pages: 136