report - european space agency

Telecommand and Telemetry System Security Design Study

ESA contract 19300/05/NL/JA

Reference System Architecture

Doc.-No.: TMTC-SEC-OHB-RP-001

ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 1 of 58

TMTC-SEC-OHB-RP-001-03_Reference_System_Architecture_20060508.doc

Report

Title: Reference System Architecture

Document No.: TMTC-SEC-OHB-RP-001

Issue: 3.0 Date: 2006-05-08

ESA Doc. No.: D1.1

Prepared by: Dr. C. Gorecki Date: 2006-05-08

Checked by: Dr. R. Rathje, A. Weigl Date: 2006-05-08

Product Assurance: J. Mathes Date: 2006-05-08

Project Management: Dr. R. Rathje Date: 2006-05-08

Distribution: ESA

Schutzvermerk DIN 34

Copying of this document, and giving it to others and the use or communication of the contents, thereof, are forbidden without express authority. Offenders are liable to the payment of damages. All rights are reserved in the event of the grant of a patent or the registration of utility model or design.

OHB-System AG

D-28359 Bremen

Universitätsallee 27-29

Tel: 0421-2020-8

Weitergabe sowie Vervielfältigung dieser Unterlage, Verwertung und Mitteilung ihres Inhalts ist nicht gestattet, soweit nicht ausdrücklich zugestanden. Zuwiderhandlungen verpflichten zu Schadenersatz. Alle Rechte für den Fall der Patenterteilung oder Gebrauchsmuster-Eintragung vorbehalten.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 2 of 58


DOCUMENT CHANGE RECORD

Issue Date Page and/or Paragraph affected

Draft 2006-01-23 Initial issue

1.0 2006-02-24 Inclusion of RIDs and completion from Phase 1 Review Meeting presentations and discussions.

2.0 2006-03-29 Inclusion of RIDs and completion from Issue 1.0 Review

3.0 2006-05-08 Inclusion of Issue 2.0 comments. Changes/ additions are made to the following sections: 4.2 (EGSE) p. 30-31, 4.4 (Reference System Architecture Definition) drawing p. 33, Table 4-1 (Nodes and Elements), Crypto-EGSE module added, p. 35, Table 4-2 (Links), links description between EGSE and control center added, p. 40-41.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 3 of 58


TABLE OF CONTENTS

1 Introduction ..............................................................................................................................5

1.1 Purpose of Document ......................................................................................................5

1.2 Definitions and Abbreviations...........................................................................................6

1.3 Documents.......................................................................................................................6

1.3.1 Applicable Documents .................................................................................................6

1.3.2 Reference Documents .................................................................................................7

2 Mission Characteristics.............................................................................................................8

2.1 Navigation........................................................................................................................9

2.2 Communication................................................................................................................9

2.3 Earth Observation ..........................................................................................................10

2.4 Science / Technology.....................................................................................................12

2.5 Deep Space ...................................................................................................................14

2.6 Manned Space Flight .....................................................................................................14

2.7 Launcher........................................................................................................................15

3 Applicable Systems ................................................................................................................16

3.1 ESA Data Handling and System Layers.........................................................................17

3.1.1 TC System Layers......................................................................................................17

3.1.1.1 Physical Layer ....................................................................................................18

3.1.1.2 Coding Layer......................................................................................................18

3.1.1.3 Transfer Layer ....................................................................................................19

3.1.1.4 Segmentation Layer ...........................................................................................19

3.1.1.5 Packetization Layer ............................................................................................19

3.1.2 TM System Layers .....................................................................................................20

3.1.2.1 Physical Layer ....................................................................................................20

3.1.2.2 Coding Layer......................................................................................................20

3.1.2.3 Transfer Layer ....................................................................................................20

3.1.2.4 Segmentation Layer ...........................................................................................20

3.1.2.5 Packetization Layer ............................................................................................21

3.2 Space Link Extension (SLE) Services ............................................................................22

3.2.1 SLE Security Aspects.................................................................................................24

3.3 Space Communications Protocol Standards (SCPS) .....................................................27

4 Reference System Architecture..............................................................................................28

4.1 Introduction ....................................................................................................................28

4.2 Electrical Ground Support Equipment (EGSE) ...............................................................30

4.3 Launch and Early Orbit Phase (LEOP)...........................................................................32

4.4 Reference System Architecture Definition......................................................................33

4.5 Network Domain Characterization..................................................................................41





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 4 of 58


4.5.1 Space Network...........................................................................................................41

4.5.1.1 Frame Relay.......................................................................................................41

4.5.1.2 IF Transparent....................................................................................................42

4.5.2 Space Link .................................................................................................................42

4.5.3 Ground Network.........................................................................................................43

4.6 Security Associations.....................................................................................................43

4.6.1 SLE Transfer Service Associations in the Ground Segment.......................................44

4.6.2 Spacecraft Control Service.........................................................................................45

4.6.2.1 Envelope SCS1 ..................................................................................................45

4.6.2.2 Envelope SCS2 ..................................................................................................46

4.6.2.3 Envelope SCS3 ..................................................................................................46

4.6.2.4 Envelope SCS4 ..................................................................................................47

4.6.3 Payload Control and Delivery Service ........................................................................48

4.6.3.1 Envelope PCDS1 ...............................................................................................48

4.6.3.2 Envelope PCDS2 ...............................................................................................48

4.6.3.3 Envelope PCDS3 ...............................................................................................49

4.6.3.4 Envelope PCDS4 ...............................................................................................49

4.6.3.5 Envelope PCDS5 ...............................................................................................50

4.6.4 Envelope PCDS6 .......................................................................................................50

4.6.5 Envelope PCDS7 .......................................................................................................51

4.6.6 Envelope PCDS8 .......................................................................................................51

4.6.7 Envelope PCDS9*......................................................................................................52

4.6.8 Envelope PCDS10*....................................................................................................52

4.7 Link and Module Characteristics ....................................................................................53

A Annex: Delay Tolerant Networks ............................................................................................55





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 5 of 58


1 INTRODUCTION

1.1 Purpose of Document This report has been prepared under European Space Agency (ESA) Contract No. 19300/05/NL/JA – Telecommand and Telemetry System Security Design Study (TMTC-SEC). As directed by the Statement of Work [AD 1] the objective of the first phase is to transform user requirements and constraints into system requirements.

Phase 1 is divided into three main tasks:

• The reference system architecture, suitable / adaptable for the various ESA mission types, identifies the involved system elements and the interfaces to other systems.

• The risk assessment within the second task identifies possible threats and their impact to the system elements as well as the resulting risks.

• The third task transforms the perceptions gained from the first two tasks into the system security requirements, their justification and a set of guidelines, to tailor the security requirements to the different mission classes.

This document describes the reference system architecture. An overview of the logical flow and the coherence of the phase 1 documents is given in Figure 1-1. Parts which are covered within this report are accented by the red circles.

RequirementsJustification File

(D1.3.b)

System SecurityRequirements

(D1.3.a)

Risk AssessmentReport(D1.2)

Tailored RSA withidentified Linksand services

Reference SystemArchitecture

(D1.1)

Identify link

characteristics

Pre-Tailoring(Step 0)

Tailoring of RSAIdentified end-to-end

links and services

TailoringProcess

User / Stakeholder

Requirements

Mission



� Protocols� Algorithms� Standards

TailoredRequirements

Phase1_Overview.vsd

Figure 1-1: Phase 1 Overview





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 6 of 58


1.2 Definitions and Abbreviations

CA Certificate Authority

CCSDS Consultative Committee for Space Data Systems

CoS Class-of-Service

DoS Denial of Service

DTN Delay Tolerant Network

ECSS European Cooperation for Space Standardization

EGSE Electrical Ground Support Equipment

GEO Geostationary Orbit

HDC High level discrete command

HDLC High-Level Data Link Control

ISL Inter Satellite Link

ISO International Standards Organization

KFD Key Fill Device

LEO Low Earth Orbit

MCC Mission Control Center

OCC Operational Control Center

P/L Payload

PCDS Payload Control and Delivery Service

PDGS Payload Data Ground Segment

POS Payload Operations Service

RSA Reference System Architecture

SCPS Space Communications Protocol Standards

SCS Spacecraft Control Service

SLE Space Link Extension

TC Telecommand

TM Telemetry

TTTC Time tagged Telecommand

1.3 Documents

1.3.1 Applicable Documents

The following documents are applicable documents to this report:

Document number Document title Issue

[AD 1] Invitation to Tender AO/1-4734/05/NL/JA

Telecommand and Telemetry System Security Design Study. Statement of Work

02





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 7 of 58


1.3.2 Reference Documents

The following documents are reference documents to this report and contain additional information:

Document number / Author Document title Issue / Date

[RD 1] CCSDS 910.4-B-2 Cross Support Reference Model – Part 1, Space Link Extension Services. Recommendation for Space Data System Standards, Blue Book

Issue 2, October 2005.

[RD 2] ESOC Contract No. 17462/03/D/CS.

Encryption for Space, Present Scenario, Performance and Software Efficient Applications, Final Report

July 2004

[RD 3] CCSDS 910.0-Y-1, Space Link Extension Services – Executive Summary, Yellow Book

Issue 01, April 2002

[RD 4] draft-irtf-dtnrg-arch-03 Delay-Tolerant Network Architecture Draft, July 2005

[RD 5] draft-irtf-dtnrg-sec-overview-00

Delay-Tolerant Networking Security Overview Draft, September 2005

[RD 6] draft-irtf-dtnrg-bundle-security-00

Bundle Security Protocol Specification Draft, July 2005

[RD 7] Warthman, F. Delay-Tolerant Networks (DTNs) – A Tutorial V1.1, May 2003

[RD 8] CCSDS 701.0-B-3 Advanced Orbiting Systems, Networks and Data Links: Architectural Specification, Blue Book

Issue 03, June 2001

[RD 9] CCSDS 710.0-G-0.3 Space Communications protocol Specification (SCPS) – Rationale, Requirements, and Application Notes

Draft Green Book, April 1997

[RD 10] CCSDS 717.0-B-1 Space Communications protocol Specification (SCPS) – File Protocol (SCPS-FP)

Blue Book, May 1999

[RD 11] CCSDS 714.0-B-1 Space Communications protocol Specification (SCPS) – Transport Protocol (SCPS-TP)

Blue Book, May 1999

[RD 12] CCSDS 713.5-B-1 Space Communications protocol Specification (SCPS) – Security Protocol (SCPS-SP)

Blue Book, May 1999

[RD 13] CCSDS 713.0-B-1 Space Communications protocol Specification (SCPS) – Network Protocol (SCPS-NP)

Blue Book, May 1999

[RD 14] ESA PSS-04-107 Packet Telecommand Standard Issue 02, April 1992

[RD 15] ESA PSS-04-106 Packet Telemetry Standard Issue 01, January 1988

[RD 16] CCSDS-231-0-B-1 TC Synchronization and Channel Coding Blue Book. Issue 01, September 2003

