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

From: Danny Mayer <[email-masked]>
Date: Sun, 01 Dec 2013 19:31:11 -0500

On 12/1/2013 5:29 PM, Ted Lemon wrote:
> On Dec 1, 2013, at 5:05 PM, Olafur Gudmundsson <[email-masked]> wrote:
>> The "threat" the document is trying to address, device wants to
DNSSEC or CERT validation but clock is far off thus VALID credentials
fail validation.
> 
> Ah, thanks for explaining. This is what I was missing—you're not
> doing
this to avoid a threat at all, but rather to simply make DNSSEC work in
a possibly non-secure mode until such time as you can bootstrap better
time information.
> 
> This would be worth mentioning in the introduction and/or the
> security
considerations section. You allude to it in the security considerations,
but it's pretty oblique.
> 
> It is worth pointing out that NTP doesn't actually need DNS to
work—DHCP can deliver NTP server addresses as IP addresses. That said,
this option seems to add value, since there is no guarantee that devices
that implement the existing DHCP NTP will not send FQDNs rather than IP
addresses.

I had a long discussion with Bernie over the issue of delivering NTP IP
addresses via DHCP. We understand the issues you raised concerning
DNSSEC and have no disagreement about that. The problem is that for NTP
DNS names are preferred over IP addresses because that allows a server
maintainer to retire an NTP server. With an IP address there is no
chance that your local instance will know about this and continue to
bombard the old address. Moreover the newer pool option cannot be used
to any advantage.

When was the last time you looked at your NTP configuration and verified
that all of the servers listed are still valid? How often will DHCP
servers do this as a matter of course before providing such
provisioning? We have systems that are being bombarded by requests even
though no NTP server is responding to queries. We have plenty of
evidence of this. Even worse we have seen home routers which have
hard-coded IP addresses for NTP servers embedded. How long are those
going to be in operation?

I think we need to figure out how to get around the Catch-22 situation
of DNSSEC requiring relatively good time and NTP wanting to be able to
use DNS to find valid NTP servers.

We need a joint agreement on how to deal with this between DHCP and NTP
Working Groups assuming that is a viable option in the first place.
RFC5908 was not a good indication of this.

Danny

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Ted Lemon <[email-masked]>
Date: Sun, 1 Dec 2013 21:36:59 -0500

> RFC5908 was not a good indication of this.

RFC 5908 got approved pretty much accidentally, without finishing the review process in the DHC working group.   It was a major screwup, and I don't precisely know how it happened.   It doesn't really do what you wanted, and it certainly doesn't do what we wanted.   I agree that this needs to be resolved, but the resolution has to be based on reasoning, not an instinctive reaction to past pain.

I'm not even convinced that DHCP is the right way to distribute NTP server information.   I suspect Olafur may be thinking about the case that's more common at present, which is that an FQDN is hard-coded into the O.S. distribution, and resolved at startup time.   In that case, DHCP's ability to deliver NTP server IP addresses doesn't help.

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.

---

From: Hal Murray <[email-masked]>
Date: Sun, 01 Dec 2013 20:47:34 -0800

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?

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.

[email-masked] 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?

-- 
These are my opinions.  I hate spam.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Dec 2013 00:13:17 -0500

> Does DNS using DNSSEC return a specific error code for time-invalid?  Or just 

A response with a bad clock fails to validate, which is the same as no response.

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

Closer than 1970.

> It might be possible to discourage that by making them return crappy time.

History suggests otherwise.   If an IP address is hardcoded, it will get pummeled by devices that are too dumb to give up.

> mechanism if ISPs also provided NTP servers?

You mean DHCP?   Yes, that's what we're talking about.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 02 Dec 2013 00:27:13 -0500

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

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

> 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

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 02 Dec 2013 05:37:27 +0000

We already know we want to discuss how long NTP will use an IP it got
from a DNS lookup.

We know there is no good API to get the TTL from this lookup.

An IP can easily be moved to another machine; there's no reason to have
a TTL for these.

On the other hand, there is a way to update ntpd's config file.

See http://support.ntp.org/Dev/GettingNtpdItsConfiguration for more
information, and we might want to look at "refreshing" URL-based
configurations on a schedule.

H

---

From: Warner Losh <[email-masked]>
Date: Sun, 1 Dec 2013 23:44:14 -0700

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

So 5 years in the future is no problem?

Warner

---

From: Sanjeev Gupta <[email-masked]>
Date: Mon, 2 Dec 2013 20:12:29 +0800

On Mon, Dec 2, 2013 at 8:31 AM, Danny Mayer <[email-masked]> wrote:

> The problem is that for NTP
> maintainer to retire an NTP server.
>

