[Sis-dtn] [EXTERNAL] BPv7 PID resolution

[Dr. Keith L Scott]

Or maybe the human-in-the-loop is stage 2a and 2b is where the system is large enough that some automated lookup service is needed.  Honestly don’t know if that’s ‘b’ or ‘d’ or whatever, I think it’s a function of the network size at which connecting to other nodes with human-in-the-loop gets unscalable.

                                --keith

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org>
Date: Monday, November 14, 2022 at 1:58 PM
To: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>, Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <beau.t.blanding at nasa.gov>, sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] [EXTERNAL] BPv7 PID resolution
To your first paragraph below: I think I agree, except that I was assuming that other sites (e.g. ground gateways between agencies) would be added to the SS&A registry as needed.  The ‘unregistered nodes’ in what you have below could be nodes entirely internal to some entity (e.g. a BP router ‘in the middle of’ NASA’s infrastructure).  An entity could elect to instantiate a SS&A entries for all such nodes (e.g. build 17 room XXX of GSFC as a ‘site’ – OK, didn’t actually check to see if the registry supports that well) if they want to.  We’re not opposed to it, just wanted to admit the possibility that an agency might not want to list all such assets.

The intent of the above was that in stage 2b, the way to establish communication with something that’s not yours would be to look up to POC in the SSI record in the SS&A registry and manually get the connectivity information.  That way nodes can be configured with ‘default deny’ security policies and (by the time the humans get through exchanging confiuguration information which would include security material) only accept bundles from trusted sources (using e.g. BPsec and a security context that signs the primary+payload blocks, e.g.)

We could devise some sort of directory service that would allow someone to query for the connectivity characteristics / configuration of a particular node, but I think that’s: 1) not really needed at the moment / can be developed later as necessary 2) might require some interesting security measures (maybe I don’t WANT just anybody to know how to communicate with this node, or even that the node exists) and 3) some more infrastructure around the information exchanges that will be needed (like a standardized way to express schedules).  I think the most relevant of those is 1) we can develop such a directory service later as needed.  We’re better off getting a BPv7 spec out that folks can build to and as the population grows, think about automation.

                                --keith


From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Date: Monday, November 14, 2022 at 1:42 PM
To: Dr. Keith L Scott <kscott at mitre.org>, Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <beau.t.blanding at nasa.gov>, sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Subject: Re: [EXTERNAL] BPv7 PID resolution
Hi Keith,

I believe that there was a third aspect of this and that was providing an actual node registry and not just the existing “Agency x owns this range of node numbers”, which is what we have now.  I assumed that all of the DTN Sites offering DTN services, i.e. store and forward, would be registered in the SS&A registry.  This would include who owned them, where they are located, what services they offer, and their node numbers.  That still leaves all of the rest of the DTN Nodes that do not offer services, per se, as essentially unregistered entities, except that their assigned number would (putatively) identify the “owning” agency.

In Stage 2a, where we are, more or less, expecting node deployments to be a private matter and managed by the agency (or project), the needed info about actual identities, locations, routing, etc must be managed (privately) within the deployment.  However, in any Stage 2b context, where interoperability and the identities of nodes, and their permissions, would be a concern, I wonder if this is really adequate?

Have you guys addressed this in any way?

Thanks, Peter


From: Keith Scott <kscott at mitre.org>
Date: Monday, November 14, 2022 at 5:00 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, "Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT]" <beau.t.blanding at nasa.gov>, "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Subject: [EXTERNAL] BPv7 PID resolution

Peter,

The sis-dtn wg has gone through your comments on the bpv7 draft Red Book and has proposed modifications to the document to address the issues you raised.  The high-level proposed changes to the larger issues you raised are:


  *   Include text at the end of Section 2 identifying ongoing and future work that discusses security and network management, and how security can be used to secure network management.


  *   Include in the SANA considerations section a plan to use Site Service Info records in the Service Sites and Apertures registry to provide POC information to entities wishing to connect to the BP node at a specific site.


Some issues, like the ‘late binding’ discussion probably require some discussion to resolve.

Do you have some time to start working through the PID items?  The document is here: https://docs.google.com/document/d/1P8g8_2HPnadf3RfAdP6tltI4H_kwiL-p/edit?usp=share_link&ouid=112263620729744601172&rtpof=true&sd=true<https://urldefense.us/v3/__https:/docs.google.com/document/d/1P8g8_2HPnadf3RfAdP6tltI4H_kwiL-p/edit?usp=share_link&ouid=112263620729744601172&rtpof=true&sd=true__;!!PvBDto6Hs4WbVuu7!fmK28hRCJGziSKAiLWtldRMS9EO8YneHSoKu93EdeWZkVPN3SCYN5vaM29QgO89Mm8iaC6zB$> if you’d like to take a look first, or we can start by walking through them together.

                                v/r,

                                --keith

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