Subject: RE: [dhcwg] dhc WG last call on<draft-ietf-dhc-ddns-resolution-08.txt>

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 16 Jun 2005 15:38:29 -0400

Thanks for the comments Stuart. I'll go back and look at the draft
carefully to see what changes to make.

DHC WG members, Ralph informs me that we received too "official" little
feedback  on the draft so that it did NOT pass the WG Last-Call.

And, based on Ralph (and now Stuart's) feedback, I will need to revise
the document anyway.

But, providing comments on other changes now would be greatly
appreciated so that we don't have substantive comments during the next
WG Last Call.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Stuart Cheshire
> Sent: Thursday, June 16, 2005 3:28 PM
> To: DHCP discussion list
> Subject: Re: [dhcwg] dhc WG last call 
> on<draft-ietf-dhc-ddns-resolution-08.txt>
> 
> >This message announces a WG last call on "Resolution of DNS Name
> >Conflicts among DHCP Clients" 
> <draft-ietf-dhc-ddns-resolution-08.txt>.
> 
> I just took a look at this, and it appears to have a trivial race 
> condition:
> 
> 6.3.1  Initial DHCID RR Query
> 
>    When a DHCP client or server intends to update an A or AAAA RR, it
>    performs a DNS query with QNAME of the target name and 
> with QTYPE of
>    DHCID.
> 
>    If the query returns NXDOMAIN, the updater can conclude 
> that the name
>    is not in use and proceeds to Section 6.3.2.
> 
> What if two clients do this at the same time?
> 
> Surely this non-existence of the DHCID record needs to be 
> expressed as a 
> required precondition in the DNS UPDATE, so that it's performed 
> conceptually as an atomic test-and-set operation?
> 
> In fact, that's exactly what Section 6.3.2 says, making Section 6.3.1 
> completely redundant. Since the protocol has to work even when the 
> Section 6.3.1 test yields the wrong result, Section 6.3.1 serves no 
> purpose and should just be deleted.
> 
> Also, while I like the idea of DNS UPDATE clients being able 
> effectively 
> to tag their records to help identify later who was responsible for 
> creating the record, I think the proposed DHCID solution is too 
> DHCP-centric. IPv6 clients using stateless address 
> autoconfiguration want 
> to use DNS UPDATE too, and in order to be good citizens, they 
> want to be 
> able to tell whether the records they're about to stomp all 
> over belong 
> to them or to a different DNS UPDATE client. We need a 
> tagging solution 
> that works for both v4 and v6, without pre-supposing DHCP.
> 
> This is more than a passing academic interest. Starting in 
> Mac OS X 10.4 
> Tiger, Apple now ships a Secure DNS UPDATE client:
> 
>    <http://www.dns-sd.org/ClientSetup.html>
> 
> We face exactly the problems raised in this draft. Some sites 
> configure 
> per-user keys, in which case there's no problem because conflicts are 
> simply not possible, because a user cannot update another's name. 
> However, for the sake of similicity many sites configure a 
> single site 
> key for DNS update, trusting the users to cooperate with each other. 
> Trusting users to cooperate is fine when the users are 
> trustworthy and 
> willing to cooperate, but even willing trustworthy users 
> can't cooperate 
> when the mechanisms for cooperation don't exist. Most people 
> are willing 
> to avoid stomping over someone else's name, but you can't 
> expect them to 
> do that if they have no reasonable way to know that the name 
> is someone 
> else's.
> 
> Stuart Cheshire <[email-masked]>
>  * Wizard Without Portfolio, Apple Computer, Inc.
>  * www.stuartcheshire.org
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Jun 2005 13:06:40 -0700

I think that the difference between what Stuart proposes and what is  
proposed in the draft is that if the name is taken, as the draft is  
now written, you only need to do one query.   If it's changed as  
Stuart proposes, then in this case you would have to try the update  
both ways.   In the case where the record exists and is tagged as  
having been created by the current client, you wind up doing a query  
and an update.   In the case where the record doesn't exist, you just  
do an update.

I actually had the same comment that Stuart had, a couple of drafts  
back, but didn't elect to actually say anything about it, because on  
a practical level I don't think it makes any difference, and I'm more  
concerned with getting the draft out than with getting exactly the  
right update algorithm into place, when it's not particularly clear  
to me which algorithm is actually better.

I will point out that in the case where you have a DHCP server  
running its queries through a caching name server, and where the  
server is not skipping updates that it "knows" have already been  
done, you're way better off doing a lookup before sending the update,  
because the lookup hits the cache, whereas the update has to go to  
the primary.   So there's at least a pretty good argument for  
claiming that even if the algorithm as described in the draft results  
in a higher total number of queries, as long as most of those queries  
wind up hitting the cache and not the primary, you still win.

As for the question of non-DHCP clients updating the DNS following  
autoconfiguration, this is a huge can of worms.   Let me point out a  
couple of things, though:

1. It's highly unlikely that any administrative domain is going to  
broadly distribute a TSIG key that can be used to update a DNS  
zone.   The opportunities for wreaking havoc in a configuration like  
this are just way too exciting for words.

2. As Stuart says, if individual TSIG keys are given out, there's no  
problem.

3. We have a serious key distribution problem with updates like  
this.   I think that in a real world use scenario, what you really  
want is for the client, whatever it is, to generate and negotiate a  
key with the DNS service, which is set up to accept initial key/name  
association for unclaimed names, possibly restricted based on the  
source IP address, or possibly subject to some out-of-band  
authorization scheme.   The key is hung off the name, and is a DNSSEC  
key, not a TSIG key.   The client then uses SIG(0) to do whatever it  
wants to records hanging off of that name.   Policy controls in the  
DNS server prevent abuse.

4. If you really do have a site where the TSIG key is widely  
distributed and cooperation is desired, the autoconfig software can  
always generate a DHCID record anyway.   It would have to know what  
client identifier its DHCP client is using.   This is the meat of the  
problem - distributing the disambiguation key.   Nothing in this  
draft precludes us from writing up a draft explaining how to have an  
autoconf client do a DNS update using a DHCID RR.   We do not need to  
hold up advancement of this draft based on that future work.

I would be very interested in working with you, Stuart, to write up  
drafts describing solutions (3) and (4) if you want to pursue them.    
I am very much opposed to holding up this draft in order to squeeze  
the documentation of either solution into it.   I'm also opposed to  
holding up this draft based on your concerns about the update algorithm.

Finally, Ralph, what the heck is up with this not passing last call  
because of no substantive comments?   Is it the case that we have to  
pick nits in order for the draft to advance?   If so, kudos to Stuart  
for doing so!   We have been working on this draft literally for as  
long as I've been in the IETF.   The reason there are no comments on  
it is that most of the people involved in the work are not reading  
the mailing list anymore - they consider the draft done.   No  
substantive changes have been made in years.   This draft needs to  
advance.   It needs to advance now.   It does not need a respin.

Please tell me who I have to sleep with to make this happen.   (No  
hanky-panky, sorry - I'm married.)

---

From: Ralph Droms <[email-masked]>
Date: Thu, 16 Jun 2005 16:38:12 -0400

Ted - the draft didn't pass last call because I found a bunch of
substantive comments in a doc that a few people said was "OK as is" and
most people didn't comment on at all.  I don't think it's quite baked,
yet.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Jun 2005 13:51:38 -0700

> most people didn't comment on at all.  I don't think it's quite baked,

I don't object to any of your comments, but I also don't see any of  
them as anything but editorial, and I think the draft is fine without  
them.   I think "not quite baked" isn't accurate.   I don't object to  
Bernie making the changes you've proposed.   However, as I say, these  
seem like editorial changes; I apologize for not commenting on the  
changes that you call "substantive," but when I originally read your  
message I didn't register that you considered them more than  
editorial, and I didn't object to any of them, so I didn't see any  
reason to comment.

Can we get a respin (please, without the algorithm changes Stuart  
proposed) and bring this back to last call right away, or is there  
something that you think stands in the way of this?

I'm sorry if my previous message seemed to make the point a little  
too strongly, but I am really surprised by all of this - I don't see  
an announcement of this decision in my inbox, so unless I somehow  
missed the announcement, Bernie's response to Stuart really was the  
first I'd heard of it.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 16 Jun 2005 17:10:33 -0400

Ted - many of the comments were editorial, but the first few I consider
substantive (I guess we'll have to agree to disagree on the
classification of those comments).  I believe that those issues would
have been caught by the IESG ... but it's our job to catch them before
they go to the IESG.

Even the editorial comments, I think, need to be addressed to make sure
we're producing high quality docs.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Jun 2005 14:18:01 -0700

On Jun 16, 2005, at 2:10 PM, Ralph Droms wrote:
> I guess we'll have to agree to disagree on the classification of  
> those comments
That's allowed!   :')

> I believe that those issues would
Sure.

> we're producing high quality docs.
That's fine.   However, it's always possible to find one more nit to  
correct in any document written by human beings.   So I would like to  
at least *try* to draw a line in the sand here.   Can we please get  
just the changes you've requested, and then say we're done?   No more  
editorial respins unless something painfully glaring is found?

I guess whether or not this works out depends on whether Stuart finds  
the reasoning in my response to him compelling; if not, we have to do  
some more debate anyway... :'}

---

From: Stig Venaas <[email-masked]>
Date: Sat, 25 Jun 2005 14:42:10 +0200

> >I guess we'll have to agree to disagree on the classification of  

Whatever classification, I agree with Ralph's comments and believe they
need to go into a new revision.

> editorial respins unless something painfully glaring is found?

So yes, I think we should address Ralph's comments. I agree with
trying to draw a line after that though.

> some more debate anyway... :'}

I believe Stuart is right that there is a possible non-dhcp issue
with IPv6 clients doing stateless autoconfiguration and dynamic
updates. Seems to me one should consider using the DHCID RR also
for such clients. Perhaps the only thing needed is to rename DHCID
to CID (client id) or something and possibly add a couple of
sentences to draft-ietf-dnsext-dhcid-rr-09.txt.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Sat, 25 Jun 2005 20:11:16 +0200

On Sat, Jun 25, 2005 at 02:42:10PM +0200, Stig Venaas wrote:
[...]
> sentences to draft-ietf-dnsext-dhcid-rr-09.txt.

Just to clarify. My point is that the name is a bit unfortunate
since I believe it might be used with other configuration mechs
than DHC. But the name isn't that important, so I don't want that
in itself to hold the draft back.

How other configuration mechanisms use this should be described
in separate drafts I think.

Stig