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

Moury Gilles Gilles.Moury at cnes.fr
Sun May 9 21:23:45 UTC 2021


Thank you Craig for this clear diagram which illustrates unambiguously the order of processing. The proposed text will add a justification to the order of processing. We will discuss this update of the SDLS Green Book at our upcoming meeting. There is a strong push from SLP WG (G.Kazz) to develop that subject in the GB and issue a revision quickly.

Best regards,
Gilles

Gilles MOURY
CNES Toulouse
De : Biggerstaff, Craig (JSC-CD42)[SGT, INC] <craig.biggerstaff at nasa.gov>
Envoyé : vendredi 7 mai 2021 20:46
À : Ignacio.Aguilar.Sanchez at esa.int
Cc : Moury Gilles <Gilles.Moury at cnes.fr>; sls-sea-dls at mailman.ccsds.org
Objet : RE: [Sls-sea-dls] [EXTERNAL] TR: CCSDS Order of Processing: Figure 6-3 in CCSDS 232.0 and Figure 3-3 in CCSDS 350.5-G

Ignacio, thanks for your comments.  I definitely agree that RF & Modulation should be a separate 'lane', and corrected that oversight in the latest version (attached).  At the recommendation of some C&S WG members (whose discussion prompted this diagram in the first place), I also added a legend, a note on BCH ordering, and numbering of sequential flow.  I did not incorporate your other suggestions, as the diagram can't include much more visual information without losing easy readability.

Best regards,


Craig


From: Ignacio.Aguilar.Sanchez at esa.int<mailto:Ignacio.Aguilar.Sanchez at esa.int> <Ignacio.Aguilar.Sanchez at esa.int<mailto:Ignacio.Aguilar.Sanchez at esa.int>>
Sent: Thursday, May 6, 2021 1:46 AM
To: Biggerstaff, Craig (JSC-CD42)[SGT, INC] <craig.biggerstaff at nasa.gov<mailto:craig.biggerstaff at nasa.gov>>
Cc: Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>; sls-sea-dls at mailman.ccsds.org<mailto:sls-sea-dls at mailman.ccsds.org>
Subject: Re: [Sls-sea-dls] [EXTERNAL] TR: CCSDS Order of Processing: Figure 6-3 in CCSDS 232.0 and Figure 3-3 in CCSDS 350.5-G

I like the drawing, Craig.

A few possible improvements suggested:

- placement of the Mod and Demod boxes in a new layer above "C&S", which is "RF & Modulation";
- addition of internal interfaces like the "RF lock" and "Bit Lock" from the Demod box to the CLCW or the control frames towards FARM-1 as directives (not data traffic);
- addition of text above the solid arrows that directly connect from VC Gen to VC Mux and from VC Demux to VC Rec to explain the perceived absence of COP-1 processing;
- consideration/illustration of distinct control frame, expedited-service frame and sequence-controlled frame processing (may overlap with the two previous comments);
- addition of external interfaces (e.g. to the redundant Demod to obtain their "RF Lock" and "Bit Lock", directives to manage FOP-1, Apply Security, FARM-1, Process Security).

Let us know if the above helps.

Kind regards,

Ignacio

[cid:image001.gif at 01D74528.4ADD3B60]

Ignacio Aguilar Sánchez
Communication Systems Engineer
Electrical Engineering Department

European Space Research and Technology Centre
Keplerlaan 1, PO Box 299, 2200 AG Noordwijk, The Netherlands
Tel. (31) 71 565 5695
Fax (31) 71 565 5418
Email: ignacio.aguilar.sanchez at esa.int<mailto:ignacio.aguilar.sanchez at esa.int>
www.esa.int<https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.esa.int%2F&data=04%7C01%7Ccraig.biggerstaff%40nasa.gov%7Ca0b54883dbdb4059510a08d9105a9665%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637558803540802107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=W8xm55SVMfY8B6yj2pf2yhDcwVkJFK5ODMhVTOoz7xk%3D&reserved=0>



From:        "Biggerstaff, Craig\(JSC-CD42\)\[SGT, INC\] via SLS-SEA-DLS" <sls-sea-dls at mailman.ccsds.org<mailto:sls-sea-dls at mailman.ccsds.org>>
To:        "Moury Gilles" <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>, "sls-sea-dls at mailman.ccsds.org<mailto:sls-sea-dls at mailman.ccsds.org>" <sls-sea-dls at mailman.ccsds.org<mailto:sls-sea-dls at mailman.ccsds.org>>
Date:        05/05/2021 22:14
Subject:        Re: [Sls-sea-dls] [EXTERNAL] TR: CCSDS Order of Processing: Figure 6-3 in CCSDS 232.0 and Figure 3-3 in CCSDS 350.5-G
Sent by:        "SLS-SEA-DLS" <sls-sea-dls-bounces at mailman.ccsds.org<mailto:sls-sea-dls-bounces at mailman.ccsds.org>>
________________________________


Dear SDLS WG members,



I have lately received a few (internal NASA) questions regarding the order of processing between SDLS and COP, similar to discussions in the WG earlier.  Since we already discussed adding clarifying text in the next SDLS Green Book revision, attached is a diagram I created to illustrate the flow and interactions between protocol sub-layers.  If the WG finds this helpful, we could consider it (or something similar) for inclusion along with the clarifying text.



Best regards,







Craig Biggerstaff



[KBR - Copy]

KBR  |  Senior Engineer Specialist, Mission Systems Operations Contract

2101 NASA Parkway, Mail Code CD4  |  Houston, Texas 77058  |  USA

Office: +1 281.483.2027  |  craig.biggerstaff at nasa.gov<mailto:craig.biggerstaff at nasa.gov>

________________________________

This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient.  Any review, use, distribution, or disclosure by others is strictly prohibited.  If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.



From: SLS-SEA-DLS <sls-sea-dls-bounces at mailman.ccsds.org<mailto:sls-sea-dls-bounces at mailman.ccsds.org>> On Behalf Of Moury Gilles
Sent: Friday, February 5, 2021 11:44 AM
To: sls-sea-dls at mailman.ccsds.org<mailto:sls-sea-dls at mailman.ccsds.org>
Subject: [EXTERNAL] [Sls-sea-dls] TR: CCSDS Order of Processing: Figure 6-3 in CCSDS 232.0 and Figure 3-3 in CCSDS 350.5-G



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<mailto: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<mailto:craig.biggerstaff at 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>>; Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>
Cc : Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>; 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>>
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:image003.png at 01D74528.4ADD3B60]

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>

 [attachment "SDLS & COP interactions.vsd" deleted by Ignacio Aguilar Sanchez/estec/ESA]

_______________________________________________
SLS-SEA-DLS mailing list
SLS-SEA-DLS at mailman.ccsds.org<mailto:SLS-SEA-DLS at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsls-sea-dls&data=04%7C01%7Ccraig.biggerstaff%40nasa.gov%7Ca0b54883dbdb4059510a08d9105a9665%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637558803540812068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NXlTXAvmEgFvnVbIg20Cg%2BNVoO5zRD0te5Gik7fQiOs%3D&reserved=0>

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or

protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received

this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect

personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20210509/52cee8e6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1155 bytes
Desc: image001.gif
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20210509/52cee8e6/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 1940 bytes
Desc: image002.jpg
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20210509/52cee8e6/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 434658 bytes
Desc: image003.png
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20210509/52cee8e6/attachment-0001.png>


More information about the SLS-SEA-DLS mailing list