Re: [Ntp] Experimental/Private EF area: was Re: Registries document

[Harlan Stenn <[e-mail]>]

On 8/1/2023 2:47 AM, Miroslav Lichvar wrote:
> On Tue, Aug 01, 2023 at 01:45:36AM -0700, Harlan Stenn wrote:
>> The Autokey change from Type 1 to Type 2 came out in July of 2003.
>>
>> draft-ietf-ntp-autokey-00 came out in September of 2007, partway thru the
>> period where ntp-4.2.4 was in use.
>>
>> I heard plenty from folks who said "don't break backward compatibility".  I
>> heard *nothing* about "hey, maybe we should figure out how to make the EF
>> code match 5906".
> 
> Ok, so why do you want to make the change now?

Because we have to upgrade the EF handling code anyway, to support both 
versions.

And Autokey is already there, in the codebase, and behaving as-expected.

The "shim" layer that puts the Autokey packet information into a packet 
is the only layer that needs a change, and it's no big deal to make it 
happen.

Furthermore, we'll be releasing this code with all the proposed new EFs 
in there as well, and we can use things like I-DO to communicate whether 
or not Autokey is supported.

Basically, the result will be something that is much more robust and 
functional, will serve as an even better reference implementation, and 
can be done for very little cost.

>> But, as I said, I'm going to be working on a document where the V1 EF is
>> documented for historical purposes.
> 
> Isn't it easier to update RFC5906, when nothing has implemented it?

1) We're gonna make Autokey work with the V2 EF fields described in 5906 
anyway.  If somebody makes a simple change to RFC5906 (won't be me/us) 
and we do this, that will create another mess to clean up down the road.

2) I'm planning to produce a document that also describes the V1 EF 
fields and Autokey.

I was not yet planning to document the V1 and V2 Autokey stuff, but 
we'll likely do that, just for the sake of completeness.  "In for a 
penny, in for a pound."

>> The values I chose are very efficient to process in an enterprise-class or
>> "carrier grade" implementation.
> 
> I don't think there is a measurable impact for an NTP server searching
> EF types in a set of 8-bit values instead of 16-bit values, certainly
> not in an NTP implementation like ntpd, which is mainly limited by the
> OS.

I don't understand what you are claiming here.  Please say more.

> Can you demonstrate it?

I believe so, and if somebody wants to see it and is prepared to fund 
that effort we can do it.

> And are you sure this impact is bigger
> than the impact of resolving collisions between the ntpd autokey types
> and RFC5906?

I am absolutely sure of it.

I'm sure there are folks out there who won't think any of the following 
matters:

- I have been writing code, professionally, for 50 years.
- I got an MSE in Computer Science (a bit different from a plain MS)
   over 40 years' ago.
- Dave Mills looked at the quality of my work and the scope of what I
   was doing that he made me the NTP Project Manager and, effectively,
   his shield or gatekeeper nearly 30 years' ago, and he never fired me.

So I, at least, and a good number of folks I have worked with over the 
past 50 years, think I have at least a basic competence to make these 
sort of assessments.

I'm pretty sure I've shown that there are no collisions, and that the 
claim that there *could* be collisions are, politely, absurd.

Nobody has yet to offer any evidence to the contrary, but many keep 
(baselessly) claiming it to be the case.

So perhaps more to the point, why are you apparently interested in 
seeing time and effort invested in fixing a hypothetical or imaginary 
problem with 5906?

>>> Why would you do that? Such a waste of your project's resources.
>>
>> I'm not saying we'd do it for free.
> 
> I see. If somebody else is paying for a pointless increase in
> the complexity of the code, that makes it ok.

Srsly?

How did you come up with "pointless" based on the information I provided?

>> There are apparently large organizations who, in spite of being told for a
>> very long time that Autokey should not be used, still use Autokey because it
>> gets them a TAI offset, and "it works just fine for them".
> 
> If they need the TAI offset, allow the Autokey LEAP extension field to
> be used without the rest of Autokey and protect it by a symmetric key
> or NTS. That would be a useful improvement.

Sure.  But that only works if the client deployment will tolerate that 
simplification.  It might.  We don't know yet.

I don't want to make an assumption like that.

>>> Let's update the registries to include the ntpd Autokey EF types and
>>> move on.
>>
>> Please keep the V1 EF table separate from the V2 EF table.
> 
> The trouble is that there is only one table. How would an
> implementation know which table is a received packet using?

I cannot even fathom how you got to the place where you are asking this.

If somebody has a V1 implementation somewhere and they want to 
understand packet content, they look up the values in the V1 EF table.

If somebody is using a V2 implementation, they use the V2 EF table.

Why would anybody who cares about V1 want to wade thru a table with V1 
and V2 entries in it?

Why would anybody who cares about V2 want to wade thru a table with V1 
and v2 entries in it?

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