Internet-Draft The update registries draft February 2021
Salz Expires 7 August 2021 [Page]
Workgroup:
ntp
Internet-Draft:
draft-rsalz-update-registries-02
Published:
Intended Status:
Informational
Expires:
Author:
R. Salz
Akamai Technologies

The update registries draft

Abstract

The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of assigned number registries, collectively called the NTP registries. Some registries have wrong values, some registries do not follow current common practice, and some are just right. For the sake of completeness, this document reviews all NTP and NTS registries.

Discussion Venues

This note is to be removed before publishing as an RFC.

Source for this draft and an issue tracker can be found at https://github.com/richsalz/draft-rsalz-update-registries.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 7 August 2021.

Table of Contents

1. Introduction

The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of assigned number registries, collectively called the NTP registries. Some registries have wrong values, some registries do not follow current common practice, and some are just right. For the sake of completeness, this document reviews all NTP and NTS registries.

The bulk of this document can be divided into two parts:

2. Existing Registries

This section describes the registries and the rules for them. It is intended to be a short summary of the syntax and registration requirements for each registry. The semantics and protocol processing rules for each registry -- that is, how an implementation acts when sending or receiving any of the fields -- is not described here.

2.1. Reference ID, Kiss-o'-Death

[RFC5905] defined two registries, the Reference ID in Section 7.3, and the Kiss-o'-Death in Section 7.4. Both of these are allowed to be four ASCII characters; padded on the right with all-bits-zero if necessary. Entries that start with 0x58, the ASCII letter uppercase X, are reserved for private experimentation and development. Both registries are first-come first-served. The formal request to define the registries is in Section 16.

Section 7.5 of [RFC5905] defined the on-the-wire format of extension fields but did not create a registry for it.

2.2. Extension Field Types

[RFC5906] mentioned the Extension Field Types registry, and defined it indirectly by defining 30 extensions (15 each for request and response) in Section 13. It did not provide a formal definition of the columns in the registry. Section 10 of [RFC5906] splits the Field Type into four subfields, only for use within the Autokey extensions.

[RFC7821] added a new entry, Checksum Complement, to the Extension Field Types registry.

[RFC7822] clarified the processing rules for Extension Field Types, particularly around the interaction with the Message Authentication Code (MAC) field.

[RFC8573] changed the cryptography used in the MAC field.

The following problems exists with the current registry:

  • Many of the entries in the Extension Field Types registry have swapped some of the nibbles; 0x1234 is listed as 0x1432 for example. This document marks the erroneous values as reserved.
  • Some values were mistakenly re-used.

2.3. Network Time Security Registries

[RFC8915] defines the Network Time Security (NTS) protocol. Sections 7.1 through 7.5 (inclusive) added entries to existing registries.

Section 7.6 created a new registry, NTS Key Establishment Record Types, that partitions the assigned numbers into three different registration policies: IETF Review, Specification Required, and Private or Experimental Use.

Section 7.7 created a new registry, NTS Next Protocols, that similarly partitions the assigned numbers.

Section 7.8 created two new registries, NTS Error Codes and NTS Warning Codes. Both registries are also partitioned the same way.

3. New Registries

The following general guidelines apply to all registries defined here:

The IESG is requested to choose three designated experts, with two being required to approve a registry change.

Each entry described in the below sub-sections is intended to completely replace the existing entry with the same name.

4. IANA Considerations

4.1. NTP Reference Identifier Codes

The registration procedure is changed to specification required.

The Note is changed to read as follows:

  • Codes beginning with the character "-" are reserved for experimentation and development. IANA cannot assign them.

The columns are defined as follows:

  • ID (required): a four-byte value padded on the right with zero's. Each value must be an ASCII uppercase letter or minus sign
  • Clock source (required): A brief text description of the ID
  • Reference (required): the publication defining the ID.

The existing entries are left unchanged.

4.2. NTP Kiss-o'-Death Codes

The registration procedure is changed to specification required.

The Note is changed to read as follows:

  • Codes beginning with the character "-" are reserved for experimentation and development. IANA cannot assign them.

The columns are defined as follows:

  • ID (required): a four-byte value padded on the right with zero's. Each value must be an ASCII uppercase letter or minus sign.
  • Meaning source (required): A brief text description of the ID.
  • Reference (required): the publication defining the ID.

The existing entries are left unchanged.

4.3. NTP Extension Field Types

The registration procedure is changed to specification required.

The reference should be [RFC5906] added, if possible.

The following Note is added:

  • Field Types in the range 0xF000 through 0xFFFF, inclusive, are reserved for experimentation and development. IANA cannot assign them. Both NTS Cookie and Autokey Message Request have the same Field Type; in practice this is not a problem as the field semantics will be determined by other parts of the message.

The columns are defined as follows:

  • Field Type (required): A two-byte value in hexadecimal.
  • Meaning (required): A brief text description of the field type.
  • Reference (required): the publication defining the field type.

The table is replaced with the following entries.

