The previous posts I’ve made around access layer security features have been somewhat more focused on protecting the network itself from attack. One of the biggest security issues with Ethernet / IP is that there are no built-in protections against one device “impersonating” another by spoofing an IP address or ARP responses. Without using additional functionality to protect against this, any user on a subnet can trivially intercept traffic from other hosts in that subnet by doing ARP poisoning. Also, there is nothing to prevent a host from sending traffic from a different source address than it is actually assigned, and nothing to prevent someone from manually setting a static address on their device to “squat” on an address or bypass any DHCP restrictions that might be in place.

Fortunately, many modern business class switches have features that can protect against these access layer attacks. I’ll talk about the Cisco IOS features in this blog post. These features are intended for semi-untrusted access networks that end users connect to. Most of these settings will cause problems in a data center environment, and really shouldn’t be necessary there. You should trust the devices that you are placing in a data center.

DHCP Snooping

The DHCP snooping feature allows a switch to inspect DHCP requests and responses.

By itself, DHCP snooping prevents a user from running an unauthorized DHCP server. It will only allow DHCP responses from ports that have been marked as trusted. It also prevents users from flooding the DHCP server with requests, by rate limiting DHCP requests on user facing access ports.

Arguably more importantly though, DHCP snooping builds a database that tracks to IP to MAC to interface associations. This database is used by several other features, like ARP inspection and IP source guard.

DHCP snooping should be enabled globally, and then for each specific VLAN that users connect on:

ip dhcp snooping vlan 3
ip dhcp snooping

Uplink ports that face the DHCP servers should be marked as trusted:

! uplink port
interface GigabitEthernet0/1
  ip dhcp snooping trust

If you wish to rate limit DHCP requests, this can be configured individually on access ports:

! user port
interface GigabitEthernet0/2
  ip dhcp snooping limit rate 1

And you can view the address bindings that the switch has captured:

show ip dhcp snooping bindings

Dynamic ARP Inspection

Dynamic ARP inspection (DAI) uses the information that DHCP snooping gathers to apply several additional critical protections. It checks ARP packets to ensure that they match what the switch knows from the DHCP snooping database. You must have DHCP snooping enabled to use DAI.

DAI rate limits ARP packets. If the limit is exceeded, the port will be error disabled. Secondly, because it verifies the IP address in ARP responses with the DHCP snooping database, it effectively stops someone from manually assigning a static IP address to bypass DHCP. It also will drop bogus gratuitous ARP responses that are seen when someone it attempting an ARP poisoning attack.

DAI should be enabled for specific VLAN’s. Uplink ports must be configured to be “trusted” so that devices with a static IP elsewhere in the network (like the default gateway for the subnet) will continue to work:

ip arp inspection vlan 3

! uplink port
interface GigabitEthernet0/1
 ip arp inspection trust

This is definitely a really useful feature that you should try to use where possible on user facing access layer networks.

Source Guard

IP source guard also uses the information gathered via DHCP snooping. It enforces the IP to port mapping. It can be used along with DAI or separately. Source guard effectively creates an ACL and applies it on the physical port.

So, if a host attempts to send an IP packet from a source IP that is different than the source IP that the DHCP server assigned to the host on that port, IP source guard will block it. This also prevents a user from using a static IP address.

IP source guard is enabled individually on each user facing port. Don’t enable it on uplinks that go to other network devices.

! user port
int gi0/3
  ip verify source

To show the IP to port bindings that the switch knows about, use:

show ip verify source

Unicast RPF

Unicast reverse path forwarding (URPF) is not really an Ethernet specific feature, and not specific to user facing access networks. It is definitely useful in other parts of the network as well.

URPF works at the IP level to make sure that a packet is received from an interface that has a valid route back to the source IP on the packet. You would enable URPF on the layer 3 interface on the routers on a particular subnet.

URPF has two different modes - strict and loose. Typically most networks will have multiple paths to a given subnet because of redundant connections. Strict mode RPF checks if the interface the packet was received on is the best route for traffic back to the subnet. Loose mode URPF just ensures that there is a valid route in the table back to the originating subnet, regardless of which interface the route references.  Loose mode prevents traffic from being sourced from addresses that aren’t in the routing table at all.

URPF loose mode can be configured on a Layer 3 interface like this:

int vl3
 ip verify unicast source reachable-via any

Strict mode is configured like this:

int vl3
 ip verify unicast source reachable-via rx

IPv6

IPv6 introduces some new challenges for these features. While IPv6 can use central DHCP servers (DHCPv6), IPv6 hosts also can choose an IP address on their own through auto-configuration. IPv6 also uses neighbor discovery (ND) in place of ARP, and has router advertisements (RA’s) that can also be spoofed by hosts to intercept traffic.

Vendors have developed some features for IPv6 that are similar to their counterpart IPv4 access layer security features. RA guard prevents end user ports from transmitting router advertisements. ND inspection works similar to DHCP snooping to build a mapping of IPv6 addresses to ports.

There is also a Secure Neighbor Discovery protocol, called SeND that uses certificates to help secure some of these aspects of IPv6. Using certificates at the Ethernet / IP layer honestly sounds like it would be a nightmare from a support perspective.

Many currently deployed switches and hosts do not support these IPv6 security features yet. I think it’s a little unclear what types of access layer security solutions will be widely deployed with IPv6. If you’re buying new access layer switches today, I would recommend looking at which of these IPv6 security features they support. This is definitely a problematic part of IPv6 deployments. I don’t think there’s a perfect solution for securing IPv6 at the access layer today. Hopefully one will evolve over time.