MPLS VPNs and Firewalling
As previously described, it might not be sufficient to control VPN separation with the route targets. In an extranet scenario, for example, routes from various VPNs are brought together in a single context; therefore, additional security measures need to be taken. Firewalls offer a solution to this problem.
To find out where firewalls are needed, consider the following steps:
1. |
Establish a map of the full network?
This may include several VPN sites, maybe some extranet zones, and probably the Internet. The key concept here is reachability: who can reach what (also considering routing changes, static routing, and so on). |
2. |
Divide this full network into zones of trust?
The Internet and the MPLS core are always separate zones, each extranet is a zone, and each VPN is a separate zone. Depending on the security policy of a VPN, a single VPN might have several zones of trust (see Chapter 1) internally, divided by VPN sites. (Internal splits within a VPN site are outside the scope here.) |
In principle, firewalls are required on all zone boundaries.
The concept of zones of trust was introduced in Chapter 1. We apply this concept to the previous example to show how it can be applied in practice.
Figure 4-12 depicts the various zones of trust in the current example, with both Internet and extranet connectivity.
Figure 4-12. Zones of Trust
Following this procedure strictly, firewalls would also be required between the MPLS core and the VPNs, a setup which is not normally seen in implementations. The reason for this is that the MPLS core has a special role in the provisioning: the MPLS core, or better yet, the service provider providing the core, is usually trusted by the VPN customers. And, in fact, the VPN customer has no choice here except to trust the service provider.
The reason is that every service provider has the power to make any VPN it provides insecure?for example, by adding additional VPN sites, by sniffing traffic on the trunk lines, or by inserting fake traffic into a VPN. This issue is common to all VPN service models: for example, in ATM VPN services, the service provider has the power to send fake traffic into a VPN.
Therefore, the MPLS core has a special status in that it is most implicitly trusted by the VPN customers. If the service provider cannot be trusted, firewalls would add little value: The service provider could still sniff connections and interrupt or "steal" them.
NOTE
The only solution if the service provider is not trusted is to provision additional security on top of the MPLS VPN service, such as with CE-CE IPsec. In practice, this has so far rarely been done.
Thus, since the MPLS core is implicitly trusted, the zones of trust change for the VPN customers. Figure 4-13 shows the effective zones of trust as seen from a VPN user.
Figure 4-13. Zones of Trust, Seen from a VPN User
Therefore, firewalling is typically required between a VPN and the Internet, and between a VPN and an extranet.
NOTE
From a service provider point of view, the VPN customers are typically not trusted. Therefore, a service provider's view of zones of trust corresponds to Figure 4-12. To shield the core from VPN users, a service provider does not use firewalls but other measures: infrastructure ACLs, strict router security, as well as security of any routing protocol used. See Chapter 5 for more details.
The firewalling between VPNs and the Internet or extranets can be achieved in several ways. A firewall can be placed at the VPN site connecting to one of the "outside" zones. This would typically be under the control of the VPN customer. Alternatively, a central firewall can be used to shield VPNs against outside zones. Figure 4-14 depicts this scenario, which also solves the problem of nonunique address space. In this case, the extranet/Internet PE holds a VRF for each VPN that requires access to the extranet/Internet. Only the routes from this VRF are imported from the MPLS side, plus a possibly static route to the outside. From the VRF on the shared PE, there is a connection to a virtual firewall and from there to the extranet.
Figure 4-14. Firewalling Between VPNs and Internet/Extranets
A virtual firewall maintains separate customer contexts, similar to a PE router. Between those contexts there is no connectivity, such that all customer contexts are completely independent. The firewalling function is performed between each customer context and the Internet context.
The added advantage here is that the firewall can also perform a NAT function, so that each VPN can keep using the entire theoretical IP address space. Therefore, each connected VPN perceives the virtual firewall as as a normal firewall.
The lines between the PE and the firewall can be implemented either physically or logically, that is, either with separate cables or as VLANs on a single ethernet connection, for example. Typically, a single physical connection is used, and virtual interfaces are configured for each virtual firewall.
When different VPNs are connected in an extranet, or within one VPN site with different security levels, firewalls should be positioned between the zones. Figure 4-15 shows an example of how this can be achieved.
Figure 4-15. Firewalling Within a VPN or an Extranet
In this scenario, the firewalls are within the VPN they protect, and even the link between the firewall and the PE router belongs to that VPN. Therefore, no virtualization is required here, and normal enterprise firewalls can be used here.
It cannot be stressed enough that in all of these scenarios where routes are exchanged through route-target configuration, firewalls are essential: without them the sides are just interconnected on the IP level, without any protection. This applies clearly to sites within a single VPN but also to extranet scenarios.
A firewall protects primarily against intrusions: it prevents an outsider from accessing internal devices. However, there is another important threat: DoS attacks. Firewalls only provide limited protection against DoS attacks because there are other ways to degrade the service. For example, if the access line between the PE and the firewall in Figure 4-15 is overloaded, the firewall does not help. Even worse, if the PE router itself is overloaded, it might also affect the connected VPNs.
DoS attacks cannot be averted with features on boxes: the problem has to be solved by appropriate network design. The following section outlines the potential issues and design solutions for DoS attacks.
