dhcpinform or dhcprequest

[Shawn Holland]

On Wed, 2009-09-02 at 15:46 -0700, David W. Hankins wrote:
> On Wed, Sep 02, 2009 at 05:22:54PM +0200, Tom Schmitt wrote:
> > Sadly I have not much hope that the vendor will change anything: The Client is a HP workstation with Windows XP and Microsoft is not well known for changing their software based on a request from a single person.
> 
> the windows XP client is not known to behave as you describe, sending
> a DHCPINFORM in lieu of a DHCPREQUEST...
> 
> quite the opposite, it is well known to renew at the correct time.
> 
> the DHCPINFORM packets a client sends aren't based on lease time
> expiration, but rather are a random delayed window after bootup, when
> the Microsoft Industry Updater ("automatic updates") tries to check
> for patches.  the MIU wants the unofficial "WPAD" option to try local
> http proxies first.
> 
> you can suppress the DHCPINFORM packets at DHCPREQUEST time by sending
> a 'poison pill' wpad option contents.  windows caches this poison pill
> and will not send a DHCPINFORM when the MIU starts up.  this also
> stops the client from trying to locate proxies by DNS or other methods,
> and so it is in general a good idea if you aren't actually using WPAD.
> 
> although it's not impossible for an attacker to insert a WPAD option
> at DHCP time, succeeding in giving a poison pill means it is impossible
> for an attacker to succeed via any other WPAD transport mechanism...a
> net gain.
> 
> i've considered including it in our example dhcpd.conf, except that
> this raises questions about how we would document the option.  the
> only reference that describes the option is an expired I-D.
> 
> 
> anyway.
> 
> the only time i've ever heard of a similar situation was with
> failover servers in early 3.0.x, where the client was processed by both
> servers, so ddns updates were performed (identically) by both servers.
> 
> the bug comes when the servers record inconsistent lease times, and
> the client binds to the longer lease time of the two.  the early lease
> time comes, and in expiring the lease the server tears down ddns
> state.  but we fixed this long ago, such that expiration events are
> only processed when both servers agree the lease has expired.
> 
> so you are probably a victim to some unusual order of operations that
> causes the servers to agree that the client has been given a shorter
> lease time than it has bound to...
> 

You can confirm what the client is being offered by looking at the offer
packet in tcpdump.

eg. 

tcpdump -nes0 -i eth0 ether host 00:24:36:37:6c:d0 -vv

Discover packet:

20:22:53.506604 00:24:36:37:6c:d0 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 342: (tos 0x0, ttl 255, id 27835, offset 0, flags
[none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67:
[udp sum ok] BOOTP/DHCP, Request from 00:24:36:37:6c:d0, length 300, xid
0xa8d69d36, Flags [none] (0x0000)
	  Client-Ethernet-Address 00:24:36:37:6c:d0
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    Parameter-Request Option 55, length 6: 
	      Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
	      Option 119, Option 252
	    MSZ Option 57, length 2: 1500
	    Client-ID Option 61, length 7: ether 00:24:36:37:6c:d0
	    Lease-Time Option 51, length 4: 7776000


Offer Packet:

20:22:54.004086 00:02:b3:e7:61:86 > 00:24:36:37:6c:d0, ethertype IPv4
(0x0800), length 342: (tos 0x10, ttl 16, id 0, offset 0, flags [none],
proto UDP (17), length 328) 10.2.0.1.67 > 10.2.255.254.68: [udp sum ok]
BOOTP/DHCP, Reply, length 300, xid 0xa8d69d36, Flags [none] (0x0000)
	  Your-IP 10.2.255.254
	  Client-Ethernet-Address 00:24:36:37:6c:d0
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Offer
	    Server-ID Option 54, length 4: 10.2.0.1
	    Lease-Time Option 51, length 4: 5
	    Subnet-Mask Option 1, length 4: 255.255.0.0
	    Default-Gateway Option 3, length 4: 10.2.0.1
	    Domain-Name-Server Option 6, length 4: 10.2.0.1
	    Domain-Name Option 15, length 10: "sandara.ca"

You should see the lease time (Option 51) in seconds. In my example 5
seconds.

If you look at the dhcpd.leases file it will confirm the lease time
offered

lease 10.2.255.254 {
  starts 3 2009/09/02 23:24:08;
  ends 3 2009/09/02 23:24:13;
  tstp 3 2009/09/02 23:24:13;
  binding state free;
  hardware ethernet 00:24:36:37:6c:d0;
  uid "\001\000$67l\320";
}

Now you should know exactly what was offered and be able to guess when
the client will request next.

-- 
Regards,
Shawn Holland
Sandara Technologies Ltd.