C6 VPLS and VPWS Security Overview

The fundamental security considerations for VPLS and VPWS constructs are to assure the integrity of the U-PE configurations and to prevent DoS and resource starvation attacks against the U-PE, N-PE, and PE-AGG devices. Figure 7-5 shows the untrusted zone, such as floor (of a building) customer switches to an U-PE (or customer UNI to a service provider component). The trust is from a service provider perspective because it is assumed that the U-PE, N-PE, and PE-AGG devices are within the service provider's control. We will introduce types of attacks for these services and the appropriate defenses in this section; the attack details and defense mechanisms will be discussed later in this chapter.

Figure 7-5. Metro Ethernet Security Mode

[View full size image]


Figure 7-5 depicts the trusted and untrusted zones for VPLS-based service.

Attack mechanisms may be categorized as follows:

  • MAC attacks (content-addressable memory or CAM overflow)

  • Broadcast/multicast storm attacks

  • VLAN hopping or Dynamic Trunking Protocol (DTP) attacks

  • Spanning tree attacks

  • DHCP rogue server attacks

  • Hijack management access

Table 7-1 summarizes these attacks and the appropriate defensive responses. This table is the foundation of our security discussion in this chapter.

Table 7-1. VPLS/VPWS Attack Points and Defensive Actions

Attack

Defensive Features/Actions

MAC attacks (CAM table overflow)

Port security, per-VLAN MAC limiting

Broadcast/multicast storm attacks

Storm control

VLAN hopping, DTP attacks

Careful configuration (disable autotrunking, used dedicated VLAN-ID for trunk ports, set user ports to nontrunking, VLAN 1 minimization, disable unused ports, and so on)

Spanning tree attacks

BPDU guard, root guard, MD5 VTP authentication

DHCP rogue server attack

DHCP snooping (differentiate trusted and untrusted ports)

Hijack management access

Secure variants of management access protocols (not telnet, etc., but SSH and out-of-band management), disable password recovery, encrypted passwords

Proactive defense

Deploy MAC-level port security, wire-speed ACLs, 802.1x


NOTE

A constantly flapping port may cause LDP generating/withdrawing labels and denial of service to the protocol stack.

Note that the IETF (Martini) drafts permit a copy of the VLAN priority fields into the MPLS EXP, and we recommend awareness of this fact.


Physical Interconnection Option Details

The three scenarios previously described can be physically structured in a number of ways:

  • Layer 2 end-to-end with no customer VLANs, essentially "port mode" operations. Layer 2 end-to-end with customer VLANs where customer VLANs are transported to customer remote sites, either transparently (ingress/egress VLANs are consistent or customer VLANs are modified by the service provider transport network). Service provider Layer 2 transport of Layer 3 customer edge facing the service provider Layer 2 MPLS network is a router similar to the typical Frame Relay model.

  • Service provider Layer 3 interconnect to Layer 2 customer edge is an example of a customer network using a service provider for Layer 3 routing.

D1 SP Interconnect Models

Interconnect models include the following types:

  • Single PE? The CE device is connected directly to the SP's PE (aka Network-PE [n-PE]), which implements full EoMPLS functionality and provides access facilities, encapsulation/decapsulation, and transport over the core.

  • Distributed PE? The SP locates an extension of its PE edge device on physical premises that are not directly under SP control (referred to as a "Provider Edge?Customer Located Equipment (PE-CLE)" or "User-PE (U-PE)") and performs part of the EoMPLS interconnect operations?namely, access facilities and some encapsulation mechanism, with the N-PE providing core access.

    This allows the service provider to multiplex many customers' sites over a shared infrastructure?perhaps a fiber ring. In this case, it becomes imperative that the U-PE be very tightly secured because it is exposed in a location where the SP may not be able to monitor access.

NOTE

Recommendation

We recommend that no service provider edge (PE) router be located at a customer premise because such an installation exposes the service provider to unwelcome access. Further, in order to mitigate against control plane spoofing, examples of protocols that should never be exposed to untrusted routers include IGP, BGP, LDP, and RSVP-TE.


The physical structure of the SP access network generally takes the following forms:

  • Point-to-point links including hub-and-spoke and tree topologies, where a CE is connected with a point-to-point link directly to an N-PE or to an aggregation PE that grooms some set of links into point-to-point connections to the PE. Security considerations reflect the degree of separation inherent in a point-to-point network layout.

  • Ring topology, where customer edge devices are connected to User provider edge (U-PE) devices that are interconnected in a ring formation with an N-PE node providing access to the service provider core.

In this scenario, the shared medium transports a variety of Layer 2 VLANs from a single customer with several physically colocated sites. In addition, this ring may also support VLANs from other customers that the SP can service in that same geographical area. As such, the design needs to address the possibilities of overlapping VLANs, where different customers may have the same VLAN ID and are unwilling to change them. This requires the use of some sort of tag prepending to the packets prior to its forwarding through the shared medium. This can be accomplished either through MPLS tagging of the frames (requiring an MPLS-aware universal provider edge device) or through QinQ VLAN tagging (an additional IEEE 802.1Q VLAN tag is inserted above the customer's VLAN tags).

The QinQ approach is typically used today because the low-cost, MPLS-aware User provider edge devices are still not widely available. As such, the upper VLAN tag that the SP defines must be carefully administered by the SP so that misdirected traffic scenarios do not occur.

D3 Metro Ethernet Model

A typical implementation of an EoMPLS network is the Metro Ethernet Model. In this topology, the service provider extends an Ethernet connection to the customer's network as an access medium to the Layer 2 service being offered. This provides a relatively high bandwidth interconnect at a low price point. However, in consideration of the ease with which Ethernet LAN networks can be compromised if access to the network is gained, it is necessary to be aware of the associated risks and attempt to minimize them.

If intruders can gain access to the Ethernet facilities themselves, an Ethernet hub/repeater can be readily inserted into the network, allowing for complete observation of transit data, man-in-the-middle attacks, and denial of service assaults. As such, steps should be taken to minimize this risk.

Due to the relatively large number of access facilities in a typical service provider network, identifying the appropriate connection to compromise is quite difficult. Ensuring that control traffic exchanges between the customer edge devices are authenticated can greatly reduce the likelihood of man-in-the-middle intrusions. However, simple monitoring of transit traffic is still readily accomplished and if data sensitivity demands it, encryption of the traffic should be considered. The service provider and customer should monitor the status of the interconnect link and investigate any logged circuit anomalies in a proactive manner.