idnits 2.17.1 draft-mlichvar-ntp-short-extension-fields-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. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 25, 2019) is 1828 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Lichvar 3 Internet-Draft Red Hat 4 Updates: RFC7822 (if approved) April 25, 2019 5 Intended status: Standards Track 6 Expires: October 27, 2019 8 NTPv4 Short Extension Fields 9 draft-mlichvar-ntp-short-extension-fields-01 11 Abstract 13 This document specifies a new packet format for the Network Time 14 Protocol version 4 (NTPv4) which is compatible with RFC 7822, but 15 allows NTPv4 packets to contain shorter extension fields. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 27, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 RFC 7822 [RFC7822] specifies a minimum length of extension fields in 52 NTPv4 packets in order to prevent ambiguities in their parsing. 53 Without these rules, an extension field in a valid NTPv4 packet could 54 be parsed as a Message Authentication Code (MAC), or a MAC could be 55 parsed as an extension field. 57 The minimum length of 28 octets forces extension fields that do not 58 contain enough data to reach the minimum length to waste space. With 59 multiple extension fields in a packet the wasted space accumulates. 61 A different issue with extension fields in NTPv4 packets is that 62 servers/clients cannot pad a response/request to a specific length, 63 e.g. to make their length symmetric when they contain different 64 extension fields, or the sums of their lengths are different, unless 65 one of the extension fields included in the request/response supports 66 padding. 68 This document specifies a new NTPv4 format using three new extension 69 fields: 71 1. An extension field which contains other extension fields with no 72 requirements on minimum length 74 2. An extension field which does not contain any information and can 75 always be used for padding 77 3. An extension field which contains MAC 79 Together, these extension fields allow NTPv4 packets to contain short 80 extension fields, minimize the wasted space, and allow the packets to 81 be padded to any length that meets the requirements of RFC 7822. 83 Older NTP implementations which follow RFC 7822 will parse a packet 84 in the new format as a valid packet which contains a single unknown 85 extension field, skipping all extension fields and/or MAC, and can 86 respond as appropriate. 88 An implementation which supports the new format will parse all 89 extension fields and/or MAC contained in the packet. 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. New extension fields 99 2.1. Packing Field 101 The Packing Field is an NTP extension field following RFC 7822 102 [RFC7822], which contains one or more other extension fields. The 103 format of the extension field is shown below. 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Field Type | Length | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Subfield 1 Type | Subfield 1 Length | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 . . 113 . Subfield 1 Data . 114 . . 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 . . 117 . . 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Subfield N Type | Subfield N Length | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 . . 122 . Subfield N Data . 123 . . 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 Figure 1: Format of Packing Field 128 The extension field has the following fields: 130 Field Type 131 The type which identifies the Packing Field. TBD 133 Length 134 The length of the extension field, which is at least 28 135 octets. 137 Subfield 1..N Type 138 The types of the contained extension fields. 140 Subfield 1..N Length 141 The lengths of the contained extension field, which are 142 divisible by 4 and can be smaller than 28. 144 Subfield 1..N Data 145 Data specific to the included extension fields. 147 2.2. Padding Field 149 The Padding Field is an NTP extension field which does not contain 150 any useful data. It does not follow the requirements from RFC 7822 151 [RFC7822] and it MUST be contained in the Packing Field. 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Field Type | Length | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 . . 159 . Padding . 160 . . 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 2: Format of Padding Field 165 The extension field has the following fields: 167 Field Type 168 The type which identifies the Padding Field. TBD 170 Length 171 The length of the extension field. 173 Padding 174 Octets filling the space of the extension field with any 175 value. 177 2.3. MAC Field 179 The MAC Field is an NTP extension field which contains a MAC as 180 specified in RFC 5905 [RFC5905]. It does not follow the requirements 181 from RFC 7822 [RFC7822] and it MUST be contained in the Packing 182 Field. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Field Type | Length | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Key Identifier | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 . . 192 . Message Digest . 193 . . 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 3: Format of MAC Field 198 The extension field has the following fields: 200 Field Type 201 The type which identifies the MAC Field. TBD 203 Length 204 The length of the extension field. 206 Key Identifier 207 The ID of the key which is used for calculating the digest. 209 Message Digest 210 Digest calculated over all UDP data before the Key 211 Identifier, including the length of the MAC Field and Packing 212 field. 214 3. New NTPv4 format 216 An NTPv4 packet in the new format consists of: 218 1. NTPv4 header per RFC 5905 [RFC5905](48 octets) 220 2. Field Type of the Packing Field (2 octets) 222 3. Length of all data following the NTP header (2 octets) 224 4. Extension fields with no restrictions on their minimum length, 225 optionally including the Padding and/or MAC Fields (at least 24 226 octets) 228 The packet MUST have exactly one Packing Field and it MUST contain 229 all other extension fields. The packet MUST NOT have a MAC outside 230 the Packing Field. If there is not enough data to reach the minimum 231 length of 28 octets, the Packing Field MUST include at least one 232 Padding Field to increase the length of the Packing Field. 234 4. Parsing of NTPv4 packets 236 An implementation SHOULD check if the following applies to the UDP 237 data before parsing it as an NTPv4 packet in the new format: 239 1. NTP version (in the first octet) is 4. 241 2. NTP mode (in the first octet) is 1, 2, 3, 4, or 5. 243 3. Length is at least 76 octets. 245 4. 49th and 50th octets contain the type of the Packing Field. 247 5. 51st and 52nd octets contain a value that is equal to the length 248 of the UDP data minus 48. 250 5. IANA Considerations 252 IANA is requested to allocate Extension Field Types for the Packing, 253 Padding, and MAC Extension Fields. 255 6. Normative References 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, 259 DOI 10.17487/RFC2119, March 1997, 260 . 262 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 263 "Network Time Protocol Version 4: Protocol and Algorithms 264 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 265 . 267 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 268 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 269 March 2016, . 271 Author's Address 272 Miroslav Lichvar 273 Red Hat 274 Purkynova 115 275 Brno 612 00 276 Czech Republic 278 Email: mlichvar@redhat.com