1. FSH/security SLS-SLP fall2009 (version 4) Page 1 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) marjorie@delandelong.com

2. FSH/security SLS-SLP fall2009 (version 4) Page 2 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.

3. FSH/security SLS-SLP fall2009 (version 4) Page 3 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, and TC = TC Space Data Link Protocol (not a general abbreviation for “telemetry” or “telecommand”)

4. FSH/security SLS-SLP fall2009 (version 4) Page 4 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.

5. FSH/security SLS-SLP fall2009 (version 4) Page 5 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

6. FSH/security SLS-SLP fall2009 (version 4) Page 6 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

7. FSH/security SLS-SLP fall2009 (version 4) Page 7 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

8. FSH/security SLS-SLP fall2009 (version 4) Page 8 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

9. FSH/security SLS-SLP fall2009 (version 4) Page 9 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

10. FSH/security SLS-SLP fall2009 (version 4) Page 10 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)

11. FSH/security SLS-SLP fall2009 (version 4) Page 11

12. FSH/security SLS-SLP fall2009 (version 4) Page 12

13. FSH/security SLS-SLP fall2009 (version 4) Page 13 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.

14. FSH/security SLS-SLP fall2009 (version 4) Page 14

15. FSH/security SLS-SLP fall2009 (version 4) Page 15 Section 2: Weaknesses for the Security Headers This section describes issues for: 2.1 Encryption of the Insert Zone 2.2 Restrictions of the FSH format

16. FSH/security SLS-SLP fall2009 (version 4) Page 16

17. FSH/security SLS-SLP fall2009 (version 4) Page 17 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.

18. FSH/security SLS-SLP fall2009 (version 4) Page 18 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

19. FSH/security SLS-SLP fall2009 (version 4) Page 19 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

20. FSH/security SLS-SLP fall2009 (version 4) Page 20

21. FSH/security SLS-SLP fall2009 (version 4) Page 21 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.

22. FSH/security SLS-SLP fall2009 (version 4) Page 22 3.2 Variable-length FSH within a VC (TM or AOS) 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.

23. FSH/security SLS-SLP fall2009 (version 4) Page 23 3.2 Variable-length FSH within a VC (TM or AOS) 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.

24. FSH/security SLS-SLP fall2009 (version 4) Page 24 3.2 Variable-length FSH within a VC (TM or AOS) 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?

25. FSH/security SLS-SLP fall2009 (version 4) Page 25 3.2 Variable-length FSH within a VC (TM or AOS) 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).

26. FSH/security SLS-SLP fall2009 (version 4) Page 26 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.

27. FSH/security SLS-SLP fall2009 (version 4) Page 27 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.

28. FSH/security SLS-SLP fall2009 (version 4) Page 28 3.3 Insert Zone and FSH for TC frames (as data transfer services, not for security) 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.

29. FSH/security SLS-SLP fall2009 (version 4) Page 29 3.3 Insert Zone and FSH for TC frames (as data transfer services, not for security) 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.

30. FSH/security SLS-SLP fall2009 (version 4) Page 30

31. FSH/security SLS-SLP fall2009 (version 4) Page 31 Section 4: A simpler alternative for Security Headers?

32. FSH/security SLS-SLP fall2009 (version 4) Page 32 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]

33. FSH/security SLS-SLP fall2009 (version 4) Page 33 4. A simpler alternative for Security Headers? 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.

34. FSH/security SLS-SLP fall2009 (version 4) Page 34

35. FSH/security SLS-SLP fall2009 (version 4) Page 35

36. FSH/security SLS-SLP fall2009 (version 4) Page 36

37. FSH/security SLS-SLP fall2009 (version 4) Page 37 4. A simpler alternative for Security Headers? 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.

38. FSH/security SLS-SLP fall2009 (version 4) Page 38 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.

39. FSH/security SLS-SLP fall2009 (version 4) Page 39 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.

40. FSH/security SLS-SLP fall2009 (version 4) Page 40 Section 5: Suggestions for the harmonization changes in the Draft Pink Sheets

41. FSH/security SLS-SLP fall2009 (version 4) Page 41 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.