Ensuring IP address allocation integrity with DHCP snooping

Nearly every IP network you use allocates IP addresses to clients via DHCP. There is a lot you can do with DHCP and it is a fairly well thought out and extensible successor to BOOTP.

This post briefly explores the sorts of issues we have with DHCP on a large scale temporary network, and the sorts of things that go wrong.

Quick recap

DHCP is an application layer protocol that allows clients to negotiate for an IP address lease. The protocol also allows clients to obtain additional configuration parameters as a part of the lease process (e.g. an embedded device client might obtain the IP address of a server from which it can subsequently download firmware).

You might think that DHCP uses some sort of low-level trickery (hey, it must! You don’t even have an IP address yet!) but in fact it is a very simple UDP protocol that works via broadcasts. So, you are in fact using IP to obtain an address so that you can use IP.

The protocol works roughly as follows:

  1. The client sends a DHCPDISCOVER broadcast in order to locate all DHCP servers on the local subnet. The client sends a list of options in this request for items it wants back from relevant DHCP servers.
  2. Any and all servers respond to the client with a DHCPOFFER response. At the time of sending the offer, the server(s) will set aside an IP address for the client. The offer also includes additional dhcp options that have been requested by the client.
  3. The client receives all of the responses and then chooses one to request as a lease (DHCPREQUEST). Once that is sent, any server that is NOT the server that offered the address that the client chose will return the offered address back to their pool for use by other clients.
  4. The server that recognises the response (via a unique transaction ID used throughout the conversation) will respond with a DHCP acknowledgement and ‘lease’ the IP address to the client for the time specified in the policy on the server.

When DHCP Servers go bad

Every tech•ed there will be someone who brings:

  1. A dinky little home router with a view to starting their own rogue wireless network
  2. An entire enterprise infrastructure in VMs, including DHCP servers and so on, with their network adapter set to bridge the virtual switch with the local network

In our experience, we’ll get at least two to three rogue DHCP servers popping up at each tech•ed.

As you can see from the brief protocol overview above, there isn’t really any authentication or trust between the clients and the DHCP server. Therefore any rogue DHCP server will be treated with the same authority as our own and start handing out IP addresses for a different subnet and with a different router and so on. Once this happens, a large number of clients can aquire an incorrect IP address quite quickly and this creates a massive PITA for the helpdesk guys to tell everyone to do a release and renew to get an IP address that works.

Trusted and authorised servers

You might have noticed that when you use Windows DHCP server there are a few behaviours that might strike a networking traditionalist such as myself as odd:

  1. If your DHCP server is a member of a domain, it will not start until someone with administrative credentials ‘authorises’ the server to serve addresses. You do that using the DHCP server MMC snap-in.
  2. If your DHCP server is on a standalone server, and it is running, and it sees another DHCP server that is also running and that server is a member of a domain … then your standalone DHCP server will shut down.

I believe that both of these approaches are a little bit silly for a number of reasons, the primary of which being that rogue DHCP servers are rarely Windows Servers. A little busybox machine or home wifi router isn’t going to play in the above scheme and so you’re still exposed to IP addressing integrity issues.

We’re really dealing with a layer 3 network security/integrity issue here and the correct place to solve it is in the network itself, not in the operating system of some select servers that exist on that network.

DHCP Snooping

DHCP Snooping is a catch-all term that covers a number of techniques for ensuring the security and integrity of certain aspects of the edge of your network. You can think of DHCP Snooping as a type of light-weight firewall that sits in every switch on your network.

The main feature we’re interested from the various features in the DHCP Snooping arsenal is where by individual ports can be marked as trusted or untrusted for the purposes of DHCP traffic.

We are deploying a large number of Cisco Catalysts throughout the venue for the event. The standard units in the IDFs will have 24 x 10/100 copper ports, and 1 x fibre GBIC to connect the switch back to the core of the network. The standard configuration we will deploy to these switches will set all 24 10/100 copper ports as untrusted. We will nominate the fibre GBIC as trusted.

The result of this configuration is that packets such as a DHCPOFFER received on one of the untrusted ports are simply dropped. They never enter the network. It does not matter if the device on the edge port is a massive Windows Data Centre Edition server or a $89 home wifi unit … the treatment is at the packet level and the result is the same.

Problem solved!

Since we started insisting on Catalysts in all untrusted/edge scenarios, we’ve never had a repeat of the issues of the tech•eds of many years ago. The solution described above is implemented at the right place in the OSI networking model, and at the right place in terms of the overall topology of your network.

If you have rogue DHCP server problems then it is well worth looking into the benefits of DHCP Snooping. There are a lot of features under that name and I’ve only briefly touched on one that is relevant to the event here.

Further reading:

I recommend the first link as a very comprehensive overview of all of the aspects of DHCP Snooping that you can add to your network security arsenal.