ntp.conf changes for NTS

[Achim Gratz]

Richard Laager via devel writes:
> On 1/30/19 2:37 PM, Gary E. Miller via devel wrote:
>> Sure there is, we now have a choice that did not formerly exist, and I
>> can see uses for both:
>> 
>> 1. If we do not get desired server: fail
>> 2. If we do not get desired server: use the offered one instead
>> 
>> #2 is new to NTS.
>> 
>> For an unattended server, I would want #2.  For testing, or a closely
>> watched server, I would want #1.
>
> There's another complication too. The server can send back a name or an
> IP address. What happens if the client request contains a name and the
> server's response contains an IP? That might be a match (e.g. if the
> client performs an A/AAAA lookup for the name it requested, it gets back
> that IP in the response) or it might not.

As a user I'd like the client to reject an IP that doesn't match the
name I#ve asked for.  Note that the client can obtain this information
prior to the NTS-KE handshake.

> I wonder if a pool server might do this. You ask for
> "us.nts.pool.ntp.org" and it gives you back a particular IP to connect
> to. In that case, you'd want to follow the referral.

But then you shouldn't have asked for a specific server, i.e. the client
didn't send a "Server Negotiation".

> I think it would be useful to understand the use case(s) for the client
> requesting a specific server vs the use case(s) for a user configuring
> the client to request a specific server.

Let's see:

1. I know just the NTS-KE address that is published somewhere.  The
client goes to the NTS-KE and doesn't do server negotiation.  It uses
the server it gets back from the NTS-KE or uses the same address if it
doesn't get one back for further communication.

2. I know the NTS-KE and a bunch of specific servers served by that
NTS-KE.

2.a) I don't care about which server I get back.  => proceed like in 1.
That covers pools of all sorts, I think.

2.b) I want one specific serer, so the client does server negotiation.
If I get that server back, I'm a happy camper.  If I get another server
back (including no server, which means use the NTS-KE address), as a
user I'd like this to fail, but other users may want to run with the
server they've got rather than no server.  So we might need an option in
the client.

> Or, you can punt this all to the user by offering both choices:
>
> nts nts-ke.example.org
> ^^ Accepts whatever is returned.
>
> nts nts-ke.example.org ask ntpd.example.org
> ^^ Sends an explicit request. Accepts whatever is returned.
>
> nts nts-ke.example.org require ntpd.example.org
> ^^ Sends an explicit request. If not mirrored back exactly, stop.

That could work I think.

> Here's another wrinkle. Does the first example, "nts
> nts-ke.example.org", send a request for "nts-ke.example.org"? I think it
> should.

The RFC doesn't have an explicit preference, but it's implied that there
is no server negotiation at all in this case, not from the client nor
the NTS-KE.  So in order to pin the NTS-KE as the server you'd need to
do

nts nts-ke.example.org require nts-ke.example.org

I'd say.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada