1. SDLS impact on TM, AOS, TC Space Data Link Protocols Greg Kazz NASA/JPL Oct 16/17, 2012

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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.7References – 2.1.1Architecture – Figure 2.1 Relationship with OSI Layers – 2.1.2Protocol Features – 2.2.3Summary of Services – 2.3Overview of Functions – 2.3.2Internal Organization of Protocol Entity – 4Protocol Format – 5Managed parameters – Annex ASecurity Considerations 7

8. 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

9. 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