Network Time Protocol Version 4: Port RandomizationSI6 NetworksEvaristo Carriego 2644Haedo, Provincia de Buenos Aires1706Argentina+54 11 4650 8472fgont@si6networks.comhttps://www.si6networks.comSI6 NetworksEvaristo Carriego 2644Haedo, Provincia de Buenos Aires1706Argentina+54 11 4650 8472ggont@si6networks.comhttps://www.si6networks.comRed HatPurkynova 115Brno612 00Czech Republicmlichvar@redhat.comNetwork Time Protocol (ntp) Working Groupsecuritytransport protocols
The Network Time Protocol (NTP) can operate in several modes. Some of these
modes are based on the receipt of unsolicited packets and therefore
require the use of a well-known port as the local port. However, in
the case of NTP modes where the use of a well-known port is not required,
employing such a well-known port unnecessarily facilitates the ability of
attackers to perform blind/off-path attacks. This document formally
updates RFC 5905, recommending the use of transport-protocol ephemeral port
randomization for those modes where use of the NTP well-known port is not
required.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 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
() 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.
Table of Contents
. Introduction
. Terminology
. Considerations about Port Randomization in NTP
. Mitigation against Off-Path Attacks
. Effects on Path Selection
. Filtering of NTP Traffic
. Effect on NAPT Devices
. Update to RFC 5905
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgments
Authors' Addresses
Introduction
The Network Time Protocol (NTP) is one of the oldest Internet
protocols and is currently specified in . Since its original
implementation, standardization, and deployment, a number of
vulnerabilities have been found both in the NTP specification and in
some of its implementations . Some of these
vulnerabilities allow for blind/off-path attacks, where an attacker
can send forged packets to one or both NTP peers to achieve Denial
of Service (DoS), time shifts, or other undesirable outcomes. Many
of these attacks require the attacker to guess or know at least a
target NTP association, typically identified by the tuple {srcaddr,
srcport, dstaddr, dstport, keyid} (see ).
Some of these parameters may be known or easily guessed.
NTP can operate in several modes. Some of these modes rely on the
ability of nodes to receive unsolicited packets and therefore
require the use of the NTP well-known port (123). However, for modes
where the use of a well-known port is not required, employing the
NTP well-known port unnecessarily facilitates the ability of attackers
to perform blind/off-path attacks (since knowledge of the port
numbers is typically required for such attacks). A recent study
that analyzes the port numbers employed by NTP clients
suggests that numerous NTP clients employ the NTP well-known port as their local port, or select predictable ephemeral
port numbers, thus unnecessarily facilitating the ability of
attackers to perform blind/off-path attacks against NTP.
BCP 156 already recommends the randomization of transport-protocol ephemeral ports. This document aligns NTP with the
recommendation in BCP 156 by formally updating
such that port randomization is employed for those NTP modes for
which the use of the NTP well-known port is not needed.Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 when, and only when, they appear in all
capitals, as shown here.Considerations about Port Randomization in NTP
The following subsections analyze a number of considerations about
transport-protocol ephemeral port randomization when applied to NTP.Mitigation against Off-Path Attacks
There has been a fair share of work in the area of blind/off-path
attacks against transport protocols and upper-layer protocols, such
as and . Whether the target of the attack is a
transport-protocol instance (e.g., TCP connection) or an upper-layer
protocol instance (e.g., an application-protocol instance), the
attacker is required to know or guess the five-tuple {Protocol, IP
Source Address, IP Destination Address, Source Port, Destination
Port} that identifies the target transport-protocol instance or the
transport-protocol instance employed by the target upper-layer
protocol instance. Therefore, increasing the difficulty of guessing
this five-tuple helps mitigate blind/off-path attacks.
As a result of these considerations, transport-protocol ephemeral
port randomization is a best current practice (BCP 156) that helps
mitigate off-path attacks at the transport layer. This document
aligns the NTP specification with the existing best current
practice on transport-protocol ephemeral port selection, irrespective of other
techniques that may (and should) be implemented for mitigating off-path attacks.
We note that transport-protocol ephemeral port randomization is a
transport-layer mitigation against blind/off-path attacks and does
not preclude (nor is it precluded by) other possible mitigations for
off-path attacks that might be implemented at other layers (e.g.,
). For instance, some of the
aforementioned mitigations may be ineffective against some off-path
attacks or may benefit from the additional entropy
provided by port randomization .Effects on Path Selection
Intermediate systems implementing the Equal-Cost Multipath (ECMP)
algorithm may select the outgoing link by computing a hash over a
number of values, including the transport-protocol source port.
Thus, as discussed in , the selected client port may have
an influence on the measured offset and delay.
If the source port is changed with each request, packets in different
exchanges will be more likely to take different paths, which could
cause the measurements to be less stable and have a negative impact
on the stability of the clock.
Network paths to/from a given server are less likely to change between
requests if port randomization is applied on a per-association basis. This
approach minimizes the impact on the stability of NTP measurements,
but it may cause different clients in the same network synchronized to the
same NTP server to have a significant stable offset between their clocks.
This is due to their NTP exchanges consistently taking different paths with
different asymmetry in the network delay. recommends that NTP implementations randomize the ephemeral
port number of client/server associations. The choice of whether to
randomize the port number on a per-association or a per-request basis
is left to the implementation.Filtering of NTP Traffic
In a number of scenarios (such as when mitigating DDoS attacks), a
network operator may want to differentiate between NTP requests sent
by clients and NTP responses sent by NTP servers. If an
implementation employs the NTP well-known port for the client port, requests/responses cannot be readily differentiated by
inspecting the source and destination port numbers.
Implementation of port randomization for nonsymmetrical modes allows for
simple differentiation of NTP requests and responses and for the
enforcement of security policies that may be valuable for the mitigation of
DDoS attacks, when all NTP clients in a given network employ port randomization.Effect on NAPT Devices
Some NAPT devices will reportedly not translate the source port of a
packet when a system port number (i.e., a port number in the range
0-1023) is employed. In networks where such NAPT devices
are employed, use of the NTP well-known port for the client port may
limit the number of hosts that may successfully employ NTP client
implementations at any given time.
In the case of NAPT devices that will translate the source port even
when a system port is employed, packets reaching the external realm
of the NAPT will not employ the NTP well-known port as the source
port, as a result of the port translation function being performed by the
NAPT device.Update to RFC 5905
The following text from Section
Peer
Process Variables of :
dstport:
UDP port number of the client, ordinarily the NTP port
number PORT (123) assigned by the IANA. This becomes the source
port number in packets sent from this association.
is replaced with:
dstport:
UDP port number of the client. In the case of broadcast
server mode (5) and symmetric modes (1 and 2), it SHOULD contain
the NTP port number PORT (123) assigned by IANA. In the
client mode (3), it SHOULD contain a randomized port number, as
specified in . The value in this variable becomes the
source port number of packets sent from this association. The
randomized port number SHOULD NOT be shared with other
associations, to avoid revealing the randomized port to other
associations.
If a client implementation performs transport-protocol ephemeral port randomization
on a per-request basis, it SHOULD close the corresponding socket/port
after each request/response exchange. In order to prevent duplicate
or delayed server packets from eliciting ICMP port unreachable error
messages at the client, the client MAY wait for more responses from
the server for a specific period of time (e.g., 3 seconds) before
closing the UDP socket/port.
NOTES:Randomizing the ephemeral port number on a per-request basis
will better mitigate blind/off-path attacks, particularly if
the socket/port is closed after each request/response exchange,
as recommended above. The choice of whether to randomize the
ephemeral port number on a per-request or a per-association
basis is left to the implementation, and it should consider the
possible effects on path selection along with its possible
impact on time measurement.
On most current operating systems, which implement ephemeral
port randomization , an NTP client may normally rely
on the operating system to perform ephemeral port
randomization. For example, NTP implementations using POSIX
sockets may achieve ephemeral port randomization by not
binding the socket with the bind() function or binding it to
port 0, which has a special meaning of "any port". Using the connect() function for the socket will make the port inaccessible
by other systems (that is, only packets from the specified remote socket will be
received by the application).
IANA Considerations
This document has no IANA actions.Security Considerations
The security implications of predictable numeric identifiers
(and of predictable
transport-protocol port numbers in particular) have been
known for a long time now. However, the NTP specification has
traditionally followed a pattern of employing common settings even
when not strictly necessary, which at times has resulted in negative
security and privacy implications (see, e.g.,
). The use of the NTP well-known
port (123) for the srcport and dstport variables is not required for
all operating modes. Such unnecessary usage comes at the expense of
reducing the amount of work required for an attacker to successfully
perform blind/off-path attacks against NTP. Therefore, this document
formally updates , recommending the use of transport-protocol port randomization when use of the NTP well-known port is
not required.
This issue has been assigned CVE-2019-11331 in the U.S.
National Vulnerability Database (NVD).ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Network Time Protocol Version 4: Protocol and Algorithms SpecificationThe Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]Recommendations for Transport-Protocol Port RandomizationDuring the last few years, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput reduction to broken connections or data corruption. These attacks rely on the attacker's ability to guess or know the five-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. This document describes a number of simple and efficient methods for the selection of the client port number, such that the possibility of an attacker guessing the exact value is reduced. While this is not a replacement for cryptographic methods for protecting the transport-protocol instance, the aforementioned port selection algorithms provide improved security with very little effort and without any key management overhead. The algorithms described in this document are local policies that may be incrementally deployed and that do not violate the specifications of any of the transport protocols that may benefit from them, such as TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP), Datagram Congestion Control Protocol (DCCP), and RTP (provided that the RTP application explicitly signals the RTP and RTCP port numbers). This memo documents an Internet Best Current Practice.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesUsage Analysis of the NIST Internet Time ServiceJournal of Research of the National Institute of Standards and Technology, Volume 121Challenges in Time Transfer using the Network Time Protocol (NTP)Proceedings of the 48th Annual Precise Time and Time Interval Systems and Applications Meeting, pp. 271-290NTP Client Data MinimizationWork in ProgressAttacking the Network Time ProtocolNDSS '16The Security of NTP's Datagram ProtocolCryptology ePrint Archive Report 2016/1006Network Time FoundationOn the Generation of Transient Numeric IdentifiersSI6 NetworksQuarkslab This document performs an analysis of the security and privacy
implications of different types of "transient numeric identifiers"
used in IETF protocols, and tries to categorize them based on their
interoperability requirements and their associated failure severity
when such requirements are not met. Subsequently, it provides advice
on possible algorithms that could be employed to satisfy the
interoperability requirements of each identifier category, while
minimizing the negative security and privacy implications, thus
providing guidance to protocol designers and protocol implementers.
Finally, it describes a number of algorithms that have been employed
in real implementations to generate transient numeric identifiers,
and analyzes their security and privacy properties. This document is
a product of the Privacy Enhancement and Assessment Research Group
(PEARG) in the IRTF.
Work in ProgressInternet Control Message ProtocolIP Network Address Translator (NAT) Terminology and ConsiderationsThis document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT. This memo provides information for the Internet community.IPsec-Network Address Translation (NAT) Compatibility RequirementsThis document describes known incompatibilities between Network Address Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses. This memo provides information for the Internet community.Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) SpecificationThis document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]Defending TCP Against Spoofing AttacksRecent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. This memo provides information for the Internet community.ICMP Attacks against TCPThis document discusses the use of the Internet Control Message Protocol (ICMP) to perform a variety of attacks against the Transmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. This document is not an Internet Standards Track specification; it is published for informational purposes.Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number RegistryThis document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice.CVE-2019-1133The MITRE CorporationNational Vulnerability DatabaseAcknowledgments
The authors would like to thank (in alphabetical order) ,
, , , , ,
, , , , , , , , ,
, , , ,
, , , , , and for providing valuable comments on earlier draft versions of this document. raised the problem of DDoS mitigation when the NTP well-known
port is employed as the client port (discussed in of this document).
The authors would like to thank for answering questions
about a popular NTP implementation (see ). would like to thank and for
their love and support.Authors' AddressesSI6 NetworksEvaristo Carriego 2644Haedo, Provincia de Buenos Aires1706Argentina+54 11 4650 8472fgont@si6networks.comhttps://www.si6networks.comSI6 NetworksEvaristo Carriego 2644Haedo, Provincia de Buenos Aires1706Argentina+54 11 4650 8472ggont@si6networks.comhttps://www.si6networks.comRed HatPurkynova 115Brno612 00Czech Republicmlichvar@redhat.com