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

[Harlan Stenn <[e-mail]>]

On 8/28/2019 4:14 AM, Miroslav Lichvar wrote:
> On Wed, Aug 28, 2019 at 03:42:15AM -0700, Harlan Stenn wrote:
>> On 8/28/2019 3:37 AM, Miroslav Lichvar wrote:
>>> My suggestion would be to keep the NTP header 48 octets long and
>>> change only two fields: the refid and reference timestamp. They are
>>
>> If you change the refid field how will you effect degree 1 loop detection?
> 
> 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.

What benefit is there to requiring them if there's already an adequate
field for the information in the base packet?

I'm very curious how the ID if the remote server's reference will be
useful, and not just another attack vector.

> 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?

>>> ignored by current servers and most clients. That gives us 12 octets
>>> of contiguous space in the header to work with. That's plenty for the
>>> timescale negotiation and other metadata. Longer fields should be in
>>> extension fields. No MACs allowed.
>>
>> I assume you meant "No >legacy< MACs allowed."
> 
> Right.
> 

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