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

Olafur Gudmundsson <ogud@ogud.com> Mon, 02 December 2013 13:14 UTC

Return-Path: <ogud@ogud.com>
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 D3E5A1AE21A for <dhcwg@ietfa.amsl.com>; Mon, 2 Dec 2013 05:14:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_RRWykK-Szk for <dhcwg@ietfa.amsl.com>; Mon, 2 Dec 2013 05:14:02 -0800 (PST)
Received: from smtp82.ord1c.emailsrvr.com (smtp82.ord1c.emailsrvr.com [108.166.43.82]) by ietfa.amsl.com (Postfix) with ESMTP id B6D9A1ADF78 for <dhcwg@ietf.org>; Mon, 2 Dec 2013 05:14:01 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 95ACB500CE; Mon, 2 Dec 2013 08:13:59 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 0F08350089; Mon, 2 Dec 2013 08:13:56 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <20131202044734.B78E0406060@ip-64-139-1-69.sjc.megapath.net>
Date: Mon, 2 Dec 2013 08:13:56 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <25AE7031-096A-4F01-B754-7FAC4D4F8E84@ogud.com>
References: <20131202044734.B78E0406060@ip-64-139-1-69.sjc.megapath.net>
To: Hal Murray <hmurray@megapathdsl.net>
X-Mailer: Apple Mail (2.1510)
Cc: NTP Working Group <ntpwg@lists.ntp.org>, Bernie Volz <volz@cisco.com>, Ted Lemon <ted.lemon@nominum.com>, "dhcwg@ietf.org WG" <dhcwg@ietf.org>
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
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 13:14:05 -0000

On Dec 1, 2013, at 11:47 PM, Hal Murray <hmurray@megapathdsl.net> wrote:

> Does DNS using DNSSEC return a specific error code for time-invalid?  Or just 
> a generic didn't-work?
> 

RCODE==SERVFAIL, 

> How close does the time have to be for DNSSEC to work?

somewhere between a month and an hour depending on what device is looking up
for X.509 this might be somewhere between a year and a minute 
it all depends on how close to the edge the providers of Validatable Signatures still keep using them. 


> 
> 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.
> 

IFF there were enough NTP servers on a any cast addresss that might work most of the time. 
The draft is proposing to do this via naturally distributed solution the local DHCP server or router for ND, thus eliminating the need
for any additional infrastructure, this is based on the assumption that these "servers" have decent idea what the current time is. 

The problem in nutshell is that devices have to use their own time source or a distant one. 
To me it seems having a local (i.e. on local network but off device) is a reasonable starting point to get to the great distant one. 

> 
> 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?
> 
> 

DHCP NAMESERVER option returns the IP address of the DNS resolvers, 

	Olafur