[Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Joseph Swick]

Hi List,
I've been lurking for several months now on the list and I remember some
discussion about trying to find acceptable methods for bootstrapping the
local system time so that DNSSEC would work.

I recently got around to updating my router a week or two ago from 3.7.?
to 3.10.28-16 because Comcast finally switched on IPv6 for my neck of
the woods (realized this when I finally noticed the performance impact
of the issues with Comcast IPv6 and the 3.7 release) .  Tonight, I went
and reset my configuration this evening to clear out some mistakes I
made (that was keeping IPv6 from working).  Then I noticed that was
getting SERVFAIL for some domains (e.g.: bufferbloat.net) and not others
and (in trying to keep this short) I finally remembered to check the
clock on the router and saw that it was set to Feb 24th instead of the
correct time & date.

Is the current recommendation still to put in a couple of IPs for NTP
servers into the config of the router?  Or has there been more work
towards resolving the NTP bootstrap issue in the more recent releases?

TIA.

-Joseph

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Dave Taht]

On Sat, Mar 22, 2014 at 3:33 AM, Joseph Swick <cerowrt@decoy.cotse.net> wrote:
> Hi List,
> I've been lurking for several months now on the list and I remember some
> discussion about trying to find acceptable methods for bootstrapping the
> local system time so that DNSSEC would work.
>
> I recently got around to updating my router a week or two ago from 3.7.?
> to 3.10.28-16 because Comcast finally switched on IPv6 for my neck of
> the woods (realized this when I finally noticed the performance impact
> of the issues with Comcast IPv6 and the 3.7 release) .

I reallly, really, really want to get the comcast users off of 3.7.x. That bug
is rather severe.

> Tonight, I went
> and reset my configuration this evening to clear out some mistakes I
> made (that was keeping IPv6 from working).  Then I noticed that was
> getting SERVFAIL for some domains (e.g.: bufferbloat.net) and not others
> and (in trying to keep this short) I finally remembered to check the
> clock on the router and saw that it was set to Feb 24th instead of the
> correct time & date.
>
> Is the current recommendation still to put in a couple of IPs for NTP
> servers into the config of the router?  Or has there been more work
> towards resolving the NTP bootstrap issue in the more recent releases?

There has not (as yet) been any work put into resolving the thorny
ntp/dnssec interrelationship problem. (famous bug #113 in the cerowrt
database). (Not having
been running any releases for long enough for it to become a problem made it
slip my mind!)

There WAS a bug in openwrt's ntp which led to only one ntp server being queried,
rather than the default 4. This was fixed several releases back. So
you failed to
get a valid time from the one ntp server you saw, and things degraded
from there.

The ntp servers queried presently largely are not dnssec signed, so
the ntp queries
should succeed (I think?) in the general case. However, for
robustness, I'd argue for enhancing the ntp startup script to
temporarily disable dnssec until it gets a valid time, and then
enabling it. I believe support for running the script was added to
busybox ntp, the problem  remaining is how to tell dnsmasq about it
correctly.

> TIA.
>
> -Joseph
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Simon Kelley]

On 22/03/14 17:42, Dave Taht wrote:
> On Sat, Mar 22, 2014 at 3:33 AM, Joseph Swick <cerowrt@decoy.cotse.net> wrote:
>> Hi List,
>> I've been lurking for several months now on the list and I remember some
>> discussion about trying to find acceptable methods for bootstrapping the
>> local system time so that DNSSEC would work.
>>
>> I recently got around to updating my router a week or two ago from 3.7.?
>> to 3.10.28-16 because Comcast finally switched on IPv6 for my neck of
>> the woods (realized this when I finally noticed the performance impact
>> of the issues with Comcast IPv6 and the 3.7 release) .
> 
> I reallly, really, really want to get the comcast users off of 3.7.x. That bug
> is rather severe.
> 
>> Tonight, I went
>> and reset my configuration this evening to clear out some mistakes I
>> made (that was keeping IPv6 from working).  Then I noticed that was
>> getting SERVFAIL for some domains (e.g.: bufferbloat.net) and not others
>> and (in trying to keep this short) I finally remembered to check the
>> clock on the router and saw that it was set to Feb 24th instead of the
>> correct time & date.
>>
>> Is the current recommendation still to put in a couple of IPs for NTP
>> servers into the config of the router?  Or has there been more work
>> towards resolving the NTP bootstrap issue in the more recent releases?
> 
> There has not (as yet) been any work put into resolving the thorny
> ntp/dnssec interrelationship problem. (famous bug #113 in the cerowrt
> database). (Not having
> been running any releases for long enough for it to become a problem made it
> slip my mind!)
> 
> There WAS a bug in openwrt's ntp which led to only one ntp server being queried,
> rather than the default 4. This was fixed several releases back. So
> you failed to
> get a valid time from the one ntp server you saw, and things degraded
> from there.
> 
> The ntp servers queried presently largely are not dnssec signed, so
> the ntp queries
> should succeed (I think?) 

Not necessarily. If DNSSEC is configured to ensure that unsigned domains
are real unsigned domains, then that requires proof-of-noexistence of
the relevant DS records, and therefore accurate time.

To solve this, we need a handle on why inception and expiry times were
added to the DNSSEC protocol. My guess is that it's to avoid use of old
keys which have been rendered insecure by the passage of time (any key
can be cracked or compromised, given enough time.)

One possibility would be to store the current time in NVRAM. When the
router comes up, that gives a lower bound on the current time, and would
 solve attacks using old keys.



in the general case. However, for
> robustness, I'd argue for enhancing the ntp startup script to
> temporarily disable dnssec until it gets a valid time, and then
> enabling it. I believe support for running the script was added to
> busybox ntp, the problem  remaining is how to tell dnsmasq about it
> correctly.

Less drastic would be to disable the key-time checks for this phase.
Simplest would be a config flag: start it up with that flag whilst NTP
does its stuff, them restart without when the clock is OK. Another
option would be to disable the checks when the query arrives from a
"magic" loopback address: maybe 127.110.116.112 (127.'n'.'t'.'p')



Cheers,
Simon.

> 

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

Simon Kelley <simon@thekelleys.org.uk> writes:

> One possibility would be to store the current time in NVRAM. When the
> router comes up, that gives a lower bound on the current time, and
> would solve attacks using old keys.

This is already implemented (basically it finds the most recently
modified file in /etc and sets the time to that; I think there's also a
script that periodically refreshes some file there), and works to keep
time during a reboot. However, when first flashing an image, the time
will be whatever time that image was created...

> Less drastic would be to disable the key-time checks for this phase.
> Simplest would be a config flag: start it up with that flag whilst NTP
> does its stuff, them restart without when the clock is OK. Another
> option would be to disable the checks when the query arrives from a
> "magic" loopback address: maybe 127.110.116.112 (127.'n'.'t'.'p')

The magic address would require the resolver and/or the ntp daemon to be
patched? What about a config option that adds a grace time? Say enable
dnssec after N seconds?

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/03/14 19:38, Toke Høiland-Jørgensen wrote:
> Simon Kelley <simon@thekelleys.org.uk> writes:
> 
>> One possibility would be to store the current time in NVRAM. When
>> the router comes up, that gives a lower bound on the current
>> time, and would solve attacks using old keys.
> 
> This is already implemented (basically it finds the most recently 
> modified file in /etc and sets the time to that; I think there's
> also a script that periodically refreshes some file there), and
> works to keep time during a reboot. However, when first flashing an
> image, the time will be whatever time that image was created...
> 
>> Less drastic would be to disable the key-time checks for this
>> phase. Simplest would be a config flag: start it up with that
>> flag whilst NTP does its stuff, them restart without when the
>> clock is OK. Another option would be to disable the checks when
>> the query arrives from a "magic" loopback address: maybe
>> 127.110.116.112 (127.'n'.'t'.'p')
> 
> The magic address would require the resolver and/or the ntp daemon
> to be patched? What about a config option that adds a grace time?
> Say enable dnssec after N seconds?

That would be possible: it would require care to make it work in the
face of the system time being warped by NTP. Best way may  be to use
times() rather than time()

Cheers,

Simon.

> 
> -Toke
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMt56gACgkQKPyGmiibgrfafgCeJVIyxtGXLfkh/YaLkQ9QaTzM
/Q4AoJiWKjwnwVlU+3v75asbK39cuImx
=AJrb
-----END PGP SIGNATURE-----

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

Simon Kelley <simon@thekelleys.org.uk> writes:

> That would be possible: it would require care to make it work in the
> face of the system time being warped by NTP. Best way may  be to use
> times() rather than time()

Good point. Since the availability of reliable time is what we're
waiting for, perhaps a large jump in the system clock could be taken to
mean it has been achieved and taken as a signal to exit the grace
period? With a timer for the case where the time is already accurate, of
course. This would make it rather specific to this use case, though...

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Joseph Swick]

On 03/22/2014 01:42 PM, Dave Taht wrote:
> On Sat, Mar 22, 2014 at 3:33 AM, Joseph Swick <cerowrt@decoy.cotse.net> wrote:

>> I recently got around to updating my router a week or two ago from 3.7.?
>> to 3.10.28-16 because Comcast finally switched on IPv6 for my neck of
>> the woods (realized this when I finally noticed the performance impact
>> of the issues with Comcast IPv6 and the 3.7 release) .
> 
> I reallly, really, really want to get the comcast users off of 3.7.x. That bug
> is rather severe.

Yeah, I had kept putting off upgrading to one of the fixed releases due
to the assumption that my area of Southern NH would be among the last to
get IPv6 switched on.  Wasn't until I started looking into why my
Internet performance had gotten so bad I remembered the bug (and why I
kept reminding my self to upgrade)

