| Internet-Draft | NTP Profile for Deep Space | October 2026 |
| Blanchet | Expires 4 May 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 May 2027.¶
Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Deep space networks based on IP, as described in [I-D.ietf-tiptop-ip-architecture], 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 [RFC5905] 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 [I-D.ietf-tiptop-usecase].¶
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¶
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 Section 5.2. 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 [RFC5905]) with no delay-sensitive element.¶
The NTP client/server exchange (mode 3 request, mode 4 response, Section 8 of [RFC5905]) 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 [RFC5905] 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 (Appendix A).¶
However, there are client-side impacts:¶
The client/server exchange has been wire-compatible, and no version of the protocol changes its delay behavior ([RFC5905], [I-D.ietf-ntp-ntpv5]). Therefore, unless specified, this document applies to any NTP version.¶
While the on-wire protocol is delay-indifferent, the mitigation and discipline algorithms specified (Sections 10 through 13 of [RFC5905]) contain constants and defaults sized for terrestrial delays.¶
The selection algorithm (Section 11.2.1 of [RFC5905]) rejects any source whose root synchronization distance exceeds the distance threshold MAXDIST, whose default is 1.5 seconds (Section 7.2 of [RFC5905]). 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 [RFC5905]) 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 Section 5.2. 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 (Appendix A) confirm both the failure with defaults and the success once raised.¶
A server includes in its responses the root delay and root dispersion of its own synchronization path (Section 7.3 of [RFC5905]). 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 [RFC5905]). 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:¶
SNTP clients (Section 14 of [RFC5905]) 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:¶
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 (Appendix A).¶
Default poll intervals (commonly 2^6 = 64 seconds) sit below deep space RTTs and trigger the origin-test failure of Section 3; the poll interval must be configured above the maximum RTT, which the specified poll range permits (Section 7.2 of [RFC5905]). Burst features that send several packets seconds apart at startup (the burst and iburst behaviors of the poll process, Section 13.1 of [RFC5905]) 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 [RFC5905]) 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.¶
The clock filter algorithm (Section 10 of [RFC5905]) 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, Appendix A). Missions needing a first correction in one round trip should use an SNTP-style client (Section 14 of [RFC5905]), 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.¶
The offset equation of Section 8 of [RFC5905] 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 (Appendix A).¶
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.¶
When the forward (client to server) delay dfwd and the reverse delay drev differ, substituting into the offset equation of Section 8 of [RFC5905] 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 (Appendix A): 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 [I-D.ietf-tiptop-ip-architecture]), which may be different on the reverse path. Therefore:¶
NTS [RFC8915] bootstraps per-request authentication through NTS-KE, a TLS 1.3 handshake over TCP on port 4460 (Section 4 of [RFC8915]), 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 [RFC8915]) to cover the interval between re-keying opportunities; alternatively, symmetric-key authentication of NTP packets (the optional MAC field of Section 7.3 of [RFC5905] with pre-shared keys) provides origin authentication with zero additional round trips and no handshake, at the cost of manual key management.¶
An NTP client implementation:¶
This section maps the profile to the connectivity scenarios of [I-D.ietf-tiptop-usecase]: 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).¶
| 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:¶
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[nasatime] and a Lunar Timezone[lunartimezone] is being defined. Any non UTC reference is outside the scope of this document.¶
Unauthenticated NTP over deep space inherits the usual NTP risks as discussed in [RFC5905]. This profile changes the security posture in the following ways.¶
Widening response-acceptance windows to one RTT or more (the origin validity implied by Section 3) 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 [RFC5905]), so the exposure is response substitution and delay, not arbitrary replay.¶
Successful delay attacks are stronger: per Section 7, 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 (Section 5.2) 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.¶
This document has no IANA actions.¶
The following people provided useful comments to improve this document (in no specific order): Hal Murray, Gary Miller, Miroslav Lichvar, Ruben Nijveld.¶
This appendix summarizes the emulation campaign backing the analysis of the document. Full inputs, captured packets, per-run outputs and analysis are published at [deepspace_simulations].¶
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) [NTPSEC], chrony 4.8 (full mitigation pipeline in one-shot mode, server mode, and NTS client mode) [CHRONY], the ntp.org reference implementation 4.2.8p18 (sntp single-exchange client and ntpd server in orphan mode) [NTPORG], and ntpd-rs 1.9.0 (daemon client and server, NTPv4 and native draft NTPv5) [NTPDRS].¶
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 (Section 5.2), with the same implementation versions in containers sharing one clock, clients measuring without adjusting the clock:¶