The discussion below provides some historical context, an overview and a description of the network protocol stack of the Solar System Internetwork (SSI).

History

In 1999, the Interagency Operations Advisory Group (IOAG) was established to achieve cross support across the international space community and to expand the enabling levels of space communications and navigation interoperability [CCS14, Foreword].

In 2007, the IOAG chartered a Space Internetworking Strategy Group (SISG) to reach international consensus on a recommended approach for transitioning the participating agencies towards a future network-centric era of space mission operations [CCS14, Foreword].

In 2008, the SISG released a preliminary report on their operations concept for a Solar System Internetwork (SSI) [CCS14, Foreword]; see the 2011 conference version of the report [EDB11].

In 2010, the IOAG finalised the SSI Operations Concept and asked the Consultative Committee for Space Data Systems (CCSDS) to create the SSI architectural definition [CCS14, Foreword].

In 2014, the CCSDS Space Internetworking Services - Delay-Tolerant Networking (SIS-DTN) working group released the official informational report [CCS14].

The SSI architecture is based on international standards and voluntary agreements [CCS14, Executive Summary].

Participation in the SSI is expected to be incremental, and furthermore, the SSI specification and technologies are still evolving.

In fact, the Interplanetary Networking Special Interest Group (IPNSIG), a chapter of the Internet Society, has the vision to develop a secure and robust Solar System Internet, by extending networking to space, from the historical point-to-point, “bent pipe” communication architecture to a store-and-forward, packet-switched design, interconnecting any number of terrestrial and space-borne nodes [KCB+21].

Overview

The fundamental objective of the SSI is to provide automated and internetworked data communication services for space ventures (at least across the solar system) [CCS14, Executive Summary; EDB11, Sec. 2].

The emphasis on automation arises from the need to support communication among the various participants operating in space ventures without requiring a detailed understanding of space communication operations [CCS14, Executive Summary].

Examples of participants include [CCS14, Sec. 2.1]:

• crewed and robotic space-faring vehicles, often carrying investigative instruments;
• planetary surface systems, with crew and/or instruments;
• ground antenna stations;
• centralised ground-based mission operations centres (MOCs) on Earth;
• science investigators at widely distributed laboratories on Earth.

The SSI interconnects multiple networks built on two types of networking architectures, namely 1️⃣ the Internet architecture and 2️⃣ the DTN architecture.

Fig. 1 depicts a communication scenario that the SSI architecture is designed to support.

In Fig. 1,

• Multiple missions may be involved, and each mission may operate multiple spacecrafts, which may autonomously collaborate on mission objectives.
• The set of spacecrafts conducting a long-lived mission may change over time, as disabled spacecrafts become decommissioned and new spacecrafts get deployed.
• Data may be routinely relayed among spacecrafts, even among spacecrafts deployed for different missions, by different space agencies. Furthermore, data may be relayed through different spacecrafts at different times, introducing the possibility of multiple data paths between spacecrafts and MOCs.

To accommodate the multi-agency, multi-mission scenario in Fig. 1, the SSI architecture specifies three stages of functionality:

• Stage 1 Mission Functionality
• Stage 2 Internetwork Functionality
• Stage 3 Advanced Functionality

Protocol stack

The SSI protocol stack is a combination of the Internet Protocol (IP) stack and the Delay-Tolerant Network (DTN) protocol stack, as shown in Fig. 2.

Going top-down along the DTN “facet” (CCSDS term) [CCS14, Sec. C3],

• DTN applications are applications designed to operate with communications characterised by variable, substantial latencies due to 1️⃣ large signal propagation delays, 2️⃣ lengthy physical communication outages, or 3️⃣ both.

  These applications are implemented to utilise the CCSDS File Delivery Protocol (CFDP) and optionally other DTN application-layer services over a Bundle Protocol (BP) network.

• The BP network runs over the Licklider Transmission Protocol (LTP).

  While protocols from the IP suite are limited to scenarios in which network paths are continuously connected and have low latencies, BP network can operate in any scenario in the SSI, including on top of TCP/IP, as Fig. 3 shows.

