Re: [Ntp] Registries document

[Harlan Stenn <[e-mail]>]

On 7/31/2023 4:32 AM, Miroslav Lichvar wrote:
> On Thu, Jul 27, 2023 at 04:53:26AM -0700, Harlan Stenn wrote:
>> 2.2 Extension Field Types.  The claim that "RFC5906 Section 10 splits the
>> Field Type into four subfields, only for use within the Autokey extension"
>> remains flat out wrong.  The specified subfields have been used by other,
>> now formalized EF documents,
> 
> No, Autokey is still the only RFC using the response and error
> bits.

No other proposals have used the error bit, my notes say that Autokey 
does not actually use that bit, and my earlier documents contained notes 
saying that we could reclaim that bit.

But the Response bit is used by the I-DO EF, and at one time there were 
expectations that two of the NTS subcommands would be "responses". I'm 
not seeing this information right now, but I clearly remember seeing it, 
recently.  No big deal.

The point remains that, as clearly described in 
draft-stenn-ntp-extension-field, there are 8 bits for flags and the code 
(subtype).  The biggest user of code bits to-date is Autokey, which has 
10 codes (4 bits).  There is demonstrably *plenty* of space for more 
subcodes with this layout.  And if, for whatever reason, one needs more, 
those additional subcodes can be had by using another Type value.

Again, as described in draft-stenn-ntp-extension-field, we have 
identified a total of 10 EFs so far, and reserving 0x..0E thru 0x..FE 
for experimental and Private use (which I continue to believe is a 
wasteful and ill-conceived idea), and 0x..0F thru 0x..FF for I-DO meta 
values (which would not need to happen if we didn't do the 
experimental/private thing), we still have over *200* available EFs.

There's no lack of EF Type or Code/subtype/whatever/flag resources.

>> They have been a day-one foundational design
>> component of extension fields.
> 
> Maybe it was, but it wasn't documented anywhere. The checksum
> complement type (RFC 7821) didn't follow it.

Really?  I beg to differ.

It was documented in the code.

It was somewhat documented in 5906.

It was properly documented by draft-stenn-ntp-extension-field, which 
folks can, if they choose, pretend never even existed.

The EF for the Checksum Complement is 0x2005.  5 is the type (one more 
than 4, the type used for NTS), and the 0x2 was done back when I wanted 
to use 4 flag bits: 0x8 Response, 0x4 Error, 0x2 MAC-Optional, and 0x1 
MAC-Supplied.

> Ultimately, it doesn't matter. NTP implementations that need to
> work with multiple EF types can use lists of 16-bit values or another
> data structure better optimized for quick lookups. The impact on
> performance of potential optimizations allowed by splitting the EF
> range to 256 8-bit partitions seems negligible to me and certainly not
> worth the troubles with specification.

You are, of course, entitled to your opinion.

As long as your implementation gets the expected results, why should 
anybody care if you check 8 bits or check 16?

But please don't make it harder for people to:

- have well-performing code
- write better RFCs that use these
- make sure IANA assigns reasonable values, when not given
   recommendations by proposal authors

>> We have repeatedly cited code and practice to this effect.  What
>> was implemented and deployed was the V1 EF format.  RFC 5906 documents the
>> V2 EF format.
> 
> It's not clear to me what exactly you mean by "V1 EF" and "V2 EF"
> format. It cannot be the Autokey version as ntpd implements Autokey
> v2. If there was a version associated specifically with this
> incompatibility wasn't documented anywhere and why does RFC 5906 say
> "This informational document describes the NTP extensions for Autokey
> as implemented in an NTPv4 software distribution available from
> http://www.ntp.org" ?

Because that statement was written before the change was made to the EF 
structure layout in the RFC.

As many (you included) have noticed, the reference implementation uses 
the V1 EF structure layout, even though that spec was changed in the 
RFC, which, again, was published 13 years' after the code was released.

> Autokey v1 in ntpd used the same EF type field format as v2. See this
> commit from 2001 where the version number changed:

I am *very* curious about this, as I remember that years' ago you and I 
discussed this, and I discussed it with Dave Mills.  The on-wire format 
of EFs (at which time Autokey was the only user) had a different format.

But it may not matter - if Autokey *now* follows the V2 EF format then 
there are *still* no collisions with NTS values.  Autokey uses a Type 
field of 0x..02, and NTS uses a Type field of 0x..04.