[RD 17] CCSDS-100.0-G-1 Telemetry Summary of Concept and Rationale Green Book. Issue 1, December 1987

[RD 18] Bellare, M.; Kiliany, J.; Rogawayz, P.

The Security of the Cipher Block Chaining Message Authentication Code. Journal of Computer and System Sciences, Vol. 61, No. 3, pp. 362 - 399.

December 2000





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 8 of 58


2 MISSION CHARACTERISTICS

Security and reliability is essential for all spacecraft missions, where human lives or the assets of operators and stakeholders may be endangered. Security engineering is about building systems to remain dependable and withstand intentional or unintentional disruptions. The security system design has to meet the critical assurance requirements that are both different from mission to mission but also have generic architectural core commonalities, that are mandatory for all mission types. This means that a reference system architecture has to determine the common nucleus of all mission types, which in a second step may be extended by the mission-specific modules. But before that the different ESA mission types have been analyzed to identify their generic modules (communalities).

In the study the following of mission scenarios, each corresponding to a particular type of satellite or spacecraft system were characterized:

o Navigation e.g. GPS, GALILEO (MEO constellations)

o Communication e.g. ASTRA, Intelsat, Eutelsat (GEO fleets), Orbcom, Globalstar (LEO constellations)

o Earth observation e.g. SAR-Lupe, GMES (LEO)

o Science/Technology e.g. Integral, Planck, Eddington, Robotic Servicing, Technological Demonstrators

o Deep Space e.g. Cassini/Huygens, Mars Express, Rosetta)

o Manned Space flight e.g. Space Station, Moon, Mars

These mission scenarios are further described hereafter.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 9 of 58


2.1 Navigation The purpose of a navigation system is to provide military and civilian users with positioning services. The space network comprises of the satellite constellation (e.g. 30 Galileo satellites), the ground network comprises ground stations around the world that are responsible for monitoring the flight paths of the satellites, synchronizing the satellites' onboard atomic clocks, and uploading data for transmission by the satellites through the space link. Users are connected by using personal receivers with optional external services to provide to enhanced accuracy or to use pre-processed data.

The system’s value is extremely high, due to many civilian and military services relying on navigation data e.g. support of digitization of a battle space, aircraft navigation, time distribution and synchronization, vehicle policing/surveillance systems, fleet management systems and many others. Hence, a disruption of the navigation service would have an immediate and major impact on many civilian and military systems.

Objectives • To provide position data to ground and space based users.

Users • Military

• Life saving services

• Civilian (commercial)

• Civilian (research)

Examples • Galileo

• Global Positioning System (GPS)

Location of the Systems

• Ground: control stations

• Space: satellite

External Network Gateways • Web server for customer data download

Table 2-1 Characteristics of a navigation type mission.

2.2 Communication In general telecommunication satellites can be placed in geo-synchronous, Molniya or low Earth orbits.

In most cases GEO is selected for communications applications because ground based antennae, which must be directed toward the satellite, can operate effectively without the need for expensive equipment to track the satellite’s motion. Especially for applications that require a large number of ground antennae (such as direct TV distribution), the savings in ground equipment can more than justify the extra cost and onboard complexity of lifting a satellite into the relatively high geostationary orbit. A GEO spacecraft appears to be in a fixed position to an earth-based observer and revolves around the earth at a constant speed once per day over the equator. This allows for the establishment of permanent links. The use of multiple satellites connected via ISL allows for a worldwide coverage, e.g. used for satellite phones. The mission value is usually high and dependent on the application (civil-, government-, military- or commercial communication links and services, TV and Radio broadcast, Satellite broadband, Internet etc.).

Communication satellites can also represent a commercial asset to their operators, e.g. through leasing of transponder capacity. Depending on the applications and complexity of payload(s), the structure of the ground networks can be very complex.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 10 of 58


Objectives • Provides space network based communication links and services and/or transponder capacity.

• Applications can be:

o TV/Radio broadcast

o Communication links / services

o Internet via broadband data connection

Users • Military

• Government



Examples • Olympus

• Artemis

• Inmarsat

• ASTRA (Europe)

• Milstar (USA)


• Ground: control station(s), user stations

• Space: satellite(s), satellite fleets

External Network Gateways • POTS, Internet

Table 2-2 Characteristics of a communication type mission

2.3 Earth Observation Spacecrafts used for earth observation (remote sensing / environmental monitoring) are specifically designed to observe the earth from orbit e.g. by use of synthetic aperture radar, high resolution optical, infrared, radar altimetry, or ozone monitoring instruments. The purpose can be intended for military use (e.g. reconnaissance) but also for non-military and dual-use scenarios such as the GMES environmental monitoring system.

The data of EO missions are of utmost importance for their users (civil or/and military), thus the mission value is generally high. The manifold use of EO mission data vary from reconnaissance and battlefield assessment, launch detection for missile early warning systems, logistics, cartography, monitoring of phenomena, geological mapping, mineral exploration to surveillance and emergency management. Governments increasingly use of remote sensing to observe "hot spots" and to monitor the adherence of international regulations and environmental threats. Depending on the scenario, the loss of EO services can be critical, not only to commercial operators, but also for user groups relying on information or services. Pure military missions are not within the focus of the Agency but e.g. the GMES missions are foreseen to account for dual use scenarios1. In the following the term "military" is used linked to dual-use mission scenarios. Within these scenarios the security level is determined by the user with the highest security requirements; that, in the majority of cases, will be the military user.

Due to the broad range of applications, the structure of the ground network can range from complex (e.g. if for a reconnaissance system mission planning and data acquisition can be performed by different nations) to clearly structured. An example for a clearly structured ground network is ESA’s GAIA mission (although this is no EO mission), where TM/TC and downlink data paths are handled only by ground stations of the ESA Science Network.

1 see ESA/PB-EO(2005)54, rev.3, p.31





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 11 of 58


The science data is distributed to the scientific processing center directly via high-speed communication lines. Users are provided with data by ESA only.

The GMES missions are foreseen to account for dual use scenarios (see e.g. ESA/PB-EO(2005)54, rev.3 p.31). The term "military" is used to describe dual-use mission scenarios.

GatewayGateway GatewayGateway

G/S Command and Data Acquisition

Processing and

Archiving Center

Mission Control

Center

Payload

Management

and Data Pre-

processing

Specific UserRequests

TM

/TC

Raw

Data

User Network

Basic Product

ServiceSegment

Processed Data

Customized Service

Other Ground

Stations

External Data

(e.g. Land Surface)

Airborne andIn situ Data

Local and

SpecializedData

ExternalAtmospheric

Data

Pre-processed Data

PerformanceVerification

File: EO_Scenario_1.vsd

Green Sentinel(s)Other Satellites

Figure 2-1: EO Scenario Example 1 (GMES)





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 12 of 58


Objectives • Provides space based observation of the earth.

• The observation data can be:

o Optical

o Radar

o Infrared

o etc.

Users • Military

• Life saving services



Examples • GMES

• SAR-Lupe (Germany)

• Helios 2 (France)



• Space: satellite(s)


Table 2-3 Characteristics of an earth observation type mission

2.4 Science / Technology Spacecrafts for science / technology missions are specially designed for their tasks, which sometimes may be similar to EO missions but not to study the Earth but other planets or objects of the Solar System. In this way, payload(s) can be similar to an EO mission but mounted on a spacecraft designed for a deep space mission or on a planetary lander module. The objectives of science / technology missions are manifold. Missions may be the search for Earth-like planets, studying the origin of comets, the relationship between comet and interstellar material, to collect long-wavelength infrared radiation from distant objects in the universe, an X-Ray telescope, or to experiment with new materials and technologies in a space environment. The examples listed show that there is no clear boundary to deep space missions, because science & technology missions are often deep space missions (e.g. Rosetta). The main characteristic of these missions is that they generally do not have governmental or military user groups.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 13 of 58


GatewayGateway

Cebreros

New NorciaKourou

DSN (add-on/back-up)

GatewayGateway

European Space

Operations Centre (ESOC)

V M O CVenus Express

MissionOperations

Centre

Critical Operations Support(PI expertise & authority)

Real TimeSupport

PI Support Area

Venus Express ScienceOperations Centre (VSOC)

Consolidated PayloadOperations Requests (CPOR)

Science Policy &Guidelines

TM/TC

Consolidated PayloadOperations Requests (CPOR)

P O SPayload

OperationsService

P I s

PrincipalInvestigators

Telemetry & AuxillaryData to all Users

S W TScience Working

Team

1

2

1

2

� Near Earth Commisioning� Venus Commisioning

� Routine Operations

File: Venus_Express_SC_Operation.vsd Figure 2-2: Spacecraft operations scenario example (Venus Express)

An example for a spacecraft operations scenario is depicted in Figure 2-2. The reference system architecture enables the mapping of the stakeholder-specific communication lines to the generic technical architecture as given in Figure 4-6.

Objectives • Provides: space based observation of objects within the solar system, extraction of science data from onboard experiments and payloads, and robotic capabilities

• Measurement/experiment data can be:

o determination of chemical, mineralogical and isotopic compositions

o characterization of the nucleus of a comet

o determination of dynamic properties, surface morphology and composition

o determination of physical properties and interrelation of volatiles and refractories

o etc.

Users • Civilian (research)


Examples • Venus Express

• Integral

• Robotic Servicing

• Technological Demonstrators



• Space: spacecraft(s)


Table 2-4 Characteristics of a science / technology type mission.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 14 of 58


2.5 Deep Space ESA has been extremely active with many missions to explore our solar system. But not only are planets being studied, asteroids and comets are also of interest. The users of these systems are mostly civilian research groups. ESA's first deep-space mission, Giotto, passed within 600 km of the nucleus of Comet Halley on 13 March 1986.

These types of missions do provide a challenge due to the distances that needs to be covered, that result in very slow communication channels. E.g. a message can take minutes or hours to reach its destination (Mars 4 and 20 minutes, Saturn 70 to 90 minutes). These communication networks can be attached to the earth network using delay tolerant protocols.

Naturally all missions cause investments in costs and time, but in contrast to others deep space missions may take many years to reach some of the destinations (Wirtanen, Voyager 1 and 2) and additionally may be dependant from a start window. Loss of communication or satellite contact can wipe out many years of planning and work. These missions do not effect national security; however, a hacker lock-out could result in image loss or a loss of the spacecraft. If the mission is lost due to weak security provisions, and the next start window may be 73 years later, the loss in terms of image, time and money will differ from e.g. a LEO mission. This makes security important also to deep space missions; even though the level of security will be lower compared to other mission types.

Objectives • Scientific exploration of interplanetary objects and distant planets, e.g. planetary geology.

• The observation data can be:

o Optical

o Radar

o Infrared

o etc.

Users • Civilian (science and technology)

Examples • Giotto (ESA)

• Aurora (ESA)

• Rosetta (ESA)

• Hayabusa (Japan)

• Deep Impact (NASA)



• Space: satellite(s), probes


Table 2-5 Characteristics of a deep space type mission.

