RFC 9109

Network Time Protocol Version 4: Port Randomization

📅 published August 2021, from ietf

RFC 9109 🎀 Network Time Protocol Version 4: Port Randomization

okay bestie, let's get into this one 💖 RFC 9109 is titled "Network Time Protocol Version 4: Port Randomization." It's written by F. Gont, G. Gont (SI6 Networks) and M. Lichvar (Red Hat). It's a Standards Track doc, dated August 2021, with ISSN 2070-1721. It updates RFC 5905 (the main NTP spec), and there's no Obsoletes line, so it doesn't replace anything 🦋

Abstract

NTP can run in a few different modes 🌸 Some of them rely on receiving unsolicited packets, so they need the well-known port. But for the modes that don't need that port, using it anyway just makes life easier for attackers doing blind/off-path attacks 🙈 So this doc formally updates RFC 5905 and recommends transport-protocol ephemeral port randomization for those modes where the NTP well-known port isn't required. It's giving security glow-up 💅

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 https://www.rfc-editor.org/info/rfc9109.

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 (https://trustee.ietf.org/license-info) 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 🧚

  • 1. Introduction
  • 2. Terminology
  • 3. Considerations about Port Randomization in NTP
    • 3.1. Mitigation against Off-Path Attacks
    • 3.2. Effects on Path Selection
    • 3.3. Filtering of NTP Traffic
    • 3.4. Effect on NAPT Devices
  • 4. Update to RFC 5905
  • 5. IANA Considerations
  • 6. Security Considerations
  • 7. References
    • 7.1. Normative References
    • 7.2. Informative References
  • Acknowledgments
  • Authors' Addresses

1. Introduction 💖

okay so NTP is one of the oldest Internet protocols out there, and it's currently specified in [RFC5905] 👑 Since it was first implemented, standardized and deployed, a bunch of vulnerabilities have been found, both in the NTP spec and in some implementations [NTP-VULN]. Some of these vulnerabilities allow blind/off-path attacks, where an attacker sends forged packets to one or both NTP peers to cause Denial of Service (DoS), time shifts, or other messy outcomes 😭 A lot of these attacks need the attacker to guess or know at least a target NTP association, which is typically identified by the tuple {srcaddr, srcport, dstaddr, dstport, keyid} (see Section 9.1 of [RFC5905]). Some of those parameters may be known or easily guessed, which is not it 💀

NTP can operate in several modes ✨ Some of these modes rely on nodes being able to receive unsolicited packets, so they require the NTP well-known port (123). But for modes where a well-known port isn't required, using the NTP well-known port anyway unnecessarily makes it easier for attackers to pull off blind/off-path attacks (since knowing the port numbers is typically required for those attacks). A recent study [NIST-NTP] looked at the port numbers NTP clients use, and it suggests that numerous NTP clients either use the NTP well-known port as their local port, or pick predictable ephemeral port numbers. Again, that's giving free passes to attackers 🙈

BCP 156 [RFC6056] already recommends randomizing transport-protocol ephemeral ports 🦋 This document lines NTP up with that recommendation by formally updating [RFC5905], so port randomization is used for those NTP modes where the NTP well-known port isn't needed. Main character energy, fr fr 🌟

2. Terminology 🎀

Okay, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly as shown here 💅

3. Considerations about Port Randomization in NTP 🌸

The following subsections are where we dig into a bunch of considerations about transport-protocol ephemeral port randomization when it's applied to NTP 🧠

3.1. Mitigation against Off-Path Attacks 🛡️

There's been a fair share of work on blind/off-path attacks against transport protocols and upper-layer protocols, like [RFC4953] and [RFC5927] 🔥 Whether the target is a transport-protocol instance (e.g., a 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 used by the target upper-layer protocol instance. So making that five-tuple harder to guess helps mitigate blind/off-path attacks ✨

So, transport-protocol ephemeral port randomization is a best current practice (BCP 156) that helps mitigate off-path attacks at the transport layer 🦋 This document lines the NTP spec [RFC5905] up with that existing best current practice on transport-protocol ephemeral port selection, no matter what other techniques (and should) be implemented to mitigate off-path attacks.

We should note that transport-protocol ephemeral port randomization is a transport-layer mitigation against blind/off-path attacks. It doesn't block other possible mitigations at other layers (e.g., [NTP-DATA-MINIMIZATION]), and those other mitigations don't block it either 🫶 For instance, some of the mitigations mentioned above may be ineffective against some off-path attacks [NTP-FRAG], or may benefit from the extra entropy that port randomization provides [NTP-security] 🤓

3.2. Effects on Path Selection 🛤️

Intermediate systems that implement the Equal-Cost Multipath (ECMP) algorithm may pick the outgoing link by computing a hash over a number of values, including the transport-protocol source port. So, as discussed in [NTP-CHLNG], the client port you pick can actually influence the measured offset and delay 😳

If the source port changes with every request, packets in different exchanges are more likely to take different paths, which could make the measurements less stable and hurt the stability of the clock 💔

Network paths to and from a given server are less likely to change between requests if port randomization is applied on a per-association basis 💜 This approach keeps the impact on the stability of NTP measurements low, but it may cause different clients in the same network that are synced to the same NTP server to end up with a significant stable offset between their clocks. That's because their NTP exchanges keep taking different paths, with different asymmetry in the network delay 😵‍💫

Section 4 recommends that NTP implementations randomize the ephemeral port number of client/server associations. Whether to randomize the port number per association or per request is left up to the implementation 🧚

3.3. Filtering of NTP Traffic 🚦

In a number of scenarios (like when mitigating DDoS attacks), a network operator may want to tell apart NTP requests sent by clients from NTP responses sent by NTP servers. If an implementation uses the NTP well-known port for the client port, requests and responses can't be easily told apart by looking at the source and destination port numbers 🙃 Port randomization for nonsymmetrical modes lets you tell NTP requests and responses apart with ease, and it allows security policies that can be really valuable for mitigating DDoS attacks, as long as all NTP clients in a given network use port randomization 🔥

3.4. Effect on NAPT Devices 🌐

Some NAPT devices reportedly won't translate the source port of a packet when a system port number (i.e., a port number in the range 0-1023) [RFC6335] is used. In networks where those NAPT devices are deployed, using the NTP well-known port for the client port may limit how many hosts can successfully run NTP client implementations at any given time 😬

      |  NOTES:
      |
      |     NAPT devices are defined in Section 4.1.2 of [RFC2663].
      |
      |     The reported behavior is similar to the special treatment of
      |     UDP port 500, which has been documented in Section 2.3 of
      |     [RFC3715].

And in the case of NAPT devices that do translate the source port even when a system port is used, packets reaching the external realm of the NAPT won't use the NTP well-known port as the source port, because the port translation function done by the NAPT device takes care of it 🧚‍♀️

That's the end of part 1, bestie 💜 Part 2 has Section 4 (the actual update to RFC 5905 🎀), IANA Considerations, Security Considerations, and the References, so stay tuned for the rest of the tea ☕✨

4. Update to RFC 5905 ✨

okay so this section is basically a patch note 🩹. It takes a sentence from Section 9.1 (Peer Process Variables) of [RFC5905] and swaps it for a new version. Here's the old bit:

The following text from Section 9.1 (Peer Process Variables) of
[RFC5905]:

|  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:

And here's the new version, which is where the magic happens 🪄:

|  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 [RFC6056].  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
|     [RFC0792] [RFC4443] 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 [RFC6056], 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).

