Question about dhcp-client-identifier
Glenn.Satchell at uniq.com.au
Wed Aug 22 14:09:32 UTC 2007
>X-Virus-Scanned: amavisd-new at network1.net
>Date: Wed, 22 Aug 2007 09:57:30 -0400
>From: Darren <perl-list at network1.net>
>To: dhcp-users at isc.org
>Subject: Re: Question about dhcp-client-identifier
>Simon Hobson wrote:
>>> This is ideal! If we could specify to key on hardware, would that not
>>> force the DHCP server to do one of the following depending on condition:
>>> 2) if the two devices are in separate physical networks, prevent one of
>>> them from obtaining an IP due to: one-lease-per-client true; setting. I
>>> would expect this behavior as the DHCP server would see both as the same
>>> client and would deny an IP for one of the requests from the separate
>> No, if they are in two different networks then the second device will
>> get it's address and the lease for the first device will be
>> terminated (see man dhcpd.conf). The first device will not know this
>> and so will continue to use it's address until it's time to renew it.
>> At this point things get interesting !
>> I'm not entirely sure, but I think the server will do it's
>> ping-before-offer check and find the address in use - which means it
>> then marks the address as abandoned. I'm not sure if it will NAK the
>> clients request or just ignore it.
>> Eventually the first device will get a new address and the process
>> will repeat. A similar thing will happen in the second subnet.
>> After enough time, you will run out of available addresses - and have
>> a fun time trying to figure out why !
>Can I formally request a change in behavior then? Or perhaps a new
>option? If a mac address already has a lease, it cannot obtain another
>one. The behavior should be as follows:
>1) if a DHCPDISCOVER comes in from the same physical network from which
>the mac already has an IP address leased to it, it will be offered the
>same IP again.
>2) if a DHCPDISCOVER comes in from a different physical network than the
>mac already has an IP address leased to it, it will be ignored (and
>logged). If the device is a laptop, the user will have to be told how
>to release their first IP before roaming to another network segment with
>their laptop. Or, really short leases will need to be used in certain
>I understand that this behavior is totally against RFC, however, in the
>USA, this behavior is desirable due to CALEA. So maybe you can call it
>a CALEA option? For further information regarding CALEA:
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.
What happens if the Bad Guy manually assigns himself an IP address that
is valid for the subnet? Instant access...
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.
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.
More information about the dhcp-users