[Sis-dtn] [EXTERNAL] BPv7 PID resolution
Vint Cerf
vint at google.com
Tue Nov 15 11:18:31 UTC 2022
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/d29fbf23/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/d29fbf23/attachment-0001.bin>
More information about the SIS-DTN
mailing list