CE-Specific Router Security and Topology Design Considerations

The one key point to emphasize when referring to the customer edge (CE) router is that it is an untrusted device from the service provider's perspective. However, the customer's concerns include the following:

  • Reliable transfer of data and routes, unhindered to all appropriate endpoints

  • Ensuring that data and routes are not leaked to other service provider customers

  • Ensuring that the service provider is attaining committed service-level agreements (SLAs) in terms of availability and throughput

  • Expeditious troubleshooting of a network problem by the SP

  • Expeditious problem analysis by the customer

Clearly, the type of physical network that is selected to interconnect the CE to the PE offers differing levels of resilience to intrusion and redirection. A serial point-to-point facility is difficult to subvert, and intrusions are usually noticeable. When this type of serial connection is interrupted, alarms are raised quickly and the two endpoints are difficult to masquerade.

Private virtual circuit (PVC)?based networks, such as Frame Relay and ATM, are somewhat less resistant in that they are generally controlled by software-based virtual circuit switching and can be readily misswitched or duplicated. However, even these facilities typically use a serial point-to-point connection between the CE and the telecommunications central office (telco), making intrusion difficult outside of the telco realm.

Ethernet-based facilities are most readily compromised in that it is relatively easy to insert a promiscuous monitoring device somewhere in the path. Note that the physical links from the CE to the central office remain directly cabled, and consequently intrusion still generally requires telco access.

Of course, it is possible to insert equipment into these physical plants, but the level of expertise required to identify the correct facility, access the physical structures, and unobtrusively insert illicit systems is very high and not readily performed by any but a determined and well-funded attacker.


So what is the security recommendation for a CE-to-PE circuit?

One comment about Local Loop Security, such as a point-to-point connection between the CE and the PE where the underlying transport is SDH, which is typically not point-to-point on the physical map: The deployment of 1+1 protection in metropolitan area networks automatically duplicates the traffic depending on the configuration itself. Ethernet installations, for example, may be based on Ethernet switch connections at customer locations that are organized in rings going from a Customer A site to a Customer B site to a Customer C site, and so on. These switches consequently have physical access to the Ethernet trunks. It is therefore essential to be cognizant of the physical security plant factors when implementing a CE-to-PE link.

The more significant issues with shared physical-interface accesses (PVC-based or VLAN-based) would be managing the offered traffic loads so that one VPN cannot impact the operational characteristics of other VPNs being terminated on the same port. To guarantee the performance of the VPNs per SLA agreements, it is necessary to either provision much greater bandwidth on the access port than the expected load or to manage the bandwidth available using policing and shaping mechanisms. Typically, this is done by offering a limited set of performance options (say four or five classes) to customers when they request the service.

Policing controls are then applied to the interfaces based on these predefined classes of service to meet the expectations of the customer. In an unmanaged VPN, where different entities control the CE and PE, and consequently neither can be guaranteed to stay within the expected operational characteristics, these controls would need to be applied to both routers to ensure that offered loads do not impact the applicable networks.

MPLS VPNs offer a few network topology design options to address varying customer deployment needs:

  • Central services topology? In this scenario, either the customer or the SP is providing a service at a centralized site, which can then be accessed by various VPN entities. For example, the SP may be providing a storage area network (SAN) facility or perhaps an IP telephony CallManager service. This necessitates judicious use of MPLS VPN route targets to provide connectivity to these facilities without leaking access between VPNs. Note that the servers providing such support must be carefully managed so that access to these devices themselves will not compromise the various VPNs.

  • Hub and spoke topology? In this design, a particular customer site is designated as the focal point for user traffic and is also likely to provide corporate services to other sites. Examples may be server farms or Internet access. These types of implementations have security needs as well.

  • Any to any topology? When traffic profiles indicate that sites need to freely communicate with one another, any-to-any connectivity may be appropriate. This is the simplest topology to implement from an MPLS VPN perspective in that the import/export policies of route targets are the same at all sites within a given VPN.

An example of security concerns for the above topologies is controlling services, which may be specific to particular corporate groups or providing firewall/NAT mechanisms for Internet access such as assuring that access to a customer's VPN is not compromised. However, MPLS introduces no additional concerns with respect to managing corporate traffic flows in a hub-and-spoke design and, as such, typical network planning approaches can still be applied.

