Re: [Ntp] Quick review of WGLC for status change for draft-ietf-ntp-update-registries

[Harlan Stenn <[e-mail]>]

On 8/15/2022 4:43 AM, Miroslav Lichvar wrote:
> On Mon, Aug 15, 2022 at 04:09:12AM -0700, Harlan Stenn wrote:
>> ntpd implemented the V1 EF format back around 2000.  When 5906 was
>> published, it used the V2 EF format.
>>
>> The code was not updated to use the V2 format.
> 
> What are the benefits of the V2 format over V1? To me it looks like
> different ordering of bits in the EF type field, which could not
> possibly have any advantage that would be worth the break in
> compatibility.
> 
> Why was this incompatibility not mentioned in RFC 5906?

My guess is that folks found the v1 format to be ugly in the way the 
fields were laid out.  As in, it offended "enough" peoples' OCD-ness.

I have no idea why it was not mentioned in 5906.

>> It is not difficult to support the v1 and v2 EF types.
> 
> If there are no conflicts.

I disagree.

The only use of the v1 format was for autokey.

TTBOMK the only users of the v1 format are ntp-4 implementations.  They 
will ONLY recognize autokey stuff.

Was this collision something that happens on an initial NTS handshake or 
was it farther down the line?

This all sounds kinda fishy to me.

The autokey stuff REQUIRES an authenticated packet, so this certainly 
would not be a problem on the receiving ntpd side.

The same should be true for a server that only speaks NTS.  But for this 
collision to be an issue here, it would mean that the client thinks it 
should be setting up an autokey association with the NTS server.

So am I missing something, or is this just drama based on a hypothetical?

> We already have one, which can resolved in the context of other EFs in
> the packet, but that will not generally be true for all future EFs.

Sorry, I'm still not seeing that there is anything "real" here.

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!