1 / 9

SDLS impact on TM, AOS, TC Space Data Link Protocols

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 .

hector
Download Presentation

SDLS impact on TM, AOS, TC Space Data Link Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 SDLSfor 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

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

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

  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.

  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.

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

  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”

  9. Security, Patent and SANA Considerations • New Annex A added to AOS, TM, TC providing a general overview about Security Concerns text provided by HowieWeiss. 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

More Related