]> Viagenie

Canada marc.blanchet@viagenie.ca

Internet Internet Engineering Task Force ntp time synchronization space ip deep space delay Deep space communications involve long delays (e.g., Earth to Mars one-way delay is 4-24 minutes) and intermittent communications, because of orbital dynamics. This document defines an NTP profile for deep space. NTP on-wire protocol is indifferent to path delays and transfers time in a single round trip at any distance, but diverges if delays in each direction is different. Some algorithmic constants and defaults such as distance threshold, dispersion bounds, poll intervals and burst modes, need to be tailored to the deep space scenario. The use of secured NTP is also discussed.

Introduction Deep space networks based on IP, as described in , contain nodes whose clocks must be synchronized or at least related to Earth time scales, for navigation, science data timestamping, security protocols, and network operations. NTP is the most widely deployed IP time synchronization protocol, which makes it a natural candidate for deep space time distribution. However, parts of its specification's algorithms and defaults, and mechanisms commonly layered on it, assume terrestrial round-trip times. The key characteristics of deep space communications, the connectivity scenarios, and the derived requirements are described in . Space missions have been using precise Position, Navigation and Timing(PNT) for various purposes, using specific channels. The use of NTP is not meant to replace PNT, but to provide a time synchronisation service to any computer in spacecrafts, in their payload, as well as assets on celestial body surface, where PNT is not available. Missions may elect to compensate the relativistic time effects by some adjustments to the received time sync. However, such mechanism is outside the scope of this document

Deployment Model In one time synchronization deployment model in deep space, the reference clocks and stratum 1 servers live on Earth. The NTP clients are the remote deep space assets: spacecrafts, orbiters, relays, landers, rovers, etc. In addition, intermediate nodes such as orbiters, relays, gateways may additionally serve time onward to assets behind them, acting as clients toward Earth and servers toward their local network, at one stratum below their Earth source. Such relays advertise the root delay and root dispersion of their path to Earth, which has specific constraints described in . Given these constraints and deep space long delays and intermittence, intermediate nodes may also declare themselves as root/stratum 1 with proper adjustment. Finally, it is expected that surface or orbital networks around celestial bodies may have reference clocks and stratum 1 servers to serve the celestial body surface network. In this case, it is expected that high connectivity and low latency similar to Earth Internet will be typical. No adaptations are identified as needed for this scenario, but this scenario is not discussed in this memo. This profile only affects the NTP client, which is one expected to be in deep space. No changes are needed for the server, since it is stateless request processing (Section 8 of ) with no delay-sensitive element.

NTP On-Wire Protocol And Distance The NTP client/server exchange (mode 3 request, mode 4 response, Section 8 of ) is a single stateless request/response carrying four timestamps: T1 (client transmit), T2 (server receive), T3 (server transmit), T4 (client receive). Nothing in the on-wire protocol bounds the interval between T1 and T4: the offset and delay equations of Section 8 of are defined for any round-trip time. One time transfer therefore costs exactly one round trip at any distance. The measurements confirm this from an 8-minute up to a 20-hour RTT, with a single unmodified exchange each time (). However, there are client-side impacts:

• The client's response timeout must exceed the number of round trips the operation needs times the maximum RTT of the mission (propagation plus any scheduled contact gap, as computed in ), plus margin. While the specifications place no limit, common defaults in implementations are a few seconds (see ), unsuitable for most deep space scenarios.
• The client's poll interval must exceed the maximum RTT. Section 8 of requires a client to validate a response against the origin timestamp of its most recent request (the "bogus packet" test, an anti-replay measure) and describes a single in-flight exchange per association. A client polling faster than the RTT replaces its expected origin before each response arrives, so every response fails the origin test and is discarded; the protocol then never synchronizes, even though every packet is delivered intact. The specification's poll range accommodates most deep space missions without change: MAXPOLL is 17 (2^17 s, about 36 hours, Section 7.2 of ).

Protocol Versions The client/server exchange has been wire-compatible, and no version of the protocol changes its delay behavior (, ). Therefore, unless specified, this document applies to any NTP version.

