draft-ietf-ntp-bcp-05.txt   draft-ietf-ntp-bcp-06.txt 
Internet Engineering Task Force D. Reilly, Ed. Internet Engineering Task Force D. Reilly, Ed.
Internet-Draft Spectracom Internet-Draft Spectracom
Intended status: Best Current Practice H. Stenn Intended status: Best Current Practice H. Stenn
Expires: December 15, 2017 Network Time Foundation Expires: June 17, 2018 Network Time Foundation
D. Sibold D. Sibold
PTB PTB
June 13, 2017 December 14, 2017
Network Time Protocol Best Current Practices Network Time Protocol Best Current Practices
draft-ietf-ntp-bcp-05 draft-ietf-ntp-bcp-06
Abstract Abstract
NTP Version 4 (NTPv4) has been widely used since its publication as NTP Version 4 (NTPv4) has been widely used since its publication as
RFC 5905 [RFC5905]. This documentation is a collection of Best RFC 5905 [RFC5905]. This documentation is a collection of Best
Practices from across the NTP community. Practices from across the NTP community.
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 December 15, 2017. This Internet-Draft will expire on June 17, 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
(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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 5, line 51 skipping to change at page 5, line 51
When using servers with attached hardware reference clocks, it is When using servers with attached hardware reference clocks, it is
recommended that several different types of reference clocks be used. recommended that several different types of reference clocks be used.
Having a diversity of sources means that any one issue is less likely Having a diversity of sources means that any one issue is less likely
to cause a service interruption. to cause a service interruption.
Are all clocks on a network from the same vendor? They may have the Are all clocks on a network from the same vendor? They may have the
same bugs. Are they using the same base chipset, regardless of same bugs. Are they using the same base chipset, regardless of
whether or not the finished products are from different vendors? Are whether or not the finished products are from different vendors? Are
they all running the same version of firmware? Chipset and firmware they all running the same version of firmware? Chipset and firmware
bugs can happen, but is often more difficult to diagnose than a bugs can happen, but they can be more difficult to diagnose than
standard software bug. application software bugs.
A systemic problem with time from any satellite navigation service is A systemic problem with time from any satellite navigation service is
possible and has happened. Sunspot activity can render satellite or possible and has happened. Sunspot activity can render satellite or
radio-based time source unusable. If the time on your network must radio-based time source unusable. If the time on your network must
be correct close to 100% of the time, then even if you are using a be correct close to 100% of the time, then even if you are using a
satellite-based system, you must plan for those rare instances when satellite-based system, you must plan for those rare instances when
the system is unavailable (or wrong!). the system is unavailable (or wrong!).
4.3. Mode 6 and 7 4.3. Mode 6 and 7
skipping to change at page 8, line 18 skipping to change at page 8, line 18
synchronize one NTP client, but NTP servers that can service tens of synchronize one NTP client, but NTP servers that can service tens of
thousands of clients take more resources to run. Users who want to thousands of clients take more resources to run. Users who want to
synchronize their computers should only synchronize to servers that synchronize their computers should only synchronize to servers that
they have permission to use. they have permission to use.
The NTP pool project is a group of volunteers who have donated their The NTP pool project is a group of volunteers who have donated their
computing and bandwidth resources to freely distribute time from computing and bandwidth resources to freely distribute time from
primary time sources to others on the Internet. The time is primary time sources to others on the Internet. The time is
generally of good quality, but comes with no guarantee whatsoever. generally of good quality, but comes with no guarantee whatsoever.
If you are interested in using the pool, please review their If you are interested in using the pool, please review their
instructions at http://www.pool.ntp.org/en/use.html. instructions at http://www.pool.ntp.org/en/use.html [5].
If you are a vendor who wishes to provide time service to your If you are a vendor who wishes to provide time service to your
customers or clients, consider joining the pool and providing a customers or clients, consider joining the pool and providing a
"vendor zone" thru the pool project. "vendor zone" through the pool project.
If you want to synchronize many computers, consider running your own If you want to synchronize many computers, consider running your own
NTP servers that are synchronized by the pool, and synchronizing your NTP servers that are synchronized by the pool, and synchronizing your
clients to your in-house NTP servers. This reduces the load on the clients to your in-house NTP servers. This reduces the load on the
pool. pool.
If you would like to contribute a server with a static IP address and If you would like to contribute a server with a static IP address and
a permanent Internet conenction to the pool, please consult the a permanent Internet connection to the pool, please consult the
instructions at http://www.pool.ntp.org/en/join.html . instructions at http://www.pool.ntp.org/en/join.html [6] .
4.6. Leap Second Handling 4.6. Leap Second Handling
UTC is kept in agreement with the astronomical time UT1 [7] to within UTC is kept in agreement with the astronomical time UT1 [7] to within
+/- 0.9 seconds by the insertion (or possibly a deletion) of a leap +/- 0.9 seconds by the insertion (or possibly a deletion) of a leap
second. UTC is an atomic time scale whereas UT1 is based on the second. UTC is an atomic time scale whereas UT1 is based on the
rotational rate of the earth. Leap seconds are not introduced at a rotational rate of the earth. Leap seconds are not introduced at a
fixed rate. They are announced by the IERS (International Earth fixed rate. They are announced by the IERS (International Earth
rotation and Reference systems Service) in its Bulletin C [8] when rotation and Reference systems Service) in its Bulletin C [8] when
necessary to keep UTC and UT1 aligned. necessary to keep UTC and UT1 aligned.
skipping to change at page 9, line 5 skipping to change at page 9, line 5
capability to broadcast leap second information. Some GNSS systems capability to broadcast leap second information. Some GNSS systems
(like GPS) or radio transmitters (like DCF77) broadcast leap second (like GPS) or radio transmitters (like DCF77) broadcast leap second
information, so if you are synced to an ntp server that is ultimately information, so if you are synced to an ntp server that is ultimately
synced to a source that provides leap second notification you will synced to a source that provides leap second notification you will
get advance notification of impending leap seconds automatically. get advance notification of impending leap seconds automatically.
Since the length of the UT1 day is generally slowly increasing [9], Since the length of the UT1 day is generally slowly increasing [9],
all leap seconds that have been introduced since the practice started all leap seconds that have been introduced since the practice started
in 1972 have been "positive" leap seconds, where a second is added to in 1972 have been "positive" leap seconds, where a second is added to
UTC. NTP also supports a "negative" leap second, where a second is UTC. NTP also supports a "negative" leap second, where a second is
removed from UTC, should that ever become necessary (or useful). removed from UTC, should that ever become necessary.
While earlier versions of NTP contained some ambiguity regarding when While earlier versions of NTP contained some ambiguity regarding when
a leap second that is broadcast by a server should be applied by a a leap second that is broadcast by a server should be applied by a
client, RFC 5905 is clear that leap seconds are only applied on the client, RFC 5905 is clear that leap seconds are only applied on the
last day of a month. However, because some older clients may apply last day of a month. However, because some older clients may apply
it at the end of the current day, it is recommended that NTP servers it at the end of the current day, it is recommended that NTP servers
wait until the last day of the month before broadcasting leap wait until the last day of the month before broadcasting leap
seconds. Doing this will prevent older clients from applying a leap seconds. Doing this will prevent older clients from applying a leap
second at the wrong time. Note well that NTPv4 allows a maximum poll second at the wrong time. Note well that NTPv4 allows a maximum poll
interval of 17, or 131,072 seconds, which is longer than a day. interval of 17, or 131,072 seconds, which is longer than a day.
skipping to change at page 11, line 16 skipping to change at page 11, line 16
same leap smear configuration. same leap smear configuration.
4.7. Configuring ntpd 4.7. Configuring ntpd
Configuration access to ntpd is controlled by the "modify" status in Configuration access to ntpd is controlled by the "modify" status in
NTP's configuration file (ntp.conf), which is controlled by a NTP's configuration file (ntp.conf), which is controlled by a
"restrict" statement. The syntax is: "restrict" statement. The syntax is:
restrict address mask address_mask nomodify restrict address mask address_mask nomodify
See https://support.ntp.org/bin/view/Support/ConfiguringNTP for See https://support.ntp.org/bin/view/Support/ConfiguringNTP [12] for
additional information on configuring ntpd. additional information on configuring ntpd.
5. NTP Security Mechanisms 5. NTP Security Mechanisms
In the standard configuration NTP packets are exchanged unprotected In the standard configuration NTP packets are exchanged unprotected
between client and server. An adversary that is able to become a between client and server. An adversary that is able to become a
Man-In-The-Middle is therefore able to drop, replay or modify the Man-In-The-Middle is therefore able to drop, replay or modify the
content of the NTP packet, which leads to degradation of the time content of the NTP packet, which leads to degradation of the time
synchronization or the transmission of false time information. A synchronization or the transmission of false time information. A
profound threat analysis for time synchronization protocols are given profound threat analysis for time synchronization protocols are given
in RFC 7384 [RFC7384]. NTP provides two internal security mechanisms in RFC 7384 [RFC7384]. NTP provides two internal security mechanisms
to protect authenticity and integrity of the NTP packets. Both to protect authenticity and integrity of the NTP packets. Both
measures protect the NTP packet by means of a Message Authentication measures protect the NTP packet by means of a Message Authentication
Code (MAC). Neither of them encrypts the NTP's payload, because this Code (MAC). Neither of them encrypts the NTP's payload, because this
payload information is not considered to be confidential. payload information is not considered to be confidential.
5.1. Pre-Shared Key Approach 5.1. Pre-Shared Key Approach
This approach applies a symmetric key for the calculation of the MAC, This approach applies a symmetric key for the calculation of the MAC,
which protects authenticity and integrity of the exchanged packets which protects authenticity and integrity of the exchanged packets
for a association. NTP does not provide a mechanism for the exchange for an association. NTP does not provide a mechanism for the
of the keys between the associated nodes. Therefore, for each exchange of the keys between the associated nodes. Therefore, for
association, keys have to be exchanged securely by external means. each association, keys have to be exchanged securely by external
It is recommended that each association be protected by its own means. It is recommended that each association be protected by its
unique key. NTP does not provide a mechanism to automatically own unique key. NTP does not provide a mechanism to automatically
refresh the applied keys. It is therefore recommended that the refresh the applied keys. It is therefore recommended that the
participants periodically agree on a fresh key. The calculation of participants periodically agree on a fresh key. The calculation of
the MAC may always be based on an MD5 hash, and an AES-128-CMAC hash the MAC may always be based on an MD5 hash, and an AES-128-CMAC hash
is expected to soon be allowed as well. If the NTP daemon is built is expected to soon be allowed as well. If the NTP daemon is built
against an OpenSSL library, NTP can also base the calculation of the against an OpenSSL library, NTP can also base the calculation of the
MAC upon any other digest algorithm supported by each side's OpenSSL MAC upon any other digest algorithm supported by each side's OpenSSL
library. library.
To use this approach the communication partners have to exchange the To use this approach the communication partners have to exchange the
key, which consists of a keyid with a value between 1 and 65534, key, which consists of a keyid with a value between 1 and 65534,
inclusive, and a label which indicates the chosen digest algorithm. inclusive, and a label which indicates the chosen digest algorithm.
Each communication partner adds this information to their key file in Each communication partner adds this information to their key file in
the form: the form:
keyid label key keyid label key
The key file contains the key in clear text. Therefore it should The key file contains the key in clear text. Therefore it should
only be readable by the NTP process. Different keys are added line only be readable by the NTP process. Different keys are added line
by line to the key file. by line to the key file.
A NTP client establishes a protected association by appending the An NTP client establishes a protected association by appending the
option "key keyid" to the server statement in the NTP configuration option "key keyid" to the server statement in the NTP configuration
file: file:
server address key keyid server address key keyid
Note that the NTP process has to trust the applied key. A key is Note that the NTP process has to trust the applied key. A key is
deemed trusted when its keyid is added to the list of trusted keys by deemed trusted when its keyid is added to the list of trusted keys by
the "trustedkey" statement in the NTP configuration file. the "trustedkey" statement in the NTP configuration file.
trustedkey keyid_1 keyid_2 ... keyid_n trustedkey keyid_1 keyid_2 ... keyid_n
skipping to change at page 12, line 37 skipping to change at page 12, line 37
Autokey was designed in 2003 to provide a means for clients to Autokey was designed in 2003 to provide a means for clients to
authenticate servers. However, security researchers have identified authenticate servers. However, security researchers have identified
vulnerabilities in the Autokey protocol, which make the protocol vulnerabilities in the Autokey protocol, which make the protocol
"useless". [13] "useless". [13]
Autokey SHOULD NOT BE USED. Autokey SHOULD NOT BE USED.
5.3. Network Time Security 5.3. Network Time Security
Work has begun on an enhanced replacement for Autokey, which is Work is in progress on an enhanced replacement for Autokey, which is
called Network Time Security (NTS) [NTS]. NTS was published in the called Network Time Security (NTS) [NTSFORNTP]. As of December 2017,
summer of 2013. As of October 2016, this effort was at draft #15, this effort was at draft #10, and in in the 'final call' process.
and about to begin 'final call'. The first unicast implementation of Readers are encouraged to adopt its mechanisms.
NTS was started in the summer of 2015 and is expected to be released
in early 2017.
6. NTP Security Best Practices 6. NTP Security Best Practices
6.1. Minimizing Information Leakage 6.1. Minimizing Information Leakage
The base NTP packet leaks important information (including reference The base NTP packet leaks important information (including reference
ID and reference time) that may be used in attacks [NDSS16], ID and reference time) that may be used in attacks [NDSS16],
[CVE-2015-8138], [CVE-2016-1548]. A remote attacker can learn this [CVE-2015-8138], [CVE-2016-1548]. A remote attacker can learn this
information by sending mode 3 queries to a target system and information by sending mode 3 queries to a target system and
inspecting the fields in the mode 4 response packet. NTP control inspecting the fields in the mode 4 response packet. NTP control
skipping to change at page 13, line 22 skipping to change at page 13, line 20
information to inappropriate third parties. information to inappropriate third parties.
Hosts should only respond to NTP control queries from authorized Hosts should only respond to NTP control queries from authorized
parties. One way to do this is to only allow control queries from parties. One way to do this is to only allow control queries from
authenticated sources via authorized IP addresses. authenticated sources via authorized IP addresses.
A host that is not supposed to act as an NTP server that provides A host that is not supposed to act as an NTP server that provides
timing information to other hosts may additionally log and drop timing information to other hosts may additionally log and drop
incoming mode 3 timing queries from unexpected sources. Note well incoming mode 3 timing queries from unexpected sources. Note well
that the easiest way to monitor ntpd's status is to send it a mode 3 that the easiest way to monitor ntpd's status is to send it a mode 3
query. A much better appropach might be to filter mode 3 queries at query. A much better approach might be to filter mode 3 queries at
the edge, or make sure mode 3 queries are allowed from trusted the edge, or make sure mode 3 queries are allowed only from trusted
systems or networks. systems or networks.
An "leaf-node host" is host that is using NTP solely for the purpose A "leaf-node host" is a host that is using NTP solely for the purpose
of adjusting its own system time. Such a host is not expected to of adjusting its own system time. Such a host is not expected to
provide time to other hosts, and relies exclusively on NTP's basic provide time to other hosts, and relies exclusively on NTP's basic
mode to take time from a set of servers. (That is, the host sends mode to take time from a set of servers. (That is, the host sends
mode 3 queries to its servers and receives mode 4 responses from mode 3 queries to its servers and receives mode 4 responses from
these servers containing timing information.) To minimize these servers containing timing information.) To minimize
information leakage, leaf-node hosts should drop all incoming NTP information leakage, leaf-node hosts should drop all incoming NTP
packets except mode 4 response packets that come from unknown packets except mode 4 response packets that come from unknown
sources. Note well that proper monitoring of an ntpd instance sources. Note well that proper monitoring of an ntpd instance
includes checking the time of that ntpd instance. includes checking the time of that ntpd instance.
skipping to change at page 15, line 5 skipping to change at page 14, line 49
6.3. Detection of Attacks Through Monitoring 6.3. Detection of Attacks Through Monitoring
Users should monitor their NTP instances to detect attacks. Many Users should monitor their NTP instances to detect attacks. Many
known attacks on NTP have particular signatures. Common attack known attacks on NTP have particular signatures. Common attack
signatures include: signatures include:
1. "Bogus packets" - A packet whose origin timestamp does not match 1. "Bogus packets" - A packet whose origin timestamp does not match
the value that expected by the client. the value that expected by the client.
2. "Zero origin packet" - A packet with a origin timestamp set to 2. "Zero origin packet" - A packet with an origin timestamp set to
zero [CVE-2015-8138]. zero [CVE-2015-8138].
3. A packet with an invalid cryptographic MAC [CCR16]. 3. A packet with an invalid cryptographic MAC [CCR16].
The observation of many such packets could indicate that the client The observation of many such packets could indicate that the client
is under attack. is under attack.
Also, Kiss-o'-Death (KoD) packets can be used in denial of service Also, Kiss-o'-Death (KoD) packets can be used in denial of service
attacks. Thus, the observation of even just one KoD packet with a attacks. Thus, the observation of even just one KoD packet with a
high poll value could be sign that the client is under attack. See high poll value could be sign that the client is under attack. See
skipping to change at page 17, line 51 skipping to change at page 17, line 51
Vendors are encouraged to invest resources into providing their own Vendors are encouraged to invest resources into providing their own
time servers for their devices to connect to. time servers for their devices to connect to.
7.2.1. Get a vendor subdomain for pool.ntp.org 7.2.1. Get a vendor subdomain for pool.ntp.org
The NTP Pool Project offers a program where vendors can obtain their The NTP Pool Project offers a program where vendors can obtain their
own subdomain that is part of the NTP Pool. This offers vendors the own subdomain that is part of the NTP Pool. This offers vendors the
ability to safely make use of the time distributed by the Pool for ability to safely make use of the time distributed by the Pool for
their devices. Vendors are encouraged to support the pool if they their devices. Vendors are encouraged to support the pool if they
participate. For more information, visit http://www.pool.ntp.org/en/ participate. For more information, visit http://www.pool.ntp.org/en/
vendors.html . vendors.html [15] .
8. NTP over Anycast 8. NTP over Anycast
Anycast is described in BCP 126 [RFC4786]. (Also see RFC 7094 Anycast is described in BCP 126 [RFC4786]. (Also see RFC 7094
[RFC7094]). With anycast, a single IP address is assigned to [RFC7094]). With anycast, a single IP address is assigned to
multiple interfaces, and routers direct packets to the closest active multiple interfaces, and routers direct packets to the closest active
interface. interface.
Anycast is often used for Internet services at known IP addresses, Anycast is often used for Internet services at known IP addresses,
such as DNS. Anycast can also be used in large organizations to such as DNS. Anycast can also be used in large organizations to
skipping to change at page 19, line 36 skipping to change at page 19, line 36
Time is a fundamental component of security on the internet. Time is a fundamental component of security on the internet.
Credentials and certificates can expire. Logins and other forms of Credentials and certificates can expire. Logins and other forms of
access can be revoked after a period of time, or at a scheduled time. access can be revoked after a period of time, or at a scheduled time.
And some applications may assume that system time cannot be changed And some applications may assume that system time cannot be changed
and is always monotonic, and vulnerabilites may be exposed if a time and is always monotonic, and vulnerabilites may be exposed if a time
in the past is forced into a system. Therefore, any system in the past is forced into a system. Therefore, any system
adminstrator concerned with security should be concerned with how the adminstrator concerned with security should be concerned with how the
current time gets into their system. current time gets into their system.
[NTS] is an Internet-Draft of a collection of methods to secure time [NTSFORNTP] is an Internet-Draft that specifies the Network Time
transfer over networks. [NTSFORNTP] is an Internet-Draft that Security (NTS) mechanism and applies it specifically to NTP. Readers
applies the methods in [NTS] specifically to NTP. At the time of are encouraged to check the status of the draft, and make use of the
this writing, these are still drafts. Readers are encourages to methods it describes.
check the status of these drafts, and make use of the methods they
describe.
12. References 12. References
12.1. Normative References 12.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>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <http://www.rfc-editor.org/info/rfc4786>. December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[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>.
[RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
"Architectural Considerations of IP Anycast", RFC 7094, "Architectural Considerations of IP Anycast", RFC 7094,
DOI 10.17487/RFC7094, January 2014, DOI 10.17487/RFC7094, January 2014,
<http://www.rfc-editor.org/info/rfc7094>. <https://www.rfc-editor.org/info/rfc7094>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
12.2. Informative References 12.2. Informative References
[CCR16] Malhotra, A. and S. Goldberg, "Attacking NTP's [CCR16] Malhotra, A. and S. Goldberg, "Attacking NTP's
Authenticated Broadcast Mode", SIGCOMM Computer Authenticated Broadcast Mode", SIGCOMM Computer
Communications Review (CCR) , 2016. Communications Review (CCR) , 2016.
[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", 2016, ORIGIN TIMESTAMP CHECK IMPERSONATION VULNERABILITY", 2016,
skipping to change at page 21, line 9 skipping to change at page 21, line 9
vulnerability-spotlight-further-ntpd_27.html>. vulnerability-spotlight-further-ntpd_27.html>.
[MILLS2006] [MILLS2006]
Mills, D., "Computer network time synchronization: the Mills, D., "Computer network time synchronization: the
Network Time Protocol", CRC Press , 2006. Network Time Protocol", CRC Press , 2006.
[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", NDSS'16, San Diego, "Attacking the Network Time Protocol", NDSS'16, San Diego,
CA. , 2016, <https://eprint.iacr.org/2015/1020.pdf>. CA. , 2016, <https://eprint.iacr.org/2015/1020.pdf>.
[NTS] Sibold, D., Roettger, S., and K. Teichel, "Network Time
Security", draft-ietf-ntp-network-time-security-15 (work
in progress), September 2016.
[NTSFORNTP] [NTSFORNTP]
Sibold, D., Roettger, S., and K. Teichel, "Using the Sibold, D., Roettger, S., and K. Teichel, "Using the
Network Time Security Specification to Secure the Network Network Time Security Specification to Secure the Network
Time Protocol", draft-ietf-ntp-using-nts-for-ntp-06 (work Time Protocol", draft-ietf-ntp-using-nts-for-ntp-10 (work
in progress), September 2016. in progress), October 2017.
12.3. URIs 12.3. URIs
[1] http://www.ntp.org/downloads.html [1] http://www.ntp.org/downloads.html
[2] http://bk.ntp.org/ [2] http://bk.ntp.org/
[3] https://github.com/ntp-project/ntp [3] https://github.com/ntp-project/ntp
[4] http://www.bcp38.info [4] http://www.bcp38.info
[5] http://www.pool.ntp.org/en/use.html
[6] http://www.pool.ntp.org/en/join.html
[7] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time [7] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time
[8] https://www.iers.org/IERS/EN/Publications/Bulletins/ [8] https://www.iers.org/IERS/EN/Publications/Bulletins/
bulletins.html bulletins.html
[9] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time [9] https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time
[10] https://www.ietf.org/timezones/data/leap-seconds.list [10] https://www.ietf.org/timezones/data/leap-seconds.list
[11] http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno [11] http://bk1.ntp.org/ntp-stable/README.leapsmear?PAGE=anno
[12] https://support.ntp.org/bin/view/Support/ConfiguringNTP
[13] https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html [13] https://lists.ntp.org/pipermail/ntpwg/2011-August/001714.html
[14] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse [14] https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
Authors' Addresses [15] http://www.pool.ntp.org/en/vendors.html
Authors' Addresses
Denis Reilly (editor) Denis Reilly (editor)
Spectracom Spectracom
1565 Jefferson Road, Suite 460 1565 Jefferson Road, Suite 460
Rochester, NY 14623 Rochester, NY 14623
US US
Email: denis.reilly@spectracom.orolia.com Email: denis.reilly@spectracom.orolia.com
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
Dieter Sibold Dieter Sibold
Physikalisch-Technische Bundesanstalt Physikalisch-Technische Bundesanstalt
 End of changes. 33 change blocks. 
50 lines changed or deleted 50 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/