Re: [Ntp] [EXT] Pool and DNS

[Neta R S <[e-mail]>]

Hi,

Perhaps, in order to avoid the uncertainty regarding when NTPs needs to
query the DNS, we can just say that assuming the calibration period is one
month,
250 DNS queries means an average of  about 10 DNS queries per day, which is
usually several order of magnitude lower than the total daily number of DNS
queries per machine.

Regarding NTS, I will add a reference to it in the draft, where we say that
“adding an authentication layer to Khronos will enhance its security
guarantees and enable the detection of various spoofing and modification
attacks.”

Thanks,
Neta

On Wed, Oct 19, 2022 at 12:58 PM Ulrich Windl <
[e-mail]> wrote:

> >>> Hal Murray <[e-mail]> schrieb am 19.10.2022 um 06:42 in
> Nachricht
> <[e-mail]
> >:
>
> >> Around 250 DNS queries are required by Khronos to obtain a pool of 1000
> NTP
> >> servers, which is equal to the number of queries performed by NTPv4 in a
> >> duration of 10 days (assuming a query per hour).
> >
> > Where did that "a query per hour" come from?
>
> Good question: maxpoll default is still 10, and on typical servers a higher
> number like 12 makes little sense.
>
> >
> > It's not wildly wrong and I don't have a better number.  But I worry
> that
> > somebody will assume it is a solid data point and use it in some future
> line
>
> >
> > of reasoning.
> >
> > ‑‑‑‑‑‑‑‑
> >
> > My reading is that pool traffic is bimodal.  ntpd makes a few DNS
> requests
> > on
> > startup then uses those servers for a long time.  sntp makes a DNS
> request
> > every time it is run.
> >
> > You can see that by watching the traffic on a server in the pool when
> you
> > disable it by setting the traffic rate to monitor‑only.  The traffic
> drops
>
> By "disabling" you mean removing it from the DNS pool, but keep it running?
>
> > abruptly by X%, then slowly decays.  "Slowly" is ballpark of 10% per
> day.  X
>
> >
> > is ballpark of 60%.  (I didn't get decent data because I only figured
> out
> > what
> > was going on after I had already messed things up.  Next time...)
> >
> > ‑‑‑‑‑‑‑‑‑‑
> >
> > The main problem with DNS and the pool is that there is currently no
> clean
> > way to remove a server from the pool.  If you remove it from the pool,
> the
> > sntp traffic will vanish since it will get removed from future DNS
> answers.
>
> > But the ntpd traffic will continue to use existing servers as long as
> ntpd
> > keeps running and the servers keep responding.
>
> Not quite: If the server performs worse than the rest, ntpd wil request
> another one, dropping the bad one.
> We are runníng most servers using manycast here, but the mechanism should
> be
> similar.
>
>
> >
> > There is no way to ask if a server is still in the pool.  If there was,
> ntpd
>
> > should check every day or week or ...  That would add more DNS traffic
> from
>
> > the long running ntpd servers.  Khronos would add much more.
> >
> > ‑‑‑‑‑‑‑‑‑‑
> >
> > The more interesting question is NTS.  The NTS‑KE step is fairly
> heavyweight,
> > much more work than a DNS lookup.
> >
> > The current parameters are 8 cookies with a lifetime of a day.  A day is
> > 86400 seconds.  That means we need to poll each server every 10800
> seconds.
>
> > With 1000 servers and M=15 (from the draft) that will take a Khronos
> poll
> > every (10800/1000)*15 => 162 seconds.  If Khronos runs at 10x the poll
> time
> of
> > ntpd, that's not going to work.
> >
> > We could gain a factor of 2 or 3 by dropping cookies older than a day.
> (and
>
> > asking for several more to fill up again when we do poll a server)
> >
> > Of course, NTS doesn't work with the pool and I don't see how to fix
> that,
> > so this is all a wild goose chase.
> >
> >
> > Maybe we should be comparing Khronos with 1 or 2 trusted servers using
> NTS.
> >
> >
> > ‑‑
> > These are my opinions.  I hate spam.
> >
> >
> >
> > _______________________________________________
> > ntp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ntp
>
>
>
>