[Sis-dtn] [EXT] RE: BPv7 PIDS

[Dr. Keith L Scott]

Right, sorry, I did mention that in the text.  Let’s talk about whether to use that or not in the initial tabletop exercise.

                                --keith


From: sburleig.sb at gmail.com <sburleig.sb at gmail.com>
Date: Friday, October 7, 2022 at 2:18 PM
To: Dr. Keith L Scott <kscott at mitre.org>, sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Subject: [EXT] 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

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