Internet Engineering Task Force H. Stenn
Internet-Draft Network Time Foundation
Intended status: Standards Track March 25, 2019
Expires: September 26, 2019
Network Time Protocol Suggested REFID Extension Field
draft-stenn-ntp-suggest-refid-05
Abstract
NTP's Reference ID, or REFID, identifies the source of time in a
timestamp or time packet. In NTP packets sent over the network the
REFID is used to identify the "system peer", and in the long-term
general case its fundamental purpose is to prevent a one-degree
timing loop. Each instance of NTP decides for itself what REFID it
will put in its outgoing packets, and there is currently no way for
an external time source to tell or recommend this value in the case
where that external time source is selected as the "system peer."
The SUGGESTED-REFID NTP Extension Field proposal is a backward-
compatible way for a time source to tell its peers or clients "If you
use me as your system peer, use this nonce as your REFID."
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 September 26, 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
Stenn Expires September 26, 2019 [Page 1]
Internet-Draft Network Time Protocol Suggested REFID March 2019
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. The REFID . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Suggested REFID Extension Field . . . . . . . . . . . . . 4
4. Generating and Sending a Nonce as the Suggested REFID
Extension Field . . . . . . . . . . . . . . . . . . . . . . . 4
5. Remembering a Nonce Suggested REFID Extension Field . . . . . 5
6. The Suggested REFID Extension Field and Leap Smear REFIDs . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
NTP has been widely used through several revisions, with the latest
being RFC 5905 [RFC5905]. A core component of the protocol and the
algorithms is the Reference ID, or REFID, which is used to identify
the time source. Traditionally, when the source of time was another
system the REFID was the IPv4 address of that other system. If the
remote system was using IPv6 for its connection, a 4 octet digest
value of the IPv6 address was used. The general case core purpose of
the REFID is to prevent a one-degree timing loop (where if A has
several timing sources that include B, if B decides to get its time
from A we don't want A then deciding to get its time from B). The
REFID is considered to be "public data" and is a vital core-component
of the base NTP packet. In an increasingly hostile Internet,
knowledge of a system's time source is abusable information. If a
system's REFID is the IPv4 address of its system peer, an attacker
can try to use that information to send spoofed time packets to
either or both the target or the target's server, attempting to cause
a disruption in time service. There is also a clear use-case for
having a special REFID for use if systems are exchanging leap-smeared
time. This proposal is a backward-compatible way for a time source
to tell its peers or clients "If you use me as your system peer, use
Stenn Expires September 26, 2019 [Page 2]
Internet-Draft Network Time Protocol Suggested REFID March 2019
this nonce as your REFID." This nonce, a Suggested REFID, SHOULD be
untraceable to the sending system. When used to hide the identity of
a server, if the receiving system uses this Suggested REFID nonce
instead of the IPv4 address as its REFID, this type of attack and
information disclosure is prevented. When used to indicate that a
system is either offering leap-smeared time or is synchronized to a
leap-smeared time source, this information can be used to prevent
unwanted synchronization to a source that is not offering the
"flavor" of time we want, and, in the case where a leap smear
correction continues into the next day, the second half of a leap
smear correction can be applied in the expected manner.
This SUGGESTED-REFID NTP Extension Field proposal is a simple, clean,
backward-compatible way for an external time soure to request that
the receiving system use the provided nonce in the case where the
receiving system uses the sending system as its system peer.
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].
2. The REFID
The core reason for the REFID in the NTP Protocol is to prevent a
timing loop of degree 1. Put another way, if servers A and B are
exchanging time with each other and server B decides to follow A as
its system peer, the REFID that B will use must be able to identify
server A. The interpretation of a REFID is based on the stratum, as
documented in RFC 5905 [RFC5905], section 7.3, "Packet Header
Variables". At Stratum 2+, which will be the case if servers A and B
are exchanging packets over IPv4, if server B follows A, then B will
have A's IPv4 address as its REFID. When A asks B for its time, A
will see that B is synchronized to A because B will tell A that its
REFID is A's IPv4 address, so when A sees its IP address as B's
REFID, A knows that if it were to follow B for its time then there
would be a timing loop. In this case, A will not select B as a
potential source of time.
Another related use case for the REFID centers around the increasing
use of leap-smearing time servers when the insertion (or any eventual
deleiton) of a leap second occurs. It is critical that operators and
client systems be able to identify when a server is offering leap-
smeared time. Futhermore, with the current practice of smearing the
insertion of a leap second starting at noon UTC on the day of the
leap event and completing the smear at noon UTC on the day after the
leap event, a server that is operating during a leap smear event must
Stenn Expires September 26, 2019 [Page 3]
Internet-Draft Network Time Protocol Suggested REFID March 2019
be able to immediately identify if it should respond with either
correct or leap-smeared time.
3. The Suggested REFID Extension Field
Since there is no way in the base NTP packet for "this" instance of
an NTP server to tell the "other" instance what REFID it should use
if the "other" instance decides to use "this" instance as its system
peer, the best available way to convey this information is via an
extension 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 | Field Length |
+-------------------------------+-------------------------------+
| Suggested REFID |
+---------------------------------------------------------------+
NTP Extension Field: REFID Suggestion
Field Type: TBD (Recommendation for IANA: 0x0006 (Suggested REFID))
Field Length: 0x0008
Suggested REFID: The 4 octets of the suggested REFID. Random nonce
REFID values SHOULD be 0xFDxxxxxx, where the bottom 3 octets SHOULD
be random values.
Examples: When decoded as an IPv4 address, a random nonce suggested
REFID would decode as 253.0.0.0 thru 253.255.255.255.
4. Generating and Sending a Nonce as the Suggested REFID Extension
Field
A system that decides to send a nonce as a Suggested REFID extension
field SHOULD generate a new Suggested REFID nonce for each new
association. It MAY generate a new Suggested REFID nonce for any
association in any response. In addition to remembering the IP-based
REFID, the sender MUST also remember its most-recent Suggested REFID
nonce.
Since the core NTPv4 and earlier protocols do not contain any way to
tell the recipient what to use as a REFID and RFC 5905 [RFC5905] uses
the IPv4 address of the sender as the REFID if the association is
effected over an IPv4 connection, this means that an attacker can
simply send an NTP client request to a server knowing that server's
system peer will be returned as the REFID in the response packet. At
Stenn Expires September 26, 2019 [Page 4]
Internet-Draft Network Time Protocol Suggested REFID March 2019
this point, an attacker can, if that REFID is an IPv4 address, begin
to launch attacks at the target forging the putative IP of the
target's time source, or the attacker can start forging packets to
the putative time server claiming to be from the target, in an
attempt to cause the time server to limit or deny time service to the
target.
Using a nonce for the REFID that is only recognized by the sending
machine effectively prevents this type of attack.
If servers S1, S2, and S3 are all exchanging time with each other and
are all using the Suggested REFID mechanism, there is a 3 in
16,777,216 (2^24) chance that two different servers in the same group
will happen to choose the same nonce, and that would produce a false-
positive timing loop detection. If a nonce Suggested REFID is never
changed, this false-positive condition will occur for potentially a
long time. This small risk can be reduced by periodically generating
a new Suggested REFID.
5. Remembering a Nonce Suggested REFID Extension Field
An NTP server keeps track of the IP address it uses to talk to its
peers. If an NTP server chooses to send a Suggested REFID to an
associated peer, the server MUST remember this value. When checking
for a timing loop, the Suggested REFID must also be included in the
list of tested REFID values.
A set of NTP servers that are acting as a group of time servers
SHOULD be using peer associations (NTP mode 1 and 2 packets), and
SHOULD NOT be using client/server (NTP mode 3 and 4) exchanges.
Nevertheless, implementors should be aware that the recommendation
against using client/server associations for time groups may be
ignored, and should be conscious of the choices they make and the
configuration options they offer in order to accomodate (or at least
document) this situation.
6. The Suggested REFID Extension Field and Leap Smear REFIDs
The Suggested REFID can play an important part when a server has a
client population that receives leap-smeared time.
The current preferred behavior for servers that offer leap-smeared
time is to offer leap-smeared time in response to appropriate client
(mode 3) requests. There are two competing forces at play during
this time:
- Clients that want correct time should get correct time.
Stenn Expires September 26, 2019 [Page 5]
Internet-Draft Network Time Protocol Suggested REFID March 2019
- Clients that want leap-smeared time should get leap-smeared time.
An additional complication is that a leap-second insertion event
begins at noon UTC, when the Leap Indicator is 1, but the smear is
only halfway applied at midnight UTC, when the Leap Indicator changes
back to 0. There is no simple way for the client to let its
server(s) know that it is using leap-smeared time.
One simple way for the client to let its server(s) know that it is
using and wants leap-smeared time is for the client to use a Leap
Smear REFID [DRAFT-LEAP-SMEAR-REFID] in its client (mode 3) requests
during the entire leap smear period.
7. Acknowledgements
The author wishes to acknowledge the contributions of Martin Burnicki
and Sam Weiler.
8. IANA Considerations
This memo requests IANA to allocate NTP Extension Field Type 0x0006
(Suggested REFID) for this proposal.
9. Security Considerations
Adopting this proposal will provide a much needed mechanism by which
cooperating systems can agree on a less trackable and less
identifiable nonce for the REFID. It will also provide a means to
properly and better handle leap-smearing events with populations
where some clients want correct time and other clients want leap-
smeared time, thus enabling better time synchronization.
No reports of adverse consequences of adopting this proposal have
been received.
10. References
10.1. 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>.
Stenn Expires September 26, 2019 [Page 6]
Internet-Draft Network Time Protocol Suggested REFID March 2019
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
10.2. Informative References
[DRAFT-I-DO]
Stenn, H., "draft-stenn-ntp-i-do", 2018.
[DRAFT-LEAP-SMEAR-REFID]
Stenn, H., "draft-stenn-ntp-leap-smear-refid", 2018.
Author's Address
Harlan Stenn
Network Time Foundation
P.O. Box 918
Talent, OR 97540
US
Email: stenn@nwtime.org
Stenn Expires September 26, 2019 [Page 7]
