Subject: RE: [dhcwg] "client identifier" in server replies

From: [email-masked]
Date: Tue, 8 Jul 2003 18:01:08 +0800

Choosing random xid may reduce the chances of clashing, but won't eliminate the problem. I feel, to ensure correct protocol operation, DHCP servers should return "client id" also in their replies. 

regards,
swamy.

> -----Original Message-----
> From: ext Bud Millwood [mailto:[email-masked]]
> Sent: Tuesday, July 08, 2003 2:57 PM
> To: Nelakuditi Narasimha (NET/Bangalore)
> Cc: [email-masked]
> Subject: Re: [dhcwg] "client identifier" in server replies
> 
> 
> On Tuesday 08 July 2003 06.39, [email-masked] wrote:
> 
> > Hi Thamer, I was discussing the case in which client fills 
> "Client ID"
> > field but NOT "Client Hardware addr(MAC)". This is possible 
> as servers
> > identify clients using EITHER "Client ID" OR "Client HW 
> addr". Coming back
> > to 'xid', I think checking 'xid' alone is not a good idea, 
> considering
> > erroneous servers, multiple clients using same xids etc.
> 
> If the client is on the local segment and the server is 
> capturing packets with 
> raw frames, the server will know the hw addr of the client. 
> In this case the 
> combination of xid and unicast is pretty tight. If the server is not 
> capturing raw frames, it has no way to know the client's hw 
> addr (client id 
> is opaque, last I checked), so you will probably get a 
> broadcast only if 
> there's no hw addr (chaddr) defined. In this case, xid is the 
> only thing you 
> can use.
> 
> Same goes for a relay agent.
> 
> If you're a client using xid to identify responses to you: 
> Use a random XID 
> such that it will likely be unique across the entire network. The two 
> constraints that help further minimize xid clashes are 1) the 
> xid only really 
> needs to be unique on your segment, not the entire network and 2) the 
> duration of your query. This is assuming that you're not 
> filling out the 
> chaddr field, which you *should* be if you can.
> 
> I think those three (randomness, segment subset and query 
> duration) give you a 
> high probability of identifying responses intended for you if 
> you're not 
> using the hwaddr field.
> 
> Note that if the client *does* fill out the hw addr field, 
> you're basically 
> guaranteed that a response is for you.
> 
> Regards,
> 
> Bud Millwood
> Weird Solutions, Inc.
> http://www.weird-solutions.com
> tel: +46 8 758 3700
> fax: +46 8 758 3687
> mailto:[email-masked]
> 
> > regards,
> > swamy.
> >
> > > -----Original Message-----
> > > From: ext Thamer Al-Harbash [mailto:[email-masked]]
> > > Sent: Monday, July 07, 2003 11:30 PM
> > > To: Nelakuditi Narasimha (NET/Bangalore)
> > > Cc: [email-masked]
> > > Subject: Re: [dhcwg] "client identifier" in server replies
> > >
> > > On Mon, 7 Jul 2003 [email-masked] wrote:
> > > > Hi, If the client is setting "client identifier" but not
> > >
> > > "client hardware addr" in the messages that it is sending to
> > > server, server is supposed to identify it with "client
> > > identifier". But as per RFC2131, server MUST NOT fill "client
> > > identifier" option in OFFER and ACK messages. If this is the
> > > case, how is client supposed to validate the response (as
> > > 'xid' alone is not sufficient)???
> > >
> > > Why? An xid is a 32-bit unsigned integer. That's about as many IP
> > > addresses as are possibly with IPv4. Unless you're picking your
> > > xid badly, this shouldn't be a problem.
> > >
> > > Also, unless the client requests broadcasts with the broadcast
> > > bit, the server will be unicasting replies to it. The MAC
> > > addresses with the xid should be sufficient.
> > >
> > > --
> > > Thamer Al-Harbash
> 
> 

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

---

From: Bud Millwood <[email-masked]>
Date: Tue, 8 Jul 2003 14:49:44 +0200

On Tuesday 08 July 2003 12.01, [email-masked] wrote:

> Choosing random xid may reduce the chances of clashing, but won't eliminate
> the problem. I feel, to ensure correct protocol operation, DHCP servers
> should return "client id" also in their replies.

Filling out chaddr and htype *will* eliminate the problem. As long as client 
id is also present, the device will be identified with client id (which is 
the preferred identifier).

