| Internet Engineering Task Force | D. Reilly |
| Internet-Draft | Spectracom Corporation |
| Intended status: Best Current Practice | September 18, 2015 |
| Expires: March 21, 2016 |
Network Time Protocol Best Current Practices
draft-reilly-ntp-bcp-00
NTP Version 4 (NTPv4) has been widely used since its publication as RFC 5905 [RFC5905]. This documentation is a collection of Best Practices from across the NTP community.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 21, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
NTP Version 4 (NTPv4) has been widely used since its publication as RFC 5905 [RFC5905]. This documentation is a collection of Best Practices from across the NTP community.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
No software (not even NTP) is perfect. Bugs can be present in any software. As software is widely deployed, users find more bugs. And even if software is thoroughly tested and "all" the bugs are wrung out, users continuously find new ways to use software that their authors did not conceive of, which can uncover more bugs. Thousands of individual bugs have been found and fixed in the NTPv4 reference implementation since the first release in 1997.
In addition, there are always new ideas about security on the Internet, and an application which is secure today could be insecure tomorrow once an unknown bug (or a known behavior) is exploited in the right way. Many security mechanisms rely on time, either directly or indirectly, as part of their operation. If an attacker can spoof the time, they may be able to bypass or neutralize other security elements.
In general, the best way to protect yourself and your networks against these bugs and security threats is to make sure that you keep your NTP implementation up to date. The NTP protocol has many different implementations on many different platforms. It is advised that NTP users actively monitor wherever they get their software to find out when updates are available, and deploy them as soon as practical.
The original implementation of NTP Version 4 is still actively maintained and being developed by Network Time Foundation with help from volunteers. The Network Time Foundation currently maintains the reference implementation for NTP at http://www.ntp.org/downloads.html and also at https://github.com/ntp-project/ntp .
NTP deployments are only as secure as the network they are running on.
Many network attacks rely on modifying the IP source address of a packet to point to a different IP address than the computer which originated it. This behavior has been known for quite some time, and BCP 38 [RFC2827] was approved to address this in 2000. This document calls for filtering incoming traffic to make sure that the source IP address is consistent with the networks that are connected to that interface. It's recommended that all large networks (and ISP's of any size) implement this. More information is availavle at http://www.bcp38.info .
NTP can be made more secure by making a few simple changes to the ntp.conf file.
NTP Mode 7 packets can be used as a vehicle for a Denial of Service Attack. Users can prevent their NTP servers from participating by adding the following to their ntp.conf file:
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
Editor's Note: Someone who is smarter than I am will have to write this one.
It only takes a small amount of bandwidth to synchronize one NTP client, but NTP servers that can service tens of thousands of clients can take considerable resources to run. Users who want to synchronize their computers should only synchronize to servers that they have permission to use.
The NTP pool project is a collection of volunteers who have donated their compting and bandwidth resources to provide time on the Internet for free. The time is generally of good quality, but comes with no guarantee whatsoever. If you are interested in using the pool, please review their instrutions at http://www.pool.ntp.org/en/use.html .
If you want to synchronize multiple computers using the pool, consider running your own NTP server, synchronizing that to the pool, and synchronizing your clients to your in-house NTP server. This reduces the load on the pool.
Only use -g on cold-start. Other things TBD.
Editor's Note: I think I'd like to expand this a bit to cover how to deal with NTP stopping, when to restart it, and under what circumstances to not restart it!
Readers of this BCP already understand how important accurate time is for network computing. And as computing becomes more ubiquitous, there will be many small "Internet of Things" devices that require accurate time. These embedded devices may not have a traditional user interface, but if they connect to the Internet they will be subject to the same security threats as traditional deployments.
Vendors of embedded devices have a special responsibility to pay attention to the current state of NTP bugs and security issues, because their customers usually don't have the ability to update their NTP implementation on their own. Those devices may have a single firmware upgrade, provided by the manufacturer, that updates all capabilities at once. This means that the vendor essentially assumes the responsibility of making sure their devices have the latest NTP updates applied.
This should also include the ability to update the NTP server address.
(Note: do we find specific historical instances of devices behaving badly and cite them here?)
The "Kiss-o'-Death" packet is a rate limiting mechanism where a server can tell a misbehaving client to "back off" its query rate. It is important for all NTP devices to respect these packets and back off when asked to do so by a server. It is even more important for an embedded device, which may not have exposed a control interface for NTP.
Vendors of embedded devices that need time synchronization should also carefully consider where they get their time from. There are several public-facing NTP servers available, but they may not be prepared to service requests from thousands of new devices on the Internet.
Vendors are encouraged to invest resources into providing their own time servers for their devices.
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 ability to safely make use of the time distributed by the Pool for their devices. Vendors are encouraged to support the pool if they participate. For more information, visit http://www.pool.ntp.org/en/vendors.html .
A few examples of interesting NTP Deployments
TBD
TBD
Anycast is described in BCP 126 [RFC4786]. (Also see RFC 7094 [RFC7094]). With anycast, a single IP address is assigned to multiple interfaces, and routers direct packets to the closest active interface.
Anycast is often used for Internet services at known IP addresses, such as DNS. Anycast can also be used in large organizations to simplify configuration of a large number of NTP clients. Each client can be configured to the same IP address, and a pool of anycast servers can be deployed to service those requests. New servers can be added to or taken from the pool, and other than a temporary loss of service while a server is taken down, these additions can be transparent to the clients.
While clients are connected to an NTP server via anycast, the client does not know which particular server they are connected to. And as anycast servers enter and leave the network, the server a particular client is connected to may change, which can cause temporary problems on the client. It is recommended that anycast is deployed in environments where precision synchronization is not required.
A client also may not have any way to diagnose if an anycast server is not functioning properly. It is recommended that any anycast NTP implementation include multiple interfaces with at least one Unicast address. These Unicast addresses should be monitored (perhaps in a peering arrangement) so that if one server's reference goes bad, it can use the other servers to validate the correct time.
The author wishes to acknowledge the contributions of Harlan Stenn, Sue Graves, Samuel Weiler, and Karen O'Donoghue.
This memo includes no request to IANA.
TBD
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC2827] | Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000. |
| [RFC4786] | Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006. |
| [RFC5905] | Mills, D., Martin, J., Burbank, J. and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010. |
| [RFC7094] | McPherson, D., Oran, D., Thaler, D. and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014. |