Layer 2 and Unmanaged VPN Service Considerations

Clearly, the types of physical network available to interconnect the CE and PE offer varying levels of resilience to intrusion and redirection mechanisms. A serial point-to-point facility is difficult to subvert and intrusions are usually noticeable. When a serial connection of this nature is interrupted, alarms are raised quickly and the two end points 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 mis-switched or duplicated. However, even these facilities typically use a serial point-to-point connection between the CE and the telecommunications (telco) central office, making intrusion difficult outside of the telco realm.

Ethernet-based facilities are most readily compromised in that inserting a promiscuous monitoring device within the network is relatively easy. The physical links from the CE to the central office remain directly cabled and consequently intrusion still generally requires telco access.

Of course, you can 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 the most determined and well-funded attackers.

The more significant issue with shared physical interface accesses (PVC-based or VLAN-based) is managing the offered traffic loads so that one VPN cannot impact the operational characteristics of other VPNs that are terminated on the same port. To guarantee the performance of the VPNs per SLAs, you must either provision much greater bandwidth on the access port than the expected load or manage the bandwidth available using policing and shaping mechanisms. Typically, this is done through the offering of a limited set of performance options (say, four or five classes) to the customer when he requests 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 need to be applied to both routers to ensure that offered loads do not impact the applicable networks.

Design Option Examples

MPLS VPNs offer several network design options to address varying customer deployment needs. These include the following:

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

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

  For example, controlling services that might be specific to particular corporate groups or providing firewall/NAT mechanisms for Internet access. 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.

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

In the service providermanaged VPN environment, the CE is managed by the service provider. That is, the SP's control extends all the way out to a point-of-presence within the customer's IGP. This section recommends best practice deployment guidelines for the customer edge implementation. When a service provider manages a customer edge, 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 mechanismthat is, the routing instance between the CE and PE

• The gathering customer statistics as required for reporting

This model provides the SP with the greatest degree of control over the potential impact of the customer's operations on the SP's network itself, as well as greater control over issues that might arise and affect other SP customer VPNs. The SP has a single backbone infrastructure for multiple sets of customers.

In addition, this arrangement implies some degree of trust on the part of the customer:

• The customer permits another company (the SP) to have access to its IGP.

• The customer trusts the SP to map its network communications solely to end points approved by the customer.

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

Additionally, in some environments the customer demands a call for some degree of sharing of responsibility between the SP and the customer. In these situations, the span of control with respect to the previously mentioned parameters can shift from one direction to the other. A customer might have an unmanaged VPN in which an unmanaged VPN is distinguished by the notion that the CE router is owned and controlled by the customer. Although 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 in which the customers manage the CE router themselves rather than the SP. In this scenario, the demarcation point between the SP and the customer is usually the dataset at the customer premises (although the communication facility provider might not be the Layer 3 MPLS VPN provider). The customer has full control of the configuration of the CE router and interacts with the SP's network over some mutually agreed upon arrangement between the SP and the customer.

The SP might 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 its network operations are not disturbed by changes in the customer's network environment or CE router setups.

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

• Retain complete control of their IGP

• Provide additional fault analysis/troubleshooting information access

• Minimize 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 these:

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

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

• There is a requirement for a clear definition of SLA responsibilities between the SP and enterprise customer, due to changes in the span of control. This requirement is a result of the need for the SP to closely interact with the customer in the event of problems that require an additional level of security awareness at the PE router because the CE is no longer under the explicit control of the service provider.

Carrier's Carrier Network and Inter-Autonomous Considerations

Carrier's Carrier (CsC) networks can be viewed as a special case of unmanaged VPNs. In these environments, a hierarchy of service provider operators is used to provision end-to-end connectivity for a customer, where the SP who is directly interfacing with the end customer might not have facilities in place to meet all of the customer's needs completely. As an example, a smaller SP might have been selected to provide MPLS VPN services for a given customer. However, although the particular SP might possess direct facilities to meet the customer's needs at the end points of the network, the SP might not be capable of providing intercontinental or transoceanic facilities. As such, the SP might contract with a carrier who has such networking available through a CsC type of arrangement. Consequently, the top-tier SP views the second-tier SP as an unmanaged VPN client, whereas the second-tier SP might have either an unmanaged or a managed arrangement with the end customer. CsC is usually accomplished by the higher-level SP mapping the secondary SP's traffic through some form of a VPN-LSP path. As such, one essentially has end customer traffic mapped into a VPN by the first SP and then again into another labeled hierarchy by the second SP.

