draft-ietf-ntp-refid-updates-00.txt   draft-ietf-ntp-refid-updates-01.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: May 17, 2017 Boston University Expires: June 2, 2018 Boston University
November 13, 2016 November 29, 2017
Network Time Protocol REFID Updates Network Time Protocol REFID Updates
draft-ietf-ntp-refid-updates-00 draft-ietf-ntp-refid-updates-01
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 36 skipping to change at page 1, line 36
smeared time. smeared time.
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 http://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 May 17, 2017. This Internet-Draft will expire on June 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
(http://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. 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 . . . . . . . . . . . . . . . 5 3. Augmenting the IPv6 REFID Hash . . . . . . . . . . . . . . . 6
3.1. Background . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Background . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Potential Problems . . . . . . . . . . . . . . . . . . . 6 3.2. Potential Problems . . . . . . . . . . . . . . . . . . . 6
3.3. Questions . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . 7
4.3. Questions . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Questions . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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-
skipping to change at page 3, line 39 skipping to change at page 3, line 39
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
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. 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.
The NOT-YOU REFID proposal does have a small risk, in that a system
that might return NOT-YOU does not have perfect information, and it
is possible that the remote system peer is contacting "us" via a
different network interface. In this case, the remote system might
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
stratum positions 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, until this
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 a trusted situation, an operator might well choose to expose the
real REFID. RFC 5905 [RFC5905], section 7.3, "Packet Header real REFID. RFC 5905 [RFC5905], section 7.3, "Packet Header
Variables", explains how a remote system peer is converted to a Variables", explains how a remote system peer is converted to a
REFID. It says: 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. ...
skipping to change at page 10, line 8 skipping to change at page 10, line 14
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.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
8.2. Informative References 8.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.
[NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, [NDSS16] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg,
 End of changes. 13 change blocks. 
14 lines changed or deleted 25 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/