Skip to main content

The update registries draft
draft-rsalz-update-registries-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author Rich Salz
Last updated 2020-12-22
Replaced by draft-ietf-ntp-update-registries
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-rsalz-update-registries-00
ntp                                                              R. Salz
Internet-Draft                                       Akamai Technologies
Intended status: Informational                          22 December 2020
Expires: 25 June 2021

                      The update registries draft
                    draft-rsalz-update-registries-00

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 defines all
   current 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 25 June 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Salz                      Expires 25 June 2021                  [Page 1]
Internet-Draft         The update registries draft         December 2020

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Existing Registries . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Reference ID, Kiss-o'-Death . . . . . . . . . . . . . . .   3
     2.2.  Extension Field Types . . . . . . . . . . . . . . . . . .   3
     2.3.  Network Time Security Registries  . . . . . . . . . . . .   4
   3.  New Registries  . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Consideration  . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  NTP Reference Identifier Codes  . . . . . . . . . . . . .   4
     4.2.  NTP Kiss-o'-Death Codes . . . . . . . . . . . . . . . . .   5
     4.3.  NTP Extension Field Types . . . . . . . . . . . . . . . .   5
     4.4.  Network Time Security Key Establishment Record Types  . .   8
     4.5.  Network Time Security Next Protocols  . . . . . . . . . .   8
     4.6.  Network Time Security Error Codes . . . . . . . . . . . .   8
     4.7.  Network Time Security Warning Codes . . . . . . . . . . .   8
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

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 defines all
   current registries.

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

   *  First, each registry, its defining document, and a summary of its
      syntax is defined.

   *  Second, the revised format and entries for each registry are
      defined.