There is also a variation on this approach, usually referred to as an Inter-AS network, in which the interconnection between SPs is purely a label-switching mechanism and the end point peering is still accomplished between the CE routers.

CsC network environments present an additional set of interconnection concerns because the following connectivity arrangements are present:

• Connections between customer and provider

• Connections between a provider and its carrier

• Routing and label implementation arrangements between the two SP

In this situation, SLA and security requirements exist amongst three entities, rather than the typical two.

This approach is generally favored by customers who do not want to operate a Layer 3 network or who feel that they can simply use the SP's expertise and support staff to operate the Layer 3 environment. The notion of an SP edge router interconnecting with a customer's network at a Layer 2 level is increasingly popularin particular, in metro environments. In this design, the customer presents a Layer 2based interconnect, possibly one or more VLANs, to the PE Layer 3 network. In effect, the SP PE router is the routing kick-off point for Layer 3 service for the customer. The customer has no Layer 3 routing occurring within his own network. Such an implementation allows the customer to focus on the pure switching component of networking his campuses.

To secure this type of connectivity arrangement, several considerations need to be addressed, besides the typical Layer 3 interconnect.

In the case of a LAN-based, Layer 2 interconnect, the PE router must maintain ARP entries for all the end system addresses that are reachable beyond that interface.

The number of entries can be considerable depending on the size of the connected site, and they can considerably impact router CPU and memory. It is generally thought that an excess of 20,000 ARP entries can lead to issues on the connected router; as such you might want to segment a large campus.

In addition, the fact that no Layer 3 CE router exists in this scenario means no reasonable mechanisms are available to ensure that the only accesses into the VPN from this interface are those authorized to access the VPN. That is, given some large number of hosts on this Layer 2 domain, it is difficult, if not impossible, to create access controls that can ensure that only the appropriate traffic sources existthe Layer 2 domain must be a trusted network space. This must be an operational consideration of the entity controlling the Layer 2 networkbe it the customer or the SP. Intrusion into the network at this point gives access to much, if not all, of the entire VPN (depending on the VLAN arrangements).

In addition, because this is a Layer 2 environment, no Layer 3 opportunities are available for controlling DoS issues beyond the PE edge. If an assault or intrusion reaches the Layer 2 space, it must be dealt with at that level. For example, a broadcast-oriented attack would have an immediate impact on all the nodes within the same Layer 2 domain.

The SP must also determine the degree of interaction it wants to have with respect to L2 operationsfor example, spanning tree termination and Cisco Discovery Protocol (CDP functions, QoS, trusted ports, and so on).

As MPLS VPNs have become more popular, the need to provide connectivity across different SP or autonomous system boundaries has become apparent. Large enterprise customers are often multinational and, because of their geography, might not always be able to get their full VPN connectivity through a single provider. Even if connectivity can be achieved via a single SP infrastructure, the topology of the network might be split into multiple autonomous systems.

The Inter-AS suite of solutions was introduced to facilitate such connectivity requirements. The three most popular choices are referred to as option A, option B, and option C; they are described in Section 10 of RFC 4364.

Option A is an IP relationship between two AS domains commonly represented by back-to-back VRF constructs.

Option B has become the option of choice for inter-provider connectivity where two SPs under separate authoritative control peer with the intent of directly exchanging VPNv4 routes. Option C, on the other hand, has become the option of choice for Inter-AS connectivity. in which multiple autonomous systems under the same authoritative control peer use route-reflectors and exchange BGP next-hop addresses across the Inter-AS links.

Whichever connectivity model is chosen, the SP must choose how to provision the import/export policies at the PE routers, ASBR routers, and route reflectors (if applicable). The route-target values used to implement these policies might or might not be the same in each autonomous system. Because of this, three different schemes can be adopted for the import/export policies:

