draft-ietf-ntp-refid-updates-01.txt   draft-ietf-ntp-refid-updates-02.txt 
Internet Engineering Task Force H. Stenn Internet Engineering Task Force H. Stenn
Internet-Draft Network Time Foundation Internet-Draft Network Time Foundation
Intended status: Standards Track S. Goldberg Intended status: Standards Track S. Goldberg
Expires: June 2, 2018 Boston University Expires: June 7, 2018 Boston University
November 29, 2017 December 4, 2017
Network Time Protocol REFID Updates Network Time Protocol REFID Updates
draft-ietf-ntp-refid-updates-01 draft-ietf-ntp-refid-updates-02
Abstract Abstract
RFC 5905 [RFC5905], section 7.3, "Packet Header Variables", defines RFC 5905 [RFC5905], section 7.3, "Packet Header Variables", defines
the value of the REFID, the system peer for the responding host. In the value of the REFID, the system peer for the responding host. In
the past, for IPv4 associations the IPv4 address is used, and for the past, for IPv4 associations the IPv4 address is used, and for
IPv6 associations the first four octets of the MD5 hash of the IPv6 IPv6 associations the first four octets of the MD5 hash of the IPv6
are used. There are at least three shortcomings to this approach, are used. There are at least three shortcomings to this approach,
and this proposal will address the three so noted. One is that and this proposal will address the three so noted. One is that
knowledge of the system peer is "abusable" information and should not knowledge of the system peer is "abusable" information and should not
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 2, 2018. This Internet-Draft will expire on June 7, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The REFID . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. The REFID . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. NOT-YOU REFID . . . . . . . . . . . . . . . . . . . . . . 3 1.2. NOT-YOU REFID . . . . . . . . . . . . . . . . . . . . . . 3
1.3. IPv6 REFID . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. IPv6 REFID . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Leap-Smear REFID . . . . . . . . . . . . . . . . . . . . 4 1.4. Leap-Smear REFID . . . . . . . . . . . . . . . . . . . . 4
1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. The NOT-YOU REFID . . . . . . . . . . . . . . . . . . . . . . 5 2. The NOT-YOU REFID . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Augmenting the IPv6 REFID Hash . . . . . . . . . . . . . . . 6 3. Augmenting the IPv6 REFID Hash . . . . . . . . . . . . . . . 6
3.1. Background . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Background . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Potential Problems . . . . . . . . . . . . . . . . . . . 6 3.2. Potential Problems . . . . . . . . . . . . . . . . . . . 7
3.3. Questions . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Questions . . . . . . . . . . . . . . . . . . . . . . . . 7
4. The REFID sent to clients during a Leap-Smear . . . . . . . . 7 4. The REFID sent to clients during a Leap-Smear . . . . . . . . 7
4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Leap Smear REFID . . . . . . . . . . . . . . . . . . . . 7 4.2. Leap Smear REFID . . . . . . . . . . . . . . . . . . . . 8
4.3. Questions . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Questions . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
1.1. The REFID 1.1. The REFID
The interpretation of a REFID is based on the stratum, as documented The interpretation of a REFID is based on the stratum, as documented
in RFC 5905 [RFC5905], section 7.3, "Packet Header Variables". The in RFC 5905 [RFC5905], section 7.3, "Packet Header Variables". The
core reason for the REFID in the NTP Protocol is to prevent a degree- core reason for the REFID in the NTP Protocol is to prevent a degree-
one timing loop, where server B decides to follow A as its time one timing loop, where server B decides to follow A as its time
source, and A then decides to follow B as its time source. source, and A then decides to follow B as its time source.
skipping to change at page 3, line 22 skipping to change at page 3, line 22
1.2. NOT-YOU REFID 1.2. NOT-YOU REFID
This REFID mechanism, however, also allows a third-party C to learn This REFID mechanism, however, also allows a third-party C to learn
that A is the time source that is being used by B. When A is using that A is the time source that is being used by B. When A is using
IPv4, C can learn this by querying B for its time, and observing that IPv4, C can learn this by querying B for its time, and observing that
the REFID in B's response is the IPv4 address of A. Meanwhile, when the REFID in B's response is the IPv4 address of A. Meanwhile, when
A is using IPv6, then C can again query B for its time, and then can A is using IPv6, then C can again query B for its time, and then can
use an offline dictionary attack to attempt to determine the IPv6 use an offline dictionary attack to attempt to determine the IPv6
address that corresponds to the digest value in the response sent by address that corresponds to the digest value in the response sent by
B. C could construct the necessary dictionary by compiling a list of B. C could construct the necessary dictionary by compiling a list of
publically accessible IPv6 servers. Remote attackers can use this publicly accessible IPv6 servers. Remote attackers can use this
technique to attempt to identify the time sources used by a target, technique to attempt to identify the time sources used by a target,
and then send spoofed packets to the target or its time source in an and then send spoofed packets to the target or its time source in an
attempt to disrupt time service, as was done e.g., in [NDSS16] or attempt to disrupt time service, as was done e.g., in [NDSS16] or
[CVE-2015-8138]. [CVE-2015-8138].
The REFID thus unnecessarily leaks information about a target's time The REFID thus unnecessarily leaks information about a target's time
server to remote attackers. The best way to mitigate this server to remote attackers. The best way to mitigate this
vulnerability is to decouple the IP address of the time source from vulnerability is to decouple the IP address of the time source from
the REFID. To do this, a system can use an otherwise-impossible the REFID. To do this, a system can use an otherwise-impossible
value for its REFID, called the "not-you" value, when it believes value for its REFID, called the "not-you" value, when it believes
skipping to change at page 4, line 7 skipping to change at page 4, line 7
different network interface. In this case, the remote system might different network interface. In this case, the remote system might
choose us as their system peer, and a degree-one timing loop will choose us as their system peer, and a degree-one timing loop will
occur. In this case, however, the two systems will spiral into worse occur. In this case, however, the two systems will spiral into worse
stratum positions with increasing root distances, and eventually the stratum positions with increasing root distances, and eventually the
loop will break. If any other systems are available as time servers, loop will break. If any other systems are available as time servers,
one of them will become the new system peer. However, until this one of them will become the new system peer. However, until this
happens the two spiraling systems will have degraded time quality. happens the two spiraling systems will have degraded time quality.
1.3. IPv6 REFID 1.3. IPv6 REFID
In a trusted situation, an operator might well choose to expose the In an environment where all time queries made to a server can be
real REFID. RFC 5905 [RFC5905], section 7.3, "Packet Header trusted, an operator might well choose to expose the real REFID. RFC
Variables", explains how a remote system peer is converted to a 5905 [RFC5905], section 7.3, "Packet Header Variables", explains how
REFID. It says: a remote system peer is converted to a REFID. It says:
If using the IPv4 address family, the identifier is the four-octet If using the IPv4 address family, the identifier is the four-octet
IPv4 address. If using the IPv6 family, it is the first four IPv4 address. If using the IPv6 family, it is the first four
octets of the MD5 hash of the IPv6 address. ... octets of the MD5 hash of the IPv6 address. ...
However, the MD5 hash of an IPv6 address often looks like a valid However, the MD5 hash of an IPv6 address often looks like a valid
IPv4 address. When this happens, an operator cannot tell if the IPv4 address. When this happens, an operator cannot tell if the
REFID refers to an IPv6 address or and IPv4. Specifically, the NTP REFID refers to an IPv6 address or and IPv4. Specifically, the NTP
Project has received a report where the generated IPv6 hash decoded Project has received a report where the generated IPv6 hash decoded
to the IPv4 address of a different machine on the system peer's to the IPv4 address of a different machine on the system peer's
network. network.
This proposal offers a way for a system to generate a REFID for a This proposal offers a way for a system to generate a REFID for a
IPv6 system peer that does not conflict with an IPv4-based REFID. IPv6 system peer that does not conflict with an IPv4-based REFID.
This proposal is not fully backwards-compatible. It SHOULD be This proposal is not fully backwards-compatible. It SHOULD be
implemented by both peers in an NTP association. Having said this, implemented by both peers in an NTP association. In the scenario
however, in a properly-designed NTP network there is negligible risk where A and B are peering using IPv6, where A is the system peer and
of a degree-one timing loop if only one system implements and uses does not understand IPv6 REFID, and B is subordinate and is using
the IPv6 REFID. This backward incompatability can be avoided by IPv6 REFID, A will not be able to determine that B is using A as its
using the proposed I-DO protocol. system peer and a degree-one timing loop can form.
If both peers implement the IPv6 REFID this situation cannot happen.
[If at least one of the peers implements the proposed I-DO protocol
this situation cannot happen.]
1.4. Leap-Smear REFID 1.4. Leap-Smear REFID
RFC 5905 [RFC5905] and earlier versions of NTP are the overwhelming RFC 5905 [RFC5905] and earlier versions of NTP are the overwhelming
method of distributing time on networks. Leap Seconds will continue method of distributing time on networks. Leap Seconds will continue
to exist for a good number of years' time, and since the timescale to exist for a good number of years' time, and since the timescale
mandated by POSIX effectively ignores any instances where there are mandated by POSIX effectively ignores any instances where there are
not 86,400 seconds' time in a day something must be done to reliably not 86,400 seconds' time in a day something must be done to reliably
synchronize clocks during the application of leap second corrections. synchronize clocks during the application of leap second corrections.
One mechanism for dealing with the application that has recently One mechanism that has recently become visible to deal with the
become visible is to apply the leap second using a "smear", where the insertion of a leap second is to apply the leap second using a
time reported by leap-second aware servers is gradually adjusted so "smear", where the time reported by leap-second aware servers is
there is no major disruption to time synchronization when processing gradually adjusted so there is no major disruption to time
a leap second. synchronization when processing a leap second.
While the proper handling of leap seconds can be expected from up-to- While the proper handling of leap seconds can be expected from up-to-
date software and time servers, there are large numbers of out-of- date software and time servers, there are large numbers of out-of-
date software installations and systems that are just not able to date software installations and systems that are just not able to
properly handle a leap second correction. properly handle a leap second correction.
This proposal offers a way for a system to generate a REFID that This proposal offers a way for a system to generate a REFID that
indicates that the time being supplied in the NTP packet already indicates that the time being supplied in the NTP packet already
contains an amount of leap smear correction, and what that amount is. contains an amount of leap smear correction, and what that amount is.
skipping to change at page 5, line 43 skipping to change at page 5, line 48
When enabled, this proposal allows the one-degree loop detection to When enabled, this proposal allows the one-degree loop detection to
work and useful diagnostic information to be provided to trusted work and useful diagnostic information to be provided to trusted
partners while keeping potentially abusable information from being partners while keeping potentially abusable information from being
disclosed to ostensibly uninterested parties. It does this by disclosed to ostensibly uninterested parties. It does this by
returning the normal REFID to queries that come from trusted returning the normal REFID to queries that come from trusted
addresses or from an address that the current system believes is its addresses or from an address that the current system believes is its
time source (aka its "system peer"), and otherwise returning a time source (aka its "system peer"), and otherwise returning a
special IP address that is interpreted to mean "not you". The "not special IP address that is interpreted to mean "not you". The "not
you" IP address is 127.127.127.127 when the query is made from an you" IP address is 127.127.127.127 when the query is made from an
IPv4 address, or when the query is made from an IPv6 address whose IPv4 address, or when the query is made from an IPv6 address whose
four-octect hash does not equal 127.127.127.127. The "not you" IP four-octet hash does not equal 127.127.127.127. The "not you" IP
address is 127.127.127.128 when the query is made from an address address is 127.127.127.128 when the query is made from an address
whose four-octect hash equals 127.127.127.127. whose four-octet hash equals 127.127.127.127.
Note that this mechanism fully supports degree-one loop detection in This mechanism is correct and transparent when the system responding
the case where the responding NOT-YOU system can accurately detect with a NOT-YOU can accurately detect when it's getting a timing query
when it's getting a request from its system peer, and otherwise from its system peer. A querying system that uses IPv4 continues to
provides the most basic diagnostic information to third parties. check that its IPv4 address does not appear in the REFID before
deciding whether to take time from the current system. A querying
system that uses IPv6 continues to check that the four-octet hash of
its IPv6 address does not appear in the REFID before deciding whether
to take time from the current system. However...
This proposal will hide the current system's system peer from Use of the NOT-YOU REFID proposal will hide the current system's
querying systems that the current system believes are not the current system peer from querying systems that the current system believes
system's system peer. Note well, however, that the current system are not the current system's system peer. Should the current system
will return the "not you" value to a query from its system peer if return the "not you" REFID to a query from its system peer, for
the system peer sends its query from an unexpected IP address. Put example in the case where the system peer sends its query from an
unexpected IP address, a one-degree timing loop can occur. Put
another way, the responding system has imperfect knowledge about another way, the responding system has imperfect knowledge about
whether or not the sender is its system peer and there are cases whether or not the sender is its system peer and there are cases
where it will offer a NOT-YOU response to its system peer, which will where it will offer a NOT-YOU response to its system peer, which can
then produce a degree-one timing loop. then produce a degree-one timing loop.
Note that this mechanism fully supports degree-one loop detection in
the case where the responding NOT-YOU system can accurately detect
when it's getting a request from its system peer, and otherwise
provides the most basic diagnostic information to third parties.
3. Augmenting the IPv6 REFID Hash 3. Augmenting the IPv6 REFID Hash
3.1. Background 3.1. Background
In a trusted network, the S2+ REFID is generated based on the network In a trusted network, the S2+ REFID is generated based on the network
system peer. RFC 5905 [RFC5905] says: system peer. RFC 5905 [RFC5905] says:
If using the IPv4 address family, the identifier is the four-octet If using the IPv4 address family, the identifier is the four-octet
IPv4 address. If using the IPv6 family, it is the first four IPv4 address. If using the IPv6 family, it is the first four
octets of the MD5 hash of the IPv6 address. ... octets of the MD5 hash of the IPv6 address. ...
skipping to change at page 6, line 42 skipping to change at page 7, line 10
When using the REFID to check for a timing loop for an IPv6 When using the REFID to check for a timing loop for an IPv6
association, if the code that checks the first four-octets of the association, if the code that checks the first four-octets of the
hash fails to match then the code must check again, using 0xFF as the hash fails to match then the code must check again, using 0xFF as the
first octet of the hash. first octet of the hash.
3.2. Potential Problems 3.2. Potential Problems
There is a 1 in 16,777,216 chance that the REFID hashes of two IPv6 There is a 1 in 16,777,216 chance that the REFID hashes of two IPv6
addresses will be identical, producing a false-positive loop addresses will be identical, producing a false-positive loop
detection. With a sufficient number of servers, the risk of this detection. With a sufficient number of servers, the risk of this
problem becomes a non-issue. The use of the NOT-YOU REFID and/or the problem becomes a non-issue. [The use of the NOT-YOU REFID and/or
proposed "REFID Suggestion" or "I-DO" extension fields are ways to the proposed "REFID Suggestion" or "I-DO" extension fields are ways
mitigate this potential situation. to mitigate this potential situation.]
Unrealistically, if only two instances of NTP are communicating via Unrealistically, if only two instances of NTP are communicating via
IPv6 and one side implements this new IPv4 REFID hash and the other IPv6 and system A implements this new IPv6 REFID hash and system B
side does not, the "other side" will not be able to detect this loop does not, system B will not be able to detect this loop condition.
condition. In this case, the two machines will slowly increase their In this case, the two machines will slowly increase their Stratum
Stratum until they reach S16 and become unsynchronized. This until they reach S16 and become unsynchronized. This situation is
situation is considered to be unrealistic because the only current considered to be unrealistic because, for this to happen, each system
way this could happen would be for there to only be these two would have to have only the other system available as a time source,
instances of NTP available as time sources in a misconfigured "orphan for example, in a misconfigured "orphan mode" setup. There is no
mode" setup. There is no risk of this happening in an NTP network risk of this happening in an NTP network with 3 or more time sources,
with 3 or more time sources, or in a properly-configured "time or in a properly-configured "time island" setup.
island" setup.
3.3. Questions 3.3. Questions
Should we reference the REFID Suggestion and I-DO proposals here?
Should we ask IANA to allocate a pseudo Extension Field Type of Should we ask IANA to allocate a pseudo Extension Field Type of
0xFFFF (for example) so the proposed "I-Do" exchange can report 0xFFFF (for example) so the proposed "I-Do" exchange can report
whether or not the "IPv6 REFID Hash" is supported? whether or not the "IPv6 REFID Hash" is supported?
4. The REFID sent to clients during a Leap-Smear 4. The REFID sent to clients during a Leap-Smear
4.1. Background 4.1. Background
RFC 5905 [RFC5905] and earlier versions of NTP are the overwhelming RFC 5905 [RFC5905] and earlier versions of NTP are the overwhelming
method of distributing time on networks. Leap Seconds will continue method of distributing time on networks. Leap Seconds will continue
skipping to change at page 7, line 33 skipping to change at page 7, line 51
not 86,400 seconds' time in a day, something must be done to reliably not 86,400 seconds' time in a day, something must be done to reliably
synchronize clocks during the application of leap second corrections. synchronize clocks during the application of leap second corrections.
One mechanism for dealing with the application that has recently One mechanism for dealing with the application that has recently
become visible is to apply the leap second using a "smear", where the become visible is to apply the leap second using a "smear", where the
time reported by leap-second aware servers is gradually adjusted so time reported by leap-second aware servers is gradually adjusted so
there is no major disruption to time synchronization when processing there is no major disruption to time synchronization when processing
a leap second. a leap second.
While the proper handling of leap seconds can be expected from up-to- While the proper handling of leap seconds can be expected from up-to-
date software and time servers, there are large numbers of out-of- date software and time servers, there are large numbers of out-of-
date software installations and systems that are just not able to date software installations and systems that are not able to properly
properly handle a leap second correction. handle a leap second correction.
This proposal offers a way for a system to generate a REFID that This proposal offers a way for a system to generate a REFID that
indicates that the time being supplied in the NTP packet already indicates that the time being supplied in the NTP packet already
contains an amount of leap smear correction, and what that amount is. contains an amount of leap smear correction, and what that amount is.
4.2. Leap Smear REFID 4.2. Leap Smear REFID
RFC 5905 [RFC5905] defines the data type of NTP time values in RFC 5905 [RFC5905] defines the data type of NTP time values in
Section 6, "Data Types": Section 6, "Data Types":
skipping to change at page 8, line 18 skipping to change at page 8, line 35
| Seconds | | Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction | | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Timestamp Format (32:32) NTP Timestamp Format (32:32)
This format provides coverage for 136 years' time to a precision of This format provides coverage for 136 years' time to a precision of
232 picoseconds. If a leap-second addition is being completely 232 picoseconds. If a leap-second addition is being completely
smeared just before before the stroke of the next POSIX second then smeared just before before the stroke of the next POSIX second then
the smear correction will be (0,1). If this was the only way to the smear correction will be (0,1). [That's mathematical domain
apply a leap smear correction then we could simply use an unsigned range notation - how to cite it?] If this was the only way to apply
value to represent the correction. But while the first popular leap a leap smear correction then we could simply use an unsigned value to
smear implementation applied the correction over an appropriate represent the correction. But while the first popular leap smear
number of hours' time before the actual leap second so the system implementation applied the correction over an appropriate number of
time was corrected at the stroke of 00:00, that meant that the hours' time before the actual leap second, so the system time was
difference between system time and UTC spent half of the duration of again correct at the stroke of 00:00, that meant that the difference
the smear application at [.5,1) "off" of correct time. The second between system time and UTC spent half of the duration of the smear
popular implementation of the leap smear applied the first half- application at [.5,1) "off" of correct time. The second popular
second correction before the stroke of 00:00 for a correction range implementation of the leap smear applied the first half-second
of (0,.5] and the last half-second correction starting at the stroke correction before the stroke of 00:00 for a correction range of
of 00:00 for a [-.5,0) correction range. This also means we need a (0,.5] and the last half-second correction starting at the stroke of
00:00 for a [-.5,0) correction range. This also means we need a
signed value to represent the amount of correction. signed value to represent the amount of correction.
The REFID of a system that is supplying smeared time to client The REFID of a system that is supplying smeared time to client
requests while leap-smear correction is active would be 254.b1.b2.b3, requests while leap-smear correction is active would be 254.b1.b2.b3,
where the three octets (b1, b2, and b3) are a 2:22 formatted value, where the three octets (b1, b2, and b3) are a 2:22 formatted value,
yielding precision to 238 nanoseconds, or about a quarter of a yielding 2 signed bits of integer time and 22 bits of unsigned
microsecond. fractional subseconds, with a precision to 238 nanoseconds, or about
a quarter of a microsecond. Signed time is needed to implement the
mathematical range described in the previous paragraph.
[How should we cite the 2:22 notation? This is the same general
format that we use for NTP timestamps.]
The client is not expected to do anything with this information.
Indeed, the whole point of offering smeared time is that there is
reason to believe the clients are unable to properly handle a leap
second correction. In this case, clients cannot be expected to do
anything with data embedded in the REFID, either. However,
monitoring systems that use tools that show a host's system peer,
like the 'ntpq' and 'sntp' programs in the reference implementation,
[HMS: how to cite this?] can use this information to make sure that
clients are following a leap-smearing server and can see fairly
accurately what the smear is for each client.
Note that if an NTP server decides to offer smeared time corrections Note that if an NTP server decides to offer smeared time corrections
to clients, it SHOULD only offer this time in response to CLIENT time to clients, it SHOULD only offer this time in response to CLIENT time
requests. An NTP server that is offering smeared time SHOULD NOT requests. An NTP server that is offering smeared time SHOULD NOT
send smeared time in any peer exchanges. Also, CLIENT machines send smeared time in any peer exchanges. Also, system that sync
SHOULD NOT be distributing time (smeared or otherwise) to other their time via CLIENT requests SHOULD NOT be distributing time
systems. (smeared or otherwise) to other systems.
We also note that during the application of a leap smear, the REFID We also note that during the application of a leap smear, the REFID
from a system offering smeared time cannot provide detection of a from a system offering smeared time cannot provide detection of a
timing loop. This is not expected to be a problem because time timing loop. This is not expected to be a problem because time
server systems are not expected to make CLIENT connections with each server systems are not expected to make CLIENT connections with each
other, so they should not be receiving smeared time. Moreso, if a other, so they should not be receiving smeared time. Moreso, if a
time server is configured to make CLIENT connections to a server that time server is configured to make CLIENT connections to a server that
offers smeared time, with the mechanism described here it can detect offers smeared time, with the mechanism described here it can detect
when it is getting smeared time, and either ignore time from that when it is getting smeared time, and either ignore time from that
source, or "undo" the leap smear correction and use the corrected source, or "undo" the leap smear correction and use the corrected
 End of changes. 24 change blocks. 
70 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/