Question about dhcp-client-identifier

Tim Peiffer peiffer at
Wed Aug 22 15:32:07 UTC 2007

I don't think it is possible as you suggest - ignore the UID.  According 
to the man page for dhcpd.conf, there is the option of ignoring 
duplicates, only allowing a MAC to hold only one lease.  I don't know 
how one would look a duplicate MAC's in different subnets though.

>        The  duplicates  flag tells the DHCP server that if a request 
> is received from a client that matches the MAC address of a host 
> declaration, any other leases matching that MAC address should be 
> discarded by the server,  even  if  the  UID is not the same.   This 
> is a violation of the DHCP protocol, but can prevent        clients 
> whose client identifiers change regularly from  holding  many  leases  
> at  the  same  time.   By  default, duplicates are allowed.

I would echo Glenn's sentiments.  I think your efforts are better spent 
on tracking ip to hardware to physical port down to jack per unit of 
time.  Have something else provide the access controls and leave to 
DHCPD the job of providing addressing and network parameters.  If you 
mandate that everyone 'must' get their address from the DHCP server and 
enforce through realtime dhcp packet snooping on the switch (I know that 
vendor C will do it), then there are little chances of 'hiding'.
Besides, you get bonus points from law enforcement if you can show 
positive session information to within a few minutes of start/stop 
activity, regardless of whether the address was assigned by the DHCP server.

Alternatively require the users to 'log in to the network' through 
effective use of proxy firewalls or deployment of 802.1X.

Duplicate MAC addresses are a fact of life, regardless of whether 
someone choses to administratively re-assign the MAC. Programmable Array 
Logic and Gate Array Logic used to encode station addresses blow bits 
periodically.  Sometimes vendors accidentally duplicate through bad QA, 
etc..  It is also sometimes different to tell the difference between 
hardware failure and malice just purely on MAC.

The point is that if you leave access controls to DHCPD, you will find 
your self chasing your tail more often than you care to admit.

Tim Peiffer
Network Support Engineer
Networking and Telecommunications Services
University of Minnesota/Northern Lights GigaPOP

Darren wrote:
>> Ok, so let's try and understand this. Joe User with a certain mac
>> address is happily working away. A Bad Guy tracks his connection
>> somehow and borrows his mac address, then connects to the same network
>> but a different subnet. You want him to be denied an IP address by
>> dhcp. All that shows up in the logs is that a particular mac address
>> turned up on another subnet. Happens a lot if you have roving laptops.
> We are aware that this is a problem for roving laptops.  We can handle 
> that on the support/administrative end of things.
>> What happens if the Bad Guy manually assigns himself an IP address that
>> is valid for the subnet? Instant access...
> We have other methods in place for making it impossible for a user to 
> statically assign himself an IP.
>> What about the same scene, but on the same subnet? The new device can
>> steal all the connections that Joe User had. This is one way to do ARP
>> cache poisoning. There are others that don't require the use of a
>> duplicated mac address.
> We aren't particularly concerned about a user causing another user 
> problems, we will deal with that on the administrative/support side.  We 
> ARE concerned about a user being able to "hide".
>> As has been said many times on this list, DHCP is not a security
>> enforcement service. By its very nature it happily hands out IP
>> addresses to unauthenticated devices on the network.
> Understood - we would never use it as a security device.  We merely 
> would like to be able to make the data from DHCP more useful.
>> regards,
>> -glenn

More information about the dhcp-users mailing list