• Scheme 1 Each SP uses its own route-target value and rewrites the incoming route-target value from an adjacent provider using the RT-rewrite feature at the ASBR router. This enables the SP to configure its PE routers with local route-target values, regardless of whether the VPN is connected to multiple autonomous systems. If an existing VPN requires connectivity via another autonomous system, the SP need only know the route-target value used by the adjacent provider and then rewrite this to the local value at the ASBR boundaries.

  Those SPs that prefer a centralized filtering and provisioning methodology generally favor this scheme because they are able to make all the changes at the ASBR routers rather than the PE routers. However, this scheme complicates the filtering configuration and can compromise the security of the local VPNs if the wrong route-target value is configured. This scheme is therefore not recommended unless the correct provisioning tools are in place.

• Scheme 2 Each SP uses the same route-target values for each VPN that crosses autonomous system boundaries. This scheme requires that the route-target format consist of one or other of their autonomous system numbers. This scheme is not recommended for two reasons: (1) Using a route-target value, which belongs to the neighbor provider, might conflict with the filtering scheme used by the neighbor provider; and (2) it is not very practical because the majority of VPNs exist prior to Inter-AS becoming a requirement.

• Scheme 3 Each SP configures its PE routers with route-target import statements that match the route-target export statements for a given VPN within the adjacent autonomous system. This is the recommended scheme because this scheme doesn't require the neighbor provider's route-target value to be associated with the local VPN prefixes. This scheme, however, might require the provisioning tool to update the VRF configurations at all the relevant PE routers whenever the VPN becomes an Inter-AS VPN. Most deployments commence with option A or back-to-back VRFs and move to option B for more scalability. Option C can be deployed in an Inter-AS model in which the provider is under the same trust and administrative domains. In the next section, we identify security attributes to secure the customer edge router connection to the provider edge device.

Customer Edge Router Security Considerations

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 router's CE-facing interfaces and on the CE router's PE-facing interfaces. RPF 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 operating modes:

• Loose In this mode, if the incoming packet's source address is reachable through any interface in the router, the packet is forwarded.

• Strict In strict mode, the packet must enter via the exact interface through which the source address would be reached prior to forwarding.

The two modes are intended for operation at different points of the network. Loose mode is primarily applicable in network cores, whereas strict mode is intended for use at the edges of a given network.

Because 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, the RPF mechanism must be relaxed somewhat by using loose mode.

Various QoS mechanisms can be used to protect the PE and CE router interfaces from undue traffic volumes. A higher-than-expected traffic flow might be due to a deliberate DoS assault or simply be the result of a misconfigured device somewhere within the network. However, because these mechanisms are inserted directly into the forwarding path, they do have an impact on packet forwarding ratesespecially on software-based platforms. As such, these features should be applied with care and due consideration given to the environment in which they are to be applied.

The PE is within the SP domain and could have multiple customer relationships; for example, multiple customer VPNs might be provisioned on a single PE. From a security standpoint, ensuring complete privacy between various customers is of utmost importance for the service provider. Hardening the control and data plane for a PE is required as a security best practice guideline. To manage forwarding information between the PE and CE, some sort of Layer 3 routing must be performed. There are, in essence, two options: static routing and dynamic routing. The pros and cons of each are well understood in Layer 3 routing environments and apply equally to an MPLS VPN network. However, an MPLS VPN PE-CE connection involves a relationship between separate corporate entities, so due consideration must be given to the security and stability implications of such interconnections. For example, the concerns of interconnecting two entities can include the following:

• The PE or CE might be subject to floods of routes from its neighbor.

• Instabilities in the routing protocol processes can adversely affect CPU utilization.

• Invalid routes injected into either network space can cause traffic flows, resulting in suboptimal or insecure pathing.

These issues are no different from those faced by most Internet service providers (ISP) today, although ISPs usually do not use IGPs in their interconnection points. They typically rely solely on BGP for this purpose. MPLS-VPN customers might desire the use of mechanisms other than BGP; as a result, consideration needs to be given to the requirements this might impose. For data plane security, as in the CE, the use of uRFP is recommended for the PE. The uRPF lookup feature should be enabled on each interface of the PE router's CE-facing interfaces and on the CE router's PE-facing interfaces. RPF 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.

Implementing security guidelines for both the PE and the core as per Cisco ISP Essentials (ISBN 1-58705-041-2, Cisco Press) is highly recommended.