Delay Limits and Defaults While the on-wire protocol is delay-indifferent, the mitigation and discipline algorithms specified (Sections 10 through 13 of ) contain constants and defaults sized for terrestrial delays.

Distance Threshold and Dispersion Bounds The selection algorithm (Section 11.2.1 of ) rejects any source whose root synchronization distance exceeds the distance threshold MAXDIST, whose default is 1.5 seconds (Section 7.2 of ). The root distance includes half the round-trip delay, so with default constants every source beyond a 3-second RTT (roughly the Earth-Moon distance) is structurally unselectable: the algorithm as specified can never synchronize to a deep space source, regardless of packet delivery. The dispersion constant MAXDISP (16 seconds, Section 7.2 of ) also bounds the root distance that a server may advertise; this limit applies to servers synchronized over a deep space path and is described in . Deep space clients must raise the distance threshold (and any implementation analog, such as per-source delay ceilings) to at least maxRTT/2 plus margin. The measurements () confirm both the failure with defaults and the success once raised.

Root Delay and Root Dispersion through Relays A server includes in its responses the root delay and root dispersion of its own synchronization path (Section 7.3 of ). A server synchronized to an upstream server sets its root delay to the upstream root delay plus its measured round-trip delay to that server (Section 11.2.3 of ). A relay synchronized to Earth over a deep space path therefore advertises a root delay at least equal to its Earth RTT: 480 seconds for a Mars relay at closest approach, 2640 seconds at conjunction. However, the specification has limitations:

• Header validation: a client discards any response for which root delay/2 + root dispersion is equal to or larger than MAXDISP, 16 seconds (the packet() routine, Appendix A.5.1.1 of ). This check is independent of the distance threshold of : raising MAXDIST does not change it. A client of a relay whose Earth RTT exceeds 32 seconds discards every response of that relay.
• NTPv4 field range: root delay and root dispersion use the NTP short format, 16 bits of unsigned seconds and 16 bits of fraction (Section 6 of ). The largest value is 65536 seconds (about 18.2 hours). A relay whose root delay exceeds this value cannot represent it.
• NTPv5 field range: root delay and root dispersion use the time32 type (Sections 5 and 6 of ), with 4 bits of integral seconds and a maximum value of 16 seconds. A relay whose Earth RTT exceeds 16 seconds cannot represent its root delay in NTPv5.

SNTP clients (Section 14 of ) are not required to apply the header validation and may accept such responses, but the root distance they report is then either unbounded or omitted. The following approaches address these limits:

• The relay acts as a new root. The relay obtains time from Earth (by an SNTP exchange or a full client pipeline, per and ) and serves its local network as a primary server (stratum 1), with the Earth time acting as its reference clock. The root delay and root dispersion it advertises then describe the error of its own clock relative to Earth time, as estimated by the mission, instead of the Earth RTT. With symmetric or corrected path delays (), this error is much smaller than the RTT. This approach works with unmodified clients, in NTPv4 and NTPv5. The advertised values are the mission's estimate: they need to include the residual asymmetry of the Earth-relay path () and the drift of the relay clock since the last Earth exchange. The NTPv5 definition of root delay as twice the maximum error due to delay asymmetry (Section 10 of ) is consistent with this approach.
• The clients behind the relay use a larger header validation bound. This requires the bound to be configurable (), and is limited by the NTPv4 field range; it is not possible in NTPv5.
• An NTPv5 extension field could carry root delay and root dispersion with a larger range. No such extension field is currently defined.

Therefore, relays beyond a 16 second one-way delay from Earth should act as a new root, with advertised root delay and root dispersion derived from the mission's estimate of the relay clock error. The measurements confirm the header validation limit, the effect of a real relay at Mars distance on its clients, and the operation of a relay acting as a new root with unmodified clients ().

