Robustness Against Attacks
Over the last years, there have been an increasing number of attacks not only against application servers, but also directly against networking infrastructure. Service providers, therefore, have to be extremely careful about securing their core network well. The drastic effects of DoS attacks are mostly understood, but on MPLS VPN networks there is an additional, much more serious danger: if an attacker can control a PE device, the security of any VPN on the MPLS core can be compromised, whether connected to this PE or not. It is therefore of paramount importance for the service provider, but also for the VPN users, that the core, specifically the PEs, are properly secured and not attackable.
Where an MPLS Core Can Be Attacked
As the previous section shows, VPNs are separated from each other and from the core. This also limits potential attack points: Figure 3-5 illustrates the only interface point where a VPN can "see" the core and send packets to a core device: this is the PE router because the attachment circuit between CE and PE belongs to the VPN. Therefore, the only attack points seen from a VPN are all the PE interfaces that connect to CEs of that VPN. In the figure, VPN 1 can only see the PE interface it connects to and no other interface on that PE. Note that there is an attack point for each CE-PE connection, so that all of those PE interfaces must be protected from the entire VPN space. A VPN cannot see any other interface on the PE, nor any core routers (for example, P routers or route reflectors).
)
Figure 3-5 Visible Address Space from a VPN
Each VPN can see and, by default, reach all of its PE peer addresses. These are the only direct attack points in an MPLS VPN environment, and this needs to be examined in more detail. How can a PE router be attacked from the outside?
How an MPLS Core Can Be Attacked
In principle, a PE can be attacked with either transit traffic (not destined to the PE itself) or with targeted traffic to the PE. Traffic that is destined to a router is generally also called receive traffic.
Transit traffic is usually less of a problem because routers are designed to forward traffic fast. A router must, of course, be appropriately dimensioned to handle all potential transit traffic, which is a question of network design. This will be covered in detail in Chapter 4, "Secure MPLS VPN Designs," and Chapter 5, "Security Recommendations." However, certain forms of packets cannot be handled in hardware and can cause additional load on a router. Therefore, floods with such packets can lead to a DoS situation on the router.
Packets with IP options are one example. A packet with IP options has a variable IP header length and cannot, therefore, be looked up in current ASICs (microchips). This means that IP option packets must be switched in software, which lowers the performance of the router. Ways to protect against this are explained in Chapter 5.
Receive traffic, or traffic destined to the PE, is more of a concern because it affects the PE more directly. Two forms of attack are possible with receive traffic:
- DoS— In this case, an attacker tries to consume all resources on a PE router. This could be done, for example, by sending too many routing updates to the router, consuming all available memory.
- Intrusion— Here an attacker attempts to use a legal channel to configure the PE router. Examples are password guessing attacks against the telnet or SSH port, or SNMP writes to the router.
How the Core Can Be Protected
All of the potential attacks can be well controlled by appropriate configuration. In short, the recommendation is to block via an access control list (ACL) all access to all reachable PE interfaces. If routing is required, the routing port should be the only port on the PE not blocked by the interface ACL. Now an attacker can only attack the routing protocol directly, and that needs to be secured separately.
Following these recommendations, the PE will exclusively accept packets on the port for the routing protocol. This can also be secured, as explained in detail in Chapter 5. Any other packet destined to the PE will be dropped by the ACLs.
For overall security, of course all of the interfaces into the core need to be considered. Up to here we have covered the PE-CE interfaces. Another important point to control is the access to the Internet, and the question is whether an MPLS core or its VPNs can be attacked from the Internet.
If Internet access is provided in a VRF as if it were just another VPN, then all the above considerations apply equally to the Internet access: the Internet PE has to be dimensioned correctly, secured with ACLs, and the routing has to be secured separately.
If Internet is provided from the global routing table, then this access has to be secured in a different way. How Internet can be provisioned, what the security consequences are, and how to secure it is discussed in the Chapter 4.
Assuming proper implementation and operation, an MPLS VPN core provides a very high level of security: First of all, the interface into the core is limited to peering PE addresses only, and these can be secured well. This way, an MPLS/VPN core has considerably less exposure to attacks from the outside than a traditional IP backbone, where every interface on every core router might be a target for an attack. One of the key advantages of MPLS, then, is that it has small, well securable edges to the outside, making it easier to secure.
A traditional IP core, in comparison, is by default quite open, and each network element is reachable from the outside. This can in principal be limited by various means, such as ACLs or some core hiding techniques. But the advantage in an MPLS core is that the majority of the core is unreachable by architecture. Note that this depends how Internet routing is carried on the core: if it is carried in the global table, the risks of traditional IP cores apply as well. The key to security on an MPLS core is limited access to the global routing table from the outside. Chapter 4, "Secure MPLS VPN Designs," discusses the various options on Internet provisioning in detail.