[Sls-sea-dls] TR: CCSDS Order of Processing: Figure 6-3 in CCSDS 232.0 and Figure 3-3 in CCSDS 350.5-G

Fri Feb 5 17:44:23 UTC 2021

Dear SDLS WG member,

The order of processing between SDLS and the COP in TC has raised questions by implementing projects. To clarify the matter and provide a complete justification, Greg Kazz (SLP WG chairman) proposes to include an additional paragraph in the SDLS Green Book (355.0-G) (see exchange of mails hereafter). A text along the following lines is proposed to be inserted in front of Figure 3-3 on page 3-10:

“There are several reasons for this ordering of SDLS and COP functions :

  *   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.
  *   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.”

SDLS GB (355.0-G-1) is due for 5-year review in 2023. Nevertheless, GB do not have the same stability requirement as Blue Book and could possibly be updated more frequently. The proposal I would like to submit to the WG is to prepare an update of the GB this year to include this justification and any other clarifications/additions/updates that might be beneficial. Of course the proposed text is to be discussed and tuned so that it fits properly in that section.

Please do not hesitate to comment on that proposal so that we can initiate or not this GB update.

Best regards,

Gilles Moury
SDLS WG chair

Gilles MOURY
CNES Toulouse
De : Kazz, Greg J (US 312B) <greg.j.kazz at jpl.nasa.gov>
Envoyé : jeudi 21 janvier 2021 18:12
À : Biggerstaff, Craig (JSC-CD42)[SGT, INC] <craig.biggerstaff at nasa.gov>; Moury Gilles <Gilles.Moury at cnes.fr>; Weiss, Howard <Howard.Weiss at parsons.com>; Gian.Paolo.Calzolari at esa.int
Cc : Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>; Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] <victor.j.sank at nasa.gov>; Andres, Brent (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] <brent.r.andres at nasa.gov>; Matthew Cosby <Matt.Cosby at Goonhilly.org>; Thomas Gannett <thomas.gannett at tgannett.net>
Objet : Re: CCSDS Order of Processing: Figure 6-3 in CCSDS 232.0 and Figure 3-3 in CCSDS 350.5-G

That would be in 2023, 3 years from now…since security is on everybody’s plate these days, I highly recommend it get updated this year. It is a Green book, so I would hope we have more discretion and flexibility in updating them more frequently than the blue books. I understand the rationale for not updating blue books that often.

Thanks!
Greg

From: "Biggerstaff, Craig (JSC-CD42)[SGT, INC]" <craig.biggerstaff at nasa.gov<mailto:craig.biggerstaff at nasa.gov>>
Date: Thursday, January 21, 2021 at 8:53 AM
To: "Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>, Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>, "Weiss, Howard" <Howard.Weiss at parsons.com<mailto:Howard.Weiss at parsons.com>>
Cc: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>, "Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC]" <victor.j.sank at nasa.gov<mailto:victor.j.sank at nasa.gov>>, "Andres, Brent (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC]" <brent.r.andres at nasa.gov<mailto:brent.r.andres at nasa.gov>>, Matthew Cosby <Matt.Cosby at Goonhilly.org<mailto:Matt.Cosby at Goonhilly.org>>, Thomas Gannett <thomas.gannett at tgannett.net<mailto:thomas.gannett at tgannett.net>>
Subject: RE: CCSDS Order of Processing: Figure 6-3 in CCSDS 232.0 and Figure 3-3 in CCSDS 350.5-G

I agree with incorporating Gilles’ text.  The normal opportunity to do this would be the Green Book’s 5-year review/revision cycle.

Best regards,

Craig

From: Kazz, Greg J (US 312B) <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Sent: Wednesday, January 20, 2021 6:15 PM
To: Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>; Biggerstaff, Craig (JSC-CD42)[SGT, INC] <craig.biggerstaff at nasa.gov<mailto:craig.biggerstaff at nasa.gov>>; Weiss, Howard <Howard.Weiss at parsons.com<mailto:Howard.Weiss at parsons.com>>
Cc: Shames, Peter M (JPL-312B)[JPL Employee] <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>; Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>; Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] <victor.j.sank at nasa.gov<mailto:victor.j.sank at nasa.gov>>; Andres, Brent (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] <brent.r.andres at nasa.gov<mailto:brent.r.andres at nasa.gov>>; Matthew Cosby <Matt.Cosby at Goonhilly.org<mailto:Matt.Cosby at Goonhilly.org>>; Thomas Gannett <thomas.gannett at tgannett.net<mailto:thomas.gannett at tgannett.net>>
Subject: CCSDS Order of Processing: Figure 6-3 in CCSDS 232.0 and Figure 3-3 in CCSDS 350.5-G

Gilles, Craig, and Howie,

What Gilles provided me, Victor, and Brent (highlighted below, i.e., his bullet points) was an excellent explanation, as to why the COP has to be applied after SDLS at the sending end. And because this topic seems to come up again and again at least at NASA and perhaps at other agencies as well, I strongly recommend that we take Gilles’ text below and put it into a new paragraph in front of figure 3-3 on p. 3-10 in CCSDS 350.5-G (June 2018) to augment the rationale for that figure. I believe it will be useful for user’s to understand the rationale for processing between COP and SDLS. Note that figure 3-3 is identical to figure 6-3 in CCSDS 232.0.

What does the SDLS WG think of this recommendation ?

Best regards,
Greg

From: Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>
Date: Tuesday, January 12, 2021 at 3:57 AM
To: "Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Cc: "Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC]" <victor.j.sank at nasa.gov<mailto:victor.j.sank at nasa.gov>>
Subject: [EXTERNAL] RE: CCSDS Order of Processing: Figure 6-3 in CCSDS 232.0

Dear Greg and Victor,

All my best wishes for 2021 ! I hope we can meet in person this year !

There are several reasons for this ordering of SDLS and COP functions :

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

I hope this clarifies the matter.

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é : dimanche 10 janvier 2021 18:52
À : Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>
Cc : Sank, Victor J. (GSFC-567.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] <victor.j.sank at nasa.gov<mailto:victor.j.sank at nasa.gov>>
Objet : CCSDS Order of Processing: Figure 6-3 in CCSDS 232.0

Happy New Year, Gilles !

Victor Sank and I have a question for you, which I would like to ask you again to confirm my understanding, or correct my thinking.

Why must the FOP on the ground be done after SDLS is applied ? In other words, “why can’t the Frame Sequence Number in the Transfer Frame Primary Header, be input/applied prior to the SDSL ApplySecurity? “

I vaguely remember you saying something like, if the order were reversed (do FOP first, and then SDLS), there would be no way to know why a transfer frame was rejected and therefore the project would not have the accountability it needs to take the correct action. There would be no definitive accountability as to why a given transfer frames was rejected i.e., was it first rejected by SDLS because of an intentional cyber attack or was it just a non-cyber related incident detected by SDLS security (e.g., bit flips due to a regular noisy channel). By executing the FOP-1 and the FARM-1 together as a pair, i.e., back to back as Figure 6-3 shows, you get clean accountability back from SDLS and also from the FARM (if the frame passes SDLS, then the FARM can determine if any other COP rules have been violated or not, independent of SDLS).

Is my explanation above also your understanding ?

Best regards,
Greg

Greg Kazz
Principal Engineer
Technical Group Supervisor,
PSSE/EEISE/PPSE (312B)
Jet Propulsion Laboratory[cid:image001.png at 01D6EFD5.75A04AC0]
4800 Oak Grove Dr., M/S 301-490
Pasadena, CA 91109
1+(818)393 6529(voice)
1+(818)393 6871(fax)
email: greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20210205/f2282b6a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 434658 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20210205/f2282b6a/attachment-0001.png>