Barring that (and it shouldn't be barred), randomizing xid is not the only way 
to reduce clashes. Timing & relay segmentation further reduce the probability 
of a clash. And unicast responses, when received, are guaranteed to be for 
you.

Instead of changing DHCPV4, change the client to use both client id *and* 
htype/chaddr.

- Bud

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Jul 2003 13:44:02 -0500

On Tuesday 08 July 2003 07:49, Bud Millwood wrote:
> Filling out chaddr and htype *will* eliminate the problem. As long as
> client id is also present, the device will be identified with client id
> (which is the preferred identifier).

Bud, there are some cases, particularly with firewire, where there is no way 
to fill out the hardware address.   Of course it needs to be filled out in 
other cases - the protocol requires it.

> Barring that (and it shouldn't be barred), randomizing xid is not the only
> way to reduce clashes. Timing & relay segmentation further reduce the
> probability of a clash. And unicast responses, when received, are
> guaranteed to be for you.

It's not always easy to see that a response has been unicast.

In response to one of your earlier points, adding special cases to watch the 
wire doesn't help, because protocol specifications have to work properly in 
the general case, not just in special cases.

The solution of having the server notice xid clashes and stagger the replies 
unfortunately doesn't work because the first reply is going to be seen by 
both clients as a reply to its DHCPDISCOVER.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Jul 2003 16:18:52 -0500

On Tuesday 08 July 2003 14:28, Thamer Al-Harbash wrote:
> We already have the DHCP Hostname option. Clients can be
> configured to pass this option when the admnistrator expects high
> xid collisions.

This isn't a standard use of the DHCP host-name option, and not all DHCP 
clients support it.

>  The DHCP server can also be configured to assign
> leases per the DHCP Hostname option.

A DHCP server that uses the host-name option as an identifier is out of spec 
with the standard.   Furthermore, since host-name option values aren't 
guaranteed to be unique, this is a very risky proposition even with clients 
that _do_ support this non-standard use of the host-name option.

> We just need to promote the
> use of the DHCP Hostname option to be used to counter this
> problem.

This doesn't solve the problem anyway.   The only difference here is that 
we're now using the host-name option as if it were a client-identifier 
option.   So we have the same problem, but with a different option.

> Is this too kludgy?

It's not so much that as that I think it won't work.   :'/

---

From: John Schnizlein <[email-masked]>
Date: Tue, 08 Jul 2003 17:37:16 -0400

At 03:28 PM 7/8/2003, Thamer Al-Harbash wrote:

>...
>xid collisions. The DHCP server can also be configured to assign
>leases per the DHCP Hostname option. We just need to promote the

Yes. IMHO

The part of this that relies on DHCP clients to provide different
host-name parameters violates the design goal of RFC 2131:

   1.6 Design goals

   The following list gives general design goals for DHCP.

      o DHCP should be a mechanism rather than a policy.  DHCP must
        allow local system administrators control over configuration
        parameters where desired; e.g., local system administrators
        should be able to enforce local policies concerning allocation
        and access to local resources where desired.

      o Clients should require no manual configuration.  Each client
        should be able to discover appropriate local configuration
        parameters without user intervention and incorporate those
        parameters into its own configuration.

      o Networks should require no manual configuration for individual
        clients.  Under normal circumstances, the network manager
        should not have to enter any per-client configuration
        parameters.

John

---

From: Thamer Al-Harbash <[email-masked]>
Date: Tue, 8 Jul 2003 15:28:33 -0400 (EDT)

> other cases - the protocol requires it.

[snip]

> the general case, not just in special cases.

There may already be a way around this.

> both clients as a reply to its DHCPDISCOVER.

Agreed.

The problem here is two fold:

(1) xids cannot be guaranteed not to collide because some clients
    cannot be programmed to generate enough randomness.

(2) Some datalinks, like firewire, do not allow setting chaddr to
    anything reasonable.

Is this too kludgy?

Barring thing it would make more sense to add a DHCP option for a
larger unique ID (Secondary XID?) than to modify the BOOTP
header.

-- 
Thamer Al-Harbash

---

From: Bud Millwood <[email-masked]>
Date: Wed, 9 Jul 2003 10:48:36 +0200

On Tuesday 08 July 2003 20.44, Ted Lemon wrote:
> Bud, there are some cases, particularly with firewire, where there is no
> way to fill out the hardware address.   Of course it needs to be filled out
> in other cases - the protocol requires it.

It would seem that if you do not have a hardware address, the only way to 
guarantee that a response is for you is if your client identifier is in the 
packet, since that's guaranteed to be unique on the "subnet" ("segment" seems 
a better word choice - 2131.2p5). And XID then only needs to be unique across 
DHCP transactions on the specific client.

I don't recall seeing anything that stated that chaddr *must* be globally 
unique for a given htype, so is it not possible to assume that if your client 
identifier is unique for your segment, that it could also qualify as a 
chaddr?

I can hear the groans now. :) 16 bytes is arbitrary, and this makes a direct 
link between chaddr and clientid, but only at the client side, and only for 
packet identification.

If not, Narasimha's proposal is the only solution I can see.

Bud Millwood
Weird Solutions, Inc.