[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-mizrahi-ntp-extension-field) 00 01 02 03 04 05 06 07 RFC 7822

NTP Working Group                                             T. Mizrahi
Internet Draft                                                   Marvell
Intended status: Standards Track                                D. Mayer
Updates: 5905                                    Network Time Foundation
Expires: May 2016                                       November 1, 2015

       The Network Time Protocol Version 4 (NTPv4) Extension Fields
                   draft-ietf-ntp-extension-field-05.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 May 1, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors. All rights reserved.




Mizrahi, Mayer           Expires May 1, 2016                   [Page 1]


Internet-Draft           NTP Extension Field              November 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................................................7
   7. References.....................................................7
      7.1. Normative References......................................7
      7.2. Informative References....................................7

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, as
   defined in Section 7.5 of [RFC5905].

   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 (Section 16 of [RFC5905]).

   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 Section 10 of [RFC5906] specifies the parsing rules
   that allow a host to distinguish between an extension field and a
   MAC. However, a MAC is not mandatory after an extension field; an
   NTPv4 packet can include one or more extension fields without
   including a MAC (Section 7.5 of [RFC5905]).




Mizrahi, Mayer           Expires May 1, 2016                   [Page 2]


Internet-Draft           NTP Extension Field              November 2015


   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] 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.

   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.




Mizrahi, Mayer           Expires May 1, 2016                   [Page 3]


Internet-Draft           NTP Extension Field              November 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.  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 May 1, 2016                   [Page 4]


Internet-Draft           NTP Extension Field              November 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, Value, and Padding fields are specific to the defined
   function and are not elaborated here; the Field Type value is defined
   in an IANA registry and its Length, Value and Padding are defined by
   the document referred to by the registry. If a host receives an
   extension field with an unknown Field Type, the host SHOULD ignore
   the extension field and MAY drop the packet altogether if policy
   requires it.

   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
   information about which one was used MUST be included in the
   extension field itself.


Mizrahi, Mayer           Expires May 1, 2016                   [Page 5]


Internet-Draft           NTP Extension Field              November 2015


   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.

   If an NTP packet is received with two or more extension fields that
   require a MAC with different algorithms, the packet MUST be
   discarded.

   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.





Mizrahi, Mayer           Expires May 1, 2016                   [Page 6]


Internet-Draft           NTP Extension Field              November 2015


6. Acknowledgments

   The authors thank Dave Mills for his insightful comments.

   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.

7.2. Informative References

   [RFC5906]     Haberman, B., Mills, D., "Network Time Protocol
                 Version 4: Autokey Specification", RFC 5906, June
                 2010.

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 May 1, 2016                   [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/