[Sls-slp] Does SDLS apply to USLP truncated transfer frame ?

[Moury Gilles]

Dear Greg,

Please find hereafter the summary of our discussion within the SDLS WG regarding the applicability of SDLS to USLP truncated transfer frame. Feel free to complement with your own notes/remarks:


-          USLP truncated transfer frames are meant to be used for sending short commands (as short as 2 octets) to the spacecraft. Those short commands are typically hardware commands (bypassing OBSW) or immediate commands (triggering on-board procedures/sequences). Those commands are not necessarily emergency commands. They can be used during normal operations also. They are critical commands. Therefore, it is desirable that they can benefit from SDLS security protection;


-          SDLS minimum overhead (corresponding to TC baseline mode) is : Security Header (6 octets), Security Trailer – MAC (16 octets). This minimum overhead means that SDLS protection as is , is only applicable to truncated frames fitting into 1 LDPC(256,512) codeblock (32 octet) : Frame header (5 octets), Sec Hdr (6 oct), MAC (16 oct), leaving 5 octet maximum for the command itself. If BCH is used on the link, using SDLS would require several codeblocks per frame (at least 5). This can be acceptable, possibly even for emergency commands (e.g. tumbling spacecraft);



-          Reducing the overhead of SDLS would imply reducing the level of security provided by the protocol and taking into account additional constraints (number of key invocations, number of forged attempts, …). For example, MAC could be truncated to 64-bit (minimum length with AES) and the Sec Hdr could be reduced to 4 octet (with a reduced anti-replay counter). Nevertheless, the WG concluded that it was not advisable to design an SDLS “reduced overhead” baseline mode for this USLP truncated frame mode, because recommending a reduced security mode for critical commands is not appropriate for a standard.



-          Clear mode implementation is always an option for a given mission, although not recommended security-wise, whenever operational safety or link constraints requires it.


Best regards,
Gilles

Gilles MOURY
CNES Toulouse
De : SLS-SLP <sls-slp-bounces at mailman.ccsds.org> De la part de Moury Gilles
Envoyé : mardi 27 octobre 2020 12:13
À : Kazz, Greg J (US 312B) <greg.j.kazz at jpl.nasa.gov>
Cc : sls-sea-dls at mailman.ccsds.org; sls-slp at mailman.ccsds.org
Objet : Re: [Sls-slp] Does SDLS apply to USLP truncated transfer frame ?

Dear Greg,

Sorry for not being able to join the SLP meeting yesterday but I had another meeting at the same time that lasted more than scheduled.

For the issue you raised concerning the applicability of SDLS to truncated USLP frames, I will add it to the discussion of the SDLS WG on Wednesday. My feeling is that, also security would be needed on those emergency commands, the fact that minimum length for Security Header is something like 6 octets (TC baseline mode for SDLS) and minimum length for Security Trailer is something like 16 octets (TC baseline mode for SDLS) would make it :

-          impossible to fit a truncated USLP Transfer Frame into a 7 octets BCH codeblock (truncated USLP Transfer Frame header is 5 octets leaving only 2 octets for data field)

-          only possible to fit a truncated USLP Transfer Frame into a 32 octets LDPC codeblock (leaving only 27 octets for data field – 22 octets being taken by Security and Trailer)
We will discuss it further with the SDLS WG. I do not know whether shorter Security Header and Trailer can be envisioned for those emergency commands carried in truncated USLP Transfer Frames.

See you (virtually) this afternoon for the SLP webmeeting. I will provide input for the TM and AOS pink sheets regarding MCID/VCID validation in order to align TM/AOS with TC/USLP regarding this validation.

Best regards,

Gilles

Gilles MOURY
CNES Toulouse
De : Kazz, Greg J (US 312B) <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Envoyé : lundi 26 octobre 2020 18:45
À : Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>; sls-sdls at mailman.ccsds.org<mailto:sls-sdls at mailman.ccsds.org>
Cc : Kazz, Greg J (US 312B) via SLS-SLP <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>
Objet : Does SDLS apply to USLP truncated transfer frame ?

Dear Gilles and SLDS WG,

SLP WG has a question regarding the application of the SDLS protocol to truncated USLP Transfer Frames.
These truncated frames are envisioned for very short length telecommands or forward link Proximity-1 link commanding. This frame type provides backward compatibility with TC hardware commands or immediate commands. These commands are typically 2 octets long. We envision the truncated USLP frame length to be between 8 and 32 octets.
In that context, does it make sense for SDLS header and possibly SDLS trailer to apply to the USLP truncated frame.

The discussion of the proposed non-use of SDLS for truncated USLP frames is mentioned in Chapter 6, specifically  in Section 6.3.2. The definition of the truncated USLP frame is in Annex G of the attached draft document

The SLP WG did not think SDLS should be applicable to truncated USLP frames, but we would like your opinion on this matter.

Best regards,
Greg Kazz
Chair SLP WG

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org<mailto:sls-slp-bounces at mailman.ccsds.org>> on behalf of Matthew Cosby <Matt.Cosby at Goonhilly.org<mailto:Matt.Cosby at Goonhilly.org>>
Date: Monday, October 26, 2020 at 9:27 AM
To: "sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>
Subject: [EXTERNAL] [Sls-slp] Updated Book

All,

Here is the updated book from the working group today.

Regards, Matt.

Matthew Cosby
Chief Technology Officer
Goonhilly Earth Station Ltd
[cid:image001.jpg at 01D6AD5B.6ADA9F30]


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20201028/40973432/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 26077 bytes
Desc: image001.jpg
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20201028/40973432/attachment-0001.jpg>