[dhcwg] Trust model of Client FQDN option

Pekka Savola <pekkas@netcore.fi> Tue, 03 August 2004 18:33 UTC

Received: from megatron.ietf.org (megatron.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00270; Tue, 3 Aug 2004 14:33:31 -0400 (EDT)
Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3pO-0002tR-T8; Tue, 03 Aug 2004 14:15:58 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bs3dR-00086D-2e for dhcwg@megatron.ietf.org; Tue, 03 Aug 2004 14:03:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27594 for <dhcwg@ietf.org>; Tue, 3 Aug 2004 14:03:35 -0400 (EDT)
Received: from netcore.fi ([]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bs3gX-0006Qg-5n for dhcwg@ietf.org; Tue, 03 Aug 2004 14:06:50 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i73I32e25363 for <dhcwg@ietf.org>; Tue, 3 Aug 2004 21:03:02 +0300
Date: Tue, 03 Aug 2004 21:03:02 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: dhcwg@ietf.org
Message-ID: <Pine.LNX.4.44.0408032048200.24865-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Subject: [dhcwg] Trust model of Client FQDN option
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


(not subscribed..)

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.

The issue is that as the DNS server will be configured to trust the
DHCP server for these updates, how could the DHCP server ensure that
the Client is authorized to insert that FQDN -> IP mapping.  This is
basically deemed outside of the scope of the spec, without providing
the means in the spec to do that properly.

A suggestion is that the DHCP server includes policy information which
updates would be acceptable.  I do not think this addresses the real 
problem: if such policy is available, why does the client need to send 
the FQDN in the first place -- the DHCP server should just be 
configured to update the FQDN corresponding to a particular client to 
map to the IP address of that client; the client doesn't need to 
specify it if this will need to be included in the policy 
configuration in any case.  So, in this kind of scenario, you 
shouldn't actually need the Client FQDN option here, just the magic in 
the DHCP server to update the IP address of a particular client 

Therefore, the client should probably be able to insert a TSIG or some
other signature which the DHCP server could use for updating; this
would authorize the update (in case TSIG validation succeeds) or not
without manually configured policy lists.

(A reason why DHCP server could update the FQDN to the DNS server
might be that the ISP wants to restrict access to the DNS updates to a
smaller number of hosts.)

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