> There has not (as yet) been any work put into resolving the thorny
> ntp/dnssec interrelationship problem. (famous bug #113 in the cerowrt
> database). (Not having
> been running any releases for long enough for it to become a problem made it
> slip my mind!)

I'm more than happy to try to help out (which is why I joined the devel
list), but I'm more of the Sysadmin type than Developer (which is why
I've been lurking).

> The ntp servers queried presently largely are not dnssec signed, so
> the ntp queries
> should succeed (I think?) in the general case. However, for
> robustness, I'd argue for enhancing the ntp startup script to
> temporarily disable dnssec until it gets a valid time, and then
> enabling it. I believe support for running the script was added to
> busybox ntp, the problem  remaining is how to tell dnsmasq about it
> correctly.
> 

Ok, part of my issue was probably also that the clock was so far off, it
didn't want to skew to the correct time.

-Joseph

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

>
> > The ntp servers queried presently largely are not dnssec signed, so
> > the ntp queries
> > should succeed (I think?) in the general case. However, for
> > robustness, I'd argue for enhancing the ntp startup script to
> > temporarily disable dnssec until it gets a valid time, and then
> > enabling it. I believe support for running the script was added to
> > busybox ntp, the problem  remaining is how to tell dnsmasq about it
> > correctly.
> >
>
> Ok, part of my issue was probably also that the clock was so far off, it
> didn't want to skew to the correct time.


Something I've done in the past on systems without RTCs is to have the ntp
init script loop on calling ntpdate until it gets a valid time, and then
switch over to the continuously running ntpd.  Everything that needs the
correct time then has to start after ntp.  But with DNSSEC, that's going to
push the need to have the ntp servers specified by ip address, not by
hostname, or to have them never be secure, or we find a way to have
long-lived dnssec entries.  I think raw IP address specification is
probably safer than trying to do something like creating an insecure window
around dnssec.

-Aaron

[-- Attachment #2: Type: text/html, Size: 1521 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

Aaron Wood <woody77@gmail.com> writes:

> or we find a way to have long-lived dnssec entries.

Is the timing controllable somehow? I.e. would it be possible to set up
a special domain name with a really long-lived key that could be queried
indefinitely for the IP address of one or more NTP servers, even in the
face of an a wrong clock?

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[David Personette]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

The simplest solution seems to be to cache a lookup of pool.ntp.org. It
would only need to be used if the normal DNS target for ntpdate fails. Once
time is set, we can update the cached values of the pool once again (if
they've changed).

-- 
David P.



On Sun, Mar 23, 2014 at 7:15 AM, Toke Høiland-Jørgensen <toke@toke.dk>wrote:

> Aaron Wood <woody77@gmail.com> writes:
>
> > or we find a way to have long-lived dnssec entries.
>
> Is the timing controllable somehow? I.e. would it be possible to set up
> a special domain name with a really long-lived key that could be queried
> indefinitely for the IP address of one or more NTP servers, even in the
> face of an a wrong clock?
>
> -Toke
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

[-- Attachment #2: Type: text/html, Size: 1561 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

David Personette <dperson@gmail.com> writes:

> The simplest solution seems to be to cache a lookup of pool.ntp.org. It would
> only need to be used if the normal DNS target for ntpdate fails. Once time is
> set, we can update the cached values of the pool once again (if they've
> changed).

Hmm, I suppose a solution could be to create a script that queries
pool.ntp.org and stores it in /etc/hosts (or the dnsmasq config) as
'cached.pool.ntp.org' or similar, and then configure that as an NTP
server. And then have the script run periodically, and also at image
build time?

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

On Sun, Mar 23, 2014 at 12:15 PM, Toke Høiland-Jørgensen <toke@toke.dk>wrote:

> Aaron Wood <woody77@gmail.com> writes:
>
> > or we find a way to have long-lived dnssec entries.
>
> Is the timing controllable somehow? I.e. would it be possible to set up
> a special domain name with a really long-lived key that could be queried
> indefinitely for the IP address of one or more NTP servers, even in the
> face of an a wrong clock?


My understanding (albeit, not a deep one) is that the dnssec keys all have
a fairly short expiration, just a few months.  It would be nice if they
were longer-lived (in this particular case), but you still have an issue of
needing to decide what time is "now", within a reasonable degree, in order
to validate the domain.  Alternatively, you assume that you don't care
about the timeliness of the entry, for the resolution of ntp server names,
and then you have to somehow convey to the resolver that you want a secure
lookup, but it's ok if it's expired (or too new, or...), which gets back to
some of the earlier parts of this discussion.

-Aaron

[-- Attachment #2: Type: text/html, Size: 1525 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Michael Richardson]

Aaron Wood <woody77@gmail.com> wrote:
    > Aaron Wood <woody77@gmail.com> writes:

    >> or we find a way to have long-lived dnssec entries.

    > Is the timing controllable somehow? I.e. would it be possible to set up
    > a special domain name with a really long-lived key that could be queried
    > indefinitely for the IP address of one or more NTP servers, even in the
    > face of an a wrong clock?

    > My understanding (albeit, not a deep one) is that the dnssec keys all have a
    > fairly short expiration, just a few months.  It would be nice if they were
    > longer-lived (in this particular case), but you still have an issue of

That's operationally true, but not baked into any protocol.

So, aside from caching cache.pool.ntp.org into /etc/hosts:

The ., org. keys are not going to grow multiple year expiries, so we need our
own thing to cache.  One could cache the DNSKEY for bufferbloat.net along
with the root zone keys... then lookup ntp.bufferbloat.net. It would have to
return a A/AAAA records, because chasing a CNAME into ntp.org would fail to
validate.

    > of the entry, for the resolution of ntp server names, and then you have to
    > somehow convey to the resolver that you want a secure lookup, but it's ok if
    > it's expired (or too new, or...), which gets back to some of the earlier parts
    > of this discussion.

Bingo.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Aaron Wood]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

>
> The ., org. keys are not going to grow multiple year expiries, so we need
> our
> own thing to cache.  One could cache the DNSKEY for bufferbloat.net along
> with the root zone keys... then lookup ntp.bufferbloat.net. It would have
> to
> return a A/AAAA records, because chasing a CNAME into ntp.org would fail
> to
> validate.
>
>     > of the entry, for the resolution of ntp server names, and then you
> have to
>     > somehow convey to the resolver that you want a secure lookup, but
> it's ok if
>     > it's expired (or too new, or...), which gets back to some of the
> earlier parts
>     > of this discussion.
>
> Bingo.


That would scale well for CeroWRT, but doesn't seem like it would scale
well for general-use (OpenWRT).  Or rather, the use of
bufferbloat.netwouldn't scale well.  But OpenWRT might be able to do
the same with it's
key, and have it's own ntp.openwrt.org which resolves into the general ntp
pool.

-Aaron

[-- Attachment #2: Type: text/html, Size: 1497 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

Aaron Wood <woody77@gmail.com> writes:

> That would scale well for CeroWRT, but doesn't seem like it would
> scale well for general-use (OpenWRT). Or rather, the use of
> bufferbloat.net wouldn't scale well. But OpenWRT might be able to do
> the same with it's key, and have it's own ntp.openwrt.org which
> resolves into the general ntp pool.

Would this "caching of the key" be akin to distributing an extra trust
anchor with the key of the domain in question? And would the gain of
doing this be sufficient to warrant the extra complexity (as opposed to
just caching the IP address of one or more NTP servers)?

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Chuck Anderson]

On Mon, Mar 24, 2014 at 10:59:08AM +0100, Toke Høiland-Jørgensen wrote:
> Aaron Wood <woody77@gmail.com> writes:
> 
> > That would scale well for CeroWRT, but doesn't seem like it would
> > scale well for general-use (OpenWRT). Or rather, the use of
> > bufferbloat.net wouldn't scale well. But OpenWRT might be able to do
> > the same with it's key, and have it's own ntp.openwrt.org which
> > resolves into the general ntp pool.
> 
> Would this "caching of the key" be akin to distributing an extra trust
> anchor with the key of the domain in question? And would the gain of
> doing this be sufficient to warrant the extra complexity (as opposed to
> just caching the IP address of one or more NTP servers)?

How about writing an RFC to define a well-known NTP anycast address
and using that as a fallback?  This is a problem that needs to be
solved for the larger internet community, not just CeroWRT/OpenWRT.

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

Chuck Anderson <cra@WPI.EDU> writes:

> How about writing an RFC to define a well-known NTP anycast address
> and using that as a fallback? This is a problem that needs to be
> solved for the larger internet community, not just CeroWRT/OpenWRT.

This would probably be a nice long-term solution (though I'd be worried
about the DOS potential of such a setup?); we would probably need a
short-term solution in the intervening years until everyone implements
this, though... ;)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Mon, 24 Mar 2014 08:29:16 -0400, Chuck Anderson said:

> How about writing an RFC to define a well-known NTP anycast address
> and using that as a fallback?  This is a problem that needs to be
> solved for the larger internet community, not just CeroWRT/OpenWRT.

Using a well-known anycast address for NTP is somewhat problematic for security.
It's possible to secure anycast DNS using DNSSEC - but the NTP crypto isn't
suitable for securing an anycast mode.

Fortunately, for many use cases, we can probably rely on the upstream
provider to hand us an NTP server address in a DHCP extension.  If you're
willing to trust the *rest* of that DHCP response, you may as well trust the
NTP server it points you at.

I admit not having a clever idea for the non-DHCP case though...

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Alijah Ballard]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

Are there other ways to seed the clock. Can a timestamp be pulled from the
DNS system at all. Or what about http://en.wikipedia.org/wiki/IEEE_1588. I
have been reading specifications recently and IEEE 1588 is designed for
multicast time acquisition. Any other ideas?


On Mon, Mar 24, 2014 at 8:39 AM, Toke Høiland-Jørgensen <toke@toke.dk>wrote:

> Chuck Anderson <cra@WPI.EDU> writes:
>
> > How about writing an RFC to define a well-known NTP anycast address
> > and using that as a fallback? This is a problem that needs to be
> > solved for the larger internet community, not just CeroWRT/OpenWRT.
>
> This would probably be a nice long-term solution (though I'd be worried
> about the DOS potential of such a setup?); we would probably need a
> short-term solution in the intervening years until everyone implements
> this, though... ;)
>
> -Toke
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

