idnits 2.17.00 (12 Aug 2021) /tmp/idnits30535/draft-ietf-ntp-update-registries-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. -- The draft header indicates that this document updates RFC7821, but the abstract doesn't seem to directly say this. It does mention RFC7821 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5905, updated by this document, for RFC5378 checks: 2005-07-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (15 October 2021) is 211 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ntp R. Salz 3 Internet-Draft Akamai Technologies 4 Updates: 5905, 5906, 8573, 7822, 7821 (if 15 October 2021 5 approved) 6 Intended status: Informational 7 Expires: 18 April 2022 9 Updating the NTP Registries 10 draft-ietf-ntp-update-registries-03 12 Abstract 14 The Network Time Protocol (NTP) and Network Time Security (NTS) 15 documents define a number of assigned number registries, collectively 16 called the NTP registries. Some registries have wrong values, some 17 registries do not follow current common practice, and some are just 18 right. For the sake of completeness, this document reviews all NTP 19 and NTS registries. 21 This document updates RFC 5905, RFC 5906, RFC 8573, RFC 7822, and RFC 22 7821. 24 Notes 26 This note is to be removed before publishing as an RFC. 28 This document is a product of the NTP Working Group 29 (https://dt.ietf.org/wg/ntp). Source for this draft and an issue 30 tracker can be found at https://github.com/richsalz/draft-rsalz- 31 update-registries. 33 RFC Editor: Please update 'this RFC' to refer to this document, once 34 its RFC number is known, through the document. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 18 April 2022. 53 Copyright Notice 55 Copyright (c) 2021 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Simplified BSD License text 64 as described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 2. Existing Registries . . . . . . . . . . . . . . . . . . . . . 3 71 2.1. Reference ID, Kiss-o'-Death . . . . . . . . . . . . . . . 3 72 2.2. Extension Field Types . . . . . . . . . . . . . . . . . . 3 73 2.3. Network Time Security Registries . . . . . . . . . . . . 4 74 3. Updated Registries . . . . . . . . . . . . . . . . . . . . . 4 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 76 4.1. NTP Reference Identifier Codes . . . . . . . . . . . . . 5 77 4.2. NTP Kiss-o'-Death Codes . . . . . . . . . . . . . . . . . 5 78 4.3. NTP Extension Field Types . . . . . . . . . . . . . . . . 5 79 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Normative References . . . . . . . . . . . . . . . . . . . . 9 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 The Network Time Protocol (NTP) and Network Time Security (NTS) 86 documents define a number of assigned number registries, collectively 87 called the NTP registries. Some registries have wrong values, some 88 registries do not follow current common practice, and some are just 89 right. For the sake of completeness, this document reviews all NTP 90 and NTS registries. 92 The bulk of this document can be divided into two parts: 94 * First, each registry, its defining document, and a summary of its 95 syntax is defined. 97 * Second, the revised format and entries for each registry that is 98 being modified is specified. 100 2. Existing Registries 102 This section describes the registries and the rules for them. It is 103 intended to be a short summary of the syntax and registration 104 requirements for each registry. The semantics and protocol 105 processing rules for each registry -- that is, how an implementation 106 acts when sending or receiving any of the fields -- is not described 107 here. 109 2.1. Reference ID, Kiss-o'-Death 111 [RFC5905] defined two registries; the Reference ID in Section 7.3, 112 and the Kiss-o'-Death in Section 7.4. Both of these are allowed to 113 be four ASCII characters; padded on the right with all-bits-zero if 114 necessary. Entries that start with 0x58, the ASCII letter uppercase 115 X, are reserved for Private or Experimental Use. Both registries are 116 first-come first-served. The formal request to define the registries 117 is in Section 16. 119 [RFC5905], Section 7.5 defined the on-the-wire format of extension 120 fields but did not create a registry for it. 122 2.2. Extension Field Types 124 [RFC5906] mentioned the Extension Field Types registry, and defined 125 it indirectly by defining 30 extensions (15 each for request and 126 response) in Section 13. It did not provide a formal definition of 127 the columns in the registry. [RFC5906], Section 10 splits the Field 128 Type into four subfields, only for use within the Autokey extensions. 130 [RFC7821] added a new entry, Checksum Complement, to the Extension 131 Field Types registry. 133 [RFC7822] clarified the processing rules for Extension Field Types, 134 particularly around the interaction with the Message Authentication 135 Code (MAC) field. 137 [RFC8573] changed the cryptography used in the MAC field. 139 The following problems exists with the current registry: 141 * Many of the entries in the Extension Field Types registry have 142 swapped some of the nibbles; 0x1234 is listed as 0x1432 for 143 example. This document marks the erroneous values as reserved. 145 * Some values were mistakenly re-used. 147 2.3. Network Time Security Registries 149 [RFC8915] defines the NTS protocol. Its registries are listed here 150 for completeness, but no changes to them are specified in this 151 document. 153 Sections 7.1 through 7.5 (inclusive) added entries to existing 154 registries. 156 Section 7.6 created a new registry, NTS Key Establishment Record 157 Types, that partitions the assigned numbers into three different 158 registration policies: IETF Review, Specification Required, and 159 Private or Experimental Use. 161 Section 7.7 created a new registry, NTS Next Protocols, that 162 similarly partitions the assigned numbers. 164 Section 7.8 created two new registries, NTS Error Codes and NTS 165 Warning Codes. Both registries are also partitioned the same way. 167 3. Updated Registries 169 The following general guidelines apply to all registries updated 170 here: 172 * Every entry reserves a partition for Private or Experimentatal 173 Use. 175 * Registries with ASCII fields are now limited to uppercase letters; 176 fields starting with 0x2D, the ASCII minus sign, are reserved for 177 Private or Experimental Use.. 179 * The policy for every registry is now Specification Required, as 180 defined in [RFC8126], Section 4.6. 182 The IESG is requested to choose three designated experts, with two 183 being required to approve a registry change. 185 Each entry described in the below sub-sections is intended to 186 completely replace the existing entry with the same name. 188 4. IANA Considerations 190 4.1. NTP Reference Identifier Codes 192 The registration procedure is changed to Specification Required. 194 The Note is changed to read as follows: 196 * Codes beginning with the character "-" are reserved for 197 experimentation and development. IANA cannot assign them. 199 The columns are defined as follows: 201 * ID (required): a four-byte value padded on the right with zero's. 202 Each value must be an ASCII uppercase letter or minus sign 204 * Clock source (required): A brief text description of the ID 206 * Reference (required): the publication defining the ID. 208 The existing entries are left unchanged. 210 4.2. NTP Kiss-o'-Death Codes 212 The registration procedure is changed to Specification Required. 214 The Note is changed to read as follows: 216 * Codes beginning with the character "-" are reserved for 217 experimentation and development. IANA cannot assign them. 219 The columns are defined as follows: 221 * ID (required): a four-byte value padded on the right with zero's. 222 Each value must be an ASCII uppercase letter or minus sign. 224 * Meaning source (required): A brief text description of the ID. 226 * Reference (required): the publication defining the ID. 228 The existing entries are left unchanged. 230 4.3. NTP Extension Field Types 232 The registration procedure is changed to Specification Required. 234 The reference should be [RFC5906] added, if possible. 236 The following Note is added: 238 * Field Types in the range 0xF000 through 0xFFFF, inclusive, are 239 reserved for experimentation and development. IANA cannot assign 240 them. Both NTS Cookie and Autokey Message Request have the same 241 Field Type; in practice this is not a problem as the field 242 semantics will be determined by other parts of the message. 244 The columns are defined as follows: 246 * Field Type (required): A two-byte value in hexadecimal. 248 * Meaning (required): A brief text description of the field type. 250 * Reference (required): the publication defining the field type. 252 The table is replaced with the following entries. 254 +============+===============================+=============+ 255 | Field Type | Meaning | Reference | 256 +============+===============================+=============+ 257 | 0x0002 | Reserved for historic reasons | This RFC | 258 +------------+-------------------------------+-------------+ 259 | 0x0102 | Reserved for historic reasons | This RFC | 260 +------------+-------------------------------+-------------+ 261 | 0x0104 | Unique Identifier | RFC 8915, | 262 | | | Section 5.3 | 263 +------------+-------------------------------+-------------+ 264 | 0x0200 | No-Operation Request | RFC 5906 | 265 +------------+-------------------------------+-------------+ 266 | 0x0201 | Association Message Request | RFC 5906 | 267 +------------+-------------------------------+-------------+ 268 | 0x0202 | Certificate Message Request | RFC 5906 | 269 +------------+-------------------------------+-------------+ 270 | 0x0203 | Cookie Message Request | RFC 5906 | 271 +------------+-------------------------------+-------------+ 272 | 0x0204 | NTS Cookie | RFC 8915, | 273 | | | Section 5.4 | 274 +------------+-------------------------------+-------------+ 275 | 0x0204 | Autokey Message Request | RFC 5906 | 276 +------------+-------------------------------+-------------+ 277 | 0x0205 | Leapseconds Message Request | RFC 5906 | 278 +------------+-------------------------------+-------------+ 279 | 0x0206 | Sign Message Request | RFC 5906 | 280 +------------+-------------------------------+-------------+ 281 | 0x0207 | IFF Identity Message Request | RFC 5906 | 282 +------------+-------------------------------+-------------+ 283 | 0x0208 | GQ Identity Message Request | RFC 5906 | 284 +------------+-------------------------------+-------------+ 285 | 0x0209 | MV Identity Message Request | RFC 5906 | 286 +------------+-------------------------------+-------------+ 287 | 0x0302 | Reserved for historic reasons | This RFC | 288 +------------+-------------------------------+-------------+ 289 | 0x0304 | NTS Cookie Placeholder | RFC 8915, | 290 | | | Section 5.5 | 291 +------------+-------------------------------+-------------+ 292 | 0x0402 | Reserved for historic reasons | This RFC | 293 +------------+-------------------------------+-------------+ 294 | 0x0404 | NTS Authenticator and | RFC 8915, | 295 | | Encrypted Extension Fields | Section 5.6 | 296 +------------+-------------------------------+-------------+ 297 | 0x0502 | Reserved for historic reasons | This RFC | 298 +------------+-------------------------------+-------------+ 299 | 0x0602 | Reserved for historic reasons | This RFC | 300 +------------+-------------------------------+-------------+ 301 | 0x0702 | Reserved for historic reasons | This RFC | 302 +------------+-------------------------------+-------------+ 303 | 0x2005 | Reserved for historic reasons | This RFC | 304 +------------+-------------------------------+-------------+ 305 | 0x8002 | Reserved for historic reasons | This RFC | 306 +------------+-------------------------------+-------------+ 307 | 0x8102 | Reserved for historic reasons | This RFC | 308 +------------+-------------------------------+-------------+ 309 | 0x8200 | No-Operation Response | RFC 5906 | 310 +------------+-------------------------------+-------------+ 311 | 0x8201 | Association Message Response | RFC 5906 | 312 +------------+-------------------------------+-------------+ 313 | 0x8202 | Certificate Message Response | RFC 5906 | 314 +------------+-------------------------------+-------------+ 315 | 0x8203 | Cookie Message Response | RFC 5906 | 316 +------------+-------------------------------+-------------+ 317 | 0x8204 | Autokey Message Response | RFC 5906 | 318 +------------+-------------------------------+-------------+ 319 | 0x8205 | Leapseconds Message Response | RFC 5906 | 320 +------------+-------------------------------+-------------+ 321 | 0x8206 | Sign Message Response | RFC 5906 | 322 +------------+-------------------------------+-------------+ 323 | 0x8207 | IFF Identity Message Response | RFC 5906 | 324 +------------+-------------------------------+-------------+ 325 | 0x8208 | GQ Identity Message Response | RFC 5906 | 326 +------------+-------------------------------+-------------+ 327 | 0x8209 | MV Identity Message Response | RFC 5906 | 328 +------------+-------------------------------+-------------+ 329 | 0x8302 | Reserved for historic reasons | This RFC | 330 +------------+-------------------------------+-------------+ 331 | 0x8402 | Reserved for historic reasons | This RFC | 332 +------------+-------------------------------+-------------+ 333 | 0x8502 | Reserved for historic reasons | This RFC | 334 +------------+-------------------------------+-------------+ 335 | 0x8602 | Reserved for historic reasons | This RFC | 336 +------------+-------------------------------+-------------+ 337 | 0x8702 | Reserved for historic reasons | This RFC | 338 +------------+-------------------------------+-------------+ 339 | 0x8802 | Reserved for historic reasons | This RFC | 340 +------------+-------------------------------+-------------+ 341 | 0xC002 | Reserved for historic reasons | This RFC | 342 +------------+-------------------------------+-------------+ 343 | 0xC102 | Reserved for historic reasons | This RFC | 344 +------------+-------------------------------+-------------+ 345 | 0xC200 | No-Operation Error Response | RFC 5906 | 346 +------------+-------------------------------+-------------+ 347 | 0xC201 | Association Message Error | RFC 5906 | 348 | | Response | | 349 +------------+-------------------------------+-------------+ 350 | 0xC202 | Certificate Message Error | RFC 5906 | 351 | | Response | | 352 +------------+-------------------------------+-------------+ 353 | 0xC203 | Cookie Message Error Response | RFC 5906 | 354 +------------+-------------------------------+-------------+ 355 | 0xC204 | Autokey Message Error | RFC 5906 | 356 | | Response | | 357 +------------+-------------------------------+-------------+ 358 | 0xC205 | Leapseconds Message Error | RFC 5906 | 359 | | Response | | 360 +------------+-------------------------------+-------------+ 361 | 0xC206 | Sign Message Error Response | RFC 5906 | 362 +------------+-------------------------------+-------------+ 363 | 0xC207 | IFF Identity Message Error | RFC 5906 | 364 | | Response | | 365 +------------+-------------------------------+-------------+ 366 | 0xC208 | GQ Identity Message Error | RFC 5906 | 367 | | Response | | 368 +------------+-------------------------------+-------------+ 369 | 0xC209 | MV Identity Message Error | RFC 5906 | 370 | | Response | | 371 +------------+-------------------------------+-------------+ 372 | 0xC302 | Reserved for historic reasons | This RFC | 373 +------------+-------------------------------+-------------+ 374 | 0xC402 | Reserved for historic reasons | This RFC | 375 +------------+-------------------------------+-------------+ 376 | 0xC502 | Reserved for historic reasons | This RFC | 377 +------------+-------------------------------+-------------+ 378 | 0xC602 | Reserved for historic reasons | This RFC | 379 +------------+-------------------------------+-------------+ 380 | 0xC702 | Reserved for historic reasons | This RFC | 381 +------------+-------------------------------+-------------+ 382 | 0xC802 | Reserved for historic reasons | This RFC | 383 +------------+-------------------------------+-------------+ 384 | 0x0902 | Reserved for historic reasons | This RFC | 385 +------------+-------------------------------+-------------+ 386 | 0x8902 | Reserved for historic reasons | This RFC | 387 +------------+-------------------------------+-------------+ 388 | 0xC902 | Reserved for historic reasons | This RFC | 389 +------------+-------------------------------+-------------+ 391 Table 1 393 5. Acknowledgements 395 The members of the NTP Working Group helped a great deal. Notable 396 contributors include. 398 * Miroslav Lichvar, Red Hat 400 * Daniel Franke, Akamai Technologies 402 * Danny Mayer, Network Time Foundation 404 * Michelle Cotton, IANA 406 6. Normative References 408 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 409 "Network Time Protocol Version 4: Protocol and Algorithms 410 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 411 . 413 [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol 414 Version 4: Autokey Specification", RFC 5906, 415 DOI 10.17487/RFC5906, June 2010, 416 . 418 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 419 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 420 2016, . 422 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 423 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 424 March 2016, . 426 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 427 Writing an IANA Considerations Section in RFCs", BCP 26, 428 RFC 8126, DOI 10.17487/RFC8126, June 2017, 429 . 431 [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code 432 for the Network Time Protocol", RFC 8573, 433 DOI 10.17487/RFC8573, June 2019, 434 . 436 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 437 Sundblad, "Network Time Security for the Network Time 438 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 439 . 441 Author's Address 443 Rich Salz 444 Akamai Technologies 446 Email: rsalz@akamai.com