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

Fri Apr 12 07:48:08 UTC 2013

Dear Greg,

*** Here is the email I sent yesterday (11.April), now with a few
*** clarifications of the technical discussion about the CLCW
*** flag. The changes are in 1.2, 4.1 and 4.4, marked with %%%.
(These are points that were missing from the original and are 
not in response to comments received in the meanwhile.)

Gian Paolo, Daniel, Ignacio and myself have been discussing the ESA
position on a few things for the SDLS interface and its relationship to
TC and COP-1.  This is about two issues in your email exchange with
Gilles:

- ESA is against including a one bit SDLS Error Flag into the CLCW.

- A specific SDLS OCF Type 2 report looks like a better option. ESA sees
this as an option for future work: definition of format and rules for
SDLS OCF Type 2 report is not simple and can only be done within the
discussion of the SDLS Extended Procedures

Because I will not be at the CCSDS meeting in Bordeaux, I am laying out
my argument here on the subject of the proposed SDLS Error Flag to
replace the Reserved Spare bit in the CLCW.  

There are four main sections (sorry this is so long!):
- Section 1 considers a system where the SDLS handling is below COP-1,
so that the SDLS handling is after FOP-1 at the sending end and before
FARM-1 at the receiving end.
- Section 2 considers a system where the SDLS handling is above COP-1,
so that the SDLS handling is before FOP-1 at the sending end and after
FARM-1 at the receiving end.
- Section 3 considers the limitations of an SDLS Error Flag in the CLCW.
- Section 4 has some general points.

*** Also, this discussion assumes that a frame that fails SDLS
verification is discarded. ***  

1) For a system where the SDLS processing is after FOP-1 at the sending
end and before FARM-1 at the receiving end

1.1  COP-1 delivery assumptions
In this system, an SDLS verification failure does not compromise the
COP-1 delivery assumptions:
- At the receiving end, the SDLS failure is detected (and the frame is
discarded) before the frame reaches FARM-1.
- From the point of view of COP-1, this is similar to a frame that is
lost because of a bad CRC or BCH: the FARM does not see the failed
frame, so it does not acknowledge it.
- The FOP will not receive an acknowledgement for the frame, so it will
retransmit it (e.g. because of the timer).

1.2 COP-1 retransmission
If FOP-1 retransmits the frame, then:
%%% - In case of SDLS error (due to e.g. intruder or security 
misalignment between sending and receiving ends) it is likely that
the retransmitted frame will not change and it will be discarded 
again.
%%% - If the original SDLS failure was caused by undetected 
transmission errors (not so likely), then a retransmission can 
send a frame with fewer errors for BCH and/or CRC and it could 
solve the problem.
%%% - If the failed frame did not come from FOP-1, then, of 
course, FOP-1 cannot retransmit it.

1.3 Setting the SDLS Error Flag in the CLCW

1.3.1 If the faulty frame is discarded when the SDLS error is detected:
- The frame does not reach FARM-1, so FARM-1 will not do any actions for
the frame.
- So there would need to be some new interface from the TC SDLP to the
CLCW handling, but outside the FARM. 
- There is already an interface outside the FARM, for the Bit Lock,
etc., but can this really be recommended? 

1.3.2 If the faulty frame is not discarded when the SDLS error is
detected:
- The frame is passed to FARM-1 with an indication that it is faulty.
- This would require new FARM-1 behaviour.
- The new behaviour would not be limited to just setting the Flag in the
CLCW.
- So, there would be changes to FARM State Tables, etc., with all that
implies ...

1.4 The failure needs to be reported - see 3.5 and 3.6 below.

2) For a system where the SDLS processing is before FOP-1 at the sending
end and after FARM-1 at the receiving end

2.1  In this system, a frame can be lost because of an SDLS failure
after the frame has been acknowledged and delivered by FARM-1. This is
similar to an error being detected when reassembling a packet from
multiple frames.

2.2  It is happening above COP-1, so, strictly speaking, the COP-1
delivery assumptions are not compromised.
- The COP-1 delivery guarantee applies only as far as the output from
the FARM: if a frame suffers an error after that, then that is not
COP-1's problem. (It is a problem and it needs to be reported but it is
not COP-1's problem.)
- An example of one of these errors is mentioned in 2.1: there are
existing systems that handle this error.

2.3  The SDLS failure is detected above the FARM, as the frame is being
passed upwards.  So it does not look so convenient to try to pass
information downwards (e.g. into the FARM) so that the SDLS Error Flag
can be set in the CLCW. 