With the "server" directive, once the FQDN is resolved by the system
resolver, ntpd will continue with tah IP address, even if the FQDN changes,
till it is restarted.

We are talking only about time at startup, right?

Then, I do not see any issues if the DHCP server specifies a IP address; as
long as the server administrator can manage to check that the IP is valid
(for a short time in the future).

1. The DHCP server administrator SHOULD specify the IP address of a valid
NTP server.

or

2. DHCP Server software MUST resolve the NTP server name to an IP address
before providing it to clients

Or am I missing something even more basic?

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Dec 2013 09:38:12 -0500

> So 5 years in the future is no problem?

I was being mildly facetious, since this is a question that's pretty easy to answer, but difficult to answer precisely.   The answer depends on the zone configuration, but generally speaking "within days" is probably good enough.   See http://tools.ietf.org/html/rfc6781#section-4.4.2.2

---

From: Danny Mayer <[email-masked]>
Date: Mon, 02 Dec 2013 10:24:06 -0500

On 12/2/2013 8:47 AM, Olafur Gudmundsson wrote:
> 
> On Dec 2, 2013, at 12:27 AM, Danny Mayer <[email-masked]> wrote:
> 
> 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.

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

> 	Olafur

---

From: Warner Losh <[email-masked]>
Date: Mon, 2 Dec 2013 08:32:02 -0700

>> 	 settimeofday(const struct timeval *tp, const struct timezone *tzp)

During a leap second, the value of time_t is not well defined because by definition leap seconds don't happen in time_t/POSIX time scale (don't happen -- well don't consume space in the time_t timescale is more pedantically correct). Obscure point likely worth noting...  But using a NTP time stamp doesn't save you, since during a leap second its value is well defined, but the same as another second (ntp distinguishes in bits set in other parts of the header). Assuming the tolerance for this application is >> 1s, this won't matter, but might be worth specifying that during a leap second, the value returned shall be either the value of the prior second or the value of the next second to make it conform to most current usage.

Warner

---

From: TSG - personal <[email-masked]>
Date: Mon, 02 Dec 2013 09:01:53 -0800

On 12/01/2013 04:31 PM, Danny Mayer wrote:

Danny many entities running DNSSEC dont have the option to continue 
operations until such time as they get better time data under the certs. 
This is a policy level thing so its not something that they can 
technically ignore either.

Todd

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Dec 2013 12:12:48 -0500

On Dec 2, 2013, at 10:32 AM, Warner Losh <[email-masked]> wrote:
> Assuming the tolerance for this application is >> 1s, this won't matter, but might be worth specifying that during a leap second, the value returned shall be either the value of the prior second or the value of the next second to make it conform to most current usage.

I think the expectation is that the time will be updated with a more accurate mechanism later, and an error of 1s is not worth worrying about for typical devices, so this is almost certainly overkill.

---

From: Warner Losh <[email-masked]>
Date: Mon, 2 Dec 2013 11:12:57 -0700

> I think the expectation is that the time will be updated with a more accurate mechanism later, and an error of 1s is not worth worrying about for typical devices, so this is almost certainly overki…

This isn't to prevent an error of a second, but to bound the error to a second by adopting the main work arounds that are in practice today which do that.

Warner

---

From: Hal Murray <[email-masked]>
Date: Mon, 02 Dec 2013 10:56:48 -0800

[email-masked] said:
[Context is NTP servers next to root DNS servers.]
> History suggests otherwise.   If an IP address is hardcoded, it will get
> pummeled by devices that are too dumb to give up. 

That's why I was suggesting a crappy clock.  Can we get something that is 
crappy enough that nobody would use it for anything other than getting off 
the ground yet still good enough for DNSSEC to work?

> You mean DHCP?   Yes, that's what we're talking about. 

Are there two layers of DHCP?  ISP to home router and home router to PC.

If ISPs ran NTP servers, say next to their DNS servers, could DHCP provide IP 
Addresses for both DNS and NTP servers over both hops?

Is it reasonable to trust an ISP's NTP servers?

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 02 Dec 2013 19:58:42 +0000

Warner Losh writes:
>>> 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)
> 
> During a leap second, the value of time_t is not well defined because
> by definition leap seconds don't happen in time_t/POSIX time scale
> (don't happen -- well don't consume space in the time_t timescale is
> more pedantically correct). Obscure point likely worth noting...  But
> using a NTP time stamp doesn't save you, since during a leap second
> its value is well defined, but the same as another second (ntp
> distinguishes in bits set in other parts of the header). Assuming the
> tolerance for this application is >> 1s, this won't matter, but might
> be worth specifying that during a leap second, the value returned
> shall be either the value of the prior second or the value of the next
> second to make it conform to most current usage.

