Subject: [dhcwg] An enhancement for DHCPINFORM?

From: Simon Kelley <[email-masked]>
Date: Fri, 08 Apr 2005 13:47:31 +0100

I just started thinking about using DHCP for automatic configuration of
proxy addresses and I've hit a problem and come up with a solution.

The problem is this: suppose I want to use DHCPINFORM to get
configuration information for an non-privileged, user space application;
a good example would be a web browser doing WPAD via DHCP.

In principle this is easy, the application determines the address of the
DHCP server used to configure its host and and sends a UDP packet
containing a DHCPINFORM with the relevant "requested option" to port 68
of the DHCP server. The server returns the requested information to port
67 of the client and it now has the correct configuration information.

The problem is with use of port 67. A non-privileged application cannot
bind port 67 so it must be set-uid root or moral equivalent. Even then,
a DHCP client is likely to have port 67 bound for the purpose of lease
renewals, so an application cannot use it.

The proposed solution to this to define one the MBZ bits in the header
flags as "honour source address". If this bit is set, then the DHCP
server will not reply to the address in ciaddr and port 67, but instead
use the source address and port of the UDP packet carrying the
DHCPINFORM. Now, a user application can set this bit in a DHCPINFORM
sent from a non-privilged UDP socket, bound to an ephemeral port, and
the answer will be send back to the same socket.

This change is completely backwards compatible and very simple (it would
take about ten lines of code in dnsmasq, the DHCP server I'm most
familiar with, for example.)

Assuming nobody trashes this proposal for flaws which I've not seen, how 
would I go about getting it debated and accepted into the standard? I'm 
happy to write it up formally (as an RFC?) and follow the procedures, 
but I'm pretty hazy as to what those procedures are.

Cheers,

Simon.

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

---

From: Bud Millwood <[email-masked]>
Date: Fri, 8 Apr 2005 16:32:57 +0200

> proxy addresses and I've hit a problem and come up with a solution.

<snip>

> the answer will be send back to the same socket.

Our DHCP server responds to the source port you're originating from, 
regardless of whether it's the "valid" port 68. (I think you mean port 68 in 
the above excerpt, that's the port the client should use)

I know there are others on this list that don't think that is appropriate 
behavior, but I personally felt like it was a reasonable enough thing to do. 
Besides, you can override that behavior at the server.

If you want to introduce a flag that says "honor the source address", then 
basically you're entrusting the client to not misuse that (such as a 
user-mode application trying to spoof another node). There's no difference 
between entrusting that to the client using a flag, or simply having the 
server respond to the port the query originated from. Either way, you're 
trusting the client.

As a side note, the most widely used OS allows any user-mode app to bind to 
privileged ports (last I checked), so it's not like you get any practical 
security by having the server drop datagrams that don't originate from port 
68.

- Bud

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
mailto:[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Fri, 08 Apr 2005 22:24:56 +0700

Date:        Fri, 08 Apr 2005 13:47:31 +0100
    From:        Simon Kelley <[email-masked]>
    Message-ID:  <[email-masked]>

  | The problem is this: suppose I want to use DHCPINFORM to get
  | configuration information for an non-privileged, user space application;
  | a good example would be a web browser doing WPAD via DHCP.

What you're trying to accomplish is a good idea (more applications should
use DHCP derived data for their configuration, where that is possible),
but I don't think you're going about it the right way.

  | The problem is with use of port 67. A non-privileged application cannot
  | bind port 67 so it must be set-uid root or moral equivalent. Even then,
  | a DHCP client is likely to have port 67 bound for the purpose of lease
  | renewals, so an application cannot use it.

Yes, and that's a good thing.   I really don't think it is a great idea
to have every application that needs some config into to go making separate
requests to the DHCP server (and most likely, over and over again, as the
application, or a new instance of it, is started, 30 times a second...)

Rather than modifying DHCP to allow a non-standard port to be used, a
better solution to me seems to be to modify your dhcp client to allow
applications to register interest in particular DHCP options.   Then,
the dhcp server can request those options along with everything else.
If a new request appears, that wasn't known previously, the dhcp client
can decide to make a DHCPINFORM request and get the data - once - after
that, the data just gets refreshed as usual.

That includes, being fetched in advance, before the application starts,
even if that sometimes means that the dhcp client fetches data that no
application happens to need to use (this time).   If an application has
ever requested a DHCP option, the client may as well always fetch that
data (which costs very little) into the future, just in case the application
runs again.

All that is needed then is an API between the application (and applications
in general) and the DHCP client to allow data to be requested, and for the
results to be made available - which isn't something that needs any IETF
action.

kre

ps: I see that Andre Kostur has sent a rather similar reply while I have
been typing this one...

---

From: Simon Kelley <[email-masked]>
Date: Fri, 08 Apr 2005 16:29:41 +0100

> the above excerpt, that's the port the client should use)
I do mean port 68, my mistake.
> Besides, you can override that behavior at the server.

I guess it's valid unless there  DHCP clients out there which _don't_ 
set the source port in the UDP headers if their requests to 68, or if 
such clients are RFC non-compliant.

> server respond to the port the query originated from. Either way, you're 

It may be useful to be able to make a DHCPINFORM query on behalf of 
another node, I'm not sure.

Cheers,

Simon.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Apr 2005 09:59:40 -0700

It's arguably a bug in your DHCP client if you can't already get this  
information somehow.   There's no technical reason why it's not  
possible.   So I'd encourage you to pursue that solution before  
trying to write a new standard - it's something you can do yourself,  
and therefore more likely to produce fruit than a standards change,  
which requires that all DHCP server vendors change their code.