Poll Defaults, Burst Modes, and Reachability Default poll intervals (commonly 2^6 = 64 seconds) sit below deep space RTTs and trigger the origin-test failure of ; the poll interval must be configured above the maximum RTT, which the specified poll range permits (Section 7.2 of ). Burst features that send several packets seconds apart at startup (the burst and iburst behaviors of the poll process, Section 13.1 of ) must not be used: all packets of the burst are in flight simultaneously on a long-delay path, at most the last can pass the origin test, and an implementation that concludes unreachability from the unanswered burst gives up long before any response can physically exist. The reachability register (Section 13.1 of ) is an 8-poll shift register and is compatible with deep space operation provided the poll interval exceeds the RTT, so that each poll's response can arrive before the next poll shifts the register.

Clock Filter Sample Requirements The clock filter algorithm (Section 10 of ) selects among the last several samples, and implementations generally require several accepted samples before the source statistics permit selection and clock update. With the poll interval necessarily above the RTT, a full mitigation pipeline therefore delivers its first correction only after several polls: approximately N x poll + 1 RTT for an N-sample requirement, i.e., 3 to 5 RTTs in practice (measured: about 3 RTTs with a 3-sample implementation, ). Missions needing a first correction in one round trip should use an SNTP-style client (Section 14 of ), which applies a single exchange directly; the trade-off is forgoing the filter's protection against outliers, likely acceptable on a point-to-point scheduled link whose delay distribution is deterministic.

Accuracy over Symmetric Paths The offset equation of Section 8 of is exact when the forward and reverse delays are equal, whatever their magnitude; the well-known error bound of plus or minus RTT/2 is the bound on asymmetry, not on delay. Deep space delay therefore costs nothing in accuracy by itself. The measurements confirm this at scale: a deliberate 300-second clock error was corrected to within 0.1 to 0.25 seconds by a single exchange at RTTs of 8 minutes, 44 minutes, 2 hours, and 20 hours, with no degradation trend across three orders of magnitude of delay (). A correction is one RTT stale when applied: at a 20-hour RTT, the residual error is dominated by the client oscillator's drift over that RTT, not by the protocol.

Path Delay Asymmetry When the forward (client to server) delay dfwd and the reverse delay drev differ, substituting into the offset equation of Section 8 of shows the computed offset is wrong by exactly (dfwd - drev)/2, while the computed delay still equals dfwd + drev. The client observes only the sum, so the error is invisible to the protocol: no version, extension, or algorithm of NTP can detect it from the four timestamps. The measurements trace the predicted bias precisely, holding the RTT constant while varying the split, with two independent client implementations agreeing on the (wrong) result within 40 milliseconds (): a client on an asymmetric path synchronizes confidently to a clock that can be wrong by minutes. Delay asymmetry is expected in deep space deployments, specially for intermittence scenarios where relays hold packets in buffer until the next opportunity(see ), which may be different on the reverse path. Therefore:

• Time synchronization exchanges should be scheduled so that both directions traverse the link back to back within one contact, avoiding intermittence buffering holds between request and response.
• Where directional delays are predictable (rate differences, known schedules, ephemeris), clients may correct the computed offset by the known (dfwd - drev)/2 before applying it. However, extra care should be taken given the implicit assumptions.
• Time synchronization should not be performed across paths whose asymmetry is unknown and potentially larger than the mission's accuracy requirement.

Secured NTP: Network Time Security NTS bootstraps per-request authentication through NTS-KE, a TLS 1.3 handshake over TCP on port 4460 (Section 4 of ), which means 4 to 5 RTTs to complete the TCP connection establishment, TLS 1.3 handshake, the NTS-KE exchange and the first authenticated NTP exchange. TCP does not work well with deep space delays and intermittence. Cold NTS establishment over a deep space delay is therefore not recommended. Missions requiring authenticated time should pre-provision NTS keys and cookie material before launch or over a prior contact, sized (using the cookie-supply maintenance provisions of Section 5.7 of ) to cover the interval between re-keying opportunities; alternatively, symmetric-key authentication of NTP packets (the optional MAC field of Section 7.3 of with pre-shared keys) provides origin authentication with zero additional round trips and no handshake, at the cost of manual key management.

Implementation Requirements An NTP client implementation:

• must expose every timing-related constant as runtime configuration: response timeouts, poll intervals and their bounds, response-acceptance (origin validity) windows, sample-count requirements, distance and delay thresholds, the root distance bound of the header validation (MAXDISP, ), and any handshake or key-establishment timers. A single compiled-in constant below the mission RTT anywhere in the receive path is sufficient to make synchronization impossible.
• must scale response-acceptance windows with the configured poll interval rather than fixing them, so that configuring poll above the RTT is sufficient.
• should support a single-exchange mode (SNTP-style, Section 14 of ) for one-RTT corrections, an asymmetry correction input per , and frequency (rate) discipline per .
• when used as a relay serving time onward, should support operating as a primary server using time obtained from Earth as its reference clock, with configurable advertised root delay and root dispersion ().

Applicability to the Deep Space Connectivity Scenarios This section maps the profile to the connectivity scenarios of : Earth to cruising spacecraft (CS), Earth-Moon with full (LF) or intermittent (LI) connectivity, Earth-Mars with full (MF) or intermittent (MI) connectivity, and solar conjunction (SC). Synchronization applicability per scenario

Scenario	Single-exchange (SNTP)	Full mitigation pipeline	NTS
LF (Moon, full)	yes, timeouts only	yes; RTT just exceeds default MAXDIST, raise threshold	yes, KE seconds
LI (Moon, intermittent)	yes, timeouts cover gaps	yes; poll above RTT plus gap	yes if keys outlive gaps
CS (cruising)	yes, timeouts track ephemeris	thresholds and poll grow with ephemeris; verify ceilings pre-launch	pre-provisioned keys once RTT exceeds seconds
MF (Mars, full)	yes, 1 RTT per sync	3-5 RTT per first correction, all thresholds raised	pre-provisioned keys only
MI (Mars, intermittent)	yes if exchange fits one contact	poll and sample budget must fit contact plan	pre-provisioned keys only
SC (conjunction)	suspend; free-run on oscillator	suspend; rate discipline carries through	keys must outlive blackout

Scenario notes:

• LF and LI: at a 2.6-second Moon RTT, terrestrial defaults mostly survive, with two exceptions already visible: the default distance threshold of sits at the Moon RTT boundary, and any sub-RTT hardcoded response window () already fails on an intermittent lunar path whose effective RTT includes a contact gap. The Moon is the last place where defaults mostly work.
• CS: the RTT grows continuously; client timeouts, poll intervals and thresholds should be driven from the ephemeris. Each fixed ceiling in the client is crossed at a predictable mission date; per , missions must verify before launch that none lies inside the mission profile.
• MF and MI: the single-exchange client with an ephemeris-driven timeout is the base: one RTT per synchronization, accuracy limited only by path asymmetry () and oscillator drift over the RTT. In MI, the request and its response must be scheduled within the same contact, or the buffering becomes a large asymmetry error. Orbiters or surface gateways serving time to local assets act as a new root ().
• SC: synchronization traffic ceases for weeks; clocks free-run. Requests should not be sent during a blackout, and if they are, queued time-sync requests should be discarded rather than answered after a blackout, since a response to a weeks-old request carries a weeks-scale asymmetry error. Requests should be freshly issued after contact resumes.

Time Zones and References NTP uses UTC as its time reference, which sets the clocks of all spacecrafts based on the Earth UTC. Missions have been using various time references and a Lunar Timezone is being defined. Any non UTC reference is outside the scope of this document.

