fsh/security sls-slp fall2009 (version 4) page 1 security headers + homogeneous approach to fsh and...

FSH/security SLS-SLP fall2009 (version 4)

Security Headers + Homogeneous approach to FSH and Insert Zone in TM/AOS/TC frames: some problems and suggestions

CCSDS SLS-SLP WG, ESTEC October 2009

Marjorie de Lande Long (ESA)[email protected]


Subject:Draft Pink Sheets for TM/AOS/TC frames

This presentation describes some issues in the NASA draft changes in Pink Sheets for:

TM Space Data Link Protocol, CCSDS 132.0-B

AOS Space Data Link Protocol, CCSDS 732.0-B

TC Space Data Link Protocol, CCSDS 232.0-B

NOTE: Pink Sheets for adding an Insert Zone for Proximity-1 (CCSDS 211.0-B) arrived too late to be considered in this technical view of the issues.


Background (1):Changes in the Draft Pink Sheets

The Draft Pink Sheets make changes to fields in TM, AOS and TC Transfer Frames:

Frame Secondary Header (FSH), and

Insert Zone

In this presentation, TM = TM Space Data Link Protocol, andTC = TC Space Data Link Protocol(not a general abbreviation for “telemetry” or “telecommand”)


Background(2):Motivation for the Draft Pink Sheets

The changes to the FSH and Insert Zone are to support:

Security Headers for the Cryptographic Service for CCSDS Data Links, and

a new, dynamic service for latency-intolerant data for Constellation

and more generally:

to harmonize the FSH and Insert Zone definitions across TM, AOS and TC frames.


Background (3):Security Headers and Cryptographic Service

New Cryptographic Service for CCSDS Data Links, in Draft Orange (now White) Books

Security Headers have a common format across TM, AOS and TC Transfer Frames

Service operates within a Master Channel (MC) or a Virtual Channel (VC) (or a MAP for TC)

Security Headers use the format of the FSH currently defined for TM Transfer Frames

Security Headers use a new FSH version number


Contents

Section 1: Summary of the changes in the Draft Pink Sheets

Section 2: Weaknesses for the Security Headers

Section 3: Problems in the harmonization

Section 4: A simpler alternative for Security Headers?

Section 5: Suggestions for the harmonization changes in the Draft Pink Sheets


Section 1: Summary of the changes in the Draft Pink Sheets

This section briefly describes:1.1 FSH and Insert Zone in published Blue Books (2003 & 2006)1.2 FSH and Insert Zone changes contained in the Draft Pink Sheets


1.1 FSH and Insert Zone in Blue Books*

Optional fields for carrying additional data in TM and AOS Transfer Frames:

TM frames have FSH for a Virtual Channel or for a Master Channel

AOS frames have Insert Zone for a Physical Channel

Lengths of the FSH and Insert Zone are fixed, usually for a mission phase

as a result, the length of the Frame Data Field is fixed within a VC

*Published Blue Books, September 2003 and July 2006


1.1 FSH and Insert Zone in Blue Books

Optional fields for carrying additional data in TC Transfer Frames:

None

Notes:

Master Channel (MC): all the frames with the same Spacecraft ID on the Physical Channel

Virtual Channels (VCs) allow multiple users to share a Master Channel

*** TM and AOS frames are fixed length ****** TC frames are variable length ***

FSH is signaled (by flag in TM frame header) and has internal length field, giving maximum length of 64 octets


1.2 Changes in the Draft Pink Sheets: TM/AOS

TM and AOS frames to have FSH for a VC

TM and AOS frames to have Insert Zone for an MC

Introduce option to vary the length of the FSH within a VC

also intended for multiple users of the FSH facility for the VC

Introduce option to follow a Security Header FSH with another FSH (this will probably be removed in future Cryptographic Service drafts)


OCF

OCF

OCF

CRC

CRC

CRC

Frame Data Field

Frame Data Field

Frame Data Field

PrimaryHeader

PrimaryHeader

PrimaryHeader

FSH

FSHInsertZone

InsertZone

optional F ram e Secondary H eader for a VC or M C

flag

flag

optional Insert Zone for the Physica l C hannel

TM Transfer Frame (September 2003 Blue Book)

AOS Transfer Frame (July 2006 Blue Book)

TM or AOS Transfer Frame in Draft Pink Sheets

for a VCfor an M C



OCF

OCF

CRC

CRC

Frame Data Field

Frame Data Field

PrimaryHeader

PrimaryHeader

for two users of sam e VC

.

Draft Pink Sheets:Variable-length Frame Secondary Header within a VC


FSH

FSH



1.2 Changes in the Draft Pink Sheets: TC

TC frames to have variable-length FSH for a VC

TC frames to have fixed-length Insert Zone for an MC

Current drafts for the Cryptographic Service show the Security Header FSH follows the TC Segment Header (which is inside the Frame Data Field)

In Draft Pink Sheets for TC, Insert Zone and FSH follow the TC Segment Header, which is now outside the Frame Data Field.


CRC

CRC

