Internet Extranet and MPLS Security

The Internet is usually positioned as the insecure part in any network deployment, so threats normally come from the Internet. Although this view is completely correct, it is not complete. In other parts of the Internet, other users require security, and from their point of view, the threat also comes from "the Internet," which now includes your own network. For any given service provider networkMPLS or notthis means that a threat is originating in this network toward the Internet. One could assert that threats may be 50 percent from the Internet and 50 percent from internal sites or hybrids of sites outside the trust zone.

Some service providers take the view that security is unidirectional and that they have to secure their part of the Internet, including their customers, against the rest of the Internetbut not the other way round. There are at least two reasons this attitude is inappropriate in the global Internet. First, the Internet is a global system and requires all participants to do their share in securing access to it. Second, and more practically, an attack from a customer of a service provider often affects the service provider network as well, or other customers of that service provider. This can be observed where worms are spreading, with e-mail spam relays, and many other security incidents.

For all these reasons, operators of networks that connect to the Internet must also secure the Internet from their customers, such as by applying source address spoofing prevention as described in RFC 2827 (BCP 38).

In the specific context of MPLS VPNs, the threat originates from every VPN customer who has Internet connectivity through this MPLS VPN service. Customers who do not receive Internet connectivity from the MPLS provider can still be the source of security incidents through other paths, such as through other Internet service providers.

The CIA has published a report that shows that the majority of security incidents occur on the inside of an enterprise. More generically speaking, this refers to a zone of trust. In many networks, the insider is more of a threat to the networks than the outsider.

This principle applies in the same way to MPLS VPN deployments, for each zone of trust separately:

• The zone of a given VPN This is essentially the enterprise intranet, and the previously mentioned report refers directly to this zone of trust.

• The core network Also in the core, an insider can easily modify configurations, endangering the security of the core or connected VPNs. Where this affects VPNs, it is strictly speaking not a threat from within the zone. This is discussed earlier in this chapter.

• For extranets and other external networks Threats, such as information being changed, can be originated in these zones.

A number of potential security issues that originate in the same zone of trust exist and are thus not related to the fact that the underlying infrastructure is an MPLS network. Examples for such issues are as follows:

• An unsecured wireless access point in an enterprise, which has an MPLS VPN service.

• A DoS attack from the Internet to a web server in a VPN network, where the VPN with Internet service is provided on the same MPLS core. If an MPLS core provides Internet connectivity to a given VPN, this connectivity can also be used to attack the VPN from the outside. The same would be true in other VPN deployments, such as Frame Relay or ATM.

• An intrusion from one MPLS VPN into another VPN that results in a compromise of a customer's data. Such deployments should normally be secured by a firewall, and the security depends on the correct configuration of that firewall.

• Worm infections from a VPN site to an extranet site, where such connectivity was deployed consciously. In this case, firewalls are typically deployed and security depends on correct operation of the firewall, plus standard security measures within the end systems.

In summary, within a single zone of trust, or wherever connectivity between zones of trust has been specifically designed, security issues relating to such connectivity are outside the scope of this chapter. In these cases, traditional security solutions, such as firewalls, need to be used to separate the zones as required.

To analyze security in any environment, a threat model is required and security requirements are then evaluated against it. This chapter has defined the threats against the various zones of trust in the MPLS VPN environment.

Threats against VPNs include intrusions and DoS attacks from other VPNs, the Internet, or the MPLS core. Each other zone has similar threats. Threats that are not related to the MPLS architecture, such as internal threats within a zone of trust, are not considered in this chapter because they also exist in other VPN environments, such as ATM or Frame Relay.

In network environments where both private network and Internet access are provided by one infrastructure, the security considerations applicable to the MPLS VPN assume the added significance of the Internet component's impact or potential impact on the service provider backbone and the customer edge connections. Not only are two corporate entities involved in the network services provisioning, but the Internet and its millions of connections and users are now closely coupled with the corporate data networks.