It's actually fuzzier than that, and this situation (which is handled
differently with ntpd under unix, ntpd under windows, and on systems
that "smear" the leap second over a longer period) is one of the cases
handled by the General Timestamp API project at Network Time Foundation,
described at http://nwtime.org/projects/timestamp-api/ .

H

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Dec 2013 15:04:54 -0500

> the ground yet still good enough for DNSSEC to work?

No.   Think about this seriously.   Who is going to tweak this?   The end-user?   This isn't realistic.   We had millions of home gateways DDOSing a university NTP server for years because the router vendor burned the IP address of the NTP server into the firmware.   I doubt anybody got decent time out of this arrangement, but nevertheless it persisted.

> Are there two layers of DHCP?  ISP to home router and home router to PC.

Yes.

> Addresses for both DNS and NTP servers over both hops?

Yes.

> Is it reasonable to trust an ISP's NTP servers?

See my first response on this thread: http://www.ietf.org/mail-archive/web/dhcwg/current/msg15039.html

---

From: Warner Losh <[email-masked]>
Date: Mon, 2 Dec 2013 13:09:06 -0700

> described at http://nwtime.org/projects/timestamp-api/ .

Actually, in all those cases it is within a second of the 'real' time, hence specifying that it should be one second or the other seems appropriate. The timestamp APIs are for sub-second resolution, while the time_t in this protocol has only a second resolution... The main point is that it should be (a) specified to be what's going to most likely happen (or keep bounds on the error)  and (b) something sane that doesn't introduce errors > tolerance of the protocol. Having it be completely unspecified is a mistake, since -1 could be returned...

Warner

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 02 Dec 2013 21:32:13 +0000

Warner Losh writes:
>> that "smear" the leap second over a longer period) is one of the
>> cases handled by the General Timestamp API project at Network Time
>> Foundation, described at http://nwtime.org/projects/timestamp-api/ .
> 
> Actually, in all those cases it is within a second of the 'real' time,
> hence specifying that it should be one second or the other seems
> appropriate. The timestamp APIs are for sub-second resolution, while the
> time_t in this protocol has only a second resolution... The main point
> is that it should be (a) specified to be what's going to most likely
> happen (or keep bounds on the error)  and (b) something sane that
> doesn't introduce errors > tolerance of the protocol. Having it be
> completely unspecified is a mistake, since -1 could be returned...

I'd suspect that usually 1 second will be the ballpark, but it's pretty
easy to find situations where the system clock is out by more than that.

I mention the General Timestamp API because that effort is looking at
use cases like this one from a larger persepective.

H

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Dec 2013 09:03:11 +1100

The inception and expiration times in RRSIGs is specified as seconds
since 00:00:00 Jan 1 1970 UTC excluding leap seconds modulo 2^32.

There are no recommended fudge factors to use when evaluating these
times though named sets the expire time to 3600 seconds in the past
by default when generating RRSIGs.  I believe the other signers do
similar.  I've considered making the inception timestamp a whole
day in the past to cope with badly set timezones.

The signature validity intervals are on the order of days.  Named
defaults to 30 days.  They are regenerated about a week before they
are due expire if not already regenerated due to zone content
changes.  The records should expire from caches before they become
invalid if re-signing is being done properly.

So if the validator and the signer are both within 30 minutes of
the true time validation should succeed.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Dec 2013 09:15:19 +1100

> times though named sets the expire time to 3600 seconds in the past

That should read "inception time to 3600 seconds in the past"

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 3 Dec 2013 13:27:25 +0100

> use DNS to find valid NTP servers.

If the box doesn't have an rtc, and so maybe starts in 1970, and
doesn't have anything it can trust there is no way out of it.  You
first need _something_ you can trust be it time or some
certificate.

I do not trust my ISP, so I don't see how I can get that started
and be sure that both my time are correct and dnssec validates
properly.  The only way I see around this is that someone manually
checks that the time is correct.

Kurt

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 2 Dec 2013 08:47:01 -0500

Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 2 Dec 2013 10:31:50 -0500

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

> browser software and banks give DNSSEC authenticated addresses then it
See above, 

	Olafur

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 3 Dec 2013 13:49:25 +0100

> 	 settimeofday(const struct timeval *tp, const struct timezone *tzp)

I don't think that is something we want every dhcp client to do.
If ntpd is running you really don't want something else to change
the time.

Kurt

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 04 Dec 2013 01:40:17 +0000

> If ntpd is running you really don't want something else to change

There is a difference between DHCP at startup and a DHCP "refresh".

I suspect that a DHCP refresh should leave the clock alone.

For the startup case:

I think the best solution to this problem for LAN-connected devices will
turn out to be PTP.  And if that is not available, if you can't trust
your DHCP server to tell you what time it is, why would you trust it to
give you an IP address?

H