[Sls-slp] Security, NGU and New TC services and there effect on COP-1

[Greenberg, Edward (313B)]

Matt,  What does pretty mean?  If we add a process to precede the TC processor it must perform frame sync, derandomization (assuming you use randomization), FEC, DECRYPTION and then reconstitute the TC frame without the security.    The toughest job here is the decryption.  If you want to create a new TC process then outside of eliminating the BCH or encoding after security is added, you basically have to do the same process.   I believe the COP fails if you put security after the TC decoder...but you can lock up the TC process if the security fails which would prevent you from accepting a series of frames with a gap.  

________________________________________
From: Cosby Matthew [MCOSBY at qinetiq.com]
Sent: Wednesday, October 14, 2009 2:23 AM
To: Greenberg, Edward (313B)
Cc: Shames, Peter M (3130); Howie Weiss; SLS-SLP WG
Subject: RE: [Sls-slp] Security,        NGU and New TC services and there  effect on  COP-1

Ed,

Just to confirm our conclusion:

We agreed that if you put the security layer before the COP it would not technically cause problems with the operation of the COP/FARM as it is defined. And the reason for putting the layer before the COP is if you already have existing hardware TC processors which we do in Europe. However, you would need to complete the security checks and then re-package the frame to be processed by the ASICs. This means that you are going up and down the stack on board the spacecraft. So this method isn’t pretty and CCSDS shouldn't standardise this way of operations as it is only relevant for a specific implementation.

Where we disagree is that the COP isn't "broken" if you put the security afterwards and the security layer fails its checks. This comes back to where the COP/FARM has finished its job (to guarantee delivery of complete in sequence, error free commands). Our disagreement was that I believe that the COP has finished when it hands the command to the next process (whatever that is) – in this example it is the security layer. You believe that the COP has not completing its job correctly if the next process or processes throws the command away for another failure – in this case if the security has failed.

I am happy to discuss this at the meeting in ESTEC as this covers one of my actions.

Cheers,

Matt.

-----Original Message-----
From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Greenberg, Edward (313B)
Sent: 13 October 2009 17:36
To: SLS-SLP WG
Cc: Shames, Peter M (3130); Howie Weiss
Subject: [Sls-slp] Security, NGU and New TC services and there effect on COP-1

Last week Majorie De Lande Long posed the question as to how the new

security header and its placement in the TC frame would effect COP-1.

A few weeks ago Greg and I had a long discussion with Matt Cosby on this

very topic.  We concluded that if the security was processed prior to the

COP there is no issue.  The only problem is that the FEC decoding should be

performed before the security process.

This leads us to another item that can be put on the table.  The CCSDS is in

the final phases of approving the LDPC codes and the new generation uplink

team is investigating how to improve performance for commanding.  One of the

things being considered is to use the LDPC code for all uplinks by placing

it in the physical layer.  I this way the code would be put on synchronously

to carry the synchronous bits required in the link but independent of the

frames contain in the link.  Thus taking advantage of the 8 db gain provided

by the coding without changing the link layer protocol.  One of the benefits

of this approach is that the TC link layer protocol need not be modified and

ESA's current flight command decoder implementation need not be changed. The

only that that would be required on the flight side is an LDPC decoder with

a security processor that outputs the TC frame as currently defined

(eliminating the inserted security data fields and decrypting the data frame

data field.




_______________________________________________

Sls-slp mailing list

Sls-slp at mailman.ccsds.org

http://mailman.ccsds.org/mailman/listinfo/sls-slp

The information contained in this E-Mail and any subsequent
correspondence is private and is intended solely for the intended
recipient(s).  The information in this communication may be
confidential and/or legally privileged.  Nothing in this e-mail is
intended to conclude a contract on behalf of QinetiQ or make QinetiQ
subject to any other legally binding commitments, unless the e-mail
contains an express statement to the contrary or incorporates a formal Purchase Order.

For those other than the recipient any disclosure, copying,
distribution, or any action taken or omitted to be taken in reliance
on such information is prohibited and may be unlawful.

Emails and other electronic communication with QinetiQ may be
monitored and recorded for business purposes including security, audit
and archival purposes.  Any response to this email indicates consent
to this.

Telephone calls to QinetiQ may be monitored or recorded for quality
control, security and other business purposes.

QinetiQ Limited
Registered in England & Wales: Company Number:3796233
Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom
http://www.qinetiq.com/home/notices/legal.html<http://www.QinetiQ.com/home/legal.html>