2.4  The failure needs to be reported - see 3.5 and 3.6 below.

3. Limitations of an SDLS Error Flag
(For either position of the SDLS processing w.r.t. COP-1)

3.1  Is the purpose of the SDLS Error Flag simply to inform the sending
end, or is some automatic behaviour (other than reporting) expected from
FOP-1?
- Firstly, this would affect the FOP-1 State Tables.
- Secondly, what should FOP-1 do?  There are so many different scenarios
for SDLS use w.r.t. to SAs, VCs and MAPs that it would be difficult to
say how FOP-1 should react.  
- Because of this and the other complications (e.g. what really caused
SDLS to reject the frame), any decisions about how to handle the running
A-Service in this circumstance have to be made at a higher level
(management software and/or human operator).

3.2  The SDLS Error Flag is a single bit. It indicates "that the last
received Transfer frame provided to the SDLS ProcessSecurity function
was rejected", but it has very limited capability to say which frame or
Security Association was affected. The sequence number in the CLCW only
shows which frame was last accepted for the VC, on the A-Service.

3.3  
- For a VC where the MAPs do not all have the same SA, or where some
MAPs do not use SDLS, the sequence number in the CLCW is not much help
to find which SA is affected.  
- For an SA which covers multiple VCs, the SA can be deduced, but the
position of the error cannot. 
- If some SDLS frames are sent on the B-Service, the A-Service
sequence number in the CLCW is not helpful.

3.4  The timing of the arrival of the CLCW is also not so helpful.
There is a variable delay between the time when it is decided to set the
SDLS Error Flag and the time the next CLCW is transmitted for the VC.
By the time the flag arrives back at the sending end, there could be
further difficulties in deciding which frame it refers to, and, in some
circumstances, the error could already have cleared itself.

3.5  Clearly, the SDLS Error Flag is no substitute for an error
reporting mechanism by the SDLS protocol entity at the receiving end,
via its own management procedures, to inform the sending end of the SDLS
failure. This reporting and the SDLS management procedures are
SDLS-dependent and they are independent of the TC SDLP protocol.

3.6  At present, a TC SDLP protocol entity usually has its own
implementation dependent reporting mechanisms for reporting on progress
and on detected errors (such as detecting a frame with a bad CRC). These
mechanisms are not specified in 232.0-B.  Similarly, an implementation
can make its own decisions on how it reports a frame that is rejected by
SDLS.

4) General comments 

%%% 4.1  An SDLS frame rejection can have many causes (e.g. intruder, 
SA misalignment between sending and receiving ends, key 
management issue, undetected error).  It needs handling by
management (at least management software, and often by people).

4.2  I don't think it is a good idea to use a COP-1 PDU to report a
problem in a different protocol:
- There is no one-to-one relationship between a COP-1 instance (which is
a VC) and an SDLS instance (which is an SA).
- The one-to-many relationship between a VC and an SA can go in either
direction (multiple SAs in one VC or multiple VCs covered by one SA).

4.3  This SDLS Error Flag can only be used for TC. 
- SDLS errors also need reporting on AOS and TM links.
- When SDLS is used for AOS on the uplink, then the SDLS errors will
need to be communicated to the ground, but AOS does not use CLCWs.

4.4  Adding the SDLS Error Flag to the CLCW is not trivial.
%%%- There would be a rule for setting the flag at some time. But 
there would be other questions to be answered: When would the flag 
be reset? What is the effect on FOP state tables? 
%%%- The timing would also need to be considered. What is the minimum 
time interval before resetting the flag?  Because of the sampling 
interval for the CLCWs on a VC, the flag should not be reset too soon,
otherwise it might be reset before a CLCW has been sent.
- Given its limited usefulness, is it likely to be worth the effort in
amending other standards, getting acceptance and so on?  

I wish you all a successful meeting in Bordeaux!

Best regards,
Marjorie

Marjorie de Lande Long
I B + M A de Lande Long
Software + Consultancy
marjorie at delandelong.com

On Fri, 2013-03-29 at 18:05 +0000, Kazz, Greg J (313B) wrote:
> 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>
> Date: Thursday, March 28, 2013 4:48 AM
> To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov>
> Cc: "sls-sea-dls at mailman.ccsds.org" <sls-sea-dls at mailman.ccsds.org>,
> "sls-slp at mailman.ccsds.org" <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
> 

_______________________________________________
Sls-slp mailing list
Sls-slp at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/sls-slp