Security Considerations Unauthenticated NTP over deep space inherits the usual NTP risks as discussed in . This profile changes the security posture in the following ways. Widening response-acceptance windows to one RTT or more (the origin validity implied by ) widens the interval during which a captured response can be substituted or delayed toward the client by the same amount. The origin timestamp still binds a response to a specific request (Section 8 of ), so the exposure is response substitution and delay, not arbitrary replay. Successful delay attacks are stronger: per , an attacker (or an innocent relay schedule) that asymmetrically delays one direction by D shifts the client's clock by D/2 with no protocol-visible indication, and the acceptable delay at Mars is minutes to hours, giving an on-path attacker minutes-to-hours of undetectable clock displacement. No NTP version detects this; only external knowledge (ephemeris-based delay prediction, plausibility bounds on the clock correction, redundant paths) bounds it. Missions may apply mission-derived sanity bounds to any computed correction before applying it. A relay acting as a new root () advertises a root delay and root dispersion that are an estimate by the mission, not a measurement. Clients use these values to select sources and to bound their error; values that understate the relay clock error, by mistake or by compromise of the relay, lead clients to trust a clock with a larger error than advertised. The NTS cold key establishment is impractical in most scenarios if done during the mission. Therefore, NTS-enabled missions will fly long-lived pre-provisioned key and cookie material, increasing the value of that material. Symmetric-key MAC authentication avoids the handshake entirely.

IANA Considerations This document has no IANA actions.

Acknowledgements The following people provided useful comments to improve this document (in no specific order): Hal Murray, Gary Miller, Miroslav Lichvar, Ruben Nijveld.

References Informative References NTPsec Project chrony project Network Time Foundation Project Pendulum NASA Jet Propulsion Laboratory, Navigation and Ancillary Information Facility (NAIF) NASA Marc Blanchet

Measurement Campaign Summary This appendix summarizes the emulation campaign backing the analysis of the document. Full inputs, captured packets, per-run outputs and analysis are published at . Two virtual machines (Ubuntu 26.04) emulate the Earth side (server, free-running reference clock) and the deep-space side (client). A network emulator (Linux netem) inserts a configurable one-way delay independently in each direction: symmetric one-way delays of 240, 1320, 3600 and 36000 seconds (RTTs of 8 minutes, 44 minutes, 2 hours, and 20 hours), and asymmetric splits of 270/210, 420/60 and 60/420 seconds at a constant 480-second RTT. All operating system time synchronization was disabled and masked on both machines; before every test the client clock was deliberately offset by about +300 seconds; packet captures on both machines and before/after clock probes document every run. It should be noted that using Virtual machines may have impact on the precision of the measurements, but the primary purpose was to test the specifications and implementations over much larger timeframes than the actual precision. Therefore, the actual real precision measured may not be as accurate as if done with real hardware. Four independent implementations were used: ntpsec 1.2.3 (the ntpdig single-exchange client) , chrony 4.8 (full mitigation pipeline in one-shot mode, server mode, and NTS client mode) , the ntp.org reference implementation 4.2.8p18 (sntp single-exchange client and ntpd server in orphan mode) , and ntpd-rs 1.9.0 (daemon client and server, NTPv4 and native draft NTPv5) . In these tests, the Earth server used its local clock as reference and advertised a root delay and root dispersion of zero. A second series tested root delay through relays (), with the same implementation versions in containers sharing one clock, clients measuring without adjusting the clock:

• A test server advertising root delays from 0 to 65535 seconds, with no network delay. The full daemons (chrony, ntp.org ntpd) accepted up to 31 seconds once their distance threshold was raised and discarded every response at 33 seconds and above with any configuration (header validation). The SNTP clients (ntpdig, sntp) accepted all values; ntpdig did not include the root delay in its reported error bound. ntpd-rs accepted all values.
• A chain Earth server, relay (240 second one-way delay to Earth, 480 second RTT), surface clients (no added delay), with the relay as a regular NTP client of Earth and server to the surface. The relay synchronized after three polls (about 25 minutes) and advertised a root delay of 480.08 seconds and a root dispersion below 1 second. The chrony and ntp.org ntpd clients discarded every response of the relay with default and raised distance thresholds (header validation); the SNTP clients and ntpd-rs accepted the relay, with reported error bounds ranging from 0.4 milliseconds (root delay ignored) to 161 seconds.
• The same chain with the relay acting as a new root: SNTP exchanges with Earth every 30 seconds fed as a reference clock, advertised root delay 0.5 seconds. The relay served as stratum 1 after one RTT and a few reference clock updates (11 minutes), with measured Earth offsets within 20 milliseconds, and all the clients, with default configurations, accepted it.