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

Wed Oct 14 10:10:45 UTC 2009

Ed,

I mean that this system isn't very elegant. It would appear, to the
outside world, that we have just shoehorned in a security layer to fit
an existing implementation. Obviously we should be mindful of the
existing hardware, but we need to balance this with a correct technical
solution.

Cheers,

Matt.

Matthew Cosby

QinetiQ Space
Cody Technology Park
Ively Road, Farnborough
Hants, GU14 0LX

Tel: 

01252 396313 

Email: 

mcosby at QinetiQ.com 

Fax: 

01252 392969 

Web: 

www.QinetiQ.com 

QinetiQ - The Global Defence and Security Experts 

P Please consider the environment before printing this email. 

-----Original Message-----
From: Greenberg, Edward (313B) [mailto:edward.greenberg at jpl.nasa.gov] 
Sent: 14 October 2009 10:58
To: Cosby Matthew
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

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/ho
me/legal.html>

The QinetiQ e-mail privacy policy and company information is detailed elsewhere in the body of this email.