[Sls-slp] Re: [Sls-sea-dls] Re: Order of Processing between TC-SDLP, COP-1 and SDLS

[Kazz, Greg J (313B)]

Bonjour Gilles,

Thanks for your reply. It seems we will need to discuss what is the best mechanism for SDLS to provide real-time or near real-time reporting to the control center. My suggestion was to use a spare bit in the currently defined Version 1 of the OCF, namily the CLCW to indicate the presence of a security error. Foremost in my mind is to inform the control center as soon as possible of this problem, so that they can take immediate action – most likely to stop sending any more commands, until the problem can be analyzed. The analysis job is most likely to be done in non-real-time by other personnel. So identification of the problem can be sent in telemetry in the OCF (whether or not CCSDS needs to define yet another OCF version specifically to SDLS seems unnecessary to me, but as you point out, it is an option). In addition, the analyst may want the spacecraft to transmit some or all of the spurious data that it received to the ground, so analysis can be done on the attack – this data would be telemetered in packets, in order to understand what was received by the spacecraft vs what was expected. Regardless of what kind of OCF is sent, it will be in the clear. Do we want it to be in the clear ? Then the "bad guys" will know we have detected them.

I understand the distinction between transmission and security types of errors. However, once a security error is detected by SDLS, COP-1 will not be informed of the detected error and will continue to process frames as if nothing was wrong. The COP-1 will think it has delivered an in-order, without duplicates nor gaps stream of transfer frames but in reality it did not, due to the frame rejection by SDLS. Isn't the behaviour we desire for the COP-1 to shut down in this instance, to minimize futher contamination until the problem can be cleared?

Best regards,

Greg



From: Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>
Date: Thursday, March 28, 2013 4:48 AM
To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Cc: "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>>, "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: RE: [Sls-sea-dls] Re: Order of Processing between TC-SDLP, COP-1 and SDLS

Dear Greg and all,

I concur with the clarifications that you have introduced in section 6.3 and 6.4. Your proposed figures 6-c and 6-d are less ambiguous than the preceding ones and they clearly rule out the possibility of interfacing SDLS function with "All Frames Generation/Reception" function. The text modifications you propose in coherence with those new figures are OK.

For the modifications introduced in 4.2.1.1.2 and 4.2.1.10 which aim at defining an optional  "SDLS Error Flag" to be transmitted in the CLCW, I do not concur since we concluded at our Feb telecon on SDLS-COP interaction that we should keep SDLS and COP decoupled. The rationale being :

- COP is dealing with transmission errors exclusively, so COP-FARM and COP-FOP should only be informed of detected transmission errors

- SDLS detects and passivate security errors (discarding impacted frames). SDLS informs associated SLP protocol of security errors, SLP protocol should  in turn inform SLP user. In all cases, security errors management will require analysis and action by human operators. Therefore, I do not see what an automated procedure like the COP could do with this SDLS error flag that you would like to introduce in the CLCW. Security errors reporting will be defined as part of the SDLS extended procedures which include an SDLS Monitoring & Control service. A real-time SDLS reporting status word will be defined. It could be transmitted either in line in the frame as a newly defined OCF for TM/AOS, or as a normal TM packet to be carried in the data field of TM/AOS transfer frames. What do you think of the possibility to define a specific type of OCF for SDLS real-time reporting ?


For your last point : "ApplySecurity" and "ProcessSecurity" functions are mentionned in SDLS book. So the coherency is insured. We could still add in SLP books that  "ApplySecurity" and "ProcessSecurity" functions are virtual functions that provide security services of SDLS.

Best regards,

Gilles

Gilles MOURY
CNES Toulouse
De : Kazz, Greg J (313B) [mailto:greg.j.kazz at jpl.nasa.gov]
Envoyé : mardi 19 mars 2013 20:08
À : Moury Gilles
Cc : sls-sea-dls at mailman.ccsds.org<mailto:sls-sea-dls at mailman.ccsds.org>; sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>
Objet : Re: [Sls-sea-dls] Re: Order of Processing between TC-SDLP, COP-1 and SDLS

All,

Attached is my attempt to clarify the known interface points between the TC protocol and SDLS. Most of my redlines are confined to the following sections:

4.2.1.1.2
4.2.1.10
6.3
6.4

 I tried to clarify at what channel level (individual VC, MC, Physical Channel – meaning multiplexed Mcs) the TC user can interface with SDLS. To this end, I provided a diagram that attempts to show this relationship replacing Marjorie's in Section 6.3 and 6.4, which didn't define the interface but rather showed typically examples of where the interface might be. I also introduced text that would aide the TC user in choosing the appropriate interface point to SDLS within TC. You will see this new text also in sections 6.3 and 6.4.

