Re: [Ntp] [EXT] Pool and DNS

[David Venhoek <[e-mail]>]

Although Marcus is right that there isn't a strict lifetime specified
for NTS cookies, I think we shouldn't disregard the potential impact
this could have in terms of load when combined with NTS. RFC8915 does
suggest on cookies the following (although non-normatively):

Servers should periodically (e.g., once daily) generate a new pair
'(I,K)' and immediately switch to using these values for all
newly-generated cookies. Following each such key rotation, servers
should securely erase any previously generated keys that should now be
expired. Servers should continue to accept any cookie generated using
keys that they have not yet erased, even if those keys are no longer
current. Erasing old keys provides for forward secrecy, limiting the
scope of what old information can be stolen if a master key is somehow
compromised. Holding on to a limited number of old keys allows clients
to seamlessly transition from one generation to the next without
having to perform a new NTS-KE handshake.

With multi-day polling intervals, which could easily occur with
Khronos, it is not inconceivable that the cookies will be expired each
and every time an NTS server is queried, which would mean a NTS-KE
exchange each and every time that server is used. Given the cost of
those, I think we should at least discuss why this is a reasonable
cost to incur.

Kind regards,
David

On Fri, Oct 21, 2022 at 11:08 PM Neta R S <[e-mail]> wrote:
>
> 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
>>
>>
>>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp