Re: [dhcwg] What sorts of services does DHCP configure?

Ted Lemon <ted.lemon@nominum.com> Wed, 16 October 2013 15:30 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9408C11E82F3 for <dhcwg@ietfa.amsl.com>; Wed, 16 Oct 2013 08:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.591
X-Spam-Level:
X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HKgBR1jhrEO for <dhcwg@ietfa.amsl.com>; Wed, 16 Oct 2013 08:30:12 -0700 (PDT)
Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0D06A11E82DA for <dhcwg@ietf.org>; Wed, 16 Oct 2013 08:30:11 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUl6xA97uspwtcifZeGTjBmD6cIy2ynRz@postini.com; Wed, 16 Oct 2013 08:30:12 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 97DD91B82E4 for <dhcwg@ietf.org>; Wed, 16 Oct 2013 08:30:11 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 8ECD219005C; Wed, 16 Oct 2013 08:30:11 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Oct 2013 08:30:11 -0700
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <525DC8E1.8050208@s-carlsen.dk>
Date: Wed, 16 Oct 2013 11:30:08 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <C1C4D4A6-CA2C-4FC0-B7B7-814801A15241@nominum.com>
References: <45A697A8FFD7CF48BCF2BE7E106F06040B734A24@xmb-rcd-x04.cisco.com> <771CAC3B-56AD-445E-AC97-75D6CB4521DB@nominum.com> <525DBC60.1080209@s-carlsen.dk> <1ABC4971-1E44-4146-BEF5-A6BB3146E137@nominum.com> <525DC09B.5080703@s-carlsen.dk> <71D33595-0CE9-42CD-A572-D6C80DA9BA74@nominum.com> <525DC8E1.8050208@s-carlsen.dk>
To: Sten Carlsen <stenc@s-carlsen.dk>
X-Mailer: Apple Mail (2.1812)
X-Originating-IP: [192.168.1.10]
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>
Subject: Re: [dhcwg] What sorts of services does DHCP configure?
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2013 15:30:18 -0000

On Oct 15, 2013, at 6:59 PM, Sten Carlsen <stenc@s-carlsen.dk> wrote:
> I tend to look at this from the opposite side, what are the services that need to be configured and infomation that needs to be delivered? And as a consequence what are the tools?
> What is in the toolbox now and what is missing? Some of the missing tools are leading to ugly hacks now.
> The answer might not be DHCP, but then what is it?

I don't think the missing tools are causing us to do ugly hacks.   I think that the problems I am talking about are actually being handled perfectly well.   E.g., SMTP is generally configured manually by the end user, and there is no way to make this better using DHCP, which is why it hasn't been done.   NTP is generally hard-coded as an FQDN into the operating system, but overridable by the end-user.

Although there is an NTP option for DHCP, and it is implemented in some cases, it is not widely used, for reasons that seem obvious to me: NTP is required for replay detection, and so trusting the DHCP server to tell you what your NTP server is isn't secure.   There is actually a standard in the RFC editor queue that makes support for the NTP option mandatory in home routers, which I expect will happen, and I expect that roughly zero devices will actually request this option on a home network.   It's possible that IoT devices will, but I'll believe it when I see it.