idnits 2.17.1 draft-ietf-ntp-extension-field-06.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 (November 26, 2015) is 3045 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: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: May 2016 November 26, 2015 7 The Network Time Protocol Version 4 (NTPv4) Extension Fields 8 draft-ietf-ntp-extension-field-06.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 May 26, 2016. 43 Copyright Notice 45 Copyright (c) 2015 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............................................7 67 6. Acknowledgments................................................7 68 7. References.....................................................7 69 7.1. Normative References......................................7 70 7.2. Informative References....................................7 72 1. Introduction 74 The NTP header format consists of a set of fixed fields that may be 75 followed by some optional fields. Two types of optional fields are 76 defined, Message Authentication Codes (MAC), and extension fields, as 77 defined in Section 7.5 of [RFC5905]. 79 If a MAC is used, it resides at the end of the packet. This field can 80 be either 24 octets long, 20 octets long, or a 4-octet crypto-NAK. 82 NTP extension fields were defined in [RFC5905] as a generic mechanism 83 that allows to add future extensions and features without modifying 84 the NTP header format (Section 16 of [RFC5905]). 86 The only currently defined extension fields are the ones used by the 87 AutoKey protocol [RFC5906], and the Checksum Complement [NTPComp]. 88 The AutoKey extension field is always followed by a MAC, and Section 89 10 of [RFC5906] specifies the parsing rules that allow a host to 90 distinguish between an extension field and a MAC. However, a MAC is 91 not mandatory after an extension field; an NTPv4 packet can include 92 one or more extension fields without including a MAC (Section 7.5 of 93 [RFC5905]). 95 This document updates [RFC5905] by clarifying some points regarding 96 the usage of extension fields. Specifically, this document updates 97 Section 7.5 of [RFC5905], clarifying the relationship between 98 extension fields and MACs, and defining the behavior of a host that 99 receives an unknown extension field. 101 2. Conventions Used in this Document 103 2.1. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [KEYWORDS]. 109 2.2. Terms & Abbreviations 111 NTPv4 Network Time Protocol Version 4 [RFC5905] 113 MAC Message Authentication Code 115 3. NTP Extension Fields - RFC 5905 Update 117 This document updates Section 7.5 of [RFC5905] as follows: 119 OLD: 121 7.5. NTP Extension Field Format 123 In NTPv4, one or more extension fields can be inserted after the 124 header and before the MAC, if a MAC is present. If a MAC is not 125 present, one or more extension fields can be inserted after the 126 header, according to the following rules: 128 o If the packet includes a single extension field, the length of the 129 extension field MUST be at least 7 words, i.e., at least 28 130 octets. 132 o If the packet includes more than one extension field, the length 133 of the last extension field MUST be at least 28 octets. The length 134 of the other extension fields in this case MUST be at least 16 135 octets each. 137 Other than defining the field format, this document makes no use of 138 the field contents. An extension field contains a request or 139 response message in the format shown in Figure 14. 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Field Type | Length | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 . . 147 . Value . 148 . . 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Padding (as needed) | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 14: Extension Field Format 154 All extension fields are zero-padded to a word (four octets) 155 boundary. The Field Type field is specific to the defined function 156 and is not elaborated here. While the minimum field length 157 containing required fields is four words (16 octets), a maximum field 158 length remains to be established. 160 The Length field is a 16-bit unsigned integer that indicates the 161 length of the entire extension field in octets, including the Padding 162 field. 164 NEW: 166 7.5. NTP Extension Field Format 168 In NTPv4, one or more extension fields can be inserted after the 169 header and before the MAC, if a MAC is present. 171 Other than defining the field format, this document makes no use of 172 the field contents. An extension field contains a request or 173 response message in the format shown in Figure 14. 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Field Type | Length | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 . . 181 . Value . 182 . . 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Padding (as needed) | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Figure 14: Extension Field Format 188 All extension fields are zero-padded to a word (four octets) 189 boundary. 191 The Field Type, Value, and Padding fields are specific to the defined 192 function and are not elaborated here; the Field Type value is defined 193 in an IANA registry and its Length, Value and Padding are defined by 194 the document referred to by the registry. If a host receives an 195 extension field with an unknown Field Type, the host SHOULD ignore 196 the extension field and MAY drop the packet altogether if policy 197 requires it. 199 While the minimum field length containing required fields is four 200 words (16 octets), the maximum field length cannot be longer than 201 65532 octets due to the maximum size of the length field. 203 The Length field is a 16-bit unsigned integer that indicates the 204 length of the entire extension field in octets, including the Padding 205 field. 207 7.5.1 Extension Fields and MACs 209 7.5.1.1 Extension Fields in the Presence of a MAC 211 An extension field can be used in an NTP packet that includes a MAC, 212 for example, as defined in [RFC5906]. A specification that defines a 213 new extension field MUST specify whether the extension field requires 214 a MAC or not. If the extension field requires a MAC, the extension 215 field specification MUST define the algorithm to be used to create 216 the MAC and the length of the MAC thus created. An extension field 217 MAY allow for more than one algorithm to be used in which case the 218 information about which one was used MUST be included in the 219 extension field itself. 221 7.5.1.2 Multiple Extension Fields with a MAC 223 If there are multiple extension fields that require a MAC they MUST 224 all require use of the same algorithm and MAC length. Extension 225 fields that do not require a MAC can be included with extension 226 fields that do require a MAC. 228 If an NTP packet is received with two or more extension fields that 229 require a MAC with different algorithms, the packet MUST be 230 discarded. 232 7.5.1.3 MAC in the absence of an Extension field 234 A MAC MUST NOT be longer than 24 octets if there is no extension 235 field present unless through a previous exchange of packets with an 236 extension field which defines the size and algorithm of the MAC 237 transmitted in the packet and is agreed upon by both client and 238 server. 240 7.5.1.4 Extension Fields in the Absence of a MAC 242 If a MAC is not present, one or more extension fields can be inserted 243 after the header, according to the following rules: 245 o If the packet includes a single extension field, the length of the 246 extension field MUST be at least 7 words, i.e., at least 28 247 octets. 249 o If the packet includes more than one extension field, the length 250 of the last extension field MUST be at least 28 octets. The length 251 of the other extension fields in this case MUST be at least 16 252 octets each. 254 4. Security Considerations 256 The security considerations of time protocols in general are 257 discussed in [RFC7384], and the security considerations of NTP are 258 discussed in [RFC5905]. 260 Distributed Denial-of-Service (DDoS) attacks on NTP servers involve 261 flooding a server with a high rate of NTP packets. Malicious usage of 262 extension fields cannot amplify such DDoS attacks; such malicious 263 attempts are mitigated by NTP servers, since the servers ignore 264 unknown extension fields (as discussed in Section 3.), and only 265 respond, if needed, with known extension fields. Extension fields 266 from incoming packets are neither propagated by NTP servers nor 267 included in any response. NTP servers create their own extension 268 fields if needed for a response. A large number of extension fields 269 should be flagged by an NTP server as a potential attack. Large 270 extension field sizes should also be flagged unless they are expected 271 to be large. 273 Middleboxes such as firewalls MUST NOT filter NTP packets based on 274 their extension fields. Such middleboxes should not examine extension 275 fields in the packets since NTP packets may contain new extension 276 fields that the middleboxes have not been updated to recognize. 278 5. IANA Considerations 280 There are no new IANA considerations implied by this document. 282 6. Acknowledgments 284 The authors thank Dave Mills for his insightful comments. 286 This document was prepared using 2-Word-v2.0.template.dot. 288 7. References 290 7.1. Normative References 292 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC5905] Mills, D., Martin, J., Burbank, J., Kasch, W., 296 "Network Time Protocol Version 4: Protocol and 297 Algorithms Specification", RFC 5905, June 2010. 299 7.2. Informative References 301 [RFC5906] Haberman, B., Mills, D., "Network Time Protocol 302 Version 4: Autokey Specification", RFC 5906, June 303 2010. 305 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols 306 in Packet Switched Networks", RFC 7384, October 2014. 308 [NTPComp] Mizrahi, T., "UDP Checksum Complement in the Network 309 Time Protocol (NTP)", draft-ietf-ntp-checksum-trailer 310 (work in progress), October 2015. 312 Authors' Addresses 314 Tal Mizrahi 315 Marvell 316 6 Hamada St. 317 Yokneam, 20692 Israel 319 Email: talmi@marvell.com 321 Danny Mayer 322 Network Time Foundation 323 PO Box 918 324 Talent OR 97540 326 Email: mayer@ntp.org