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

[Dr. Keith L Scott]

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/ (thanks Sarah, for pointing this out).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220728/97591921/attachment.htm>