2.6 Manned Space Flight For human missions, safety engineering is critical and therefore, extensively applied. There is no doubt that the risk of failure with catastrophic consequence (e.g., loss of human beings) needs to be controlled to acceptable levels. The engineering process will produce requirements that are unique to this type of missions. Fail safe criterion and its implications on redundancy level is unique to manned missions.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 15 of 58


The loss of a manned mission would be extremely damaging to the reputation and interests of carriers and their program. Any other mission, however, needs to respect reliability and availability requirements and even failure tolerance.

Regarding TMTC security the missions data and even the communication systems must be protected from unauthorized access. The endangering of privacy for astronauts conversations and medical data is unique to human missions so measures must be taken to prevent interception and exploitation of data links. High availability and secure access to the onboard telecommand system is required under all possible environmental conditions during the mission.

Objectives • Space exploration with a human crew.

o Scientific experiments

o Spacecraft / space station service and repair

o Transportation

o etc.

Users • Governmental (national, multinational)



Examples • Apollo, Soyuz

• ISS, MIR

• Columbus

• Aurora (ESA)



• Space: spacecraft(s), space station, space basis (e.g. moon)

External Network Gateways • Webserver for customer data download

Table 2-6 Characteristics of a manned space flight mission

2.7 Launcher Launcher services are carried out by Arianespace, an ESA subsidiary, at ESA's spaceport in French Guiana. Relating to this project launcher missions are outside the scope of the Agency and only mentioned for completeness. Further study on launchers is omitted whereas the launch phase is considered as part of the reference system architecture.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 16 of 58


3 APPLICABLE SYSTEMS

The architecture of a mission’s communication system comprises nodes and links in the ground network, space link and space network domain. The Space Communications Protocol Standards (SCPS) [RD 3] approach is able to provide end-to-end security services which are transported between endpoints across these network domains. SCPS-TP is actually used/analyzed by the Agency for transport layer optimization for dynamic bandwidth satellite networks2. SLE services are able to provide (secured) end-to-end services between ground stations and users. This is why we see these systems as applicable and relevant to the RSA.

The space link as well as the space network domain do not conform to the Internet’s underlying assumptions: continuous, bi-directional end-to-end paths, short round trip delays, low error rates and symmetric data rates. In fact these networks are characterized by intermittent connectivity, long or variable delay, asymmetric data rates and high error rates. These properties are considered by the Delay Tolerant Network (DTN) approach [RD 4] which is described in Annex A. A protocol layer overview is given in Figure 3-1. The applicable systems described hereinafter (SCPS, DTN) are mentioned in order to address future missions or just as examples for a more secure solutions.

DTN (Optional)

Link Layer

Network Layer

Transport Layer

Physical Layer

CCSDS or other

Data Link

IPsec

Physical

Data Link

TCP

Physical

SCPS-TP

OSI (simplified) SCPS TCP/IP

Application Layer SCPS-FP or otherApplication

FTP or otherApplication

IP

SCPS-SP

SCPS-NP

File: Protocol_Layer_Overview.vsd Figure 3-1: Protocol Layer Overview

2 http://telecom.esa.int/telecom/www/object/index.cfm?fobjectid=9647





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 17 of 58


3.1 ESA Data Handling and System Layers ESA Packet Telemetry and Telecommand Systems were conceived to match the ESA ground data network architecture and operational philosophy, which is influenced by the distributed location of most of its elements over the Earth.

The control center is, in principle, only concerned with data processes pertaining to the packetization layer and above, for both telemetry and telecommand. The remote ground stations, on the other hand, are concerned with the data processes pertaining to the layers below the packetization layer (Figure 3-2).

The communication lines drawn between the spacecraft control center and the remote ground station are, usually, hired data lines of modest capacity. The advantages of a layered architecture are that all time-critical functions are concentrated in the front-end ground stations. This is particularly true for the closed-loop operation of the COP-l data link protocol. The services of the ground communication links are only required for the packet data.

Figure 3-2: ESA Ground Data network Configuration

3.1.1 TC System Layers

An overview on TC system layers and services is depicted in Figure 3-3. A short description (derived from [RD 14]) of the TC system layers is given below. A detailed description can be found in [RD 14].





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 18 of 58


Figure 3-3: TC System Layers and Services [RD 14]

3.1.1.1 Physical Layer

Input for the physical layer is the Command Link Transmission Unit (CLTU) from Coding Layer, output e.g. modulated RF and vice versa. The CMM’s (Carrier Modulation Modes) consist of 4 states, corresponding to absence or presence of data structures (e.g. CLTU from above layer) and idling.

The orderly activation and modulation of the radio frequency carrier (in combination with the CMM) is controlled by the Physical Layer Operations Procedure (PLOP) which is described in [RD 16].

SLE service on physical layer: Forward CLTUs (F-CLTU).

3.1.1.2 Coding Layer

Input for the coding layer is the TC Transfer Frame from the Transfer Layer, output is the CLTU and vice versa:

Figure 3-4: Format of the CLTU





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 19 of 58


Each code block contains an error control field which contains 7 bits obtained from a modified Bose-Chaudhuri-Hocquenghem (BCH) code. BCH encodes blocks of 32, 40, 48, 56 bits each. For the BCH coder short code blocks are padded with “0”s up to 56 bit. This is described in [RD 16].

SLE service on coding layer: Forward TC Frames (F-TCF).

3.1.1.3 Transfer Layer

Input for the transfer layer is the TC segment, output is the TC transfer frame (data direction for sending end). The protocol data unit (PDU) for the transfer layer is the TC transfer frame. The following services are provided on the transfer layer:

S/C identification by 10 bit S/C-ID in transfer frame header

Error control by 16 bit frame error control field

Sequence control by CCSDS command operation procedure one (COP-1)

Flow control by 32 bit command link control word (CLCW)

Abnormal condition recovery

SLE service on transfer layer: Forward TC Virtual Channel Access (F-TCVCA).

3.1.1.4 Segmentation Layer

Input for the segmentation layer is the TC packet, output is the TC segment (data direction for sending end). The protocol data unit (PDU) for the segmentation layer is the TC segment. The following services are provided on the segmentation layer:

Segmentation of TC packets

Routing of TC packets

Multiplexing of TC packets

Authentication of TC segments (optional)

SLE service on segmentation layer: Forward Space Packets (F-SP).

3.1.1.5 Packetization Layer

Input for the packetization layer are data from application processes, output is the TC packet (data direction for sending end). The protocol data unit (PDU) for the packetization layer is the TC packet. The following services are provided on the packetization layer:

Transport of application data units





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 20 of 58


3.1.2 TM System Layers

The following short description is derived from [RD 15] and [RD 17]. A detailed description of the TM system layers can be found in [RD 15] and [RD 17].

3.1.2.1 Physical Layer

The physical layer provides connection between the spacecraft (sending end) and the ground segment (receiving end) via an RF link. Input for the physical layer is the coded transfer frame, output is the modulated RF (data direction for sending end).

3.1.2.2 Coding Layer

Input for the coding layer is the transfer frame, output is the coded transfer frame (data direction for sending end). The following services are provided on the coding layer: Forward error correction Synchronization (ASM) Randomization SLE service on coding layer: Return All Frames (R-AF).

3.1.2.3 Transfer Layer

Input for the transfer layer is the telemetry packet, output is the (un-coded) transfer frame (data direction for sending end). The following services are provided on the transfer layer: Transport of telemetry packets Multiplexing of virtual channels SLE service on transfer layer: Return Channel Frames (R-CF), Return Operational Control Field (R-OCF) and Return Frame Secondary Header (R-FSH).

3.1.2.4 Segmentation Layer

Input for the segmentation layer is the source packet, output is the telemetry packet (data direction for sending end). The following services are provided on the segmentation layer:

Segmentation of source packets

Generation of telemetry packet header

SLE service on segmentation layer: Return Space Packets (R-SP).





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 21 of 58


3.1.2.5 Packetization Layer

Input for the packetization layer are the application data (e.g. from payload), output is the source packet (data direction for sending end). The following services are provided on the packetization layer:

Adding packet error control

Generation of source packet header

Packet sequence control

Packet identification.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 22 of 58


3.2 Space Link Extension (SLE) Services “The Space Link Extension Services extend the forward Telecommand (TC) and return Telemetry (TM) services defined by the CCSDS (see figure 1-1.). The forward TC and return TM services are used by many space missions on the space link between ground stations and spacecraft [RD 3]”.

Figure 3-5: Ground Stations Provide SLE Services to Users [RD 3]

Space Link Extension Services (SLE) arise from the desire of spacecraft operations organizations to standardize the interfaces for the transport and management of space data on the ground. The Consultative Committee for Space Data Systems (CCSDS) has defined and released a cross support reference model [RD 1]. This model defines a set of recommended services for ground link standards for inter-agency cross support. SLE services complements existing CCSDS recommendations that apply to space links based on packet telemetry, packet telecommand, and Advanced Orbiting Systems (AOS) recommendations [RD 8]. SLE extends the existing CCSDS recommendations for space links to include the exchange of spacecraft data between ground elements. CCSDS SLE has become a widely accepted standard that supports interoperability between mission user facilities and ground station facilities owned and managed by different organizations (space agencies, commercial sites, universities, etc.).

SLE services enable the ground segment assets of space agencies, ground station operators and space data users to interoperate without the need for ad hoc and complicated gateways specifically designed for each new mission. In this way, standard and interoperable access to the spacecraft via ground stations around the world is enabled.

SLE builds on the widespread adoption of CCSDS space link protocols between ground station and spacecraft and includes transfer service specifications for telemetry frames (RCF, RAF) and command link transmission units (CLTU) to move space link data units between ground stations, control centers and end-user facilities. Management service specifications are included to control the scheduling and provisioning of the transfer service. The two phases of SLE operation are named the definition phase and the utilization phase. The definition phase handles the management activities whereas the utilization phase is responsible for the data transfer, either in real-time or delayed.

By using SLE services, the users of spacecraft data are able to command their payloads and access their data through a familiar interface. Available communication technology such as the Internet or ISDN lines can be used as the communication medium. The conventional return SLE services associated with conventional TM are depicted in Figure 3-6:





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 23 of 58


GatewayGateway

All Frames

Production

ChannelFrames

Production

Packet

Production

USERS

R-AF

R-CF

From Spacelink

R-OCFR-FSH

R-CF

R-AF

R-SP

File: Reference_Architecture_Generic.vsd Figure 3-6: Conventional Return SLE Services (TM) [RD 3]

The advantage of this architecture is that all mission scenarios and various distributions of system elements are covered. The modules of the space link extension system can be combined in one ground station as well as they can be divided into several units distributed within the ground element. The forward SLE services associated with conventional TC are depicted in Figure 3-7:

GatewayGateway

CLTUProduction

TC Frames

Production

VC and Packet

Production

USERS

F-CLTU

F-CLTU F-TCF

F-TCF F-TCVCA

F-SP

Towards Spacelink