• Fig. 3 also shows below the LTP layer, sit the Encapsulation Packet Protocol and Space Packet Protocol.

  The Space Data Link Protocols (SDLPs) sit further down the protocol stack.

• Among the SDLPs, the Proximity-1 Space Link Protocol is defined for short-range, bi-directional, fixed or mobile radio links, generally used to communicate among probes, landers, rovers, orbiting constellations, and orbiting relays.

  The 1️⃣ Telecommand (TC) SDLP, 2️⃣ Telemetry (TM) SDLP, and 3️⃣ Advanced Orbital Systems (AOS) SDLP [CCS15d] serve other scenarios.

  Fig. 4 demonstrates the usage of AOS-SDLP in a space network and Proximity-1 in a Mars network.

  Fig. 5 demonstrates the usage of Proximity-1 between two space nodes; and the usage of AOS-SDLP and TC-SDLP between a space node and a ground terminal.

  Improving upon the preceding protocols, the Unified Space Data Link Protocol (USLP, not typo) has been designed to meet the requirements of space missions for efficient transfer of space application data of various types and characteristics over space-to-ground, ground-to-space, and space-to-space communications links [CCS21c].

  Fig. 6 maps the protocols discussed so far to the Open System Interconnection (OSI) model.

• Finally in the physical layer, RF communication and optical communication options exist (🖱 click links for details).
  

This continues from Solar System Internetwork (SSI).

The Stage 1 Mission Functionality of the Solar System Internetwork (SSI) is the automation of basic communication processes between vehicles and Mission Operations Centers (MOCs) that might be performed for a single space flight mission, including [CCS14, Sec. 3]:

• the initiation and termination of transmissions;
• the scheduling of data for transmission according to priority designations declared by SSI users;
• the segmentation and reassembly of large data items for transmission in small increments;
• the retransmission of data that were lost or corrupted in transmission;
• the relaying of data from one entity to another via some other entity pre-selected by management.

Fig. 1 depicts a sample communication scenario between two SSI nodes: one onboard the spacecraft and another at the spacecraft MOC.

• The SSI data flow between these two nodes is established by requesting a space link session from the Earth station control center.
• Data are exchanged via the Earth station by link-layer mechanisms, which are nominally based on the CCSDS Space Link Extension (SLE) service [CCS13].

The network configuration in Fig. 1 can be extended by setting up a separate SSI node for use by the instrument MOC, enabling the instrument MOC to operate on native instrument data flows securely routed through the node at the spacecraft MOC.

Prerequisites and protocols

To be part of the SSI, each node must be configured to run the Bundle Protocol (BP), i.e., a Bundle Protocol Agent (BPA) must be deployed at each node.

For each node on the Earth surface, a Convergence-Layer Adapter (CLA) must be deployed underneath BP, enabling the node to communicate with other Earth-bound nodes via the Internet.

For interoperation with the Internet, the CLA can use the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), or potentially the Licklider Transmission Protocol (LTP) running on top of UDP/Internet Protocol (IP).

The Aerospace Corporation created the Space Attack Research and Tactic Analysis (SPARTA) cybersecurity matrix

• to address the information and communication barriers that hinder the identification and sharing of space-cyber Tactic, Techniques, and Procedures (TTP);
• to provide unclassified information to space professionals about cyber threats to spacecraft.

The SPARTA matrix is a specialisation of the MITRE ATT&CK matrix for defining and categorising commonly identified activities that contribute to spacecraft compromises.

The nine SPARTA tactics shown in the top row of Fig. 1 are a subset of the tactics in MITRE ATT&CK.

Under each SPARTA tactic in Fig. 1, each of the main techniques accompanied by a double vertical sign, namely ⏸, can be divided into sub-techniques. For example, under tactic “Reconnaissance” (ST0001), the technique “Gather Spacecraft Design Information” (REC-0001) can be divided into 1️⃣ Software (REC-0001.01), 2️⃣ Firmware (REC-0001.02), 3️⃣ Cryptographic Algorithms (REC-0001.03), 4️⃣ Data Bus (REC-0001.04), 5️⃣ Thermal Control System (REC-0001.05), 6️⃣ Manoeuvre and Control (REC-0001.06), 7️⃣ Payload (REC-0001.07), 8️⃣ Power (REC-0001.08), and 9️⃣ Fault Management (REC-0001.09).

