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

Mark Stapp <mjs@cisco.com> Mon, 27 August 2001 16:50 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24232; Mon, 27 Aug 2001 12:50:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26611; Mon, 27 Aug 2001 12:49:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26586 for <dhcwg@ns.ietf.org>; Mon, 27 Aug 2001 12:49:15 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24127 for <dhcwg@ietf.org>; Mon, 27 Aug 2001 12:47:51 -0400 (EDT)
Received: from mjs-nt.cisco.com ([172.27.181.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA17656; Mon, 27 Aug 2001 12:48:37 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010827104131.031063b0@funnel.cisco.com>
X-Sender: mjs@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 27 Aug 2001 12:48:27 -0400
To: cheshire@apple.com
From: Mark Stapp <mjs@cisco.com>
Cc: dhcwg@ietf.org
In-Reply-To: <200108250531.f7P5Vlw17510@scv2.apple.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [dhcwg] Re: Last call for <draft-ietf-dhc-ddns-resolution-02.txt>
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

Stuart,

At 10:31 PM 8/24/01 -0700, Stuart Cheshire wrote:
> >   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".

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.

> >   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?

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.


> >   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.

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.

>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.

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.

>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?

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.

>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.

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
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg