[Battlemesh] Mesh Routing Protocol Comparison

Caleb James DeLisle cjd at cjdns.fr
Sun May 3 12:45:22 CEST 2020


Hi Dave,

I checked the RFC security properties and it seems that this is mostly to protect against a war 
driving joker turning a network into a big blackhole (?)

I can definitely see the value of that, but once you start allowing people to flash software onto 
any old device and join the network, you're kind of back where you started.

I'm optimistic that cjdns/yggdrasil like algorithms will eventually get good enough that it only 
makes sense to use these types of algorithms going forward - assuming we're willing to accept a bit 
of signature checking overhead.

Thanks,
Caleb



On 02/05/2020 17:30, Dave Taht wrote:
> On Sat, May 2, 2020 at 8:16 AM Caleb James DeLisle <cjd at cjdns.fr> wrote:
>>
>> Hey Mortiz,
>> This data is fantastic. Thank you for putting this together. I'm surprised that the cjdns DHT stuff
>> didn't come in last at everything. That algorithm is deprecated but left on because it does work
>> when no route server is available. I'd really like to migrate to Yggdrasil algorithm for these cases.
>>
>> Obviously I'd love to have the kind of scaling properties of something like Babel, but cjdns and
>> Yggdrasil have the additional constraint of having been designed to operate in an environment with
>> hostile nodes.
> 
> In part, it's my hope the hmac code in a babel branch, answers some of
> that concern. Would love to see
> more people testing that! https://github.com/jech/babeld/pull/52
> 
> the biggest barrier for that code is rotating the hmac.
> 
> I think the bird version already has working hmac code that was
> submitted fairly recently.
> 
> the relevant ietf proposal is:
> https://tools.ietf.org/html/draft-ietf-babel-hmac-10 (There's also a
> dtls thing: https://tools.ietf.org/html/draft-ietf-babel-dtls-09)
> 
> However, it is still kind of trivial to do ddoses and so on with other
> common tricks (arp spoofing, ra spoofing, etc)
> 
>> When I read the mobility testing, I'm not completely clear as to whether I'm looking at drop rate of
>> pings between nodes who have themselves changed peer relationships, or between stable nodes in a
>> globally dynamic network. In the second case I would intuitively expect to see a good showing from
>> Yggdrasil since it will just switch to tree routing when it gets confused. However if the
>> destination moves then that has to go through the DHT, and we might find this is in fact hobbling
>> the protocol.
>>
>> If this is in fact the case, then my intuition is that the DHT nodes should gossip link state
>> updates to their keyspace neighbors and communicating nodes should be able to subscribe to receive
>> link state updates of those with whom they have active sessions.
> 
> I really, really, really wish y'all might observe what happens to your
> protocols when the network is actually in use,
> not just carrying routing traffic.
> 
>>
>> Thanks,
>> Caleb
>>
>> On 01/05/2020 13:11, Moritz Warning wrote:
>>> Hi folks,
>>>
>>> I wrote a virtual test setup that supports multiple mesh routing protocols and produces nice graphs.
>>> The whole setup is based on Linux network namespaces:
>>>
>>> https://github.com/mwarning/meshnet-lab
>>>
>>> So far, there are some preliminary results with a focus on convergence, mobility and scalability.
>>>
>>> https://github.com/mwarning/meshnet-lab/blob/master/results/README.md
>>>
>>> Keep in mind that these results are not "final" yet, as hardware limitations and pathological behavior play a dominat factor in some of the results.
>>> I hope to be able to present the refined results at the next Battlemesh and have a lively discussion!
>>>
>>> Best,
>>> mwarning
>>>
>>> Btw.: if you happen to have beefy server with good CPU/IO speed - let me know.
>>> _______________________________________________
>>> Battlemesh mailing list
>>> Battlemesh at ml.ninux.org
>>> https://ml.ninux.org/mailman/listinfo/battlemesh
>>>
>> _______________________________________________
>> Battlemesh mailing list
>> Battlemesh at ml.ninux.org
>> https://ml.ninux.org/mailman/listinfo/battlemesh
> 
> 
> 


More information about the Battlemesh mailing list