draft-ietf-ntp-refid-updates-04.txt   draft-ietf-ntp-refid-updates-05.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: April 7, 2019 Boston University Expires: September 26, 2019 Boston University
October 4, 2018 March 25, 2019
Network Time Protocol REFID Updates Network Time Protocol REFID Updates
draft-ietf-ntp-refid-updates-04 draft-ietf-ntp-refid-updates-05
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 two recognized shortcomings to this approach, are used. There are two recognized shortcomings to this approach,
and this proposal addresses them. One is that knowledge of the and this proposal addresses them. One is that knowledge of the
system peer is "abusable" information and should not be generally system peer is "abusable" information and should not be generally
available. The second is that the four octet hash of the IPv6 available. The second is that the four octet hash of the IPv6
address looks very much like an IPv4 address, and this is confusing. address looks very much like an IPv4 address, and this is confusing.
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:
The source code and issues list for this draft can be found in
https://github.com/hstenn/ietf-ntp-refid-updates
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 7, 2019. This Internet-Draft will expire on September 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. IPv6 REFID . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. The NOT-YOU REFID . . . . . . . . . . . . . . . . . . . . . . 4 2. The NOT-YOU REFID . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Proposal . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Augmenting the IPv6 REFID Hash . . . . . . . . . . . . . . . 5 3. Augmenting the IPv6 REFID Hash . . . . . . . . . . . . . . . 5
3.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Potential Problems . . . . . . . . . . . . . . . . . . . 6 3.2. Potential Problems . . . . . . . . . . . . . . . . . . . 6
3.3. Questions . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
skipping to change at page 3, line 25 skipping to change at page 3, line 31
by compiling a list of publicly accessible IPv6 servers. Remote by compiling a list of publicly accessible IPv6 servers. Remote
attackers can use this technique to attempt to identify the time attackers can use this technique to attempt to identify the time
sources used by a target, and then send spoofed packets to the target sources used by a target, and then send spoofed packets to the target
or its time source in an attempt to disrupt time service, as was done or its time source in an attempt to disrupt time service, as was done
e.g., in [NDSS16] or [CVE-2015-8138]. e.g., in [NDSS16] or [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 REFID value, when it believes
that a querying system is not its time source. that a querying system is not its time source.
The NOT-YOU REFID proposal is backwards-compatible. It can be The NOT-YOU REFID proposal is backwards-compatible and provides the
bare minimum diagnostic information to third parties. It can be
implemented by one peer in an NTP association without any changes to implemented by one peer in an NTP association without any changes to
the other peer. the other peer. This holds as long as responding NOT-YOU system can
accurately detect when it's getting a request from its system peer.
The NOT-YOU REFID proposal does have a small risk, in that a system The NOT-YOU REFID proposal does have a small risk. Consider system A
that might return NOT-YOU does not have perfect information and it is that returns the NOT-YOU REFID and system B that has two network
possible that the remote system peer is contacting "us" via a interfaces B1 and B2. Suppose that system A is using system B as his
different network interface. In this case, the remote system might time source, via network interface B1. Now suppose that system B
choose us as their system peer, and a degree-one timing loop will queries system A for time via network interface B2. In this case,
occur. In this case, however, the two systems will spiral into system A returns the NOT-YOU REFID value to system B, since system A
worsening stratum positions with increasing root distances, and does not realize that network interface B1 and B2 belong to the same
eventually the loop will break. If any other systems are available system. In this case, system B might choose system A as its time
as time servers, one of them may become the new system peer. source, and a degree-one timing loop will occur. In this case,
However, unless or until this happens the two spiraling systems will however, the two systems will spiral into degrading stratum positions
have degraded time quality. with increasing root distances, and eventually the loop will break.
If any other systems are available as time servers, one of them will
become the new system peer. However, unless or until this happens
the two spiraling systems will have degraded time quality.
1.3. IPv6 REFID 1.3. IPv6 REFID
In an environment where all time queries made to a server can be In an environment where all time queries made to a server can be
trusted, an operator might well choose to expose the real REFID. RFC trusted, an operator might well choose to expose the real REFID. RFC
5905 [RFC5905], section 7.3, "Packet Header Variables", explains how 5905 [RFC5905], section 7.3, "Packet Header Variables", explains how
a remote system peer is converted to a 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
skipping to change at page 4, line 19 skipping to change at page 4, line 28
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 backwards-compatible. It SHOULD be implemented
implemented by both peers in an NTP association. In the scenario by both peers in an NTP association. In the scenario where A and B
where A and B are peering using IPv6, where A is the system peer and are peering using IPv6, where A is the system peer and does not
does not understand IPv6 REFID, and B is subordinate and is using understand IPv6 REFID, and B is subordinate and is using IPv6 REFID,
IPv6 REFID, A will not be able to determine that B is using A as its A will not be able to determine that B is using A as its system peer
system peer and a degree-one timing loop can form. and a degree-one timing loop can form.
If both peers implement the IPv6 REFID this situation cannot happen. If both peers implement the IPv6 REFID this situation cannot happen.
[If at least one of the peers implements the proposed I-DO protocol If at least one of the peers implements the proposed I-DO
this situation cannot happen.] [DRAFT-I-DO] protocol this situation cannot happen.
1.4. Requirements Language 1.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. The NOT-YOU REFID 2. The NOT-YOU REFID
2.1. Proposal 2.1. Proposal
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 one of time source (aka its "system peer"), and otherwise returning one of
two special IP addresses that is interpreted to mean "not you". The two special IP addresses that is interpreted to mean "not you". The
skipping to change at page 5, line 14 skipping to change at page 5, line 27
not our system peer, the other NOT-YOU address is returned as the not our system peer, the other NOT-YOU address is returned as the
REFID. REFID.
This mechanism is correct and transparent when the system responding This mechanism is correct and transparent when the system responding
with a NOT-YOU can accurately detect when it's getting a timing query with a NOT-YOU can accurately detect when it's getting a timing query
from its system peer. A querying system that uses IPv4 continues to from its system peer. A querying system that uses IPv4 continues to
check that its IPv4 address does not appear in the REFID before check that its IPv4 address does not appear in the REFID before
deciding whether to take time from the current system. A querying deciding whether to take time from the current system. A querying
system that uses IPv6 continues to check that the four-octet hash of 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 its IPv6 address does not appear in the REFID before deciding whether
to take time from the current system. However... to take time from the current system.
Use of the NOT-YOU REFID proposal will hide the current system's
system peer from querying systems that the current system believes
are not the current system's system peer. Should the current system
return the "not you" REFID to a query from its system peer, for
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
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 can
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.
This means that the IPv4 representation of the IPv6 hash would be: This means that the IPv4 representation of the IPv6 hash would be:
b1.b2.b3.b4 . This proposal is that the system MAY also use b1.b2.b3.b4 . This proposal is that the system MAY also use
255.b2.b3.b4 as its REFID. This reduces the risk of ambiguity, since 255.b2.b3.b4 as its REFID. This reduces the risk of ambiguity, since
addresses beginning with 255 are "reserved", and thus will not addresses beginning with 255 are "reserved", and thus will not
collide with valid IPv4 on the network. collide with valid IPv4 on the network.
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 problem becomes a non-issue. The use of the NOT-YOU REFID and/or the
the proposed "REFID Suggestion" or "I-DO" extension fields are ways proposed REFID-SUGGESTION [DRAFT-REFID-SUGGESTION] or I-DO
to mitigate this potential situation.] [DRAFT-I-DO] extension fields are ways 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 system A implements this new IPv6 REFID hash and system B IPv6 and system A implements this new IPv6 REFID hash and system B
does not, system B will not be able to detect this loop condition. does not, system B will not be able to detect this loop condition.
In this case, the two machines will slowly increase their Stratum In this case, the two machines will slowly increase their stratum
until they reach S16 and become unsynchronized. This situation is until they become unsynchronized. This situation is considered to be
considered to be unrealistic because, for this to happen, each system unrealistic because, for this to happen, each system would have to
would have to have only the other system available as a time source, have only the other system available as a time source, for example,
for example, in a misconfigured "orphan mode" setup. There is no in a misconfigured "orphan mode" setup. There is no risk of this
risk of this happening in an NTP network with 3 or more time sources, happening in an NTP network with 3 or more time sources, or in a
or in a properly-configured "time island" setup. properly-configured "time island" setup.
3.3. Questions
Should we reference the REFID Suggestion and I-DO proposals here?
4. Acknowledgements 4. Acknowledgements
For the "not-you" REFID, we acknowledge useful discussions with For the "not-you" REFID, we acknowledge useful discussions with
Aanchal Malhotra and Matthew Van Gundy. Aanchal Malhotra and Matthew Van Gundy.
For the IPv6 REFID, we acknowledge Dan Mahoney (and perhaps others) For the IPv6 REFID, we acknowledge Dan Mahoney (and perhaps others)
for suggesting the idea of using an "impossible" first-octet value to for suggesting the idea of using an "impossible" first-octet value to
indicate an IPv6 refid hash. indicate an IPv6 refid hash.
skipping to change at page 7, line 6 skipping to change at page 6, line 49
"IPv6 REFID Hash" is supported. "IPv6 REFID Hash" is supported.
6. Security Considerations 6. Security Considerations
Many systems running NTP are configured to return responses to timing Many systems running NTP are configured to return responses to timing
queries by default. These responses contain a REFID field, which queries by default. These responses contain a REFID field, which
generally reveals the address of the system's time source if that generally reveals the address of the system's time source if that
source is an IPv4 address. This behavior can be exploited by remote source is an IPv4 address. This behavior can be exploited by remote
attackers who wish to first learn the address of a target's time attackers who wish to first learn the address of a target's time
source, and then attack the target and/or its time source. As such, source, and then attack the target and/or its time source. As such,
the "not-you" REFID proposal is designed to harden NTP against these the NOT-YOU REFID proposal is designed to harden NTP against these
attacks by limiting the amount of information leaked in the REFID attacks by limiting the amount of information leaked in the REFID
field. field.
Systems running NTP should reveal the identity of their system in Systems running NTP should reveal the identity of their system in
peer in their REFID only when they are on a trusted network. The peer in their REFID only when they are on a trusted network. The
IPv6 REFID proposal provides one way to do this, when the system peer IPv6 REFID proposal provides one way to do this, when the system peer
uses addresses in the IPv6 family. uses addresses in the IPv6 family.
7. References 7. References
skipping to change at page 7, line 37 skipping to change at page 7, line 32
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
7.2. Informative References 7.2. Informative References
[CVE-2015-8138] [CVE-2015-8138]
Van Gundy, M. and J. Gardner, "Network Time Protocol Van Gundy, M. and J. Gardner, "Network Time Protocol
Origin Timestamp Check Impersonation Vulnerability (CVE- Origin Timestamp Check Impersonation Vulnerability (CVE-
2015-8138)", in TALOS VULNERABILITY REPORT (TALOS- 2015-8138)", in TALOS VULNERABILITY REPORT (TALOS-
2016-0077), 2016. 2016-0077), 2016.
[DRAFT-I-DO]
Stenn, H., "draft-stenn-ntp-i-do", 2018.
[DRAFT-REFID-SUGGESTION]
Stenn, H., "draft-stenn-ntp-suggest-refid", 2018.
[NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg,
"Attacking the Network Time Protocol", in ISOC Network and "Attacking the Network Time Protocol", in ISOC Network and
Distributed System Security Symposium 2016 (NDSS'16), Distributed System Security Symposium 2016 (NDSS'16),
2016. 2016.
Authors' Addresses [NTP-EXTENSION-FIELD]
Stenn, H., "draft-stenn-ntp-extension-fields", 2018.
Authors' Addresses
Harlan Stenn Harlan Stenn
Network Time Foundation Network Time Foundation
P.O. Box 918 P.O. Box 918
Talent, OR 97540 Talent, OR 97540
US US
Email: stenn@nwtime.org Email: stenn@nwtime.org
Sharon Goldberg Sharon Goldberg
Boston University Boston University
111 Cummington St 111 Cummington St
Boston, MA 02215 Boston, MA 02215
US US
Email: goldbe@cs.bu.edu Email: goldbe@cs.bu.edu
 End of changes. 24 change blocks. 
65 lines changed or deleted 63 lines changed or added

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