> https://github.com/JamesB192/ntp/commit/8a777f805c04d3c216feaea6d8ed5ae52bf37f01#diff-ddbe66340cfdc18553f324499136e01bc9eb9f7eb3170a4524451529dcd856f2L32
> 
> (for anyone wondering, the extra shift of 16 bits for v2 is an
> unrelated optimization)
> 
> ntpd autokey v1 uses types 0x0100-0x0109, 0x4100-0x4109, 0x8100-0x8109.
> 
> ntpd autokey v2 uses types 0x0200-0x0209, 0x4200-0x4209, 0x8200-0x8209.
> 
> RFC 5906 uses types 0x0002, 0x0102, 0x0202, 0x0302, 0x0402, 0x0502,
>      0x0602, 0x0702, 0x0802, 0x0902, 0x4002, 0x4102, 0x4202, 0x4302,
>      0x4402, 0x4502, 0x4602, 0x4702, 0x4802, 0x4902, 0x8002, 0x8102,
>      0x8202, 0x8302, 0x8402, 0x8502, 0x8602, 0x8702, 0x8802, 0x8902.
> 
> There is no conflict between ntpd v1 and v2, but both conflict with
> RFC 5906 in 3 types.

I'm not sure about this.

The change you describe looks to me like Autokey shifted from the V1 EF 
format to the V2 format.  If this is the case, it would mean that at the 
point of the commit you cite, the reference implementation follows the 
EF layout described in RFC5906, but I bet it's more involved than that, 
because...

I see the V1 format in, for example, ntp-4.1.1 (from February of 2002, 8 
years before RFC5906 was published):

include/ntp_crypto.h:
...
/*
  * Extension field definitions
  */
#define CRYPTO_VN       1       /* current protocol version number */

#define CRYPTO_NULL     ((CRYPTO_VN << 8) | 0) /* no operation */
#define CRYPTO_STAT     ((CRYPTO_VN << 8) | 1) /* status */
#define CRYPTO_ASSOC    ((CRYPTO_VN << 8) | 2) /* association ID */
#define CRYPTO_AUTO     ((CRYPTO_VN << 8) | 3) /* autokey values */
#define CRYPTO_PRIV     ((CRYPTO_VN << 8) | 4) /* cookie value */
#define CRYPTO_DHPAR    ((CRYPTO_VN << 8) | 5) /* agreement params */
#define CRYPTO_DH       ((CRYPTO_VN << 8) | 6) /* public value */
#define CRYPTO_NAME     ((CRYPTO_VN << 8) | 7) /* host name/pub key */
#define CRYPTO_CERT     ((CRYPTO_VN << 8) | 8) /* PKI certificate */
#define CRYPTO_TAI      ((CRYPTO_VN << 8) | 9) /* leapseconds table */
#define CRYPTO_RESP     0x8000                  /* response */
#define CRYPTO_ERROR    0x4000                  /* error */

At some point after this code, the EF Field Type for Autokey changed 
from 1 to 2.  This would explain why an EF table I recently saw says 
that Type 0 is permanently unassigned, Type 1 is Unassigned, and Type 2 
is for Autokey.

After 4.1.1, a good number of functional additions were made to Autokey.

ntp-4.2.6 uses Autokey Type 2 EF codes, and that came out in December of 
2009.

OK, I see the change in Autogen from Type 1 to Type 2 in August of 2001, 
so that happened between 4.1.1 and 4.1.2 (released in July of 2003).

>> The NTP Project's Reference Implementation, the basis of ALL of the IETF NTP
>> Standards to-date, has clearly demonstrated (with working code) that it is
>> very easy to decide if the V1 or V2 EF format should be used, and NO
>> interoperability problems have been observed.
> 
> I don't think you have demonstrated that yet. Where exactly we can see
> the code that supports both ntpd v2 and RFC 5906 autokey at the same
> time?

If, as you pointed out, the reference implementation switched to the V2 
EF format in July of 2003, it's been demonstrated for the past 20 years' 
time.

Or am I missing something?

> Also why would anyone want to implement RFC 5906 now?

For starters, Autokey gives folks access to TAI offsets.  And the 
"weakness" of autokey derives from crackable internal bits.  An Autokey 
EF MUST be protected by authentication (per the requirements of 5906, 
before this was changed by 7822).  Is there any reason that Autokey 
fields that were authenticated by, say, NTS would not be trustable?

But beyond that, if autokey has been using Type 2 codes in a V2 EF for 
the past 20 years' time and the Type 2 autokey codes are clearly not in 
conflict with an NTS Type 4 code in a V2 EF, then ... there is no conflict.

Or is somebody saying that there *might* be a conflict with 20+ year old 
code suddenly appearing that does not speak NTS and that *might* cause a 
conflict with a system that only speaks NTS?  Because I have answers for 
that, too.

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