[Sis-dtn] BPv7 PIDS

[sburleig.sb at gmail.com]

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/20221007/cf50b52c/attachment-0001.htm>