When a service provider is providing a customer with a L3 VPN service, the CEs are most of the time owned, controlled and managed by the service provider.
The end customer can be allowed to poll via SNMP its CEs for RO information but the configuration, the backup, the monitoring is all performed from the service provider management systems. All those management systems (TFTP, syslog, image repository, monitoring system, steppingstone, NTP….) are located on the service provider management LAN.
The loopbacks of the CEs used for the management are part of the customer VRF routing table and each customer VRF has its own routing table. We have to bear in mind that isolation from one customer VPN to another customer VPN has to be preserved at any time. How can the service provider access in a simple and secure way CE loopback addresses that are part of different VRFs? Let’s solve it.
I’m using the following MPLS network to illustrate the solution:
The Management LAN 192.168.128.0/25 is connected to a management CE called MCE1. The Management CE is part of the VRF SP_Management.
The VRF configuration on the PE2 is the following:
The CE1-CustA is part of VRF Customer_A. The management IP address of CE1-CustA is the loopback0 10.255.255.1.
The CE3-CustB is part of VRF Customer_B. The management IP address of CE3-CustA is the loopback0 10.255.255.3.
The CE9-CustA is part of VRF Customer_A. The management IP address of CE9-CustA is the loopback0 10.255.255.9.
Those CE management IP addresses have to be unique among all the customers and therefore will be allocated from a range managed by the service provider. This range of CE management IP addresses cannot be re-used in the VPN of the customers. The management network of the service provider is routed in every customer VRF and thus cannot also be re-used in the VPN of the customers. It is therefore the responsibility of the Service Provider to clearly communicate this restriction to the VPN customers.
The configuration on the PE5 is the following:
The configuration on the PE6 is the following:
To enable the connectivity between the CE loopbacks and the network management LAN, we are first going to import in the VRF Customer_A and Customer_B all the routes with the route-target 1000 that are present in the management VRF SP_Management.
The configuration on the PE5 is the following:
The configuration on the PE6 is the following:
The network management 192.168.1.128/25 is now present in the BGP database and the routing table of VRF Customer_A and Customer_B.
Now we have to ensure that there is a route back from the management network to the CE loopbacks. We create a new route-target of 1001 which is going to be used for importing only the leaking routes in VRF SP_Management. The loopback0 of the CEs will be in exported and tagged with the BGP attribute of 1:1001 in addition to the BGP attribute of the route-target of the Customer VRF. The CE loopback of a customer VRF will therefore be present in the BGP database of this customer VRF and of the management network VRF.
The following configuration is applied on PE2:
The following configuration is applied on PE5:
The following configuration is applied on PE6:
We can now ping from the MCE1 to the loopback0 of the CEs:
Only the loopback of the CEs is routable. This looks safe and finished but there is still a denial of service possibilities!
First security breach: When an ICMP echo is sent to a network management LAN device from the Customer_A VRF with a spoofed IP address of 10.255.255.3 (loopback0 of a Customer_B CE), the ICMP echo-reply will be sent to the loopback0 of Customer_B CE. As a result, from the customer_A network, you could orchestrate a denial of service attack on Customer_B CE. This is not imaginable and unacceptable for a service which is supposed to hermetically separate the networks of different customers!
In order to mitigate this, we have to configure the RPF check on the PE to CE connections.
The following configuration is applied on PE5:
The following configuration is applied on PE6:
Second security breach: We cannot access the network management LAN from all other customer networks outside the Loopback0 because there is no route back for any other network in the network management VRF. However, the packets are still reaching the network management LAN and a denial of service attack could be orchestrated from a customer LAN to the network management system of the service provider. In order to avoid this, we will be hardening our design by placing an access-list on each CEs.
The following configuration is applied on CE1-CustA:
The following configuration is applied on CE3-CustB:
The following configuration is applied on CE9-CustA:
With this configuration in place, a service provider can in a secure way manage the CEs from a centralized management LAN.
Laurent Metzger
CCIE Data Center and R&S Instructor
CCIE #13538 (Data Center, R&S, and Storage) VMware, VCP5
About Laurent:
Laurent, a triple CCIE, has been working in the telecommunications industry for over a decade. He has extensive hands-on experience supporting and troubleshooting some of the largest networks in France, the Netherlands, Spain, and Switzerland, with a primary focus on MPLS/VPN service provider, and Cisco Data Center networks and technologies. Recently, he has been a Sr. Network Architect for highly-visible corporations in Switzerland, where he has designed, installed, supported, and trained on various data center technologies, including LAN-SAN convergence, virtualization, hybrid cloud solutions, and inter-DC communication. He will be responsible for teaching iPexpert’s CCIE R&S and CCIE Data Center classes throughout the US, London, Amsterdam, Brussels, Zurich, and Milan, and is also assisting in self-study workbook development and technical support.