Threats Against a VPN
This section discusses all threats from the point of view of a VPN customer or user. Any VPN user (for example, a bank that is using an MPLS VPN service) needs to analyze security based on the threats against its VPN. Threats that are potentially related to the MPLS VPN architecture are
Intrusions from the outside (for example other VPNs, the core, or the Internet)
Denial of service (DoS) from the outside (for example, other VPNs, the core, or the Internet)
Figure 2-1 depicts where threats might come from in a specific VPN. Threats might come primarily from other VPNs (1), the core itself (2), or the Internet (3). Threats internal to a VPN are not considered here. Those are typically independent of the VPN architecture; that is, the threats would be the same over, for example, Frame Relay.
Figure 2-1. Threats Against a VPN
There is one exception to this rule: the PE is, by default, "visible" from the VPN user's network on Layer 3, and needs to be specially secured. This does not constitute a direct threat against a VPN, but against the core. Indirectly, however, a DoS attack against a PE might also affect availability of other connected VPNs. The PE is therefore a critical part in MPLS VPN security, and PE security is discussed in various sections of this book?in Chapter 3, "MPLS Security Analysis," in the section "Robustness against Attacks"; in Chapter 4, "Secure MPLS VPN Designs," in the section "Hybrid Provider Edge Recommendations"; and in Chapter 5, "Security Recommendations."
MPLS provides the possibility to connect VPN sites with any-to-any connectivity; therefore, traffic can flow from a given VPN site to any other site on that VPN. Sometimes, critics of MPLS point out that, inside a VPN, this may make secure traffic management such as firewalling and intrusion detection harder because there is not necessarily a central point where all traffic can be controlled. While this is true, MPLS gives the VPN user the choice of topology; and if more centralized services are required, MPLS allows the possibility to create hub-and-spoke topologies. This is a choice of the VPN user.
Intrusions into a VPN
Intrusions give an outsider control over parts of the VPN. This could be network elements, servers, PCs, or other networking equipment. To execute an intrusion, the attacker has to insert control traffic into the VPN; in the simplest case, a single IP packet to a destination in the VPN.
NOTE
Although most of today's intrusions use IPv4 packets, other data traffic can also be used to intrude into a network. This could be Layer 2 packets, IPv6 packets, or even the telephone system when dialing into a modem. Labeled packets also have to be considered, although the standard PE-CE interface does not allow labeled packets, which would be dropped. In the Inter-AS and Carrier's Carrier cases, labeled packets are an important consideration. See Chapter 3 for details on how labeled packets might impact security in those cases.
Figure 2-2 depicts the potential intrusion vectors into a VPN. Intrusions could potentially come from another VPN (1), the core itself (2), or from the Internet (3). What they have in common is that they must target a piece of the VPN infrastructure directly.
Figure 2-2. Intrusion Vectors into a VPN
Therefore, to control intrusions into a trusted zone, it is sufficient to block all illegitimate data traffic from the zone. In traditional networks, this is being done using a firewall that controls traffic into a site and by separating the network from other outside networks, such as the telephone system.
In the MPLS VPN environment, the principles of separation against outside networks and control of inbound traffic into a VPN prevail as well. Chapter 3, "MPLS VPN Security Analysis," shows that VPNs are fully separated from each other such that intrusions from other VPNs or from the core cannot occur. When two normally separate zones, such as two VPNs, are connected at the IP layer (for example, in an extranet or for Internet access), additional firewalling is usually required. This firewalling, however, is independent of the MPLS network, as it would also be required over any other network architecture.
However, this assumes correct operation of the MPLS core network. If the MPLS service provider engineer misconfigures a PE router, an external site might become a member of a VPN, which would enable intrusions from this external site. This misconfiguration could be accidental or malicious. Note that the same threat exists in Layer 2 networks. This is discussed further in Chapter 3.
Some Inter-AS architectures can introduce an additional risk to the VPN user. Under certain conditions, a service provider (SP) that is providing part of the Inter-AS MPLS core can send unidirectional traffic into VPNs of other Inter-AS SPs. However, a VPN user must always trust the SPs involved in the provisioning of their VPN; any core provider can make VPNs insecure. Therefore, while Inter-AS security is a concern, the fundamental issue is that the SPs must be trusted, no matter what form of VPN (also non-MPLS VPNs). Inter-AS security is discussed in detail in Chapter 4.
The threat of the accidental PE misconfiguration in this context is probably somewhat less important than the malicious misconfiguration because there is not necessarily a malicious intent in this case. The possibility of the SP engineer to maliciously insert an external site into a given VPN, however, is a serious threat against the security of that VPN because that external site effectively becomes a member of the VPN and has the possibility to intrude into it. Chapter 8, "Secure Operation and Maintenance of an MPLS Core," explains how this threat can be controlled.
Denial of Service Against a VPN
Another threat against a VPN is denial of service (DoS) from the outside. Again, this threat could come from other VPNs, the core itself, or the Internet. However, there is a key difference between intrusions and DoS: intrusions allow full access to internal data, whereas DoS does not give such access, but prevents access for all users.
To intrude, a hacker needs to be able to send packets into the trusted zone of the VPN. Therefore, it is possible to protect a VPN effectively by securing its own network edge. This action involves assuring that the intrusion points are controllable; that is, that there are no hidden intrusion points. Chapter 3 discusses this question in detail.
The threat model for a DoS attack against a VPN is different, however: A given VPN site might receive a DoS attack against its own networking infrastructure (that is, targeting parts of the VPN that are under control of the VPN user); but, as opposed to an intrusion, a DoS attack can also affect a VPN user indirectly. For example, if a PE router is under a DoS attack, this might affect a given VPN connected to that PE, even though the attack is not directly against the VPN. The result might be slower performance for VPN sites connected to this VPN. This increases the exposure to DoS attacks.
In principle, any shared part of the network under DoS might affect a given VPN. Figure 2-3 shows that the attack points for a DoS attack against a VPN include any point of that VPN, but also any points in the shared infrastructure. This applies to core devices such as PE and P routers, core lines, and shared accesses (for example, accesses to the Internet or to extranet sites).
Figure 2-3. Attack Points for DoS Against a VPN
Although protecting a VPN against intrusions is relatively straightforward with controlling the ingress points into the VPN, protection against DoS is more complex due to the indirect effect of DoS attacks on the infrastructure. The solution to this threat lies in the correct architectural design of the MPLS network. How an MPLS VPN infrastructure can be designed to appropriately secure against DoS attacks is described in detail in Chapter 4.