[-- Attachment #2: Type: text/html, Size: 1699 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Phil Pennock]

[-- Attachment #1.1: Type: text/plain, Size: 2020 bytes --]

On 2014-03-21 at 23:33 -0400, Joseph Swick wrote:
> I've been lurking for several months now on the list and I remember some
> discussion about trying to find acceptable methods for bootstrapping the
> local system time so that DNSSEC would work.

I raised this on the ntp-pool mailing-lists last year, looking for a
solution because of the chicken/egg bootstrap, with suggested approaches
and some trial scripts.  Eg:

  http://lists.ntp.org/pipermail/pool/2013-July/006569.html

For context, I'm currently running OpenWRT; attached is the
/etc/init.d/ntpdate which I'm using.  It relies upon having Python and
dig installed, as I haven't gotten around to building a small C utility
to do just this task, but perhaps the approach is useful enough that
someone else might do so?

In summary: if the current time is less than the timestamp on the
unbound-maintained copy of the root zone trust anchors, then bump the
time up at least that far, because we must be at >= that timestamp, and
this increases the odds that DNSSEC will validate if we haven't been
off-line for too long.

Then, for each hostname in the $STEP_SERVERS list (which could be
taken from ntp.conf or uci config or whatever, but here is just
hardcoded), I try to resolve IPv4 then IPv6, first with DNSSEC left
enabled, and then with DNSSEC disabled via `dig +cd`.  The first dig
command to return results is the one which is used.

The idea is to minimize the potential vulnerability of syncing to a bad
timesource, by using DNSSEC if it's available and works, after making
sure it has a reasonable chance of working if we've just rebooted, and
only if we've been off-line for some time do we fall back to insecure
DNS.

Make sure that the START value is appropriate for your systems; I've
found the OpenWRT defaults to be sufficiently broken that I stomp on
them on reinstall.  I run ntpdate once the network and firewall are up,
but just before ntpd and both of those well before other network
services which might depend upon time.

Regards,
-Phil

[-- Attachment #1.2: ntpdate-router-initscript --]
[-- Type: text/plain, Size: 2419 bytes --]

#!/bin/sh /etc/rc.common
# Copyright (C) 2006-2008 OpenWrt.org
# Copyright (C) 2013 Phil Pennock

START=60

STEP_SERVERS="0.openwrt.pool.ntp.org 1.openwrt.pool.ntp.org 2.openwrt.pool.ntp.org"
TIMEOUT="2" # in seconds
PRESEED_TIMESTAMP_FN="/etc/unbound/runtime/root.autokey"

# The core problem is that with DNSSEC, an invalid time prevents resolution
# of DNS, but we need DNS to be able to find time-servers to get a good time
# to be able to resolve DNS.
#
# We break out of this "Catch 22" situation by _trying_ normal DNS resolution,
# IPv4 and then IPv6, and only if those fail do we forcibly disable DNSSEC
# by using dig(1)'s +cd flag ("checking disabled"); trying normally first
# protects us against malicious DNS trying to point us to bad time-servers,
# if we've enough state that we _should_ already be protected.
#
# The "insecure" approach we regress to, as a last resort, is the same way
# the Internet functioned for decades.  There is a DoS+hijack attack path
# here, but if we don't have a good battery-backed clock to protect us, we
# don't have a better solution.

# Also, per a suggestion from Doug Calvert, we can use the timestamp of
# modification of the unbound root.key file itself as an approximate time.
# Unbound updates the file on every refresh, so it's not too far off.

preseed_approximate_time() {
	# Unfortunately, date(1) on OpenWRT can't parse the timestamp
	# output from ls.
	python -c '
import os, time, sys
fn=sys.argv[1]
min_time=os.stat(fn).st_ctime
if time.time() < min_time:
  want=time.strftime("%Y%m%d%H%M.%S", time.gmtime(min_time))
  os.system("date -u -s %s" % want)' "$PRESEED_TIMESTAMP_FN" > /dev/null
}

resolve_hostname_v4() {
# we use the grep both to filter out cname referrals and to detect empty
# results
	local hn="$1"
	shift
	dig +nodnssec +short "$@" -t a "$hn" | grep '^[0-9][0-9.]*$'
}

resolve_hostname_v6() {
	local hn="$1"
	shift
	dig +nodnssec +short "$@" -t aaaa "$hn" | grep -i '^[0-9a-f][0-9a-f.:]*$'
}

resolve_one_server() {
	local hn="$1"
	resolve_hostname_v4 $hn && return
	resolve_hostname_v6 $hn && return
	resolve_hostname_v4 $hn +cd && return
	resolve_hostname_v6 $hn +cd && return
}

resolve_step_servers() {
	local server ips
	for server in $STEP_SERVERS ; do
		resolve_one_server $server
	done
}

start() {
	preseed_approximate_time
	for s in $(resolve_step_servers) ; do
		/usr/sbin/ntpdate -s -b -u -t "$TIMEOUT" "$s" && break
	done
}

[-- Attachment #2: Type: application/pgp-signature, Size: 455 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[David Personette]

[-- Attachment #1: Type: text/plain, Size: 5808 bytes --]

Phil,

With the exception of the extra dependencies (dig and python), I like this.
I would suggest that if DNSSEC will be enabled, that nslookup (I think
that's the only command line resolver included by CeroWRT/OpenWRT base
installs) be extended to have a similar option as dig, to resolve without
DNSSEC.

The only other issue I see is if the router is brought online before
internet access is available. If I read your code correctly, it will try 4
times per defined server (with and without DNSSEC for IPv4 and IPv6), then
exit. It either needs to keep trying until it succeeds, or be called every
time a connection comes up (shutting down NTPd prior and restarting after).

Thanks.

-- 
David P.



On Mon, Mar 24, 2014 at 3:12 PM, Phil Pennock <
cerowrt-devel+phil@spodhuis.org> wrote:

> On 2014-03-21 at 23:33 -0400, Joseph Swick wrote:
> > I've been lurking for several months now on the list and I remember some
> > discussion about trying to find acceptable methods for bootstrapping the
> > local system time so that DNSSEC would work.
>
> I raised this on the ntp-pool mailing-lists last year, looking for a
> solution because of the chicken/egg bootstrap, with suggested approaches
> and some trial scripts.  Eg:
>
>   http://lists.ntp.org/pipermail/pool/2013-July/006569.html
>
> For context, I'm currently running OpenWRT; attached is the
> /etc/init.d/ntpdate which I'm using.  It relies upon having Python and
> dig installed, as I haven't gotten around to building a small C utility
> to do just this task, but perhaps the approach is useful enough that
> someone else might do so?
>
> In summary: if the current time is less than the timestamp on the
> unbound-maintained copy of the root zone trust anchors, then bump the
> time up at least that far, because we must be at >= that timestamp, and
> this increases the odds that DNSSEC will validate if we haven't been
> off-line for too long.
>
> Then, for each hostname in the $STEP_SERVERS list (which could be
> taken from ntp.conf or uci config or whatever, but here is just
> hardcoded), I try to resolve IPv4 then IPv6, first with DNSSEC left
> enabled, and then with DNSSEC disabled via `dig +cd`.  The first dig
> command to return results is the one which is used.
>
> The idea is to minimize the potential vulnerability of syncing to a bad
> timesource, by using DNSSEC if it's available and works, after making
> sure it has a reasonable chance of working if we've just rebooted, and
> only if we've been off-line for some time do we fall back to insecure
> DNS.
>
> Make sure that the START value is appropriate for your systems; I've
> found the OpenWRT defaults to be sufficiently broken that I stomp on
> them on reinstall.  I run ntpdate once the network and firewall are up,
> but just before ntpd and both of those well before other network
> services which might depend upon time.
>
> Regards,
> -Phil
>
> #!/bin/sh /etc/rc.common
> # Copyright (C) 2006-2008 OpenWrt.org
> # Copyright (C) 2013 Phil Pennock
>
> START=60
>
> STEP_SERVERS="0.openwrt.pool.ntp.org 1.openwrt.pool.ntp.org
> 2.openwrt.pool.ntp.org"
> TIMEOUT="2" # in seconds
> PRESEED_TIMESTAMP_FN="/etc/unbound/runtime/root.autokey"
>
> # The core problem is that with DNSSEC, an invalid time prevents resolution
> # of DNS, but we need DNS to be able to find time-servers to get a good
> time
> # to be able to resolve DNS.
> #
> # We break out of this "Catch 22" situation by _trying_ normal DNS
> resolution,
> # IPv4 and then IPv6, and only if those fail do we forcibly disable DNSSEC
> # by using dig(1)'s +cd flag ("checking disabled"); trying normally first
> # protects us against malicious DNS trying to point us to bad time-servers,
> # if we've enough state that we _should_ already be protected.
> #
> # The "insecure" approach we regress to, as a last resort, is the same way
> # the Internet functioned for decades.  There is a DoS+hijack attack path
> # here, but if we don't have a good battery-backed clock to protect us, we
> # don't have a better solution.
>
> # Also, per a suggestion from Doug Calvert, we can use the timestamp of
> # modification of the unbound root.key file itself as an approximate time.
> # Unbound updates the file on every refresh, so it's not too far off.
>
> preseed_approximate_time() {
>         # Unfortunately, date(1) on OpenWRT can't parse the timestamp
>         # output from ls.
>         python -c '
> import os, time, sys
> fn=sys.argv[1]
> min_time=os.stat(fn).st_ctime
> if time.time() < min_time:
>   want=time.strftime("%Y%m%d%H%M.%S", time.gmtime(min_time))
>   os.system("date -u -s %s" % want)' "$PRESEED_TIMESTAMP_FN" > /dev/null
> }
>
> resolve_hostname_v4() {
> # we use the grep both to filter out cname referrals and to detect empty
> # results
>         local hn="$1"
>         shift
>         dig +nodnssec +short "$@" -t a "$hn" | grep '^[0-9][0-9.]*$'
> }
>
> resolve_hostname_v6() {
>         local hn="$1"
>         shift
>         dig +nodnssec +short "$@" -t aaaa "$hn" | grep -i
> '^[0-9a-f][0-9a-f.:]*$'
> }
>
> resolve_one_server() {
>         local hn="$1"
>         resolve_hostname_v4 $hn && return
>         resolve_hostname_v6 $hn && return
>         resolve_hostname_v4 $hn +cd && return
>         resolve_hostname_v6 $hn +cd && return
> }
>
> resolve_step_servers() {
>         local server ips
>         for server in $STEP_SERVERS ; do
>                 resolve_one_server $server
>         done
> }
>
> start() {
>         preseed_approximate_time
>         for s in $(resolve_step_servers) ; do
>                 /usr/sbin/ntpdate -s -b -u -t "$TIMEOUT" "$s" && break
>         done
> }
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>

[-- Attachment #2: Type: text/html, Size: 7516 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

Phil Pennock <cerowrt-devel+phil@spodhuis.org> writes:

> For context, I'm currently running OpenWRT; attached is the
> /etc/init.d/ntpdate which I'm using. It relies upon having Python and
> dig installed, as I haven't gotten around to building a small C
> utility to do just this task, but perhaps the approach is useful
> enough that someone else might do so?

A functionality similar to this is already implemented in openwrt and
runs as the first thing on boot. It finds the newest file in /etc and
sets the system time to that:

# cat /etc/init.d/sysfixtime 
#!/bin/sh /etc/rc.common
# Copyright (C) 2013-2014 OpenWrt.org

START=00

boot() {
	local curtime="$(date +%s)"
	local maxtime="$(find /etc -type f -exec date +%s -r {} \; | sort -nr | head -n1)"
	[ $curtime -lt $maxtime ] && \
		date -s @$maxtime && \
		logger -t sysfixtime -p daemon.notice "Time fixed"
}


This works well enough that I haven't had any time problems in recent
memory. However I tend to build my images minutes before flashing them,
so for someone downloading an image off somewhere, the ntp lookup is
obviously needed.

I do believe it would be feasible to include your script without the
preseed part pretty much as-is? It adds a dependency on dig, but I guess
that is not unreasonable (certainly not for cerowrt, but maybe for
openwrt default). The ntpdate dependency can probably be gotten away
with by substituting an appropriate ntpd -q command...

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Phil Pennock]

On 2014-03-24 at 16:27 -0400, David Personette wrote:
> With the exception of the extra dependencies (dig and python), I like this.

Thanks -- that's about my stance too.  It helps prove the algorithm and
approach, but needs to be rewritten as a small tool.

> The only other issue I see is if the router is brought online before
> internet access is available. If I read your code correctly, it will try 4
> times per defined server (with and without DNSSEC for IPv4 and IPv6), then
> exit. It either needs to keep trying until it succeeds, or be called every
> time a connection comes up (shutting down NTPd prior and restarting after).

True -- a small tool which can be put into the interfaces up script
would work well.  I'm on a rather stable FiOS connection, so it's not
been an issue for me, which is why I'm still on the bloated version I
have -- it works.

Here's about what I have in mind; the ntpsrv stratum check and the
restart ntpd ourselves bits are beyond what's in the proof-of-concept
script, which is what I've been using on my home router since last July
or so (OpenWRT backfire and then later attitude adjustment).

  Usage: update-time-securely [-n ntpsrv] [-r reffile] [-t dnstimeout] hostnames...

Assume ntpsrv is 127.0.0.1, send a control packet equivalent to sysinfo,
check stratum.  If stratum is present and less than some cut-off (10?
Most free-wheeling modes use 12 or greater, right?) then we're done.  If
no response or stratum too high, ntpd is eligible for nuking.

Use the reference file as the trust anchor from dnsmasq/unbound; handle
the file given being a symlink and ensure the ctime of the file pointed
to (to handle it being a link which package management can point at
dnsmasq or unbound's config).  If clocktime is less then the timestamp
on that file (less a concurrency jitter) then time is Wrong.  Nuke ntpd
now, force time to step up-to that value, syslog it (before and after).

Try to resolve the hostnames, all together, A and AAAA concurrently.  If
we get any results, use those.  If we get no results, try again but with
the CD flag set in the DNS queries.

If we got results from the DNS resolution, nuke ntpd if it wasn't
already nuked.  Invoke ntpdate to set the time, accept the default
values and cut-offs for adjtime vs settimeofday.

If we nuked ntpd, start it again ourselves.  We can use a capture of
/proc/$oldpid/cmdline to get the command-line to invoke, or it can be a
flag option, or an option to use a magic exit code to indicate to the
caller that ntpd should now be started.

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/03/14 20:00, Toke Høiland-Jørgensen wrote:
> Simon Kelley <simon@thekelleys.org.uk> writes:
> 
>> That would be possible: it would require care to make it work in
>> the face of the system time being warped by NTP. Best way may  be
>> to use times() rather than time()
> 
> Good point. Since the availability of reliable time is what we're 
> waiting for, perhaps a large jump in the system clock could be
> taken to mean it has been achieved and taken as a signal to exit
> the grace period? With a timer for the case where the time is
> already accurate, of course. This would make it rather specific to
> this use case, though...
> 
It could be done, but I'm not sure it's very _nice_.

What do people think?


Cheers,

Simon.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMwpfcACgkQKPyGmiibgrfPegCfevYPY/WPb4/3lAdGnsBsM0EP
1WMAoItzEy8tbZ6d5ayfnClSvjy51tFb
=tL/K
-----END PGP SIGNATURE-----

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Dave Taht]

I ship dig as an optional package for cerowrt.

I think it's in bind-tools or bind-utils. It is terribly big, but most
people hae enough spare flash to have it.

An

opkg update
opkg list | less

will show you what is available.

I will argue that nobody wants to add functionality to the primitive
nsupdate....

On Mon, Mar 24, 2014 at 1:27 PM, David Personette <dperson@gmail.com> wrote:
> Phil,
>
> With the exception of the extra dependencies (dig and python), I like this.
> I would suggest that if DNSSEC will be enabled, that nslookup (I think
> that's the only command line resolver included by CeroWRT/OpenWRT base
> installs) be extended to have a similar option as dig, to resolve without
> DNSSEC.
>
> The only other issue I see is if the router is brought online before
> internet access is available. If I read your code correctly, it will try 4
> times per defined server (with and without DNSSEC for IPv4 and IPv6), then
> exit. It either needs to keep trying until it succeeds, or be called every
> time a connection comes up (shutting down NTPd prior and restarting after).
>
> Thanks.
>
> --
> David P.
>
>
>
> On Mon, Mar 24, 2014 at 3:12 PM, Phil Pennock
> <cerowrt-devel+phil@spodhuis.org> wrote:
>>
>> On 2014-03-21 at 23:33 -0400, Joseph Swick wrote:
>> > I've been lurking for several months now on the list and I remember some
>> > discussion about trying to find acceptable methods for bootstrapping the
>> > local system time so that DNSSEC would work.
>>
>> I raised this on the ntp-pool mailing-lists last year, looking for a
>> solution because of the chicken/egg bootstrap, with suggested approaches
>> and some trial scripts.  Eg:
>>
>>   http://lists.ntp.org/pipermail/pool/2013-July/006569.html
>>
>> For context, I'm currently running OpenWRT; attached is the
>> /etc/init.d/ntpdate which I'm using.  It relies upon having Python and
>> dig installed, as I haven't gotten around to building a small C utility
>> to do just this task, but perhaps the approach is useful enough that
>> someone else might do so?
>>
>> In summary: if the current time is less than the timestamp on the
>> unbound-maintained copy of the root zone trust anchors, then bump the
>> time up at least that far, because we must be at >= that timestamp, and
>> this increases the odds that DNSSEC will validate if we haven't been
>> off-line for too long.
>>
>> Then, for each hostname in the $STEP_SERVERS list (which could be
>> taken from ntp.conf or uci config or whatever, but here is just
>> hardcoded), I try to resolve IPv4 then IPv6, first with DNSSEC left
>> enabled, and then with DNSSEC disabled via `dig +cd`.  The first dig
>> command to return results is the one which is used.
>>
>> The idea is to minimize the potential vulnerability of syncing to a bad
>> timesource, by using DNSSEC if it's available and works, after making
>> sure it has a reasonable chance of working if we've just rebooted, and
>> only if we've been off-line for some time do we fall back to insecure
>> DNS.
>>
>> Make sure that the START value is appropriate for your systems; I've
>> found the OpenWRT defaults to be sufficiently broken that I stomp on
>> them on reinstall.  I run ntpdate once the network and firewall are up,
>> but just before ntpd and both of those well before other network
>> services which might depend upon time.
>>
>> Regards,
>> -Phil
>>
>> #!/bin/sh /etc/rc.common
>> # Copyright (C) 2006-2008 OpenWrt.org
>> # Copyright (C) 2013 Phil Pennock
>>
>> START=60
>>
>> STEP_SERVERS="0.openwrt.pool.ntp.org 1.openwrt.pool.ntp.org
>> 2.openwrt.pool.ntp.org"
>> TIMEOUT="2" # in seconds
>> PRESEED_TIMESTAMP_FN="/etc/unbound/runtime/root.autokey"
>>
>> # The core problem is that with DNSSEC, an invalid time prevents
>> resolution
>> # of DNS, but we need DNS to be able to find time-servers to get a good
>> time
>> # to be able to resolve DNS.
>> #
>> # We break out of this "Catch 22" situation by _trying_ normal DNS
>> resolution,
>> # IPv4 and then IPv6, and only if those fail do we forcibly disable DNSSEC
>> # by using dig(1)'s +cd flag ("checking disabled"); trying normally first
>> # protects us against malicious DNS trying to point us to bad
>> time-servers,
>> # if we've enough state that we _should_ already be protected.
>> #
>> # The "insecure" approach we regress to, as a last resort, is the same way
>> # the Internet functioned for decades.  There is a DoS+hijack attack path
>> # here, but if we don't have a good battery-backed clock to protect us, we
>> # don't have a better solution.
>>
>> # Also, per a suggestion from Doug Calvert, we can use the timestamp of
>> # modification of the unbound root.key file itself as an approximate time.
>> # Unbound updates the file on every refresh, so it's not too far off.
>>
>> preseed_approximate_time() {
>>         # Unfortunately, date(1) on OpenWRT can't parse the timestamp
>>         # output from ls.
>>         python -c '
>> import os, time, sys
>> fn=sys.argv[1]
>> min_time=os.stat(fn).st_ctime
>> if time.time() < min_time:
>>   want=time.strftime("%Y%m%d%H%M.%S", time.gmtime(min_time))
>>   os.system("date -u -s %s" % want)' "$PRESEED_TIMESTAMP_FN" > /dev/null
>> }
>>
>> resolve_hostname_v4() {
>> # we use the grep both to filter out cname referrals and to detect empty
>> # results
>>         local hn="$1"
>>         shift
>>         dig +nodnssec +short "$@" -t a "$hn" | grep '^[0-9][0-9.]*$'
>> }
>>
>> resolve_hostname_v6() {
>>         local hn="$1"
>>         shift
>>         dig +nodnssec +short "$@" -t aaaa "$hn" | grep -i
>> '^[0-9a-f][0-9a-f.:]*$'
>> }
>>
>> resolve_one_server() {
>>         local hn="$1"
>>         resolve_hostname_v4 $hn && return
>>         resolve_hostname_v6 $hn && return
>>         resolve_hostname_v4 $hn +cd && return
>>         resolve_hostname_v6 $hn +cd && return
>> }
>>
>> resolve_step_servers() {
>>         local server ips
>>         for server in $STEP_SERVERS ; do
>>                 resolve_one_server $server
>>         done
>> }
>>
>> start() {
>>         preseed_approximate_time
>>         for s in $(resolve_step_servers) ; do
>>                 /usr/sbin/ntpdate -s -b -u -t "$TIMEOUT" "$s" && break
>>         done
>>
>> }
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Török Edwin]

On 03/24/2014 11:03 PM, Toke Høiland-Jørgensen wrote:
> Phil Pennock <cerowrt-devel+phil@spodhuis.org> writes:
> 
>> For context, I'm currently running OpenWRT; attached is the
>> /etc/init.d/ntpdate which I'm using. It relies upon having Python and
>> dig installed, as I haven't gotten around to building a small C
>> utility to do just this task, but perhaps the approach is useful
>> enough that someone else might do so?
> 
> A functionality similar to this is already implemented in openwrt and
> runs as the first thing on boot. It finds the newest file in /etc and
> sets the system time to that:
> 
> # cat /etc/init.d/sysfixtime 
> #!/bin/sh /etc/rc.common
> # Copyright (C) 2013-2014 OpenWrt.org
> 
> START=00
> 
> boot() {
> 	local curtime="$(date +%s)"
> 	local maxtime="$(find /etc -type f -exec date +%s -r {} \; | sort -nr | head -n1)"
> 	[ $curtime -lt $maxtime ] && \
> 		date -s @$maxtime && \
> 		logger -t sysfixtime -p daemon.notice "Time fixed"
> }
> 

I haven't upgraded to -12 yet (still on -9), but logread doesn't seem to get its time updated:
Sat Jan 17 03:41:38 1970 authpriv.notice dropbear[3747]: Pubkey auth succeeded for 'root' with key md5 2a:6d:49:b6:74:91:9c:34:f8:7a:2e:40:65:b2:e9:e9 from 172.30.42.12:52391

Although the date is right:
# date
Mon Mar 24 22:05:20 GMT 2014

I tried running sysfixtime manually, or just run the 'date -s <unix-timestamp>' manually, with no luck.
Any idea how to get logread (or well the daemon/kernel) to update its timestamps?

Best regards,
--Edwin

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Phil Pennock]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

On 2014-03-24 at 22:03 +0100, Toke Høiland-Jørgensen wrote:
> A functionality similar to this is already implemented in openwrt and
> runs as the first thing on boot. It finds the newest file in /etc and
> sets the system time to that:

Is dnsmasq maintaining the root trust anchors in /etc or in /var/lib
somewhere?  (sorry, am using unbound in highly hacked setup)

> I do believe it would be feasible to include your script without the
> preseed part pretty much as-is? It adds a dependency on dig, but I guess
> that is not unreasonable (certainly not for cerowrt, but maybe for
> openwrt default). The ntpdate dependency can probably be gotten away
> with by substituting an appropriate ntpd -q command...

I slapped my name on it as a copyright update, simply because I was
touching it and wanted blame for mistakes to come to me instead of
normal upstream, since I was posting to a(nother) mailing-list and
sometimes that spreads further than I expect.  I'm happy for this to be
used/modified/distributed under whatever the CeroWRT/OpenWRT default
license is.

So: go for it.

-Phil

[-- Attachment #2: Type: application/pgp-signature, Size: 455 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

Török Edwin <edwin+ml-cerowrt@etorok.net> writes:

> I haven't upgraded to -12 yet (still on -9), but logread doesn't seem
> to get its time updated: Sat Jan 17 03:41:38 1970 authpriv.notice
> dropbear[3747]: Pubkey auth succeeded for 'root' with key md5
> 2a:6d:49:b6:74:91:9c:34:f8:7a:2e:40:65:b2:e9:e9 from
> 172.30.42.12:52391
>
> Although the date is right:
> # date
> Mon Mar 24 22:05:20 GMT 2014
>
> I tried running sysfixtime manually, or just run the 'date -s
> <unix-timestamp>' manually, with no luck. Any idea how to get logread
> (or well the daemon/kernel) to update its timestamps?

Sysfixtime only touches the system clock. Just checked on my box, and I
have the same issue with the logs. The system log is managed by ubusd
these days, but neither kicking that or the log daemon itself seems to
get the timings right on a 'logread'.

Interestingly, running logread -f outputs the incoming events with the
right timestamps; so I guess it's a bug somewhere that fails to get the
offset for old events or something...

Found this in the openwrt HEAD git log:

commit 345c4805ee324b4a34bd60c8f5762f0b6dd27497
Author: blogic <blogic@3c298f89-4303-0410-b956-a3cf2f4a3e73>
Date:   Tue Mar 18 19:22:38 2014 +0000

    ubox: update to latest git head
    
    logread now shows the right time.
    
    Signed-off-by: John Crispin <blogic@openwrt.org>
    
    git-svn-id: svn://svn.openwrt.org/openwrt/trunk@39951 3c298f89-4303-0410-b956-a3cf2f4a3e73

Which is newer than -9 but older (I think; the tag is missing from
github) than -12. So an upgrade should probably fix it :)

*off to upgrade my own install*

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Joseph Swick]

On 03/24/2014 07:33 PM, Toke Høiland-Jørgensen wrote:
> Which is newer than -9 but older (I think; the tag is missing from
> github) than -12. So an upgrade should probably fix it :)
> 
> *off to upgrade my own install*
> 
> -Toke
> 

I just updated to .32-12 myself, I was on .28-16, and was seeing issues
where dnsmasq would just stop serving up DNS requests.  Hopefully if I'm
watching the logfile I might see something if it happens again, but then
I would also need to be watching the correct logfile.  I do see a large
jump in time after a cold-start in logread that goes from an old time to
the correct time and logread -f does display the correct time.

So it would look like that particular issue with logread might be fixed
in -12.

-Joseph

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[David Personette]

[-- Attachment #1: Type: text/plain, Size: 7533 bytes --]

# ll $(which nslookup)
lrwxrwxrwx    1 root     root            17 Mar 21 13:16 /usr/bin/nslookup
-> ../../bin/busybox

I'm not sure it's the old nslookup that we're thinking of...

-- 
David P.



On Mon, Mar 24, 2014 at 5:58 PM, Dave Taht <dave.taht@gmail.com> wrote:

> I ship dig as an optional package for cerowrt.
>
> I think it's in bind-tools or bind-utils. It is terribly big, but most
> people hae enough spare flash to have it.
>
> An
>
> opkg update
> opkg list | less
>
> will show you what is available.
>
> I will argue that nobody wants to add functionality to the primitive
> nsupdate....
>
> On Mon, Mar 24, 2014 at 1:27 PM, David Personette <dperson@gmail.com>
> wrote:
> > Phil,
> >
> > With the exception of the extra dependencies (dig and python), I like
> this.
> > I would suggest that if DNSSEC will be enabled, that nslookup (I think
> > that's the only command line resolver included by CeroWRT/OpenWRT base
> > installs) be extended to have a similar option as dig, to resolve without
> > DNSSEC.
> >
> > The only other issue I see is if the router is brought online before
> > internet access is available. If I read your code correctly, it will try
> 4
> > times per defined server (with and without DNSSEC for IPv4 and IPv6),
> then
> > exit. It either needs to keep trying until it succeeds, or be called
> every
> > time a connection comes up (shutting down NTPd prior and restarting
> after).
> >
> > Thanks.
> >
> > --
> > David P.
> >
> >
> >
> > On Mon, Mar 24, 2014 at 3:12 PM, Phil Pennock
> > <cerowrt-devel+phil@spodhuis.org> wrote:
> >>
> >> On 2014-03-21 at 23:33 -0400, Joseph Swick wrote:
> >> > I've been lurking for several months now on the list and I remember
> some
> >> > discussion about trying to find acceptable methods for bootstrapping
> the
> >> > local system time so that DNSSEC would work.
> >>
> >> I raised this on the ntp-pool mailing-lists last year, looking for a
> >> solution because of the chicken/egg bootstrap, with suggested approaches
> >> and some trial scripts.  Eg:
> >>
> >>   http://lists.ntp.org/pipermail/pool/2013-July/006569.html
> >>
> >> For context, I'm currently running OpenWRT; attached is the
> >> /etc/init.d/ntpdate which I'm using.  It relies upon having Python and
> >> dig installed, as I haven't gotten around to building a small C utility
> >> to do just this task, but perhaps the approach is useful enough that
> >> someone else might do so?
> >>
> >> In summary: if the current time is less than the timestamp on the
> >> unbound-maintained copy of the root zone trust anchors, then bump the
> >> time up at least that far, because we must be at >= that timestamp, and
> >> this increases the odds that DNSSEC will validate if we haven't been
> >> off-line for too long.
> >>
> >> Then, for each hostname in the $STEP_SERVERS list (which could be
> >> taken from ntp.conf or uci config or whatever, but here is just
> >> hardcoded), I try to resolve IPv4 then IPv6, first with DNSSEC left
> >> enabled, and then with DNSSEC disabled via `dig +cd`.  The first dig
> >> command to return results is the one which is used.
> >>
> >> The idea is to minimize the potential vulnerability of syncing to a bad
> >> timesource, by using DNSSEC if it's available and works, after making
> >> sure it has a reasonable chance of working if we've just rebooted, and
> >> only if we've been off-line for some time do we fall back to insecure
> >> DNS.
> >>
> >> Make sure that the START value is appropriate for your systems; I've
> >> found the OpenWRT defaults to be sufficiently broken that I stomp on
> >> them on reinstall.  I run ntpdate once the network and firewall are up,
> >> but just before ntpd and both of those well before other network
> >> services which might depend upon time.
> >>
> >> Regards,
> >> -Phil
> >>
> >> #!/bin/sh /etc/rc.common
> >> # Copyright (C) 2006-2008 OpenWrt.org
> >> # Copyright (C) 2013 Phil Pennock
> >>
> >> START=60
> >>
> >> STEP_SERVERS="0.openwrt.pool.ntp.org 1.openwrt.pool.ntp.org
> >> 2.openwrt.pool.ntp.org"
> >> TIMEOUT="2" # in seconds
> >> PRESEED_TIMESTAMP_FN="/etc/unbound/runtime/root.autokey"
> >>
> >> # The core problem is that with DNSSEC, an invalid time prevents
> >> resolution
> >> # of DNS, but we need DNS to be able to find time-servers to get a good
> >> time
> >> # to be able to resolve DNS.
> >> #
> >> # We break out of this "Catch 22" situation by _trying_ normal DNS
> >> resolution,
> >> # IPv4 and then IPv6, and only if those fail do we forcibly disable
> DNSSEC
> >> # by using dig(1)'s +cd flag ("checking disabled"); trying normally
> first
> >> # protects us against malicious DNS trying to point us to bad
> >> time-servers,
> >> # if we've enough state that we _should_ already be protected.
> >> #
> >> # The "insecure" approach we regress to, as a last resort, is the same
> way
> >> # the Internet functioned for decades.  There is a DoS+hijack attack
> path
> >> # here, but if we don't have a good battery-backed clock to protect us,
> we
> >> # don't have a better solution.
> >>
> >> # Also, per a suggestion from Doug Calvert, we can use the timestamp of
> >> # modification of the unbound root.key file itself as an approximate
> time.
> >> # Unbound updates the file on every refresh, so it's not too far off.
> >>
> >> preseed_approximate_time() {
> >>         # Unfortunately, date(1) on OpenWRT can't parse the timestamp
> >>         # output from ls.
> >>         python -c '
> >> import os, time, sys
> >> fn=sys.argv[1]
> >> min_time=os.stat(fn).st_ctime
> >> if time.time() < min_time:
> >>   want=time.strftime("%Y%m%d%H%M.%S", time.gmtime(min_time))
> >>   os.system("date -u -s %s" % want)' "$PRESEED_TIMESTAMP_FN" > /dev/null
> >> }
> >>
> >> resolve_hostname_v4() {
> >> # we use the grep both to filter out cname referrals and to detect empty
> >> # results
> >>         local hn="$1"
> >>         shift
> >>         dig +nodnssec +short "$@" -t a "$hn" | grep '^[0-9][0-9.]*$'
> >> }
> >>
> >> resolve_hostname_v6() {
> >>         local hn="$1"
> >>         shift
> >>         dig +nodnssec +short "$@" -t aaaa "$hn" | grep -i
> >> '^[0-9a-f][0-9a-f.:]*$'
> >> }
> >>
> >> resolve_one_server() {
> >>         local hn="$1"
> >>         resolve_hostname_v4 $hn && return
> >>         resolve_hostname_v6 $hn && return
> >>         resolve_hostname_v4 $hn +cd && return
> >>         resolve_hostname_v6 $hn +cd && return
> >> }
> >>
> >> resolve_step_servers() {
> >>         local server ips
> >>         for server in $STEP_SERVERS ; do
> >>                 resolve_one_server $server
> >>         done
> >> }
> >>
> >> start() {
> >>         preseed_approximate_time
> >>         for s in $(resolve_step_servers) ; do
> >>                 /usr/sbin/ntpdate -s -b -u -t "$TIMEOUT" "$s" && break
> >>         done
> >>
> >> }
> >>
> >> _______________________________________________
> >> Cerowrt-devel mailing list
> >> Cerowrt-devel@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >>
> >
> >
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
>

[-- Attachment #2: Type: text/html, Size: 10417 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Michael Richardson]

Dave Taht <dave.taht@gmail.com> wrote:
    > I ship dig as an optional package for cerowrt.

    > I think it's in bind-tools or bind-utils. It is terribly big, but most
    > people hae enough spare flash to have it.

I'd like to see the mechanism as an option in the ntpdate binary.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/03/14 20:00, Toke Høiland-Jørgensen wrote:
> Simon Kelley <simon@thekelleys.org.uk> writes:
> 
>> That would be possible: it would require care to make it work in
>> the face of the system time being warped by NTP. Best way may  be
>> to use times() rather than time()
> 
> Good point. Since the availability of reliable time is what we're 
> waiting for, perhaps a large jump in the system clock could be
> taken to mean it has been achieved and taken as a signal to exit
> the grace period? With a timer for the case where the time is
> already accurate, of course. This would make it rather specific to
> this use case, though...
> 
> -Toke
> 


Ok, here's a suggestion.

Add a command-line flag to dnsmasq, called --dnssec-no-timecheck or
something, which disables the checking of RRSIG inception and expiry
times. This flag is automatically reset when dnsmasq gets the SIGHUP
signal which causes it to clear the cache and re-read (some)
configuration.

Now CeroWRT or equivalent can modify the script which starts or
restarts dnsmasq to provide that flag iff NTP has not found a valid
time yet, and modify the NTP script to SIGHUP dnsmasq when a valid
time is found. Any malicious entries which may have entered the cache
during the period of relaxed checking are discarded at this point.


This is trivial to do, and can go in 2.69rc2, if agreed promptly.


Cheers,

Simon.





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM0jCsACgkQKPyGmiibgrdEnQCfQ94UI/kbBmmX3sEUGBAMCtDS
glgAoIH2EAadNw4WmJAXBhYtknTHGk/r
=VGN4
-----END PGP SIGNATURE-----

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

Simon Kelley <simon@thekelleys.org.uk> writes:

> Add a command-line flag to dnsmasq, called --dnssec-no-timecheck or
> something, which disables the checking of RRSIG inception and expiry
> times. This flag is automatically reset when dnsmasq gets the SIGHUP
> signal which causes it to clear the cache and re-read (some)
> configuration.

One issue with this is that the openwrt init scripts currently take ages
to restart dnsmasq because it has to rebuild the configuration from uci,
which is done in shell. Other than that I like the approach; it would
enable *some* validation at least (I presume?).

Another approach to "exiting" the mode could be that if the flag is
turned off, for each validation attempt, first try to see if the time
*does* validate; if it does, turn off the flag, otherwise retry the
validation while ignoring the time. That would make it possible to just
stick the flag in the configuration and have things "just work", I
think. Only instance I can think of where this is not true is if some
lookup succeeds due to a longer validity time, which will disable the
flag, and then having the subsequent NTP server lookup fail. Not sure
what the probability of this happening is, though.

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28/03/14 07:57, Toke Høiland-Jørgensen wrote:
> Simon Kelley <simon@thekelleys.org.uk> writes:
> 
>> Add a command-line flag to dnsmasq, called --dnssec-no-timecheck
>> or something, which disables the checking of RRSIG inception and
>> expiry times. This flag is automatically reset when dnsmasq gets
>> the SIGHUP signal which causes it to clear the cache and re-read
>> (some) configuration.
> 
> One issue with this is that the openwrt init scripts currently take
> ages to restart dnsmasq because it has to rebuild the configuration
> from uci, which is done in shell.

Which makes this scheme better, since you don't have to restart
dnsmasq once the time stabilises, just SIGHUP it.

> Other than that I like the approach; it would enable *some*
> validation at least (I presume?).
All validation apart from checking the dates on the keys would continue.
> 
> Another approach to "exiting" the mode could be that if the flag
> is turned off, for each validation attempt, first try to see if the
> time *does* validate; if it does, turn off the flag, otherwise
> retry the validation while ignoring the time. That would make it
> possible to just stick the flag in the configuration and have
> things "just work", I think. Only instance I can think of where
> this is not true is if some lookup succeeds due to a longer
> validity time, which will disable the flag, and then having the
> subsequent NTP server lookup fail. Not sure what the probability of
> this happening is, though.

Neither am I, nut it would be an interesting bug to find.....


I'll add --dnssec-no-timecheck when I get a moment today.


Cheers,

Simon.

> 
> -Toke
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM1PAcACgkQKPyGmiibgrfVRwCaAkzlyNV7rl6TCEImWbyd8ohJ
gtQAn3BJe5MneWk1c44ZiZkMNrxHCFIj
=Erot
-----END PGP SIGNATURE-----

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

Simon Kelley <simon@thekelleys.org.uk> writes:

> Which makes this scheme better, since you don't have to restart
> dnsmasq once the time stabilises, just SIGHUP it.

Yeah, but my concern was the opposite: say the flag is enabled in the
config, it will run at boot in this mode, some script will kick in and
set/verify the time, then SIGHUP dnsmasq. Everything is fine so far.

Now if dnsmasq is restarted later for some reason (manually, config
change, whatever), the flag will be enabled, and there will be no script
to SIGHUP dnsmasq. This is why I suggested having the flag do nothing if
it indeed *is* possible to verify the timestamps. But I can see how from
a debugging perspective that would be an annoying feature.

I suppose special-casing the init script to add the flag only on boot
might be a solution. Will experiment with it once you've added the flag :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28/03/14 09:18, Toke Høiland-Jørgensen wrote:
> Simon Kelley <simon@thekelleys.org.uk> writes:
> 
>> Which makes this scheme better, since you don't have to restart 
>> dnsmasq once the time stabilises, just SIGHUP it.
> 
> Yeah, but my concern was the opposite: say the flag is enabled in
> the config, it will run at boot in this mode, some script will kick
> in and set/verify the time, then SIGHUP dnsmasq. Everything is fine
> so far.
> 
> Now if dnsmasq is restarted later for some reason (manually,
> config change, whatever), the flag will be enabled, and there will
> be no script to SIGHUP dnsmasq.


Understood, my suggestion is that the dnsmasq startup script somehow
interrogate NTP as to if it's running, and if it has a time lock. Only
setting the flag if it isn't or doesn't. Of course that depends on NTP
being able to answer the question.


Cheers,

Simon.

 This is why I suggested having the flag do nothing if
> it indeed *is* possible to verify the timestamps. But I can see how
> from a debugging perspective that would be an annoying feature.
> 
> I suppose special-casing the init script to add the flag only on
> boot might be a solution. Will experiment with it once you've added
> the flag :)
> 
> -Toke
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM1UfYACgkQKPyGmiibgrcJDwCfTZ5Z62g2ba53HHosgSy4paHh
rqYAoIvjh3U7WfjHSst6mI/vWQvHggPI
=Jtnj
-----END PGP SIGNATURE-----

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

Simon Kelley <simon@thekelleys.org.uk> writes:

> Understood, my suggestion is that the dnsmasq startup script somehow
> interrogate NTP as to if it's running, and if it has a time lock. Only
> setting the flag if it isn't or doesn't. Of course that depends on NTP
> being able to answer the question.

Right. Pretty sure busybox ntpd isn't able to answer that. But since
dnsmasq is spawned from a hotplug script on boot, that script can
presumably do something clever...

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28/03/14 10:48, Toke Høiland-Jørgensen wrote:
> Simon Kelley <simon@thekelleys.org.uk> writes:
> 
>> Understood, my suggestion is that the dnsmasq startup script
>> somehow interrogate NTP as to if it's running, and if it has a
>> time lock. Only setting the flag if it isn't or doesn't. Of
>> course that depends on NTP being able to answer the question.
> 
> Right. Pretty sure busybox ntpd isn't able to answer that. But
> since dnsmasq is spawned from a hotplug script on boot, that script
> can presumably do something clever...
> 


Good. Since whatever the cleverness is, it will vary in different
OSs/distrubutions, it should definitely be in the startup script and
not the dnsmasq code.


Cheers,


Simon.

> -Toke
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM10YUACgkQKPyGmiibgrfTfwCfR5KBMHRXaPyyTyHvPNVqzmPW
r3IAoKh19x3yrHYa7a9do+aMPRsMcSBQ
=eQf5
-----END PGP SIGNATURE-----

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28/03/14 10:48, Toke Høiland-Jørgensen wrote:
> Simon Kelley <simon@thekelleys.org.uk> writes:
> 
>> Understood, my suggestion is that the dnsmasq startup script
>> somehow interrogate NTP as to if it's running, and if it has a
>> time lock. Only setting the flag if it isn't or doesn't. Of
>> course that depends on NTP being able to answer the question.
> 
> Right. Pretty sure busybox ntpd isn't able to answer that. But
> since dnsmasq is spawned from a hotplug script on boot, that script
> can presumably do something clever...
> 

- --dnssec-no-timecheck in the the git repo now......



Cheers,


Simon.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM14b0ACgkQKPyGmiibgrcz4wCfbKwa2ipZgtWcoiGukiR7MLr7
LMEAn1EhXhRw+rpUsGqfkIvO1wmiFobW
=8oKH
-----END PGP SIGNATURE-----

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 211 bytes --]

Simon Kelley <simon@thekelleys.org.uk> writes:

> --dnssec-no-timecheck in the the git repo now......

Great! Prototyped some harness scripts yesterday to run it; will try
them out when I get a chance :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping -- prototype!

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 2102 bytes --]