Most controversially perhaps is the addition of an optional new flag, that SDLS should consider supporting, called "SDLS Error Flag" which enables a reporting mechanism of security errors from SDLS through the CLCW to COP-1. My concern is that without it, there is no mechanism to inform the COP-1 that the in-order, without duplicate or omission delivery guarenteed by the COP-1 may have been compromised due to actions taken by SDLS but unknown to the COP-1. I encourage the SDLS WG to consider it.

Finally to ensure that both the SDLS book and the SLP books are coherent, should there be some mention in the SDLS book about the virtual functions I.e., "ApplySecurity" and "ProcessSecurity" mentioned in TC (which will also be mentioned in AOS and TM as well). Or should we simply say in the SLP books, that this is a virtual function that represents the security services provided in SDLS?  It is another open issue.

This attached version of the TC book is now in the SLP WG CWE under: http://tinyurl.com/ck48ckr


Your comments are welcome!

Best regards,

Greg Kazz
Chairman SLP WG

From: <Kazz>, "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Date: Thursday, March 14, 2013 1:22 PM
To: Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>
Cc: "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>>, "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: [Sls-sea-dls] Re: Order of Processing between TC-SDLP, COP-1 and SDLS

Bonjour Gilles,

Thank you for contribution.  Essentially you are saying that the green box in both Figures 6c and 6d should shrink so that it does not expand beyond either the Master Channel Multiplexing Function or the MC Demultiplexing Function. In other words, there is no interface point for SDLS with either the TC-SDLP 'All frames generation' or 'All Frames receiption' functions. This makes sense. However, Figures 6c and 6d are very nebulous in the sense that there is this "SDLS ApplySecurity Function" seemingly floating around in space that shows an anchor at the port of "Virtual Channel Multiplexing/Demultiplexing" only for example. The text says it could be in Virtual Channel Generation Function or in the Virtual Channel Multiplexing function. No text talks about the possibility in the MC Multiplexing function. Also the COP management Function is called out in 6c, but no such reciprocal function exists in 6d. I think we are still lacking a clear explanation of these figures in the text.

We still need a better way to convey the relationships between the protocols involved including the order of overall processing to the user  I.e.,  between SDLS, COP-1, TC-SDLP. I think some kind of high order diagram and text that shows the order of processing between them is needed.

We also need to modify the TC Sync & CC Green book so that we capture the rationale behind our decisions on the order of processing of SDLS, COP-1, TC-SDLP (much of which you have already captured in the meeting minutes of our last TIM, but some business is yet to be completed).

Comments anyone ?

Best regards,

Greg

From: Moury Gilles <Gilles.Moury at cnes.fr<mailto:Gilles.Moury at cnes.fr>>
Date: Thursday, March 14, 2013 10:06 AM
To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Cc: "Greenberg, Edward (313B)" <edward.greenberg at jpl.nasa.gov<mailto:edward.greenberg at jpl.nasa.gov>>, "Biggerstaff, Craig (JSC-DD12)[LOCKHEED MARTIN CORP]" <craig.biggerstaff-1 at nasa.gov<mailto:craig.biggerstaff-1 at nasa.gov>>, "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>>, "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: RE: Order of Processing COP-1 and SDLS

Dear Greg,

Please find attached the additions I propose to the TC-SDLP book to avoid users implementing the wrong order of processing between SDLS and "frame error detection" by TC-SDLP. In fact, the only forbidden configuration for interfacing SDLS function with TC-SDLP functions is interfacing SDLS with "All Frame Generation" at the sending end and "All Frame Reception" at the receiving end. This guarantee that, at the receiving end, transmission errors are detected and impacted frames discarded first , before SDLS processes the frames, which satisfies our security requirement that transmission errors should be unambiguously separated from security errors.

I have therefore introduced an additional text in sections 6.3.1 and 6.4.1 to forbid this configuration (see attached redlined file). I think it covers the point. All comments are welcome.

Best regards,

Gilles

Gilles MOURY
CNES Toulouse
De : Kazz, Greg J (313B) [mailto:greg.j.kazz at jpl.nasa.gov]
Envoyé : lundi 11 mars 2013 23:02
À : Moury Gilles
Cc : Greenberg, Edward (313B); Biggerstaff, Craig (JSC-DD12)[LOCKHEED MARTIN CORP]
Objet : Order of Processing COP-1 and SDLS

Gilles,

Correct me if I am wrong, but I did not see a response from you regarding this action item below:
We do not have text in the TC SLP section 6 document which deals with this issue yet.

- best regards,

Greg
SDLS0213/01


G. Moury

Propose a solution to explicitly specify the order of processing at the receiving end between TC-COP and SDLS (if not already present in section 6 of TC-SLP)

 March 8, 2013




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20130329/c5d84247/attachment.html>