NTP Working Group T. Mizrahi Internet Draft Marvell Intended status: Standards Track D. Mayer Updates: 5905 Network Time Foundation Expires: December 2015 June 29, 2015 The Network Time Protocol Version 4 (NTPv4) Extension Fields draft-ietf-ntp-extension-field-03.txt Abstract The Network Time Protocol Version 4 (NTPv4) defines the optional usage of extension fields. An extension field, defined in RFC5905, is an optional field that resides at the end of the NTP header, and can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document updates RFC5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes (MAC). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 29, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Mizrahi, Mayer Expires December 29, 2015 [Page 1] Internet-Draft NTP Extension Field June 2015 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................. 2 2. Conventions Used in this Document ............................ 3 2.1. Terminology ............................................. 3 2.2. Terms & Abbreviations ................................... 3 3. NTP Extension Fields - RFC 5905 Update ....................... 3 4. Security Considerations ...................................... 6 5. IANA Considerations .......................................... 6 6. Acknowledgments .............................................. 6 7. References ................................................... 7 7.1. Normative References .................................... 7 7.2. Informative References .................................. 7 Appendix A. Requirements from NTPv4 and Autokey ................. 7 A.1. NTP Extension Field for Future Extensions ............... 7 A.2. NTP Extension Field with or without a MAC ............... 7 A.3. The NTP Extension Field Format .......................... 8 A.4. NTP Extension Field in Autokey .......................... 8 1. Introduction The NTP header format consists of a set of fixed fields that may be followed by some optional fields. Two types of optional fields are defined, Message Authentication Codes (MAC), and extension fields (Appendix A.3.). If a MAC is used, it resides at the end of the packet. This field can be either 24 octets long, 20 octets long, or a 4-octet crypto-NAK. NTP extension fields were defined in [RFC5905] as a generic mechanism that allows to add future extensions and features without modifying the NTP header format (Appendix A.1.). The only currently defined extension field is the one used by the AutoKey protocol [RFC5906]. This extension field is always followed by a MAC, and [RFC5906] specifies the parsing rules that allow a host to distinguish between an extension field and a MAC (Appendix A.4.). Mizrahi, Mayer Expires December 29, 2015 [Page 2] Internet-Draft NTP Extension Field June 2015 However, a MAC is not mandatory after an extension field; an NTPv4 packet can include one or more extension fields without including a MAC (Appendix A.2.). This document updates [RFC5905] by clarifying some points regarding the usage of extension fields. Specifically, this document updates Section 7.5 of [RFC5905], clarifying the relationship between extension fields and MACs, and defining the behavior of a host that receives an unknown extension field. 2. Conventions Used in this Document 2.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. 2.2. Terms & Abbreviations NTPv4 Network Time Protocol Version 4 [RFC5905] MAC Message Authentication Code 3. NTP Extension Fields - RFC 5905 Update This document updates Section 7.5 of [RFC5905] and [RFC5905Err] as follows: OLD: 7.5. NTP Extension Field Format In NTPv4, one or more extension fields can be inserted after the header and before the MAC, if a MAC is present. If a MAC is not present, one or more extension fields can be inserted after the header, according to the following rules: o If the packet includes a single extension field, the length of the extension field MUST be at least 7 words, i.e., at least 28 octets. Mizrahi, Mayer Expires December 29, 2015 [Page 3] Internet-Draft NTP Extension Field June 2015 o If the packet includes more than one extension field, the length of the last extension field MUST be at least 28 octets. The length of the other extension fields in this case MUST be at least 16 octets each. Other than defining the field format, this document makes no use of the field contents. An extension field contains a request or response message in the format shown in Figure 14. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Value . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (as needed) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Extension Field Format All extension fields are zero-padded to a word (four octets) boundary. The Field Type field is specific to the defined function and is not elaborated here. While the minimum field length containing required fields is four words (16 octets), a maximum field length remains to be established. The Length field is a 16-bit unsigned integer that indicates the length of the entire extension field in octets, including the Padding field. NEW: 7.5. NTP Extension Field Format In NTPv4, one or more extension fields can be inserted after the header and before the MAC, if a MAC is present. Other than defining the field format, this document makes no use of the field contents. An extension field contains a request or response message in the format shown in Figure 14. Mizrahi, Mayer Expires December 29, 2015 [Page 4] Internet-Draft NTP Extension Field June 2015 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Value . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (as needed) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Extension Field Format All extension fields are zero-padded to a word (four octets) boundary. The Field Type field is specific to the defined function and is not elaborated here. If a host receives an extension field with an unknown Field Type value, the host SHOULD ignore the extension field and MAY drop the packet altogether if policy requires it. Note that in the presence of an unknown extension field any MAC that may be present may be misinterpreted as an unknown extension though in this case the apparent extension length will be inconsistent with the total length of the rest of the packet. While the minimum field length containing required fields is four words (16 octets), the maximum field length cannot be longer than 65532 octets due to the maximum size of the length field. The Length field is a 16-bit unsigned integer that indicates the length of the entire extension field in octets, including the Padding field. 7.5.1 Extension Fields and MACs 7.5.1.1 Extension Fields in the Presence of a MAC An extension field can be used in an NTP packet that includes a MAC, for example, as defined in [RFC5906]. A specification that defines a new extension field MUST specify whether the extension field requires a MAC or not. If the extension field requires a MAC, the extension field specification MUST define the algorithm to be used to create the MAC and the length of the MAC thus created. An extension field MAY allow for more than one algorithm to be used in which case the Mizrahi, Mayer Expires December 29, 2015 [Page 5] Internet-Draft NTP Extension Field June 2015 information about which one was used MUST be included in the extension field itself. 7.5.1.2 Multiple Extension Fields with a MAC If there are multiple extension fields that require a MAC they MUST all require use of the same algorithm and MAC length. Extension fields that do not require a MAC can be included with extension fields that do require a MAC. 7.5.1.3 MAC in the absence of an Extension field A MAC MUST NOT be longer than 24 octets if there is no extension field present unless through a previous exchange of packets with an extension field which defines the size and algorithm of the MAC transmitted in the packet and is agreed upon by both client and server. 7.5.1.4 Extension Fields in the Absence of a MAC If a MAC is not present, one or more extension fields can be inserted after the header, according to the following rules: o If the packet includes a single extension field, the length of the extension field MUST be at least 7 words, i.e., at least 28 octets. o If the packet includes more than one extension field, the length of the last extension field MUST be at least 28 octets. The length of the other extension fields in this case MUST be at least 16 octets each. 4. Security Considerations The security considerations of the network time protocol are discussed in [RFC5905]. This document clarifies some ambiguity with regards to the usage of the NTP extension field, and thus the behavior described in this document does not introduce new security considerations. 5. IANA Considerations There are no new IANA considerations implied by this document. 6. Acknowledgments The authors thank Dave Mills for his insightful comments. Mizrahi, Mayer Expires December 29, 2015 [Page 6] Internet-Draft NTP Extension Field June 2015 This document was prepared using 2-Word-v2.0.template.dot. 7. References 7.1. Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5905] Mills, D., Martin, J., Burbank, J., Kasch, W., "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC5905Err] RFC 5905 Technical Erratum 3627, May 2014. 7.2. Informative References [RFC5906] Haberman, B., Mills, D., "Network Time Protocol Version 4: Autokey Specification", RFC 5906, June 2010. [RFC5906ERR] RFC 5906 Technical Erratum 4026, July 2014.. Appendix A. Requirements from NTPv4 and Autokey A.1. NTP Extension Field for Future Extensions The following paragraph is quoted from Section 16 of [RFC5905]. This document introduces NTP extension fields allowing for the development of future extensions to the protocol, where a particular extension is to be identified by the Field Type sub-field within the extension field. A.2. NTP Extension Field with or without a MAC The following paragraph is quoted from Section 7.5 of [RFC5905], as updated by [RFC5905Err]. In NTPv4, one or more extension fields can be inserted after the header and before the MAC, if a MAC is present. If a MAC is not present, one or more extension fields can be inserted after the header, according to the following rules: Mizrahi, Mayer Expires December 29, 2015 [Page 7] Internet-Draft NTP Extension Field June 2015 o If the packet includes a single extension field, the length of the extension field MUST be at least 7 words, i.e., at least 28 octets. o If the packet includes more than one extension field, the length of the last extension field MUST be at least 28 octets. The length of the other extension fields in this case MUST be at least 16 octets each. A.3. The NTP Extension Field Format The NTP extension field format, presented below, is quoted from [RFC5905]. For further details refer to [RFC5905]. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Value . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (as needed) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Extension Field Format A.4. NTP Extension Field in Autokey The following paragraph is quoted from Section 10 of [RFC5906], as updated by [RFC5906ERR]. One or more extension fields follow the NTP packet header and the last followed by the MAC. The extension field parser initializes a pointer to the first octet beyond the NTP packet header and calculates the number of octets remaining to the end of the packet If the remaining length is 20 (128-bit digest plus 4-octet key ID) or 24 (160-bit digest plus 4-octet key ID), the remaining data are the MAC and parsing is complete. If the remaining length is greater than 24, an extension field is present. If the remaining length is less than 8 or not a multiple of 4, a format error has occurred and the packet is discarded; otherwise, the parser increments the pointer by the extension field length and then uses the same rules as above to determine whether a MAC is present or another extension field. Mizrahi, Mayer Expires December 29, 2015 [Page 8] Internet-Draft NTP Extension Field June 2015 Authors' Addresses Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel Email: talmi@marvell.com Danny Mayer Network Time Foundation PO Box 918 Talent OR 97540 Email: mayer@ntp.org Mizrahi, Mayer Expires December 29, 2015 [Page 9]