So the big takeaway 💅: for broadcast server and symmetric modes, the NTP port 123 is still the move. In client mode though, you should grab a randomized port instead, the way [RFC6056] describes. And if you're randomizing per request, close the socket after each exchange, but you may hang around for a few seconds (the doc's example is 3) so late server packets don't trigger ICMP port unreachable errors from [RFC0792] and [RFC4443] 🙈.

5. IANA Considerations

literally nothing for IANA to do here 😌. This document has no IANA actions.

6. Security Considerations

okay this one is serious bestie, but in a fun dramatic way 🎭. Predictable numeric identifiers [PEARG-NUMERIC-IDS] are a known problem, and predictable transport-protocol port numbers [RFC6056] are a big example of that. NTP has a habit of using common settings even when they aren't strictly needed, and that has caused security and privacy problems at times (see, e.g., [NTP-DATA-MINIMIZATION]). Using the NTP well-known port (123) for the srcport and dstport variables is not required for all operating modes, but doing it anyway makes life way easier for an attacker trying to pull off blind/off-path attacks against NTP 😭. So this document formally updates [RFC5905], recommending transport-protocol port randomization whenever the NTP well-known port isn't required.

This issue has been assigned CVE-2019-11331 [VULN-REPORT] in the U.S. National Vulnerability Database (NVD). Yes, it has its own CVE. Iconic behaviour from the port 123 situation, honestly 💀.

7. References

7.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
           "Network Time Protocol Version 4: Protocol and Algorithms
           Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
           <https://www.rfc-editor.org/info/rfc5905>.

[RFC6056]  Larsen, M. and F. Gont, "Recommendations for Transport-
           Protocol Port Randomization", BCP 156, RFC 6056,
           DOI 10.17487/RFC6056, January 2011,
           <https://www.rfc-editor.org/info/rfc6056>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References

[NIST-NTP] Sherman, J. and J. Levine, "Usage Analysis of the NIST
           Internet Time Service", Journal of Research of the
           National Institute of Standards and Technology, Volume
           121, DOI 10.6028/jres.121.003, March 2016,
           <https://tf.nist.gov/general/pdf/2818.pdf>.

[NTP-CHLNG]
           Sommars, S., "Challenges 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-290,
           DOI 10.33012/2017.14978, January 2017,
           <http://leapsecond.com/ntp/
           NTP_Paper_Sommars_PTTI2017.pdf>.

