[Sis-dtn] BPv7 PIDS

Fri Oct 7 22:40:09 UTC 2022

Re:

comments dealt with things like “how do I know the source EID of this bundle isn’t spoofed”?  I think the way we’ve thought of to address that is BPsec, so there’s a little bit of text there about BPsec and network management. 

A minor clarification:

BPSec provides an integrity value which can be a keyed integrity i.e., an HMAC. An HMAC provides authentication, but it does not provide non-repudiation.

For BPSec to provide non-repudiation the “integrity” or bib must use an approved digital signature algorithm (i.e., ECDSA P384). I haven’t been able to view the posted document, but it should state that when BPSec bib utilizes an approved digital signature algorithm then it can provide non-repudiation (i.e., how do I know the source EID of this bundle isn’t spoofed).

mA

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of "sburleig.sb--- via SIS-DTN" <sis-dtn at mailman.ccsds.org>
Reply-To: <sburleig.sb at gmail.com>
Date: Friday, October 7, 2022 at 11:18 AM
To: "'Dr. Keith L Scott'" <kscott at mitre.org>, <sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] BPv7 PIDS

I look forward to thinking about all this stuff in more detail next week.  Meanwhile, on 2b) below, let me just observe that we’ve had a working implementation of delay-tolerant key administration in ION for several years.

Scott

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Dr. Keith L Scott via SIS-DTN
Sent: Friday, October 7, 2022 10:59 AM
To: sis-dtn at mailman.ccsds.org
Subject: [Sis-dtn] BPv7 PIDS

OK, I’ve uploaded all the PIDs to the “CESG Review 1 20221000” folder.  There are the RID-formatted ones from SLS and the document markup from Peter (in the .docx document).  In the document I inserted Peter’s comments as comments and replied to most of them.  I think there are a couple large topics listed below (though I invite folks to correct that assessment).  As a way to address some of these I added some text to the end of section 2 talking about ongoing / future work; many of Peter’s comments dealt with things like “how do I know the source EID of this bundle isn’t spoofed”?  I think the way we’ve thought of to address that is BPsec, so there’s a little bit of text there about BPsec and network management.  Have a look, comment at will.

Larger topics for discussion:

1) What information needs to be in a node / EID registry?  e.g. should it contain information about the convergence layers a node supports or other (detailed) configuration information?  What if those convergence layers / the configuration information vary with time?

Options for information here include:

Node Number

POC

Mission

Bundle Protocol versions supported

Physical asset to which this node is tied / on which the node is hosted

Maximum supported bundle size

EID naming schemes supported

List of extension block types supported

Does the node support BPsec?

Does the node implement standardized network management?

If implements standardized network management, which ADMs?

Lit of Convergence Layer Adaptors supported

The number of kilobytes of storage allocated to bundle retention at this node and not currently occupied by bundles.

---- <I think the following are 'too much' for the 'node number' registry -- Maybe we define some sort of separate 'ops' registry for highly-dynamic information?> ------

CL addresses / names (e.g. DNS name to resolve to an IP address)

Schedule for when communications are supported (contact plan)

Security key information (to support identity)

Services supported by this node (e.g. bping, cfdp, ...)

2b) For the moment, until we (SIS-DTN and SEA-SEC) work out something better, the key management solution (both for configuring keys / key management and exchanging keymat so as to identify peers) is going to be 'manual'.

3) It might be worth adding a subsection to the end of section 2 that discusses ongoing / future work.  Such a subsection could talk about BPsec and a bit about how we envision its use to support authentication / identity, and network management including the types of information we expect to be managed by some of the basic ADMs.

How MUCH do we need to discuss security (and potential security policies) there?  We have a BPsec Red Book and a Green Book in the current charter.

                                --keith

_______________________________________________ SIS-DTN mailing list SIS-DTN at mailman.ccsds.org https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20221007/cc8bc45f/attachment.htm>