Re: [dhcwg] Trust model of Client FQDN option
Ted Lemon <mellon@fugue.com> Tue, 03 August 2004 22:30 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18254; Tue, 3 Aug 2004 18:30:05 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7ie-0003RI-LF; Tue, 03 Aug 2004 18:25:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs7cn-0002n7-Jd for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 18:19:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17700 for <dhcwg@ietf.org>; Tue, 3 Aug 2004 18:19:10 -0400 (EDT)
Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs7ft-0002bv-WB for dhcwg@ietf.org; Tue, 03 Aug 2004 18:22:29 -0400
Received: from [66.93.162.248] (0127bhost250.starwoodbroadband.com [12.105.247.250]) by toccata.fugue.com (Postfix) with ESMTP id ACA0B1B29EB; Tue, 3 Aug 2004 17:18:20 -0500 (CDT)
In-Reply-To: <Pine.LNX.4.44.0408032048200.24865-100000@netcore.fi>
References: <Pine.LNX.4.44.0408032048200.24865-100000@netcore.fi>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <21E7AC38-E59B-11D8-8860-000A95D9C74C@fugue.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon <mellon@fugue.com>
Subject: Re: [dhcwg] Trust model of Client FQDN option
Date: Tue, 03 Aug 2004 15:19:05 -0700
To: Pekka Savola <pekkas@netcore.fi>
X-Mailer: Apple Mail (2.618)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit
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? 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. 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. So this is a well-understood problem, with well-understood and widely deployed solutions. You can see an example implementation in the ISC DHCP client and server if you're curious, and as far as I know every commercial DHCP server also implements this, and I know of quite a few sites that use it in practice. Indeed, it's been deployed at IETF meetings in the past (not sure if it's running this time). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Trust model of Client FQDN option Pekka Savola
- Re: [dhcwg] Trust model of Client FQDN option Ted Lemon
- Re: [dhcwg] Trust model of Client FQDN option Pekka Savola
- RE: [dhcwg] Trust model of Client FQDN option Bernie Volz
- RE: [dhcwg] Trust model of Client FQDN option Bernie Volz
- Re: [dhcwg] Trust model of Client FQDN option Mark Stapp
- RE: [dhcwg] Trust model of Client FQDN option Pekka Savola
- Re: [dhcwg] Trust model of Client FQDN option Ted Lemon
- RE: [dhcwg] Trust model of Client FQDN option Bernie Volz
- Re: [dhcwg] Trust model of Client FQDN option Ted Lemon
- RE: [dhcwg] Trust model of Client FQDN option Bernie Volz
- Re: [dhcwg] Trust model of Client FQDN option Ted Lemon