Cisco Systems OL-4344-01 manual Label Spoofing

Page 24

Chapter 1 About Cisco IP Solution Center

Security Requirements for MPLS VPNs

In practice, access to the PE router over the CE-PE interface can be limited to the required routing protocol by using access control lists (ACLs). This limits the point of attack to one routing protocol, for example BGP. A potential attack could send an extensive number of routes, or flood the PE router with routing updates. Both of these attacks could lead to a denial-of-service attack, however, not to an intrusion attack.

To restrict this risk it is necessary to configure the routing protocol on the PE router as securely as possible. This can be done in various ways:

Use ACLs. Allow the routing protocol only from the CE router, not from anywhere else. Furthermore, no access other than that should be allowed to the PE router in the inbound ACL on each PE interface.

ACLs must be configured to limit access only to the port(s) of the routing protocol, and only from the CE router.

Where available, configure MD-5 authentication for routing protocols.

This is available for BGP, OSPF, and RIP2. It avoids the possibility that packets could be spoofed from other parts of the customer network than the CE router. This requires that the service provider and customer agree on a shared secret between all CE and PE routers. The problem here is that it is necessary to do this for all VPN customers; it is not sufficient to do this only for the customer with the highest security requirements.

MD5 authentication in routing protocols should be used on all PE-CE peers. It is easy to track the source of such a potential denial-of-service attack.

Configure, where available, the parameters of the routing protocol to further secure this communication.

In BGP, for example, it is possible to configure dampening, which limits the number of routing interactions. Also, a maximum number of routes accepted per VRF should be configured where possible.

In summary, it is not possible to intrude from one VPN into other VPNs or the core. However, it is theoretically possible to exploit the routing protocol to execute a denial-of-service attack against the PE router. This in turn might have negative impact on other VPNs. For this reason, PE routers must be extremely well secured, especially on their interfaces to the CE routers.

Label Spoofing

Assuming the address and routing separation as discussed above, a potential attacker might try to gain access to other VPNs by inserting packets with a label that he does not own. This is called label spoofing. This kind of attack can be done from the outside, that is, another CE router or from the Internet, or from within the MPLS core. The latter case (from within the core) is not discussed since the assumption is that the core network is provided in a secure manner. Should protection against an insecure core be required, it is necessary to run IPsec on top of the MPLS infrastructure.

Within the MPLS network, packets are not forwarded based on the IP destination address, but based on the labels that are prepended by the PE routers. Similar to IP spoofing attacks, where an attacker replaces the source or destination IP address of a packet, it is also possible to spoof the label of an MPLS packet.

The interface between any CE router and its peering PE router is an IP interface, that is, without labels. The CE router is unaware of the MPLS core, and is only aware of the destination router. The intelligence exits in the PE device, where based on the configuration, the PE chooses a label and prepends it to the packet. This is the case for all PE routers, toward CE routers, as well as to the upstream service provider. All interfaces into the MPLS cloud require IP packets without labels.

Cisco IP Solution Center, 3.0: MPLS VPN Management User Guide, 3.0

1-24

OL-4344-01

 

 

Image 24
Contents About Cisco IP Solution Center Overview of ISC ISC Network Management SubnetISC Features Service Provider Network for Vlan ID Management Access Domain Assigned Resource PoolsFeatures and Functions Provided in Provisioning with ISC VPN Service Profile-Based ProvisioningRole-Based Access Control Rbac CPE Customer’s and Provider’s View of the Network Customer’s View of the NetworkAbout Provider Edge Routers PEs About Multi-VRF CEsA Multi-VRF CE Providing Layer 3 Aggregation Using Templates to Customize Configuration Files Mapping IPsec Tunnels to Mpls VPNsAuditing Service Requests Uses for the Template FunctionAbout Mpls VPNs VPNs Sharing SitesCharacteristics of Mpls VPNs Intranets and ExtranetsVPN Routing and Forwarding Tables VRFs VRF Implementation Considerations Ip vrf site2 rdCreating a VRF Instance Route Distinguishers and Route TargetsRoute Target Communities CE Routing CommunitiesHub and Spoke Considerations Security Requirements for Mpls VPNs Address Space and Routing SeparationAddress Space Separation Routing SeparationHiding the Mpls Core Structure Resistance to Attacks Securing the Routing ProtocolLabel Spoofing Routing Authentication Securing the Mpls CoreTrusted Devices PE-CE InterfaceLDP Authentication Separation of CE-PE LinksConnectivity Between VPNs MP-BGP Security Features Security Through IP Address ResolutionNorth Bound Interface NBI Ensuring VPN IsolationAPI Functionality Supported Distributed Load Balancing NBI BenefitsAPI Approach 11 Simple Flat-Based Server Load Balancing Configuration Four-Tier System Architecture Client tierControl tier