This discussion highlights the importance of making sure that hardware vendors 
understand the need for working clocks that can be easily bootstrapped.  In 
addition to NTP radio clock receivers are ubiquitous, tiny and ridiculously 
cheap.  It is unconscionable that any consumer electronics are sold today that 
boast a visible clock without including a radio clock receiver!  This doesn't 
fix the mountain of already deployed SOHO gear, but it is time for vendors that 
know better (Cisco, Netgear, D-Link, etc.) to do the right thing.

I put entropy in a similar class of problem as radio clock receivers.  There 
are a number of reasonable sources for entropy that take up virtually no PCB 
space and can be built with a few discrete components (thinking of quantum 
effects between 2 transistor gates or zener breakdown noise on a zener diode).  
Stronger entropy sources get expensive - but something that provides reasonable 
entropy for light crypto should be available on SOHO class network gear.

On Sep 12, 2013, at 2:19 PM, robert bownes wrote:

> 
> Chiming in a bit late here, however, the availability of stratum 1 clocks and 
> stratum 2 class time data on non IP and/or non interconnected networks is now 
> so large, I question why one would run NTP outside of the building in many 
> cases, certainly in an enterprise of any size.
> 
> A 1pulse per second aligned to GPS is good to a few ns. Fairly 
> straightforward to plug into even a OpenWrt type of router. Turn on the pps 
> in NTP on the router and you are good to go. 
> 
> 
> 
> 
> 
> On Tue, Sep 10, 2013 at 6:45 PM, Evan Hunt <e...@isc.org> wrote:
> On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote:
> > My colleagues and I worked on OpenWrt routers to get Unbound to work
> > there, what you need to do is to start DNS up in non-validating mode wait
> > for NTP to fix time, then check if the link allows DNSSEC answers
> > through, at which point you can enable DNSSEC validation.
> 
> That's roughly what we did with BIND on OpenWrt/CeroWrt as well.  We
> also discussed hacking NTP to set the CD bit on its initial DNS queries,
> but I don't think any of the code made it upstream.
> 
> My real recommendation would be to run an NTP pool in an anycast cloud of
> well-known v4 and v6 addresses guaranteed to be reliable over a period of
> years. NTP could then fall back to those addresses if unable to look up the
> server it was configured to use.  DNS relies on a well-known set of root
> server addresses for bootstrapping; I don't see why NTP shouldn't do the
> same.
> 
> (Actually... the root nameservers could *almost* provide a workable time
> tick for bootstrapping purposes right now: the SOA record for the root
> zone encodes today's date in the serial number.  So you do the SOA lookup,
> set your system clock, attempt validation; on failure, set the clock an
> hour forward and try again; on success, use NTP to fine-tune. Klugey! :) )
> 
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> _______________________________________________
> DNSOP mailing list
> dn...@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> dn...@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to