Network Time Protocol Version 4 (NTPv4) Extension Fields
Clarifies where optional NTP extension fields go, how they pair with a MAC, and what hosts do with fields they do not know.
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>.
@misc{rfc7822,
series = {Request for Comments},
number = 7822,
howpublished = {RFC 7822},
publisher = {RFC Editor},
doi = {10.17487/RFC7822},
url = {https://www.rfc-editor.org/info/rfc7822},
author = {T. Mizrahi and D. Mayer},
title = {{Network Time Protocol Version 4 (NTPv4) Extension Fields}},
pagetotal = 8,
year = 2016,
month = mar,
} RFC text
Contents
Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7822 Marvell
Updates: 5905 D. Mayer
Category: Standards Track Network Time Foundation
ISSN: 2070-1721 March 2016
Network Time Protocol Version 4 (NTPv4) Extension Fields
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 that can be used to add optional capabilities or additional
information that is not conveyed in the standard NTP header. This
document updates RFC 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 in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://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 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 and Abbreviations ....................................3
3. NTP Extension Fields - RFC 5905 Update ..........................3
4. Security Considerations .........................................6
5. References ......................................................7
5.1. Normative References .......................................7
5.2. Informative References .....................................7
Acknowledgments ....................................................8
Authors' Addresses .................................................8
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 (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.
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 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.
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.
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.
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 in Section 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.
5. References
5.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>.
Acknowledgments
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.org
ISO Plain Language
On this page
§1Why Extension Fields Needed Clarifying
Network Time Protocol version 4 (NTPv4) sends a fixed set of header fields that may be followed by optional fields. There are two kinds of optional field. A Message Authentication Code (MAC) sits at the end of the packet, and it can be 24 octets long, 20 octets long, or a 4-octet crypto-NAK. Extension fields carry capabilities or extra information that the standard header cannot express.
Extension fields were introduced in RFC 5905 as a general mechanism for adding future features without changing the NTP header format. Only two are defined so far: the one used by the Autokey protocol in RFC 5906, and the Checksum Complement of RFC 7821. The Autokey field is always followed by a MAC, and Section 10 of the Autokey specification gives the parsing rules that let a host tell an extension field from a MAC. A MAC is nevertheless not mandatory after an extension field, and an NTPv4 packet may carry one or more extension fields with no MAC at all.
This RFC updates Section 7.5 of RFC 5905 to correct the errors that appeared after that specification was published: the relationship between extension fields and MACs, and the behaviour of a host that receives an extension field it does not know.
NTP time messages can carry extra pieces of information after the normal header. This RFC sorts out exactly where those extra pieces go and when a message has to be signed.
NTP header
Extension field 1
Extension field 2
...
MAC (optional, always last)§3The Extension Field Format
An extension field is a small block made of four parts: a 16-bit Field Type, a 16-bit Length, a Value and Padding. The Field Type says what the field is for, and its value comes from an IANA registry. The Length, Value and Padding contents are defined by the document that the registry entry points to. The Length field is a 16-bit unsigned integer that gives the length of the whole extension field in octets, padding included.
Every extension field is zero-padded to a word, which is four octets, boundary. A field that carries the required fields needs a minimum length of four words, or 16 octets. No field can be longer than 65,532 octets, because the Length field has to be able to hold the size of the field it describes.
Each extra piece starts with a type number and a length, then holds some data, and is padded with zeros to a four-byte boundary. It must be at least 16 bytes long and cannot be longer than 65,532 bytes.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
FIELD-TYPE | Field Type | 2 bytes | Says what the field is for; the value comes from an IANA registry. | |
LENGTH | Length | 2 bytes | Length of the whole extension field in octets, padding included. | |
VALUE | Value | 2 bytes | Content of the field, as defined by the specification the registry entry points to. | |
PADDING | Padding | 2 bytes | 0 | Zero padding to the next four-octet word boundary. |
§3Unknown Field Types
Extension fields exist so that new features can be added later, which means a host will meet field types it does not understand. The updated text states that a host that receives an extension field with an unknown Field Type SHOULD ignore that extension field, and MAY drop the packet altogether if policy requires it. Ignoring the unknown field is what allows a new extension to be put into use before every host on the network understands it.
If a host meets an extension field it does not recognize, it should skip that field. It may also throw the whole packet away if its own policy says so.
§3Extension Fields and Message Authentication Codes
An extension field can travel in a packet that also carries a MAC, for example the one used by Autokey. A specification that defines a new extension field must say whether that field requires a MAC, and if it does, it must define the algorithm used to create the MAC and the length of the MAC that is created. A field may allow more than one algorithm, and in that case the field itself must carry the information about which algorithm was used.
When several extension fields in one packet require a MAC, they must all require the same algorithm and the same MAC length, and a packet must not be sent with two or more such fields that use different algorithms. A receiver that gets two or more recognized extension fields requiring different MAC algorithms must discard the packet. Extension fields that do not require a MAC can be included together with fields that do.
The MAC has one further limit. If no extension field is present, a MAC must not be longer than 24 octets, unless a longer MAC has been agreed between the client and the server. The two can agree on it in an earlier exchange of packets that carried an extension field defining the size and algorithm of the MAC that is transmitted in NTP packets.
A new kind of extension field has to say whether it needs a signature, and if so, which kind and how long. Two signed fields in one message must use the same kind, and a message that breaks that rule is thrown away.
§3Length Rules Without a MAC
A MAC is not required after an extension field, and the updated text gives the sizes that a packet without a MAC must use. If the packet includes a single extension field, the length of that extension field must be at least seven words, which is 28 octets. If the packet includes more than one extension field, the length of the last extension field must be at least 28 octets, and the length of each of the other extension fields must be at least 16 octets.
Without a signature, a message with one extra field needs that field to be at least 28 bytes long. With several, the last one needs 28 bytes and the others need 16.
| Case | Rule |
|---|---|
| Any extension field | At least 16 octets (four words) |
| Any extension field | At most 65,532 octets |
| Single extension field, no MAC | At least 28 octets (seven words) |
| Last extension field, no MAC | At least 28 octets (seven words) |
| Other extension fields, no MAC | At least 16 octets each |
§4Security Considerations
The RFC points to the general security discussion for time protocols in RFC 7384 and to the NTP discussion in RFC 5905, and then adds its own notes. Denial-of-service attacks on NTP servers work by flooding a server with a high rate of NTP packets. Malicious use of extension fields cannot make such an attack worse, because servers ignore extension fields they do not know and only respond, if they respond at all, with extension fields they do know. Extension fields that arrive in a packet are neither propagated by a server nor included in a response; a server creates its own extension fields if it needs them for a reply. A large number of extension fields should be flagged by a server as a potential attack, and large extension field sizes should also be flagged unless they are expected to be large.
One further rule protects future extensions. Middleboxes such as firewalls must not filter NTP packets based on their extension fields, and should not examine extension fields in the packets at all, because an NTP packet may carry an extension field that the middlebox has not been updated to recognize.
Extension fields cannot be used to make a flood attack worse, because servers ignore fields they do not know. Firewalls must not drop NTP packets just because of an extension field they do not understand.