< draft-gont-ntp-port-randomization-03.txt   draft-gont-ntp-port-randomization-04.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 July 22, 2019 Intended status: Standards Track August 6, 2019
Expires: January 23, 2020 Expires: February 7, 2020
Port Randomization in the Network Time Protocol Version 4 Port Randomization in the Network Time Protocol Version 4
draft-gont-ntp-port-randomization-03 draft-gont-ntp-port-randomization-04
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 39 skipping to change at page 1, line 39
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 January 23, 2020. This Internet-Draft will expire on February 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 31 skipping to change at page 2, line 31
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. Possible Future Work . . . . . . . . . . . . . . . . . . . . 6
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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
skipping to change at page 3, line 15 skipping to change at page 3, line 15
employing such well-known/service port improves the ability of an employing such 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 such
port number is typically required for such attacks). A recent study port number 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, and thus this document formally updates protocol ephemeral ports. This document aligns NTP with the
[RFC5905] such that port randomization is employed for those NTP recommendation in BCP 156 [RFC6056], by formally updating [RFC5905]
modes for which the use of the NTP service port is not required. such that port randomization is employed for those NTP modes for
This document aligns NTP with the current advice on ephemeral port which the use of the NTP service port is not required.
selection (port randomization).
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 4, line 22 skipping to change at page 4, line 19
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 that synchronize their This might mean, for example, that two systems in the same network
clocks with the same NTP server might end up with a significant that synchronize their clocks with the same NTP server might end up
offset between their clocks as a result of their NTP samples taking with a significant offset between their clocks as a result of their
paths with very different characteristics. NTP samples taking paths with very different characteristics.
If port randomization is applied for every NTP request, requests/ If port randomization is applied for every NTP request, requests/
responses would be distributed over the different available paths, responses would be distributed over the different available paths,
including those with the smallest delay. The clock filter algorithm including those with the smallest delay. The clock filter algorithm
could readily select one of such samples with lowest details, in the could readily select one of such samples with lowest delays, in the
same way that the clock select and clock cluster algorithms might same way that the clock selection and clock cluster algorithms might
also end up selecting other time sources with smaller resulting also end up selecting other time sources with smaller resulting
dispersion. On the other hand, if port-randomization is applied on a dispersion. On the other hand, if port-randomization is applied on a
per-association basis, in scenarios where the aforementioned ECMP per-association basis, in scenarios where the aforementioned ECMP
algorithm is employed, request/responses to the same association algorithm is employed, request/responses to the same association
would likely follow the same path, since the IP addresses and would likely follow the same path, since the IP addresses and
transport port numbers employed for an association would not change. transport port numbers employed for an association would not change.
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-transaction"), since this more conservative
skipping to change at page 5, line 37 skipping to change at page 5, line 35
orthogonal to other possible mitigations for off-path attacks that orthogonal to other possible mitigations for off-path attacks that
may be implemented at other layers (such as the use of timestamps in may be implemented at other layers (such as the use of timestamps in
NTP) which may or may not be effective against some off-path attacks NTP) which may or may not be effective against some off-path attacks
(see e.g. [NTP-FRAG]. This document aligns NTP with the existing (see e.g. [NTP-FRAG]. This document aligns NTP with the existing
best current practice on ephemeral port selection, irrespective of best current practice on ephemeral port selection, irrespective of
other techniques that may (and should) be implemented for mitigating other techniques that may (and should) be implemented for mitigating
off-path attacks. off-path attacks.
4. Update to RFC5905 4. Update to RFC5905
The specification of the "dstport" peer process variable from The following text from Section 9.1 ("Peer Process Variables") of
Section 9.1 ("Peer Process Variables") of [RFC5905] is updated as [RFC5905]:
follows:
dstport: UDP port number of the client. In the case of broadcast dstport: UDP port number of the client, ordinarily the NTP port
server mode (5) and symmetric modes (1 and 2), it must contain the number PORT (123) assigned by the IANA. This becomes the source
NTP port number PORT (123) assigned by the IANA. In other cases, it port number in packets sent from this association.
SHOULD contain a randomized port number, as specified in [RFC6056].
The value in this variable becomes the source port number of packets
sent from this association.
NOTES: is replaced with:
When port randomization is employed, the port number must be
randomized on a per-association basis. That is, a random port
number is selected when an association is first mobilized, and the
selected port number is expected to remain constant during the
life of an association.
On most current operating systems (that implement ephemeral port dstport: UDP port number of the client. In the case of broadcast
randomization [RFC6056]), an NTP client may normally rely on the server mode (5) and symmetric modes (1 and 2), it must contain the
operating system for performing port randomization. For example, NTP port number PORT (123) assigned by the IANA. In other cases,
NTP implementations employing the Sockets API may achieve port it SHOULD contain a randomized port number, as specified in
randomization by *not* specifying the local port for the [RFC6056]. The value in this variable becomes the source port
corresponding socket, or bind()ing the local socket to the number of packets sent from this association.
"special" port 0 (which for the Sockets API has the special
meaning of "any port"). connect()ing the docket will make the port NOTES:
inaccessible by other systems (that is, only packets from the When port randomization is employed, the port number must be
specified remote socket will be received by the application). randomized on a per-association basis. That is, a random port
number is selected when an association is first mobilized, and
the selected port number is expected to remain constant during
the life of an association.
On most current operating systems (that implement ephemeral
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 5. Possible Future Work
Port numbers could be randomized on a per-association basis, or on a Port numbers could be randomized on a per-association basis, or on a
per-request basis. When the port number is randomized on a per- per-request basis. When the port number is randomized on a per-
association basis, a random port number is selected when an association basis, a random port number is selected when an
association is first mobilized, and the selected port remains association is first mobilized, and the selected port remains
constant during the life of the association. On the other hand, when constant during the life of the association. On the other hand, when
the port number is randomized on a per-request basis, each client the port number is randomized on a per-request basis, each client
request will (statistically) employ a different ephemeral port for request will (statistically) employ a different ephemeral port for
skipping to change at page 8, line 20 skipping to change at page 8, line 24
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).
Miroslav Lichvar suggested randomization of the client port on a per- Miroslav Lichvar suggested randomization of the client port on a per-
request basis, to intentionally cause each request/response to employ request basis, to intentionally cause each request/response to employ
different paths in scenarios where ECMP is employed. different paths in scenarios where ECMP is employed.
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, Miroslav Lichvar, Aanchal Malhotra, Danny Todd Glassey, Watson Ladd, Miroslav Lichvar, Aanchal Malhotra, Danny
Mayer, Gary E. Miller, Steven Sommars, and Ulrich Windl, for Mayer, Gary E. Miller, Dieter Sibold, Steven Sommars, and Ulrich
providing valuable comments on earlier versions of this document. Windl, for 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 10. References
10.1. Normative References 10.1. Normative References
 End of changes. 12 change blocks. 
43 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/