<div dir="ltr">Felix, thanks for pragmatic advice - it's really important to have blue book in hand for BPv7 sooner rather than later.<div>Operational experience will help us find the answers to dangling participles.</div><div><br></div><div>v</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 15, 2022 at 2:30 AM Felix Flentge via SIS-DTN <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">All,<br>
<br>
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:<br>
<br>
1. CCSDS Service Management (upcoming) standards, in particular, the Service Catalogue (which may or may not be related to SS&A)<br>
2. Functional Resource Model which could cover more dynamic aspects like configuration of some nodes<br>
3. DTN Network Management<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
Felix<br>
<br>
From: SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">sis-dtn-bounces@mailman.ccsds.org</a>> On Behalf Of Dr. Keith L Scott via SIS-DTN<br>
Sent: 14 November 2022 20:01<br>
To: Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>>; Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a>>; <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><br>
Subject: Re: [Sis-dtn] [EXTERNAL] BPv7 PID resolution<br>
<br>
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.<br>
<br>
--keith<br>
<br>
From: SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">sis-dtn-bounces@mailman.ccsds.org</a><mailto:<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">sis-dtn-bounces@mailman.ccsds.org</a>>> on behalf of Dr. Keith L Scott via SIS-DTN <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><mailto:<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>>><br>
Date: Monday, November 14, 2022 at 1:58 PM<br>
To: Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a><mailto:<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>>>, Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a><mailto:<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a>>>, <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><mailto:<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>> <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><mailto:<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>>><br>
Subject: Re: [Sis-dtn] [EXTERNAL] BPv7 PID resolution<br>
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.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
--keith<br>
<br>
<br>
From: Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a><mailto:<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>>><br>
Date: Monday, November 14, 2022 at 1:42 PM<br>
To: Dr. Keith L Scott <<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a><mailto:<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a>>>, Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a><mailto:<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a>>>, <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><mailto:<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>> <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><mailto:<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>>><br>
Subject: Re: [EXTERNAL] BPv7 PID resolution<br>
Hi Keith,<br>
<br>
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.<br>
<br>
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?<br>
<br>
Have you guys addressed this in any way?<br>
<br>
Thanks, Peter<br>
<br>
<br>
From: Keith Scott <<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a><mailto:<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a>>><br>
Date: Monday, November 14, 2022 at 5:00 AM<br>
To: Peter Shames <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a><mailto:<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>>>, "Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT]" <<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a><mailto:<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a>>>, "<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><mailto:<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>>" <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><mailto:<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>>><br>
Subject: [EXTERNAL] BPv7 PID resolution<br>
<br>
Peter,<br>
<br>
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:<br>
<br>
<br>
* 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.<br>
<br>
<br>
* 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.<br>
<br>
<br>
Some issues, like the 'late binding' discussion probably require some discussion to resolve.<br>
<br>
Do you have some time to start working through the PID items? The document is here: <a href="https://docs.google.com/document/d/1P8g8_2HPnadf3RfAdP6tltI4H_kwiL-p/edit?usp=share_link&ouid=112263620729744601172&rtpof=true&sd=true" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1P8g8_2HPnadf3RfAdP6tltI4H_kwiL-p/edit?usp=share_link&ouid=112263620729744601172&rtpof=true&sd=true</a><<a href="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" rel="noreferrer" target="_blank">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</a>> if you'd like to take a look first, or we can start by walking through them together.<br>
<br>
v/r,<br>
<br>
--keith<br>
<br>
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 (<a href="mailto:dpo@esa.int" target="_blank">dpo@esa.int</a>).<br>
_______________________________________________<br>
SIS-DTN mailing list<br>
<a href="mailto:SIS-DTN@mailman.ccsds.org" target="_blank">SIS-DTN@mailman.ccsds.org</a><br>
<a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn" rel="noreferrer" target="_blank">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Please send any postal/overnight deliveries to:</div><div><div>Vint Cerf</div><div>Google, LLC</div><div>1900 Reston Metro Plaza, 16th Floor</div><div>Reston, VA 20190</div><div>+1 (571) 213 1346<br></div><div><br style="color:rgb(34,34,34)"></div></div><div><br></div><div>until further notice</div><div><br></div><div><br></div><div><br></div></div></div>