Example 1: Payload

The South Australian 6U CubeSat Kanyini has two payloads: 1️⃣ a hyperspectral imager called HyperScout 2 for earth observation, and 2️⃣ an Internet-of-Things communications module.

Example 2: Applying SPARTA to modelling a recent cyber attack

Watch a quick overview of the attack called PCspooF:

A mixed-criticality system (MCS) is an embedded computing platform in which application functions of different criticalities share computation and/or communication resources [EDN16].

A mixed time-criticality system is an MCS where the criticality is messaging timeliness.

Time-Triggered Ethernet (TTEthernet), as standardised in SAE AS6802, defines algorithms for clock synchronisation, clique detection, startup, and restart for switches and end systems to achieve fault-tolerant synchronisation in an Ethernet-based (IEEE 802.3) mixed time-criticality system.

TTEthernet is used in avionics, industrial control systems (including those for power systems) and automotive systems [LPDK23], so any security vulnerability in TTEthernet would have wide-reaching consequences.

• In avionics, TTEthernet is used as a bus service for a variety of spacecraft including NASA’s Orion capsule, NASA’s Lunar Gateway space station, and ESA’s Ariane 6 launcher [The22].

How TTEthernet works [LPDK23]

A TTEthernet network contains two types of devices: switches and end systems.

Fault-tolerance is enabled by network redundancy, and each redundant network is called a plane; Fig. 2 shows an example of a system using two planes.

Time-triggered (TT) design = All TTEthernet devices are tightly synchronised and the behaviour of the network is determined by a global schedule made offline and loaded onto each TTEthernet device before deployment.

The global schedule specifies when TT frames are forwarded and expected to arrive.

The latency and jitter of TT traffic can be reduced to below 13 μs and 1 μs respectively [Fid15, slide 12].

TTEthernet also carries best-effort (BE, i.e., regular) Ethernet traffic and rate-constrained Avionics Full Duplex Switched Ethernet (AFDX, as standardised in ARINC Specification 664 P7-1) traffic; see Fig. 3.

TTEthernet switches forward BE traffic around the pre-scheduled TT traffic when bandwidth permits.

Mechanisms exist to isolate TT traffic from BE traffic, e.g.,

• there are windows reserved for TT traffic only;
• TT and BE frames are stored in different switch buffers.

Central to TTEthernet is a synchronisation protocol, in which a device can participate as 1️⃣ a sync master, 2️⃣ a compression master, or 3️⃣ a sync client.

• Typically, a subset of the end systems serve as sync masters, while 1-2 switches per plane serve as compression masters.
• The remaining devices serve as sync clients.

Devices exchange protocol control frames (PCFs) every integration cycle.

• At the beginning of each integration cycle, every sync master sends a PCF containing its local clock value to the compression masters.
• The compression masters average the received clock values, then send out the average in a new PCF to the sync masters and clients, which then correct their local clocks.

Receiving certain PCFs from a compression master can cause sync masters and clients to lose synchronisation.

• An example of such PCFs is “coldstart acknowledgement”, which tells a sync master another sync master detected loss of synchronisation and is reestablishing it.
• Since a PCF can cause de-synchronisation, TTEthernet requires each compression master to be a self-checking pair, which only produces a PCF if two independent processors agree on the contents.

Attacker/threat model for PCspooF

The PCspooF attack is feasible provided:

• Attacker has access to at least one BE device, e.g.,
  • by supplying such a device (as a malicious supplier) for integration into the TTEthernet network before the network is deployed;
  • by connecting the device to the TTEthernet network after the network has been deployed.
• Attacker can control the BE device operating in one plane; see Fig. 4.
• Attacker-controlled BE device includes additional circuit components for conducting electromagnetic interference (EMI) through its Ethernet cable into a switch; see Fig. 5.

The PCspooF attack

