Re: [dhcwg] Fwd: New Version Notification for draft-ogud-dhc-udp-time-option-01.txt

Olafur Gudmundsson <> Mon, 02 December 2013 13:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1EACD1AE474 for <>; Mon, 2 Dec 2013 05:20:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S2hiTNmCzKeG for <>; Mon, 2 Dec 2013 05:20:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9C7A21AE428 for <>; Mon, 2 Dec 2013 05:20:37 -0800 (PST)
Received: from localhost (localhost.localdomain []) by (SMTP Server) with ESMTP id 67DCD1B8141; Mon, 2 Dec 2013 08:20:35 -0500 (EST)
X-Virus-Scanned: OK
Received: by (Authenticated sender: with ESMTPSA id 01EB81B810F; Mon, 2 Dec 2013 08:20:34 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson <>
In-Reply-To: <>
Date: Mon, 2 Dec 2013 08:20:33 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Ted Lemon <>
X-Mailer: Apple Mail (2.1510)
Cc: NTP Working Group <>, Bernie Volz <>, " WG" <>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-ogud-dhc-udp-time-option-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Dec 2013 13:20:39 -0000

On Dec 1, 2013, at 9:36 PM, Ted Lemon <> wrote:

> On Dec 1, 2013, at 7:31 PM, Danny Mayer <> wrote:
>> We need a joint agreement on how to deal with this between DHCP and NTP
>> Working Groups assuming that is a viable option in the first place.
>> RFC5908 was not a good indication of this.
> RFC 5908 got approved pretty much accidentally, without finishing the review process in the DHC working group.   It was a major screwup, and I don't precisely know how it happened.   It doesn't really do what you wanted, and it certainly doesn't do what we wanted.   I agree that this needs to be resolved, but the resolution has to be based on reasoning, not an instinctive reaction to past pain.
> I'm not even convinced that DHCP is the right way to distribute NTP server information.   I suspect Olafur may be thinking about the case that's more common at present, which is that an FQDN is hard-coded into the O.S. distribution, and resolved at startup time.   In that case, DHCP's ability to deliver NTP server IP addresses doesn't help.

> As for the home router use model, it may be that what you really want is for the home router to query for an FQDN-only DHCP option from the ISP DHCP server, and then resolve that FQDN and respond to DHCP clients on the homenet with an IP address.   Since the FQDN is not hard-coded, and the IP address is (one hopes) resolved either at query time or when its TTL expires, this ought to prevent a repeat of the firmware burn-in incident.

Strictly speaking there is no difference between OS burned in NTP server name and DHCP server provided NTP server name, both 
require DNS resolution, root zone is signed, thus if the box wants to do DNSSEC validation as soon as it can, we end up with one of: 
	disable DNSSEC 
	false negative on validation 

repeat for any protocol that wants to open TLS or IPSEC connection before NTP completes. 
Giving out a NTP server address (as in IP address)  that is outside "local" net is not responsible behavior.

Right now for inexpensive boxes we have a choice of "real-bad" and "outstanding" time source, I'm advocating for something in the middle 
i.e. quick-and-close time for the devices that do not keep time when off. 

When been doing research on Open Recursive DNS Resolvers we keep finding more and more devices that answer all questions with 
answers that are basically current time either in binary, or text. This to me implies that there is hidden need for quick-and-dirty time. 

If you have not been following the changes in DNS, there is a push to move the resolution/validation to edge i.e. run resolver/validators on edge devices or even in applications as the "ISP" resolvers can not be counted on to do DNSSEC, and in many cases play games with answers.