Subject: [dhcwg] a question about recognizing dhcp packets

From: Michele Pedrolli <[email-masked]>
Date: Sat, 21 Jan 2006 10:46:25 +0100

I hope this is the right place for my question...

I'm developing a dhcp module for a network statistic software and I  
have to recognize the type of dhcp messages.
I'm not allowed to use more than ~150 bytes/pkt so I have to infer if  
a BOOTP REQUEST is a DHCPDISCOVER or a DHCPREQUEST and if
a BOOTP REPLY is a DHCPOFFER or a DHCPACK. Options fields are not  
available because placed after the 150 byte.

The only solution I have thought is to infer the type watching the  
dhcp flow and:
- if I can see 4 packets BOOTP REQUEST/OFFER/REQUEST/OFFER with the  
same xid, probably they are DHCP DISCOVER/OFFER/REQUEST ACK;
- if I can see couples of BOOTP REQUEST/OFFER with the same xid,  
probably they are DHCP REQUEST/ACK renew packets;
  and so on...

Are there other ways to infer the type of a dhcp packet ?

bye

--
                       Michele

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Barr Hibbs" <[email-masked]>
Date: Sat, 21 Jan 2006 08:35:32 -0800

Recall that BOOTP is still a viable, actively used protocol,
especially for printers, so not being able to distinguish
between BOOTP requests and responses and DHCP requests and
responses will leave your product essentially crippled.

Because of several factors, including the unreliability of
UDP, improper behavior of certain DHCP clients, and problems
training ARP caches and enabling switches, you can't infer
with any certainty that a 4-message exchange (BOOTPREQUEST,
BOOTPREPLY, BOOTPREQUEST, and BOOTPREPLY) actually
corresponds to DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and
DHCPACK.

The additional DHCP message types, including DHCPNAK,
DHCPRELEASE, DHCPINFORM, and DHCPFORCERENEW further
complicate the situation.

In order to determine the DHCP message type, you MUST have
the option field to examine.  I'm afraid there's no other
way to be certain.

--Barr

> -----Original Message-----
> From: Michele Pedrolli
> Sent: Saturday, January 21, 2006 01:46
>

---

From: Ralph Droms <[email-masked]>
Date: Sun, 22 Jan 2006 15:45:12 -0500

Michele - where will the truncation of the DHCP messages take place in this
application?  Will there be a truncation at L2 or will the DHCP server have
to generate short messages?

I agree with Barr Hibbs who wrote that's it's probably not feasible to
reliably infer the DHCP message type from the message sequence.  If you have
access to the DHCP server, you might be able to insert the appropriate DHCP
options in the 'sname' or 'file' fields in the DHCP header.

- Ralph

---

From: Michele Pedrolli <[email-masked]>
Date: Tue, 24 Jan 2006 20:43:33 +0100

> to generate short messages?

The traffic dump is acquired via tcpdump using a snaplength of 150  
bytes per packet
and without using filters for protocols; that means that every packet  
in the net is traced.
The DHCP server generates rfc-compliant dhcp messages, with a full  
header.

> reliably infer the DHCP message type from the message sequence.

Ok, but probably I don't have to be sure about the dhcp message type.
I have to suppose if a packet is, for example, a DHCPREQUEST or a  
DHCPDISCOVER.
I can do errors. At the end, the analysis must be good.... but not  
perfect!

Back to my previous message, I think I can say that if a a four- 
sequence of BOOTP request,reply,request,
reply, probably (but not certainly) is a sequence of DHCP  
discover,offert,request,ack.
I'm looking for a tolerant heuristic to infer dhcp message type.

> If you have

No... this way is unapplicable on my test-lan

bye

--
        Michele

---

From: "Barr Hibbs" <[email-masked]>
Date: Tue, 24 Jan 2006 16:49:25 -0800

After writing my initial response to Michele's inquiry, it
occurred to me that in many environments, her trick might
work, that is:

--IF there are no BOOTP-only devices in the network
  [unlikely, but not impossible] AND
--IF there is a high probability that UDP messages are not
lost
  [possible, but not a certainty] AND
--IF clients do not have unusually short timeouts
  [fairly likely, but even a few can wreak havoc here]
--THEN assuming that a four-message sequence of
BOOTPREQUEST, BOOTPREPLY, BOOTPREQUEST, and BOOTPREPLY with
the same 'XID' (perhaps further qualified with a requirement
for the same 'haddr') is a fair first-order approximation to
the sequence DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and
DHCPACK.

> Sent: Tuesday, January 24, 2006 11:44
>
> > Michele - where will the truncation of the DHCP
> > messages take place in this application?
> > Will there be a truncation at L2 or will the DHCP
> > server have to generate short messages?
>
> The traffic dump is acquired via tcpdump using a
> snaplength of 150 bytes per packet and without using
> filters for protocols; that means that every packet
> in the net is traced.  The DHCP server generates
> rfc-compliant dhcp messages, with a full header.
>

[Barr]
Michele, is your application so restricted with respect to
buffer size that you could not specify a longer snaplength
for tcpdump?  DHCPv4 isn't the only protocol for which
considerable {sometimes essential!} information is not
restricted to the first 150 bytes of a packet.

