Subject: [Ntp] Updates to draft-stenn-ntp-extension-fields

From: Harlan Stenn <[email-masked]>
Date: Mon, 2 Oct 2017 00:00:19 -0700

Folks,

I've updated https://github.com/hstenn/ietf-ntp-extension-field.git to
include my pseudocde examples, clean up some sentences, and copy/clarify
parts of RFC5906 over to RFC5905.

It probably needs more polish before I update it to -03, but it should
be pretty close.

Feedback welcome.

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

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 2 Oct 2017 15:38:17 +0200

> parts of RFC5906 over to RFC5905.

Before we get back to the discussion about reserving the highest bits
of the EF type field for EF-specific purposes and requiring parsers to
have access to keys, I'd like to point out that this proposal is not
consistent with the current use of EF types in the reference
implementation.

If the type field is shortened to 8 bits, ntpd will use types 0-9, and
the leapseconds EF (type 5) will conflict with the checksum complement
EF.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 2 Oct 2017 09:06:37 -0700

> the leapseconds EF (type 5) will conflict with the checksum complement

The leapseconds Code 5 is an Autokey (EF Type 2) subtype.  From RFC 5906:

 0x0502 (Autokey) Lepaseconds Value Message Request
 0x8502 (Autokey) Lepaseconds Value Message Response
 0xC502 (Autokey) Lepaseconds Value Message Error Response

and the Checksum Complement is:

 0x2005  Checksum Complement.

In 5906, the first octet used the leftmost 2 bits for flags, and the
rightmost bits for the code.  The EF type was the 2nd octet.

The new proposal uses the leftmost 4 bits for flags, and the rightmost
bits are still for the code.  It's just that there are now only 4 bits
available for the code.  This shouldn't be a problem as that gives us 16
types per EF Type, and we've never used more than 10 before.  If we have
an EF Type that wants more than 16 Codes, we just need to use 2 (or
more) types for it.  From what has been suggested so far, this won't be
an issue.  NTS should be looking for 4 or 5 codes.  The Extended
Information EF proposal uses 1, and if/when it grows it has 14 more
opportunities.

This reduction from potentially 64 codes to 16 codes doesn't appear to
be an issue.

Does this make sense?  Am I missing something?
-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 3 Oct 2017 10:00:13 +0200

>  0xC502 (Autokey) Lepaseconds Value Message Error Response

This is in the RFC and IANA registry, but it's not what ntpd is
actually using. We discussed this before. Check the
include/ntp_crypto.h file in the distribution.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 3 Oct 2017 02:00:46 -0700

> include/ntp_crypto.h file in the distribution.

I haven't looked at a packet trace in a long time.  The code says:

/*
 * Extension field definitions
 */
#define CRYPTO_MAXLEN   1024    /* max extension field length */
#define CRYPTO_VN       2       /* current protocol version number */
#define CRYPTO_CMD(x)   (((CRYPTO_VN << 8) | (x)) << 16)
#define CRYPTO_NULL     CRYPTO_CMD(0) /* no operation */
#define CRYPTO_ASSOC    CRYPTO_CMD(1) /* association */
#define CRYPTO_CERT     CRYPTO_CMD(2) /* certificate */
#define CRYPTO_COOK     CRYPTO_CMD(3) /* cookie value */
#define CRYPTO_AUTO     CRYPTO_CMD(4) /* autokey values */
#define CRYPTO_LEAP     CRYPTO_CMD(5) /* leapsecond values */
#define CRYPTO_SIGN     CRYPTO_CMD(6) /* certificate sign */
#define CRYPTO_IFF      CRYPTO_CMD(7) /* IFF identity scheme */
#define CRYPTO_GQ       CRYPTO_CMD(8) /* GQ identity scheme */
#define CRYPTO_MV       CRYPTO_CMD(9) /* MV identity scheme */
#define CRYPTO_RESP     0x80000000 /* response */
#define CRYPTO_ERROR    0x40000000 /* error */

In the code above, VN (2) is the Autokey EF type.  So this code produces
an internal format of high-order 8 bits of the EF type, and the low
order 8 bits of the "code" field, shifted left by 16 bits for the length.

I have not looked to see if this is a big-endian/little endian thing
(almost certainly not, but I wanted to mention it for thoroughness), or
if it's an internal representation v. an external representation thing
(far more likely, and probably not the way I would have written it).

And it may be a bug.

If it's a bug in the code, the good news is that with NTS on the horizon
and https://tools.ietf.org/html/draft-stenn-ntp-extended-information-00,
which specifically includes a way to get the TAI offset, there should
soon be no need for Autokey.

But to start using a new idom, we could just as easily talk about:

2.0	Autokey: No-op
2.1	Autokey: Assoc
...
2.5	Autokey: leapsecond
...
2.9	Autokey: MV identity
3.0	MAC-EF
4.0	NTS
4.1	NTS whatever1
4.2	NTS whatever2
...
5.0	Checksum Complement
6.0	Suggested REFID
7.0	I-DO
8.0	LAST-EF
9.1	Extended Information (suggestion)

and aside from this, we're looking at whether or not there's a bug in
the code.  If so, it hasn't been reported, and that code is over 16
years' old.  We're looking at this, thanks!
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 16 Oct 2017 09:31:10 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 02.10.2017 um 18:06 in Nachricht

> This reduction from potentially 64 codes to 16 codes doesn't appear to

What I absolutely dislike on this specification is that the extension field's specification is like
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |R|E|   Code    |  Field Type   |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

but you register (R,E,Code, and Field Type) just as one opaque number (actually more than one due to flags being included). Now you are suggesting to change the field widths. This would give the numbers already registered a new meaning. Also, according to the specification "Field Type" is asically the NTP autokey version. Why have 8 bits for the version, but only 4 bits for the field? Can't you put additional flags elsewhere?

> Does this make sense?  Am I missing something?

I didn't have time to read the whole revised specification.

Regards,
Ulrich

> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 16 Oct 2017 01:05:40 -0700

> What I absolutely dislike on this specification is that the extension field's specification is like

Nothing changes with the already registered numbers.

The only numbers already allocated are for Autokey, and they are not
affected by this change.  OK, there's also the experimental Checksum
Complement EF, but that number was assigned with the proposed changes in
mind, as it uses the "MAC Optional" flag bit.

If you want to look at is as Field Type 1 was Autokey V1, and Field Type
2 is Autokey V2, that's fine with me.  It is not "generic versions".
The values 1-7 were thought of as the Autokey version field 10 years'
ago, but not in a "concrete" way.  Even if you want to make that
argument, that leaves ~248 more Field Types allowed for use by "other
than Autokey".

I don't know where you're getting "4 bits for the field".  I think you
mean "4 bits for the code", and that gives 16 sub-codes for each Field Type.

>From everything I've seen, this works out just fine.

The Field Type list I'm working from says:

0x0002	Autokey V2
0x0003	MAC Extension Field
0x0004	NTS
0x0005	Checksum Complement
...
0x0009	Extended Information

0x1000	MAC included
0x2000	MAC optional
0x4000	Error
0x8000	Response

Additional values for I-DO payload:
0xFFFE	I-DO Leap Smear REFIDs
0xFFFF	I-DO IPv6 REFID hash

H
--