This necessitates stringent adherence to service provider security best practices to ensure the security and reliability of the backbone. In addition, you must address network design issues to guarantee that corporate (once private network) data is not adversely impacted by the vagaries of the Internet data flows. Of course, high volumes of corporate data (for instance, large image transfers or data backups) could also impact the infrastructure to an extent that Internet traffic suffers. However, Internet traffic is typically viewed as best effort traffic with little or no expected service levels, and as such, as long as user performance is not unduly hindered, this should not be a major issue. As the usage profiles of the Internet change to support traffic that has more stringent latency or jitter restrictions, more attention might be required with respect to general traffic performance.

Of greater import are intrusion-oriented security concerns and DoS attacks that are more likely to be sourced from the Internet than the corporate space and must be addressed to mitigate impact to the VPN traffic flows. At an overview level, there are three basic approaches to providing Internet and MPLS VPN services to a given set of customers.

These are as follows:

• Totally distinct networks

• A shared core network with separate PE and CE components and connections

• Shared resources end-to-end

Clearly, the provisioning of totally separate networks ensures that the only Internet-driven security vulnerabilities will be through the customer's own interconnect points within his network. This is a very costly approach for the service provider, though, and it will be reflected in the costs passed on to the consumer of such services.

Clearly, there is an incentive for some sharing of resources with due consideration given to the degree of conjoined infrastructure that is prudent.

In general, it is recommended that the VPN service network interconnects and the Internet access be run over separate links and to separate routers (not the VPN-supporting routers), rather than attempting to homogenize them over a single facility.

That is, the service provider should provision separate PEs for VPN versus Internet access even if the backbone P routers are convergent. As well, the interconnections between the VPN and Internet PEs should be unique and preferably be terminated on separate CE routers. This allows for the greatest degree of configuration flexibility (thereby policy control) and reduces the concern that Internet-launched DoS attacks will have an immediate impact on the VPN performance. Internet traffic can be directed through DMZ facilities at centralized customer sites where firewall-based control and intrusion detection systems can be readily deployed. Internet access can then be provided to other sites through default routing propagated through the corporate VPN.

The use of default routing to direct traffic through the DMZ ensures that corporate security policies are applied to traffic that traverses the Internet and provides a single connection point where problems can be identified and controlled. This approach also minimizes the memory usage on the PE and CE routers, which can be considerable if the entire Internet table is propagated.

The third alternativesharing end-to-end resourcesensures that the network deployment costs are minimized, at least from a hardware and facilities perspective.

However, this approach is fraught with considerable security risks. Both services (MPLS/VPN and Internet access) must be tightly controlled to avoid any adverse interactions. In this scenario, the SP backbone, the PE router, the interconnection facility between the CE and PE, and the CE router itself are shared resources with respect to both the VPN and Internet traffic flows. The CE router needs to implement some mechanism to groom VPN and Internet traffic into different channels. The Internet traffic must be directed through a firewall device before re-merging with the corporate traffic. Policy-based routing or multilite-VRF can be used to perform the traffic direction. Indeed, some security perspectives suggest the use of doubled firewalls to provide an additional level of protection.

In addition, the use of IDSs is highly recommended to provide early warning and information leading to quicker resolution of Internet-driven attacks.

Due to the inherently greater degree of control and security mechanisms available, static or eBGP routing should be used between PE and CE in this scenario. The recommended CE-PE routing mechanisms are discussed later in this chapter.

Clearly, firewalling should be viewed as a necessary component of any Internet access, whether accomplished by any of the following means:

• A firewall at the central site with centralized Internet access

• A firewall at each CE site

• A firewalling through an SP service offering either through stacked or shared approaches

In addition, many current implementations of customer networks have been based on the use of private address space. Interconnecting to the Internet requires the use of global addresses that generally necessitate some form of network address translation (NAT). In addition to firewalls, this NAT functionality can be implemented either through shared services provided at a central customer site or by the SP.


+1 0

Post a comment