SDLS impact on TM, AOS, TC
Space Data Link Protocols
Greg Kazz
NASA/JPL
Oct 16/17, 2012
Proposed Pink Sheet Changes
• Add a new requirement to TM, AOS, TC to use SDLS for data link layer
security.
• In TC, augment the frame length definition to include the length of the
Security Header and Security Trailer (if present).
• Include the Security Header and Trailer fields (optional) in the definition of
frame length in AOS and TM. Note: Frame length is mentioned several
times in AOS and TM but never explicitly defined.
• In AOS,TM, TC include the Security Header and Security Trailer as optional
fields in the transfer frame format definitions.
• Reference SDLS for all AOS, TM, TC Security Services provided by SDLS
• Reference SDLS for all AOS, TM, TC protocol entity security functions
provided by SDLS
• Provide a new Security, Patent and SANA Considerations ANNEX A in TM,
TC, AOS
• Add required new Managed Parameters due to SDLS requirement
2
New SDLS Requirement in AOS, TM, TC
• Use SDLS for secure AOS, TM, TC space data links.
• Proposed Requirement formulated as:
– Secured TM Transfer Frame- If Space Data Link Security as defined in
reference [8] is required over the TM Space Data Link, then the CCSDS
Space Data Link Security Protocol (SDLS) [8] shall be used.
NOTE
• Use of the SDLS protocol requires the insertion of a
mandatory Security Header immediately preceding the
Transfer Frame Data Field and an optional Security
Trailer immediately following the Transfer Frame Data
Field. These fields and their placement within the
frame are defined in reference [8].
3
Constraints on SDLS defined in TC
• Frame Length Definition
– In TC, augment the frame length definition to include
the length of the Security Header and Security Trailer
(if present).
• Proposed Formulation:
– The count shall be measured from the first bit of the
Transfer Frame Primary Header to the last bit of the
Frame Error Control Field (if present), or to the last bit
of the Transfer Frame Data Field (if the Frame Error
Control Field is omitted). The count shall include the
sizes of the Space Data Link Security Header and
Security Trailer Fields (if present).
4
Constraints on SDLS defined in AOS
and TM
• No Explicit Frame Length Definition in TM nor AOS
• However, the term, “Frame Length” appears in the text but it is undefined.
– Rationale: Because other constraints typically “define” the frame length i.e.,
channel coding chosen
• Proposal
– In TM and AOS, define frame length to be the sum of the transfer frame fields
present.
• Proposed Formulation: The TM Transfer Frame length is defined as the
sum of the lengths of the following fields (if present): Transfer Frame
Primary Header, Transfer Frame Secondary Header, Space Data Link
Security Header, Transfer Frame Data Field, Space Data Link Security
Trailer, Operational Control Field, Frame Error Control Field. The Transfer
Frame shall be of constant length throughout a specific Mission Phase for
any Virtual Channel or Master Channel on a Physical Channel.
5
AOS, TM, TC Protocol Formats
• In AOS,TM, TC include the Security Header and Security Trailer as optional
fields in the transfer frame format definitions.
Proposed Formulation:
• A TM or AOS Transfer Frame shall encompass the major fields, positioned
contiguously, in the following sequence:
–
–
–
–
–
–
–
Transfer Frame Primary Header (6 octets, mandatory);
Transfer Frame Secondary Header (up to 64 octets, optional);
Space Data Link Security Header (up to 64 octets, optional);
Transfer Frame Data Field (integral number of octets, mandatory);
Space Data Link Security Trailer (variable, optional);
Operational Control Field (4 octets, optional);
Frame Error Control Field (2 octets, optional).
NOTE
• The Space Data Link Security Header and Trailer fields are components of
the Space Data Link Security Protocol [8] and may only apply if a protected
TM or AOS frame is required.
6
References to SDLS
• Strategy is to reference SDLS as much as possible when applicable
and not allow duplication of information in AOS/TM/TC and SDLS
• SDLS Referenced in:
–
–
–
–
–
–
–
–
–
–
Sec. 1.7
2.1.1
Figure 2.1
2.1.2
2.2.3
2.3
2.3.2
4
5
Annex A
References
Architecture
Relationship with OSI Layers
Protocol Features
Summary of Services
Overview of Functions
Internal Organization of Protocol Entity
Protocol Format
Managed parameters
Security Considerations
7
Additional Managed Parameters
• Only one new Managed Parameter proposed
to be added to AOS, TM, TC
– Presence of Space Data Link Security Header
• Value is “Present/Absent”
8
Security, Patent and SANA Considerations
• New Annex A added to AOS, TM, TC providing a
general overview about Security Concerns text
provided by Howie Weiss. It references:
– The Application of CCSDS Protocols to Secure Systems.
Report Concerning Space Data System Standards,
CCSDS 350.0-G-2. Green Book. Issue 2. Washington,
D.C.: CCSDS, January 2006.
– The new requirement in the link layer books to use
SDLS if applicable.
• General Statements added about no Patent nor
SANA considerations
9