Subj : Re: Is binkp/d's security model kaputt?
To   : tenser
From : deon
Date : Sat Sep 04 2021 09:31 am

  Re: Re: Is binkp/d's security model kaputt?
  By: tenser to Oli on Sat Sep 04 2021 03:24 am

Howdy,

 > Not only that, they're not as efficient as people think.  There's
 > a lot of wasted space in .PKT (space for fields that are never filled
 > in), and the need to record every node that's seen a message doesn't
 > seem scalable.

Yes I've been working on this randomly after the last few months - trying things out as I think of something.

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

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

The payload is the messages, and they too could have a "header" (which it kinda has today) and (sub) "payload" portion that determines if the message is accepted is discarded (I havent thought this part through yet). The idea being from the message header the tosser decides whether it is a dupe, loop, too old, or relevant "area" without having to process the current seen-by/path/msgid, etc.

 > I thought about these problems a bit when I wrote ginko, and became
 > convinced that the real solution was to serve legacy systems at the
 > edge.  For backbones and hubs, use new formats with a standard
 > canonicalization and checksumming for duplicate detection and article identification, but only translate to/from legacy formats when
 > communication with legacy software.

This is the approach that I've been thinking of too. I also want to bring in an element of high availability, so that a single hub going offline (scheduled or awol) that another system accepts the packets (without having to rebuild them).

 > Honestly? The whole hunk of poo ought to be tossed and re-architected.
 > Using the things we've improved on in the last 40 years will actually
 > simplify the whole mess, making it easier to move to IoT devices and
 > so on.

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


....лоеп
--- SBBSecho 3.14-Linux
 * Origin: I'm playing with ANSI+videotex - wanna play too? (21:2/116)

.