Re: [Ntp] [EXT] Re: NTPv5 KISS code support

[Hal Murray <[e-mail]>]

[e-mail] said:
> For ease of debugging, I want to be able to give at least some reply so the
> client can see that it is at least talking to an NTP server in these
> situations. Also, I feel that on cryptographically secured 

In the Cryptographic failure case, it might be reasonable to send back a 
non-authenticated message saying why the crypto didn't work.  The catch is 
that the receiver would have to not take any action since it might be forged, 
but it could be logged for debugging.

Is that layer of complexity worthwhile?  How do people debug crypto troubles 
today?

What fraction of "crypto" troubles are due to filtering UDP port 123?


If the reply has a cookie, that can be used to filter out simple forged 
attacks.  That doesn't cover the MitM case.  Note that V4 with 
data-minimization repurposes the transmit timestamp field to be a cookie.


-----

I like the idea of some way to say "not allowed".  How many cases are there?

1) NTS: If the server stops responding, the client will run out of cookies and 
try NTS-KE again.  That is a secure channel where we could say "no".

2) Pool:  If the server just stops responding and the client does another DNS 
lookup, it will probably get a different IP Address.

3) Moved to new IP Address: 
3a) If the client used the DNS name, trying again will get the new address.
3b) If the client used the IP Address...  ??

4) Server turning off (or reducing service area)
4a) Remove DNS entry
4b) ???

Can we steer people to use cases that are easy to implement?
Does that boil down to use DNS rather than IP Addresses?



-- 
These are my opinions.  I hate spam.