CRC

Frame Data Field

Frame Data Field

Frame Data Field

PrimaryHeader

PrimaryHeader

PrimaryHeader FSH

securityheader

FSH

InsertZone

TC Segm ent H eader, used on VC s w ith M APs or segm entation

TC Transfer Frame (September 2003 Blue Book)

TC Transfer Frame in Cryptographic Service draft

TC Transfer Frame in Draft Pink Sheets

for a VCfor an M C

1.2 Changes in the Draft Pink Sheets: TC


Section 2: Weaknesses for the Security Headers

This section describes issues for:2.1 Encryption of the Insert Zone2.2 Restrictions of the FSH format


OCF

CRC

Frame Data FieldPrimaryHeader

securityFSH

InsertZone

AOS Transfer Frame in Cryptographic Service draft (F igure 3-4)

2.1 Encryption of Insert Zone - Insert Zone is a Master Channel field- Insert Zone encryption can vary between VCs-

Next draft is expected to place Insert Zone before the Security Header

contro ls encryption for a VC or M C

this part of the fram e is encrypted


2.2 Restrictions of FSH format

The FSH format is an existing format, defined and “owned” by the TM Space Data Link Protocol

FSH format was designed more than 20 years ago as a general purpose option for telemetry frames

Maximum length of an FSH is 64 octets

By defining the Security Header as an FSH, the Cryptographic Service is restricting its options for the future. For example, the maximum length could not be increased beyond 64 octets without changing the TM Space Data Link Protocol specification.


Section 3: Problems in the harmonization

This section describes issues for:3.1 Position of the Insert Zone (TM & AOS) 3.2 Variable-length FSH within a VC (TM & AOS) 3.3 Insert Zone and FSH for TC frames


3.1 Position of the Insert Zone

Problem:

Figure 3-4 of Cryptographic Service draft shows FSH before the Insert Zone

As a result, the position of the Insert Zone can vary for frames on different VCs

No problem if the Insert Zone is before the FSH:

Next draft expected to show Insert Zone before FSH

Draft Pink Sheets for TM and AOS show Insert Zone before FSH


OCF

OCF

CRC

CRC

Frame Data Field

Frame Data Field

PrimaryHeader

PrimaryHeader

for two users of sam e VC

.


FSH

FSH

3.2 Variable-length FSH within a VC (TM or AOS):- Length of Frame Data Field is not constant for the VC- Position of - Incompatible with VCA service definition (User Defined Data)- Difficult for m ost existing systems (e.g. for Packet services)

Fram e Data Field is not constant for the VC


3.2 Variable-length FSH within a VC (TM or AOS)

3.2.1 Incompatible with the Virtual Channel Access (VCA) service definition:

For VCA service, the user supplies Service Data Units (SDUs) of User Defined Data.

SDUs have the same length as the Frame Data Field.

132.0-B(TM) says the SDUs “are fixed-length, octet-aligned data units…Their length is established by management.” Same wording in 732.0-B(AOS).

VCA service with variable-length SDUs is possible but carries costs: less convenient for users and could be difficult in some existing systems.



3.2.2 Packet services need to know the length and position of the Frame Data Field. If these are not fixed, then:

(sending end) Packet service processing for a frame would have to be later than the decision on the FSH contents for that frame.

(receiving end) Packet services would need to look inside the FSH.

- New systems could be designed for these constraints. - Changes to existing systems could be difficult.



3.2.3 Is this needed to support Security Headers?

Next draft of Cryptographic Service is expected to show the fixed-length Insert Zone used for Security Headers on a Master Channel.

If Security Headers can be carried in a fixed-length Insert Zone, then they should be able to be carried in a fixed-length FSH within a VC.

Length of the Security Header depends on the Security Association, which is static for some time. Padding length will not change if the data field length is fixed.



3.2.4 Constellation:

As shown in the Constellation presentation, the plan calls for the introduction of variable-length FSH within VCs, to carry latency-intolerant data.

Constellation is only using AOS:

AOS on downlink and on uplink

so Constellation does not need variable-length FSH within VCs on TM or TC.

Latency-intolerant data is not a new problem. What solutions have been used by other missions?



3.2.5 Is this needed for harmonization?

This is not a current feature of TM, AOS or TC, so in that sense it goes beyond harmonization.

Multiple sources with the same length FSH data can co-operate to present themselves to the existing VC_FSH service as a single user (for current TM and for possible harmonized AOS).


3.3 Insert Zone and FSH for TC frames(as data transfer services, not for security)

3.3.1 Poor service

On a TM link, frames are being generated constantly, to occupy the synchronous channel. The FSH provides a (more-or-less) regular, predictable service for a VC, depending on the VC multiplexing.

On a TC link, frames are generated irregularly. If there is no data for the Frame Data Fields of a MAP/VC, there will be no frames on that MAP/VC, so the FSH data will be left waiting.


3.3 Insert Zone and FSH for TC frames (as data transfer services, not for security)

3.3.2 TC offers better alternatives to FSH or Insert Zone