Managed CE Security Considerations

In a VPN managed by a service provider, the SP also manages the CE equipment. That is, the SP's control extends all the way out to a point of presence within the customer's Interior Gateway Protocol (IGP). This section recommends best-practice deployment guidelines for the customer edge implementation. When a service provider manages a customer edge, as such, the SP has full control of the CE configuration, including:

  • Access to the router itself for configuration and fault diagnostics

  • Interaction with the rest of the customer's IGP or routing instance

  • Interaction with the SP's PE routing mechanism; that is, the routing instance between the CE and PE

  • Gathering customer statistics as required for reporting

This model provides the SP with the greatest degree of control over the potential impact of customer operations on the SP's network itself as well as greater control over issues that may arise affecting other SP customer virtual private networks (VPNs). The SP has a single backbone infrastructure for multiple sets of customers.

Conversely, this arrangement implies some degree of trust on the part of the customer, as follows:

  • Customer permits another company (the SP) to have access to its IGP

  • Customer trusts the SP to map its network communications solely to endpoints approved by the customer

  • Customer assumes that the SP will provide the majority of fault analysis and resolution activity (since its own access is somewhat limited) because the service is managed by the SP

We emphasize, however, that the CE is always untrusted, and therefore the service provider must secure its network against attacks that may originate from the CE. In a managed service, the service provider network management station requires access to the CE, and therefore the service provider network management station must also implement security measures such that the network operations center is not compromised.

Unmanaged CE Security Considerations

There may be environments where the customer demands a call for some degree of sharing of responsibility between the SP and itself. In these situations, the span of control with respect to these parameters may shift from one direction to the other. A customer may have an unmanaged VPN that is distinguished by the notion that the CE router is owned and controlled by the customer. While the term unmanaged VPN is, strictly speaking, a misnomer (and perhaps indicative of a more SP-centric perspective), it is widely accepted to mean a network where the customer manages the CE router itself rather than the SP. In this scenario, the demarcation point between the SP and the customer is usually the remote end (the customer premise end) of the local loop where the service provider offers or manages the leased line as well customer premises. The customer has full control of the CE router's configuration and interacts with the SP's network over some mutually agreed arrangement between the SP and the customer.

The SP may have some exposure of the SP network operation to the customer's configurations of the CE router. As such, the SP needs to take additional steps to ensure that the SP network operations are not disturbed by changes in the customer network environment or CE router setups.

However, this operative mode may be more palatable to customers who desire to maintain the following:

  • Complete control of their IGP

  • Additional information access to fault analysis and troubleshooting

  • Minimized exposure of the customer network to the SP

From the SP's perspective, the unmanaged VPN environment changes the span of control significantly. This approach impacts the SP in a number of ways, including the following:

  • The need to protect the Layer 3 interconnect between the CE and PE

  • The possible requirement to protect the Layer 2 interconnect (if shared)

The requirement for a clear definition of SLA-impacting responsibilities due to changes in the span of control and the need to closely interact with customers in the event of problems requires additional level of security awareness at the PE router because the CE is no longer under its explicit control.

CE Data Plane Security

Generally for the CE router, securing the data plane is pivotal for overall security. The Unicast Reverse Path Forwarding (uRPF) lookup feature should be enabled on each interface of the PE routers' CE-facing interfaces and on the CE routers' PE-facing interfaces. uRPF attempts to verify that the source of an incoming packet is accessible via the interface from which it was received (by checking the CEF tables) prior to switching the packet through. uRPF is currently available in two general operating modes:

  • Loose? In this mode, if the incoming packet's source address is reachable via any interface in the router, the packet is forwarded. Loose mode is primarily applicable in network cores.

  • Strict? In this mode, the packet must enter via the exact interface through which the source address would be reached prior to forwarding. Strict mode is intended for use at the edges of a given network.

Since PE and CE routers implement the network edge in an MPLS/VPN context, strict mode would be the appropriate choice. However, if the connections are dual-homed, then the uRPF mechanism must be relaxed somewhat by using loose mode.

In the next section, we review provider edge security recommendations as part of the CE relationship for security. An essential aspect of CE security is to consider the overall service relationship to the provider, such as managed vs. unmanaged and the associated topological factors, whether operating in hub and spoke, full mesh, or the Internet access provisioning model.