idnits 2.17.1 draft-ietf-ntp-extension-field-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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (December 25, 2014) is 3408 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) -- Duplicate reference: RFC5905, mentioned in 'RFC5905Err', was also mentioned in 'RFC5905'. -- Duplicate reference: RFC5906, mentioned in 'RFC5906ERR', was also mentioned in 'RFC5906'. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NTP Working Group T. Mizrahi 2 Internet Draft Marvell 3 Intended status: Standards Track D. Mayer 4 Updates: 5905 Network Time Foundation 5 Expires: June 2015 December 25, 2014 7 The Network Time Protocol Version 4 (NTPv4) Extension Fields 8 draft-ietf-ntp-extension-field-02.txt 10 Abstract 12 The Network Time Protocol Version 4 (NTPv4) defines the optional 13 usage of extension fields. An extension field, defined in RFC5905, is 14 an optional field that resides at the end of the NTP header, and can 15 be used to add optional capabilities or additional information that 16 is not conveyed in the standard NTP header. This document updates 17 RFC5905 by clarifying some points regarding NTP extension fields and 18 their usage with Message Authentication Codes (MAC). 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on June 25, 2015. 43 Copyright Notice 45 Copyright (c) 2014 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 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction ................................................. 2 61 2. Conventions Used in this Document ............................ 3 62 2.1. Terminology ............................................. 3 63 2.2. Terms & Abbreviations ................................... 3 64 3. NTP Extension Fields - RFC 5905 Update ....................... 3 65 4. Security Considerations ...................................... 6 66 5. IANA Considerations .......................................... 6 67 6. Acknowledgments .............................................. 6 68 7. References ................................................... 7 69 7.1. Normative References .................................... 7 70 7.2. Informative References .................................. 7 71 Appendix A. Requirements from NTPv4 and Autokey ................. 7 72 A.1. NTP Extension Field for Future Extensions ............... 7 73 A.2. NTP Extension Field with or without a MAC ............... 7 74 A.3. The NTP Extension Field Format .......................... 8 75 A.4. NTP Extension Field in Autokey .......................... 8 77 1. Introduction 79 The NTP header format consists of a set of fixed fields that may be 80 followed by some optional fields. Two types of optional fields are 81 defined, Message Authentication Codes (MAC), and extension fields 82 (Appendix A.3.). 84 If a MAC is used, it resides at the end of the packet. This field can 85 be either 24 octets long, 20 octets long, or a 4-octet crypto-NAK. 87 NTP extension fields were defined in [RFC5905] as a generic mechanism 88 that allows to add future extensions and features without modifying 89 the NTP header format (Appendix A.1.). 91 The only currently defined extension field is the one used by the 92 AutoKey protocol [RFC5906]. This extension field is always followed 93 by a MAC, and [RFC5906] specifies the parsing rules that allow a host 94 to distinguish between an extension field and a MAC (Appendix A.4.). 96 However, a MAC is not mandatory after an extension field; an NTPv4 97 packet can include one or more extension fields without including a 98 MAC (Appendix A.2.). 100 This document updates [RFC5905] by clarifying some points regarding 101 the usage of extension fields. Specifically, this document updates 102 Section 7.5 of [RFC5905], clarifying the relationship between 103 extension fields and MACs, and defining the behavior of a host that 104 receives an unknown extension field. 106 2. Conventions Used in this Document 108 2.1. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [KEYWORDS]. 114 2.2. Terms & Abbreviations 116 NTPv4 Network Time Protocol Version 4 [RFC5905] 118 MAC Message Authentication Code 120 3. NTP Extension Fields - RFC 5905 Update 122 This document updates Section 7.5 of [RFC5905] and [RFC5905Err] as 123 follows: 125 OLD: 127 7.5. NTP Extension Field Format 129 In NTPv4, one or more extension fields can be inserted after the 130 header and before the MAC, if a MAC is present. If a MAC is not 131 present, one or more extension fields can be inserted after the 132 header, according to the following rules: 134 o If the packet includes a single extension field, the length of the 135 extension field MUST be at least 7 words, i.e., at least 28 136 octets. 138 o If the packet includes more than one extension field, the length 139 of the last extension field MUST be at least 28 octets. The length 140 of the other extension fields in this case MUST be at least 16 141 octets each. 143 Other than defining the field format, this document makes no use of 144 the field contents. An extension field contains a request or 145 response message in the format shown in Figure 14. 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Field Type | Length | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 . . 153 . Value . 154 . . 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Padding (as needed) | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Figure 14: Extension Field Format 160 All extension fields are zero-padded to a word (four octets) 161 boundary. The Field Type field is specific to the defined function 162 and is not elaborated here. While the minimum field length 163 containing required fields is four words (16 octets), a maximum field 164 length remains to be established. 166 The Length field is a 16-bit unsigned integer that indicates the 167 length of the entire extension field in octets, including the Padding 168 field. 170 NEW: 172 7.5. NTP Extension Field Format 174 In NTPv4, one or more extension fields can be inserted after the 175 header and before the MAC, if a MAC is present. 177 Other than defining the field format, this document makes no use of 178 the field contents. An extension field contains a request or 179 response message in the format shown in Figure 14. 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Field Type | Length | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 . . 187 . Value . 188 . . 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Padding (as needed) | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 14: Extension Field Format 194 All extension fields are zero-padded to a word (four octets) 195 boundary. 197 The Field Type field is specific to the defined function and is not 198 elaborated here. If a host receives an extension field with an 199 unknown Field Type value, the host SHOULD ignore the extension field 200 and MAY drop the packet altogether if policy requires it. Note that 201 in the presence of an unknown extension field any MAC that may be 202 present may be misinterpreted as an unknown extension though in this 203 case the apparent extension length will be inconsistent with the 204 total length of the rest of the packet. 206 While the minimum field length containing required fields is four 207 words (16 octets), the maximum field length cannot be longer than 208 65532 octets due to the maximum size of the length field. 210 The Length field is a 16-bit unsigned integer that indicates the 211 length of the entire extension field in octets, including the Padding 212 field. 214 7.5.1 Extension Fields and MACs 216 7.5.1.1 Extension Fields in the Presence of a MAC 218 An extension field can be used in an NTP packet that includes a MAC, 219 for example, as defined in [RFC5906]. A specification that defines a 220 new extension field MUST specify whether the extension field requires 221 a MAC or not. If the extension field requires a MAC, the extension 222 field specification MUST define the algorithm to be used to create 223 the MAC and the length of the MAC thus created. An extension field 224 MAY allow for more than one algorithm to be used in which case the 225 information about which one was used MUST be included in the 226 extension field itself. 228 7.5.1.2 Multiple Extension Fields with a MAC 230 If there are multiple extension fields that require a MAC they MUST 231 all require use of the same algorithm and MAC length. Extension 232 fields that do not require a MAC can be included with extension 233 fields that do require a MAC. 235 7.5.1.3 MAC in the absence of an Extension field 237 A MAC MUST NOT be longer than 24 octets if there is no extension 238 field present unless through a previous exchange of packets with an 239 extension field which defines the size and algorithm of the MAC 240 transmitted in the packet and is agreed upon by both client and 241 server. 243 7.5.1.4 Extension Fields in the Absence of a MAC 245 If a MAC is not present, one or more extension fields can be inserted 246 after the header, according to the following rules: 248 o If the packet includes a single extension field, the length of the 249 extension field MUST be at least 7 words, i.e., at least 28 250 octets. 252 o If the packet includes more than one extension field, the length 253 of the last extension field MUST be at least 28 octets. The length 254 of the other extension fields in this case MUST be at least 16 255 octets each. 257 4. Security Considerations 259 The security considerations of the network time protocol are 260 discussed in [RFC5905]. This document clarifies some ambiguity with 261 regards to the usage of the NTP extension field, and thus the 262 behavior described in this document does not introduce new security 263 considerations. 265 5. IANA Considerations 267 There are no new IANA considerations implied by this document. 269 6. Acknowledgments 271 The authors thank Dave Mills for his insightful comments. 273 This document was prepared using 2-Word-v2.0.template.dot. 275 7. References 277 7.1. Normative References 279 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 [RFC5905] Mills, D., Martin, J., Burbank, J., Kasch, W., 283 "Network Time Protocol Version 4: Protocol and 284 Algorithms Specification", RFC 5905, June 2010. 286 [RFC5905Err] RFC 5905 Technical Erratum 3627, May 2014. 288 7.2. Informative References 290 [RFC5906] Haberman, B., Mills, D., "Network Time Protocol 291 Version 4: Autokey Specification", RFC 5906, June 292 2010. 294 [RFC5906ERR] RFC 5906 Technical Erratum 4026, July 2014.. 296 Appendix A. Requirements from NTPv4 and Autokey 298 A.1. NTP Extension Field for Future Extensions 300 The following paragraph is quoted from Section 16 of [RFC5905]. 302 This document introduces NTP extension fields allowing for the 303 development of future extensions to the protocol, where a particular 304 extension is to be identified by the Field Type sub-field within the 305 extension field. 307 A.2. NTP Extension Field with or without a MAC 309 The following paragraph is quoted from Section 7.5 of [RFC5905], as 310 updated by [RFC5905Err]. 312 In NTPv4, one or more extension fields can be inserted after the 313 header and before the MAC, if a MAC is present. If a MAC is not 314 present, one or more extension fields can be inserted after the 315 header, according to the following rules: 317 o If the packet includes a single extension field, the length of the 318 extension field MUST be at least 7 words, i.e., at least 28 319 octets. 321 o If the packet includes more than one extension field, the length 322 of the last extension field MUST be at least 28 octets. The length 323 of the other extension fields in this case MUST be at least 16 324 octets each. 326 A.3. The NTP Extension Field Format 328 The NTP extension field format, presented below, is quoted from 329 [RFC5905]. For further details refer to [RFC5905]. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Field Type | Length | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 . . 337 . Value . 338 . . 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Padding (as needed) | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 14: Extension Field Format 344 A.4. NTP Extension Field in Autokey 346 The following paragraph is quoted from Section 10 of [RFC5906], as 347 updated by [RFC5906ERR]. 349 One or more extension fields follow the NTP packet header and the 350 last followed by the MAC. The extension field parser initializes a 351 pointer to the first octet beyond the NTP packet header and 352 calculates the number of octets remaining to the end of the packet If 353 the remaining length is 20 (128-bit digest plus 4-octet key ID) or 24 354 (160-bit digest plus 4-octet key ID), the remaining data are the MAC 355 and parsing is complete. If the remaining length is greater than 24, 356 an extension field is present. If the remaining length is less than 357 8 or not a multiple of 4, a format error has occurred and the packet 358 is discarded; otherwise, the parser increments the pointer by the 359 extension field length and then uses the same rules as above to 360 determine whether a MAC is present or another extension field. 362 Authors' Addresses 364 Tal Mizrahi 365 Marvell 366 6 Hamada St. 367 Yokneam, 20692 Israel 369 Email: talmi@marvell.com 371 Danny Mayer 372 Network Time Foundation 373 PO Box 918 374 Talent OR 97540 376 Email: mayer@ntp.org