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

From: [email-masked]
Date: Tue, 8 Jul 2003 12:39:00 +0800

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. 

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 11:27:00 +0200

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]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Jul 2003 00:20:12 -0500

On Monday 07 July 2003 23:39, [email-masked] wrote:
> Coming back to 'xid', I think checking 'xid' alone is not a good idea,
> considering erroneous servers, multiple clients using same xids etc.

That's right.   We hacked the ISC DHCP client to check chaddr in the reply 
because someone was in fact getting broadcast replies in high-traffic 
environments that were caused by xid collisions.   The problem is that a 
really good random number generator for xid generation is difficult to write 
in a portable way, and so we wind up using a fairly crappy one, which does 
the trick but certainly wouldn't be appropriate for doing crypto.   More to 
the point, in some environments I would expect collisions to be pretty much 
inevitable.   Collisions are a pretty serious problem, so I think the point 
that is being raised here is a serious one.