> Coordination-less globally unique addressing and identification
> Fully self-configuring multi-hop routing
> Unforgeable packet delivery confirmations
> Initiator anonymity
So the noisiest protocol ever with zero flood protection? Anyone knows better than my superficial hot take? But I doubt they solved those problems for real, that would be real news and academic progress.
generally speaking, networks that support anonymity have much better flood protection than things like tcp/ip. ccn routers won't send you any data packets you haven't sent an interest packet for; i'm guessing reticulum works similarly
that's an obviously good question to ask, and i'm not sure what the answer is. the original ccn work by van jacobson et al. doesn't really attempt any security. one obvious thing to try is for a router to rate-limit its forwarding of the interest packets coming in on any one port, especially if it has a lot of active interest packets from that port already (in ndn systems the router has to remember where interest packets came from so that it can forward any answering data packets out the right port, so this doesn't require maintaining any extra data.) but i don't know if existing ndn work tackles this problem or what approaches have been found to work
Sure; but distributed mesh networks feel like another area where Sybil Attacks [1] can rear their ugly heads. This is a fundamentally hard problem to solve in all distributed systems without a coordinating authority.
The blockchain approach basically bootstraps said authority, and comes with tons of additional baggage. It's the only one I'm aware of that has real countermeasures to Sybil attacks though (in a sense; 51% attacks can also look a lot like a Sybil attack with the right glasses on)
i agree about the blockchain, though now possibly there are multiple viable approaches under that rubric now that ethereum has abandoned pow
there are a lot of possible approaches to the problem, though
hashcash for announcing new destinations is one possible measure
reserving most of the bandwidth for established connections to which both parties are indicating their continuing enthusiastic consent is another, and one which the circuit-switched pstn does implicitly, which is why your phone calls wouldn't drop or skip when there was a commercial break in prime-time tv. reticulum seems to do this by reserving 97% of bandwidth for non-announcement traffic, though i might be misunderstanding
the agorics 'digital silk road' paper from 01995 (unrelated to the later darknet market) describes another approach: include a source route and postage on every packet, with each network provider deducting however much postage it feels like deducting, and keeping track of bilateral account balances with each peer network (postage sent minus postage received). if the postage runs out, your packet gets lost, and the sender can choose to try resending it over the same route with more postage or routing it over a less expensive network. periodic cash settlement between network service providers zeroes out any persistent imbalance in cash sent and received: http://www.cap-lore.com/Agorics/Library/dsr.html. i don't think this has ever been implemented, though current nsp peering agreements do resemble it to some degree. the original paper suggested using eft for the periodic settlements, but nowadays you could very reasonably do it with something like ether
you can supplement the established-connection-prioritizing mechanism with a granovetter-diagram introducer mechanism: if alice has an established connection to bob, and bob has an established connection to carol, bob can dedicate some of his bandwidth on those two connections to passing messages between alice and carol. he can do this either completely at the application layer, with no support from lower layers of the network, like an irc server or turn server, or potentially with support from the network layer to find a more efficient and reliable route. (reticulum seems to support this; bob can pass alice's destination to carol or vice versa, which the manual seems to say eliminates the need for the announce mechanism, though i don't yet understand how the protocol works.) this allows bob to prioritize such connection requests using information that isn't available at the network layer, such as whether alice and/or carol have passed a captcha and/or are paying him, who they were introduced to him by, who they've introduced him to in the past, and what valuable data they've sent him. if bob repeatedly introduces alice to people she doesn't like talking to, she might cut off contact with bob, or at least look on his future introductions with a jaundiced eye and not allocate them much bandwidth
fwiw, those seem to apply to only a single destination, and any node can sybil up as many destinations as it wants, right? `announce_cap` seems more relevant
is there a place where you've written down the threat model reticulum is intended to defend against? it's hard for me to evaluate its security measures without that context
I'm not sure there is a formal threat model yet (I'm not a maintainer), but there has been discussion regarding this topic. You can checkout the Github forum page (https://github.com/markqvist/Reticulum/discussions) and there is also an Element channel at #reticulum:matrix.org
The threat model would be highly dependent on the carrier used. For example, if you're using LoRa an adversary would be using far different methods of disruption when compared to a traditional overlay network.
> Coordination-less globally unique addressing and identification
> Fully self-configuring multi-hop routing
> Unforgeable packet delivery confirmations
> Initiator anonymity
So the noisiest protocol ever with zero flood protection? Anyone knows better than my superficial hot take? But I doubt they solved those problems for real, that would be real news and academic progress.