[Sis-dtn] [EXTERNAL] Re: [EXT] RE: Telecon 20220728

Thu Jul 28 18:43:34 UTC 2022

FYI, attached is the presentation & discussion slides I used last May to present our DTN DNS ideas to the IPNSIG.  Lots of questions remain of course, and since Scott Burleigh has changed the definition of a “region” to be a collection of nodes that all have the same contact plan, some additional things have to be considered in the next to the last slide. In any case, this is what I’ve been working on to support an initial prototype of an AMMOS Mars DTN Relay network, as well as something to test out with both IPNSIG and the DEN if we can generate interest in re-awakening the DTN Readiness Program’s DTN Engineering Network.

Regards
Leigh

J. Leigh Torgerson
Space Communications Networking Architect
Protocol Technology Lab Manager
Communications Architectures & Research (332)
Jet Propulsion Laboratory
4800 Oak Grove Drive M/S: 238-420
Pasadena, CA 91109
Office: (818) 393-0695
Email: ltorgerson at jpl.nasa.gov<mailto:ltorgerson at jpl.nasa.gov>

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of "Dr. Keith L Scott via SIS-DTN" <sis-dtn at mailman.ccsds.org>
Reply-To: "Scott, Keith L." <kscott at mitre.org>
Date: Thursday, July 28, 2022 at 10:28 AM
To: "Tomaso.deCola at dlr.de" <Tomaso.deCola at dlr.de>
Cc: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>
Subject: [EXTERNAL] Re: [Sis-dtn] [EXT] RE: Telecon 20220728

Concur.  I *think* those will ‘fall out of’ the BPsec and NM discussions, but yes, we should ensure that we have a comprehensive architecture / plan that all hangs together.

                                --keith

From: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de>
Date: Thursday, July 28, 2022 at 12:13 PM
To: Dr. Keith L Scott <kscott at mitre.org>
Cc: sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Subject: [EXT] RE: Telecon 20220728
As to the “homework” “what to do next”, we should also address at some point the remarks made by Peter Shames also in relation to the considerations drawn in IOAG about the overall security framework in CCSDS and missing elements in DTN (i.e. those going beyond BPSEC). Specifically he pointed in a presentation shared in June to: “Key management and identity mechanisms need to be defined,
Secure network management framework for multi-agency interoperability needs to be defined”.

Tomaso

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Dr. Keith L Scott via SIS-DTN
Sent: Donnerstag, 28. Juli 2022 17:56
To: sis-dtn at mailman.ccsds.org
Subject: [Sis-dtn] Telecon 20220728

SIS-DTN

IETF DTN WG Meeting

CCSDS:

• Talked about our ‘requirements’ for auditing / accounting / reliability

• Plan forward: do work, ensure that IETF DTN WG is cognizant of it; coordinate as makes sense

Naming:

• I wasn’t able to make the second half of the DTN WG meeting where naming was discussed

• Apparently Airbus has some needs that aren’t well-met by ‘just’ an IPN Node #, looking for something more

• Scott proposed using ‘just’ IPN node numbers as the identification mechanism and developing ‘DNS-like’ and ‘whois-like’ services:

• DNS-like: transforms mnemonics into IPN node numbers

• whois-like: translates IPN node numbers into points-of-contact

• Need to secure both of these services (obviously)

LTP Orange:

Need use cases / metrics for when orange is a win.

• E.g. with a latency of xxx and an LTP segment loss rate of yyy, using the metrics: (total memory*time used by receiver, total memory*time used by transmitter) ...

If we can’t find a use case that is compelling, we shouldn’t include Orange (keep the protocol as simple as possible).

Jonathan’s bit ordering question

In RFC9171, things like the Bundle Processing Control Flags refer to the ‘least significant bit’.  Note that the BPCF is a bit field represented by a CBOR unsigned integer.  In the integer representation of the CBOR unsigned int, ‘least significant bit’ is unambiguous (It’s the bit that determines whether the integer is odd or even).

We don’t really care how the link layer might mangle things for transmission, so long as what is received is interpretable as (the same) CBOR unsigned integer, so the LSB makes sense.

Homework

• LTP Orange Question

• What to do next?  BPsec Green, NM (Blue, Green), LTP

Simon’s question about ADMs

We pushed a lot of things out of the BPv7 profile for expediency.  Many of those SHOULD be addressable via network management.  We should work a set of ADMs (e.g. BPv7, ION, LTPv2, ...) in concert with the ‘base’ NM protocol work as a sanity-check to ensure that the NM protocol will in fact support what we need.  Use these to address the issues we pushed out of the base CCSDS BPv7 profile.

There’s an (old) draft BP ADM here: https://datatracker.ietf.org/doc/draft-birrane-dtn-adm-bp/<https://urldefense.us/v3/__https:/datatracker.ietf.org/doc/draft-birrane-dtn-adm-bp/__;!!PvBDto6Hs4WbVuu7!YBcwEKvxai6h74R_WFOq89JGPuwabmY9je1xfMHbcbWdT4w5bGba2JH_Mlr3N9pNHkPGEg$> (thanks Sarah, for pointing this out).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220728/a633e374/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DTN Network Ops - DTNNS - IPNSIGv2.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 4089776 bytes
Desc: DTN Network Ops - DTNNS - IPNSIGv2.pptx
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220728/a633e374/attachment-0001.pptx>