Cisco Systems OL-4344-01 manual Hiding the Mpls Core Structure

Page 22

Chapter 1 About Cisco IP Solution Center

Security Requirements for MPLS VPNs

Given addressing and routing separation across an MPLS core network, MPLS offers in this respect the same security as comparable Layer 2 VPNs, such as ATM or Frame Relay. It is not possible to intrude into other VPNs through the MPLS core, unless this has been configured specifically.

Hiding the MPLS Core Structure

The internal structure of the MPLS core network (PE and Provider router devices) should not be visible to outside networks (either the Internet or any connected VPN). While a breach of this requirement does not lead to a security problem itself, it is generally advantageous when the internal addressing and network structure remains hidden to the outside world. The ideal is to not reveal any information of the internal network to the outside. This applies equally to the customer networks as to the MPLS core.

Denial-of-service attacks against a core router, for example, are much easier to carry out if an attacker knows the IP address. Where addresses are not known, they can be guessed, but when the MPLS core structure is hidden, attacks are more difficult to make. Ideally, the MPLS core should be as invisible to the outside world as a comparable Layer 2 infrastructure (for example, Frame Relay or ATM).

In practice, a number of additional security measures have to be taken, most of all extensive packet filtering. MPLS does not reveal unnecessary information to the outside, not even to customer VPNs. The addressing in the core can be done with either private addresses or public addresses. Since the interface to the VPNs, as well as potentially to the Internet, is BGP, there is no need to reveal any internal information. The only information required in the case of a routing protocol between a PE and CE is the address of the PE router. If this is not desired, you can configure static routing between the PE and CE. With this measure, the MPLS core can be kept completely hidden.

To ensure reachability across the MPLS cloud, customer VPNs will have to advertise their routes as a minimum to the MPLS core. While this could be seen as too open, the information known to the MPLS core is not about specific hosts, but networks (routes); this offers some degree of abstraction. Also, in a VPN-only MPLS network (that is, no shared Internet access), this is equal to existing Layer 2 models, where the customer has to trust the service provider to some degree. Also in a Frame Relay or ATM network, routing information about the VPNs can be seen on the core network.

In a VPN service with shared Internet access, the service provider typically announces the routes of customers that wish to use the Internet to his upstream or peer providers. This can be done via a network address translation (NAT) function to further obscure the addressing information of the customers’ networks. In this case, the customer does not reveal more information to the general Internet than with a general Internet service. Core information is not revealed at all, except for the peering addresses of the PE router) that hold the peering with the Internet.

In summary, in a pure MPLS VPN service, where no Internet access is provided, the level of information hiding is as good as on a comparable Frame Relay or ATM network—no addressing information is revealed to third parties or the Internet. If a customer chooses to access the Internet via the MPLS core, he will have to reveal the same addressing structure as for a normal Internet service. NAT can be used for further address hiding.

If an MPLS network has no interconnections to the Internet, this is equal to Frame Relay or ATM networks. With Internet access from the MPLS cloud, the service provider has to reveal at least one IP address (of the peering PE router) to the next provider, and thus the outside world.

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

1-22

OL-4344-01

 

 

Image 22
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 Address Space Separation Security Requirements for Mpls VPNsAddress Space and Routing Separation Routing SeparationHiding the Mpls Core Structure Resistance to Attacks Securing the Routing ProtocolLabel Spoofing Trusted Devices Routing AuthenticationSecuring the Mpls Core PE-CE InterfaceSeparation of CE-PE Links LDP AuthenticationConnectivity Between VPNs MP-BGP Security Features Security Through IP Address ResolutionEnsuring VPN Isolation North Bound Interface NBIAPI Functionality Supported NBI Benefits Distributed Load BalancingAPI Approach 11 Simple Flat-Based Server Load Balancing Configuration Four-Tier System Architecture Client tierControl tier