[Sis-dtn] RE: Securing the CCSDDS Bundle Protocol

Mon Jun 22 12:53:59 UTC 2015

Thanks Scott for replying.

The list is from a spread sheet which was intended to do an A vs. B comparison in order to determine the what services are most important to the community.

Since you said basically all the services are needed do you have reference documentation from CCSDS or the IOAG that requires them?  I have looked and I have been unable to find security requirements for DTN except putting together the IOAG SSI document would require some kind IP compatible information payload security service.

I have not found an operational concept document, an approved architecture, the CCSDS requirements document I did find, did not address security of the network or the security of the payload. I did not find a threat and vulnerability assessment of the current DTN systems from which to work. I have attached simple views of what I think the systems look like in reference to the world. They are not like the draft Mission Operations Configurations.

So if you know of definitive documentation that addresses security requirements of the CCSDS DTN networks or the information passing through them, would you share them with me please. (I have a security clearance and receipt of the information can be handled via my center's security office if this is an issue)

I work from Needs Goals and Objectives, then put in constraints thus formulating requirements that need to be complied with.
It is a different way of looking at things and to most it seems a waste of time.  In very complex activities figuring out the must haves, should haves and like to have has a way of clarifying the activity.

I try never to interject my views on how something should be done, I stick to agreed processes so the answer at the end is accepted.

Thanks
Chuck     

Charles J. Sheehe III
Electronics Engineer
System Architectures and Networks Branch
21000 Brookpark Rd
Cleveland, OH 44135
Charles.J.Sheehe at nasa.gov
Office: 216-433-5179

-----Original Message-----
From: Burleigh, Scott C (312B) [mailto:scott.c.burleigh at jpl.nasa.gov] 
Sent: Friday, June 19, 2015 12:58 PM
To: Scott, Keith L (9730-Affiliate); 'sis-dtn at mailman.ccsds.org'
Cc: Sheehe, Charles J. (GRC-LCA0); Howie Weiss (howard.weiss at sparta.com)
Subject: RE: Securing the CCSDDS Bundle Protocol

Hi, Keith.  My comments in-line below.

Scott

From: sis-dtn-bounces at mailman.ccsds.org [mailto:sis-dtn-bounces at mailman.ccsds.org] On Behalf Of Scott, Keith L.
Sent: Wednesday, June 17, 2015 9:26 AM
To: 'sis-dtn at mailman.ccsds.org'
Cc: Sheehe, Charles J. (GRC-LCA0); Howie Weiss (howard.weiss at sparta.com)
Subject: [Sis-dtn] Securing the CCSDDS Bundle Protocol

At the Spring meeting we started the work on a security protocol for the CCSDS Bundle Protocol.  While Dennis and Charles have been working that, we need to get some final consensus from the WG (and all the agencies we can) on what the actual requirements for the security services (in a protocol-agnostic way) are.

To that end, below is a bag of possible services.  Please look these over and let's select / refine the set that we think we need to support for the CCSDS BP Security protocol.  Note that this is not yet the trade of S/MIME vs. SBSP - first we need to establish the 'what it is we want'.

*       Protocol can distinguish between Sender of bundle and the Security-Sender

*  This enables a forwarding node to attach security mechanisms to a bundle.  It might be useful in missions where edge nodes reside on machines with limited power for crypto.  Potentially useful, but not a critical requirement.

*       Protocol provides security services which are; hop-by-hop basis

*  Needed to choke off DOS attacks.

*       Protocol provides security services which are; end-to-end basis

*  Needed, except note that the sending "end" might be a Security-Sender rather than the original source of the bundle.

*       Protocol provides security services which are hop-by-hop basis and End-to-end basis

*  I think this is covered by the preceding three bullets.  

*       Protocol mechanisms secure information at rest

*  Mandatory.  Otherwise forwarding along a multi-agency path may be impossible.

*       Protocol provides a means to encrypt protocol elements so that messages in transit cannot practically be read

*  Needed.

*       Protocol supports pre-shared-keys (and/or known irrevocable certificates).

*  Needed.

*       Protocol provides a means to apply an integrity check to a bundle so that the identity of the security-sender can be established and changes in sensitive parts of the message can be detected.

*  I think what is needed is a means of integrity-checking any block(s) of a bundle, not the bundle as a whole.

*       Protocol allows combination of confidentiality and integrity services

*  Both confidentiality and integrity services may be needed for any single bundle.  Is that what this means?

*       Protocol prevents changing the intended destination

*  Needed.

*       Protocol prevents falsifying a bundle's source

*  Needed.

*       Protocol prevents changing a bundle's control fields

*  In general, the protocol needs to prevent changing anything in the primary block.

*       Protocol prevents changing other block or payload fields

*  Needed.

*       Protocol prevents replay of bundles

*  Not needed.  Bundles have IDs, and duplicate arrival of bundles is already possible.  Applications need to provide their own application-specific safeguards here.

*       Protocol prevents copying or disclosing bundle data as it passes

*  Not needed.  If encryption is supported then this is moot.

*       Protocol is a Standard

*  If not already a standard, the protocol must have strong prospects of becoming a standard.

*       Protocol has implementations

*  If not already implemented, implementation of the protocol must be affordable.

We need to move out on this, so I'm going to ask people to comment by COB next Monday.  You can say yes or no to the services above and/or propose new ones.  I'll set up a telecon at a mutually-inconvenient time next Tuesday.

                        --keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Drawing1.pdf
Type: application/pdf
Size: 93639 bytes
Desc: Drawing1.pdf
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20150622/403300cc/attachment.pdf>