Layer 2 Security Considerations

Security is often overlooked at the lower layers, yet lack of security at these layers might jeopardize the security of all traffic passing on the higher layers unless some form of end-to-end security is used (for example, encryption or authentication). Consider an enterprise Ethernet switch, to which several PCs are connected, as well as routers. There are a number of attack forms that permit users of PCs on that switch to redirect traffic to themselves, with so-called man-in-the-middle attacks.

Here's one attack example: The malicious user sends a flood of Address Resolution Protocol (ARP) messages to the broadcast domain. The switch keeps track of Layer 2 (MAC) addresses and notes which port they are on. With each ARP packet, the user randomly changes the MAC address, thereby slowly filling the memory of the switch with fake entries. Once the address table of the switch is full, the switch will start broadcasting all packets from all ports to every port in the virtual LAN (VLAN). This way, the attacker sees all data traffic going over the switch.

Some hacking tools available on the Internet allow someone to carry out this attack and then steal any session that is established over the switch. This is one of the reasons why telnet is not recommended. Secure Shell (SSH) prevents this problem by providing end-to-end security through authentication and encryption.

There are a number of attack forms of this type. (Refer to specific security literature for details on these attack forms.) There are also forms and tools for preventing all of these attacks: for the attack just described, for example, there is the port security command, which limits the number of MAC addresses on a port to a predefined level.

Despite all the attack forms, Layer 2 can be provisioned securely. Security is an important consideration that is often overlooked when designing Layer 2 infrastructure.

Figure 4-30 shows an example of an interconnection between two autonomous systems, provided over an Ethernet switch at an Internet Exchange Point (IXP).

If the hacker is connected to the same VLAN as the ASBRs, security of all Inter-AS VPNs is jeopardized. The hacker could, for example, insert on Layer 2 spoofed labeled packets, which appear to come from one ASBR and go to the other. This way, the hacker could insert traffic into any Inter-AS VPN. Essentially, all attack forms on Layer 2 would be applicable in this design, so that the attacker could be the man-in-the-middle for any traffic stream. Confidentiality would also be lost for all data on this path.

Layer 2 security must be considered on every shared connection. For example, if two CEs of different VPNs connect to a single PE over an Ethernet switch, it would be theoretically possible to put all CEs into a single VLAN and provide separation through some form of tunnel, such as generic routing encapsulation (GRE). If the two CEs are in the same VLAN and if the switch is not well secured, separation between those VPNs might be broken at Layer 2. RFC 2547bis explicitly states for this case:

"In the case where a number of CE routers attach to a PE router via a LAN interface, to ensure proper security, one of the following conditions must hold:

The Inter-AS scenario is a special case: Many service providers are peering with each other on IXPs and might consider using this connection for Inter-AS also. This is not secure! As previously described, a third party could introduce crafted packets into VPNs at the IXP.