PCspooF is a cyber-physical attack that attempts to disrupt the TTEthernet synchronisation protocol by spoofing PCFs, and thereby inflict denial of service on its victim.

The attack happens in two stages:

• Stage 1️⃣: This is the cyber stage, where the attacker fabricates a valid PCF.

  A PCF has the same structure as a standard minimum-sized Ethernet frame, but instead of a destination MAC address, it has a 4-byte Critical Traffic Marker (a special value used to identify all PCFs and TT traffic) and a 2-byte Virtual Link ID (also called Critical Traffic ID [Lov15], which identifies the source of a PCF); see Fig. 6.

  These two fields 👆 must match the values specified in the network schedule loaded onto the TTEthernet devices. These two fields happen to be the only fields that pose a challenge to spoof.

  Skipping the details [LPDK23, Sec. IIIA], an attacker can determine valid Critical Traffic Markers by abusing the Address Resolution Protocol and trying a maximum of around one billion possible values.

  Skipping the details again [LPDK23, Sec. IIIA], an attacker can try to use 4071 or 4070 as the Virtual Link ID, or in the worst case, try a maximum of 65536 values.

  The fabricated PCF is stored inside the payload of a benign BE frame, because TTEthernet switches drop PCFs from BE devices.

  The next stage is to trick a switch into forwarding the aforementioned BE frame as a PCF.

• Stage 2️⃣: This is the physical stage, where the attacker uses EMI to convert a BE frame into a PCF during transmission.

  This is an example of a link reset attack, which in turn is an example of a packet-in-packet attack [GBM+11].

  Scenario: a BE device is transmitting to a switch, but the PHY preamble becomes corrupted, and consequently the PHY layer of the switch resets itself.

  Attacker uses the opportunity to send packet below:

  In Fig. 7, the PHY layer and outgoing port of the switch recover during the transmission of the fake preamble.

  Result: Inner frame, which contains the fake PCF, gets sent.

  Corruption of PHY preamble can be achieved through EMI; see Figs. 8-9.

Applying SPARTA

Using the language of SPARTA, these attack stages can be identified [The22]: 1️⃣ Reconnaissance, 2️⃣ Resource Development, 3️⃣ Initial Access, 4️⃣ Execution, 5️⃣ Lateral Movement, 6️⃣ Impact

Table 1 and Table 2 map these attack stages to the attack steps in PCspooF.

Table 1: The first three stages of PCspooF.

Reconnaissance (ST0001)	Resource Development (ST0002)	Initial Access (ST0003)
Gather Spacecraft Design Information (REC-0001), and specifically, Data Bus (REC-0001.04): 😈 Attacker gathers information required for successful spoofing of TTEthernet frame fields (e.g., Critical Traffic Marker, Virtual Link ID) and design of EMI-injecting PCB. Gather Supply Chain Information (REC-0008), and specifically, Hardware (REC-0008.01): 😈 Attacker gathers information on the hardware in use, e.g., TTEthernet utilisation, EMI target. Eavesdropping (REC-0005): 😈 Attacker eavesdrops on the network to infer valid Critical Traffic Markers and Virtual Link IDs from devices’ responses or lack of response.	Stage Capabilities (RD-0004), and specifically, Identify/Select Delivery Mechanism (RD-0004.01): 😈 Attacker identifies the ideal BE device to use for executing the attack.	Compromise Supply Chain (IA-0001), and specifically, Hardware Supply Chain (IA-0001.03): 😈 Attacker sneaks the attacking BE device into the supply chain before or after the deployment of the targeted TTEthernet network. Auxiliary Device Compromise (IA-0011): 😈 Attacker investigates potential use of a USB/generic hardware vector instead of a BE device.

Table 2: The last three stages of PCspooF.

