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

[Olafur Gudmundsson <[e-mail]>]

On Dec 2, 2013, at 12:27 AM, Danny Mayer <[e-mail]> wrote:

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

Danny, Thanks for the kind introduction 

The reason for time_t is the dhcp-client can feed that directly into following call:
	 settimeofday(const struct timeval *tp, const struct timezone *tzp)

If there is better construct I wold be happy to update the draft with that. 

Be careful when you say "most systems running a DNS server" 
are you talking about resolver or authoritative server.  

In the second case you are right they are static and frequently well provisioned with good bandwidth, and 
at boot time the system has good idea why the current time is, but for all practical purposes unless they are signing
on the fly they do not need accurate time. 

ON THE OTHER HAND, resolvers and X.509 certificate checking is distributed and can take 
place on any device. As I said in another message DNS resolution is being pushed to the edge 
as devices that migrate between networks cannot count on the "local resolvers" to be "DNSSEC ready" 

You are right we can not count on the DHCP server to have good time, thus any DHCP server answering 
with the proposed option would need to make sure it has "decent current time", that is the reason I say in the
draft that the time should be within 10 minutes. 
When playing with cheap home routers I discovered that the devices can easily drift an hour a day, if NTP is not
invoked regularly, most of these devices just use 'ntpdate' and frequently run it from startup script once. 

>> 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.
> 
>> 
>> [e-mail] 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

Will a hotel network provide NTP server, and would you trust it? 
Will a coffee shop provide NTP server ??? 

	Olafur