idnits 2.17.1 draft-stenn-ntp-i-do-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 abstract seems to contain references ([RFC5905], [RFC5906]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 29, 2017) is 2333 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 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Stenn 3 Internet-Draft Network Time Foundation 4 Intended status: Standards Track November 29, 2017 5 Expires: June 2, 2018 7 Network Time Protocol I-Do Extension Field 8 draft-stenn-ntp-i-do-03 10 Abstract 12 The first implementation of NTPv4 was released in 2003. NTPv4 is 13 defined by RFC 5905 [RFC5905]. It contains a public-key security 14 protocol, Autokey, which is defined by RFC 5906 [RFC5906]. Until 15 very recently, Autokey has been the only defined "user" of NTP packet 16 Extension Fields. New proposals for extension fields are being 17 written and there is currently no convenient way to learn if a remote 18 instance of NTP supports any extension fields or not. This proposal 19 contains a method to tell a remote instance of NTP what we (are 20 willing to admit we) support, and ask what they (are willing to admit 21 they) support. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 2, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 59 2. The I-Do Extension Field . . . . . . . . . . . . . . . . . . 2 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 5. Normative References . . . . . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 The first implementation of NTPv4 was released in 2003. NTPv4 is 68 defined by RFC 5905 [RFC5905]. It contains a public-key security 69 protocol, Autokey, which is defined by RFC 5906 [RFC5906]. Until 70 very recently, Autokey has been the only defined "user" of NTP packet 71 Extension Fields. New proposals for extension fields are being 72 written and there is currently no convenient way to learn if a remote 73 instance of NTP supports any extension fields or not. This proposal 74 contains a method to tell a remote instance of NTP what we (are 75 willing to admit we) support, and ask what they (are willing to admit 76 they) support. 78 1.1. Requirements Language 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 2. The I-Do Extension Field 86 The purpose of the I-DO EF is to provide information to the remote 87 side about our capabilities. 89 If an incoming packet contains an unrecognized extension field, one 90 of several things will happen. While that unrecognized extension 91 field SHOULD be ignored, an implementation MAY choose to drop the 92 entire packet. If any extension field is present there ordinarily 93 SHOULD be a MAC following the extension field, but an older 94 conforming NTP implementation would assume that any EF MUST be 95 followed by a MAC. Some extension fields are unable to be "signed" 96 by a MAC, regardless of whether or not that MAC is a traditional MAC 97 or an extension field MAC. In the final case, the receiving system 98 will interpret the unrecognized EF as a legacy MAC, and return a 99 crypto-NAK. 101 If the remote system replies with a crypto-NAK, that is a good 102 indication that it is running older software that does not recognize 103 EFs and thinks we have sent an invalid MAC. In this case, we should 104 behave accordingly with regard to the remote system. 106 If the remote system replies without including an I-DO-RESPONSE EF, 107 we at least know they can handle EFs, but they either don't 108 understand I-DO or are not willing to tell us anything. 110 If the remote system replies with a packet that includes an I-DO- 111 RESPONSE EF, then we SHOULD remember what they told us, and use that 112 information appropriately. 114 In client/server mode, it makes sense for the client to send an I-DO 115 to the server, and notice how the server responds. It likely does 116 not make sense for the server to send an I-DO EF in response to a 117 client request. 119 In symmetric mode, either side may initiate sending an I-DO EF, and 120 the receiving side SHOULD reply with an I-DO-RESPONSE EF. 122 In broadcast mode, the broadcast server MAY send broadcast packets 123 that include an I-DO EF, but note that if, counter to recommended 124 practice, these packets are unauthenticated they MAY cause client 125 machines to misinterpret the packet as having invalid authentication. 126 In this situation, the broadcast server SHOULD alternate sending 127 broadcast server packets with and without an I-DO EF, to insure that 128 all clients receive time packets they will accept. Note that if, as 129 recommended, broadcast packets are authenticated, a conforming client 130 SHOULD have no difficulty in receiving a broadcast (mode 5) packet 131 from a server that includes an I-DO EF. 133 0 1 2 3 134 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 135 +---------------+---------------+-------------------------------+ 136 | Field Type | Field Length | 137 +-------------------------------+-------------------------------+ 138 | I-Do 1 | ... | 139 +-------------------------------+-------------------------------+ 140 | I-Do N | Padding | 141 +---------------------------------------------------------------+ 143 NTP Extension Field: REFID Suggestion 145 Field Type: TBD (Recommendation for IANA: 0x0007 (I-Do, MAC 146 required), 0x2007 (I-Do, MAC OPTIONAL), 0x8007 (I-Do Response, MAC 147 required), 0xA007 I-Do Response, MAC OPTIONAL)) 149 Field Length: as needed 151 Payload: An enumeration of the supported base Field Types, followed 152 by any padding, 0x0000, needed to fill the payload to the desired 153 32-bit boundary. 155 Example: A system that wants to advertise support for Autokey and 156 I-Do, sending to a system that wants to advertise support for I-Do, 157 NTS, and MAC-As-Extension-Field 159 0 1 2 3 160 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 161 +---------------+---------------+-------------------------------+ 162 | Field Type (0x2007) | Field Length (0x0008) | 163 +-------------------------------+-------------------------------+ 164 | 0x0007 | 0x0002 | 165 +-------------------------------+-------------------------------+ 167 NTP Extension Field: I-Do 169 0 1 2 3 170 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 171 +---------------+---------------+-------------------------------+ 172 | Field Type (0xA007) | Field Length (0x000a) | 173 +-------------------------------+-------------------------------+ 174 | 0x0003 | 0x0004 | 175 +-------------------------------+-------------------------------+ 176 | 0x0007 | 0x0000 | 177 +-------------------------------+-------------------------------+ 179 NTP Extension Field: I-Do Response 181 The sender of any I-Do extension field MUST send an extension field 182 with a Field Type of 0x0007 (I-Do, MAC required) or 0x2007 (I-Do, MAC 183 OPTIONAL) and SHOULD include a payload with any 0x0000 padding values 184 after enumerating the supported base Extension Field Types. If the 185 responding system recognizes the I-Do extension field, its response 186 MUST include an extension field with a Field Type of 0x8007 (I-Do 187 Response, MAC required) or 0xA007 (I-Do Response, MAC OPTIONAL), and 188 SHOULD include a payload with any 0x0000 padding values after 189 enumerating the supported base Extension Field Types. 191 Any system that receives an I-Do extension field as either an "offer" 192 or a "response" SHOULD scan the entire payload looking for nonzero 193 values that specify the capabilities of the remote association. 195 Any system that receives an I-Do "offer", 0x0007 or 0x2007, SHOULD 196 reply with an I-Do "response", 0x8007 or 0xA007. 198 Any system that sends an I-Do "offer" or "response" may send as few 199 or as many of its supported Field Types as it chooses. At any 200 subsequent time, either side may re-negotiate the list of supported 201 field types it is prepared to accept from the other system by sending 202 a new I-Do extension field. 204 The most-recently received I-Do list replaces any previous I-Do list. 206 3. IANA Considerations 208 This memo requests IANA to allocate NTP Extension Field Types: 210 0x0007 (I-DO) 212 0x2007 (I-DO, MAC OPTIONAL) 214 0x8007 (I-DO Response) 216 0xA007 (I-DO Response, MAC OPTIONAL) 218 and I-DO types: 220 0xFFFE (I-DO Leap Smear REFIDs) 222 0xFFFF (I-DO IPv6 REFID hash) 224 for this proposal. 226 4. Security Considerations 228 Additional information TBD 230 5. Normative References 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, 234 DOI 10.17487/RFC2119, March 1997, 235 . 237 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 238 "Network Time Protocol Version 4: Protocol and Algorithms 239 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 240 . 242 [RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol 243 Version 4: Autokey Specification", RFC 5906, 244 DOI 10.17487/RFC5906, June 2010, 245 . 247 Author's Address 249 Harlan Stenn 250 Network Time Foundation 251 P.O. Box 918 252 Talent, OR 97540 253 US 255 Email: stenn@nwtime.org