File: Reference_Architecture_Generic.vsd Figure 3-7: Conventional Forward SLE Services (TC) [RD 3]

Services provided by an SLE system e.g. the TM Return All Frames (R-AF) or the TC Forward Command Link Transmission Unit (F-CLTU) service, allow for an End-to-End view of the system. These services operate on the application layer within the simplified 5-layer Open Systems Interconnection (OSI) reference model.

Due to their scaleable nature, only actual services required by a service user or a service provider need to be implemented. For example, only the F-CLTU, F-SP and R-AF services have been implemented to support ESA’s INTEGRAL mission. Another example is given in Figure 3-8 below:

SLE Complex B

(e.g. Operations Control Center / TM processing)

SLE Complex A

(e.g. GroundStation)

All FramesProduction

ChannelFrames

Production

PacketProduction

CLTUProduction

TC FramesProduction

VC and PacketProduction

Mission DataOperations System

(e.g. University)

USERS(MDOS)

F-SPF-TCFF-CLTU

R-SPR-CFR-AF

GatewayGateway

File: Reference_Architecture_Generic.vsd

Figure 3-8: Example for a SLE Service Architecture





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 24 of 58


The SLE API developed by ESA and the Jet Propulsion Laboratory (JPL) is part of the Telemetry and Telecommand System (TMTCS) and consists of two distinct layers, the API Proxy and the API Service Element. The purpose of the API proxy is to provide a common technology independent interface to the data communications systems used for transmission of SLE protocol data units across networks. It makes the higher layers of the API and SLE applications independent of specific communications technology. External TMTCS interfaces are based on TCP/IP (WAN/LAN).

3.2.1 SLE Security Aspects

The security aspects of SLE services have been analyzed in [RD 2]. They did valuable work on locating security functions for SLE services within the CCSDS TMTC protocol stack. The CCSDS protocol stack and possible locations for security functions are depicted in Figure 3-9 (TC) and Figure 3-10 (TM). Also the assessment results given in Appendix D of [RD 2] are deemed to give valuable inputs during the next phases of this project.

Figure 3-9: TC protocol Stack [RD 2]

Advantages and disadvantages for each possible location of the security sublayer are outlined in table form. They will be used as input for the cost-benefit analysis in phase 2 of the project.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 25 of 58


Figure 3-10: TM Protocol Stack[RD 2]

In contrast to the study conclusions in [RD 2] we see a CBC-MAC using AES as not recommendable for TC authentication. The CBC-MAC principle is depicted in Figure 3-11.

Figure 3-11: CBC-MAC - the output of the last stage serves as the authentication code.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 26 of 58


A block cipher used in cipher block chaining mode (CBC) has in fact some properties of a true mathematical one-way function which normally is used to generate a message authentication code; namely compression (only the last cipher text block is used as MAC) and the dependence of this block upon every bit of input data.

Nevertheless a symmetrical block cipher is not a one-way function (serves in both directions) and if it is free from collisions (some other input data may create the same output) is incapable of proof.

For further details on CBC-MAC weaknesses refer to [RD 18].So we would recommend the use of a real one-way function with proven low collision probability (e.g. RIPEMD) to generate the message authentication codes.

Furthermore EC-DSA is outlined as “most promising” of public key cryptography for TC authentication. We would like to state that there is no need for the use of asymmetrical algorithms for TC authentication. The time needed to verify a 1024 bit RSA signature (1.27 sec3) can be optimized by use of EC algorithms but even though this is not applicable to TC data streams.

PKC should be used for authenticated key agreement and the agreed keys should be used to generate a MAC by use of an algorithm like RIPEMD. This will be outlined more detailed in phase 2 of the project where countermeasures and appropriate algorithms will be identified to realize security within the CCSDS protocol stack.

3 SPARC II





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 27 of 58


3.3 Space Communications Protocol Standards (SCPS) Due to the fact that this study is not restricted to the protocols actually in use by the Agency but shall also be applicable to future missions, SCPS deemed to be candidates to realize end-to-end security services and therefore they are relevant and potentially applicable to the reference system architecture. The future system design process will have to chose appropriate protocols dependent of the end-to-end services the system shall provide. This includes Deep Space missions and networks respectively. The four Space Communications Protocol Specification (SCPS) recommendations define a protocol suite ([RD 10], [RD 11], [RD 12], [RD 13]) that is parallel in function to, and interoperable with, the protocols of the Earth-based Internet (FTP/TCP/IP). The Internet protocol suite provides many functions needed for space communications, but these protocols are designed to meet environmental requirements that are significantly different from those encountered in communicating with a remote spacecraft. Applications involving space communications links, require special network protocols for reliable and efficient operation. Plain TCP, in particular, performs poorly over space communications links because of the link's long propagation delay and significant bit errors. A key limitation with TCP in high bit error networks is the lack of error correction capabilities. Since TCP cannot correct bit errors, if even a single bit within a packet is corrupted in transit, the receiver will discard the entire packet. This turns bit errors into packet loss. In addition, TCP can recover from the loss of only one packet per round trip.

SCPS protocols support the transfer of space mission data through space-to-ground and space-to space data sub-networks. These protocols are focused on the unique requirements of data transfer through sub-networks that involve a space data transmission path.

Figure 3-12: SCPS end-to-end Services Overview





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 28 of 58


4 REFERENCE SYSTEM ARCHITECTURE

4.1 Introduction The TM/TC subsystem provides an important two-way information data flow between a spacecraft (or spacecrafts) and its ground control station(s). Depending on the mission type, orbit, type of payload and the selected ground station(s), a reference system architecture has to give regards to the differences in subsystem design. The space link can be a continuous link, with the spacecraft being visible at all times from the ground station. This allows for a relaxed (synchronous) transmission link, compared to a non-synchronous orbit system where the spacecraft is visible to the ground station for only a few minutes during each pass. In the latter case, on-board data storage and a rapid transfer link is needed, whereas a space station requires a continuous link from its non-synchronous orbit which can be provided by a two-way link with any ground station in sight and/or by a relay system in GEO. In case of EO missions relay satellites are also used to place the data directly at mid latitudes where the processing and user services are located. Satellites for high-resolution imaging (like ENVISAT or ALOS) require much higher downlink data rates than the previous generation. They do not rely on regional X-band stations for mission data capture completeness; this has been possible by using a large capacity on board recorder and a speeded data discharge when flying over home station. They use relay satellites, which can be complemented with polar data downlink (240Mbps ALOS DTRS relay or 2 channels at 100Mbps for Envisat).

During launch, intermediate orbits and early operation early phases all spacecrafts are non-synchronous and require special ground support before they are handed over to their dedicated ground controllers. Therefore, the reference system architecture has to meet all of these demands as well as the demands induced by the diversity of missions.

For the modules comprising the nodes and elements of a typical space mission communication system, the relevant data flows and interfaces with other systems have been identified. The study focuses on the TM/TC communication and the involved subsystems; however, the threats and vulnerabilities of space mission communication systems are not limited to this link. A dependable system has to be considered as a whole.

The basic security services can not be provided only for TM/TC links without giving regards to admittance, access etc. to system facilities or network components, e.g. access control must be performed to all resources used to manage a spacecraft.

Within an end-to-end security association in some cases an isolated perception of a single intermediate link may be required. The space link transports low level TC which grants direct access to the spacecraft resources (independent of higher layer commands which are executed by the on-board S/W). In this way the space links position is outstanding, also if it’s an intermediate part within a security association. Security, located at higher protocol layers, does not prevent from successfully performed jamming attacks (Denial of Service). In contrast to, and independent of, higher layer or application commands (where an end-to-end security approach may be used), the physical layer of the space link needs to be covered by an additional link-by-link approach. This is independent from authenticated access to the spacecraft resources but will be used to ensure the availability of authenticated access to the spacecraft. Thus, the definition of mission scenarios and communication domains is followed by the characterization and identification of services implying an end-to-end instead of a link-by-link paradigm (security associations, refer to chapter 4.6). The chosen paradigm directly affects requirements and the security engineering approach. The traditional link encryption approach is depicted in Figure 4-1:





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 29 of 58


computer

GroundStation

linkcrypto

link

crypto

traditional link

encryption

linkcrypto

device

linkcryptodevice

linkcrypto

device

link

cryptodevice

„Trusted“ Gateway

(encrypt)

(decrypt)

(encrypt)

(decrypt)

Source

Destination

Source

Destination

Hop-by-Hop

File: Security_Paradigms_1.vsd Figure 4-1: Security Paradigms - Link Encryption

Link encryption is an adequate way, to protect a single exposed connection (e.g. the space-to-ground link) against transmission attacks like eavesdropping, traffic analysis, or spoofing. But in multi-hop scenarios, this approach will lead to an exploding number of crypto devices and extraordinary effort in key management and distribution. Within the ground network, CCSDS Space Link Extension Service (SLE) provides a set of services to allow for the exchange of space link protocol data units between terrestrial nodes like operational control centers, TT&C ground stations and end user facilities.

An end-to-end approach (Figure 4-2) will be used, where end-to-end services concerned with the TM/TC system are available.

Public Network

Source

Cryptodevice

File: Security_Paradigms_1.vsd

Destination(s)

Crypto

device

Destination

Crypto

device

End-to-End

Figure 4-2: Security Paradigms – End-to-End

The generic core architecture basic components has three distinct domains (see Figure 4-6):

• the ground network;

• the space link;

• and the space network is depicted in.

Basically, regards have to be given to the all perspectives of the system architecture:

• the technical view to the system and its communication connections;

• the operational view to the system and its elements;

• end-to-end and link-by-link approach.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 30 of 58


4.2 Electrical Ground Support Equipment (EGSE) The EGSE in general includes all hard- and software required to support integration and testing of the spacecraft. Usually the following functions and services are provided by the EGSE:

o Power supply and eclipse simulation

o Telecommand and telemetry handling

o On-board computer access

o Data processing, archiving and retrieval

o Data base management

o Flight hardware emulation

o Flight stimuli

o Spacecraft Dynamic simulation

o Man - Machine dialogue (MMI)

All security related functions must be provided during integration and test. Security associations (possibly located on multiple layers) must be represented by the EGSE. Interfaces to gather all required data for the validation, verification and evaluation of the crypto system must be provided by the EGSE. Further study into the complete EGSE is utmost complex and outside the scope of this project. Since the EGSE’s position is external to the operational system, regards will be given only to modules needed to validate and verify end-to-end command link security between control center and spacecraft (“Crypto-EGSE”).

The key-fill unit, used to provide the crypto keys, will be regarded as a separate device within the EGSE. An example is given in Figure 4-3.

Converter, e.g.

RS232 / RS422 /

fibre optic

Converter, e.g.

RS232 / RS422 /

fibre optic

MobileEquipment

e.g. Laptop,Black Box Unit

to Key-fill I/F

Satellite Management Unit,Ground Crypto-Device etc.

(Power Supply)(Power Supply)

Key-fillDevice

Figure 4-3: Key-fill device connected to SMU

