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 10:24 AM, Danny Mayer <[e-mail]> wrote:

> On 12/2/2013 8:47 AM, Olafur Gudmundsson wrote:
>> 
>> 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.  
>> 
> 
> I actually mostly meant resolvers and authorative servers are really no
> different in the sense being discussed here.
> 
>> 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" 
>> 
> I doubt that the number of "local resolvers" used by the general
> populace that can support DNSSEC reach even .1% today, never mind
> whether the server has it enabled.
> 

Chrome and Firefox have DNSSEC validation libraries in testing. 
Once they turn that on the numbers will jump. 
X.509 cert checks happen on edge devices today in large numbers. 
This is not just for DNSSEC this is for any device that wants to do time check before NTP can finish. 


>> 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 ??? 
>> 
> 
> I would consider them no better than the ISP's. They only provide basic
> services and almost certainly not NTP. But then how many applications
> out there will demand DNSSEC authenticated information? Generally there
> is no API to specify that from an application. When this gets into
> browser software and banks give DNSSEC authenticated addresses then it
> might take off.
> 
> Danny
> 
See above, 

	Olafur