[Sls-sea-dls] [EXTERNAL] RE: CESG-P-2021-04-001 Approval to release CCSDS 355.0-P-1.1, Space Data Link Security Protocol (Pink Sheets, Issue 1.1) for CCSDS Agency review

Shames, Peter M (US 312B) peter.m.shames at jpl.nasa.gov
Tue May 18 00:05:49 UTC 2021


I accept this answer.  Proceed.

Peter


From: Gilles Moury <Gilles.Moury at cnes.fr>
Date: Wednesday, May 12, 2021 at 9:21 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Tom Gannett <thomas.gannett at tgannett.net>, "craig.biggerstaff-1 at nasa.gov" <craig.biggerstaff-1 at nasa.gov>, "sls-sea-dls at mailman.ccsds.org" <sls-sea-dls at mailman.ccsds.org>, Greg Kazz <greg.j.kazz at jpl.nasa.gov>, Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Subject: [EXTERNAL] RE: CESG-P-2021-04-001 Approval to release CCSDS 355.0-P-1.1, Space Data Link Security Protocol (Pink Sheets, Issue 1.1) for CCSDS Agency review


Dear Peter,



Please find hereafter the reasons why the COP Management Service (TC) and the OCF Service (TM, AOS, USLP) are not protected by SDLS:



- SDLS function has to be applied to the transfer frame before the COP function at the sending end, and after the COP at the receiving end (see attached diagram - that should be added to SDLS GB for clarification of the order of processing between the COP and SDLS). The reasons for that ordering are the following :

•                    COP-1, being a go-back-N retransmission protocol, will eventually replay TC frames. SDLS is a function providing anti-replay protection, integrity and confidentiality. Therefore if FOP is applied before SDLS at the sending end, and SDLS before FARM at the receiving end, SDLS at the receiving end will discard all replayed frames by COP-1, thus defeating the COP (and eventually blocking the link).


•                    SDLS at the receiving end checks integrity of TC frames by checking the MAC. The MAC is a very powerful error detecting code (in fact much more powerful than the BCH code). Therefore, SDLS receiving end will discard all TC frames  impacted by transmission errors, if the FARM is applied after SDLS. This has two impacts :

ü    Accountability of transmission errors vs security related events cannot be made : all errors are detected by SDLS and therefore classified as security events

ü    COP-1 will replay those SDLS rejected frames, because the FARM will never see them. Those replayed TC frames will be later rejected as replay by SDLS.



  *   given the mandatory order of processing at the sending end (SDLS before COP) and at the receiving end (COP before SDLS), COP commands cannot be protected since they are generated and extracted respectively after and before SDLS is applied at both end of the link.



  *   for the OCF Service, again the order of processing at the sending end makes it unpractical to protect the OCF: the interface to the SDLS function is either with the VC generation function or with the VC multiplexing function; in both cases before the MC_OCF is appended to the frame by the Master Channel Generation function.


Not protecting the COP commands and the OCF (i.e CLCW and FSR) has indeed implications as stated in Annex B1 of SDLS BB : “The Security Protocol provides no protection to TC COP control commands nor to COP CLCW status information returned in the OCF; an attacker could use false COP control directives or OCF contents to interfere with a communications session.”. Nevertheless, this residual risk was evaluated as acceptable operationally by the WG since the legitimate operator can always reinitialize the COP. Denial of service is only temporary and not so easy to implement in the first place.

I leave it to the WG members to complement my answer. I might have missed part of the rationale.

Best regards,

Gilles



Gilles MOURY

SDLS WG Chairman



-----Message d'origine-----
De : CCSDS Secretariat <thomas.gannett at tgannett.net>
Envoyé : mardi 4 mai 2021 17:48
À : Moury Gilles <Gilles.Moury at cnes.fr>; craig.biggerstaff-1 at nasa.gov
Cc : Peter.M.Shames at jpl.nasa.gov
Objet : Re: CESG-P-2021-04-001 Approval to release CCSDS 355.0-P-1.1, Space Data Link Security Protocol (Pink Sheets, Issue 1.1) for CCSDS Agency review



Dear Document Rapporteur,



The CESG poll to approve release of CCSDS 355.0-P-1.1, Space Data Link Security Protocol (Pink Sheets, Issue 1.1) for CCSDS Agency review concluded with conditions. Please negotiate disposition of the conditions directly with the AD(s) who voted to approve with conditions and CC the Secretariat on all related correspondence.





CESG E-Poll Identifier:  CESG-P-2021-04-001 Approval to release CCSDS 355.0-P-1.1, Space Data Link Security Protocol (Pink Sheets, Issue

1.1) for CCSDS Agency review

Results of CESG poll beginning 19 April 2021 and ending 3 May 2021:



                 Abstain:  0 (0%) Approve Unconditionally:  4 (80%) (Merri, Duhaze, Burleigh, Moury) Approve with Conditions:  1 (20%) (Shames) Disapprove with Comment:  0 (0%)

CONDITIONS/COMMENTS:



     Peter Shames (Approve with Conditions):   In looking these Pink

Sheets over it does occur to me that not providing protection to the OCF and COP fields creates a vulnerbility that can be exploted by an adversary.  Annex B properly identifies this as a security vulnerability.  Can you state why this choice was made and why it would not be appropriate to also provide coverage for these operationally required fields that can potentially be attacked?





Total Respondents:  5



No response was received from the following Area(s):



     CSS

     SOIS







SECRETARIAT INTERPRETATION OF RESULTS:  Approved with Conditions

PROPOSED SECRETARIAT ACTION:            Generate CMC poll after

conditions have been addressed



* * * * * * * * * * * * * * * * * * * * * * * *


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20210518/8e4008b0/attachment-0001.htm>


More information about the SLS-SEA-DLS mailing list