Movatterモバイル変換

Internet Engineering Task Force (IETF)                        T. MizrahiRequest for Comments: 7822                                       MarvellUpdates:5905                                                   D. MayerCategory: Standards Track                        Network Time FoundationISSN: 2070-1721                                               March 2016Network Time Protocol Version 4 (NTPv4) Extension FieldsAbstract   The Network Time Protocol version 4 (NTPv4) defines the optional   usage of extension fields.  An extension field, as defined inRFC5905, is an optional field that resides at the end of the NTP header   and that can be used to add optional capabilities or additional   information that is not conveyed in the standard NTP header.  This   document updatesRFC 5905 by clarifying some points regarding NTP   extension fields and their usage with Message Authentication Codes   (MACs).Status of This Memo   This is an Internet Standards Track document.   This document is a product of the Internet Engineering Task Force   (IETF).  It represents the consensus of the IETF community.  It has   received public review and has been approved for publication by the   Internet Engineering Steering Group (IESG).  Further information on   Internet Standards is available inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7822.Copyright Notice   Copyright (c) 2016 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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.Mizrahi & Mayer              Standards Track                    [Page 1]

RFC 7822                  NTP Extension Fields                March 2016Table of Contents1. Introduction ....................................................22. Conventions Used in This Document ...............................32.1. Terminology ................................................32.2. Terms and Abbreviations ....................................33. NTP Extension Fields -RFC 5905 Update ..........................34. Security Considerations .........................................65. References ......................................................75.1. Normative References .......................................75.2. Informative References .....................................7   Acknowledgments ....................................................8   Authors' Addresses .................................................81.  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 (MACs), and extension fields as   defined in Section 7.5 of [NTPv4].   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 [NTPv4] as a generic mechanism   that allows the addition of future extensions and features without   modifying the NTP header format (Section 16 of [NTPv4]).   The only currently defined extension fields are those fields used by   the Autokey protocol [Autokey] and the Checksum Complement [RFC7821].   The Autokey extension field is always followed by a MAC, and   Section 10 of [Autokey] 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.  This   behavior is specified in Section 7.5 of [NTPv4] and in [Err3627], and   is further clarified in this document.   This document updates [NTPv4] (RFC 5905) by clarifying some points   regarding the usage of extension fields.  These updates include   changes to address errors found after the publication of [NTPv4] with   respect to extension fields.  Specifically, this document updates   Section 7.5 of [NTPv4], clarifying the relationship between extension   fields and MACs, and defining the behavior of a host that receives an   unknown extension field.Mizrahi & Mayer              Standards Track                    [Page 2]

RFC 7822                  NTP Extension Fields                March 20162.  Conventions Used in This Document2.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 and Abbreviations   MAC          Message Authentication Code   NTPv4        Network Time Protocol version 4 [NTPv4]3.  NTP Extension Fields -RFC 5905 Update   This document updates Section 7.5 of [NTPv4] 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, which is always present when an      extension field 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.       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.Mizrahi & Mayer              Standards Track                    [Page 3]

RFC 7822                  NTP Extension Fields                March 2016      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.       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      values 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.Mizrahi & Mayer              Standards Track                    [Page 4]

RFC 7822                  NTP Extension Fields                March 2016   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 [Autokey].  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 the use of more than      one algorithm, in which case the information about which algorithm      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 the 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.      An NTP packet MUST NOT be sent with two or more extension fields      that require a MAC with different algorithms.      If an NTP packet is received with two or more extension fields      that this receiver recognizes and those fields 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 a longer MAC is agreed upon by both client      and server.  The client and server can negotiate this behavior      using a previous exchange of packets with an extension field that      defines the size and algorithm of the MAC transmitted in NTP      packets.Mizrahi & Mayer              Standards Track                    [Page 5]

RFC 7822                  NTP Extension Fields                March 2016   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 time protocols in general are   discussed in [SecTime], and the security considerations of NTP are   discussed in [NTPv4].   Distributed Denial-of-Service (DDoS) attacks on NTP servers involve   flooding a server with a high rate of NTP packets.  Malicious usage   of extension fields cannot amplify such DDoS attacks; such malicious   attempts are mitigated by NTP servers, since the servers ignore   unknown extension fields (as discussed inSection 3) and only   respond, if needed, with known extension fields.  Extension fields   from incoming packets are neither propagated by NTP servers nor   included in any response.  NTP servers create their own extension   fields if needed for a response.  A large number of extension fields   should be flagged by an NTP server as a potential attack.  Large   extension field sizes should also be flagged, unless they are   expected to be large.   Middleboxes such as firewalls MUST NOT filter NTP packets based on   their extension fields.  Such middleboxes should not examine   extension fields in the packets, since NTP packets may contain new   extension fields that the middleboxes have not been updated to   recognize.Mizrahi & Mayer              Standards Track                    [Page 6]

RFC 7822                  NTP Extension Fields                March 20165.  References5.1.  Normative References   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate               Requirement Levels",BCP 14,RFC 2119,               DOI 10.17487/RFC2119, March 1997,               <http://www.rfc-editor.org/info/rfc2119>.   [NTPv4]     Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,               "Network Time Protocol Version 4: Protocol and Algorithms               Specification",RFC 5905, DOI 10.17487/RFC5905,               June 2010, <http://www.rfc-editor.org/info/rfc5905>.5.2.  Informative References   [Autokey]   Haberman, B., Ed., and D. Mills, "Network Time Protocol               Version 4: Autokey Specification",RFC 5906,               DOI 10.17487/RFC5906, June 2010,               <http://www.rfc-editor.org/info/rfc5906>.   [Err3627]   RFC Errata, Erratum ID 3627,RFC 5905.   [RFC7821]   Mizrahi, T., "UDP Checksum Complement in the Network Time               Protocol (NTP)",RFC 7821, DOI 10.17487/RFC7821,               March 2016, <http://www.rfc-editor.org/info/rfc7821>.   [SecTime]   Mizrahi, T., "Security Requirements of Time Protocols in               Packet Switched Networks",RFC 7384,               DOI 10.17487/RFC7384, October 2014,               <http://www.rfc-editor.org/info/rfc7384>.Mizrahi & Mayer              Standards Track                    [Page 7]

RFC 7822                  NTP Extension Fields                March 2016Acknowledgments   The authors gratefully acknowledge Dave Mills for his insightful   comments.  The authors also thank Tim Chown, Sean Turner, Miroslav   Lichvar, Suresh Krishnan, and Jari Arkko for their thorough review   and helpful comments.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   United States   Email: mayer@ntp.orgMizrahi & Mayer              Standards Track                    [Page 8]