draft-ietf-ntp-port-randomization-02.txt   draft-ietf-ntp-port-randomization-03.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: October 18, 2020 Red Hat Expires: November 29, 2020 Red Hat
April 16, 2020 May 28, 2020
Port Randomization in the Network Time Protocol Version 4 Port Randomization in the Network Time Protocol Version 4
draft-ietf-ntp-port-randomization-02 draft-ietf-ntp-port-randomization-03
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 October 18, 2020. This Internet-Draft will expire on November 29, 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 4, line 14 skipping to change at page 4, line 14
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.
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 offset and delay.
This might mean, for example, that two clients in the same network
synchronized with the same NTP server using a stable source port
(selected randomly or not) have a significant offset between their
clocks due to their NTP exchanges taking paths with different
asymmetry in the network delay.
If the clients changed their source port with each request, packets If the source port is changed with each request, packets in different
in different exchanges would take different paths. The measured exchanges will be more likely to take different paths, which could
delay and offset would be less stable, but the offset between the cause the measurements to be less stable and have a negative impact
clients' clocks would be smaller. The impact on stability of the on the stability of the clock.
clocks would be mitigated by the clock filter algorithm, which
prefers samples with shorter delay.
On the other hand, if port-randomization is applied on a per- Network paths to/from a given server are less likely to change
association basis, request/responses to the same association would between requests if port randomization is applied on a per-
likely follow the same path, since the IP addresses and transport association basis. This approach minimizes the impact on the
port numbers employed for an association would not change. This stability of NTP measurements, but may cause different clients in the
would thus result in more stability of the measurements. same network synchronized to the same NTP server to have a
significant stable offset between their clocks due to their NTP
exchanges consistently taking different paths with different
asymmetry in the network delay.
Section 4 recommends NTP implementations to randomize the ephemeral Section 4 recommends NTP implementations to randomize the ephemeral
port number of non-symmetrical associations. The choice of whether port number of client/server associations. The choice of whether to
to randomize the port number on a per-association or a per-request randomize the port number on a per-association or a per-request basis
basis is left to the implementation. is left to the implementation.
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
differentiation of NTP requests and responses, and for the differentiation of NTP requests and responses, and for the
enforcement of security policies that may be valuable for the enforcement of security policies that may be valuable for the
mitigation of DDoS attacks. mitigation of DDoS attacks, when all NTP clients in a given network
employ port randomization.
3.4. Effect on NAT devices 3.4. Effect on NAT devices
Some NAT devices will not translate the source port of a packet when Some NAT devices will not translate the source port of a packet when
a privileged port number is employed. In networks where such NAT a privileged port number is employed. In networks where such NAT
devices are employed, use of the NTP service port for the client port devices are employed, use of the NTP service port for the client port
will essentially limit the number of hosts that may successfully will essentially limit the number of hosts that may successfully
employ NTP client implementations. employ NTP client implementations.
In the case of NAT devices that will translate the source port even In the case of NAT devices that will translate the source port even
skipping to change at page 5, line 44 skipping to change at page 5, line 44
[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 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 the
cases, it SHOULD contain a randomized port number, as specified in client mode (3), it SHOULD contain a randomized port number, as
[RFC6056]. The value in this variable becomes the source port specified in [RFC6056]. The value in this variable becomes the
number of packets sent from this association. The randomized port source port number of packets sent from this association. The
number SHOULD NOT be shared with other associations. randomized port number SHOULD NOT be shared with other
associations.
NOTES: NOTES:
The choice of whether to randomize the port number on a per- The choice of whether to randomize the port number on a per-
request or a per-association basis is left to the request or a per-association basis is left to the
implementation, and should consider, among others, the implementation, and should consider, among others, the
considerations discussed in Section 3.2. considerations discussed in Section 3.2.
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()
skipping to change at page 8, line 39 skipping to change at page 8, line 42
[chrony] "chrony", <https://chrony.tuxfamily.org/>. [chrony] "chrony", <https://chrony.tuxfamily.org/>.
[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] [I-D.irtf-pearg-numeric-ids-generation]
Gont, F. and I. Arce, "On the Generation of Transient Gont, F. and I. Arce, "On the Generation of Transient
Numeric Identifiers", draft-irtf-pearg-numeric-ids- Numeric Identifiers", draft-irtf-pearg-numeric-ids-
generation-01 (work in progress), February 2020. generation-02 (work in progress), May 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
 End of changes. 11 change blocks. 
33 lines changed or deleted 29 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/