| Internet-Draft | IP in Deep Space | July 2026 |
| Blanchet, et al. | Expires 7 January 2027 | [Page] |
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. Most of the IP protocol stack used on the Internet, in particular reliable transport protocols and applications, is based on the assumptions of shorter delays and mostly uninterrupted communications. This document describes the key characteristics, use cases, and requirements for deep space networking, intended to help when profiling IP protocols in such environment.¶
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 7 January 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 communications involve long delays (e.g., Earth to Mars is 4-24 minutes one way) and intermittent communications, mainly because of orbital dynamics. Up to now, communications have typically been done on a layer-2 point to point basis, in some cases with relays operating at layer-2 or below. Most missions have operated on their own, without direct data exchanges between spacecrafts at higher layers.¶
Use of networking technologies, including IP, has become established within space vehicles that have their own onboard networks. Complex human exploration and collaborative science missions are driving increased networking between vehicles. Additionally, there is a rising need for interoperability between mission end-users and multiple service providers. As the scale of missions, link interconnections, and application interactions grows, it will be increasingly important to support standard IP-based network data flows.¶
This document describes the key characteristics and use cases for networking in deep space. It provides examples taken from the current communications facilities to reach the Moon and Mars, as well as future plans. While these examples provide great insight on what is possible today, the resulting architecture should also consider future possibilities and farther celestial bodies. For example, while the number of relays and orbiters around the Moon and Mars is currently limited, it is expected that their number will increase significantly, therefore providing improved coverage around those celestial bodies, resulting in an impact on communications and networking traffic patterns, intermittence and alternate paths.¶
Initially the needs considered in this document are to support IP-based applications in or between private networks, without assumption of reachability to/from the global Internet. At least initially, interplanetary IP networks are likely to be protected from the Internet, and vice-versa the Internet is protected from them (since they may have unique routing, congestion control, and other behaviors). However, over time it is possible that connectivity to the Internet may become available for some mission assets, and eventually interplanetary networks could become part of the Internet.¶
This work is a followup of an assessment on the use of the IP protocol stack in deep space [I-D.many-deepspace-ip-assessment].¶
Communication in deep space is vastly different than on Earth. This document does not describe space communication technologies below IP, but only the information relevant from the IP protocol stack viewpoint for the purpose of its engineering. More information is available for the Moon [ioagmoon] and Mars [ioagmars].¶
Position, Navigation and Timing (PNT) is not directly discussed in this memo, but is a vital offering from space network service providers, in addition to data communications. Networking can support some of the data exchanges that facilitate PNT services.¶
Near Earth orbits, such as Low Earth Orbit (LEO), Medium Earth Orbit (MEO), and Geosynchronous Earth Orbit (GEO) communications and networking to and from Earth are out of scope for this memo. Near-Earth satellite networking, including 3GPP Non-Terrestrial Networks (NTN), operates with round-trip times of milliseconds to hundreds of milliseconds and generally continuous connectivity through constellation handover; techniques developed there do not address the minutes-to-hours delays and scheduled multi-day disruptions characteristic of deep space, which are the focus of this document. However, the same 3GPP NTN technologies are expected to be used in low orbits around other celestial bodies; in that context, orbiting a celestial body and serving its surface and orbital assets, they are in scope of this document. In addition, given the relatively small distance to the Moon, there are possibilities to use spacecraft around Earth or at Lagrange points as relays to communicate with lunar assets. In this context, these possibilities are in scope.¶
The source of this document is located at https://github.com/marcblanchet/draft-tiptop-usecase. Comments or changes are welcomed by filing a PR or an issue against that repository.¶
This subject should be discussed on the IETF tiptop working group mailing list.¶
Compared to Internet on Earth, deep space communications and networking have multiple challenges, such as:¶
Without any changes, a typical Internet application will not work in this environment, though some Internet stack protocols are more suitable than others. Among the challenges in this list, the primary factors impacting Internet stack protocols are delays and disruptions, discussed in this memo.¶
This section describes the following cases of mission operating environments: Moon (surface and orbiting), Mars (surface and orbiting), Lagrange points, cruising spacecraft, and onboard spacecraft, starting with some commonality between all cases.¶
The Consultative Committee for Space Data Systems (CCSDS) is an organization comprised of many space agencies that has developed various link-layer protocols used on the links between Earth, orbiters and surface assets. Examples include Telecommand (TC) [CCSDS_TC], Telemetry (TM) [CCSDS_TM], Advanced Orbiting Systems (AOS) [CCSDS_AOS], and Proximity1 (Prox1) [CCSDS_PROX1]]. A newer Unified Space Data Link Protocol (USLP) [CCSDS_USLP], has been designed to replace these in the future. A generic encapsulation mechanism is defined by CCSDS to support networking and other uses over these link layer protocols, including IPv4, IPv6, and IP header compression options [IPoverCCSDSSpaceLinks][SANAIPEHeaderRegistry]. IP packets can be transported over any CCSDS link layers.¶
Surface assets on celestial bodies, such as habitats, rovers, stations and others may communicate with each other while on the surface network using Earth terrestrial technologies such as IEEE 802.11 and 3GPP technologies [ioagmoon][ioagmars] using IP, similar to the Internet, where links are almost always connected and there are no significant delays. They may also communicate using a relay orbiter.¶
Multiple providers, such as the LNSPs for the Moon, will provide various services including communications and networking.¶
Orbiters acting as communications relays are already deployed or planned for both the Moon and Mars. A sufficient number of orbiters can create a constellation which may provide full coverage of the celestial body surface [ioagmoon][ioagmars], or at least key regions (e.g. the lunar south pole). Relaying from one surface asset to another surface asset through these orbiters may use either CCSDS link-layers or link-layers similar to LEO constellations on Earth.¶
Space missions are typically planned many years in advance and are long-lived, spanning over many years or decades. Spacecraft are controlled from Earth and therefore should always be manageable from Earth. Given the remoteness and the difficulty to physically access the spacecraft, software upgrades and configuration changes are avoided whenever possible and backward compatibility is paramount.¶
Space exploration is more than ever carried by multiple stakeholders. A mixture of assets operated by government, commercial, and academic/research organizations from multiple nations are deployed. They will operate largely independently, but collaboration over time is expected to meet shared science goals, joint exploration missions, and mission cross-support needs (e.g. in contingency and emergency cases).¶
While links can be noisy due to weak signals, interference, etc., often packet delivery is actually virtually error-free due to the strong coding available within the link layer. Delivery is generally in-order. Queuing in modems, gateways, and other systems may be significant in comparison to typical terrestrial device queues, while the memory available for such queues on space-qualified hardware is often severely constrained; both the depth and the sizing of these buffers should be considered. In some planetary proximity regimes, CCSDS COP-1 or COP-P link layer retransmissions may be performed, further improving reliability at the IP layer (at some expense to delays). Packet losses might be more common in some specific cases of either very low link margins or aggressive Adaptive Coding and Modulation (ACM), even though they might generally be avoided through physical link engineering and contact planning. See Section 5.2 for requirements related to timers used for loss detection.¶
There are currently very few orbiters around Moon but there are plans to establish multiple constellations of them to be used as communication relays. As few as 5 cooperating orbiters at the right orbits is sufficient to provide full coverage [ioagmoon], and smaller sets of orbiters can be targeted to provide full coverage of specific limited regions such as the far side or the polar regions [imconstellation]. Until full coverage is accomplished, interruptions of communications are expected. While Earth ground stations are able to directly cover assets on the near side of Moon, use of relays may still be desirable to improve power usage, data capacity, and spectrum efficiency.¶
Different types of networking nodes are expected on the lunar surface, with a wide range of capabilities, from those that have very limited functionality (similar to IoT devices on Earth), up to more highly-capable infrastructure hub nodes that provide access for other surface users (e.g. in a habitat or lander), and in-between cases such as crewed or uncrewed rovers that may have combinations of direct-to-Earth, with proximity orbiters, or via local wireless LAN or cellular capabilities.¶
The LunaNet Interoperability Specification (LNIS) [lnis] is a framework including IP networking support for lunar service providers and users to acheive interoperability.¶
NASA has described plans for a sustained lunar surface base, the Moon Base program, near the lunar south pole, deployed in phases and comprising commercial landers, crewed and uncrewed rovers, drones, and later pressurized habitats and power infrastructure [nasamoonbase]. The networking use cases described in this document, including surface networks interconnecting habitats, rovers, drones and other surface assets, surface-to-orbiter relaying, and direct-with-Earth links, are intended to cover such deployments.¶
For human / crewed operations, nearly continuous coverage and data flows might be expected. However, for other types of network users (such as science missions), only limited communication opportunities may be available.¶
Some nodes (such as those supporting human missions) may have multiple/redundant links available simultaneously, but this should not be expected in general, and even then it is likely to be more for failover use than for multipath network transport.¶
Data link operation is scheduled in advance through coordination between the end-user mission operations centers and LNSPs. The time windows for operation and data rates are well-known in advance (typically days or more). Successful link operation generally requires both directional pointing/tracking (with knowledge of vehicle locations and motion) of antenna systems, as well as pre-configuration of modem / signal processing and gateway systems that require prior coordination on many parameters. Ad hoc or random access may be available at some later point, but is likely to be rare for at least proximity and direct-with-Earth links.¶
Near or on the surface, it is currently expected that the mobile spacecraft such as rovers or humans will be moving slowly compared to fast-moving vehicules on terrestrial networks where specific requirements are needed for handover.¶
While interoperability and cross support are frequently expected, there is no assumption in-general that different parties can simply connect at the link layer or trade packets at the network layer (either directly or through intermediaries). Network routing and interconnection is likely to be closely coordinated and limited by policies established jointly between cooperating organizations. It is not likely to be directly like the Internet, with BGP, DNS, etc. generally available to support interdomain operations.¶
One-way delay from Earth to Moon is around 1.3 seconds.¶
Capacity is expected to eventually be in the range of hundreds of Mbps over radio links and Gbps via optical links between Earth and Moon assets [ioagmoon].¶
There are currently some orbiters around Mars, of which 4 are actively in use as relays, and 2 active rovers. Multiple missions are planned[ioagmars] in the coming years. Communications are from ground stations on Earth, such as the DSN, to Mars orbiters acting as layer0-1 relays to surface assets such as rovers, and reverse. The relays do not have notion of frames, and only forward bits at different frequencies for each segment, a mechanism named "bag of bits"[ioagmars]. These orbiters can do as "bent-pipe" when the two segments are active, or by storing the bits as "store-and-forward" until the next segment becomes available. Since the current set of orbiters do not provide full coverage of Mars, the communication windows are calculated and planned between Earth and each orbiter, and between each orbiter and each surface asset. Currently, only one rover can use a relay link at any given time. The MaROS project[maros] sponsored by the Jet Propulsion Laboratory acts as a broker to enable missions to enter data about the communications capabilities such as frequencies, bandwidth, window of communication time, ... so that rover missions can schedule the available communications windows for transmitting and receiving. Most orbiters are used and scheduled in MaROS. One of the Mars orbiters is Mars Reconnaissance Orbiter(MRO)[mro]. It was launched in 2005 and has a single 40Mhz processor but over 100G of solid state memory. MaROS experience over years shows that the current bottleneck is not the temporary storage of the relays but the bandwidth from Mars surface assets to Mars orbiter relays. As demonstrated by a study[marscommstudy] on Mars communication windows, the communication windows seem to happen at a constant frequency, but the reality shows that the timing is pretty variable, which means a very large range of resulting round-trip time (RTT) for communications from Earth to Mars and back. For example, within 3 months in 2024, the calculated RTT of the various combinations of orbiters and rovers varied from 30 minutes to 170 hours.¶
Surface assets are commanded directly from Earth but at a very low rate. The traffic from the assets to Earth goes through relays.¶
It is expected that future constellations of Mars orbiters acting as relays will also have optical inter-satellite links[ioagmars]. The current orbiters were put in various orbits for the purpose of science, and usually have a small number of short relay opportunities per day. However, dedicated relay orbiters could be put at much higher altitudes to provide much better coverage.¶
About every 26 months, a solar conjunction happens for a period of around two weeks, where the Sun is between Earth and Mars, therefore causing the interruption of communications between Earth and Mars, as described in Section 4.6.¶
One-way delay from Earth to Mars is from 4 to 24 minutes, depending on the actual relative distance between them.¶
It is envisioned that optical links between Earth and Mars may deliver hundreds of Mbps[ioagmars].¶
Sun-Earth and Earth-Moon Lagrange points, such as Earth-Moon (EML)-1,2,4,5 and Earth-Sun (ESL)-1,2, are popular for science mission objectives and also being considered for communication relays and therefore potential network forwarders.¶
Sets of cooperating spacecraft may also be used to increase data return and streamline operations for science missions co-located at Lagrange points, by networking locally and sharing a common DWE "trunk link".¶
Spacecraft that are cruising towards a deep space destination are assumed to generally be reached via direct point-to-point links from Earth using CCSDS link-layers.¶
Modern spacecraft generally contain multiple computers typically linked with wired realtime buses or links such as CAN, SpaceWire, RS-422, and others, but also increasingly using Ethernet or Time-Triggered Ethernet [tte] (TTE), with IP as the networking layer. Especially in complex human-crewed vehicles, WiFi is becoming important, and has been used extensively in the International Space Station and planned for the Lunar Gateway.¶
IP networking onboard a spacecraft (or within a habitat) can support applications within the local network, without experiencing most of the typical space communications challenges described prior. Considerations need to be made, however, in order to make sure these applications do not rely on typical wider infrastructure (e.g. DNS, NTP, etc.) that may not be externally available in space. Additionally, some nodes on the network may be mobile/dynamic, such as astronaut suits and personal electronics, rovers, etc.¶
Multiple countries are developing systems aimed for a sustained lunar presence combining crewed and robotic missions. The technologies developed for lunar use are intended to be applied later for Mars as well, and might equally apply for missions to asteroids and other deep space bodies. IP has been included in the stack for the International Deep Space Interoperability Standards [idsis], and the LunaNet Interoperability Specification [lnis]. There is a general intention to extend and reuse systems developed for lunar use to later Mars use.¶
Separate space agencies and private companies are deploying lunar space stations, orbiters, landers, rovers, habitats, crewed mission elements, and other assets. Due to pervasive use and support of IP in modern computing systems, it is used onboard many space systems already, and between co-located systems (e.g. onboard ISS), and planned to be needed for networking on the Lunar Gateway, in Lunar 3GPP surface networks, and in Lunar habitat LAN and WLAN networks.¶
As more-and-more IP-enabled assets become deployed in lunar vicinity, it will increasingly create opportunities to interconnect them. In fact, internetworking of lunar (and future Mars) systems is becoming essential, as plans call explicitly for cooperation between mission elements and communications/navigation system assets operated by different space agencies and/or private companies acting as service providers.¶
There are expected to be several different interoperable LNSPs offering a variety of relay and/or DWE services, to provide wide coverage and cross-support opportunities. As more significant numbers of missions target Mars and other bodies, the same concepts should apply.¶
It may be expected that planetary IP networks should over time become united into larger aggregates, and even into a single interoperable network (as intended within the LunaNet conception).¶
It is expected that surface assets (for Moon, Mars, asteroids, etc.) will communicate with other surface assets on the same body through typical Earth-based wireless technologies such as WiFi or 4G/5G/6G, or via a orbiting relays.¶
Regarding applications, the following is an incomplete list:¶
This section describes example connectivity scenarios in deep space. Each scenario is labeled with a two-letter acronym so that other documents, such as protocol profiles, can refer to them. This list is not intended to be exhaustive.¶
A spacecraft cruising towards a deep space destination communicates directly with Earth. The one-way delay increases over time, but at orders of magnitude lower speed than the speed of light; therefore the round-trip time increases "slowly".¶
Moon assets are mostly always reachable, as with the terrestrial Internet. This can be accomplished in various ways, such as a constellation of low Moon orbit satellites connected together with Optical Inter-Satellite Links (OISL). For example, many rovers, drones and habitats on the Moon surface are connected to a 3GPP 6G network provided by such a constellation. At any single point in time, one or many of these satellites are communicating with Earth, providing full connectivity on the Moon and between the Moon and Earth. The Earth to Moon one-way delay is around 1.3 seconds. This scenario is the end goal for both the Moon and Mars. Given announced constellation deployment plans, essentially full coverage of the relevant lunar sites may be achieved in the near future. In such deployments, intermittence becomes an exception to be handled (e.g., equipment failures, contingencies, or power-save periods) rather than the general rule. Documents profiling protocols for these environments should therefore provide recommendations for both the intermittent and the full-connectivity regimes.¶
Moon assets are reachable by intermittence from Earth. This can happen when there is a limited number of satellites which do not provide full-time connectivity. The Earth to Moon one-way delay is around 1.3 seconds.¶
Mars assets are mostly always reachable, as with the terrestrial Internet. As for the Moon, this can be accomplished in various ways, such as a constellation of satellites around Mars connected together with Optical Inter-Satellite Links (OISL). The Earth to Mars one-way delay is between 4 and 24 minutes, depending on the relative position of each planet. That one-way delay changes "slowly" as the planets are orbiting around the Sun.¶
Mars assets are reachable by intermittence from Earth. For example, a rover on the Mars surface is connected to a Mars surface IP network which receives intermittent connectivity from a few orbiters, with an average of one overpass every 6 hours. Some of those orbiters have circular orbits, others elliptical; the latter means that the overpasses are not at a fixed frequency. The orbiters are connected to Earth ground stations while they are in line of sight with Earth. The Earth to Mars one-way delay is between 4 and 24 minutes, depending on the relative position of each planet, and changes "slowly" as the planets are orbiting around the Sun.¶
A solar conjunction happens when the Sun is between Earth and another celestial body, blocking or degrading direct communications between Earth and the assets at that body. For Mars, a solar conjunction occurs approximately every 26 months, which is the Earth-Mars synodic period. As the Sun-Earth-Mars angle becomes small, the charged particles of the solar corona increasingly corrupt the radio signals crossing near the Sun, degrading communications before interrupting them completely. Mission operators typically observe a communications moratorium of around two weeks, during which no commands are sent to Mars assets [marsconjunction].¶
Solar conjunctions are precisely predictable years in advance. This scenario is therefore a scheduled, total interruption of the Earth-to-body communications that is much longer than the interruptions of the intermittent connectivity scenarios.¶
Other celestial bodies undergo the same phenomenon at a recurrence equal to their synodic period, such as approximately every 13 months for Jupiter and approximately every 12.4 months for Saturn; the duration of the interruption depends on the geometry and on how fast the body moves relative to the Sun as seen from Earth. Communications between Earth and the Moon are not subject to solar conjunctions, since the Moon orbits Earth. Communications local to the celestial body, such as between surface assets and orbiters, are not affected and continue to operate during a conjunction; only the long-haul links crossing near the Sun are interrupted. In the future, relay spacecraft located away from the direct Earth-to-body line, for example in heliocentric orbit or at Lagrange points, could provide an alternate path around a conjunction, at the cost of a longer path.¶
During a conjunction blackout, traffic sources that continue to generate data (e.g., steady telemetry or science flows) can fill the storage of relays and orbiters; store-and-forward capacity planning and source throttling policies should take these multi-week interruptions into account (see Section 5). Cruising spacecraft on long-distance trajectories may also experience solar conjunctions when the Sun crosses the Earth-spacecraft line. A study of communication delays, disruptions and blackouts for crewed Mars missions is available in [conjunctionstudy].¶
The characteristics described in this document (latency, bandwidth, unidirectionality, intermittence, topology) vary greatly between connectivity scenarios; no single set of constraints applies to all deployments. When evaluating protocol or security solutions against these requirements, the applicable connectivity scenario (see Section 4) should be identified first, since the constraints pull designs in different directions: very low bandwidth links make handshake-heavy mechanisms impractical, while unidirectional links preclude interactive exchanges entirely. Requirements in this section should be read as scenario-dependent and prioritized per deployment rather than simultaneously binding. Table 1 summarizes the main constraints of each scenario.¶
| Scenario | One-way delay | Intermittence |
|---|---|---|
| Earth to Cruising Spacecraft (CS) | increases slowly over the mission | rare; solar conjunctions possible on long-distance trajectories |
| Earth-Moon Full Connectivity (LF) | around 1.3 seconds | exceptional (equipment failures, contingencies, power-save periods) |
| Earth-Moon Intermittent Connectivity (LI) | around 1.3 seconds | frequent, mostly scheduled |
| Earth-Mars Full Connectivity (MF) | 4 to 24 minutes | exceptional (equipment failures, contingencies, power-save periods) |
| Earth-Mars Intermittent Connectivity (MI) | 4 to 24 minutes | frequent, mostly scheduled |
| Solar Conjunction (SC) | not applicable (no direct path) | total, scheduled interruption; around two weeks in the case of Mars |
Until full coverage by orbiter constellations is achieved around a celestial body, the orbiters and other assets that are facing intermittent communications should provide store-and-forward capability. These can be implemented at - layer-1, like the current Mars orbiters, where frames are not seen ("bag of bits"), at layer-2 doing frame storage or at layer-3 doing packet storage. Storage higher in the stack enables more versatile, agile and policy-based routing. For example, the current Mars relay orbiters store below the frame level ("bag of bits") and perform no routing: the stored data can only follow the pre-planned segment. Storage at the network layer allows the forwarding decision to be (re)evaluated at the time of transmission, which matters because the path may have been computed long before a stored packet is actually forwarded, and topology or policies may have changed in the interval. A key factor for designing the store and forward capability of an orbiter is its storage capacity.¶
Surface assets that are facing intermittent communications also need the store-and-forward capability.¶
Mechanisms should be defined to avoid as much as possible storage full events on a relay. This may include some in-advance signaling to the network about future full storage event, so that the network and/or the source can throttle down or reroute packets to avoid that event.¶
In the event of full storage, a policy should be determined on which packets should be dropped, such as the last one in the queue, the first one in the queue, ones based on policies related to packet or transport fields like source or destination addresses, traffic classes, flow ids, etc. , similar to queue management used in terrestrial networks. These policies are important for differentiated trafic such as Emergency and Search and Rescue.¶
Even if calculations can be done based on known orbital dynamics, events happen that result in missed communication windows. For example, some communication windows were not used on Mars because a rover may be still charging and therefore does not have enough energy to perform communications. Random events can also happen because of space weather. Therefore, while the window of comms can be calculated and used, the system should be able to cope with random long interruption events.¶
Proper guards should be designed to avoid denial-of-service attacks by filling storage in the network; this may include authentication and authorization of the traffic sources allowed to consume storage, and accounting of storage usage per source or traffic class.¶
Timers are used in transport protocols, application protocols and applications themselves for various purposes, such as detecting/presuming packet loss or data lifetime. Timers should be therefore adjusted and configured based on the expected travel time and RTT from the source to destination. Given variations and possible dynamic changes in the network that can cause much longer latency, appropriate safeguards should be put for timer values.¶
There are two main challenges that deep space networks pose for use of timers in loss detection. First, for cases like Mars, the time needed to infer a loss and request retransmission is much longer than what protocols are designed for in the Internet, and can be so long as to preclude retransmission within the same contact window. Second, for cases where the timing can vary widely, finding appropriate timeout values and adjusting them automatically may be a challenge. Mitigating the long propagation delays could be approached through various techniques such as higher-level erasure coding (e.g. in application or transport protocols), more aggressive retransmission policies, or other methods. Mitigating varying delays can be approached through the use of planning/orchestration systems to provide guidance on proper values over time, or other methods.¶
Lifetime is also attached to some data, such as content, security keys, certificates, tokens, session keys and naming records. Similarly, the lifetime should be adjusted and configured based on the characteristics of the applications and expected travel time and RTT.¶
Current Internet protocols and applications typically use UTC as their time reference. There are currently work to define Lunar Standard Time, also called Coordinated Lunar Time and Mars Standard Time [lunartime]. Depending on the application and use case, it may be necessary to adapt the protocol or the application to use another time reference.¶
Some IETF protocols such as [RFC5870][RFC8805] use a Earth coordinate system such as [WGS84] or address-based reference[RFC8805] for encoding location. Deep space uses various coordinate systems such as celestial body references[SANACelestialBodyReference] or orbit-relative references[SANAOrbitRelativeReference]. Therefore, IETF protocols carrying location information may need to be updated to also support space coordinate reference systems. An example of such space coordinate reference system addition for IETF protocols is in [RFC9179].¶
Given the large latency of space communications, multiple steps of exchanges or handshakes may still work but are far from optimal and may never converge. Therefore, applications and protocols should be adapted to minimize the number of exchanges.¶
Similarly, applications, protocols or networking stack that depend on signaling back to the source or to somewhere in the path may arrive too late for any usefulness, because of the latency. Therefore, any signaling should be carefully designed based on the expected latency.¶
Given that space communications will always have much lower bandwidth than what is possible in shorter distances such as on Earth, optimization of the bandwidth usage is important. This can be implemented at many levels in the networking stack, starting from layer-2 to IP header compression to transport and application data compression.¶
Since IP (and UDP) does not provide reliable transport services, such as loss, duplicates and reordered recovery, a reliable transport should be used and configured properly for space delays and intermittence for applications and protocols requiring it.¶
Congestion control algorithms may declare congestion based on heuristics such as when delays are increasing. In that case, sources pace down to decrease their usage of the bandwidth. However, given that forwarders in space apply the store-and-forward technique when link intermittence happen, the congestion seen by the source is not actually congestion in the typical Internet sense, but deep buffer usage in forwarders, as a normal and expected operation. Therefore, congestion control should be adapted or not used because of intermittence. At least early on, while the networks are small scale, coordinated resource planning and management may be performed to avoid creating congestion.¶
To minimize routing and forwarding tables, optimal address aggregation is preferred, and it starts with proper allocation of addresses.¶
The network in deep space, not including the surface networks on celestial bodies, will grow at a small pace, which does not warrant complex routing schemes. However, over time, the network will become sufficiently complex not only because of the number of forwarders but also because of the intrinsic intermittent and delay communication patterns, which may warrant more complex routing solutions and orchestration.¶
On a well-connected and low delay network such as Internet, an unexpected reboot of an intermediate node or a endpoint is recovered relatively fast: adjacency can be restored with neighbors for intermediate nodes, and endpoints can resume or restart their connections with their peers within short time. On the contrary, given the intermittence and long delays in deep space, this fast recovery is unlikely.¶
For intermediate nodes, storing in permanent memory the contact schedule or the expected next opportunities for neighbors may help faster recovery.¶
For endpoints, applications may keep a state context in permanent memory, either at the application layer or at the transport layer or both.¶
Electrical power and energy are constrained in systems operating in deep space compared to the terrestrial Internet, although with increasing growth of the Internet of Things (IoT) on Earth, similar constraints are also present in many terrestrial systems.¶
Since there are a variety of different types and sizes of deep space exploration hardware systems, there are different options to generate power including solar panels or radioisotope thermoelectric generators (RTGs). Operating off of batteries is common, since sufficient power is not always able to be generated. In any case, the available power is limited and when transmitting, a substantial amount must go to operating amplifiers and other communications system hardware. Transmissions may be limited to specific times in order to conserve power and budget it during times when more is not available to generate (e.g. when operating in lunar "night" on a part of the moon not exposed to sunlight). Some links and physical layer protocols operate synchronously and transmit continuously when active (e.g. using idle frames), while others transmit only data frames and use "Barker codes" or other burst transmission synchronization methods.¶
The implications of this are that there are a variety of different modes that networking nodes may be in at any time, and some could manifest as temporary "disconnections", even if there is antenna visibility and connectivity would otherwise have been schedulable.¶
Since transmission dominates the power budget, protocols may need asymmetrical behavior to protect the energy resources of constrained nodes: for example, minimizing the number and size of transmissions required from the constrained side of an exchange, even at the cost of additional transmissions from the well-resourced side.¶
Spacecraft frequently use power save modes with asymmetric radio states: the transmitter may be turned off (transmission dominates power usage) while the receiver remains on, or the node may be entirely asleep. Combined with network-layer store-and-forward, a destination may not be listening at the time packets are sent yet still receive them later. Protocols and applications should therefore not assume that a peer is continuously reachable or that a request implies a timely response; since buffered packets are delivered when the destination is listening again, the notion of the peers being simultaneously online does not apply. Key exchange and re-keying mechanisms should be usable asynchronously, tolerating exchanges that complete over an arbitrary delay.¶
The CCSDS has created a reference document covering general security threats against space missions, as well as classes of mitigations [CCSDS-Threats]. This is a useful high-level reference, though it does not go into depth on networking protocols.¶
Security protocols and mitigations are most often based on time, such as keys and certificate lifetimes, tokens lifetime, firewall opened ports time windows, etc. Keys and certificates have also a lifecycle where they should be renewed.¶
Given the delays to act, for example from Earth to a celestial body, notifications of security issues and mitigation actions will be delayed, which may increase the impact of security issues such as denial of service attacks.¶
Security validation, such as certificate validation, based on on-line immediate queries to validation databases, such as done with OCSP [RFC6960], or with a certificate chain will likely take too long if the validation database is far from the validation querier. Techniques such as preemptive caching of validation chain and certs should be investigated.¶
Certificate lifecycle should be well planned to take into account delays and intermittence, so that for example certificate renewals are done sufficiently in advance.¶
Forward secrecy and post-compromise security have different properties and requirements and should be considered separately. Because physical access to deep space assets is generally impossible, recovery from compromise depends on remote means: mechanisms to update trust anchors and credentials over the network, designed to operate under long delays and intermittence, should be part of the security architecture.¶
Some envisioned applications are inherently multi-party: astronaut suit radio networks, space weather alerts, and broadcast navigation or almanac signals (e.g., the LunaNet Augmented Forward Signal). Where such one-to-many traffic requires confidentiality or authentication, group key management adapted to long delays and intermittence would be needed; the specific protocol layers and mechanisms are out of scope of this document.¶
Key establishment and key update mechanisms should be usable asynchronously: given long RTTs and intermittence, mechanisms requiring interactive exchanges before new keys take effect create long windows during which a compromised key remains in use. Moreover, because packets may be buffered in intermediate nodes, a peer that is not reachable at the time of transmission may still receive and process a key update later; key management should therefore not depend on any notion of the peers being simultaneously online, but rather tolerate exchanges that complete over an arbitrary delay. Mechanisms that can establish keys in advance of their use, or complete key updates without an interactive exchange, should be preferred.¶
Devices operating in deep space often have limited computational and memory resources. Key agreement - especially key updates - should be efficient and scalable. Given the potential lifetime of space systems and risk of quantum computing to cryptography, this includes requirements for efficiency and scalability in use of post quantum cryptography.¶
There are no actions for IANA in this document.¶
This following people have provided valuable feedback and comments, in no specific order: Roy Gladden, Padma Pillay-Esnault, Tomek Mrugalski, Atsushi Tagami, Pascal Thubert, Carles Gomez Montenegro, Martin Duke, Xisen Tian, Dan York, Meiling Chen, Tony Li, Britta Hale, Eric Rescorla, Michael Richardson, and John Mattsson.¶