Right, so I took a stab at prototyping something based on the
--dnssec-no-timecheck option Simon just added to dnsmasq.

There's an updated dnsmasq package here:

http://archive.tohojo.dk/cerowrt/wndr/3.10.32-12-tohojo/packages/dnsmasq-dhcpv6_2014-03-29-b7639d58158c6e971535893b407560e136a27994_ar71xx.ipk

Which, apart from the change to dnsmasq itself, has a modification to
the init script that will add the parameter to dnsmasq on bootup (but
not on subsequent restarts), and then spawn a script that will check the
ntpd stratum status and wait for it to be set; or, if no stratum
information is available just set the time with ntpd -q. Once either the
time has been set, or ntpd reports a valid stratum, dnsmasq is sent
SIGHUP to turn dnssec time validation back on.

To get ntpd to report its stratum status, it is spawned with the -S
parameter which will periodically report its status, including stratum.
A small script then records that in a file which the dnsmasq script
checks. Since the script falls back to running ntpd -q, this change to
ntpd is not strictly necessary; but I thought it better to make it
available rather than running a second ntp sync on top of the running
ntpd server. To enable the ntpd modification, replace
/etc/init.d/sysntpd with the attached file, put this into
/usr/sbin/ntpd_record_stratum and chmod +x it:

#!/bin/sh
echo $stratum > /var/ntp.stratum