The key-fill device provides the keys to the security modules. There is only a temporarily connection between the key-fill device and the key-fill I/Fs of other system modules (e.g. via fiber optic), thus the key-fill device can be seen isolated from the network domains. Requirements generated by its use, concerned e.g. to device handling, electromagnetic emissions, sealing of connectors / harnesses and handling of long term crypto-parameters and secrets are outside of scope. The latter includes the storage and controlled destruction of hard disks or other removable media used during the key-fill process.

An example for a command link system configuration with security modules for key management, en-/decryption and authentication is given in Figure 4-4:





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 31 of 58


S-bandtelecommand/telemetry

Satellite Control Center SCC

Ground Crypto Board GCB

Krypto-EinheitSmart Card SC1

Mission planningMP

I/F

Flight Operations Segment (FOS)

AuthenticationProcess

Keystorage

e.g. Smart Card

Backup key storage

Dedicated

line(s)

Encryption/Decryption

Boardcomputer

SMU Crypto Module

Satellite Management Unit (SMU)

TMTC

Module

S-bandtelecommand/telemetry

e.g. S-Band

HF-linkTC TM

Serial I/F

Inter-Satellite Link

ISL

Spacecraft

HF Link, optical,...

KeyAgreement

Authenti-cation

Process

DSP

System

Key I/F:to Payload Data

Decryption

Key I/F:

to Payload DataEncryption

Channel Coding Unit

Channel Decoding Unit

ISL commands

Ground Crypto Modules

Key Agreement Encryption/Decryption

DSP System

Plain TCs

Encrypted TM

Encrypted TC

Plain TM

Figure 4-4: Example system with security modules

The Key I/Fs are used to provide the appropriate keys for payload data encryption (on board of the spacecraft) and payload data decryption (within the ground segment). The Crypto-EGSE contains all the modules needed to provide the designated security services like authentication, en-/decryption etc. The generation of TC for test purposes theoretically can also be part of the EGSE, but it is assumed here that a real ground station is used to generate the test-telecommands.

Crypto EGSE

telecommand/telemetry(e.g. S-band)

Satellite Control Center SCC

Ground Crypto Board GCB

Krypto-EinheitSmart Card SC1

Mission planningMP

I/F

Authentication

Process

Keystorage

e.g. Smart Card

Backup key storage

Dedicated

line(s)

To Spacecraft

HF/Test-linkTest TC Test TM

Key I/F:to Payload Data

Decryption

Channel Decoding UnitGround Crypto Modules

Key Agreement Encryption/Decryption

DSP System

Plain Test TCsEncrypted Test TM

Encrypted Test TCPlain Test TM

Flight Operations Segment (FOS)

Figure 4-5: Example for a Crypto EGSE

An example for a Crypto EGSE is given in Figure 4-5. Debug interfaces are needed to access the data required for validation and verification of the security functions for the command link. These data need to be handled according to their classification as well as the location where the data is extracted.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 32 of 58


4.3 Launch and Early Orbit Phase (LEOP) The launch and early orbit phase has to be considered due to it’s implications to TMTC security and the derived system security requirements. The LEOP can be divided into the following three steps:

o A functional test of the spacecraft which is performed at the launcher facilities close to launch (e.g. white room or before the fairing is closed)

o the launch itself, and

o the early orbit phase

The functional test includes testing the communication and security sub-systems and must be performed with one of the ground stations operating the spacecraft after LEOP. Flight keys are used to perform this tests. There are two options to provide these keys to the spacecraft: either the keys are introduced immediately before launch by use of some EGSE, or the keys already have been stored before the spacecraft’s transport to the launcher facilities. In the latter case the transport and storage of the spacecraft must be secured. The implications concerned with both options are out of scope of this project but should be kept in mind. The functional test may be performed by use of a network connection between the spacecraft at launcher facilities and it’s ground station. This network connection must be protected against active and passive attacks. A mobile EGSE can be used instead but we would like to annotate that in some cases the import or export of cryptographic equipment may violate foreign laws. This for sure is also out of scope of the project, but the security requirements to protect the functional tests must be considered.

During the launch phase, the launcher places the spacecraft into it’s orbit or it’s transfer orbit. The launcher TM is not in scope of the project although it may transport some housekeeping data from the spacecraft’s health sensors (if the spacecraft is powered during launch).

After the spacecraft has been released from the launcher, the attitude is stabilized passively by a slow rotation (usually at a rate of about 1 revolution per minute). Power is connected via the separation switch and the spacecraft starts TM transmission. This phase has to be considered due to the possibly limited timeslots to access the spacecraft via TC. This is similar to emergency situations where the spacecraft is tumbling. Therefore some system designs allow to bypass the security layers to account for emergency and contingency situations; but this is a serious backdoor which might be able to endanger the value of the mission. The implications of the launch phase will be considered as requirements, dependencies and conflicts within the security requirements report.

The LEOP ground station tracks the Telemetry signal, starts to check out all subsystems of the spacecraft to verify the spacecraft to be in a good and healthy condition and performs the commissioning.

Within the reference system architecture the entities are represented by a spacecraft and a corresponding ground station, even though a third-party or any other ground station may be used to perform the LEOP.

Nevertheless this phase must be considered and therefore it is mentioned here. If security is enabled during all lifecycles, the ground station, used to perform the LEOP, must be disposed of the appropriate communication equipment and the corresponding keys. This influences the interoperability and cross support capabilities between ground stations. These implications will be considered as requirements, dependencies and conflicts within the security requirements report.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 33 of 58


4.4 Reference System Architecture Definition

Spacecraft n

ISLLink

GatewayGateway GatewayGateway

G/S Antenna

Network

G/S Antenna

Network

G/S 1

FOS(Flight Operations Segment)

Mission

Control

Payload Operations

G/S n

NetworkLink

Network

Link

PDGSPayload Data

Ground Segment

(Service Provider)

NetworkLink

Payload

ManagementPOS

(Payload Operations

Service)

User n

User

Task n

UserTask 3User

Task 2User

Task 1

Ground

Space Link

Space Network

L1a L1b L2a L2b

L4bL6a

L6b

L7a

L7b

L8a L8b L9a L9b L10a L10b

L12a L12bL11a L11b L14a L14b

L15

a

L15

b

L16

a

L16

b

L13a

L13b

M1b

M1c

M2

M3 M3a

M4

M4a M4b

M4c

M5

M5a

M5b

M6

L17a

L17b

M2c

M6a Payload

Management(optional)

M7

M7aNetwork

Link

M7b

L18a L18b

L19a L19b

L20a

L20b

...

L21a

L21b

Spacecraft ...

ISLLink

Payload:P/L Data Link

Avionics:On-Board Data

Handling,

Telemetry &Telecommand

L3a L3b L4a

L5a

L5

b

M1

M1aSpacecraft 2

ISLLink



Handling,Telemetry &

Telecommand

L3a L3b L4a

L5

aL5b

M1

M1aSpacecraft 1

ISLLink



Handling,

Telemetry &Telecommand

L3a L3b L4a

L5a

L5

b

M1

M1a

......

M1b

M1c

File: Reference_Architecture_Generic_v3.vsd

L4b

Spacecraft

Test-IF Test-IF

Ground Network

M1bn M1an

L3an L3bnL4an L4bn

L5an

L5

bn

L22a

L22b

Crypto-

EGSE

M8

Figure 4-6: Generic Core Architecture for Space Missions





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 34 of 58


Red colored connections are “classical” spacecraft TM/TC data transmission links related to operation and control of the spacecraft (e.g. HDCs), whereas the blue colored ones denote the payload related TM/TC data links. The user of a service provided by the spacecraft will never access the spacecraft system TM/TC (e.g. Power OFF/ON). TM/TC which is made accessible to users (e.g. via SLE services) will be related to the payload. This is indicated by the blue color. There can be more than one TM/TC link present for some types of spacecrafts. Commanding of the payload can be realized through bi-directional payload TM/TC links.

The basic nodes and elements of the TM/TC reference system architecture are outlined in the following table:

Module Description connected to

M1 (Spacecraft) A spacecraft (satellite, space station, shuttle etc.)

consists of an avionics part (on-board data handling, telemetry and telecommand) and one or more payloads

M2, M3, M3a

M1a (Avionics)

This module contains the avionics of the spacecraft, TM/TC transceiver, on-board data handling (including HDC processing) and the spacecrafts bus system to

control the payload(s)

M1b, M1c, M3

M1b (Payload) Instrument / Payload: data pre-processing and TM

downlink M1a, M1c, M3a

M1c / M2c (ISL) Optical or RF Inter Spacecraft Link (ISL) M1a, M1b, M2

M2 (Add. Spacecraft)

Other spacecrafts can act as relay stations for commanding of M1 (e.g. GEO relay) and/or as nodes of

the space network (e.g. global satellite telecommunication network). M2 represents a node of the

space network which can also be a Probe, only accessible through ISL, e.g. Cassini/Huygens

M1, (and M3, M3a)

M3 / M3a (G/S Antenna Network)

The ground station antenna network can be a network of distributed antennas (e.g. ESA science network) for

handling of TM/TC, payload TM/TC and downlink data paths from one more various locations or a single ground station with antenna(s) for all TM/TC links. The antenna used for payload TM/TC can also be a part of the user

station (e.g. Handheld, Sat phone etc.)

M1, M4 (and M2)

M4 (Ground Station, GS)

Flight Operations Segment

The ground station consists of the mission control center and the payload management, and can be connected to

other ground and user stations via network link

M3, M3a, M5, M6, M8 (indirectly M7)

M4a (Mission Control Center) Mission and satellite control, telemetry and telecommand,

flight dynamics, mission planning, Command and Data acquisition (CDA) and archiving

M3, M4b, M4c, M6

M4b (Payload Operations) Dedicated PL operation (control & quality), handling of PL

control TM/TC (e.g. calibration & remote control), processing, archiving and distribution

M3a, M4a, M4c

M5 (PDGS)

Payload Data Ground Segment

Provides and possibly commercializes services yielded by the spacecraft system to users or subsequent service

providers (third party service providers)

M3a, M4, M7 (indirectly M6)

M5a (Payload Management, POS) Dedicated PL processing (control & quality), processing,

archiving and distribution M3a, M5b

M6 (Other GS) Alternative Ground station(s) M4, M7 (indirectly

M5)

M7 (User Station) The user station may have its own antenna (network) and also a payload management (if the payload is under user

control). It is connected to the ground station via a

M5, M6 (indirectly M4)





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 35 of 58


Module Description connected to

network link and may provide processed P/L data or services to the user network

M4c/M5b/M6a/M7b (Network Link) Communication unit within the ground network

(terrestrial, RF, and fiber optic) M4a, M4b, M5a,

M7a

M8 Crypto-EGSE for validation and verification of the designated security services for the command link

between control center and spacecraft M4a, M1a, (M1b)

Table 4-1: Nodes and Elements of the Reference System Architecture

Link Description connected to Used Standards/Protocols

L1a TC (uplink): transmission of telecommands

