INTERNET-DRAFT V. Choudhary Intended Status: Standards Track A. Kumar Updates: 5905 Huawei Technologies India U. Windl Universitaet Regensburg Expires: December 5, 2015 June 3, 2015 The Network Time Protocol Version 4 Extension Format draft-choudharykumar-ntp-ntpv4-extended-extensions-01 Abstract The Network Time Protocol Version 4 (NTPv4) defines the optional usage of extension fields. An extension field as defined in RFC 5905, 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 redefines NTP extension header proposed in RFC 5905 for addressing unnecessary padding issue which is required for differentiating between NTP extension and MAC data. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Vikram & Anil Expires December 5, 2015 [Page 1] INTERNET DRAFT NTPv4 Extension Format June 3, 2015 Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terms & Abbreviations . . . . . . . . . . . . . . . . . . . 3 2. NTPv4 Extension Format . . . . . . . . . . . . . . . . . . . . 4 2.1 NTPv4 extension header format. . . . . . . . . . . . . . . . 4 2.2. Rules for new extensions. . . . . . . . . . . . . . . . . . 4 2.3. Ensuring backward compatibility. . . . . . . . . . . . . . 5 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Normative References . . . . . . . . . . . . . . . . . . . 6 5.2 Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Vikram & Anil Expires December 5, 2015 [Page 2] INTERNET DRAFT NTPv4 Extension Format June 3, 2015 1 Introduction 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. 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. This document updates RFC5905 by redefining legacy NTP extension header format which will help in reducing NTP packet size and ensures network bandwidth is not wasted just by adding unnecessary padding as mentioned above. All the new extensions MUST follow the proposed NTP extension header format. 1.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]. 1.2 Terms & Abbreviations NTPv4 Network Time Protocol Version 4 [RFC5905] MAC Message Authentication Code Vikram & Anil Expires December 5, 2015 [Page 3] INTERNET DRAFT NTPv4 Extension Format June 3, 2015 2. NTPv4 Extension Format 2.1 NTPv4 extension header format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| Field Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Value . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (as needed) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M-Bit : 1 - More extensions to be followed 0 - No more extensions o. Removes size restriction for all extension fields o. Removal of padding saves network bandwidth o. Backward compatibility is ensured Note: The proposed solution doesn't help in addressing legacy size constrains for NTP auto key extensions. 2.2. Rules for new extensions. New NTPv4 extensions MUST follow below rules : o. Autokey extension/s MUST be continuous and SHOULD start after NTP header. Proposed M-BIT solution cannot be used for Autokey extension as the MSB (most significant bit) of Autokey Field type is already used for indicating response messages. If the Autokey extensions are used in the middle then it won't be possible to indicate whether more/none extensions are following the current extension or not. Thus Autokey extensions MUST be the first extension after NTP header and SHOULD be processed as per the guideline defined by RFC 5906 [RFC5906]. o. First extension following NTP header MUST be at least 28 octets. This is required for handling legacy MAC issue. o. First extension following utokey extension MUST be at least 28 octets. Vikram & Anil Expires December 5, 2015 [Page 4] INTERNET DRAFT NTPv4 Extension Format June 3, 2015 2.3. Ensuring backward compatibility. a. NTP packet with no extension/s and MAC. This is simple as the packet size will be just equal to NTP header size. No special processing required. b. NTP packet with MAC only. NTP packet size as defined in RFC 5905 will be considered for MAC processing. c. NTP packet with Autokey extension/s and with/without MAC. Autokey extension's are the only defined NTP extension's so current size limitation and processing will remain as defined in RFC 5905 and 5906. Vikram & Anil Expires December 5, 2015 [Page 5] INTERNET DRAFT NTPv4 Extension Format June 3, 2015 3 Security Considerations The security considerations of the network time protocol are discussed in [RFC5905]. This document extends current available extension format for the usage of the NTP extension field, and thus the described in this document does not introduce new security considerations. 4 IANA Considerations There are no new IANA considerations implied by this document. Field type value for new extensions should consider M-BIT while requesting IANA. Example: If a new extension has field type value 0x0009 then it must request following values to be reserved by IANA. 0x0009 New extension field type (Without M-BIT) 0x8009 New extension field type (With M-BIT) 5 References 5.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. 5.2 Informative References [RFC5906] Haberman, B., Mills, D., "Network Time Protocol Version 4: Autokey Specification", RFC 5906, June 2010. Vikram & Anil Expires December 5, 2015 [Page 6] INTERNET DRAFT NTPv4 Extension Format June 3, 2015 Authors' Addresses Vikram Choudhary Huawei Technologies India Pvt. Ltd, Divyashree Techno Park, Whitefield, Bangalore, Karnataka 560037, India Email: vikram.choudhary@huawei.com Anil Kumar S N Huawei Technologies India Pvt. Ltd, Divyashree Techno Park, Whitefield, Bangalore, Karnataka 560037, India Email: anil.sn@huawei.com Ulrich Windl Universitaet Regensburg, Klinikum EMail: ulrich.windl@rz.uni-regensburg.de Vikram & Anil Expires December 5, 2015 [Page 7]