There's a busybox package with this modification included here, but I
can't promise it is built with the exact same options as the one
distributed with cerowrt (though it works for me):

http://archive.tohojo.dk/cerowrt/wndr/3.10.32-12-tohojo/packages/busybox_1.19.4-7_ar71xx.ipk



Please test this out and let me know if it works for you. It seems to
work for me; however, I have not been successful in actually getting my
router to boot up without the time synced. Not sure if it's just ntpd
that syncs up before the script runs (and then takes a while to update
its stratum), or if some hidden mechanism does something magical to set
the time (even when the *fixtime init scripts are disabled).


-Toke


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: sysntpd --]
[-- Type: text/x-sh, Size: 749 bytes --]

#!/bin/sh /etc/rc.common
# Copyright (C) 2011 OpenWrt.org

START=98

USE_PROCD=1
PROG=/usr/sbin/ntpd

validate_ntp_section() {
	uci_validate_section system timeserver "${1}" \
		'server:list(host)' 'enable_server:bool:0'
}

start_service() {
	local server enable_server peer

	validate_ntp_section ntp || {
		echo "validation failed"
		return 1
	}

	[ -z "$server" ] && return

	procd_open_instance
	procd_set_param command "$PROG" -n -S /usr/sbin/ntpd_record_stratum
	[ "$enable_server" = "1" ] && procd_append_param command -l
	for peer in $server; do
		procd_append_param command -p $peer
	done
	procd_set_param respawn
	procd_close_instance
}