> > I agree with Barr Hibbs who wrote that's it's
> > probably not feasible to reliably infer the DHCP
> > message type from the message sequence.
>
> Ok, but probably I don't have to be sure about
> the dhcp message type.  I have to suppose if a
> packet is, for example, a DHCPREQUEST or a
> DHCPDISCOVER.
>
> I can do errors. At the end, the analysis must be
> good.... but not perfect!
>
> Back to my previous message, I think I can say
> that if a four-message sequence of BOOTP request,
> reply, request, reply probably (but not certainly)
> is a sequence of DHCP discover, offer, request, ack.
[Barr]
errors are, in fact, the bugaboo of what you're trying to
accomplish.  Lately we have seen a large number of DHCP
clients that are intolerant of even moderate delays between
requests and replies, behaving like this:

  CLIENT                SERVER            NETWORK
  --+---                ---+--            ---+---
    |\                     |                 |
    | \___ DISCOVER ______>|                 |
    |       (XID 1)  /     |\                |
    |                |     | \___ PING _____>|
    |             (< 2 s.) |                 |
    |\               |     |           (no response)
    | \___ DISCOVER ______>|                 |
    |       (XID 2)  |     |\                |
    |<______ OFFER __/____/| \___ PING _____>|
    |       (XID 1)        |                 |

   and so on for a very long time...

This trap occurs because the server is stateless, while the
client is stateful, discarding the OFFER (XID 1) it was not
expecting after sending DISCOVER (XID 2).

> > If you have access to the DHCP server, you might
> > be able to insert the appropriate DHCP options in
> > the 'sname' or 'file' fields in the DHCP header.
>
> No... this way is inapplicable on my test-lan
>
[Barr]
...and the DHCP client would also need to be accessible in
the same way to approach certainty.

Given as Michele is working with a test lab setup, it might
be possible to control BOOTP users, packet loss, and
ill-behaved clients in order to make the leap from
BOOTPREQUESTs and BOOTPREPLIES to the four-message
DHCPDISCOVER sequence.

I can't think of any easy solutions that would work in every
circumstance (other than running Ethereal or other packet
sniffer), but good luck in solving your problem.

--Barr

---

From: Ralph Droms <[email-masked]>
Date: Wed, 25 Jan 2006 05:57:29 -0500

Michele - now I understand your problem a little better.  And I see where
Barr followed up to point out that your heuristics might work reasonably
well if there is no conflicting BOOTP traffic.

I poked around in RFC 2131 to see if I could identify any usages in the
header fields you could use to help differentiate the types of messages, but
I couldn't find anything...

- Ralph Droms

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 25 Jan 2006 13:47:54 -0800

> the sequence DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and

Consider for example this log of a common four message exchange
of INFORMs sent by Windows XP systems:

Jan 25 20:13:34 lab1 dhcpd: DHCPINFORM from 192.168.0.254 via 192.168.0.1
Jan 25 20:13:34 lab1 dhcpd: DHCPACK to 192.168.0.254 (00:13:ce:81:19:43) via 192
.168.0.1
Jan 25 20:13:38 lab1 dhcpd: DHCPINFORM from 192.168.0.254 via 192.168.0.1
Jan 25 20:13:38 lab1 dhcpd: DHCPACK to 192.168.0.254 (00:13:ce:81:19:43) via 192
.168.0.1

This is an example of a client that broadcasts DHCPINFORMs hoping
to receive WPAD configuration directives in DHCP Option #252 so
that it may patch itself from them.

	http://www.wrec.org/Drafts/draft-cooper-webi-wpad-00.txt

This is not DISCOVER-OFFER-REQUEST-ACK, and is indistinguishable
otherwise.

One out of four isn't a very good success rate.

I submit there is no way to be anything resembling "sure" outside of
digesting option 53.

> > rfc-compliant dhcp messages, with a full header.

Another option might be a firewall rule on ports 67/68 which
redirects a copy of the packet to a local application (duplicate
the packet to a local port that will record its contents, or
other system-specific methods such as piping packets through
dynamically spawned applications).

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Michele Pedrolli <[email-masked]>
Date: Fri, 27 Jan 2006 09:40:20 +0100

> Jan 25 20:13:34 lab1 dhcpd: DHCPINFORM from 192.168.0.254 via  
[..]
> This is not DISCOVER-OFFER-REQUEST-ACK, and is indistinguishable

It is possibile to distinguish a DHCPDISCOVER and a DHCPINFORM using  
the value of 'ciaddr' field:
DISCOVER's ciaddr must be 0 and INFORM's ciaddr must be the client's  
network address.

It's more difficult to distinguish an INFORM from a REQUEST. But if I  
can distinguish an OFFER, the following
REQUEST is distinguishable using the xid (the same xid is used for  
offer and request).

bye

--
			Michele

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Jan 2006 09:51:32 -0700

> DISCOVER's ciaddr must be 0 and INFORM's ciaddr must be the client's  

Unfortunately, not all clients that implement DHCPINFORM actually fill out the 
value in ciaddr as required, so for example the ISC DHCP server and the 
Nominum server, in order to interoperate with such non-conforming clients, 
will reply with a DHCPACK to the IP source address of a DHCPINFORM packet if 
ciaddr contains 0.0.0.0.

Also, in addition to DHCPINFORM, a DHCPREQUEST in the SELECTING state will 
have 0.0.0.0 in the ciaddr.   And a DHCPREQUEST in the RENEWING or REBINDING 
state will have the client's network address in ciaddr, so even if you 
restrict your information gathering solely to properly conforming DHCP 
clients, you still can't distinguish reliably between a DHCPINFORM and a 
DHCPREQUEST using ciaddr.