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

Danny Mayer <> Mon, 02 December 2013 00:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0513B1AE212 for <>; Sun, 1 Dec 2013 16:31:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ic-JisuIabp8 for <>; Sun, 1 Dec 2013 16:31:45 -0800 (PST)
Received: from ( [IPv6:2001:4f8:fff7:1::5]) by (Postfix) with ESMTP id 15E4E1AE297 for <>; Sun, 1 Dec 2013 16:31:44 -0800 (PST)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1VnHQJ-0004FJ-DI; Mon, 02 Dec 2013 00:31:40 +0000
Message-ID: <>
Date: Sun, 01 Dec 2013 19:31:11 -0500
From: Danny Mayer <>
Organization: NTP
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Ted Lemon <>, Olafur Gudmundsson <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on
Cc: NTP Working Group <>, " WG" <>, "Bernie Volz \(volz\)" <>
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 00:31:47 -0000

On 12/1/2013 5:29 PM, Ted Lemon wrote:
> On Dec 1, 2013, at 5:05 PM, Olafur Gudmundsson <> wrote:
>> The "threat" the document is trying to address, device wants to
DNSSEC or CERT validation but clock is far off thus VALID credentials
fail validation.
> Ah, thanks for explaining. This is what I was missing—you're not
> doing
this to avoid a threat at all, but rather to simply make DNSSEC work in
a possibly non-secure mode until such time as you can bootstrap better
time information.
> This would be worth mentioning in the introduction and/or the
> security
considerations section. You allude to it in the security considerations,
but it's pretty oblique.
> It is worth pointing out that NTP doesn't actually need DNS to
work—DHCP can deliver NTP server addresses as IP addresses. That said,
this option seems to add value, since there is no guarantee that devices
that implement the existing DHCP NTP will not send FQDNs rather than IP

I had a long discussion with Bernie over the issue of delivering NTP IP
addresses via DHCP. We understand the issues you raised concerning
DNSSEC and have no disagreement about that. The problem is that for NTP
DNS names are preferred over IP addresses because that allows a server
maintainer to retire an NTP server. With an IP address there is no
chance that your local instance will know about this and continue to
bombard the old address. Moreover the newer pool option cannot be used
to any advantage.

When was the last time you looked at your NTP configuration and verified
that all of the servers listed are still valid? How often will DHCP
servers do this as a matter of course before providing such
provisioning? We have systems that are being bombarded by requests even
though no NTP server is responding to queries. We have plenty of
evidence of this. Even worse we have seen home routers which have
hard-coded IP addresses for NTP servers embedded. How long are those
going to be in operation?

I think we need to figure out how to get around the Catch-22 situation
of DNSSEC requiring relatively good time and NTP wanting to be able to
use DNS to find valid NTP servers.

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.