Subject: Re: Last call for <draft-ietf-dhc-ddns-resolution-02.txt>

From: Stuart Cheshire <[email-masked]>
Date: Fri, 24 Aug 2001 22:31:45 -0700

>   Furthermore, this specification
>   applies only to DHCP client and server processes: it does not apply
>   to other processes which initiate DNS updates.

Same comment as for draft-ietf-dhc-fqdn-option: Protocol specifications 
need to specify what packets are valid on the wire -- how the code is 
implemented shouldn't matter. If two hosts send identical packet 
sequences, it makes no sense to say that one is legal and the other is 
not because one host used different "processes" to send the packets and 
the other host did it using a single "process".

>   At many sites, the difficulties with distributing DNS update
>   credentials to all of the DHCP clients lead to the desire for the
>   DHCP servers to perform A RR updates on behalf of their clients.

If the clients don't have any credentials to prove they are not rogue 
clients, how secure is it to allow rogue clients to ask a middleman to do 
updates for them?

>   FOr this purpose, a DHCID RR, described in [6], is used to associate
>   client identification information with a DNS name and the A or PTR
>   RR associated with that name. When either a client or server adds an
>   A or PTR RR for a client, it also adds a DHCID RR which specifies a
>   unique client identity (based on a "client specifier" created from
>   the data in the client's DHCPREQUEST message). In this model, only
>   one A RR is associated with a given DNS name at a time.

I don't think this works.

The purpose of the DHCID RR is to protect against two clients that are 
accidentally configured to think they have the same host name.

Adding the DHCID RR is just another level of indirection to the same 
problem: what do you do if two clients are accidentally configured to 
think they have the same DHCID?

If the DHCID RR is derived from the Client Identifier Option (code 61) 
then there's no protection against two clients being accidentally 
configured with the same value, so this option hasn't solved the "unique 
identifier" problem.

If the DHCID RR is derived from the client's link-layer network address, 
then it is harder to have accidental collisions because user's don't 
normally manually set their link-layer address, but now you have the 
opposite problem: false negatives, as described below:

What about the user who uses a laptop on Ethernet in the office, and then 
uses 802.11 wireless in the conference room, and then uses PPP over a 
modem when dialing in from home?

When they leave their office Ethernet try to access the network from the 
conference room using wireless, the DNS update will fail because they are 
accessing the network from a different link-layer address, so they appear 
to be a different client trying to steal a DNS name that's already in use.

When they dial in from home in the evening, their modem doesn't even have 
a link-layer address to use to derive the DHCID.

Even supposing that they are connecting from home using a 802.11 wireless 
and a DSL line, so they do have a link-layer address, what chance is 
there that the Cisco DNS servers are going to let Pacific Bell's DHCP 
servers do unauthenticated DNS updates?

I think the main benefit of Dynamic DNS updates is to allow mobile 
clients to be reached using a constant name, no matter where they are. I 
think a mobility solution that only works as long as users don't leave 
their office Ethernet has limited applicability.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: Mark Stapp <[email-masked]>
Date: Mon, 27 Aug 2001 12:48:27 -0400

Stuart,

>the other host did it using a single "process".

The motivation for the sentence you quote is pretty simple: the rr and the 
MUSTs and SHOULDs for noticing and using it are designed to address the 
needs of the DHCP community. The rr is not a general-purpose 'identifier 
rr'. The method for computing its data is explicitly tied to DHCP message 
data. It seemed more direct to say that up-front rather than leave it as an 
implication of the specification. Other situations involving other updaters 
of DNS are outside the scope of the DHC WG.

>clients, how secure is it to allow rogue clients to ask a middleman to do

There is certainly a level of administrative control that can be exercised 
by limiting dns update credentials to the DHCP servers. The sentence you 
quote is about distributing DNS update credentials, based on the 
observation that it may be more practical to distribute them to a few 
servers rather than to very many clients. The alternative is also, of 
course, valid: clients may be assigned credentials that allow them to 
update some name or names. Both of these specifications say explicitly that 
there's no DHCP security right now, and that unsecured DNS updates are a 
bad idea. But DHCP works acceptably in some places in spite of its security 
flaws.

>configured with the same value, so this option hasn't solved the "unique

Absolutely - this method does not prevent accidental or malicious 
misconfigurations. But from the perspective of the dhcp servers, two hosts 
presenting the same CID are the same client, so there are several problems 
that this particular misconfiguration will cause, and which aren't 
addressed by the existing DHCP specification.

>a link-layer address to use to derive the DHCID.

Quite correct. This is an issue with DHCP in general. This single host with 
multiple CIDs is seen as more than one client by most DHCP servers: that's 
the way the protocol works. This is the problem with CIDs that vary with 
the link-layer: it would be useful if clients allowed a stable identifier 
to be configured, or could generate and remember one.

>servers do unauthenticated DNS updates?

None at all: see my explanation of administrative domains in the previous 
email. I'd expect that the pacbell dhcp servers might update some zones 
that pb controls, not that they'd arbitrarily initiate updates to zones 
that they have no credentials to update.

>their office Ethernet has limited applicability.

That assertion is really about mobility and the dns protocols, though it 
may valid for some portion of the dhcp clients in the world. You've 
addressed your needs by obtaining DNS service that is independent of your 
DHCP service (and even of whether or not you're using DHCP.) Personally, I 
don't particularly care whether my laptop can be 'reached' using a stable 
dns name when I'm roaming. Most of the time, I'm behind someone's firewall 
or on a VPN where my host couldn't accept an incoming smtp, ftp, or http 
connection anyway. It works much better for me to use other servers to hold 
my mail and serve my public data. When I'm roaming, I don't really need to 
be 'pingable', and my IP reachability is often so restricted that a 
'constant' dns name wouldn't matter.

I don't think that the configuration you use is prohibited by the 
specifications under discussion. If you think that it is, would you please 
send me some examples of specific clarifications that would help you? Or is 
there something that should be added to the introduction section somewhere 
that would better delineate where this specification applies and where it 
doesn't? I think that the sentences about non-DHCP client processes pretty 
much address your case, but if they're not adequate, I'd like to improve them.

Thanks,
Mark

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