from G/S antenna to the spacecraft via direct space link

M3, M1a

CCSDS File Delivery Protocol (CCSDS 727.0-B-3)

Packet Telecommand Standard (ESA-PSS-04-107),

Space Packet Protocol (CCSDS-133.0-B-1),

TC Space Data Link Protocol (CCSDS-232.0-B-1),

TC Synchronization and Channel Coding

(CCSDS-231.0-B-1)

L1b TM (downlink): transmission of telemetry from spacecraft to G/S antenna via direct space link

M1a, M3


TM Channel Coding Standard (ESA-PSS-04-103)

Packet Telemetry Standard (ESA-PSS-04-106),


TM Space Data Link Protocol (CCSDS-132.0-B-1),

TM Synchronization and Channel Coding

(CCSDS-131.0-B-1)

L2a

Payload TC / Feeder Link (uplink): direct transmission of payload telecommands from

G/S antenna to spacecraft via space link (dedicated P/L TC connection)

M1b, M3a






(CCSDS-231.0-B-1)

AOS Space Data Link Protocol (CCSDS 732.0-B-1)

L2b Payload TM / Data (downlink): direct

transmission of P/L telemetry from spacecraft to G/S antenna via direct space link

M3a, M1b CCSDS File Delivery Protocol

(CCSDS 727.0-B-3)

TM Channel Coding Standard





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 36 of 58



(ESA-PSS-04-103)





(CCSDS-131.0-B-1)

AOS Space Data Link Protocol (CCSDS 732.0-B-1)

L3b TM/TC (ISL uplink): transmission of TM/TC

data to another spacecraft via Inter Spacecraft Link

M1a, M1c

CCSDS Proximity Link (CCSDS 211.2-B-1)

X.25/LAP-B

TCP/IP

SCPS-NP

L3a TM/TC (ISL downlink): reception of TM/TC

data from another spacecraft via Inter Spacecraft Link

M1c, M1a


X.25/LAP-B

TCP/IP

SCPS-NP

L4b Payload TM/TC (ISL uplink): transmission of

P/L-TM/TC data to another spacecraft via Inter Spacecraft Link

M1b, M1c


X.25/LAP-B

TCP/IP

SCPS-NP

L4a Payload TM/TC (ISL downlink): reception of P/L-TM/TC data from another spacecraft via

Inter Spacecraft Link M1c, M1b


X.25/LAP-B

TCP/IP

SCPS-NP

L5a Payload Control TC (uplink): P/L control via spacecraft TC, processed by avionics (e.g.

OBDH) M1a, M1b Proprietary Protocols

L5b

Payload Control TM (downlink): P/L telemetry, processed by on-board avionics and

transmitted via “normal” TM/TC space link (e.g. P/L housekeeping data)

M1b, M1a Proprietary Protocols

L6a Payload TM/TC (ISL uplink), e.g. to probe M2c, M1c



X.25/LAP-B

TCP/IP

SCPS-NP

Optical (laser)

Proprietary Protocols





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 37 of 58



L6b Payload TM/TC (ISL downlink), e.g. from

probe M1c, M2c



X.25/LAP-B

TCP/IP

SCPS-NP

Optical (laser)


L7a TM/TC (ISL), e.g. to probe (TC) or to GEO

relay (TM) M2c, M1c



X.25/LAP-B

TCP/IP

SCPS-NP

Optical (laser)


L7b TM/TC (ISL), e.g. from probe (TM) or from

GEO relay to spacecraft (TC) M1c, M2c



X.25/LAP-B

TCP/IP

SCPS-NP

Optical (laser)


L8a TC (uplink): M4a, M3

SLE - Forward CLTU (CCSDS 912.1-B-2)

SLE - Forward Space Packet (CCSDS 912.3-B-1)

TCP/IP (WAN)

X.25

L8b TM (downlink): M3, M4a

SLE - Return All Frames (CCSDS 911.1-B-2)

SLE - Return Channel Frames (CCSDS 911.2-B-1)

SLE - Return Operational Control Fields

(CCSDS 911.5-B-1)

TCP/IP (WAN)

X.25

L9a Direct Payload TC / Feeder Link (uplink): M4b, M3a



TCP/IP (WAN)

X.25





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 38 of 58



L9b Direct Payload TM / Data (downlink): M3a, M4b

SLE – Return All Frames (CCSDS 911.1-B-2)



(CCSDS 911.5-B-1)

TCP/IP (WAN)

X.25

L10a Payload TC / e.g. Feeder Link (POS uplink): M5a, M3a



TCP/IP (WAN)

X.25

L10b Payload TM / e.g. Data (POS downlink): M3a, M5a

SLE – Return All Frames (CCSDS 911.1-B-2)



(CCSDS 911.5-B-1)

TCP/IP (WAN)

X.25

L11a Mission Control Network input (TC uplink): M4c, M4a TCP/IP (LAN)

L11b Mission Control Network input (TM downlink): M4a, M4c TCP/IP (LAN)

L12a Payload Operation Network (TC uplink) M4c, M4b TCP/IP (LAN)

L12b Payload Operation Network (TM downlink) M4b, M4c TCP/IP (LAN)

L13a GS/Service Provider Network (Payload TC

uplink) M4c, M5b



TCP/IP (WAN)

X.25

L13b GS/Service Provider Network (Payload TM

downlink) M5b, M4c




(CCSDS 911.5-B-1)

TCP/IP (WAN)

X.25

L14a POS Network output (Payload TM downlink) M5a, M5b TCP/IP (LAN)





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 39 of 58



L14b POS Network input (Payload TC uplink) M5b, M5a TCP/IP (LAN)

L15a Inter-GS Network (TC uplink): M6a, M4c



TCP/IP (WAN)

X.25

L15b Inter-GS Network (TM downlink): M4c, M6a




(CCSDS 911.5-B-1)

TCP/IP (WAN)

X.25

L16a Inter-GS Network (Payload TC uplink) M6a, M4c



TCP/IP (WAN)

X.25

L16b Inter-GS Network (Payload TM downlink) M4c, M6a




(CCSDS 911.5-B-1)

TCP/IP (WAN)

X.25

L17b Payload Control TC (uplink) M4a, M4b TCP/IP (LAN)

L17a Payload Control TM (downlink) M4b, M4a TCP/IP (LAN)

L18a Network from service provider to user M5b, M7b TCP/IP (WAN)

X.25

L18b Network from user to service provider M7b, M5b TCP/IP (WAN)

X.25

L19a Optional Payload TC (uplink) for direct user

access to payload, e.g. sat. phone M3a, M7a



TCP/IP (WAN)

X.25

L19b Optional Payload TM (downlink) for direct user access to payload data, e.g. sat. phone, sat.

TV, Internet via satellite M7a, M3a







ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 40 of 58




(CCSDS 911.5-B-1)

TCP/IP (WAN)

X.25

L20a Payload TC (uplink), e.g. sat. phone M7b, M7a TCP/IP (LAN)

L20b Payload TM (downlink), e.g. sat. phone, sat.

TV, Internet via satellite M7a, M7b TCP/IP (LAN)

L21a Payload TM (downlink) between ground station

and user (e.g. basic products or not customized services)

M6a, M7b




(CCSDS 911.5-B-1)

TCP/IP (WAN)

X.25

L21b Payload TC (uplink) between user and ground

station (e.g. user requests to payload) M7b, M6a



TCP/IP (WAN)

X.25

L22a Transmission of plain telecommands and/or encrypted TM from control center to Crypto-

EGSE M4a, M8






(CCSDS-231.0-B-1)






(CCSDS-131.0-B-1)

L22b Transmission of plain TM and/or encrypted TC

from Crypto-EGSE to control center M8, M4a



Packet Telemetry Standard





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 41 of 58



(ESA-PSS-04-106),




(CCSDS-131.0-B-1)





(CCSDS-231.0-B-1)

Table 4-2: Links in the Reference System Architecture

Note: Only the avionics and payload TM/TC related elements are considered within the above tables.

4.5 Network Domain Characterization

4.5.1 Space Network

The space network consists of a number of spacecrafts connected via the inter spacecraft links (ISL), which may use optical or radio frequency transmissions. In Figure 4-6 a red colored connection indicates TM/TC-related transmissions, for example, ISL packets relayed via spacecrafts with low earth orbit or by a GEO positioned spacecraft with its own (continuous) TM/TC link to a ground station. A blue colored data path indicates a connection between the payload units, e.g. the use of relay satellites for payload data links. In general there are two basic approaches to setup inter spacecraft links (ISL) within the space network: frame relay and IF transparent.

4.5.1.1 Frame Relay

Frame relay as an synchronous HDLC protocol (high-level data link control) based network sends its data in HDLC packets, referred to as frames. Frame relay relies on the higher layers to perform end-to-end error correction. Each switch inside a frame relay network just relays the data (frame) to the next switch. X.25 or TCP/IP, in contrast, perform error correction from switch to switch. In a secured frame relay network the data will be encapsulated as depicted in Figure 4-7. An example is given where an order file (time tagged telecommand TTTC) for EO spacecraft 2 is relayed by spacecraft 1 via ISL. In this example spacecraft 1 acts like a secured gateway. The TTTC file is first encrypted with the key of the destination spacecraft SC 2 and than encrypted with the key of the relaying spacecraft SC 1. SC 1 decrypts the ISL packet with its key shared with the ground station and relays it to SC 2. SC 2 decrypts the TTTC by use of its key shared with the ground station.

Another approach is the use of individually agreed session keys between the relaying nodes. The approaches differ in terms of the implementation effort (hard- and software) and will be analyzed during phase 2 (countermeasures) and phase 3 (cost-/benefit analysis) of the study.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 42 of 58


GatewayGateway

(Decrypt packet and relay viaISL to spacecraft 2)

SC 1

SC 2

Time Tagged Telecommand (TTTC)

(Decrypt ISL packet)

ISL packet for spacecraft 2encrypted with key for spacecraft 1


encrypted with key for spacecraft 2


for spacecraft 2

ISL packet for spacecraft 2encrypted with key for spacecraft 1



Time Tagged Telecommand (TTTC)for spacecraft 2




Time Tagged Telecommand (TTTC)encrypted with key for spacecraft 2


Time Tagged Telecommand (TTTC)TTTC encryption

with key for SC2

ISL packet

encryption withkey for SC1

Figure 4-7: Secured TTTC ISL transmission via frame relay

4.5.1.2 IF Transparent

In case of IF transparent ISL modes the packets are relayed without any visible changes to either the message or tracing data. In principle the relaying node acts either as a transparent bridge between the space link and the space network or as a simple repeater within the space network. Compared to the secured frame relay approach given in Figure 4-7 IF transparent relaying will result in a lower implementation and computation effort and lower transmission delays. No decryption or re-encryption has to be performed by the relaying nodes and the responsibility for security is deferred to the endpoints or higher protocol layers respectively. The IF transparent mode will enable attacks like flooding which may result in denial of service on the other hand. Analysis of advantages and disadvantages of this mode compared to a frame relay like approach will be performed during the following phases of the study.

