Revisiting the Use of the IP Protocol Stack in Deep Space: Assessment and Possible Solutions
draft-many-deepspace-ip-assessment-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Marc Blanchet , Christian Huitema , Dean Bogdanović | ||
| Last updated | 2024-03-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Mailing List |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-many-deepspace-ip-assessment-01
Internet Engineering Task Force M. Blanchet
Internet-Draft Viagenie
Intended status: Informational C. Huitema
Expires: 5 September 2024 Private Octopus Inc.
D. Bogdanovic
AlefEdge, Inc
4 March 2024
Revisiting the Use of the IP Protocol Stack in Deep Space: Assessment
and Possible Solutions
draft-many-deepspace-ip-assessment-01
Abstract
Deep space communications involve long delays (e.g., Earth to Mars is
4-20 minutes) and intermittent communications, because of orbital
dynamics. Up to now, communications have been done on a layer-2
point to point basis, with sometimes the use of relays, therefore no
layer-3 networking was possible. RFC4838 reports an assessment done
around 25 years ago concluding that the IP protocol stack was not
suitable for deep space networking. This result lead to the
definition of a new protocol stack based on a store-and-forward
paradigm implemented in the Bundle Protocol(BP). More recently,
space agencies are planning to deploy IP networks on celestial
bodies, such as Moon or Mars, ground, and vicinity. This document
revisits the initial assessment of not using IP and provides solution
paths to use the IP protocol stack, from IP forwarding to transport
to applications to network management, in deep space communications.
Status of This Memo
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 5 September 2024.
Blanchet, et al. Expires 5 September 2024 [Page 1]
Internet-Draft IP in Deep Space March 2024
Copyright Notice
Copyright (c) 2024 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Document and Discussion location . . . . . . . . . . . . 5
2. IP forwarding . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IP Routing . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. QUIC Transport . . . . . . . . . . . . . . . . . . . . . . . 6
5. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. COAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. UDP Transport . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Applications . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Network services . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Domain Name System(DNS) . . . . . . . . . . . . . . . . . 10
9.2. Network Management . . . . . . . . . . . . . . . . . . . 11
9.3. Network Operations and Security . . . . . . . . . . . . . 11
9.4. Key Management and Distribution . . . . . . . . . . . . . 12
9.5. Time . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Additional Considerations . . . . . . . . . . . . . 18
A.1. IP Version . . . . . . . . . . . . . . . . . . . . . . . 19
A.2. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . 19
A.3. IPv6 over Space Links . . . . . . . . . . . . . . . . . . 20
A.4. Bundle Protocol and IP . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Blanchet, et al. Expires 5 September 2024 [Page 2]
Internet-Draft IP in Deep Space March 2024
1. Introduction
Deep space communications involve long delays (e.g., Earth to Mars is
4-20 minutes) and intermittent communications, because of orbital
dynamics. Up to now, communications have been done on a layer-2
point to point basis, with sometimes the use of relays, therefore no
layer-3 networking was possible. [RFC4838] reports an assessment
done around 25 years ago concluding that the IP protocol stack was
not suitable for deep space networking. This result lead to the
definition of a new protocol stack based on a store-and-forward
paradigm implemented in the Bundle Protocol(BP) [RFC9171] and its
various components, such as convergence-layer adapters([RFC9174],
[RFC7122]) and BP Security(BPSEC)[RFC9172].
More recently, space agencies are planning to deploy IP networks on
celestial bodies, such as Moon[ioag] or Mars[ioag-mars], ground, and
vicinity, using layer2 technologies such as WIFI or 5G.
This document revisits the initial assessment of not using IP and
provide solution paths to use IP in deep space communications. IP in
deep space means running IP over deep space layer-2 links, a reliable
transport over IP, applications protocols over that transport and
applying proper routing, security and network management on that IP
network. Reusing the whole IP stack in deep space enables the reuse
of all protocols, tools and software currently used on Internet.
However, as one might already argue, most of the IP stack can not be
used as is and therefore requires careful configuration and possibly
some protocol changes that are discussed in this document.
The examplary network for this document is where deep space links are
using IP over CCSDS space links[IPoverCCSDSSpaceLinks] and that on
and around a celestial body, a connected network is established with
local network infrastructure and services.
The keyword Delay-Tolerant Networking (DTN), also expanded to Delay
and Disruption-Tolerant Networking, has been used to identify the
problem space and given that up to now, the solution was based on the
Bundle protocol, DTN was also associated with Bundle protocol. This
document tries to solve the DTN problem using the Internet Protocol
stack. Therefore, in this document, the DTN keyword is used to name
the problem space, not the Bundle protocol solution.
This document covers more topics than what may need to be discussed
or standardized in IETF, but the intent is to help answer many
questions raised while looking at the whole problem space, and, in
this context, provides an non-exhaustive list of topics that needs to
be addressed.
Blanchet, et al. Expires 5 September 2024 [Page 3]
Internet-Draft IP in Deep Space March 2024
Since Moon is a few light seconds away from Earth, it is possible to
somewhat configure and run various IP based protocols and
applications to make it "work". Mars with a much longer delay is
more difficult. Therefore, this document uses Mars as the base
example, knowing that if it works for Mars, a much harder problem, it
could be replicated easily for Moon, or for other networks made with
relays around a celestial body. This framework shall also work for
longer delays, such as reaching Jupiter or the whole Solar System
Internet(SSI), but it is not specifically discussed. This document
uses "deep space" extensively in order to differentiate with "space"
which often includes Earth orbiting communications, which is not
discussed in this document.
It should also be noted that DTN and BP were also designed for non-
space use cases. While this document focuses on the deep space use
case, it shall work for the other use cases of BP, but no work or
discussion on these other use cases is provided in this document.
Space missions are typically planned many years in advance and are
long-lived, spanning over many years even decades. Spacecrafts 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.
As with Bundle protocol, this framework proposes to use IP in deep
space with the same store-and-forward paradigm. Therefore, the IP
layer has to deal with the fact that a destination may not be
currently reachable and that IP packets should be stored for an
unusual amount of time, such as minutes or hours or days, in the
forwarding device waiting for a new link up opportunity. The
transport layer should be able to work with long and variable delays,
including intermittent communications. The application protocols and
application themselves should be properly set to wait a longer time
than on Internet to receive a response to a query. Finally, all
network services such as routing, security, naming and network
management should also be adapted in this new context. This document
is structured around these layers.
In a nutshell, this framework is based on the following main pillars:
the storage of IP packets in intermediary nodes while the destination
is unreachable, the use of the QUIC transport[RFC9000] with proper
configuration, the predominance of using HTTP protocol (over QUIC)
for applications, the use of IP network services such as routing,
naming and network management and considerations related to time in
all levels of the stack.
Blanchet, et al. Expires 5 September 2024 [Page 4]
Internet-Draft IP in Deep Space March 2024
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Document and Discussion location
The source of this document is located at
https://github.com/marcblanchet/draft-deepspace-ip-assessment.
Comments or changes are welcomed as a PR or an issue.
This subject should be discussed on the deepspace@ietf.org mailing
list.
2. IP forwarding
In the context of deep space, an IP packet would need to be stored
temporarily over some possible longer period than typical Internet
when the next hop is currently unreachable or undefined, for example
due to orbital dynamics. Therefore, a new queueing discipline might
be needed to store packets in this context, that might be implemented
as a deep queue with active queue management(AQM)[RFC7567].
Bidirectional Forwarding Detection(BFD)[RFC5880] with large timers
should be considered. When the link to the next hop is up, maybe
minutes or hours later, forwarding tables would be updated and stored
packets would be forwarded on the link for appropriate destinations.
This is being discussed in the Time-Variant Routing(TVR) working
group [TVRWG] and one part is implemented as a YANG model
[I-D.united-tvr-schedule-yang].
The store-and-forward paradigm, either implemented in BP or IP or at
higher layers, requires proper sizing and provisioning of memory and
storage for temporarily storing IP packets at each forwarding node
for the target deployment and usage.
Store and forward policies shall be defined and implemented to cover
cases such as when storage is full and new packets are received or
which priorities should be given to packets when link becomes up. An
example is described in [I-D.blanchet-tvr-forwarding].
Various IP stack kernel buffers used for example for reassembly
queues need to be properly sized for the target usage.
Blanchet, et al. Expires 5 September 2024 [Page 5]
Internet-Draft IP in Deep Space March 2024
Storing IP packets (or BP bundles) may in fact make the buffer bloat
issue[buffer-bloat] a much bigger problem if the management of stored
packets is not properly implemented with the right queueing
discipline.
3. IP Routing
Given the relative static nature of space networks at least for the
forseeable future, e.g., new nodes or routers are not often added or
deleted in the network, use of static routes configured based on
contact plan schedules
([I-D.blanchet-tvr-contactplan],[I-D.united-tvr-schedule-yang] may be
sufficient in the short term.
If run over space links, IGPs such as OSPFv3 [RFC5340] have time-
related configurable parameters such as RxmtInterval, InfTransDelay,
HelloInterval, RouterDeadInterval. There are 16 bits values in
seconds, which means a maximum of ~18 hours. This maximum may be too
small depending on the contact plan schedule. Time-Variant
Routing(TVR) working group [TVRWG] is looking at this problem space.
Given that it is likely that multiple network operators will be
present on celestial bodies, it is expected that BGP [RFC4271] would
be used.
4. QUIC Transport
[RFC4838]describes various issues that make the IP protocol suite not
suitable for space. One of them is TCP handshake and timers that do
not work over a 20 minute delay link. If TLS handshake is added on
top of TCP, then it is even worse. In fact, this is similar, but not
identical because of disruptions, to large bandwidth-delay product
use cases[RFC1072], because the delay is large, even if the bandwidth
is somewhat much smaller than on Internet. In last 25 years,
transport protocols have evolved a lot. QUIC ([RFC9000], [RFC9001],
...) is a potential transport solution to the space communications
characteristics, given all its novel features.
QUIC like most IP transports implements congestion control
mechanisms, which, based on various metrics such as calculated delays
or packet loss, pace the rate of sending packets at the source node
to decrease the perceived congestion in the network.
Current implementations of QUIC typically set the initial RTT
estimates in hundreds of milliseconds as it is expected to be a good
start for connecting establishment on Internet. However, that value
is way too low for long delay communications in deep space. By
adjusting initial RTT to a proper value in the QUIC stack for the
Blanchet, et al. Expires 5 September 2024 [Page 6]
Internet-Draft IP in Deep Space March 2024
deep space connection, and given that many timers in QUIC are related
to the RTT, a successful connection can be established. An initial
proof of concept[picoquic-poc] with a QUIC implementation[picoquic]
showed potential use of QUIC in deep space. Additional timers and
parameters may need to be adjusted. Further investigation of QUIC
use in deep space is needed, especially for congestion control,
detection and recovering from loss of data. A document describing
how to profile a QUIC stack for this use case is being
written[draft-huitema-quic-in-space]. The possible use of careful
resume [I-D.ietf-tsvwg-careful-resume] should be considered, as a way
to dynamically update QUIC client stacks based on a better known RTT
estimate from the server.
Establishing a QUIC connections includes discovering the network
conditions, which typically requires several RTT. For space
communications, we need to minimize the impact of the initial delays
either by keeping connections up for a long time, or if that is not
possible by using mechanisms like 0RTT or careful resume to
accelerate the re-discovery of network conditions by the new
connection.
The ability to have multiple streams and applications within a single
QUIC connection is also very valuable and useful for this use case.
A ground station may setup the initial QUIC connection with a
spacecraft and then carry all needed applications and streams over
that same connection.
Given that spacecrafts and ground systems are aware of each other and
are typically managed by the same organization, the trust anchors may
be preloaded so that each peer already have a trust relationship with
the other. This, together with the resume token acquired during a
previous connection, would enable the use of the 0-RTT QUIC feature
enabling sending application data on the first packet. Even more,
the initial QUIC connection could be established while the spacecraft
is on the ground, so that while moving in space, the connection only
needs to be updated with new RTT estimates, either by configuration
or automatically. It should be noted that the 0-RTT feature is
encrypted but vulnerable to replay attacks, which should be
considered in the missions risk assessment.
The mandatory ability to have TLS negotiated at the beginning of the
QUIC connection makes the use of IP layer security (aka IPSec) less
needed to be deployed, while knowing that IP and transport security
are different. Operational complexity in space is very costly and
brings brittleness of the reliability and therefore, a single layer
of security, managed at the application transport (aka HTTP-QUIC), is
very valuable.
Blanchet, et al. Expires 5 September 2024 [Page 7]
Internet-Draft IP in Deep Space March 2024
Session key and certificate lifetime together with certificate
validation and trust chain anchors need to be carefully configured
and handled. This is further discussed in section Section 9.4.
The store-and-forward paradigm, needed for deep space, may also be
implemented at the QUIC transport layer instead of the IP layer, by
architecting a string of QUIC proxies. Those proxies would need to
react to the socket error of no connection by storing the data
payload, until the next opportunity arise. However, that would
require that the actual topology of the network be known at each
proxy and that contact plans also be known at the QUIC proxy layer so
that the proxy does not try to contact when in fact, no connectivity
is happening. There would be no routing updates, so any link change
from the contact plan would not be used. However, some messaging
layer may be put on a network of message relays, connected by QUIC
connections.
QUIC has various applications such as Multiplexed Application
Substrate over QUIC Encryption(masque)[MASQUEWG] and
media(moq)[MOQWG] that could also be used in deep space. Specific
investigation of these need to be done.
QUIC may also be implemented without congestion control. The Bundle
Protocol stack does not have an end-to-end congestion control
mechanism and rely on priority queuings set on each link for specific
bundles. This priority queuing can be done at the IP forwarding
layer as discussed previously. Therefore, implementing a similar
architecture of Bundle Protocol means that the IP transport may not
need congestion control. Moreover, as space links are highly managed
and carefully allocated and provisionned, end-to-end congestion
control may not be as needed as on Internet.
QUIC in deep space has very good promise but requires extensive
investigation and testing to ensure proper usage and deployment.
5. HTTP
HTTP by itself has no notion of time. An HTTP request and response
may take minutes or hours to be completed, theoretically. However,
current infrastructure and software on Internet have various time-
related configurations that will not work as is in the deep space
context.
HTTP headers containing time, such as Cache-Control and Expires
[RFC9111] need to be set large enough to cover the longest delay so
that expiration does not happen before the actual data arrives at the
destination. As with any HTTP application and content on Internet,
these headers should be set properly based on the deployment use
Blanchet, et al. Expires 5 September 2024 [Page 8]
Internet-Draft IP in Deep Space March 2024
case, which is ever more important for deep space. Similarly, when
continuous content transfer is used, as with 100-Continue [RFC9110],
proper values for headers should be set.
HTTP clients and servers typically have default timeouts that shall
be modified. For example, curl [curl] has the "-m" option for this
use case. Similarly, HTTP server implementations have various
timeouts configuration variables to be set properly. Testing with
HTTP client Curl and HTTP server nginx and an introduced network
delay of 20 minutes showed that HTTP communications work just fine
with very basic configuration changes.
HTTP applications themselves must be developed using an asynchronous
pattern and if they have timeouts, they should be adjusted
/appropriately.
Internet Web sites are designed with the assumption of hundred of
milliseconds delay and relatively always connected, where pages
contain multiple queries to further get resources, media, queries to
web services and downloading additional code and frameworks. This
could work in theory in this context of space, but it will not be
optimal, as multiple queries will be generated and therefore taking
multiple RTT before the whole page is received complete. This issue
can be mitigated by using various techniques such as Web Assembly
[wasm] or pre-caching. Moreover, tt could be possible to have very
basic HTML pages with zero or very few href and no media content
unless locally cached to be used. An example would be a rover on
Mars presenting an HTTP server with a base and bare HTML page to
offer basic info on its status (maybe all in text) and some
additional detailed pages, most likely also in base html text.
However, it is foreseen that most applications based on QUIC-HTTP
transport in deep space would be using REST or similar asynchronous
patterns and not typical web browsing.
Caching should be used extensively on celestial bodies networks to
maximize local fetching. Preemptive caching by pre-populating caches
with data that shall be used locally on the celestial body network
shall be done as much as possible to provide better response time on
the local celestial body network.
QPACK [RFC9204] should be considered for higher bandwidth efficiency.
6. COAP
COAP [RFC7252] is an application transport for use with contrained
nodes and constrained networks, which fits well with the deep space
use case. As such, a COAP profile for deep space use has been
defined [I-D.gomez-core-coap-space].
Blanchet, et al. Expires 5 September 2024 [Page 9]
Internet-Draft IP in Deep Space March 2024
7. UDP Transport
This document has a primary focus on HTTP-QUIC-COAP but UDP-based
protocols and applications are also well suited for deep space, as
there is no handshake and no notion of congestion control within the
protocol. Investigation of which applications and protocols over UDP
shall be done to provide proper profiles and best practices for deep
space use.
8. Applications
There are a large number of IETF-defined IP-based application
protocols, as well as non-standard ones. Some may work as is in a
deep space environment, some others may require changes in timers or
else in protocol or in the implementation, and some may not work at
all. It would be appropriate to pick the most likely used
application protocols and assess their usability for this use case.
It may also be useful to test implementations. Obviously, the needed
characteristic of these application protocols is the asynchronous
paradigm, given long delays and intermittent communications. One
outcome of this assessment could be a best practice document on how
to write applications in such use case.
It should be noted that if the application is using HTTP as a
transport, and that guidance on using HTTP as described in Section 5
is followed, then the HTTP application should work.
9. Network services
9.1. Domain Name System(DNS)
Domain name requests and response over long delays generate timeouts
and when there is no reachability to the DNS server, requests will
not be answered. Therefore, on celestial bodies IP networks, a local
DNS infrastructure with all the names and values stored locally is
needed. Moreover, to keep the same DNS root and the current DNSSEC
trust chain, all keys necessary for validation should also be stored
locally. The DNSSEC RR TTL values would need to be longer than the
mission lifetime. [dns-isolated-networks] describes the various ways
to achieve naming in isolated networks use case, which applies to
deep space.
Blanchet, et al. Expires 5 September 2024 [Page 10]
Internet-Draft IP in Deep Space March 2024
9.2. Network Management
NETCONF[RFC6241] and RESTCONF[RFC8040] can be used with proper
configuration values in implementations to avoid timeouts. RESTCONF
with appropriate HTTP config would enable long delayed queries to be
working. NETCONF uses TCP which won't work on delayed and
intermittent communications. If NETCONF is defined over QUIC, then
it could be used with proper QUIC profile as discussed in Section 4.
On the other hand, RESTCONF with proper HTTP profile would just work
fine.
RESTCONF uses various timestamps and HTTP time related headers to
compare transactions time, so for example to avoid any race in
configuration changes. However, there is no notion of timeout in the
protocol itself, so it should work as is. Implementations, at the
RESTCONF level or underneath (HTTP) may have implementation-specific
timeouts that should be configured properly to handle long delays.
A network manager should obviously be aware that a RESTCONF
notification sent by a server that travels over some delayed links or
networks will arrive later than typical, and such notification may be
less useful at the time it arrives. However, this is the reality of
a delayed and intermittent communications network.
SSH in its normal interactive mode sends each character in a separate
packet, which over long delay networks, will not be optimal. SSH can
be configured in line mode where packets are sent only when a full
line is entered. That mode shall be preferred. However, SSH like
NETCONF runs over TCP which will not work. However, SSH over QUIC
was proposed[I-D.bider-ssh-quic] which proper QUIC configuration
might work.
As a summary, it seems possible that all IP nodes (and even dual-
stack (BP and IP) nodes) in space can be remotely managed using
RESTCONF, as well as locally managed.
9.3. Network Operations and Security
On Earth, as it is planned today, the space network shall be isolated
from the current Internet by "air gap", to disable any direct
communications from Internet to deep space. Moreover, destination IP
prefixes filtering shall be used to restrict the traffic to only the
relevant one for each link. Note that this shall also be implemented
in the routing control plane, but additional security might be
appropriate to further protect the deep space links.
Blanchet, et al. Expires 5 September 2024 [Page 11]
Internet-Draft IP in Deep Space March 2024
Each celestial network edge device shall have firewall rules to
disable non-useful trafic to go through deep space links. If
communications from Mars may only occur to Earth, but not Moon, then
appropriate filtering based on destination IPv6 prefixes shall be
used.
Given the air gap on Earth for Internet, there shall be no default
route advertised in space that could for example point to Earth
Internet.
Caching should be used aggressively in all levels of the IP stack in
this architecture. For example, DNS servers on remote celestial
bodies should have all useful names already configured. HTTP Caches
should be deployed and preemptively filled with all necessary
objects.
IPsec may be used to provide secure tunnelling or VPN set of
services. However, QUIC-TLS may be instead investigated to provide
the needed security, given that at the transport level, the security
parameters may be dictated by the applications, therefore ensuring
security policies from end to end applications, instead of at the
network level.
There will likely be multiple "operators" on celestial IP networks.
Therefore it is likely needed to provide some kind of exchange point
similar to the Internet Exchange Point(IXP) as we know today on
Internet. This would enable local exchange of trafic on the
celestial body without going through deep space links. BGP should
then be considered.
9.4. Key Management and Distribution
Protocols or infrastructure using crypto keys and certificates should
be carefully managed. Certificates and session keys should have a
lifetime large enough so that they will still be valid even when
longer than expected disruptions happen. For missions, certificate
lifetimes should be considered based on a mission extended lifetime.
The whole trust chain for certificate validation, including updates,
should also be transferred in advance to the appropriate location on
the celestial body network to avoid invalid verifications because of
the lack of an intermediate certificate, as one do not want to query
any parent certificate over space links. Similarly, Certificate
Revocation Lists(CRL) real-time fetching [RFC5280] or Online
Certificate Status Protocol[RFC2560] should be investigated before
considering their use in this environment.
Blanchet, et al. Expires 5 September 2024 [Page 12]
Internet-Draft IP in Deep Space March 2024
9.5. Time
Since this framework reuses the IP protocol stack, it inherently
assumes time coherence between the celestial bodies networks and no
changes in how protocols are specifying time. Therefore, as with
Bundle Protocol suite, it practically assumes UTC-based time being
available on all celestial bodies, so that time related comparisons
can be achieved. The way to accomplish this on the celestial bodies
networks and in space is out of scope for this document.
10. Summary
With proper profiling of protocols, software and operations, and with
possibly little to no changes in protocols, the use of the IP
protocol stack in deep space with long delays and intermittent
communications seems possible and provides an alternative to a Bundle
protocol based network. This is now possible to envision because of
the various advances in the IP stack, specially the QUIC transport,
compared to the initial assessment done 25 years ago.
11. IANA Considerations
This memo includes no request to IANA.
12. Security Considerations
TBD
13. References
13.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>.
[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>.
13.2. Informative References
[RFC1072] Jacobson, V. and R. Braden, "TCP extensions for long-delay
paths", RFC 1072, DOI 10.17487/RFC1072, October 1988,
<https://www.rfc-editor.org/info/rfc1072>.
Blanchet, et al. Expires 5 September 2024 [Page 13]
Internet-Draft IP in Deep Space March 2024
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560,
DOI 10.17487/RFC2560, June 1999,
<https://www.rfc-editor.org/info/rfc2560>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003,
<https://www.rfc-editor.org/info/rfc3633>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
Blanchet, et al. Expires 5 September 2024 [Page 14]
Internet-Draft IP in Deep Space March 2024
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram
Convergence Layers for the Delay- and Disruption-Tolerant
Networking (DTN) Bundle Protocol and Licklider
Transmission Protocol (LTP)", RFC 7122,
DOI 10.17487/RFC7122, March 2014,
<https://www.rfc-editor.org/info/rfc7122>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
Blanchet, et al. Expires 5 September 2024 [Page 15]
Internet-Draft IP in Deep Space March 2024
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/info/rfc9171>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/info/rfc9172>.
[RFC9174] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-
Tolerant Networking TCP Convergence-Layer Protocol Version
4", RFC 9174, DOI 10.17487/RFC9174, January 2022,
<https://www.rfc-editor.org/info/rfc9174>.
[RFC9204] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Field Compression for HTTP/3", RFC 9204,
DOI 10.17487/RFC9204, June 2022,
<https://www.rfc-editor.org/info/rfc9204>.
[I-D.united-tvr-schedule-yang]
Qu, Y., Lindem, A., Kinzie, E., Fedyk, D., and M.
Blanchet, "YANG Data Model for Scheduled Attributes", Work
in Progress, Internet-Draft, draft-united-tvr-schedule-
yang-01, 3 March 2024,
<https://datatracker.ietf.org/doc/html/draft-united-tvr-
schedule-yang-01>.
[I-D.ietf-tsvwg-careful-resume]
Kuhn, N., Emile, S., Fairhurst, G., Secchi, R., and C.
Huitema, "Convergence of Congestion Control from Retained
State", Work in Progress, Internet-Draft, draft-ietf-
tsvwg-careful-resume-07, 16 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
careful-resume-07>.
[I-D.gomez-core-coap-space]
Gomez, C. and S. Aguilar, "CoAP in Space", Work in
Progress, Internet-Draft, draft-gomez-core-coap-space-00,
19 December 2023, <https://datatracker.ietf.org/doc/html/
draft-gomez-core-coap-space-00>.
[I-D.blanchet-tvr-contactplan]
Blanchet, M., Torgerson, J. L., and Y. Qu, "Contact Plan
Yang Model for Time-Variant Routing of the Bundle
Blanchet, et al. Expires 5 September 2024 [Page 16]
Internet-Draft IP in Deep Space March 2024
Protocol", Work in Progress, Internet-Draft, draft-
blanchet-tvr-contactplan-01, 7 July 2023,
<https://datatracker.ietf.org/doc/html/draft-blanchet-tvr-
contactplan-01>.
[I-D.blanchet-tvr-forwarding]
Blanchet, M., "Forwarding in the context of Time-Variant
Routing(TVR)", Work in Progress, Internet-Draft, draft-
blanchet-tvr-forwarding-00, 13 March 2023,
<https://datatracker.ietf.org/doc/html/draft-blanchet-tvr-
forwarding-00>.
[I-D.bider-ssh-quic]
bider, D., "QUIC-based UDP Transport for Secure Shell
(SSH)", Work in Progress, Internet-Draft, draft-bider-ssh-
quic-09, 2 December 2020,
<https://datatracker.ietf.org/doc/html/draft-bider-ssh-
quic-09>.
[dns-isolated-networks]
Blanchet, M., "Domain Name System in Mostly Isolated
Networks", Work in Progress, Internet-Draft, draft-
blanchet-dns-isolated-networks-00, September 2023,
<https://datatracker.ietf.org/doc/html/draft-blanchet-dns-
isolated-networks-00>.
[IPoverCCSDSSpaceLinks]
Consultative Committee on Space Data Systems(CCSDS), "IP
OVER CCSDS SPACE LINKS, Blue Book 702", September 2012,
<https://public.ccsds.org/Pubs/702x1b1c1.pdf>.
[SANAIPEHeaderRegistry]
Space Assigned Numbers Authority, "Internet Protocol
Extension Header",
<https://sanaregistry.org/r/ipe_header/>.
[wasm] World Wide Web Consortium(W3C), "WebAssembly
Specifications", <https://github.com/webassembly/spec>.
[ioag] Lunar Communications Architecture Working Group,
Interagency Operations Advisory Group, "The Future Lunar
Communications Architecture, Report of the Interagency
Operations Advisory Group", January 2022,
<https://www.ioag.org/Public%20Documents/Lunar%20communica
tions%20architecture%20study%20report%20FINAL%20v1.3.pdf>.
Blanchet, et al. Expires 5 September 2024 [Page 17]
Internet-Draft IP in Deep Space March 2024
[ioag-mars]
Mars and Beyond Communications Architecture Working Group,
Interagency Operations Advisory Group, "The Future Mars
Communications Architecture, Report of the Interagency
Operations Advisory Group", February 2022,
<https://www.ioag.org/Public%20Documents/
MBC%20architecture%20report%20final%20version%20PDF.pdf>.
[picoquic-poc]
Huitema, C., "QUIC to Mars", February 2023,
<https://www.privateoctopus.com/2023/02/07/quic-to-
mars.html>.
[picoquic] Huitema, C., "picoquic",
<https://github.com/private-octopus/picoquic>.
[draft-huitema-quic-in-space]
Huitema, C. and M. Blanchet, "QUIC in Space",
<https://github.com/huitema/quic-in-space>.
[TVRWG] IETF, "Time-Variant Routing (tvr)",
<https://datatracker.ietf.org/group/tvr/about/>.
[MOQWG] IETF, "Media Over QUIC (moq)",
<https://datatracker.ietf.org/group/moq/about/>.
[MASQUEWG] IETF, "Multiplexed Application Substrate over QUIC
Encryption (masque)",
<https://datatracker.ietf.org/group/masque/about/>.
[curl] "Curl", <https://curl.se>.
[CCSDSWEB] CCSDS, "Consultative Committee for Space Data Systems",
<https://ccsds.org>.
[buffer-bloat]
Gettys, J., "The Blind Men and the Elephant",
<https://gettys.wordpress.com/2018/02/11/the-blind-men-
and-the-elephant/>.
Appendix A. Additional Considerations
This section lists additional considerations that are important for
the deployment of IP in deep space, but may not require changes to
protocols or implementations, as they are more related to network
operations.
Blanchet, et al. Expires 5 September 2024 [Page 18]
Internet-Draft IP in Deep Space March 2024
A.1. IP Version
As discussed in the previous section, space missions are long-lived
and require full reachability to every spacecraft. Since IPv4
address space is consumed, the use of IPv4 address space would rely
on using Network Address Translation(NAT) in space. The significant
consequence is the one-way reachability that NAT creates: as soon as
there is a NAT in the path from the source to the destination, the
destination is not be directly reachable. For example, if a NAT is
deployed in space, the spacecrafts behind the NAT will not be
directly reachable from Earth missions operations and network
management consoles. If the NAT is on the other side of the
connections, then spacecrafts will not be able to communicate or send
notifications to mission operations or network management consoles.
This is a significant issue if using IPV4 in deep space.
The Internet has been transitioning from IPv4 to IPv6 to continue its
expansion and since the missions are long-lived, IPv6 is the only IP
version that has the appropriate lifetime for the deep space network.
IPv6 also brings specific features such as IPv6 DHCP prefix
delegation[RFC3633] that could be used for spacecrafts as mobile
networks docking into a temporary or more permanent network and
getting a prefix from the attaching network.
Finally, running both IPv4 and IPv6 simultaneously, while doable as
we do on Internet today, brings additional operational challenges
both in security, such as handling multiple versions of access
control lists, and network management that one should avoid as much
as possible in space.
Therefore, IPv6 is recommended to be the only IP protocol version
used in space. Moreover, if there is any required protocol change,
IPv6 should be the base IP protocol used underneath.
Most protocols and topics discussed in this document are independent
of the IP version, but if there are differences, only the IPv6
version is discussed.
A.2. IPv6 Addressing
Space communications infrastructure must avoid at all costs any
address space collision, since it would prevent any reachability
between the colliding networks. For example, if one organization
creates a network on a celestial body using an address space and
another organization, or even worse the same organization, creates
another network anywhere in space using the same address space, those
two networks will not be able to reach each other, undermining any
Blanchet, et al. Expires 5 September 2024 [Page 19]
Internet-Draft IP in Deep Space March 2024
communications. NATs can be used between the two but this will just
further complexify or disable remote network management.
IPv6 addressing in space should only use non-overlapping address
space, based on duly allocated IPv6 space assigned to each
organization, from the public IPv6 address space[RFC4291] managed by
registries, providing IPv6 network services in space. IPv6 unique-
local addressing [RFC4193] can be used within a single domain but
such traffic should not cross domains using the unique-local
addressing, and should instead used the global addressing as managed
by the IPv6 preferred address algorithm [RFC6724].
Current Regional Internet Registries(RIR) may not have in place the
appropriate policies for the deep space use case, since these
policies are aimed towards terrestrial Internet usage, such as
broadband usage, ISP peering and other considerations. These
policies may need to be revised to include deep space usage or
another organization with proper membership to be put in place to
allocate and assign IPv6 address space, and possibly Autonomous
System Numbers, for that specific community and usage.
A.3. IPv6 over Space Links
The Consultative Committee for Space Data Systems (CCSDS, [CCSDSWEB]
is a standard organization for space communications, which membership
is space agencies and related commercial organizations. IP packet
encapsulation into space links is defined in CCSDS 702
[IPoverCCSDSSpaceLinks] and the codepoint for IPv6 packet
encapsulation is 87 for space links, as specified in the Space
Assigned Numbers Registry(SANA) [SANAIPEHeaderRegistry]. However, it
is unknown if IPv6 has been implemented and tested, given long delays
and Neighbor Discovery [RFC4861] timers. An IPv6 over CCSDS Space
Links specification may need to be defined.
A.4. Bundle Protocol and IP
As discussed in Section 1, the Bundle Protocol [RFC9171] has been
designed to create a store-and-forward networking capability for
space and other use cases. This document framework specifies an
alternate way to accomplish the networking for the same use case by
reusing as much as possible the IP protocol stack, therefore
inheriting all the engineering and implementations implemented and
running daily on Internet. This re-use also means that
implementations have been exercised on real traffic orders of
magnitude more than what has been achieved with Bundle protocol
stacks.
Blanchet, et al. Expires 5 September 2024 [Page 20]
Internet-Draft IP in Deep Space March 2024
It is possible to mix BP and IP on the same links or networks.
Therefore, this framework and the BP stack can create independent and
simultaneous networks or can be mixed.
Acknowledgements
This work started by reassessing the use of the whole IP stack in the
context of deep space. Soon, QUIC was identified as the key
technology for this endeavour. Christian Huitema was very helpful in
not only confirming the ability to use QUIC but also took the time
and effort to test and modify its picoquic stack[picoquic] to confirm
the initial hypothesis[picoquic-poc]. Its involvement and
confirmation are the key for the launch of this work. Then, Martin
Thompson has been also kind to take time to answer initial questions
on QUIC, further confirming the possibility of using QUIC for deep
space. Since then, many individuals have provided significant
comments and perspectives on this subject.
This document and its underlying work has been reviewed and discussed
by many, who have provided valuable feedback and comments, including
disagreements, and made an overall more solid document. These people
are, in no specific order: Geoff Huston, Martin Thompson, Peter
Ashwood-Smith, Tony Li, George Neville-Neil, Jim Gettys, Nicolas
Kuhn, Eric Vyncke, Russ Housley, Emile Stephan, Dave Taht, Jean-
Philippe Dionne.
Authors' Addresses
Marc Blanchet
Viagenie
Canada
Email: marc.blanchet@viagenie.ca
Christian Huitema
Private Octopus Inc.
Email: huitema@huitema.net
Dean Bogdanovic
AlefEdge, Inc
Email: ivandean@gmail.com
Blanchet, et al. Expires 5 September 2024 [Page 21]