[Sis-dtn] [EXTERNAL] BPv7 PID resolution
Vint Cerf
vint at google.com
Tue Nov 15 18:34:58 UTC 2022
WHOIS was early on a manual directory
DNS did not exist - hosts.txt was manually created and disributed.
v
On Tue, Nov 15, 2022 at 12:26 PM Dr. Keith L Scott <kscott at mitre.org> wrote:
> 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))
>
> - 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.
>
> - Those endpoints may or may not implement BPsec, or may have other
> implementation-specific mechanisms (e.g. some sort of firewall-like
> capabilities)
> - 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).
>
> - 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.
>
> - BPsec, if you implement it and if you tighten your security policy,
> should mitigate risk here
> - 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 <(571)%20213-1346>
>
>
>
>
>
> until further notice
>
>
>
>
>
>
>
--
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/bebb6020/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3995 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20221115/bebb6020/attachment-0001.bin>
More information about the SIS-DTN
mailing list