draft-ietf-ntp-port-randomization-01.txt   draft-ietf-ntp-port-randomization-02.txt 
Network Time Protocol (ntp) Working Group F. Gont Network Time Protocol (ntp) Working Group F. Gont
Internet-Draft G. Gont Internet-Draft G. Gont
Updates: rfc5905 (if approved) SI6 Networks Updates: rfc5905 (if approved) SI6 Networks
Intended status: Standards Track M. Lichvar Intended status: Standards Track M. Lichvar
Expires: September 10, 2020 Red Hat Expires: October 18, 2020 Red Hat
March 9, 2020 April 16, 2020
Port Randomization in the Network Time Protocol Version 4 Port Randomization in the Network Time Protocol Version 4
draft-ietf-ntp-port-randomization-01 draft-ietf-ntp-port-randomization-02
Abstract Abstract
The Network Time Protocol can operate in several modes. Some of The Network Time Protocol can operate in several modes. Some of
these modes are based on the receipt of unsolicited packets, and these modes are based on the receipt of unsolicited packets, and
therefore require the use of a service/well-known port as the local therefore require the use of a service/well-known port as the local
port number. However, in the case of NTP modes where the use of a port number. However, in the case of NTP modes where the use of a
service/well-known port is not required, employing such well-known/ service/well-known port is not required, employing such well-known/
service port unnecessarily increases the ability of attackers to service port unnecessarily increases the ability of attackers to
perform blind/off-path attacks. This document formally updates perform blind/off-path attacks. This document formally updates
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 10, 2020. This Internet-Draft will expire on October 18, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 40 skipping to change at page 2, line 40
1. Introduction 1. Introduction
The Network Time Protocol (NTP) is one of the oldest Internet The Network Time Protocol (NTP) is one of the oldest Internet
protocols, and currently specified in [RFC5905]. Since its original protocols, and currently specified in [RFC5905]. Since its original
implementation, standardization, and deployment, a number of implementation, standardization, and deployment, a number of
vulnerabilities have been found both in the NTP specification and in vulnerabilities have been found both in the NTP specification and in
some of its implementations [NTP-VULN]. Some of these some of its implementations [NTP-VULN]. Some of these
vulnerabilities allow for off-path/blind attacks, where an attacker vulnerabilities allow for off-path/blind attacks, where an attacker
can send forged packets to one or both NTP peers for achieving Denial can send forged packets to one or both NTP peers for achieving Denial
of Service (DoS), time-shifts, and other undesirable outcomes. Many of Service (DoS), time-shifts, or other undesirable outcomes. Many
of these attacks require the attacker to guess or know at least a of these attacks require the attacker to guess or know at least a
target NTP association, typically identified by the tuple {srcaddr, target NTP association, typically identified by the tuple {srcaddr,
srcport, dstaddr, dstport, keyid}. Some of these parameters may be srcport, dstaddr, dstport, keyid}. Some of these parameters may be
easily known or guessed. easily known or guessed.
NTP can operate in several modes. Some of these modes rely on the NTP can operate in several modes. Some of these modes rely on the
ability of nodes to receive unsolicited packets, and therefore ability of nodes to receive unsolicited packets, and therefore
require the use of a service/well-known port number. However, for require the use of a service/well-known port number (123). However,
modes where the use of a service/well-known port is not required, for modes where the use of a service/well-known port is not required,
employing such well-known/service port improves the ability of an employing the well-known/service port improves the ability of an
attacker to perform blind/off-path attacks (since knowledge of such attacker to perform blind/off-path attacks (since knowledge of the
port number is typically required for such attacks). A recent study port numbers is typically required for such attacks). A recent study
[NIST-NTP] that analyzes the port numbers employed by NTP clients [NIST-NTP] that analyzes the port numbers employed by NTP clients
suggests that a considerable number of NTP clients employ the NTP suggests that a considerable number of NTP clients employ the NTP
service/well-known port as their local port, or select predictable service/well-known port as their local port, or select predictable
ephemeral port numbers, thus improving the ability of attackers to ephemeral port numbers, thus improving the ability of attackers to
perform blind/off-path attacks against NTP. perform blind/off-path attacks against NTP.
BCP 156 [RFC6056] already recommends the randomization of transport- BCP 156 [RFC6056] already recommends the randomization of transport-
protocol ephemeral ports. This document aligns NTP with the protocol ephemeral ports. This document aligns NTP with the
recommendation in BCP 156 [RFC6056], by formally updating [RFC5905] recommendation in BCP 156 [RFC6056], by formally updating [RFC5905]
such that port randomization is employed for those NTP modes for such that port randomization is employed for those NTP modes for
which the use of the NTP service port is not required. which the use of the NTP service port is not needed.
2. Terminology 2. Terminology
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Considerations About Port Randomization in NTP 3. Considerations About Port Randomization in NTP
The following subsections analyze a number of considerations about The following subsections analyze a number of considerations about
skipping to change at page 3, line 43 skipping to change at page 3, line 43
transport protocol instance (e.g., TCP connection) or an upper-layer transport protocol instance (e.g., TCP connection) or an upper-layer
protocol instance (e.g., an application protocol instance), the protocol instance (e.g., an application protocol instance), the
attacker is required to know or guess the five-tuple {Protocol, IP attacker is required to know or guess the five-tuple {Protocol, IP
Source Address, IP Destination Address, Source Port, Destination Source Address, IP Destination Address, Source Port, Destination
Port} that identifies the target transport protocol instance or the Port} that identifies the target transport protocol instance or the
transport protocol instance employed by the target upper-layer transport protocol instance employed by the target upper-layer
protocol instance. Therefore, increasing the difficulty of guessing protocol instance. Therefore, increasing the difficulty of guessing
this five-tuple helps mitigate blind/off-path attacks. this five-tuple helps mitigate blind/off-path attacks.
As a result of this considerations, BCP 156 [RFC6056] recommends the As a result of this considerations, BCP 156 [RFC6056] recommends the
randomization of transport-protocol ephemeral ports. And as such, randomization of transport-protocol ephemeral ports. Thus, this
this document aims to bring the NTP specification [RFC5905] in line document aims to bring the NTP specification [RFC5905] in line with
with the aforementioned recommendation. the aforementioned recommendation.
We note that the use of port randomization is a transport-layer We note that the use of port randomization is a transport-layer
mitigation against off-path/blind attacks, and does not preclude (nor mitigation against off-path/blind attacks, and does not preclude (nor
is it precluded by) other possible mitigations for off-path attacks is it precluded by) other possible mitigations for off-path attacks
that might be implemented by an application protocol (e.g. that might be implemented by an application protocol (e.g.
[I-D.ietf-ntp-data-minimization]). For instance, some of the [I-D.ietf-ntp-data-minimization]). For instance, some of the
aforementioned mitigations may be ineffective against some off-path aforementioned mitigations may be ineffective against some off-path
attacks [NTP-FRAG] or may benefit from the additional entropy attacks [NTP-FRAG] or may benefit from the additional entropy
provided by port randomization [NTP-security]. provided by port randomization [NTP-security].
skipping to change at page 4, line 36 skipping to change at page 4, line 36
clocks would be mitigated by the clock filter algorithm, which clocks would be mitigated by the clock filter algorithm, which
prefers samples with shorter delay. prefers samples with shorter delay.
On the other hand, if port-randomization is applied on a per- On the other hand, if port-randomization is applied on a per-
association basis, request/responses to the same association would association basis, request/responses to the same association would
likely follow the same path, since the IP addresses and transport likely follow the same path, since the IP addresses and transport
port numbers employed for an association would not change. This port numbers employed for an association would not change. This
would thus result in more stability of the measurements. would thus result in more stability of the measurements.
Section 4 recommends NTP implementations to randomize the ephemeral Section 4 recommends NTP implementations to randomize the ephemeral
port number of non-symmetrical associations on a per-association port number of non-symmetrical associations. The choice of whether
basis (as opposed to "per-request"), since this is believed to be the to randomize the port number on a per-association or a per-request
more conservative approach. However, implementations may override basis is left to the implementation.
this setting and perform port-randomization on a per-request basis.
3.3. Filtering of NTP traffic 3.3. Filtering of NTP traffic
In a number of scenarios (such as when mitigating DDoS attacks), a In a number of scenarios (such as when mitigating DDoS attacks), a
network operator may want to differentiate between NTP requests sent network operator may want to differentiate between NTP requests sent
by clients, and NTP responses sent by NTP servers. If an by clients, and NTP responses sent by NTP servers. If an
implementation employs the NTP service port for the client port implementation employs the NTP service port for the client port
number, requests/responses cannot be readily differentiated by number, requests/responses cannot be readily differentiated by
inspecting the source and destination port numbers. Implementation inspecting the source and destination port numbers. Implementation
of port randomization for non-symmetrical modes allows for simple of port randomization for non-symmetrical modes allows for simple
skipping to change at page 5, line 49 skipping to change at page 5, line 47
number PORT (123) assigned by the IANA. This becomes the source number PORT (123) assigned by the IANA. This becomes the source
port number in packets sent from this association. port number in packets sent from this association.
is replaced with: is replaced with:
dstport: UDP port number of the client. In the case of broadcast dstport: UDP port number of the client. In the case of broadcast
server mode (5) and symmetric modes (1 and 2), it SHOULD contain server mode (5) and symmetric modes (1 and 2), it SHOULD contain
the NTP port number PORT (123) assigned by the IANA. In other the NTP port number PORT (123) assigned by the IANA. In other
cases, it SHOULD contain a randomized port number, as specified in cases, it SHOULD contain a randomized port number, as specified in
[RFC6056]. The value in this variable becomes the source port [RFC6056]. The value in this variable becomes the source port
number of packets sent from this association. number of packets sent from this association. The randomized port
number SHOULD NOT be shared with other associations.
NOTES: NOTES:
When port randomization is employed, the port number SHOULD be
randomized on a per-association basis. That is, a random port The choice of whether to randomize the port number on a per-
number SHOULD selected when an association is first mobilized, request or a per-association basis is left to the
and the selected port number is expected to remain constant implementation, and should consider, among others, the
during the life of an association. An implementation MAY, considerations discussed in Section 3.2.
however, override this setting and employ port randomization on
a per-request basis.
On most current operating systems, which implement ephemeral On most current operating systems, which implement ephemeral
port randomization [RFC6056], an NTP client may normally rely port randomization [RFC6056], an NTP client may normally rely
on the operating system to perform port randomization. For on the operating system to perform port randomization. For
example, NTP implementations using POSIX sockets may achieve example, NTP implementations using POSIX sockets may achieve
port randomization by *not* binding the socket with the bind() port randomization by *not* binding the socket with the bind()
function, or binding it to port 0, which has a special meaning function, or binding it to port 0, which has a special meaning
of "any port". connect()ing the docket will make the port of "any port". connect()ing the socket will make the port
inaccessible by other systems (that is, only packets from the inaccessible by other systems (that is, only packets from the
specified remote socket will be received by the application). specified remote socket will be received by the application).
5. Implementation Status 5. Implementation Status
[RFC Editor: Please remove this section before publication of this [RFC Editor: Please remove this section before publication of this
document as an RFC.] document as an RFC.]
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
skipping to change at page 7, line 25 skipping to change at page 7, line 21
6. IANA Considerations 6. IANA Considerations
There are no IANA registries within this document. The RFC-Editor There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an can remove this section before publication of this document as an
RFC. RFC.
7. Security Considerations 7. Security Considerations
The security implications of predictable numeric identifiers The security implications of predictable numeric identifiers
[I-D.gont-predictable-numeric-ids] (and of predictable transport- [I-D.irtf-pearg-numeric-ids-generation] (and of predictable
protocol port numbers [RFC6056] in particular) have been known for a transport-protocol port numbers [RFC6056] in particular) have been
long time now. However, the NTP specification has traditionally known for a long time now. However, the NTP specification has
followed a pattern of employing common settings and code even when traditionally followed a pattern of employing common settings and
not strictly necessary, which at times has resulted in negative code even when not strictly necessary, which at times has resulted in
security and privacy implications (see e.g. negative security and privacy implications (see e.g.
[I-D.ietf-ntp-data-minimization]). The use of the NTP service port [I-D.ietf-ntp-data-minimization]). The use of the NTP service port
(123) for the srcport and dstport variables is not required for all (123) for the srcport and dstport variables is not required for all
operating modes, and such unnecessary usage comes at the expense of operating modes, and such unnecessary usage comes at the expense of
reducing the amount of work required for an attacker to successfully reducing the amount of work required for an attacker to successfully
perform off-path/blind attacks against NTP. Therefore, this document perform off-path/blind attacks against NTP. Therefore, this document
formally updates [RFC5905], recommending the use of transport- formally updates [RFC5905], recommending the use of transport-
protocol port randomization when use of the NTP service port is not protocol port randomization when use of the NTP service port is not
required. required.
This issue has been tracked by US-CERT with VU#597821, and has been This issue has been tracked by US-CERT with VU#597821, and has been
assigned CVE-2019-11331. assigned CVE-2019-11331.
8. Acknowledgments 8. Acknowledgments
Watson Ladd raised the problem of DDoS mitigation when the NTP
service port is employed as the client port (discussed in Section 3.3
of this document).
The authors would like to thank (in alphabetical order) Ivan Arce, The authors would like to thank (in alphabetical order) Ivan Arce,
Todd Glassey, Watson Ladd, Aanchal Malhotra, Danny Mayer, Gary E. Todd Glassey, Watson Ladd, Aanchal Malhotra, Danny Mayer, Gary E.
Miller, Tomoyuki Sahara, Dieter Sibold, Steven Sommars, and Ulrich
Windl, for providing valuable comments on earlier versions of this
document.
Miller, Dieter Sibold, Steven Sommars, and Ulrich Windl, for Watson Ladd raised the problem of DDoS mitigation when the NTP
providing valuable comments on earlier versions of this document. service port is employed as the client port (discussed in Section 3.3
of this document).
The authors would like to thank Harlan Stenn for answering questions The authors would like to thank Harlan Stenn for answering questions
about nwtime.org's NTP implementation. about nwtime.org's NTP implementation.
Fernando would like to thank Nelida Garcia and Jorge Oscar Gont, for Fernando would like to thank Nelida Garcia and Jorge Oscar Gont, for
their love and support. their love and support.
9. References 9. References
9.1. Normative References 9.1. Normative References
skipping to change at page 8, line 37 skipping to change at page 8, line 31
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011, DOI 10.17487/RFC6056, January 2011,
<https://www.rfc-editor.org/info/rfc6056>. <https://www.rfc-editor.org/info/rfc6056>.
9.2. Informative References 9.2. Informative References
[chrony] "chrony", <https://chrony.tuxfamily.org/>. [chrony] "chrony", <https://chrony.tuxfamily.org/>.
[I-D.gont-predictable-numeric-ids]
Gont, F. and I. Arce, "Security and Privacy Implications
of Numeric Identifiers Employed in Network Protocols",
draft-gont-predictable-numeric-ids-03 (work in progress),
March 2019.
[I-D.ietf-ntp-data-minimization] [I-D.ietf-ntp-data-minimization]
Franke, D. and A. Malhotra, "NTP Client Data Franke, D. and A. Malhotra, "NTP Client Data
Minimization", draft-ietf-ntp-data-minimization-04 (work Minimization", draft-ietf-ntp-data-minimization-04 (work
in progress), March 2019. in progress), March 2019.
[I-D.irtf-pearg-numeric-ids-generation]
Gont, F. and I. Arce, "On the Generation of Transient
Numeric Identifiers", draft-irtf-pearg-numeric-ids-
generation-01 (work in progress), February 2020.
[NIST-NTP] [NIST-NTP]
Sherman, J. and J. Levine, "Usage Analysis of the NIST Sherman, J. and J. Levine, "Usage Analysis of the NIST
Internet Time Service", Journal of Research of the Internet Time Service", Journal of Research of the
National Institute of Standards and Technology Volume 121, National Institute of Standards and Technology Volume 121,
March 2016, <https://tf.nist.gov/general/pdf/2818.pdf>. March 2016, <https://tf.nist.gov/general/pdf/2818.pdf>.
[NTP-CHLNG] [NTP-CHLNG]
Sommars, S., "Challenges in Time Transfer Using the Sommars, S., "Challenges in Time Transfer Using the
Network Time Protocol (NTP)", Proceedings of the 48th Network Time Protocol (NTP)", Proceedings of the 48th
Annual Precise Time and Time Interval Systems and Annual Precise Time and Time Interval Systems and
 End of changes. 17 change blocks. 
45 lines changed or deleted 42 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/