[Sis-dtn] FW: [EXTERNAL] BPv7 PID resolution

Dr. Keith L Scott kscott at mitre.org
Tue Nov 15 18:54:35 UTC 2022 

Some folks were having difficulties reading Peter’s emails.
 
Forwarding unsigned.
 
                                --keith
 
From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Date: Tuesday, November 15, 2022 at 12:47 PM
To: Dr. Keith L Scott <kscott at mitre.org>, Cerf, Vinton <vint at google.com>, Felix Flentge <Felix.Flentge at esa.int>
Cc: 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

Hi Keith,
 
Yes, something like that is what makes sense to me.  It is transparent about what will need to be done without being prescriptive at this point, where the machinery that would help is still unspecified.  I think of it as a sort of “leg up”.
 
You did not mention it, but I assume that you are still going to include some sort of SANA node registry too.  Right?
 
Thanks, Peter
 
 
From: Keith Scott <kscott at mitre.org>
Date: Tuesday, November 15, 2022 at 9:27 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, Vint Cerf <vint at google.com>, Felix Flentge <Felix.Flentge at esa.int>
Cc: "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

 

I certainly favor transparency – we should tell folks what they need to do manually currently.  I’d LIKE to put that in a green book, like an updated SSI Architecture book, but if we need to add something to section 2 of the BPv7 profile that says something like the following, that’d probably work.
 
Here’s how to get a new node onto the BP network:
1) Get a node number from SANA (to ensure that you don’t conflict with somebody else)
2) Figure out who you want to connect to (immediate BP neighbor(s))

1. There’s not currently a good way of find out where the nodes are; you have to know somebody and figure out from there where there’s a good node for you to connect to.  MAYBE we should recommend that each center-equivalent with an agency/entity stand up a ‘border’ BP router?  That’d be a really good way to get stuff started.

3a) Call somebody in charge of the nodes that you want to connect to to talk about convergence layers and contact plans and how to connect
3b) Talk to the folks with whom you want to communicate (endpoints) about security policy and other requirements.  

1. Those endpoints may or may not implement BPsec, or may have other implementation-specific mechanisms (e.g. some sort of firewall-like capabilities)
2. Eventually BPsec is coming, so be planning to go that way.

3c) If you want to get information from ‘the network’ (network management) you’re going to need to work getting that information with the individual bp node managers (people).

1. Network management isn’t standardized yet (anywhere, CCSDS *or* IETF) so it’s likely that anything you’ll be able to get is going to be custom.

4) Understand that this BP network we’re building is a network.  Once you connect to the network, anybody on the network will (probably) be able to send bundles to your node.

1. BPsec, if you implement it and if you tighten your security policy, should mitigate risk here
2. We need to develop firewall-like mechanisms in our implementations, or acquire other implementations that have them.

 
Is that the kind of thing you’re looking for?
 
                                v/r,
 
                                --keith
 
 
From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Date: Tuesday, November 15, 2022 at 12:09 PM
To: Cerf, Vinton <vint at google.com>, Felix Flentge <Felix.Flentge at esa.int>, Dr. Keith L Scott <kscott at mitre.org>
Cc: 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

Vint, Felix, Keith, et al,
 
I get the point about wanting to have this spec out sooner rather than later, and I am not trying to stall that event.  I do see these missing pieces as being part of the functional superstructure for the SSI and not service management (which in my mind includes contact planning and related configuration info), nor network management (which includes routing updates and controls).  I think that those can wait.  An important part of what is missing in my mind is the SSI equivalent of DNS and WhoIs, both of which, if I am not mistaken, were present in the early days of the Internet.
 
In the case of the SSI we really do not have to create anything new to create some useful registries, we can just use what is there in the SANA already.  Perhaps wise council is to say that we might be jumping the gun by doing that and moving in a direction that, on further consideration, is not the long term direction we would want to go for our nascent Solar System Internet.   I can abide with that result, but I feel we are missing an obvious opportunity to start to govern this thing we are creating.
 
If that is what consensus dictates that is fine.  But at that point I think we need to tell the cottage industry folks, in this SSI Stage 2a, that they must fend for themselves and cook up local / implementation-based solutions to manage node IDs, naming, identities and keys.  Or do you all think that we should just stay silent on that subject too?
 
Thanks, Peter
 
 
From: Vint Cerf <vint at google.com>
Date: Tuesday, November 15, 2022 at 3:18 AM
To: Felix Flentge <Felix.Flentge at esa.int>
Cc: Keith Scott <kscott at mitre.org>, 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: Re: [Sis-dtn] [EXTERNAL] BPv7 PID resolution

 

Felix, thanks for pragmatic advice - it's really important to have blue book in hand for BPv7 sooner rather than later.
Operational experience will help us find the answers to dangling participles.

 

v

 


 
On Tue, Nov 15, 2022 at 2:30 AM Felix Flentge via SIS-DTN <sis-dtn at mailman.ccsds.org> wrote:


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).
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn





 

-- 
Please send any postal/overnight deliveries to:

Vint Cerf

Google, LLC

1900 Reston Metro Plaza, 16th Floor

Reston, VA 20190

+1 (571) 213 1346

 


 

until further notice

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20221115/3678f43a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7621 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20221115/3678f43a/attachment-0001.bin>

More information about the SIS-DTN mailing list