4.5.2 Space Link

One or more space links are used to connect the spacecraft to the ground station. A TM/TC link is always used to operate the spacecraft and to connect to its On-Board-Data-Handling (OBDH) unit. The payload can be connected via a separated uplink connection (e.g. the feeder link for television satellites) and a payload downlink. The payload link can also be used for in-band telecommands. Its nature (uni-/ bi-directional or broadcast) depends on the mission type, e.g. broadcast for television, bi-directional for telecom applications and unidirectional for science missions.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 43 of 58


4.5.3 Ground Network

The ground network consists of different modules that may be at separated locations or operated by different stakeholders. The operational control center (OCC) is responsible for the proper operation of the spacecraft (including system TM/TC, flight dynamics and mission planning) and the payload management, which includes the conversion of order files into TC sequences.

Payload processing and archiving may be performed either by a special node that also may be responsible for the distribution of data to legitimated users or it can be performed by the users themselves if they possess the payload processing equipment (e.g. television, navigation, telephony).

External data and services may be reference data, for example, GPS/EO instrument calibration or similar data from other spacecraft systems. This data may be offered by the provider between contacts to a certain spacecraft.

4.6 Security Associations Within the system architecture the endpoints of a service (provider and user) will form a security association. Such a service may be e.g. a space link extension service, a data delivery service between a user and the provider or an upload of an order file via ISL. The security requirements defined for each association are mission specific. From point of view of the reference system architecture an envelope is defined between the endpoints of a security association which encapsulates all processing, formatting, acquisition and delivery/forwarding of data between the endpoints. This allows for the abstract view to the system which is required for the reference system architecture. During the tailoring process, appropriate security requirements will be chosen, to achieve a chosen level of security for the service. Appropriate countermeasures to be placed within the envelope around a service will provide the required security services (Figure 4-8). Countermeasures will be analyzed within phase 2 of this project.

Data

forwarding

Processing

& formatting

Data

acquisition

Provider

Data

delivery

De-formatting

& processing

Data

acquisition

User

Envelope

Security Services:

� authentication� availability

� data confidentiality� data integrity� non-repudiation

� access control

File: E-2-E-Envelope.vsd Figure 4-8: Envelope for an End-to-End service

This approach eases the definition of appropriate (security-) protocols to be used for the reliable transport of service data units between the endpoints (point-to-point, point-to-multipoint). Another benefit will be the identification of nodes which are intermediate nodes between different security associations. The security model results out of the identification of the security associations.

To facilitate the identification of relevant requirements for a single link or system module, the end-to-end links and services have to be identified. End-to-end services may either involve multiple links and intermediate nodes or only two nodes and the communication link in between (which is equivalent to link-by-link).





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 44 of 58


4.6.1 SLE Transfer Service Associations in the Ground Segment

For space link extension services, security associations will be established between the provider and the user of the service. The data routing for services is dependent on the mission type. Possible associations for SLE services are listed below:

Return SLE services (TM):

o Return All Frames (R-AF). Provides a complete set of TM frames from a single space link symbol stream to spacecraft operators and other users who have a need all the frames.

o Routing of TM frames from participating ground stations to the operational control center

o Routing of TM frames from participating ground stations to users

o Routing of TM frames from participating ground stations to R-CF service providers

o Return Channel Frames (R-CF). Provides Master Channel (MC) or specific Virtual Channels (VC) extracted from a particular R-AF channel, as specified by the user.

o Routing of individual virtual channels from participating ground stations to the operational control center

o Routing of individual virtual channels from participating ground stations to users

o Routing of individual virtual channels from participating ground stations to payload operations service

o Routing of individual virtual channels from participating ground stations to service providers

o Routing of channel frames from CF service provider to packet service provider

o Return Secondary Frame Header (R-FSH). Provides MC or VC Frame Secondary Headers (FSH) extracted from an R-AF channel, as specified by each R-FSH service.

o Return Operational Control Field (R-OCF). Provides MC or VC Operational Control Fields (OCF) extracted from an R-AF channel, as specified by each R-OCF service

o Return Space Packet (R-SP). Enables single users to receive packets with selected Application Process Identifiers (APID) from one spacecraft VC.

o Routing of TM packets from packet service provider to user

o Return Insert (R-Insert) and Return Bitstream (R-Bitstream). These are Advanced Orbiting Systems (AOS) services not yet defined by CCSDS.

Forward SLE services (TC):

o Forward Space Packets (F-SP). Enables users to provide packets for uplink to a spacecraft without needing to co-ordinate with others users of the spacecraft.

o Routing of payload TC packets from payload operations service to the F-SP service provider

o Routing of TC packets from user to the VC and packet service provider

o Forward Telecommand Virtual Channel Access (F-TCVCA). Enables users to provide complete virtual channels.

o Routing of individual virtual TC channels from users to operational control center and/or payload operations service

o Forward Telecommand Frames (F-TCF). Enables users to supply TC frames to be transformed to Command Link Transmission Units.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 45 of 58


o Routing of TC frames from VC and packet service provider to TC frames service provider

o Forward Command Link Transmission Unit (F-CLTU). Enables users to provide CLTUs for uplink to spacecraft.

o Routing of CLTUs from an operational control center (or other users) to participating ground stations

o Routing of CLTUs from the user to the F-CLTU service provider

4.6.2 Spacecraft Control Service

The envelopes listed below are representing the basic visible security associations. For instance, a scenario whereby a TC is sent by a science experimenter (user) but validated and actually sent by the OCC is represented by two security associations: a first one between the science experimenter and the OCC and a second one between the OCC and the destination (spacecraft). In case of a secured (encrypted) communication the TC from the science experimenter must be decrypted to be validated by the OCC which acts as a gateway in this case. After successfully validation of the TC the OCC will have to re-encrypt it by use of a key shared with the destination.

4.6.2.1 Envelope SCS1

The security association between MCC and spacecraft encapsulates the space link TC and TM transmission for spacecraft operation and control.

Unit Name

M4a (Mission Control)

M3 Modules

M1a (Avionics)

L1 a/b Links

L8 a/b





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 46 of 58



The security association between MCC and spacecraft encapsulates the space link TC and TM transmission for spacecraft operation and control via ISL.

Unit Name

M4a (Mission Control)

M3

M1a

M1c

M2c

Modules

M1an (Avionics)

L1 a/b

L3 a/b

L7 a/b Links

L8 a/b


The security association between another ground station and spacecraft (cross support) encapsulates the space link TC and TM transmission for spacecraft operation and control.

Unit Name

M4an (Mission Control)

M6a

M4c

M4a

M3

Modules

M1a (Avionics)

L1 a/b

L8 a/b

L11 a/b Links

L15 a/b





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 47 of 58



The security association between another ground station and spacecraft (cross support) encapsulates the space link TC and TM transmission for spacecraft operation and control via ISL.

Unit Name

M4an (Mission Control)

M6a

M4c

M4a

M3

M1a

M1c

M2c

Modules

M1an (Avionics)

L15 a/b

L11 a/b

L8 a/b

L1 a/b

L3 a/b

Links

L7 a/b





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 48 of 58


4.6.3 Payload Control and Delivery Service

In this section the basic payload control and delivery security associations are listed. Additional associations resulting from possibilities like cross support via ISL and the latter in case of operating the payload via the avionics unit of a spacecraft. To adhere to the example given in chapter 4.6.2 the security associations will be PCDS8 and PCDS1 (or PCDS5). The spacecraft’s payload is not accessed directly by the science experimenter.

4.6.3.1 Envelope PCDS1

The security association between FOS payload operations center and the payload encapsulates the space link TC and TM transmission for payload operation and control.

Unit Name

M4b (Payload Operations)

M3a Modules

M1b (Payload)

L2 a/b Links

L9 a/b


The security association between FOS payload operations center and the payload encapsulates the space link TC and TM transmission for payload operation and control via ISL.

Unit Name


M3a

M1b

M1c

M2c

Modules

M1bn (Payload)

L4n a/b

L6 a/b

L4 a/b

L2 a/b

Links

L9a/b





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 49 of 58



The security association between FOS payload operations center and the payload encapsulates the space link TC and TM transmission for payload operation and control in case of operating the payload via the avionics unit (no separate payload TMTC link).

Unit Name


M4a

M3

M1a

Modules

M1b (Payload)

L5 a/b

L1 a/b

L8 a/b Links

L17 a/b


The security association between FOS payload operations center and the payload encapsulates the space link TC and TM transmission for payload operation and control via ISL in case of operating the payload via the avionics unit (no separate payload TMTC link).

Unit Name


M4a

M3

M1a

M1c

M2c

M1an

Modules

M1bn (Payload)

L3n a/b

L8 a/b

L6 a/b

L3 a/b

L8 a/b

Links

L17 a/b





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 50 of 58



The security association between another FOS payload operations center and the payload (cross support) encapsulates the space link TC and TM transmission for payload operation and control.

Unit Name

M4bn (Payload Operations)

M6a

M4c

M4b

M3a

Modules

M1b (Payload)

L2 a/b

L9 a/b

L12 a/b

L16 a/b

Links

L12n a/b

4.6.4 Envelope PCDS6

The security association between the payload management POS center and the payload (cross support) encapsulates the space link TC and TM transmission for payload operation and control.

Unit Name

M5a (Payload Management POS)

M5b

M4c

M4b

M3a

Modules

M1b (Payload)

L2 a/b

L9 a/b

L12 a/b

L13 a/b

Links

L14n a/b





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 51 of 58



The security association between the service provider (PDGS) and the user encompasses the TC and TM links for payload operation and control through service provider.

Unit Name


M5b

M7b Modules

M7a (Payload Management)

L14 a/b

L18 a/b Links

L20 a/b


The security association between the user and the flight operations segment encompasses the TC and TM links for payload operation and control through the flight operations segment.

Unit Name


M4c

M6a or M5b

M7b

Modules


L12 a/b

L16 a/b or L13 a/b

L21 a/b or L18 a/b Links

L20 a/b





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 52 of 58


4.6.7 Envelope PCDS9*

The security association directly between the user and the payload encompasses the TC and TM links for payload operation and control through the space links.

Unit Name

Modules M1b (Payload)

M3a


Links L2 a/b

L19 a/b

4.6.8 Envelope PCDS10*

The security association directly between the service provider (PDGS) and the payload encompasses the TC and TM links for payload operation and control through the space links.

Unit Name

M1b (Payload)

M3a Modules


L2 a/b Links

L10 a/b

Note: * marked envelopes are theoretical links at this time. Future missions may allow service providers and users to directly control their own payloads, but this function is not currently used.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 53 of 58


4.7 Link and Module Characteristics The reference system architecture will be tailored to the scenario used for a specific mission. To facilitate the identification of relevant requirements for a link or system module, the end-to-end links and services have to be identified first. This will be described more in detail within the tailoring guidelines. This chapter gives an idea of how this could be achieved.

