draft-ietf-ntp-port-randomization-00.txt   draft-ietf-ntp-port-randomization-01.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: April 24, 2020 Red Hat Expires: September 10, 2020 Red Hat
October 22, 2019 March 9, 2020
Port Randomization in the Network Time Protocol Version 4 Port Randomization in the Network Time Protocol Version 4
draft-ietf-ntp-port-randomization-00 draft-ietf-ntp-port-randomization-01
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 April 24, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Considerations About Port Randomization in NTP . . . . . . . 3 3. Considerations About Port Randomization in NTP . . . . . . . 3
3.1. Mitigation Against Off-path Attacks . . . . . . . . . . . 3 3.1. Mitigation Against Off-path Attacks . . . . . . . . . . . 3
3.2. Effects on Path Selection . . . . . . . . . . . . . . . . 4 3.2. Effects on Path Selection . . . . . . . . . . . . . . . . 4
3.3. Filtering of NTP traffic . . . . . . . . . . . . . . . . 4 3.3. Filtering of NTP traffic . . . . . . . . . . . . . . . . 4
3.4. Effect on NAT devices . . . . . . . . . . . . . . . . . . 5 3.4. Effect on NAT devices . . . . . . . . . . . . . . . . . . 5
3.5. Relation to Other Mitigations for Off-Path Attacks . . . 5 3.5. Relation to Other Mitigations for Off-Path Attacks . . . 5
4. Update to RFC5905 . . . . . . . . . . . . . . . . . . . . . . 5 4. Update to RFC5905 . . . . . . . . . . . . . . . . . . . . . . 5
5. Possible Future Work . . . . . . . . . . . . . . . . . . . . 6 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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
skipping to change at page 3, line 50 skipping to change at page 3, line 49
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. And as such,
this document aims to bring the NTP specification [RFC5905] in line this document aims to bring the NTP specification [RFC5905] in line
with the aforementioned recommendation. with 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].
3.2. Effects on Path Selection 3.2. Effects on Path Selection
Intermediate systems implementing the Equal-Cost Multi-Path (ECMP) Intermediate systems implementing the Equal-Cost Multi-Path (ECMP)
algorithm may select the outgoing link by computing a hash over a algorithm may select the outgoing link by computing a hash over a
number of values, that include the transport-protocol source port. number of values, that include the transport-protocol source port.
skipping to change at page 4, line 18 skipping to change at page 4, line 16
provided by port randomization [NTP-security]. provided by port randomization [NTP-security].
3.2. Effects on Path Selection 3.2. Effects on Path Selection
Intermediate systems implementing the Equal-Cost Multi-Path (ECMP) Intermediate systems implementing the Equal-Cost Multi-Path (ECMP)
algorithm may select the outgoing link by computing a hash over a algorithm may select the outgoing link by computing a hash over a
number of values, that include the transport-protocol source port. number of values, that include the transport-protocol source port.
Thus, as discussed in [NTP-CHLNG], the selected client port may have Thus, as discussed in [NTP-CHLNG], the selected client port may have
an influence on the measured delay and jitter values. an influence on the measured delay and jitter values.
This might mean, for example, that two systems in the same network This might mean, for example, that two clients in the same network
that synchronize their clocks with the same NTP server might end up synchronized with the same NTP server using a stable source port
with a significant offset between their clocks as a result of their (selected randomly or not) have a significant offset between their
NTP samples taking paths with very different characteristics. clocks due to their NTP exchanges taking paths with different
asymmetry in the network delay.
If port randomization is applied for every NTP request, requests/ If the clients changed their source port with each request, packets
responses would be distributed over the different available paths, in different exchanges would take different paths. The measured
including those with the smallest delay. The clock filter algorithm delay and offset would be less stable, but the offset between the
could readily select one of such samples with lowest delays, in the clients' clocks would be smaller. The impact on stability of the
same way that the clock selection and clock cluster algorithms might clocks would be mitigated by the clock filter algorithm, which
also end up selecting other time sources with smaller resulting prefers samples with shorter delay.
dispersion. On the other hand, if port-randomization is applied on a
per-association basis, in scenarios where the aforementioned ECMP On the other hand, if port-randomization is applied on a per-
algorithm is employed, request/responses to the same association association basis, request/responses to the same association would
would likely follow the same path, since the IP addresses and likely follow the same path, since the IP addresses and transport
transport port numbers employed for an association would not change. port numbers employed for an association would not change. This
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 on a per-association
basis (as opposed to "per-transaction"), since this more conservative basis (as opposed to "per-request"), since this is believed to be the
approach avoids the possible negative implications of port more conservative approach. However, implementations may override
randomization on time synchronization. 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 43 skipping to change at page 5, line 45
The following text from Section 9.1 ("Peer Process Variables") of The following text from Section 9.1 ("Peer Process Variables") of
[RFC5905]: [RFC5905]:
dstport: UDP port number of the client, ordinarily the NTP port dstport: UDP port number of the client, ordinarily the NTP port
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 must contain the server mode (5) and symmetric modes (1 and 2), it SHOULD contain
NTP port number PORT (123) assigned by the IANA. In other cases, the NTP port number PORT (123) assigned by the IANA. In other
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.
NOTES: NOTES:
When port randomization is employed, the port number SHOULD be
When port randomization is employed, the port number must be
randomized on a per-association basis. That is, a random port randomized on a per-association basis. That is, a random port
number is selected when an association is first mobilized, and number SHOULD selected when an association is first mobilized,
the selected port number is expected to remain constant during and the selected port number is expected to remain constant
the life of an association. during the life of an association. An implementation MAY,
however, override this setting and employ port randomization on
On most current operating systems (that implement ephemeral a per-request basis.
port randomization [RFC6056]), an NTP client may normally rely
on the operating system for performing port randomization. For
example, NTP implementations employing the Sockets API may
achieve port randomization by *not* specifying the local port
for the corresponding socket, or bind()ing the local socket to
the "special" port 0 (which for the Sockets API has the special
meaning of "any port"). connect()ing the docket will make the
port inaccessible by other systems (that is, only packets from
the specified remote socket will be received by the
application).
5. Possible Future Work
Port numbers could be randomized on a per-association basis, or on a On most current operating systems, which implement ephemeral
per-request basis. When the port number is randomized on a per- port randomization [RFC6056], an NTP client may normally rely
association basis, a random port number is selected when an on the operating system to perform port randomization. For
association is first mobilized, and the selected port remains example, NTP implementations using POSIX sockets may achieve
constant during the life of the association. On the other hand, when port randomization by *not* binding the socket with the bind()
the port number is randomized on a per-request basis, each client function, or binding it to port 0, which has a special meaning
request will (statistically) employ a different ephemeral port for of "any port". connect()ing the docket will make the port
each request. As discussed in Section 3, varying the port number inaccessible by other systems (that is, only packets from the
across requests may impact the time quality achieved with NTP. As a specified remote socket will be received by the application).
result, this document recommends the conservative approach of
randomizing port numbers on a per-association basis (as opposed to a
"per-transaction" basis). The possibility of randomizing port
numbers on a per-transaction may be subject of future work, and is
not recommended by this document.
6. 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
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
skipping to change at page 7, line 18 skipping to change at page 6, line 51
OpenNTPD: OpenNTPD:
[OpenNTPD] has never explicitly set the local port of NTP clients, [OpenNTPD] has never explicitly set the local port of NTP clients,
and thus employs the ephemeral port selection algorithm and thus employs the ephemeral port selection algorithm
implemented by the operating system. Thus, on all operating implemented by the operating system. Thus, on all operating
systems that implement port randomization (such as current systems that implement port randomization (such as current
versions of OpenBSD, Linux, and FreeBSD), OpenNTPD will employ versions of OpenBSD, Linux, and FreeBSD), OpenNTPD will employ
port randomization for client ports. port randomization for client ports.
chrony: chrony:
[chrony] has never explicitly set the local port of NTP clients, [chrony] by default does not set the local client port, and thus
and thus employs the ephemeral port selection algorithm employs the ephemeral port selection algorithm implemented by the
implemented by the operating system. Thus, on all operating operating system. Thus, on all operating systems that implement
systems that implement port randomization (such as current port randomization (such as current versions of OpenBSD, Linux,
versions of OpenBSD, Linux, and FreeBSD), chrony will employ port and FreeBSD), chrony will employ port randomization for client
randomization for client ports. ports.
nwtime.org's sntp client: nwtime.org's sntp client:
sntp does not explicitly set the local port, and thus employs the sntp does not explicitly set the local port, and thus employs the
ephemeral port selection algorithm implemented by the operating ephemeral port selection algorithm implemented by the operating
system. Thus, on all operating systems that implement port system. Thus, on all operating systems that implement port
randomization (such as current versions of OpenBSD, Linux, and randomization (such as current versions of OpenBSD, Linux, and
FreeBSD), it will employ port randomization for client ports. FreeBSD), it will employ port randomization for client ports.
7. 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.
8. 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.gont-predictable-numeric-ids] (and of predictable transport-
protocol port numbers [RFC6056] in particular) have been known for a protocol port numbers [RFC6056] in particular) have been known for a
long time now. However, the NTP specification has traditionally long time now. However, the NTP specification has traditionally
followed a pattern of employing common settings and code even when followed a pattern of employing common settings and code even when
not strictly necessary, which at times has resulted in negative not strictly necessary, which at times has resulted in negative
security and privacy implications (see e.g. 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.
9. Acknowledgments 8. Acknowledgments
Watson Ladd raised the problem of DDoS mitigation when the NTP Watson Ladd raised the problem of DDoS mitigation when the NTP
service port is employed as the client port (discussed in Section 3.3 service port is employed as the client port (discussed in Section 3.3
of this document). 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, Dieter Sibold, Steven Sommars, and Ulrich Windl, for Miller, Dieter Sibold, Steven Sommars, and Ulrich Windl, for
providing valuable comments on earlier versions of this document. providing valuable comments on earlier versions 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.
10. References 9. References
10.1. Normative References 9.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,
<https://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,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[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>.
10.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] [I-D.gont-predictable-numeric-ids]
Gont, F. and I. Arce, "Security and Privacy Implications Gont, F. and I. Arce, "Security and Privacy Implications
of Numeric Identifiers Employed in Network Protocols", of Numeric Identifiers Employed in Network Protocols",
draft-gont-predictable-numeric-ids-03 (work in progress), draft-gont-predictable-numeric-ids-03 (work in progress),
March 2019. March 2019.
[I-D.ietf-ntp-data-minimization] [I-D.ietf-ntp-data-minimization]
 End of changes. 23 change blocks. 
83 lines changed or deleted 66 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/