service_triggers()
{
	procd_add_reload_trigger "system"
	procd_add_validation validate_ntp_section
}

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping -- prototype!

[Michael Richardson]

This process needs to be written up as an IETF BCP.

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping -- prototype!

[Dave Taht]

Well I strongly favor less interdependency between ntp, a monitoring
script, and dnsmasq.

I'd kind of like some sort of check on validating the dns roots, if it fails
due to the time being wrong, disable dnssec and wait for clock slew.

Another other alternative is a ntp that does a query with the
authenticate bit off, all the time.

I kind of lost track of all the other suggestions...


On Sat, Mar 29, 2014 at 2:21 PM, Michael Richardson <mcr@sandelman.ca> wrote:
>
> This process needs to be written up as an IETF BCP.
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping -- prototype!

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]

Dave Taht <dave.taht@gmail.com> writes:

> Well I strongly favor less interdependency between ntp, a monitoring
> script, and dnsmasq.

Well, the reverse dependency (i.e. the modification of the ntpd startup
script) is not strictly needed, so the dependency could be made to be
one-way (it kinda is already). Also, in case ntpd is missing it's quite
easy to just bail out and start dnsmasq in full validation mode.

The nice thing about this switch to dnsmasq is that it does validation
of the chain, just ignoring validity times; which presumably would make
it harder to exploit as you'd need an actual valid key, rather than just
be able to spoof the packets reply of the non-validated query...

