Internet DRAFT - draft-mlichvar-ntp-short-extension-fields
draft-mlichvar-ntp-short-extension-fields
Internet Engineering Task Force M. Lichvar
Internet-Draft Red Hat
Updates: RFC7822 (if approved) April 25, 2019
Intended status: Standards Track
Expires: October 27, 2019
NTPv4 Short Extension Fields
draft-mlichvar-ntp-short-extension-fields-01
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 October 27, 2019.
Copyright Notice
Copyright (c) 2019 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 October 27, 2019 [Page 1]
Internet-Draft NTPv4 Short Extension Fields April 2019
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 October 27, 2019 [Page 2]
Internet-Draft NTPv4 Short Extension Fields April 2019
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Subfield 1 Data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subfield N Type | Subfield N Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Subfield N Data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of Packing Field
The extension field has the following fields:
Field Type
The type which identifies the Packing Field. TBD
Length
The length of the extension field, which is at least 28
octets.
Subfield 1..N Type
The types of the contained extension fields.
Subfield 1..N Length
The lengths of the contained extension field, which are
divisible by 4 and can be smaller than 28.
Subfield 1..N Data
Lichvar Expires October 27, 2019 [Page 3]
Internet-Draft NTPv4 Short Extension Fields April 2019
Data specific to the included extension fields.
2.2. Padding Field
The Padding Field is an NTP extension field which does not contain
any useful data. It does not follow the requirements from RFC 7822
[RFC7822] and it MUST be contained in the Packing Field.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Padding .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of Padding Field
The extension field has the following fields:
Field Type
The type which identifies the Padding Field. TBD
Length
The length of the extension field.
Padding
Octets filling the space of the extension field with any
value.
2.3. MAC Field
The MAC Field is an NTP extension field which contains a MAC as
specified in RFC 5905 [RFC5905]. It does not follow the requirements
from RFC 7822 [RFC7822] and it MUST be contained in the Packing
Field.
Lichvar Expires October 27, 2019 [Page 4]
Internet-Draft NTPv4 Short Extension Fields April 2019
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Message Digest .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of MAC Field
The extension field has the following fields:
Field Type
The type which identifies the MAC Field. TBD
Length
The length of the extension field.
Key Identifier
The ID of the key which is used for calculating the digest.
Message Digest
Digest calculated over all UDP data before the Key
Identifier, including the length of the MAC Field and Packing
field.
3. New NTPv4 format
An NTPv4 packet in the new format consists of:
1. NTPv4 header per RFC 5905 [RFC5905](48 octets)
2. Field Type of the Packing Field (2 octets)
3. Length of all data following the NTP header (2 octets)
4. Extension fields with no restrictions on their minimum length,
optionally including the Padding and/or MAC Fields (at least 24
octets)
The packet MUST have exactly one Packing Field and it MUST contain
all other extension fields. The packet MUST NOT have a MAC outside
the Packing Field. If there is not enough data to reach the minimum
Lichvar Expires October 27, 2019 [Page 5]
Internet-Draft NTPv4 Short Extension Fields April 2019
length of 28 octets, the Packing Field MUST include at least one
Padding Field to increase the length of the Packing Field.
4. Parsing of NTPv4 packets
An implementation SHOULD check if the following applies to the UDP
data before parsing it as an NTPv4 packet in the new format:
1. NTP version (in the first octet) is 4.
2. NTP mode (in the first octet) is 1, 2, 3, 4, or 5.
3. Length is at least 76 octets.
4. 49th and 50th octets contain the type of the Packing Field.
5. 51st and 52nd octets contain a value that is equal to the length
of the UDP data minus 48.
5. IANA Considerations
IANA is requested to allocate Extension Field Types for the Packing,
Padding, and MAC Extension Fields.
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5905] 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,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4
(NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822,
March 2016, <https://www.rfc-editor.org/info/rfc7822>.
Author's Address
Lichvar Expires October 27, 2019 [Page 6]
Internet-Draft NTPv4 Short Extension Fields April 2019
Miroslav Lichvar
Red Hat
Purkynova 115
Brno 612 00
Czech Republic
Email: mlichvar@redhat.com
Lichvar Expires October 27, 2019 [Page 7]
