idnits 2.17.1 draft-rsalz-update-registries-01.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 (7 January 2021) is 1203 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 7 January 2021 5 Expires: 11 July 2021 7 The update registries draft 8 draft-rsalz-update-registries-01 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 11 July 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 Consideration . . . . . . . . . . . . . . . . . . . . . 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 divded 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 four ASCII 107 characters, left justified and padded with zero's. Entries that 108 start with 0x58, the ASCII letter uppercase X, are reserved for 109 private experimentation and development. Both registries are first- 110 come first-served. The formal request to define the registries is in 111 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; 1234 is listed as 1432 for example. 138 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 regisries. 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 regisries 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. 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 Consideration 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. Should we remove the 395 Unassigned and Reserved rows? Should we convert the numbers to hex? 397 4.5. Network Time Security Next Protocols 399 The registration procedure is changed to specification required. 401 The following note should be added: 403 * Protocol ID numbers in the range 0x8000 through 0xFFFF, inclusive, 404 are reserved for experimentation and development. IANA cannot 405 assign them. 407 The existing entries are left unchanged. Should we remove the 408 Unassigned and Reserved rows? Should we convert the numbers to hex? 410 4.6. Network Time Security Error Codes 412 The registration procedure is changed to specification required. 414 The following note should be added: 416 * Error code numbers in the range 0x8000 through 0xFFFF, inclusive, 417 are reserved for experimentation and development. IANA cannot 418 assign them. 420 The existing entries are left unchanged. Should we remove the 421 Unassigned and Reserved rows? 423 4.7. Network Time Security Warning Codes 425 The registration procedure is changed to specification required. 427 The following note should be added: 429 * Warning code numbers in the range 0x8000 through 0xFFFF, 430 inclusive, are reserved for experimentation and development. IANA 431 cannot assign them. 433 The existing entries are left unchanged. Should we remove the 434 Unassigned and Reserved rows? Can IANA handle an empty table? 436 5. Acknowledgements 438 The members of the NTP Working Group helped a great deal. Notable 439 contributors include. 441 * Miroslav Lichvar, RedHat 443 * Daniel Franke, Akamai Technologies 445 * Danny Mayer, Network Time Foundation 447 And thanks to Harlen Stenn for providing popcorn. 449 6. Normative References 451 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 452 "Network Time Protocol Version 4: Protocol and Algorithms 453 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 454 . 456 [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol 457 Version 4: Autokey Specification", RFC 5906, 458 DOI 10.17487/RFC5906, June 2010, 459 . 461 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 462 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 463 2016, . 465 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 466 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 467 March 2016, . 469 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 470 Writing an IANA Considerations Section in RFCs", BCP 26, 471 RFC 8126, DOI 10.17487/RFC8126, June 2017, 472 . 474 [RFC8573] Malhotra, A. and S. Goldberg, "Message Authentication Code 475 for the Network Time Protocol", RFC 8573, 476 DOI 10.17487/RFC8573, June 2019, 477 . 479 [RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. 480 Sundblad, "Network Time Security for the Network Time 481 Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020, 482 . 484 Author's Address 486 Rich Salz 487 Akamai Technologies 489 Email: rsalz@akamai.com