Network Time Protocol Version 4: Port Randomization
updates
- rfc-5905 — Network Time Protocol Version 4: Protocol and Algorithms Specification
Extracted elements (15)
NTP has traditionally employed the well-known port 123 even when not strictly necessary, which unnecessarily reduces the entropy an attacker must overcome to mount a blind/off-path attack. This document corrects that pattern to align with BCP 156 (RFC 6056).
Port randomization is recommended on a per-association basis to minimize impact on clock stability, since per-request randomization causes packets in different exchanges to take different ECMP paths, leading to less stable offset and delay measurements.
The choice of whether to randomize the ephemeral port on a per-request or per-association basis is left to the implementation; per-request randomization better mitigates blind/off-path attacks but may negatively affect time measurement stability due to ECMP path variation.
When all NTP clients in a network use randomized ports, operators can easily differentiate client requests (random source port, destination port 123) from server responses (source port 123, random destination port), enabling DDoS mitigation policies.
ECMP intermediate systems may hash the source port to select the outgoing link. Changing the source port per-request can cause NTP exchanges to traverse different paths with different delay asymmetry, potentially introducing stable clock offsets between clients synchronized to the same server.
On most current operating systems implementing RFC 6056 ephemeral port randomization, NTP clients can rely on the OS by not calling bind() or binding to port 0; using connect() additionally restricts the socket to only receive packets from the specified remote socket.
Some NAPT devices do not translate the source port when a system port (0–1023) is used. In such networks, using the NTP well-known port 123 as the client port may limit the number of hosts that can simultaneously use NTP, since NAPT translation requires unique port mappings.
If a client performs port randomization on a per-request basis, it SHOULD close the corresponding socket/port after each request/response exchange, to limit exposure of the randomized port.
In broadcast server mode (5) and symmetric modes (1 and 2), the dstport variable SHOULD contain the NTP well-known port number 123 assigned by IANA, as these modes require receipt of unsolicited packets.
In client mode (3), the dstport variable SHOULD contain a randomized ephemeral port number as specified in RFC 6056 (BCP 156), rather than the NTP well-known port 123.
The randomized ephemeral port number SHOULD NOT be shared with other associations, to avoid revealing the randomized port to other NTP associations.
To prevent duplicate or delayed server packets from eliciting ICMP port unreachable errors at the client, the client MAY wait for additional responses for a specific period (e.g., 3 seconds) before closing the UDP socket/port.
The dstport peer process variable holds the UDP port number of the NTP client. It becomes the source port number in packets sent from that association. Its value depends on the operating mode: well-known port 123 for broadcast/symmetric modes, randomized port for client mode.
Transport-protocol ephemeral port randomization is a transport-layer mitigation against blind/off-path attacks and is complementary to—not a replacement for—other NTP-layer mitigations such as NTP data minimization or authentication. Port randomization adds entropy that benefits those other mitigations as well.
Using the NTP well-known port 123 for both srcport and dstport in client mode unnecessarily reduces the search space for blind/off-path attackers who need to guess the five-tuple {Protocol, IP src, IP dst, src port, dst port} to forge packets targeting an NTP association. This issue is assigned CVE-2019-11331.