Execution (ST0004)	Lateral Movement (ST0007)	Impact (ST0009)
Time Synchronised Execution (EX-0008): 😈 Attacker implements a “ticking timebomb” trigger, which activates attack after a preset amount of post-deployment time. Flooding (EX-0013), and specifically, Erroneous Input (EX-0013.02): 😈 Attacker brute-forces ARP requests and emissions of EMI. Exploit Hardware/Firmware Corruption (EX-0005), and specifically, Design Flaws (EX-0005.01): 😈 Attacker exploits weaknesses permitting aggressive ARP polling of BE devices, gathering of information (e.g., Critical Traffic Markers, Virtual Link IDs), and link reset attacks for spoofing PCFs (see Fig. 7). Spoofing (EX-0014), and specifically, Bus Traffic (EX-0014.02): 😈 Attacker injects spoofed PCFs via EMI-based link reset attacks.	Exploit Lack of Bus Segregation (LM-0002): 😈 Attacker is enabled by the situation where critical (TT) and non-critical (BE) components share the same physical networking infrastructure to use a non-critical component (BE device) to disrupt the operations of critical components (TT devices).	Disruption (IMP-0002): 😈 TTEthernet synchronisation broken, critical operations not being performed, leading to disruption of critical spacecraft operations (e.g., manoeuvring, sensing, communications) and overall mission.

Introduction

In many space applications, it is desirable to have a single, common application-layer data structure for the creation, storage, and transport of variable-length application-layer data.

These data is expected to be 1️⃣ exchanged and stored on board, 2️⃣ transferred over one or more space data links, and 3️⃣ used within ground systems.

It is often necessary to identify the 1️⃣ type, 2️⃣ source, and/or 3️⃣ destination of these data.

The preceding needs motivate the definition of the Space Packet Protocol (SPP).

The SPP is designed as a self-delimited carrier of a data unit — called a Space Packet — that contains an application process identifier (APID) used to identify the data contents, data source, and/or data user within a given enterprise [CCS20d, Sec. 2.1.1].

Fig. 1 shows where the SPP sits in the CCSDS protocol stack.

Fig. 2 shows a communication scenario between a spacecraft and a ground terminal, where the SPP plays an important role.

APID

APIDs are unique in a single naming domain [CCS20d, Sec. 2.1.3]

An APID naming domain usually corresponds to a spacecraft, or an element of a constellation of space vehicles.

Every space project allocates the APIDs to be used in a naming domain.

More precisely, the space project assigns APIDs to managed data paths within a naming domain.

Open-source implementations

The following open-source implementations are known at the time of writing:

• A C-based implementation is available from NASA.
• A Python-based implementation is available from the LibreCube project.

The Spectre attacks exploit the weakness CWE-1037 “Processor Optimization Removal or Modification of Security-critical Code”.

Modern processors use branch prediction and speculative execution to maximise performance, but the implementations of these optimisations in many processors were found to have broken a range of software security mechanisms, including operating system process separation, containerisation, just-in-time (JIT) compilation, and countermeasures to cache timing and side-channel attacks [KHF+20].

Watch the presentation given by one of the discoverers of Spectre attacks at the 40th IEEE Symposim on Security and Privacy:

More information on the Meltdown and Spectre website.

NIST provides guidelines on engineering trustworthy (see Definition 1) and cyber-resilient (see Definition 2) systems through NIST SP 800-160 volumes 1 and 2 [RWM22, RPG+21], to be used in conjunction with

• ISO/IEC/IEEEE International Standard 15288:2015 [ISO15],
• NIST SP 800-37 [Joi18] and
• NIST SP 800-53 [Joi20].

A primary objective of NIST SP 800-160 volume 1 is to provide a basis for establishing a discipline for systems security engineering as part of systems engineering in terms of its principles, concepts, activities and tasks.

• Systems engineering is a transdisciplinary and integrative approach to enabling the successful realisation, use, and retirement of engineered systems [RWM22, Sec. 2.2].
• Systems security engineering is meant to provide complementary engineering capabilities that extend the concept of trustworthiness to deliver trustworthy systems [RWM22, p. 2].
• Without going into details, Fig. 1 captures the workflow in the prescribed Systems Security Engineering Framework [RWM22, Sec. 4].

A primary objective of NIST SP 800-160 volume 2 is to provide guidance on how to apply cyber resilience concepts, constructs and engineering practices to systems security engineering and risk management for systems (e.g., enterprise IT, industrial control systems, Internet of Things) and organisations.