Variable-length TC frames can carry short or long data items (packets or user defined data).

Some MAPs can be reserved for urgent data. Other MAPs can be allocated to different classes of data.

MAP multiplexing scheme can give priority to the urgent data.

Similarly for VCs, in systems which favour VC multiplexing rather than MAP multiplexing.



3.3.3 Position of the Frame Data Field

Currently, the starting position of the Frame Data Field is the same for all TC transfer frames. New Insert Zone and FSH fields would cause changes for handling of Packets, Segments and User Defined Data.

- New systems could be designed for these constraints. - Changes to some existing systems could be difficult.



3.3.4 Interactions with COP-1

How would the new FSH and Insert Zone services interact with COP-1? For example:

Frame contents (data field, FSH and Insert Zone) would need to be determined before the frame entered FOP-1. But FOP-1 operates inside a VC, so order could not be preserved for the Insert Zone data.

What happens to the FSH or Insert Zone for a BC-frame (COP-1 directive)?

This would need careful investigation before the new services could be specified.


FOP-1 forVC 6

VC mux

Partial framesbefore FOP-1

Frames onthe MC

FOP-1 forVC 10

Sequence of Insert Zone data units for the MC

Insert Zone Service: interaction with FOP-1

1

1

3

2

4

23456

?

?


Section 4: A simpler alternative for Security Headers?


4. A simpler alternative for Security Headers?

1. As proposed, use a format for the Security Header that looks like the format of the FSH. But avoid the name “FSH”. Use the name “Security Header” for the format. Perhaps the Cryptographic Service would benefit from changes to the details of the format.

2. Use the name “Security Header” for the headers themselves whenever they appear in frames.

3. The Cryptography Service for a VC will be managed at both ends of the link. It does not need an in-line flag such as the Frame Secondary Header Flag.[“managed” = known to the sender and receiver]



4. In a TM or AOS frame, place the Security Header immediately before the Frame Data Field.

5. In a TM or AOS frame, the length of the Security Header should be fixed within a VC. (Looks possible – to be confirmed.)

6. In a TC frame, place the Security Header after the Segment Header as proposed.


OCF

OCF

CRC

CRC

Frame Data Field

Frame Data FieldSecurityHeader

PrimaryHeader

PrimaryHeader

FSH

FSH

TM Transfer Frame (September 2003 Blue Book)

TM Transfer Frame with Security Header

Simpler alternative for Security Header in TM Frames:- on systems that do not support the Cryptographic Service, the handling of fields outside the Frame Data Field can continue unchanged


OCF

OCF

CRC

CRC

Frame Data Field

Frame Data FieldSecurityHeader

PrimaryHeader

PrimaryHeader

AOS Transfer Frame (July 2006 Blue Book)

AOS Transfer Frame with Security Header

Simpler alternative for Security Header in AOS Frames:- on systems that do not support the Cryptographic Service, the handling of fields outside the Frame Data Field can continue unchanged

InsertZone

InsertZone


CRC

CRC

Frame Data Field

Frame Data Field

PrimaryHeader

PrimaryHeader

SecurityHeader

TC Segm ent H eader, used on VC s w ith M APs or segm entation

TC Transfer Frame (September 2003 Blue Book)

TC Transfer Frame with Security Header

Simpler alternative for Security Header in TC Frames:- on systems that do not support the Cryptographic Service, the handling of fields outside the Frame Data Field can continue unchanged



7. If possible, do not include an option to chain one Security Header to another one or to an FSH. Chaining is expected to be removed from the next Cryptographic Service draft.

8. Consider the addition of the Security Header as a separate task from the FSH /Insert Zone harmonization.


Advantages for the Cryptographic Service

1. It would be easier and quicker to add the Security Header to the TM/AOS/TC Blue Books because there would be fewer changes and fewer unknowns.

2. There would be less impact on support by existing systems and by SLE services.


Advantages for the Cryptographic Service

3. The new Cryptographic Service would “own” the format of the Security Header, without reference to the FSH format, which already belongs to the TM Space Data Link Protocol. So if, for example, future cryptography methods needed a Security Header longer than 64 octets, this could be done: a new version number could be used for a different Security Header format with a longer length field.


Section 5: Suggestions for the harmonization changes in the Draft Pink Sheets


5. Suggestions for the harmonization changes in the Draft Pink Sheets

Consider the FSH / Insert Zone harmonization as a separate task from the addition of Security Headers.

Do not introduce FSH / Insert Zone to TC frames. The harmonization would bring costs and risks but no benefits.

For TM & AOS, limit the harmonization to the basic features, using fixed-length FSH within a VC.

Variable-length FSH within a VC: If this must be added to the AOS standard because of Constellation requirements, then do not add it to TM.

fsh/security sls-slp fall2009 (version 4) page 1 security headers + homogeneous approach to fsh and...

Documents

suggestionsccsds slsslp

zone changes

tm frames

draft pink sheetsthe

draft pink sheetssection

tm space data link protocol

nasa draft changes

draft pink sheetsthis