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

[Harlan Stenn <[e-mail]>]

On 8/28/2019 4:26 AM, Miroslav Lichvar wrote:
> On Wed, Aug 28, 2019 at 04:19:29AM -0700, Harlan Stenn wrote:
>> On 8/28/2019 4:14 AM, Miroslav Lichvar wrote:
>>> Hopefully with something better than the current refid field based on
>>> (hashes of) addresses. Something like your suggested-refid proposal,
>>> except the extension field would contain both the ID of the server
>>> (randomly generated) and the ID of the its reference.
>>
>> Extension fields are optional.
> 
> Most clients don't need to know the refid, so to me it makes sense for
> the refid information to be optional.

Goes to traceability of time in environments where this information is
useful, if not critical.

>> I'm very curious how the ID if the remote server's reference will be
>> useful, and not just another attack vector.
> 
> It's a random number and not an address. So it should be better than
> the NTPv4 refid, right?

How is this useful without knowing who the server is talking to?

>>> This could fit into the space of the NTPv4 refid and reference
>>> timestamp, but it would take 64 of those 96 bits and I'm not sure if
>>> 32 bits is enough for the other new stuff.
>> Exactly what do you see as the use-cases for this information in the
>> base packet?  Exactly how would this information be used?
> 
> It seems you agree it should be optional.

No, I still believe the refid is a core critical component of the base
packet, at least in cases where one cares about understanding leaf
nodes.  Yes, we *could* fracture this out but I haven't seen a
significant benefit to doing this.  Making the refid optional just makes
it much harder to understand what's going on with a client.

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!