> I'd kind of like some sort of check on validating the dns roots, if it
> fails due to the time being wrong, disable dnssec and wait for clock
> slew.

Well conceivably you could be in a situation where the roots validate,
but validation fails further down the chain, making that scheme fail in
weird and unpredictable ways?

> Another other alternative is a ntp that does a query with the
> authenticate bit off, all the time.

This would involve teaching the uclibc resolver about the CD bit and
expose it in the resolver API I think. Can look into how difficult this
actually is to do; with the caveat that I'm not exactly an expert on
such code :P

Also, see above re: validation modes.

> On Sat, Mar 29, 2014 at 2:21 PM, Michael Richardson <mcr@sandelman.ca> wrote:
>>
>> This process needs to be written up as an IETF BCP.

I'll be happy to write something up once we actually settle on something :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping -- prototype!

[Dave Taht]

On Sun, Mar 30, 2014 at 6:21 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Dave Taht <dave.taht@gmail.com> writes:
>
>> Well I strongly favor less interdependency between ntp, a monitoring
>> script, and dnsmasq.
>
> Well, the reverse dependency (i.e. the modification of the ntpd startup
> script) is not strictly needed, so the dependency could be made to be
> one-way (it kinda is already). Also, in case ntpd is missing it's quite
> easy to just bail out and start dnsmasq in full validation mode.
>
> The nice thing about this switch to dnsmasq is that it does validation
> of the chain, just ignoring validity times; which presumably would make
> it harder to exploit as you'd need an actual valid key, rather than just
> be able to spoof the packets reply of the non-validated query...
>
>> I'd kind of like some sort of check on validating the dns roots, if it
>> fails due to the time being wrong, disable dnssec and wait for clock
>> slew.
>
> Well conceivably you could be in a situation where the roots validate,
> but validation fails further down the chain, making that scheme fail in
> weird and unpredictable ways?

