Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

[Hal Murray <[e-mail]>]

[e-mail] said:
> IIRC, there are few implementations that do that. openntpd is probably the
> most widely used one. As a server, it just checks if the packet is 48 or 64
> octets long and that the mode is 1 or 3. ...

What's the 64 byte case?

I'm trying to make it fit with old style shared key authentication (no 
extension field) but that's 20 or 24 bytes, 4 bytes for the key-ID and 16 or 
20 for MAC.

-----------


[e-mail] said:
>> I propose we just avoid this situation entirely by making NTS a
>> mandatory part of v5.
> I don't think that is a good idea. I'm sure we can figure out something
> simple that doesn't require TCP or TLS. For instance, moving the origin field
> in the header would prevent such broken servers from sending a valid
> response. 

I'm looking for a way to ask a server what it supports without knowing what it 
supports.  That would be simple if we had thought about it back when designing 
version 0 of the protocol.

NTS-KE uses ALPN so you get version info as part of the TLS handshake.

But I'd like something light weight.  The complication is that we also have to 
determine if the server supports telling us what it supports.  I don't see how 
to do that in a simple clean way.  No response can mean either it doesn't 
support that packet or the server is down.  You can try something 
simpler/older to see if the server is up, but no response doesn't tell you if 
the server is down or the network is lossy.  We can probably work around that, 
but by that time it's no longer clean and simple.

We should be sure to put something like this into the v5 protocol so it will 
be there when v6 comes along.







-- 
These are my opinions.  I hate spam.