RE: [dhcwg] Trust model of Client FQDN option

"Bernie Volz" <volz@cisco.com> Wed, 04 August 2004 18:42 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 OAA27612; Wed, 4 Aug 2004 14:42:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQQN-0005Rp-3H; Wed, 04 Aug 2004 14:23:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQKo-0004Hr-7b for dhcwg@megatron.ietf.org; Wed, 04 Aug 2004 14:17:54 -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 OAA25485 for <dhcwg@ietf.org>; Wed, 4 Aug 2004 14:17:52 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsQO7-0005GQ-Pf for dhcwg@ietf.org; Wed, 04 Aug 2004 14:21:21 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2004 11:19:05 -0700
X-BrightmailFiltered: true
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i74IHGSK013153; Wed, 4 Aug 2004 11:17:17 -0700 (PDT)
Received: from volzw2k (sjc-vpn4-15.cisco.com [10.21.80.15]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AKP42380; Wed, 4 Aug 2004 14:17:16 -0400 (EDT)
From: "Bernie Volz" <volz@cisco.com>
To: "'Ted Lemon'" <mellon@fugue.com>
Subject: RE: [dhcwg] Trust model of Client FQDN option
Date: Wed, 4 Aug 2004 14:18:41 -0400
Organization: Cisco
Message-ID: <000201c47a4f$78a634e0$3f428182@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.5709
In-Reply-To: <C3FD5408-E63D-11D8-8860-000A95D9C74C@fugue.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
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

And, we probably should add a 4th point ... If a DNS server allows dynamic
DNS updates, it is the final authority of what it allows to be added,
removed, or modified in a zone and should have properly configured policies
to prohibit operations that are not intended. Simply assuming that any
update from a trusted source (such as a DHCP server with a valid TSIG key)
should be performed is likely not acceptable.

- Bernie

> -----Original Message-----
> From: Ted Lemon [mailto:mellon@fugue.com] 
> Sent: Wednesday, August 04, 2004 1:43 PM
> To: Bernie Volz
> Cc: <dhcwg@ietf.org>
> Subject: Re: [dhcwg] Trust model of Client FQDN option
> 
> 
> On Aug 4, 2004, at 10:17 AM, Bernie Volz wrote:
> > -> If the query returns NODATA, the updater can conclude that the
> > target
> > -> name is in use, but that no DHCID RR is present.  This indicates
> > that
> > -> some records have been configured by an administrator.  
> Whether the 
> > -> updater proceeds with an update is a matter of local 
> administrative 
> > -> policy.
> 
> Hm, this is interesting.   As a point of information, the two 
> implementations with which I am familiar do not give the 
> administrator 
> a knob to tweak here.  We just assume that if the name is in the DNS 
> and doesn't have a DHCID (well, TXT) record, we shouldn't scribble on 
> it.
> 
> I think a stronger statement here might be better:
> 
> Whether the updater proceeds with an update is a matter of local 
> administrative policy.   DHCP servers MUST NOT proceed with 
> the update 
> unless explicitly configured to do so.
> 
> The draft should talk about these two issues in the security 
> considerations section, and the FQDN drafts should mention in the 
> security considerations section that these security 
> considerations are 
> addressed in the resolution draft.   I don't think we can make any 
> requirements to address this, but the answers we came up with in 
> response to Pekka's query could reasonably go into the security 
> considerations section of one or all of the drafts:
> 
> 1. If the DHCP server does updates, there is no way to prevent one 
> client from getting a name after another client had it, but that 
> client's lease expired.
> 
> 2. If the DHCP server does updates, it will be possible for DHCP 
> clients to request names that might have special meaning, like www or 
> wwww.   This can be handled in one of two ways:
>    a. Use a special zone for dynamic names, so that it doesn't
>       matter that the client gets www.dyndns.bigcompany.org, or
>    b. If the DHCP server provides this capability, set up a
>       filter on the DHCP server that prevents certain names from
>       being claimed by clients, even if they do not currently
>       appear in the DNS.
> 
> 3. If the DHCP server does updates, and is allowed to override names 
> that do not have DHCID records, this can mean that a client 
> will get a 
> name that is already registered for some purpose in the DNS.   This 
> behavior is required to be disabled by default, so it should not be a 
> problem in practice, but we mention it here to raise awareness of the 
> implications of configuring your DHCP server to allow it.
> 
> Hm, one other problem that occurs to me is that a client could send 
> something like "www.students" in the fqdn option, and this could turn 
> into "www.students.littlecollege.edu".   That is a vaguely 
> official-looking name.   So any filtering that needs doing based on 
> specific reserved names like "www" needs to be on the first label in 
> the name, not on the entire name.
> 


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