http://www.bortzmeyer.org/dns-routing-hijack-turkey.html

?

>> Another other alternative is a ntp that does a query with the
>> authenticate bit off, all the time.

>
> This would involve teaching the uclibc resolver about the CD bit and
> expose it in the resolver API I think. Can look into how difficult this
> actually is to do; with the caveat that I'm not exactly an expert on
> such code :P


>
> Also, see above re: validation modes.
>
>> On Sat, Mar 29, 2014 at 2:21 PM, Michael Richardson <mcr@sandelman.ca> wrote:
>>>
>>> This process needs to be written up as an IETF BCP.
>
> I'll be happy to write something up once we actually settle on something :)
>
> -Toke



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping -- prototype!

[Toke Høiland-Jørgensen]

> > Well conceivably you could be in a situation where the roots
> validate,
> > but validation fails further down the chain, making that scheme fail
> in
> > weird and unpredictable ways?
> 
> http://www.bortzmeyer.org/dns-routing-hijack-turkey.html
> 
> ?

I was thinking more about the case where, say, the root server keys validate, but the keys further down the chain have been changed, and the clock is set to a time in the interval between the respective beginnings of validity time... I would think that could happen with no malicious intent way too often for the root keys to be a very useful heuristic to use...

-Toke

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping -- prototype!

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

Toke Høiland-Jørgensen <toke@toke.dk> writes:

> This would involve teaching the uclibc resolver about the CD bit and
> expose it in the resolver API I think. Can look into how difficult
> this actually is to do; with the caveat that I'm not exactly an expert
> on such code :P

OK, went looking at the code. As far as I can tell, it would probably be
possible to teach the part of uclibc that does DNS lookups about the CD
bit. However, I'm not sure there's a way to pass the request for no
validation through the resolver to the right place; certainly not
without entirely reworking the way ntpd does hostname lookups (and
possibly other parts of the C library as well). Either way it's not
something I feel up to with the time I have available for hacking on
cerowrt. So I am abandoning this avenue of enquiry.

I'll be happy to work on improving the dnsmasq script with the
--dnssec-no-timecheck parameter approach; but if it is going to be
rejected in favour of a different approach I'd rather not waste any more
time on it... :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping -- prototype!

[Dave Taht]

On Sun, Mar 30, 2014 at 12:30 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>
>> This would involve teaching the uclibc resolver about the CD bit and
>> expose it in the resolver API I think. Can look into how difficult
>> this actually is to do; with the caveat that I'm not exactly an expert
>> on such code :P
>
> OK, went looking at the code. As far as I can tell, it would probably be
> possible to teach the part of uclibc that does DNS lookups about the CD
> bit. However, I'm not sure there's a way to pass the request for no

Only thing I can think of that makes some sense at the moment is
doing a stubby resolver in ntp itself.

> validation through the resolver to the right place; certainly not

There isn't. Arguably there should have been a flag added to getaddrinfo
ages ago...

> without entirely reworking the way ntpd does hostname lookups (and
> possibly other parts of the C library as well). Either way it's not

Not today then. :)

> something I feel up to with the time I have available for hacking on
> cerowrt. So I am abandoning this avenue of enquiry.

So far fixing this dependency has eluded dnssec implementers for 12 years.

> I'll be happy to work on improving the dnsmasq script with the
> --dnssec-no-timecheck parameter approach; but if it is going to be
> rejected in favour of a different approach I'd rather not waste any more
> time on it... :)

Please push the script into the cerowrt repo for further testing.

> -Toke



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping -- prototype!

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

Dave Taht <dave.taht@gmail.com> writes:

> Only thing I can think of that makes some sense at the moment is doing
> a stubby resolver in ntp itself.

Right. Next time I feel like writing one of those I'll give it a shot... :P

> There isn't. Arguably there should have been a flag added to
> getaddrinfo ages ago...

I was going to add one; however, it seems it's not entirely straight
forward to propagate it through the C library so the code that produces
DNS packets can actually act on it...

> Please push the script into the cerowrt repo for further testing.

Pushed :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping -- prototype!

[Robert Bradley]

[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]

On 30/03/2014 21:51, Toke Høiland-Jørgensen wrote:
> Dave Taht <dave.taht@gmail.com> writes:
>
>> There isn't. Arguably there should have been a flag added to
>> getaddrinfo ages ago...
> I was going to add one; however, it seems it's not entirely straight
> forward to propagate it through the C library so the code that produces
> DNS packets can actually act on it...

There is a val_getaddrinfo() available in libval which is based on
http://tools.ietf.org/html/draft-hayatnagarkar-dnsext-validator-api-09#section-3.2
if we want to go down that route.  From what I can tell, you'd start by
creating your own validation context
(http://tools.ietf.org/html/draft-hayatnagarkar-dnsext-validator-api-09#section-6)
and use something like:

/* Use default policy (label=NULL) and disable clock skew checks */
char *label = NULL;
val_context_t *ctx;
val_status_t dnssec_status;
val_create_context(label, *ctx); /* Error handling here for non-zero
return values or ctx=NULL */
val_context_setqflags(ctx, VAL_CTX_FLAG_SET, VAL_QUERY_IGNORE_SKEW);

/* Perform lookup (ignoring error handling again) */
val_getaddrinfo(ctx, ..., *status);
if (val_istrusted(status))
{
/*
DNSSEC signature check is good or not applicable:
Continue as normal
*/
}

/* Clear context */
val_free_context(ctx);

The validation in that case is done entirely outside dnsmasq (with the
CD bit set on the libval queries).  We have libval available already but
not installed, so that is not a problem.  Implementing this in BusyBox
and sysntpd may be a bit of an issue though.

-- 
Robert Bradley



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping -- prototype!

[Robert Bradley]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

On 31/03/2014 13:42, Robert Bradley wrote:
> There is a val_getaddrinfo() available in libval which is based on
> http://tools.ietf.org/html/draft-hayatnagarkar-dnsext-validator-api-09#section-3.2
> if we want to go down that route.
<snip>
> The validation in that case is done entirely outside dnsmasq (with the
> CD bit set on the libval queries).  We have libval available already but
> not installed, so that is not a problem.  Implementing this in BusyBox
> and sysntpd may be a bit of an issue though.

I have a *very* rough implementation of this at
https://github.com/rb12345/busybox (ntpd-dnssec branch), based on
busybox HEAD.  However, this is completely untested at this point.  This
patch requires the libval and libsres libraries to operate and
introduces a new ENABLE_FEATURE_DNSSEC flag/config option.  When
enabled, the internal str2sockaddr/val_str2sockaddr function will always
validate DNSSEC signatures using the libval library.  The nice thing
about this is that if it works, upstream ISP support for DNSSEC is
unnecessary since all the queries and responses are performed locally. 
The downside is that everything in busybox that uses str2sockaddr is now
forced to do recursive DNSSEC lookups.

-- 
Robert Bradley



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]