Salz                      Expires 25 June 2021                  [Page 2]
Internet-Draft         The update registries draft         December 2020

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 four ASCII
   characters, left justified and padded with zero's.  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.

   [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 nibbles (half of a byte),

   *  Some values were mistakenly re-used.

Salz                      Expires 25 June 2021                  [Page 3]
Internet-Draft         The update registries draft         December 2020

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 regisries.

   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 regisries are also partitioned the same way.

3.  New Registries

   The following general guidelines apply to all registries defined
   here:

   *  Every entry reserves a partition for private use and
      experimentation.

   *  Registries with ASCII fields are now limited to uppercase letters;
      fields starting with 0x2D, the ASCII minus sign, are reserved for
      private use.

   *  The policy for every registry is now specification required, as
      defined in Section 4.6 of [RFC8126].

   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 Consideration

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.

Salz                      Expires 25 June 2021                  [Page 4]
Internet-Draft         The update registries draft         December 2020

   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 have "RFC5906" added; if only one reference is
   possible, replace the existing 5905 with 5906.

   The following Note is added:

   *  Field Types in the range 0xD000 throught 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:

Salz                      Expires 25 June 2021                  [Page 5]
Internet-Draft         The update registries draft         December 2020

   *  Field Type (required): A four-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.  Note that the
   intent is that the second and fourth digits in the Field Type column
   are switched.

   +============+==============================+=======================+
   | Field Type | Meaning                      | Reference             |
   +============+==============================+=======================+
   | 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         | RFC 5906              |
   |            | Request                      |                       |
   +------------+------------------------------+-----------------------+
   | 0x0208     | GQ Identity Message Request  | RFC 5906              |
   +------------+------------------------------+-----------------------+
   | 0x0209     | MV Identity Message Request  | RFC 5906              |
   +------------+------------------------------+-----------------------+
   | 0x8200     | No-Operation Response        | RFC 5906              |
   +------------+------------------------------+-----------------------+
   | 0x0304     | NTS Cookie Placeholder       | RFC 8915, Section 5.5 |
   +------------+------------------------------+-----------------------+
   | 0x0404     | NTS Authenticator and        | RFC 8915, Section 5.6 |
   |            | Encrypted Extension Fields   |                       |
   +------------+------------------------------+-----------------------+
   | 0x8201     | Association Message          | RFC 5906              |
   |            | Response                     |                       |
   +------------+------------------------------+-----------------------+

Salz                      Expires 25 June 2021                  [Page 6]
Internet-Draft         The update registries draft         December 2020

   | 0x8202     | Certificate Message          | RFC 5906              |
   |            | Response                     |                       |
   +------------+------------------------------+-----------------------+
   | 0x8203     | Cookie Message Response      | RFC 5906              |
   +------------+------------------------------+-----------------------+
   | 0x8204     | Autokey Message Response     | RFC 5906              |
   +------------+------------------------------+-----------------------+
   | 0x8205     | Leapseconds Message          | RFC 5906              |
   |            | Response                     |                       |
   +------------+------------------------------+-----------------------+
   | 0x8206     | Sign Message Response        | RFC 5906              |
   +------------+------------------------------+-----------------------+
   | 0x8207     | IFF Identity Message         | RFC 5906              |
   |            | Response                     |                       |
   +------------+------------------------------+-----------------------+
   | 0x8208     | GQ Identity Message          | RFC 5906              |
   |            | Response                     |                       |
   +------------+------------------------------+-----------------------+
   | 0x8209     | MV Identity Message          | RFC 5906              |
   |            | Response                     |                       |
   +------------+------------------------------+-----------------------+
   | 0xC200     | No-Operation Error Response  | RFC 5906              |
   +------------+------------------------------+-----------------------+
   | 0xC201     | Association Message Error    | RFC 5906              |
   |            | Response                     |                       |
   +------------+------------------------------+-----------------------+
   | 0xC202     | Certificate Message Error    | RFC 5906              |
   |            | Response                     |                       |
   +------------+------------------------------+-----------------------+
   | 0xC203     | Cookie Message Error         | RFC 5906              |
   |            | Response                     |                       |
   +------------+------------------------------+-----------------------+
   | 0xC204     | Autokey Message Error        | RFC 5906              |
   |            | Response                     |                       |
   +------------+------------------------------+-----------------------+
   | 0xC205     | Leapseconds Message Error    | RFC 5906              |
   |            | Response                     |                       |
   +------------+------------------------------+-----------------------+
   | 0xC206     | Sign Message Error Response  | RFC 5906              |
   +------------+------------------------------+-----------------------+
   | 0xC207     | IFF Identity Message Error   | RFC 5906              |
   |            | Response                     |                       |
   +------------+------------------------------+-----------------------+
   | 0xC208     | GQ Identity Message Error    | RFC 5906              |
   |            | Response                     |                       |
   +------------+------------------------------+-----------------------+
   | 0xC209     | MV Identity Message Error    | RFC 5906              |
   |            | Response                     |                       |

Salz                      Expires 25 June 2021                  [Page 7]
Internet-Draft         The update registries draft         December 2020

   +------------+------------------------------+-----------------------+

                                  Table 1

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.  Should we remove the
   Unassigned and Reserved rows?  Should we convert the numbers to hex?

4.5.  Network Time Security Next Protocols

   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.  Should we remove the
   Unassigned and Reserved rows?  Should we convert the numbers to hex?

4.6.  Network Time Security Error Codes

   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.  Should we remove the
   Unassigned and Reserved rows?

4.7.  Network Time Security Warning Codes

   The registration procedure is changed to specification required.

   The following note should be added:

Salz                      Expires 25 June 2021                  [Page 8]
Internet-Draft         The update registries draft         December 2020

   *  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.  Should we remove the
   Unassigned and Reserved rows?  Can IANA handle an empty table?

5.  Acknowledgements

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

   *  Miroslav Lichvar, RedHat

   *  Daniel Franke, Akamai Technologies

   *  Danny Mayer, Network Time Foundation

   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, June 2010,
              <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, June 2010,
              <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, March
              2016, <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,
              March 2016, <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, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

Salz                      Expires 25 June 2021                  [Page 9]
Internet-Draft         The update registries draft         December 2020

   [RFC8573]  Malhotra, A. and S. Goldberg, "Message Authentication Code
              for the Network Time Protocol", RFC 8573,
              DOI 10.17487/RFC8573, June 2019,
              <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, September 2020,
              <https://www.rfc-editor.org/info/rfc8915>.

Author's Address

   Rich Salz
   Akamai Technologies

   Email: rsalz@akamai.com

Salz                      Expires 25 June 2021                 [Page 10]