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

Danny Mayer <mayer@ntp.org> Mon, 02 December 2013 05:27 UTC

Return-Path: <mayer@ntp.org>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884C01AE3D0 for <dhcwg@ietfa.amsl.com>; Sun, 1 Dec 2013 21:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrQdLkO5tCTX for <dhcwg@ietfa.amsl.com>; Sun, 1 Dec 2013 21:27:42 -0800 (PST)
Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by ietfa.amsl.com (Postfix) with ESMTP id 36EE71AE269 for <dhcwg@ietf.org>; Sun, 1 Dec 2013 21:27:42 -0800 (PST)
Received: from static-108-1-140-117.bstnma.east.verizon.net ([108.1.140.117] helo=[10.10.10.102]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from <mayer@ntp.org>) id 1VnM2i-0005zH-Q1; Mon, 02 Dec 2013 05:27:38 +0000
Message-ID: <529C1A31.2080900@ntp.org>
Date: Mon, 02 Dec 2013 00:27:13 -0500
From: Danny Mayer <mayer@ntp.org>
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: Hal Murray <hmurray@megapathdsl.net>, Ted Lemon <ted.lemon@nominum.com>
References: <20131202044734.B78E0406060@ip-64-139-1-69.sjc.megapath.net>
In-Reply-To: <20131202044734.B78E0406060@ip-64-139-1-69.sjc.megapath.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 108.1.140.117
X-SA-Exim-Rcpt-To: hmurray@megapathdsl.net, ted.lemon@nominum.com, ntpwg@lists.ntp.org, dhcwg@ietf.org, volz@cisco.com, ogud@ogud.com
X-SA-Exim-Mail-From: mayer@ntp.org
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail1.ntp.org)
Cc: NTP Working Group <ntpwg@lists.ntp.org>, "dhcwg@ietf.org WG" <dhcwg@ietf.org>, Bernie Volz <volz@cisco.com>
Subject: Re: [dhcwg] [ntpwg] Fwd: New Version Notification for draft-ogud-dhc-udp-time-option-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mayer@ntp.org
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: Mon, 02 Dec 2013 05:27:43 -0000

On 12/1/2013 11:47 PM, Hal Murray wrote:
> Does DNS using DNSSEC return a specific error code for time-invalid?  Or just 
> a generic didn't-work?
> 
> How close does the time have to be for DNSSEC to work?
> 

That's a question that should be asked in the dnsext WG mailing list
(though technically the Working Group is now closed). Olafur and I
(apart from Ted who is IETF area director) are probably the only ones on
these lists who participate in that mailing list. Olafur was one of the
cochairs of the DNS ext working group.

The document does not describe the DNSSEC requirements for accurate time
and probably should so that it can be assessed in that light.
The ones I know about are RRSIG inception time and expiration time and
then there are certificate expiration date-times.

The proposal seems to suggest that a timestamp in 64-bit time_t be
distributed by DHCP. I'm not sure why not a NTP timestamp instead.
However most systems running a DNS server is likely to have a static
address in the first place and that is what DHCP distributes as
nameservers to query. Since they use static addresses do they
participate in DHCP services at all? And who says that the DHCP server
itself has accurate time?

> Could this problem be solved by setting up a bank of NTP servers at well 
> known IP Addresses?  Say, one next to each root DNS server.  If you tried to 
> do that, I'd expect a serious problem would be overload because idiots would 
> try to use them for normal NTP use rather than just getting off the ground.  
> It might be possible to discourage that by making them return crappy time.
> 

No, it would just overwhelm them. See the NIST time servers for an
example of heavy load.

> 
> ted.lemon@nominum.com said:
>> 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. 
> 
> Most ISPs already provide DNS servers for their customers.  How do their IP 
> address get setup in home routers?  Could NTP servers piggyback on that 
> mechanism if ISPs also provided NTP servers?

I wish they would provide NTP services in the same way. Unfortunately
although most ISP's will have NTP servers they do not usually tell their
customers about them and they certainly do not provide authenticated
packets like autokey.

Danny