idnits 2.17.1 draft-rsalz-update-registries-02.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (3 February 2021) is 1177 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ntp R. Salz 3 Internet-Draft Akamai Technologies 4 Intended status: Informational 3 February 2021 5 Expires: 7 August 2021 7 The update registries draft 8 draft-rsalz-update-registries-02 10 Abstract 12 The Network Time Protocol (NTP) and Network Time Security (NTS) 13 documents define a number of assigned number registries, collectively 14 called the NTP registries. Some registries have wrong values, some 15 registries do not follow current common practice, and some are just 16 right. For the sake of completeness, this document reviews all NTP 17 and NTS registries. 19 Discussion Venues 21 This note is to be removed before publishing as an RFC. 23 Source for this draft and an issue tracker can be found at 24 https://github.com/richsalz/draft-rsalz-update-registries. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 7 August 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Existing Registries . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Reference ID, Kiss-o'-Death . . . . . . . . . . . . . . . 3 62 2.2. Extension Field Types . . . . . . . . . . . . . . . . . . 3 63 2.3. Network Time Security Registries . . . . . . . . . . . . 4 64 3. New Registries . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. NTP Reference Identifier Codes . . . . . . . . . . . . . 4 67 4.2. NTP Kiss-o'-Death Codes . . . . . . . . . . . . . . . . . 5 68 4.3. NTP Extension Field Types . . . . . . . . . . . . . . . . 5 69 4.4. Network Time Security Key Establishment Record Types . . 9 70 4.5. Network Time Security Next Protocols . . . . . . . . . . 9 71 4.6. Network Time Security Error Codes . . . . . . . . . . . . 9 72 4.7. Network Time Security Warning Codes . . . . . . . . . . . 9 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 6. Normative References . . . . . . . . . . . . . . . . . . . . 10 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 The Network Time Protocol (NTP) and Network Time Security (NTS) 80 documents define a number of assigned number registries, collectively 81 called the NTP registries. Some registries have wrong values, some 82 registries do not follow current common practice, and some are just 83 right. For the sake of completeness, this document reviews all NTP 84 and NTS registries. 86 The bulk of this document can be divided into two parts: 88 * First, each registry, its defining document, and a summary of its 89 syntax is defined. 91 * Second, the revised format and entries for each registry are 92 defined. 94 2. Existing Registries 96 This section describes the registries and the rules for them. It is 97 intended to be a short summary of the syntax and registration 98 requirements for each registry. The semantics and protocol 99 processing rules for each registry -- that is, how an implementation 100 acts when sending or receiving any of the fields -- is not described 101 here. 103 2.1. Reference ID, Kiss-o'-Death 105 [RFC5905] defined two registries, the Reference ID in Section 7.3, 106 and the Kiss-o'-Death in Section 7.4. Both of these are allowed to 107 be four ASCII characters; padded on the right with all-bits-zero if 108 necessary. Entries that start with 0x58, the ASCII letter uppercase 109 X, are reserved for private experimentation and development. Both 110 registries are first-come first-served. The formal request to define 111 the registries is in Section 16. 113 Section 7.5 of [RFC5905] defined the on-the-wire format of extension 114 fields but did not create a registry for it. 116 2.2. Extension Field Types 118 [RFC5906] mentioned the Extension Field Types registry, and defined 119 it indirectly by defining 30 extensions (15 each for request and 120 response) in Section 13. It did not provide a formal definition of 121 the columns in the registry. Section 10 of [RFC5906] splits the 122 Field Type into four subfields, only for use within the Autokey 123 extensions. 125 [RFC7821] added a new entry, Checksum Complement, to the Extension 126 Field Types registry. 128 [RFC7822] clarified the processing rules for Extension Field Types, 129 particularly around the interaction with the Message Authentication 130 Code (MAC) field. 132 [RFC8573] changed the cryptography used in the MAC field. 134 The following problems exists with the current registry: 136 * Many of the entries in the Extension Field Types registry have 137 swapped some of the nibbles; 0x1234 is listed as 0x1432 for 138 example. This document marks the erroneous values as reserved. 140 * Some values were mistakenly re-used. 142 2.3. Network Time Security Registries 144 [RFC8915] defines the Network Time Security (NTS) protocol. Sections 145 7.1 through 7.5 (inclusive) added entries to existing registries. 147 Section 7.6 created a new registry, NTS Key Establishment Record 148 Types, that partitions the assigned numbers into three different 149 registration policies: IETF Review, Specification Required, and 150 Private or Experimental Use. 152 Section 7.7 created a new registry, NTS Next Protocols, that 153 similarly partitions the assigned numbers. 155 Section 7.8 created two new registries, NTS Error Codes and NTS 156 Warning Codes. Both registries are also partitioned the same way. 158 3. New Registries 160 The following general guidelines apply to all registries defined 161 here: 163 * Every entry reserves a partition for private use and 164 experimentation. 166 * Registries with ASCII fields are now limited to uppercase letters; 167 fields starting with 0x2D, the ASCII minus sign, are reserved for 168 private use and experimentation. 170 * The policy for every registry is now specification required, as 171 defined in Section 4.6 of [RFC8126]. 173 The IESG is requested to choose three designated experts, with two 174 being required to approve a registry change. 176 Each entry described in the below sub-sections is intended to 177 completely replace the existing entry with the same name. 179 4. IANA Considerations 181 4.1. NTP Reference Identifier Codes 183 The registration procedure is changed to specification required. 185 The Note is changed to read as follows: 187 * Codes beginning with the character "-" are reserved for 188 experimentation and development. IANA cannot assign them. 190 The columns are defined as follows: 192 * ID (required): a four-byte value padded on the right with zero's. 193 Each value must be an ASCII uppercase letter or minus sign 195 * Clock source (required): A brief text description of the ID 197 * Reference (required): the publication defining the ID. 199 The existing entries are left unchanged. 201 4.2. NTP Kiss-o'-Death Codes 203 The registration procedure is changed to specification required. 205 The Note is changed to read as follows: 207 * Codes beginning with the character "-" are reserved for 208 experimentation and development. IANA cannot assign them. 210 The columns are defined as follows: 212 * ID (required): a four-byte value padded on the right with zero's. 213 Each value must be an ASCII uppercase letter or minus sign. 215 * Meaning source (required): A brief text description of the ID. 217 * Reference (required): the publication defining the ID. 219 The existing entries are left unchanged. 221 4.3. NTP Extension Field Types 223 The registration procedure is changed to specification required. 225 The reference should be [RFC5906] added, if possible. 227 The following Note is added: 229 * Field Types in the range 0xF000 through 0xFFFF, inclusive, are 230 reserved for experimentation and development. IANA cannot assign 231 them. Both NTS Cookie and Autokey Message Request have the same 232 Field Type; in practice this is not a problem as the field 233 semantics will be determined by other parts of the message. 235 The columns are defined as follows: 237 * Field Type (required): A two-byte value in hexadecimal. 239 * Meaning (required): A brief text description of the field type. 241 * Reference (required): the publication defining the field type. 243 The table is replaced with the following entries. 245 +============+===============================+=============+ 246 | Field Type | Meaning | Reference | 247 +============+===============================+=============+ 248 | 0x0002 | Reserved for historic reasons | This RFC | 249 +------------+-------------------------------+-------------+ 250 | 0x0102 | Reserved for historic reasons | This RFC | 251 +------------+-------------------------------+-------------+ 252 | 0x0104 | Unique Identifier | RFC 8915, | 253 | | | Section 5.3 | 254 +------------+-------------------------------+-------------+ 255 | 0x0200 | No-Operation Request | RFC 5906 | 256 +------------+-------------------------------+-------------+ 257 | 0x0201 | Association Message Request | RFC 5906 | 258 +------------+-------------------------------+-------------+ 259 | 0x0202 | Certificate Message Request | RFC 5906 | 260 +------------+-------------------------------+-------------+ 261 | 0x0203 | Cookie Message Request | RFC 5906 | 262 +------------+-------------------------------+-------------+ 263 | 0x0204 | NTS Cookie | RFC 8915, | 264 | | | Section 5.4 | 265 +------------+-------------------------------+-------------+ 266 | 0x0204 | Autokey Message Request | RFC 5906 | 267 +------------+-------------------------------+-------------+ 268 | 0x0205 | Leapseconds Message Request | RFC 5906 | 269 +------------+-------------------------------+-------------+ 270 | 0x0206 | Sign Message Request | RFC 5906 | 271 +------------+-------------------------------+-------------+ 272 | 0x0207 | IFF Identity Message Request | RFC 5906 | 273 +------------+-------------------------------+-------------+ 274 | 0x0208 | GQ Identity Message Request | RFC 5906 | 275 +------------+-------------------------------+-------------+ 276 | 0x0209 | MV Identity Message Request | RFC 5906 | 277 +------------+-------------------------------+-------------+ 278 | 0x0302 | Reserved for historic reasons | This RFC | 279 +------------+-------------------------------+-------------+ 280 | 0x0304 | NTS Cookie Placeholder | RFC 8915, | 281 | | | Section 5.5 | 282 +------------+-------------------------------+-------------+ 283 | 0x0402 | Reserved for historic reasons | This RFC | 284 +------------+-------------------------------+-------------+ 285 | 0x0404 | NTS Authenticator and | RFC 8915, | 286 | | Encrypted Extension Fields | Section 5.6 | 287 +------------+-------------------------------+-------------+ 288 | 0x0502 | Reserved for historic reasons | This RFC | 289 +------------+-------------------------------+-------------+ 290 | 0x0602 | Reserved for historic reasons | This RFC | 291 +------------+-------------------------------+-------------+ 292 | 0x0702 | Reserved for historic reasons | This RFC | 293 +------------+-------------------------------+-------------+ 294 | 0x2005 | Reserved for historic reasons | This RFC | 295 +------------+-------------------------------+-------------+ 296 | 0x8002 | Reserved for historic reasons | This RFC | 297 +------------+-------------------------------+-------------+ 298 | 0x8102 | Reserved for historic reasons | This RFC | 299 +------------+-------------------------------+-------------+ 300 | 0x8200 | No-Operation Response | RFC 5906 | 301 +------------+-------------------------------+-------------+ 302 | 0x8201 | Association Message Response | RFC 5906 | 303 +------------+-------------------------------+-------------+ 304 | 0x8202 | Certificate Message Response | RFC 5906 | 305 +------------+-------------------------------+-------------+ 306 | 0x8203 | Cookie Message Response | RFC 5906 | 307 +------------+-------------------------------+-------------+ 308 | 0x8204 | Autokey Message Response | RFC 5906 | 309 +------------+-------------------------------+-------------+ 310 | 0x8205 | Leapseconds Message Response | RFC 5906 | 311 +------------+-------------------------------+-------------+ 312 | 0x8206 | Sign Message Response | RFC 5906 | 313 +------------+-------------------------------+-------------+ 314 | 0x8207 | IFF Identity Message Response | RFC 5906 | 315 +------------+-------------------------------+-------------+ 316 | 0x8208 | GQ Identity Message Response | RFC 5906 | 317 +------------+-------------------------------+-------------+ 318 | 0x8209 | MV Identity Message Response | RFC 5906 | 319 +------------+-------------------------------+-------------+ 320 | 0x8302 | Reserved for historic reasons | This RFC | 321 +------------+-------------------------------+-------------+ 322 | 0x8402 | Reserved for historic reasons | This RFC | 323 +------------+-------------------------------+-------------+ 324 | 0x8502 | Reserved for historic reasons | This RFC | 325 +------------+-------------------------------+-------------+ 326 | 0x8602 | Reserved for historic reasons | This RFC | 327 +------------+-------------------------------+-------------+ 328 | 0x8702 | Reserved for historic reasons | This RFC | 329 +------------+-------------------------------+-------------+ 330 | 0x8802 | Reserved for historic reasons | This RFC | 331 +------------+-------------------------------+-------------+ 332 | 0xC002 | Reserved for historic reasons | This RFC | 333 +------------+-------------------------------+-------------+ 334 | 0xC102 | Reserved for historic reasons | This RFC | 335 +------------+-------------------------------+-------------+ 336 | 0xC200 | No-Operation Error Response | RFC 5906 | 337 +------------+-------------------------------+-------------+ 338 | 0xC201 | Association Message Error | RFC 5906 | 339 | | Response | | 340 +------------+-------------------------------+-------------+ 341 | 0xC202 | Certificate Message Error | RFC 5906 | 342 | | Response | | 343 +------------+-------------------------------+-------------+ 344 | 0xC203 | Cookie Message Error Response | RFC 5906 | 345 +------------+-------------------------------+-------------+ 346 | 0xC204 | Autokey Message Error | RFC 5906 | 347 | | Response | | 348 +------------+-------------------------------+-------------+ 349 | 0xC205 | Leapseconds Message Error | RFC 5906 | 350 | | Response | | 351 +------------+-------------------------------+-------------+ 352 | 0xC206 | Sign Message Error Response | RFC 5906 | 353 +------------+-------------------------------+-------------+ 354 | 0xC207 | IFF Identity Message Error | RFC 5906 | 355 | | Response | | 356 +------------+-------------------------------+-------------+ 357 | 0xC208 | GQ Identity Message Error | RFC 5906 | 358 | | Response | | 359 +------------+-------------------------------+-------------+ 360 | 0xC209 | MV Identity Message Error | RFC 5906 | 361 | | Response | | 362 +------------+-------------------------------+-------------+ 363 | 0xC302 | Reserved for historic reasons | This RFC | 364 +------------+-------------------------------+-------------+ 365 | 0xC402 | Reserved for historic reasons | This RFC | 366 +------------+-------------------------------+-------------+ 367 | 0xC502 | Reserved for historic reasons | This RFC | 368 +------------+-------------------------------+-------------+ 369 | 0xC602 | Reserved for historic reasons | This RFC | 370 +------------+-------------------------------+-------------+ 371 | 0xC702 | Reserved for historic reasons | This RFC | 372 +------------+-------------------------------+-------------+ 373 | 0xC802 | Reserved for historic reasons | This RFC | 374 +------------+-------------------------------+-------------+ 375 | 0x0902 | Reserved for historic reasons | This RFC | 376 +------------+-------------------------------+-------------+ 377 | 0x8902 | Reserved for historic reasons | This RFC | 378 +------------+-------------------------------+-------------+ 379 | 0xC902 | Reserved for historic reasons | This RFC | 380 +------------+-------------------------------+-------------+ 382 Table 1 384 4.4. Network Time Security Key Establishment Record Types 386 The registration procedure is changed to specification required. 388 The following note should be added: 390 * Record Type numbers in the range 0x4000 through 0x7FFF, inclusive, 391 are reserved for experimentation and development. IANA cannot 392 assign them. 394 The existing entries are left unchanged. 396 4.5. Network Time Security Next Protocols 398 The registration procedure is changed to specification required. 400 The following note should be added: 402 * Protocol ID numbers in the range 0x8000 through 0xFFFF, inclusive, 403 are reserved for experimentation and development. IANA cannot 404 assign them. 406 The existing entries are left unchanged. 408 4.6. Network Time Security Error Codes 410 The registration procedure is changed to specification required. 412 The following note should be added: 414 * Error code numbers in the range 0x8000 through 0xFFFF, inclusive, 415 are reserved for experimentation and development. IANA cannot 416 assign them. 418 The existing entries are left unchanged. 420 4.7. Network Time Security Warning Codes 422 The registration procedure is changed to specification required. 424 The following note should be added: 426 * Warning code numbers in the range 0x8000 through 0xFFFF, 427 inclusive, are reserved for experimentation and development. IANA 428 cannot assign them. 430 The existing entries are left unchanged. 432 5. Acknowledgements 434 The members of the NTP Working Group helped a great deal. Notable 435 contributors include. 437 * Miroslav Lichvar, RedHat 439 * Daniel Franke, Akamai Technologies 441 * Danny Mayer, Network Time Foundation 443 * Michelle Cotton, IANA 445 And thanks to Harlen Stenn for providing popcorn. 447 6. Normative References 449 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 450 "Network Time Protocol Version 4: Protocol and Algorithms 451 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 452 . 454 [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol 455 Version 4: Autokey Specification", RFC 5906, 456 DOI 10.17487/RFC5906, June 2010, 457 . 459 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 460 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 461 2016, . 463 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 464 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 465 March 2016, . 467 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 468 Writing an IANA Considerations Section in RFCs", BCP 26, 469 RFC 8126, DOI 10.17487/RFC8126, June 2017, 470 . 472 [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code 473 for the Network Time Protocol", RFC 8573, 474 DOI 10.17487/RFC8573, June 2019, 475 . 477 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 478 Sundblad, "Network Time Security for the Network Time 479 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 480 . 482 Author's Address 484 Rich Salz 485 Akamai Technologies 487 Email: rsalz@akamai.com