Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 4 Dec 2005 23:58:25 -0500

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

If you're going to have multiple DHCP servers, such as failover pairs,
doing the DNS updates, you need to have those servers agree on how they
will identify the clients. This is not JUST for DNS updates. Failover
partners need to use the same identifiers for clients.

So, this is really not an issue.

The rules are pretty clearly described in the RFC:

For DHCPv4:
1. Use the DUID if the client identifier option is provided by the
client and it is a DUID and the server supports it. This is a new RFC
that is in the RFC-editor queue so no clients and servers yet support
this.
2. Otherwise, use the client identifier option if provided by the
client,
3. Otherwise, use htype and chaddr.

For DHCPv6:
1. Use the DUID of the client.

There really is no mystery here.

- Bernie 

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Sunday, December 04, 2005 11:43 PM
> To: Bernie Volz (volz); Sam Hartman; Mark Stapp (mjs)
> Cc: [email-masked]; [email-masked]; Pekka Savola; 
> Ted Lemon; [email-masked]; [email-masked]; Steven M. Bellovin; 
> Jeffrey Hutzelman
> Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last 
> Call:'Resolution of FQDN Conflicts among DHCP Clients' to 
> Proposed Standard]
> 
> 
> 
> On Thursday, December 01, 2005 08:48:10 AM -0500 "Bernie Volz (volz)" 
> <[email-masked]> wrote:
> 
> > How about we address issue 1 by expanding the DHCID RR type code. We
> > have 16-bits and we're just using 4 values presently. 
> There's plenty of
> > room for future expansion *SHOULD* someone come along and 
> demand a new
> > algorithm in the future. I can't see why this would EVER occur since
> > this really isn't about strong cryptographic protection (we're just
> > trying to make it non-trivial to find a client's identity 
> by not storing
> > it in clear text).
> 
> I think that's a good start; in fact, I was going to propose 
> something very 
> similar.  This solves half the problem; particularly, it 
> makes it possible 
> to indicate that some other hash is in use.  It does bind the 
> hash to the 
> type, rather than allowing them to be specified orthogonally, 
> but I don't 
> think that's a major problem.  If it ever becomes an issue, 
> there should be 
> no problem defining a type where the next 16 bits indicate a 
> subtype and 
> the 16 bits after that indicate a hash.
> 
> However, it doesn't solve the other half of the problem, 
> which is present 
> even without considering changing hash algorithms.  The 
> problem is that for 
> any given fqdn and DHCP client, there are multiple possible 
> DHCID RR's; in 
> particular, one for each type.  In order the update mechanism to work 
> without requiring either an advance query or multiple update 
> attempts, all 
> possible updaters must agree in advance on the type in use.  
> This lack of 
> negotiation seems problematic to me, even in the absence of 
> multiple hash 
> algorithms.
> 
> -- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 05 Dec 2005 01:47:24 -0500

> partners need to use the same identifiers for clients.

The document I read identifies several possible situations in which DHCID 
records are used to coordinate between updaters which are not DHCP failover 
partners.  It discusses a scenario in which multiple clients may attempt to 
issue updates for the same name (and, presumably, in which more than one 
client is authorized to issue such an update; otherwise, there would be no 
problem), and one in which a client moves between subnets served by 
different DHCP servers, both of which are authorized issue updates for the 
client's FQDN.

You can plausibly argue that the two DHCP servers in the second scenario, 
while not failover partners, are nonetheless part of the same 
administrative domain and require coordination.  Such an argument seems a 
little weak to me, but if that were the only issue, I could live with it.

I suppose you can also argue that two clients configured to use the same 
name will (by design) not produce the same DHCID RR's even if they use the 
same type, and therefore there's not a problem if they use different types. 
That I'll definitely buy.

However, what about a scenario where both a client and the DHCP server on 
its home network are authorized to do the updates.  When the client is at 
home, it lets the server do the update.  When it is off-site at an IETF 
meeting, the IETF DHCP server has no authorization to update the client's 
fqdn, so the client must do so itself.  Now, if the client and its home 
DHCP server disagree on which type to use, then the update may fail.

> 3. Otherwise, use htype and chaddr.

The rules are clear, but require that all possible updaters have the same 
view of the world.  Consider the client I described above, which identifies 
itself with a DUID.  So, as far as the client knows, it should follow rule 
1 and use the DUID to form a DHCID record.  Unfortunately, the client's 
home DHCP server doesn't support DUID's, so it skips rule 1 and follows 
rule 2, using the client identifier.

It gets worse when you start adding new types after DHCID support is widely 
deployed.  In fact, you arguably have that problem already, since a client 
supporting this option doesn't know whether its home server even supports 
the DHCID RR, as opposed to using the TXT record method.

If you think my example involving both a client and a server is contrived, 
consider a client which always does its own updates.  When such a client is 
updated, it may begin supporting new DHCID record types.  It may begin 
supporting DUID's, or even be required to switch from non-DUID client 
identifiers to DUID's because it now supports IPv6.  In each of these 
cases, the client will fail to perform an update because its new DHCID 
value is different from the old one.  You can require the client to give up 
its lease and remove the record prior to shutting down, but such a 
requirement is fragile because a client may shut down unexpectedly, with no 
chance to send a DDNS update first.

In short, as long as the only authorized updaters are a set of carefully 
coordinated DHCP servers which never receive configuration changes or 
software upgrades, everything works.  Once you introduce clients (which by 
their nature are unpredictable) or support for new DHCID types, the 
negotiation problem becomes an issue.  It's possible to work around by 
performing an extra query to determine what DHCID type is in use, but you 
seem to want to avoid that.

-- Jeff

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Dec 2005 09:54:26 -0700

> DHCP server disagree on which type to use, then the update may fail.

Are you under the impression from reading the documents carefully that this 
scenario is valid?   Because I don't see that it is - in general, it's not 
possible for the client to know when sending a DHCPDISCOVER whether or not 
it's at home, and it's supposed to send the same options in its DHCPREQUEST.   
So the only way that it can work when you have the client doing updates of 
its own A record is for the client to _always_ do its own update, whether 
it's at home or away.   Furthermore, if you think about it, this makes sense 
anyway - why have a complicated decision-making process in a scenario where 
the decision being made doesn't affect the outcome of the protocol?