Network Time Protocol Best Current Practices
draft-reilly-ntp-bcp-00

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

Abstract

   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.

Status of This Memo

   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 Notice

   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.

Reilly                   Expires March 21, 2016                 [Page 1]
Internet-Draft          Network Time Protocol BCP         September 2015

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Keeping NTP up to date  . . . . . . . . . . . . . . . . . . .   2
   3.  General Network Security Best Prectices . . . . . . . . . . .   3
     3.1.  BCP 38  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  NTP Configuration Best Practices  . . . . . . . . . . . . . .   3
     4.1.  Mode 7  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Autokey . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.3.  Using Pool Servers  . . . . . . . . . . . . . . . . . . .   4
     4.4.  Starting, Cold-Starting, and Re-Starting NTP  . . . . . .   4
   5.  NTP in Embedded Devices . . . . . . . . . . . . . . . . . . .   4
     5.1.  Updating Embedded Devices . . . . . . . . . . . . . . . .   5
     5.2.  KISS Packets  . . . . . . . . . . . . . . . . . . . . . .   5
     5.3.  Server configuration  . . . . . . . . . . . . . . . . . .   5
       5.3.1.  Get a vendor subdomain for pool.ntp.org . . . . . . .   5
   6.  NTP Deployment Examples . . . . . . . . . . . . . . . . . . .   6
     6.1.  Client-Only configuration . . . . . . . . . . . . . . . .   6
     6.2.  Server-Only Configuration . . . . . . . . . . . . . . . .   6
     6.3.  Anycast . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   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.

1.1.  Requirements Language

   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].

2.  Keeping NTP up to date

   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.

Reilly                   Expires March 21, 2016                 [Page 2]
Internet-Draft          Network Time Protocol BCP         September 2015

   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 .

3.  General Network Security Best Prectices

   NTP deployments are only as secure as the network they are running
   on.

3.1.  BCP 38

   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 .

4.  NTP Configuration Best Practices

   NTP can be made more secure by making a few simple changes to the
   ntp.conf file.

Reilly                   Expires March 21, 2016                 [Page 3]
Internet-Draft          Network Time Protocol BCP         September 2015

4.1.  Mode 7

   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

4.2.  Autokey

   Editor's Note: Someone who is smarter than I am will have to write
   this one.

4.3.  Using Pool Servers

   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.

4.4.  Starting, Cold-Starting, and Re-Starting NTP

   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!

5.  NTP in Embedded Devices

   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

Reilly                   Expires March 21, 2016                 [Page 4]
Internet-Draft          Network Time Protocol BCP         September 2015

   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.

5.1.  Updating Embedded Devices

   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?)

5.2.  KISS Packets

   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.

5.3.  Server configuration

   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.

5.3.1.  Get a vendor subdomain for pool.ntp.org

   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

Reilly                   Expires March 21, 2016                 [Page 5]
Internet-Draft          Network Time Protocol BCP         September 2015

   participate.  For more information, visit http://www.pool.ntp.org/en/
   vendors.html .

6.  NTP Deployment Examples

   A few examples of interesting NTP Deployments

6.1.  Client-Only configuration

   TBD

6.2.  Server-Only Configuration

   TBD

6.3.  Anycast

   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.

Reilly                   Expires March 21, 2016                 [Page 6]
Internet-Draft          Network Time Protocol BCP         September 2015

7.  Acknowledgements

   The author wishes to acknowledge the contributions of Harlan Stenn,
   Sue Graves, Samuel Weiler, and Karen O'Donoghue.

8.  IANA Considerations

   This memo includes no request to IANA.

9.  Security Considerations

   TBD

10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [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, <http://www.rfc-editor.org/info/rfc2827>.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
              December 2006, <http://www.rfc-editor.org/info/rfc4786>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <http://www.rfc-editor.org/info/rfc5905>.

   [RFC7094]  McPherson, D., Oran, D., Thaler, D., and E. Osterweil,
              "Architectural Considerations of IP Anycast", RFC 7094,
              DOI 10.17487/RFC7094, January 2014,
              <http://www.rfc-editor.org/info/rfc7094>.

Author's Address

   Denis Reilly
   Spectracom Corporation
   1565 Jefferson Road, Suite 460
   Rochester, NY  14623
   US

   Email: denis.reilly@spectracom.orolia.com

Reilly                   Expires March 21, 2016                 [Page 7]