Table 1
Field Type Meaning Reference
0x0002 Reserved for historic reasons This RFC
0x0102 Reserved for historic reasons This RFC
0x0104 Unique Identifier RFC 8915, Section 5.3
0x0200 No-Operation Request RFC 5906
0x0201 Association Message Request RFC 5906
0x0202 Certificate Message Request RFC 5906
0x0203 Cookie Message Request RFC 5906
0x0204 NTS Cookie RFC 8915, Section 5.4
0x0204 Autokey Message Request RFC 5906
0x0205 Leapseconds Message Request RFC 5906
0x0206 Sign Message Request RFC 5906
0x0207 IFF Identity Message Request RFC 5906
0x0208 GQ Identity Message Request RFC 5906
0x0209 MV Identity Message Request RFC 5906
0x0302 Reserved for historic reasons This RFC
0x0304 NTS Cookie Placeholder RFC 8915, Section 5.5
0x0402 Reserved for historic reasons This RFC
0x0404 NTS Authenticator and Encrypted Extension Fields RFC 8915, Section 5.6
0x0502 Reserved for historic reasons This RFC
0x0602 Reserved for historic reasons This RFC
0x0702 Reserved for historic reasons This RFC
0x2005 Reserved for historic reasons This RFC
0x8002 Reserved for historic reasons This RFC
0x8102 Reserved for historic reasons This RFC
0x8200 No-Operation Response RFC 5906
0x8201 Association Message Response RFC 5906
0x8202 Certificate Message Response RFC 5906
0x8203 Cookie Message Response RFC 5906
0x8204 Autokey Message Response RFC 5906
0x8205 Leapseconds Message Response RFC 5906
0x8206 Sign Message Response RFC 5906
0x8207 IFF Identity Message Response RFC 5906
0x8208 GQ Identity Message Response RFC 5906
0x8209 MV Identity Message Response RFC 5906
0x8302 Reserved for historic reasons This RFC
0x8402 Reserved for historic reasons This RFC
0x8502 Reserved for historic reasons This RFC
0x8602 Reserved for historic reasons This RFC
0x8702 Reserved for historic reasons This RFC
0x8802 Reserved for historic reasons This RFC
0xC002 Reserved for historic reasons This RFC
0xC102 Reserved for historic reasons This RFC
0xC200 No-Operation Error Response RFC 5906
0xC201 Association Message Error Response RFC 5906
0xC202 Certificate Message Error Response RFC 5906
0xC203 Cookie Message Error Response RFC 5906
0xC204 Autokey Message Error Response RFC 5906
0xC205 Leapseconds Message Error Response RFC 5906
0xC206 Sign Message Error Response RFC 5906
0xC207 IFF Identity Message Error Response RFC 5906
0xC208 GQ Identity Message Error Response RFC 5906
0xC209 MV Identity Message Error Response RFC 5906
0xC302 Reserved for historic reasons This RFC
0xC402 Reserved for historic reasons This RFC
0xC502 Reserved for historic reasons This RFC
0xC602 Reserved for historic reasons This RFC
0xC702 Reserved for historic reasons This RFC
0xC802 Reserved for historic reasons This RFC
0x0902 Reserved for historic reasons This RFC
0x8902 Reserved for historic reasons This RFC
0xC902 Reserved for historic reasons This RFC

4.4. Network Time Security Key Establishment Record Types

The registration procedure is changed to specification required.

The following note should be added:

  • Record Type numbers in the range 0x4000 through 0x7FFF, inclusive, are reserved for experimentation and development. IANA cannot assign them.

The existing entries are left unchanged.

4.5. Network Time Security Next Protocols

The registration procedure is changed to specification required.

The following note should be added:

  • Protocol ID numbers in the range 0x8000 through 0xFFFF, inclusive, are reserved for experimentation and development. IANA cannot assign them.

The existing entries are left unchanged.

4.6. Network Time Security Error Codes

The registration procedure is changed to specification required.

The following note should be added:

  • Error code numbers in the range 0x8000 through 0xFFFF, inclusive, are reserved for experimentation and development. IANA cannot assign them.

The existing entries are left unchanged.

4.7. Network Time Security Warning Codes

The registration procedure is changed to specification required.

The following note should be added:

  • Warning code numbers in the range 0x8000 through 0xFFFF, inclusive, are reserved for experimentation and development. IANA cannot assign them.

The existing entries are left unchanged.

5. Acknowledgements

The members of the NTP Working Group helped a great deal. Notable contributors include.

And thanks to Harlen Stenn for providing popcorn.

6. Normative References

[RFC5905]
Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, , <https://www.rfc-editor.org/info/rfc5905>.
[RFC5906]
Haberman, B., Ed. and D. Mills, "Network Time Protocol Version 4: Autokey Specification", RFC 5906, DOI 10.17487/RFC5906, , <https://www.rfc-editor.org/info/rfc5906>.
[RFC7821]
Mizrahi, T., "UDP Checksum Complement in the Network Time Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, , <https://www.rfc-editor.org/info/rfc7821>.
[RFC7822]
Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, , <https://www.rfc-editor.org/info/rfc7822>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC8573]
Malhotra, A. and S. Goldberg, "Message Authentication Code for the Network Time Protocol", RFC 8573, DOI 10.17487/RFC8573, , <https://www.rfc-editor.org/info/rfc8573>.
[RFC8915]
Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time Security for the Network Time Protocol", RFC 8915, DOI 10.17487/RFC8915, , <https://www.rfc-editor.org/info/rfc8915>.

Author's Address

Rich Salz
Akamai Technologies