Securely Managing CE Devices

In providing a managed CPE service, a service provider needs to have access to its customer CPEs. However, all CEs (including customer-owned CEs) should be under the management umbrella. A network management VRF, called the VPN_Network_Management, contains the circuit addresses of all the CE routes. Note that the term circuit implies the IP connectivity between these managed customer devices and the NOC. The service provider network management station(s) originates from this VRF. Conversely, each customer VRF should contain the service provider network management station(s) in order to permit bidirectional communication between the management workstation and the CE router. An example of the interaction between the CE router and the service provider network management station is shown in Figure 8-3.

Figure 8-3. Example Interaction Between CE Router and SP Network Management Station

NOTE

The CE should all have a unique loopback address from the ISPs management address space. In this example, the PE?CE circuit is part of the customer VPN (and customers may want to have this following their address plans. This is an area of negotiation between the service provider and the customer.

Management VRF Overview

By creating a management VRF, all CE routers can be managed from a single spot; and by virtue of the transitivity rule, which states that only routes originating from the VRF are exported, routing separation is guaranteed between CE routers. Figure 8-4 illustrates the importing and exporting of routes from the management VRF. All CE routers are easily identified, as they all should use a circuit address from the same service provider?managed address space.

Figure 8-4. P and PE Management via VRF Table

Example 8-1 allows connection to a service provider network management station. When provisioning VRFs, access to the network management stations would be part of the basic provisioning process, so what is shown in Example 8-1 would be typical across all VRFs.

Example 8-1. NOC Station Access to Customer VRFs

ip vrf VPN_Allied_Industries

 rd 64700:10600

 route-target export 64700:10600

 route-target import 64700:10600!! Export routes to the Management VRF!

 route-target export 64700:1!! Import Management host(s) only!

 route-target import 64700:10

In addition to the normal import/export route-targets for the VRF, two more route-targets are specified. The route-target export 64700:1 exports all routes from this VRF to the management VRF using the extended community attribute 64700:1. The route-target import 64700:10 imports any VPN-IPv4 addresses with the extended community attribute 64700:10, which identifies any management host(s).

Example 8-2 shows a management VRF example. This VRF is configured at the PE that connects to the service provider management subnet. Multiple PEs could provide the network management service for redundancy.

Example 8-2. Network Management VRF Configuration

ip vrf VPN_Management

 rd 64700:1

 import map IN-Management

 export map OUT-Management

 route-target export 64700:1

 route-target import 64700:1!! Only allow CE circuit addresses into VRF!ip prefix-list CE-Circuits seq 10 permit 172.24.6.0/16 ge 30ip prefix-list CE-Circuits seq 10 permit 172.24.7.0/16 ge 30!and so on...!route-map IN-Management permit 10

 match ip address prefix-list CE-Circuits!! Set Management Workstation route to 64700:10!route-map OUT-Management permit 10

 match ip address 20

 set extcommunity rt 64700:10!! Access List to identify management hosts (one line for each host)!access-list 20 permit 146.171.66.90 0.0.0.0...!! Set a static route to Management workstation(s)!ip route vrf VPN_Management 146.171.66.0 255.255.255.0 <NH Int> <NH IP>!! Enter other routes to Management hosts...

Management VRF Details

This VRF uses the service provider?specified "well known" RD and RT of 64700:1. In addition to the normal import/export route-targets for the VRF, two route-maps are specified: IN-Management and OUT-Management.

The IN-Management route-map limits any imported addresses to that of the circuit address space. In other words, the address prefix must be a subnet 30 bits long, and it must begin with 172.24.6.0, 172.24.7.0, and so on?the address pools to which all CE circuit addresses belong.

NOTE

In the previous example, all VPN customers must accept that these 172.24.x.y networks cannot be used by them in the VPN.

This concept is applicable for a certain number of VPNs; for example, when selecting ranges from all three RFC 1918 networks, it helps to minimize the probability of address conflicts. However, with a large number of (larger) VPNs, this concept may be limiting.

Using official addresses could help for scalability, but this is no guarantee because official addresses could be "stolen."

Therefore, the network architect must be aware of these issues when planning the address range for service provider network management access to customer VPNS.

All other routes in the customer VRF are excluded. The service provider could poll a CE hub or switch by simply providing it with 172.24.x.x address, which could be included in the VRF.

The management VRF is connected to an interface that could originate from many subnets, in addition to the management subnet. For purposes of example, let's say the management subnet is 146.171.66.0. To guarantee that only the host addresses of management workstations are included in the customer VRF, static routes should be used to identify each management address individually.

The static route command specifies the management VRF, the host address, the next hop interface, and the next hop address.

The OUT-Management route-map sets all management host addresses (those that match the access-list 20) to the extended-community attribute of 64700:10, which is then imported into the customer VRF with a corresponding import map.

As an example, the management workstation has an IP address of 146.171.66.90. In the above configuration, a static route is added for each management workstation so we can manage routes down to individual hosts. This prevents CEs from accessing anything else on the management subnet except for the specific hosts.

If these host address routes are redistributed to a CE via a routing protocol such as RIPv2, the CE may re-advertise the route back to the PE in a summarized form even though split-horizon is enabled. (Do not send routes out an interface you received them on.)

For example, if the host route 146.171.66.90 255.255.255.255 is advertised to a CE with auto-summary enabled, that route will be summarized to a B-class address of 146.171.0.0 255.255.0.0 and advertised back to the PE.

The split-horizon process will allow the route to pass because it is not the same as the route that was received.

Two ways to avoid this problem are to

• Turn auto-summary off at the CE
• Use route distribution filtering at the PE

NOTE

We have presented a generic overview of CE management in terms of the link technology implemented. However, there are potentially a variety of emerging applicable configurations, such as Frame Relay, ATM, or VLAN encapsulation on the link, and a VRF on the CE that retains the management (logical) link, thus resulting in a completely separated VPN data link. This solution can avoid address conflict, and the management security is consequently higher due to the VPN separation. We recommend that users commence with a generic solution when launching a Layer 3?based service and consider deploying a solution that results in additional separation of the VPN when deploying a Layer 2?based service.