Re: [dhcwg] Trust model of Client FQDN option

how an administrator controls dns updates is not _really_ a dhcp protocol 
issue. there is no standardized way to express dns update policy, and, as a 
policy issue, it's not really an ietf issue at all, in my opinion. I can 
think of several possible ways that a dns administrator might configure his 
or her dns servers:

1. use a zone-wide TSIG key and allow any update to any name, trusting any 
updater who presents a valid TSIG key

2. provision a different key for each name; only allow an updater to update 
a name if it presents the 'right' key for that name

3. use zone-wide TSIG keys, but prohibit dns updates to some names, period

now (1) is a bit weak, though it is used, and (2) presents a significant 
key-distribution hurdle. (3) is frequently done in the field, and we have 
years of field experience with it in v4.

having a dhcp option that carries an fqdn does not give any client license 
to use the server as a dns update proxy. it also does not relieve dns 
administrators of the responsibility to establish some policy about 
updates. there are sites that don't allow _any_ updates from anyone - 
that's a valid policy too. for many other sites, however, having a dhcp 
server and then a dns server each have an opportunity to apply some policy 
about the names that can be updated is efficient and effective.

perhaps you'd like it if some drafts' security considerations sections 
said: "watch out, because some dhcp client might present 'www' in its FQDN 
option, and you might not want to let that update happen." that'd be fine, 
but that's about as far as it can go, because there is a wide range of 
update policies in place in the field.

-- Mark

At 02:05 AM 8/4/2004 +0300, Pekka Savola wrote:
>On Tue, 3 Aug 2004, Ted Lemon wrote:
> > On Aug 3, 2004, at 11:03 AM, Pekka Savola wrote:
> > > I'm not sure the v4 or v6 DHC FQDN client options address the problem
> > > of the trust model for the update content sufficiently well.  I'd even
> > > go as far to say that it might create a false sense of security.
> >
> > Pekka, in the meeting this morning, you said you hadn't read the drafts
> > having to do with DNS updates on DHCPv4.   Have you now read them?
>
>Yes; I scanned through draft-ietf-dhc-fqdn-option and the dnxext dhcrr
>document.
>
> > The reason I ask is that for the entire duration of the time I've been
> > coming to IETF, people have occasionally raised the very same issue you
> > are now raising.
>
>Maybe this would stop if these issues would actually be adequately
>addressed?  I promise to bring this up again at the last minute if
>not.
>
>What you describe below is very well, and probably addresses most of
>the issues (to a certain degree, which should be spelled out), but
>none of this seems to exist written in the clear in
>draft-ietf-dhc-fqdn-option.
>
>Let's look at its Security Considerations section (the others don't
>include anything relevant to this, AFAICS):
>
>1st paragraph: generic text about DNS update authentication
>requirements
>
>2nd: notes the two approaches (client vs dhcp updated), and that they
>depend e.g., on security model (without going into details)
>
>3rd: generic text wrt. whether DHCP server would always do the updates
>or not
>
>4th: notes the lack of authentication of the user, given that DHCP
>authentication is not there or is not deployed.  Ascertaining the
>identty of the client is difficult. [note: DHCP authentication has
>very little to do with the authorization of the client to update a
>specific name]
>
>5th: describes scenarios where you might not be able to spoof DHCP
>packets, and a little text about being able to trust (in some cases)
>the dhc client id. [note: spoofing or not spoofing DHCP packets, and
>DHC client id do not yet provide any authorization to update a DNS
>name]
>
>I also note that the draft doesn't even mention
>draft-ietf-dnsext-dhcid-rr-08.txt.
>
>The actual meat is missing, and does not address *DNS name*
>authorization at all, just talks quite a bit about DHCP authentication
>and different ways to eliminate DHCP spoofing.
>
> > The solution we have adopted, which is widely deployed, allows two
> > answers to your question.   The first is a more paranoid solution that
> > requires widespread distribution of individual DNS update keys.   The
> > second is a more laissez-faire solution that does not require the
> > distribution of individual DNS update keys.   This second solution is
> > no more or less secure than the first, but its behavior is different.
> > Names added by the DHCP server are marked as such, and if a name is
> > present and was not added by the DHCP server, that name can't be
> > replaced at the request of the DHCP client.   When a client's lease
> > expires, another client can acquire the previous client's name, so
> > there's no protection for client names.   You get to pick which
> > solution to deploy, based on your willingness to distribute keys and
> > based on whether or not you care whether a DHCP client can count on
> > retaining its name, once its name is registered.
>
>--
>Pekka Savola                 "You each name yourselves king, yet the
>Netcore Oy                    kingdom bleeds."
>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg