[Sis-dtn] [EXTERNAL] BPv7 PID resolution

Tue Nov 15 07:29:37 UTC 2022

All,

I think what we are discussing here belongs more to the 'realm' of service management and needs to consider at least the following aspects and the relationship between them:

  1.  CCSDS Service Management (upcoming) standards, in particular, the Service Catalogue (which may or may not be related to SS&A)
  2.  Functional Resource Model which could cover more dynamic aspects like configuration of some nodes
  3.  DTN Network Management

While I think it is important to have a plan how to address this topic (I would think that the CESG could discuss the how, who and when), I also would like to stress that this is IMHO not required for release of CCSDS BPv7 for Agency review. I see an urgent need to have a CCSDS BPv7 Blue Book out asap for upcoming programmes and projects. Of course, this book will not and cannot address all topics which are necessary for DTN in general (in the same way RfC 791 fails to describe a lot of things which are necessary for a planetary Internet) or even all aspects which are required for successful use in a single mission (e.g., accounting and reliability). These things will be addressed in upcoming standards and recommendations.

I am fine with the current (non-normative) text in 'D2 SANA Considerations', I am only wondering whether a special PoC for DTN would be necessary (there is already a generic PoC which would cover all services I assume). Anyway, I am happy with anything in this sections which is non-normative and allows us to move forward.

Regards,
Felix

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Dr. Keith L Scott via SIS-DTN
Sent: 14 November 2022 20:01
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
Subject: Re: [Sis-dtn] [EXTERNAL] BPv7 PID resolution

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<mailto:sis-dtn-bounces at mailman.ccsds.org>> on behalf of Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto: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<mailto:peter.m.shames at jpl.nasa.gov>>, Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <beau.t.blanding at nasa.gov<mailto:beau.t.blanding at nasa.gov>>, sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org> <sis-dtn at mailman.ccsds.org<mailto: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<mailto: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<mailto:kscott at mitre.org>>, Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <beau.t.blanding at nasa.gov<mailto:beau.t.blanding at nasa.gov>>, sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org> <sis-dtn at mailman.ccsds.org<mailto: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<mailto:kscott at mitre.org>>
Date: Monday, November 14, 2022 at 5:00 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, "Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT]" <beau.t.blanding at nasa.gov<mailto:beau.t.blanding at nasa.gov>>, "sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>" <sis-dtn at mailman.ccsds.org<mailto: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://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fdocs.google.com%2Fdocument%2Fd%2F1P8g8_2HPnadf3RfAdP6tltI4H_kwiL-p%2Fedit%3Fusp%3Dshare_link%26ouid%3D112263620729744601172%26rtpof%3Dtrue%26sd%3Dtrue__%3B!!PvBDto6Hs4WbVuu7!fmK28hRCJGziSKAiLWtldRMS9EO8YneHSoKu93EdeWZkVPN3SCYN5vaM29QgO89Mm8iaC6zB%24&data=05%7C01%7CFelix.Flentge%40esa.int%7C571a1469ceb2473f853408dac672d00b%7C9a5cacd02bef4dd7ac5c7ebe1f54f495%7C0%7C0%7C638040493666071731%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W8kYhc20w8Ue261anPAgk2CEsq%2FDKV9lVfTVrUjun9k%3D&reserved=0> if you'd like to take a look first, or we can start by walking through them together.

                                v/r,

                                --keith

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 43715 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20221115/0747edf7/attachment-0001.bin>