[NTP-DATA-MINIMIZATION]
           Franke, D. and A. Malhotra, "NTP Client Data
           Minimization", Work in Progress, Internet-Draft,
           draft-ietf-ntp-data-minimization-04, 25 March 2019,
           <https://datatracker.ietf.org/doc/html/draft-ietf-ntp-
           data-minimization-04>.

[NTP-FRAG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg,
           "Attacking the Network Time Protocol", NDSS '16,
           DOI 10.14722/ndss.2016.23090, February 2016,
           <https://www.cs.bu.edu/~goldbe/papers/NTPattack.pdf>.

[NTP-security]
           Malhotra, A., Van Gundy, M., Varia, M., Kennedy, H.,
           Gardner, J., and S. Goldberg, "The Security of NTP's
           Datagram Protocol", Cryptology ePrint Archive Report
           2016/1006, DOI 10.1007/978-3-319-70972-7_23, February
           2017, <https://eprint.iacr.org/2016/1006.pdf>.

[NTP-VULN] "Network Time Foundation",
           <http://support.ntp.org/bin/view/Main/SecurityNotice>.

[PEARG-NUMERIC-IDS]
           Gont, F. and I. Arce, "On the Generation of Transient
           Numeric Identifiers", Work in Progress, Internet-Draft,
           draft-irtf-pearg-numeric-ids-generation-07, 2 February
           2021, <https://datatracker.ietf.org/doc/html/draft-irtf-
           pearg-numeric-ids-generation-07>.

[RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
           RFC 792, DOI 10.17487/RFC0792, September 1981,
           <https://www.rfc-editor.org/info/rfc792>.

[RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
           Translator (NAT) Terminology and Considerations",
           RFC 2663, DOI 10.17487/RFC2663, August 1999,
           <https://www.rfc-editor.org/info/rfc2663>.

[RFC3715]  Aboba, B. and W. Dixon, "IPsec-Network Address Translation
           (NAT) Compatibility Requirements", RFC 3715,
           DOI 10.17487/RFC3715, March 2004,
           <https://www.rfc-editor.org/info/rfc3715>.

[RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
           Control Message Protocol (ICMPv6) for the Internet
           Protocol Version 6 (IPv6) Specification", STD 89,
           RFC 4443, DOI 10.17487/RFC4443, March 2006,
           <https://www.rfc-editor.org/info/rfc4443>.

[RFC4953]  Touch, J., "Defending TCP Against Spoofing Attacks",
           RFC 4953, DOI 10.17487/RFC4953, July 2007,
           <https://www.rfc-editor.org/info/rfc4953>.

[RFC5927]  Gont, F., "ICMP Attacks against TCP", RFC 5927,
           DOI 10.17487/RFC5927, July 2010,
           <https://www.rfc-editor.org/info/rfc5927>.

[RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
           Cheshire, "Internet Assigned Numbers Authority (IANA)
           Procedures for the Management of the Service Name and
           Transport Protocol Port Number Registry", BCP 165,
           RFC 6335, DOI 10.17487/RFC6335, August 2011,
           <https://www.rfc-editor.org/info/rfc6335>.

[VULN-REPORT]
           The MITRE Corporation, "CVE-2019-1133", National
           Vulnerability Database, August 2020,
           <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-
           2019-11331>.

Acknowledgments

huge thank-you hugs to everyone 🫶 The authors would like to thank (in alphabetical order) Ivan Arce, Roman Danyliw, Dhruv Dhody, Lars Eggert, Todd Glassey, Blake Hudson, Benjamin Kaduk, Erik Kline, Watson Ladd, Aanchal Malhotra, Danny Mayer, Gary E. Miller, Bjorn Mork, Hal Murray, Francesca Palombini, Tomoyuki Sahara, Zaheduzzaman Sarker, Dieter Sibold, Steven Sommars, Jean St-Laurent, Kristof Teichel, Brian Trammell, Éric Vyncke, Ulrich Windl, and Dan Wing for providing valuable comments on earlier draft versions of this document.

Watson Ladd raised the problem of DDoS mitigation when the NTP well-known port is employed as the client port (discussed in Section 3.3 of this document). Main character energy, honestly 👑.

The authors would like to thank Harlan Stenn for answering questions about a popular NTP implementation (see <https://www.nwtime.org>).

Fernando Gont would like to thank Nelida Garcia and Jorge Oscar Gont for their love and support 💜.

Authors' Addresses

Fernando Gont
SI6 Networks
Evaristo Carriego 2644
1706 Haedo, Provincia de Buenos Aires
Argentina

Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI:   https://www.si6networks.com


Guillermo Gont
SI6 Networks
Evaristo Carriego 2644
1706 Haedo, Provincia de Buenos Aires
Argentina

Phone: +54 11 4650 8472
Email: ggont@si6networks.com
URI:   https://www.si6networks.com


Miroslav Lichvar
Red Hat
Purkynova 115
612 00 Brno
Czech Republic

Email: mlichvar@redhat.com

and that's a wrap, bestie 🌈🦋✨

📦 where this page comes from