First we will eliminate all links which are dispensable for a mission. An example is given in Table 4-3:

Navigation Communication EO Science Deep Space Manned SF

L1a X X X X X X

L1b X X X X X X

L2a X X X X

L2b X X X X X

L3a X X X X

…

Table 4-3: Example for identification of relevant links

Depending on the mission type, we will have end-to-end services over the corresponding links between

o Operator ⇔ spacecraft

o Service provider ⇔ user

o User ⇔ payload

o Service provider ⇔ payload

o Operator ⇔ payload

o etc.

More than a single link can be involved in the connection used to realize an end-to-end service e.g. between user and operator or user and payload. Intermediate links of an End-to-End service can be marked each with a color as denoted in Table 4-4.

Furthermore each link can be characterized by delay and availability. Delay can be classified as

o Negligible (e.g. ground network)

o Low (e.g. LEO)

o Moderate (e.g. GEO)

o High (e.g. Deep Space),

the availability of a link may be classified as

o Reliable (e.g. Ethernet)

o Moderate (e.g. wireless network connection between mobile entities)

o Intermittent (e.g. LEO S-band connection)

o Disruptive (e.g. deep space communication)

The characteristics of the links involved in an end-to-end service can be used to determine if DTN capabilities are required for the involved nodes. An example for a deep space mission may look like Table 4-4:





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 54 of 58


End-to-end service Link characteristics

Involved links R-AF F-CLTU Service “X” Delay Availability

Lxa X moderate moderate

Lxb X moderate moderate

Lya X moderate moderate

Lyb X moderate moderate

Lza X high disruptive

Lzb X high disruptive

… X negligible reliable

Table 4-4: Identification of link characteristics

If high delay and/or disruptive connectivity characteristics are identified for a link, it’s endpoints have to be equipped with DTN capabilities. This will impact the design and location of security services. If e.g. a GEO relay spacecraft is designed to act as a gateway to a deep space network and DTN capabilities are required, end-to-end security service between the payload of the deep space probe and the user can be realized only at the bundle layer.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 55 of 58


A ANNEX: DELAY TOLERANT NETWORKS

The reference system architecture consists of the nodes and links depicted in Figure 4-6. To adapt this architecture to all mission scenarios, additional parameters are needed to characterize the communication links, namely in the space link and space network domain: delay and availability. The DTN overview below is based on [RD 4] and [RD 7].

In general, each network is adapted to a particular communication region where communication characteristics are relatively homogeneous. The boundaries between regions are defined by such things as link delay, link connectivity, data-rate asymmetry, error rates, addressing and reliability mechanisms, quality-of-service provisions, and trust boundaries. Unlike the Internet, wireless networks used for deep space or interplanetary communication characteristically have long and variable delays, arbitrarily long periods of link disconnection, high error rates, and large bi-directional data-rate asymmetries. The DTN architecture [RD 4] describes delay-tolerant and disruption-tolerant networks as an evolution of the architecture. It was originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration.

IP

LINK 2

PHY 2

APPLICATION

TCP

IP

LINK 1

PHY 1

File: TCP_IP_Gateway.vsd

LINK 1

PHY 1

IP

LINK 3

PHY 3

LINK 2

PHY 2

APPLICATION

TCP

IP

LINK 3

PHY 3

Source Destination

Layer:

Application

Transport

Network

Link

Physical

Host Router HostRouter Figure 4-9: Standard TCP/IP gateway architecture [RD 7]

An example for an Internet (TCP/IP-based) architecture with two routers and different physical layers is depicted in Figure 4-9. Communication on the Internet is based on packet switching. Packets are pieces of a complete block of user data that travels independently from source to destination through a network of links connected by routers. IP packets contain both user application data (the payload part) and a header (the control part). The header contains a destination address and other information that determines how the packet is switched from one router to another. The packets in a given message may arrive out of order, but the destination’s transport mechanism reassembles them in the correct order.

DTNs support interoperability of regional networks by accommodating long delays between and within regional networks, and by translating between regional network communication characteristics. In providing these functions, DTNs accommodate the mobility and limited power of evolving wireless communication devices.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 56 of 58


Many evolving and potential networks do not conform to the Internet’s underlying assumptions. These networks are characterized by:

o Intermittent Connectivity: If there is no end-to-end path between source and destination (network partitioning), end-to-end communication using the TCP/IP protocols does not work. Other protocols are required.

o Long or Variable Delay: In addition to intermittent connectivity, long propagation delays between nodes and variable queuing delays at nodes contribute to end-to-end path delays that can defeat Internet protocols and applications that rely on quick return of acknowledgements or data.

o Asymmetric Data Rates: The Internet supports moderate asymmetries of bi-directional data rate for users with cable TV or asymmetric DSL access. However, if asymmetries are large, they defeat conversational protocols.

o High Error Rates: Bit errors on links require correction (which requires more bits and more processing) or retransmission of the entire packet (which results in more network traffic). For a given link-error rate, fewer retransmissions are needed for hop-by-hop than for end-to-end retransmission (linear increase vs. exponential increase, per hop).

DTNs overcome the problems associated with intermittent connectivity, long or variable delay, asymmetric data rates, and high error rates by using store-and-forward message switching.

DTN routers need persistent storage for their queues for one or more of the following reasons:

o A communication link to the next hop may not be available for a long time.

o One node in a communicating pair may send or receive data much faster or more reliably than the other node.

o A message, once transmitted, may need to be retransmitted if an error occurs at an upstream (toward the destination) node or link, or if an upstream node declines acceptance of a forwarded message.

By moving whole messages (or fragments thereof) in a single transfer, the message-switching technique provides network nodes with immediate knowledge of the size of messages, and therefore the requirements for intermediate storage space and retransmission bandwidth.

When communicating nodes are in motion, links can be obstructed by intervening bodies. When nodes must conserve power or preserve secrecy, links are shut down. These events cause intermittent connectivity. When no path exists to connect a source with a destination, a network partition is said to occur. On the Internet, intermittent connectivity causes loss of data. Packets that can-not be immediately forwarded are usually dropped (discarded), and TCP may retransmit them with slower retransmission timing. If packet-dropping is too severe, TCP eventually ends the session, which can cause applications to fail.

The DTN architecture implements store-and-forward message switching by overlaying a new protocol layer - called the bundle layer - on top of heterogeneous region-specific lower layers. The bundle layer ties together the region-specific lower layers so that application programs can communicate across multiple regions.

Bundles are also called messages (as in message-switched). The bundle layer stores and forwards entire bundles (or bundle fragments) between nodes. A single bundle-layer protocol is used across all networks (regions) that make up a DTN. By contrast, the layers below the bundle layer (the transport layer and below) are chosen for their appropriateness to the communication environment of each region. Figure 4-10 illustrates the bundle overlay and compares Internet protocol layers with DTN protocol layers:





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 57 of 58


File: DTN_Bundle_Layer.vsd

common across

all DTN regions

Internet Layers DTN Layers

Application

Bundle

Application

Transport (TCP)

Network (IP)

Link

Physical

Transport

Network

Link

Physical

specific to each

DTN region

Figure 4-10: Additional Bundle Layer for Store-and-Forward message switching [RD 7]

Bundle layers communicate between themselves using simple sessions with minimal or no round-trips. Any acknowledgement from the receiving node is optional, depending on the class of service selected.

The lower-layer protocols that support bundle layer exchanges may, of course, be conversational like TCP. But on intermittently connected links with long delays, non-conversational or minimally-conversational lower-layer protocols can be implemented.

DTN routers and gateways - nodes that can forward bundles within or between DTN regions, respectively - terminate transport protocols at the bundle layer. The bundle layers thus act as surrogates for end-to-end sources and destinations. The side-effect is that conversational lower-layer protocols of low-delay regions are isolated at the bundle layer from long delays in other regions of the end-to-end path.

DTNs support node-to-node retransmission of lost or corrupt data at both the transport layer and the bundle layer. However, because no single transport-layer protocol (the primary means of reliable transfer) operates end-to-end across a DTN, end-to-end reliability can only be implemented at the bundle layer. A bundle custodian must store a bundle until either another node accepts custody, or expiration of the bundle’s time-to-live, which is intended to be much longer than a custodian’s time-to-acknowledge. However, the time-to-acknowledge should be large enough to give the underlying transport protocols every opportunity to complete reliable transmission. Custody transfers do not provide guaranteed end-to-end reliability. This can only be done if a source requests both custody transfer and return receipt. In that case, the source must retain a copy of the bundle until receiving a return receipt, and it will retransmit if it does not receive the return receipt. The bundle layer uses reliable transport-layer protocols together with custody transfers to move points of retransmission progressively forward toward the destination (Figure 4-11).

In this way DTNs will support the realization of end-to-end services across regions with intermittent links and variable delays which will be characteristic for deep space and interplanetary missions. The DTN approach can be generalized for all networks which are considered within this study. If reliable links are used (e.g. in the ground network domain), the characteristic parameters delay and availability of that link can be set appropriate and persistent storage capabilities can be realized wherever a network node has to act as a gateway to a network region with different capabilities.





ESA Doc. No.: D1.1

Issue: 3.0 Date: 2006-05-08

Page: 58 of 58


potential delaypotential delay potential delaypotential delay

File: Custody_Tranfer.vsd

Layers:

Application

Transport

Network

Link

Physical

Bundle

Source Destination

1

CT CT CT CT

32

Persistent storage

CT Custody tranfer capability

Custody transfer of bundle

Custody transfer acknowledgement

Custodian Custodian

Figure 4-11: Custody transfer for lossy links [RD 7]

The use of DTNs will add some special security requirements to the system. As an overlay protocol, the bundle protocol is possibly an easier target for attackers. If it is possible to insert new bundles (messages) at lower-layer "hops", then DTN nodes must be capable of countering such insertions by detecting and deleting such spurious bundles where possible. The use of public key cryptosystems, verification of the source application’s signature and Class-of-Service (CoS) rights by use of stored copies of adjacent-user certificates and certificate-authority (CA) public keys may be one way to overcome this vulnerability. Certificates and keys can also be obtained as needed, and access-control lists can be used to identify valid signatures. This leads to requirements for a well designed security infrastructure and is discussed later. Also, it is possible to take advantage of lower layer security services. Different protocols may be used along a pass of a bundle, which is not visible (or controllable) from the DTN layer; therefore, administrative coordination is required to keep all services communicating with each other.

In [RD 5] the threats and special requirements of DTNs have been outlined. [RD 6] is a draft recommendation for a DTN security protocol specification. The mechanisms (use of the proposed cipher suites, bundle protocol agents, security policies etc.) described in [RD 6] can be used to realize secure end-to-end services at the bundle layer but will add a significant overhead, at least to the system S/W and data in transit. Additional headers are needed to securely store and forward message switching functions and fragmentation of messages (e.g. the custody related -, bundle authentication -, bundle fragment - and payload security header). The use of DTN capabilities should be limited either to gateways which connect to the space network domain or to system elements that have to deal with delayed links.