Subj : Re: Is binkp/d's security model kaputt?
To   : deon
From : tenser
Date : Thu Sep 09 2021 02:08 am

On 04 Sep 2021 at 09:31a, deon pondered and said...
 
 de> There are 2 parts to a packet - header and payload, and I think the
 de> header can be reduced quite a bit (currently its 58 chars). I've created
 de> a format that is 50 chars - for a full 5D packet, although I'm wondering
 de> if the 5D idea should be dropped and only 4D retained (that brings it
 de> back to 37 chars). It could be trimmed a bit more if the "src" was taken
 de> from the calling system, saving another 8 chars. Using the packet name
 de> itself could reduce the header by a further 8 chars or so - and I'm
 de> playing with that idea. (So its down to 21 from todays 58).

Well, I'm not so much interested in shaving bytes off of these
data as I am reducing structural inefficiencies that cause things
to, say, grow linearly with the size of the network.  The Path:
mechanism used on USENET to detect duplicates and loops seems
universally superior to FTN's `SEEN-BY` lines.

In terms of actual data sent over the wire, however, a textual
serialization using an extensible format seems superior to binary
formats.  For that matter, the entire FTN naming scheme seems
antiquated, though I don't see a great way to remove that short
of a wholesale replacement (which may itself be worthwhile).

 de> With the header, the receiving system could calculate a checksum on the
 de> packet and determine whether it accepts the payload. (Because its seen
 de> that packet before or not - or if it needs to resume from an offset.)

Yup.  A collision-resistent hash as a mechanism for detecting
duplicates seems reasonable.  Taking again from USENET, where
"Message-Id:" was defined to be globally unique, a similar
mechanism could be used here.  Again, we run into the legacy
angle; to support legacy systems, it'd have to be something
else, even though FTN has defined a message-id equivalent,
since it's not universally implemented.

 de> Yup, there is no reason that the "core" follow the old ways.

Agreed.

--- Mystic BBS v1.12 A46 2020/08/26 (Linux/64)
 * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

.