idnits 2.17.1 draft-stenn-ntp-extension-fields-09.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 abstract seems to contain references ([RFC5905], [RFC5906], [RFC7822]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC7822, but the abstract doesn't seem to directly say this. It does mention RFC7822 though, so this could be OK. -- The abstract seems to indicate that this document updates RFC5905, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2019) is 1857 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5906 ** Downref: Normative reference to an Experimental RFC: RFC 7821 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Stenn 3 Internet-Draft D. Mills 4 Obsoletes: 7822 (if approved) Network Time Foundation 5 Intended status: Standards Track March 26, 2019 6 Expires: September 27, 2019 8 Network Time Protocol Version 4 (NTPv4) Extension Fields 9 draft-stenn-ntp-extension-fields-09 11 Abstract 13 Network Time Protocol version 4 (NTPv4) defines the optional usage of 14 extension fields. An extension field, as defined in RFC 5905 15 [RFC5905] and RFC 5906 [RFC5906], resides after the end of the NTP 16 header and supplies optional capabilities or information that cannot 17 be conveyed in the basic NTP packet. This document updates RFC 5905 18 [RFC5905] by clarifying some points regarding NTP extension fields 19 and their usage with legacy Message Authentication Codes (MACs), and 20 removes wasteful requirements added by RCF 7822 [RFC7822]. 22 This proposal deprecates RFC 7822 [RFC7822]. 24 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: 26 The source code and issues list for this draft can be found in 27 https://github.com/hstenn/ietf-ntp-extension-fields 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 27, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 65 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 67 3. NTP MAC - RFC 5906 Update . . . . . . . . . . . . . . . . . . 4 68 3.1. RFC5906 Section 4. - Autokey Cryptography . . . . . . . . 4 69 3.2. RFC5906 Section 10. - Autokey Protocol Messages . . . . . 4 70 3.3. RFC5906 Section 11.5. - Error Recovery . . . . . . . . . 5 71 3.4. RFC5906 Section 13. - IANA Consideration . . . . . . . . 5 72 4. NTP Extension Fields - RFC 5905 Update . . . . . . . . . . . 5 73 4.1. OLD: 'RFC5905 7.5 - NTP Extension Field Format' . . . . . 5 74 4.2. NEW: 'RFC5905 Section 7.5 - NTP Extension Field Format' . 6 75 4.3. NEW: 'RFC5905 Section 7.5.1 - Extension Fields and MACs' 8 76 4.4. OLD: 'RFC5905 Section 9.2. - Peer Process Operations' . . 10 77 4.5. NEW: 'RFC5905 Section 9.2. - Peer Process Operations' . . 10 78 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 8.2. Informative References . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 An NTP packet consists of a set of fixed fields that may be followed 89 by optional fields. Two types of optional fields are defined: 90 extension fields (EFs) as defined in Section 7.5 of RFC 5905 91 [RFC5905], and legacy Message Authentication Codes (legacy MACs). 93 If a legacy MAC is used, it resides at the end of the packet. This 94 field can be either a 4-octet crypto-NAK or data that has 95 traditionally been 16, 20 or 24 octets long. 97 Additional information about the content of a MAC is specified in RFC 98 5906 [RFC5906], but since that RFC is Informational an implementor 99 that was not planning to provide Autokey would likely never read that 100 document. The result of this would be interoperability problems, at 101 least. To address this problem this proposal also copies and 102 clarifies some of the content of RFC 5906, putting it into RFC 5905. 103 Because there is a reasonable expectation that RFC 5906 will be 104 deprecated, this document does not propose changes or updates to RFC 105 5906. 107 NTP extension fields are defined in RFC 5905 [RFC5905] as a generic 108 mechanism that allows the addition of future extensions and features 109 without modifying the NTP header format (Section 16 of RFC 5905 110 [RFC5905]). 112 With the knowledge and experience we have gained over time, it has 113 become clear that simplifications, clarifications, and improvements 114 can be made to the NTP specification around EFs and MACs. 116 This proposal adjusts and clarifies the requirements around EFs and 117 MACs, allows EFs to be on 4-octet boundaries of any acceptable 118 length, and provides methods to disambiguate packet parsing in the 119 unexpected and unlikely case where an implementation would choose to 120 send a packet that could be ambiguously parsed by the receiver. 122 This proposal deprecates RFC 7822 [RFC7822]. 124 Implementations are still free to send EFs that are padded to longer 125 lengths that otherwise follow the requirements below. 127 This document better specifies and clarifies extension fields as well 128 as the requirements and parsing of a legacy MAC, with changes to 129 address errors found after the publication of RFC 5905 [RFC5905] with 130 respect to extension fields. Specifically, this document updates 131 Section 7.5 of RFC 5905 [RFC5905], clarifying the relationship 132 between extension fields and MACs, and expressly defines the behavior 133 of a host that receives an unknown extension field. 135 2. Conventions Used in This Document 136 2.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 2.2. Terms and Abbreviations 144 EF - Extension Field 146 MAC - Message Authentication Code 148 NTPv4 - Network Time Protocol, Version 4 RFC 5905 [RFC5905] 150 3. NTP MAC - RFC 5906 Update 152 This document copies and updates some information in RFC 5906 153 [RFC5906] and puts it in to RFC 5905, as follows: 155 3.1. RFC5906 Section 4. - Autokey Cryptography 157 This section describes some of the cryptography aspects of Autokey. 158 The third paragraph describes the use of 128- and 160-bit message 159 digests. The enumeration of 128- and 160-bit message digests is not 160 meant to be limiting - other message digest lengths MAY be 161 implemented. This paragraph also describes some of the expected 162 semantic ranges of the key ID. This information belongs in RFC 5905. 163 The key ID value is particularly significant because it provides 164 additional detection and disambiguation protection when deciding if 165 the next data portion is either a legacy MAC or an extension field. 166 [This is additional evidence that although RFC 5906 is Informational, 167 parts of its content are REQUIRED for proper behavior of RFC 5905.] 169 3.2. RFC5906 Section 10. - Autokey Protocol Messages 171 This section describes the extension field format, including initial 172 flag bits, a Code field, and 8-bit Field Type, and the 16-bit Length. 173 This proposal expands and clarifies this information and puts it into 174 RFC 5905. 176 This section says "The reference implementation discards any packet 177 with a field length of more than 1024 characters." but this is no 178 longer true. 180 3.3. RFC5906 Section 11.5. - Error Recovery 182 This section describes the crypto-NAK, which should be described in 183 RFC 5905. A crypto-NAK is used by RFC 5905 as well. [This is 184 additional evidence that even though RFC 5906 was Informational, some 185 of its content is REQUIRED for proper behavior for RFC 5095.] 187 3.4. RFC5906 Section 13. - IANA Consideration 189 This section lists the Autokey-related Extension Field Types, 190 including Flag Bits, Codes, and Field Types, which should be 191 described in RFC 5905, or perhaps in some other document. [This is 192 additional evidence that even though RFC 5906 is Informational, some 193 of its content is REQUIRED for proper behavior for RFC 5905.] 195 4. NTP Extension Fields - RFC 5905 Update 197 This document updates Section 7.5 of RFC 5905 [RFC5905] as follows: 199 4.1. OLD: 'RFC5905 7.5 - NTP Extension Field Format' 201 In NTPv4, one or more extension fields can be inserted after the 202 header and before the MAC, which is always present when an extension 203 field is present. Other than defining the field format, this 204 document makes no use of the field contents. An extension field 205 contains a request or response message in the format shown in 206 Figure 14. 208 0 1 2 3 209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 210 +---------------+---------------+-------------------------------+ 211 | Field Type | Field Length | 212 +-------------------------------+-------------------------------+ 213 . . 214 . Value . 215 . . 216 +-------------------------------+-------------------------------+ 217 | Padding (as needed) | 218 +---------------------------------------------------------------+ 220 Figure 14: Extension Field Format 222 All extension fields are zero-padded to a word (four octets) 223 boundary. The Field Type field is specific to the defined function 224 and is not elaborated here. While the minimum field length 225 containing required fields is four words (16 octets), a maximum field 226 length remains to be established. 228 The Length field is a 16-bit unsigned integer that indicates the 229 length of the entire extension field in octets, including the Padding 230 field. 232 4.2. NEW: 'RFC5905 Section 7.5 - NTP Extension Field Format' 234 In NTPv4, one or more extension fields can be inserted after the 235 header and before the possibly optional legacy MAC. A MAC SHOULD be 236 present when an extension field is present. A MAC is always present 237 in some form when NTP packets are authenticated. This MAC SHOULD be 238 either a legacy MAC or a MAC-EF. It MAY be both. Other than 239 defining the field format, this document makes no use of the field 240 contents. An extension field contains a request or response message 241 in the format shown in Figure 14. 243 0 1 2 3 244 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 245 +---------------+---------------+-------------------------------+ 246 | Field Type | Field Length | 247 +-------------------------------+-------------------------------+ 248 . . 249 . Value . 250 . . 251 +-------------------------------+-------------------------------+ 252 | Padding (as needed) | 253 +---------------------------------------------------------------+ 255 Figure 14: Extension Field Format 257 The four octets that comprise the Field Type and Field Length are 258 called the Extension Field Header. Octets beyond the Extension Field 259 Header are called the Extension Field Body, or the Extension Field 260 Payload. The EF Body (EF Payload) MAY be null in some cases. 262 All extension fields are zero-padded to a word (four octet) boundary. 263 The Field Type is specific to the defined functionality and detailed 264 information about the Field Type is not elaborated here. The minimum 265 size of an Extension Field is a 32-bit word (4 octets), and while the 266 maximum extension field size MUST be 65532 octets or less, an NTP 267 packet SHOULD NOT exceed the network MTU. 269 The Field Length is a 16-bit unsigned integer that indicates the 270 length of the entire extension field in octets, including any Padding 271 octets. The bottom two bits of the Field Length SHOULD be zero, and 272 the size of the extension field SHOULD end on a 32-bit (4 octet) 273 boundary. [RFC5905 Section 7.5 says "All extension fields are zero- 274 padded to a word (four octets) boundary." but does not use 'MUST' 275 language. Is it overkill to reiterate this requirement here? Should 276 we use SHOULD or MUST regarding the bottom two bits or the boundary 277 of the EF? It is possible, down the road, that we might find some 278 use for those bottom 2 bits, even if we require a 32-bit boundary on 279 the last octet of an EF.] 281 The Field Type contains the following sub-elements: 283 0 1 2 3 284 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 285 +---------------+---------------+-------------------------------+ 286 |R|E| Code | Type | (Field Length) | 287 +-------------------------------+-------------------------------+ 289 Extension Field Header Format 291 Where the following Field Type flags are defined: 293 R: 0 for "Information/Query", 1 for a "Response" 295 E: 0 for "OK", 1 for an "Error". Unused, and will be deprecated. 297 [The 'R' flag is currently used by Autokey [RFC5906], and by the 298 proposed I-DO [DRAFT-I-DO] extension field. This flag is used after 299 the packet is accepted.] 301 [The 'E' flag was proposed for use by Autokey, after the packet was 302 accepted. As it was never used and no other use-cases have been 303 identified, we are recommending this flag be deprecated at some point 304 in the future.] 306 [The EF Code subtype is currently used by RFC 5906, Autokey 307 [RFC5906], by the proposed Extended Information 308 [DRAFT-EXTENDED-INFORMATION], I-DO [DRAFT-I-DO], and is expected to 309 be used by the NTS Extension Field, at least.] 311 The Autokey EF currently uses the most Code values - 10 of them, 312 which equates to the least-significant 4 bits of the high-order 313 octet. It is possible that additional flag bits will be allocated; 314 in the past, the high-order 2 bits were reserved, and for a time two 315 additional bits were proposed. Make no assumptions about the unused 316 bits in this octet. 318 The EF Header and Body fields (the Flags, Code, Type, and Length, and 319 any Value or Padding) are specific to the defined functionality and 320 are not elaborated here; appropriate Field Type Flags, the EF Code, 321 and EF Type values are defined in an IANA registry, and the Length, 322 Value, and Padding values are defined by the document referred to by 323 the registry. If a host receives an extension field with an unknown 324 Field Type, the host SHOULD ignore the extension field and MAY drop 325 the packet altogether, depending on local policy. 327 The Length field is a 16-bit unsigned integer that indicates the 328 length of the entire extension field in octets, including any 329 Padding. 331 While the minimum field length of an EF that contains no value or 332 padding fields is one word (four octets), and the minimum field 333 length of an EF that contains required fields is two words (8 334 octets), the maximum field length MUST NOT be longer than 65532 335 octets due to the maximum size of the data represented by the Length 336 field, and SHOULD be small enough that the size of the NTP packet 337 received by the client does not exceed the smallest MTU between the 338 sender and the recipient. The bottom two bits of the Field Length 339 SHOULD be zero and the EF data SHOULD be aligned to a 32-bit (4 340 octet) boundary. 342 4.3. NEW: 'RFC5905 Section 7.5.1 - Extension Fields and MACs' 344 With the inclusion of additional Extension Fields, there is now a 345 potential that a poorly-designed implementation would produce an 346 ambiguous parsing in the presence of a legacy MAC. What follows are 347 two possibly independent ways to prevent this situation from ever 348 happening. 350 Note well that to-date, there are only two defined Extension Field 351 Types: Autokey, defined by RFC 5906 [RFC5906], and the Experimental 352 UDP Checksum Complement in the Network Time Protocol, defined by RFC 353 7821 [RFC7821]. 355 In spite of its known serious problems, Autokey is still in use by 356 some and is a legacy case that is easily supported. Old systems will 357 still work. An old system will still be able to open a properly- 358 configured Autokey association to a new system, a new system will 359 still be able to open a properly-configured Autokey association with 360 an old system, and two new systems will be able to open a properly- 361 configured Autokey association. 363 The UDP Checksum Complement extension field forbids the use of a 364 legacy MAC, so any packet that uses it CANNOT be using a legacy MAC. 365 [We could list the detailed and specific reasons why traffic using 366 this EF is immune to EF/legacy MAC problems, but I fear that would 367 just be confusing to most people.] 369 The first and best way to prevent ambiguous parsing is to use the 370 I-DO [DRAFT-I-DO] extension field. 372 By definition any NTP client or server that handles any other 373 Extension Fields is "new code" and can completely prevent ambiguity 374 by the initiating side sending a packet containing an I-DO 375 [DRAFT-I-DO] extension field followed by an optional MAC-EF 376 [DRAFT-MAC-LAST-EF] followed by an optional legacy MAC. The 377 inclusion of any MAC would be dictated by the authentication 378 requirements of the association. 380 Note that NTP traffic works perfectly well without using any other 381 extension fields. Newer extension fields offer additional 382 capabilities, but these capabilities are not required for operation. 383 [Even in the case of NTS or SNT, we're talking about "new code" that 384 can be expected to be aware of issues with new extension fields an 385 legacy MACs.] 387 If the initiating side sends an I-DO [DRAFT-I-DO] packet and gets no 388 response, it operates as if the other side cannot handle new 389 extension fields and simply continues the association without sending 390 any new extension fields. At any point in the future a packet can be 391 sent with an I-DO extension field to see if the other side will 392 respond. 394 An NTP implementation that receives a packet with an I-DO extension 395 field may respond with a packet that may or may not contain an I-DO 396 Response. If it does not respond, the other side SHOULD assume that 397 the receiver does not understand new EFs. If it responds without 398 sending an I-DO Response extension field, the sending side knows it 399 should not send any new extension fields to this server. If the 400 system that receives an I-DO extension field responds with an I-DO 401 Response, it's telling the sender exactly what capabilities it is 402 currently willing to exchange. 404 The second way to prevent ambiguous parsing is to use the LAST-EF 405 [DRAFT-MAC-LAST-EF] extension field. 407 By definition, if I-DO is used and each side agrees to support LAST- 408 EF then LAST-EF will prevent any ambiguity. 410 If, however, I-DO is not used then one side can simply send a packet 411 with a LAST-EF. The LAST-EF extension field could be four-octet 412 extension field, it could be a 28 octet extension field, or some 413 other length that ends on a 32-bit boundary. If the other side 414 responds appropriately then all is well. If the other side does not 415 respond appropriately the sender should proceed without sending any 416 new extension fields. 418 Parties interested in additional reasons for and approaches to 419 understanding why there is no reason to be concerned about potential 420 ambiguities with new code that would use new extension fields and 421 legacy MACs can look at the the drafts that preceded this document. 423 4.4. OLD: 'RFC5905 Section 9.2. - Peer Process Operations' 425 ... 427 FXMIT. ... This message includes the normal NTP header data shown in 428 Figure 8, but with a MAC consisting of four octets of zeros. ... 430 4.5. NEW: 'RFC5905 Section 9.2. - Peer Process Operations' 432 ... 434 FXMIT. ... This message includes the normal NTP header data shown in 435 Figure 8, but with a MAC consisting of four octets of zeros. This 436 MAC can be a legacy MAC or a MAC-EF. If it's a MAC-EF, the crypto- 437 NAK MUST be the only MAC in the MAC-EF payload. ... 439 5. Acknowledgements 441 The authors wish to acknowledge the contributions of Sam Weiler, 442 Danny Mayer, and Tal Mizrahi. 444 6. IANA Considerations 446 This memo requests IANA to update the NTP Extension Field Types table 447 in the NTP Parameters document as follows. The following is expected 448 to be a functional superset of the existing information: 450 0 1 451 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 452 +---------------+---------------+ 453 |R|E| Code | Type | 454 +-------------------------------+ 456 NTP Extension Field Type Format 458 Where the following Field Type flags are defined: 460 R: 0 for "Information/Query", 1 for a "Response" 462 E: 0 for "OK", 1 for an "Error". Unused, and will be deprecated. 464 +------------+----------------------------------------------+ 465 | Field Type | Meaning | 466 +------------+----------------------------------------------+ 467 | 0x0000 | crypto-NAK (with Field Length of 0) | 468 | 0x0000 | RESERVED: Permanently Unassigned | 469 | 0x0001 | RESERVED: Unassigned | 470 | 0x0002 | Autokey: No-Operation Request | 471 | 0x8002 | Autokey: No-Operation Response | 472 | 0x0102 | Autokey: Association Message Request | 473 | 0x8102 | Autokey: Association Message Response | 474 | 0x0202 | Autokey: Certificate Message Request | 475 | 0x8202 | Autokey: Certificate Message Response | 476 | 0x0302 | Autokey: Cookie Message Request | 477 | 0x8302 | Autokey: Cookie Message Response | 478 | 0x0402 | Autokey: Autokey Message Request | 479 | 0x8402 | Autokey: Autokey Message Response | 480 | 0x0502 | Autokey: Leapseconds Value Message Request | 481 | 0x8502 | Autokey: Leapseconds Value Message Response | 482 | 0x0602 | Autokey: Sign Message Request | 483 | 0x8602 | Autokey: Sign Message Response | 484 | 0x0702 | Autokey: IFF Identity Message Request | 485 | 0x8702 | Autokey: IFF Identity Message Response | 486 | 0x0802 | Autokey: GQ Identity Message Request | 487 | 0x8802 | Autokey: GQ Identity Message Response | 488 | 0x0902 | Autokey: MV Identity Message Request | 489 | 0x8902 | Autokey: MV Identity Message Response | 490 | 0x0003 | * MAC | 491 | 0x0104 | * NTS Unique Identifier Request | 492 | 0x8104 | * NTS Unique Identifier Response | 493 | 0x0204 | * NTS Cookie | 494 | 0x0304 | * NTS Cookie Placeholder | 495 | 0x0404 | * NTS AEEF Request | 496 | 0x8404 | * NTS AEEF Response | 497 | 0x0005 | Checksum Complement | 498 | 0x2005 | Checksum Complement (deprecated flag 0x2000) | 499 | 0x0006 | * Suggest REFID | 500 | 0x0007 | * I-DO | 501 | 0x0008 | * LAST-EF | 502 | 0x0009 | * Extended Information | 503 | 0x00FF | * thru | 504 | 0xFDFF | * RESERVED for future I-DO Payloads | 505 | 0xFEFF | * I-DO Payload: Leap Smear REFIDs | 506 | 0xFFFF | * I-DO Payload: IPv6 REFID hash | 507 +------------+----------------------------------------------+ 509 * Tentative Reservation 511 Current Extension Fields 513 7. Security Considerations 515 The authors know of no adverse consequences of adopting this 516 proposal. 518 8. References 520 8.1. Normative References 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, 524 DOI 10.17487/RFC2119, March 1997, 525 . 527 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 528 "Network Time Protocol Version 4: Protocol and Algorithms 529 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 530 . 532 [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol 533 Version 4: Autokey Specification", RFC 5906, 534 DOI 10.17487/RFC5906, June 2010, 535 . 537 [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time 538 Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 539 2016, . 541 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 542 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 543 March 2016, . 545 8.2. Informative References 547 [DRAFT-EXTENDED-INFORMATION] 548 Stenn, H., "draft-stenn-ntp-extended-information", 2019. 550 [DRAFT-I-DO] 551 Stenn, H., "draft-stenn-ntp-i-do", 2019. 553 [DRAFT-MAC-LAST-EF] 554 Stenn, H., "draft-stenn-ntp-mac-last-ef", 2019. 556 Authors' Addresses 557 Harlan Stenn 558 Network Time Foundation 559 P.O. Box 918 560 Talent, OR 97540 561 US 563 Email: stenn@nwtime.org 565 David L. Mills 566 Network Time Foundation 567 P.O. Box 918 568 Talent, OR 97540 569 US 571 Email: mills@udel.edu