NTPv4 Short Extension Fields
draft-mlichvar-ntp-short-extension-fields-00

Document Type Active Internet-Draft (individual)
Last updated 2018-09-26
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                               M. Lichvar
Internet-Draft                                                   Red Hat
Updates: RFC7822 (if approved)                        September 26, 2018
Intended status: Standards Track
Expires: March 30, 2019

                      NTPv4 Short Extension Fields
              draft-mlichvar-ntp-short-extension-fields-00

Abstract

   This document specifies a new packet format for the Network Time
   Protocol version 4 (NTPv4) which is compatible with RFC 7822, but
   allows NTPv4 packets to contain shorter extension fields.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 30, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (https://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.

Lichvar                  Expires March 30, 2019                 [Page 1]
Internet-Draft        NTPv4 Short Extension Fields        September 2018

1.  Introduction

   RFC 7822 [RFC7822] specifies a minimum length of extension fields in
   NTPv4 packets in order to prevent ambiguities in their parsing.
   Without these rules, an extension field in a valid NTPv4 packet could
   be parsed as a Message Authentication Code (MAC), or a MAC could be
   parsed as an extension field.

   The minimum length of 28 octets forces extension fields that do not
   contain enough data to reach the minimum length to waste space.  With
   multiple extension fields in a packet the wasted space accumulates.

   A different issue with extension fields in NTPv4 packets is that
   servers/clients cannot pad a response/request to a specific length,
   e.g. to make their length symmetric when they contain different
   extension fields, or the sums of their lengths are different, unless
   one of the extension fields included in the request/response supports
   padding.

   This document specifies a new NTPv4 format using three new extension
   fields:

   1.  An extension field which contains other extension fields with no
       requirements on minimum length

   2.  An extension field which does not contain any information and can
       always be used for padding

   3.  An extension field which contains MAC

   Together, these extension fields allow NTPv4 packets to contain short
   extension fields, minimize the wasted space, and allow the packets to
   be padded to any length that meets the requirements of RFC 7822.

   Older NTP implementations which follow RFC 7822 will parse a packet
   in the new format as a valid packet which contains a single unknown
   extension field, skipping all extension fields and/or MAC, and can
   respond as appropriate.

   An implementation which supports the new format will parse all
   extension fields and/or MAC contained in the packet.

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].

Lichvar                  Expires March 30, 2019                 [Page 2]
Internet-Draft        NTPv4 Short Extension Fields        September 2018

2.  New extension fields

2.1.  Packing Field

   The Packing Field is an NTP extension field following RFC 7822
   [RFC7822], which contains one or more other extension fields.  The
   format of the extension field is shown below.

    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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Subfield 1 Type         |        Subfield 1 Length      |
Show full document text