[HacDC:Byzantium] cjdns review

[Ben Mendis]

To be specific, I don't think CJDNS is a bad technology. On the
contrary, I think it is interesting and will have a valuable role in
influencing then next few decades of the Internet. However it's not a
replacement for the use cases that Byzantium Linux or Commotion Wireless
try to address. While most of the CJDNS fanboys will try to tell you
that CJDNS can replace Layer-3 routing (and they're not completely
wrong) the problem is that it's not a practical alternative for our
deployment model.

Creating connections between nodes in CJDNS requires more collusion in
that new nodes must know the correct public key and password to create a
link with another existing node. This is good for security, but not
conducive to the rapid and organic deployment that we're looking for.
Furthermore, as a mobile node roams from one AP to the next, they would
need to re-negotiate the link (and discover key/pw again) with each new AP.

If the AP offers up some kind of layer-3 routing to other networks which
have nodes (such as the Internet) then you don't have the re-negotiation
problem. However, in our use case Internet access is not a guarantee.
And what provides for that layer-3 routing anyways? We'll that's exactly
what Byzantium and Commotion try to solve with OSLR or Babel or BATMAN.

Furthermore, CJDNS doesn't route IPv4 traffic to the IPv4 Internet, at
least not by itself. You would need to do some kind of 4-in-6 tunneling.
Which is yet another layer of overhead and latency, and another "moving
piece" that can fail and disrupt service for users.

So based on my understanding of CJDNS, it's not a competing technology
in our problem domain, although some of the functionality overlaps. And
in certain cases, they are actually complimentary projects. CJDNS, in
its typical and most practical deployment, is an overlay network. That
means it needs an existing network to run on top of, and that's exactly
what Byzantium or Commotion can provide.


A couple of other points of interest I've come across.

Starting with Wikipedia (I know it's not authoritative and often out of
date).
" The address is generated initially when a node is set up, through a
brute-forced key generation process (keys are repeatedly generated until
the result of double SHA-512 begins with 0xFC). This process is unique,
as it guarantees cryptographically bound addresses (the double SHA-512
of the public key), sourced from random data (private key is random
data, public key is the scalar multiplication of this data)."

Two things. First of all, wouldn't brute-forcing the key generation
exhaust the entropy available in /dev/random and force the use of less
random bits from /dev/urandom? Also, don't the public/private keys need
to be based on prime numbers, not just random numbers? The strength of
RSA is the assumption that factorization of large _prime_ numbers is
mathematically a hard problem to solve. This last part is probably just
the Wiki-author's misunderstanding. I'm giving cjd the benefit of the
doubt because he seems like he would know better.

>From the projectmeshnet wiki.
"While you can technically add as many as 255 peers, more is not better.
The software likes to run with about 3 peers and will work fine even if
only 1 of them is functioning. ~ CJD"

A limitation of 255 peers seems arbitrary and actually quite low. I'm
sure it would be fine for permanent infrastructure nodes, however it
seems quite restrictive for mobile ad-hoc nodes which might roam in and
out of range with dozens or hundreds of other nodes.

I still think CDJNS is a cool project and I'm keeping an eye on it, just
not for rapid deployment in disaster relief scenarios. The usability
cost, while modest compared to alternative overlay networks, is still
quite high in comparison to the solution we have been building.
Hypothetically, we could make CJDNS just as automatic, but in the
process we would be discarding some of the security benefits it's trying
to achieve.

No one tool is a panacea for the problems facing the Internet. The use
cases we are facing today are so diverse that no single solution can
encompass them all. Projects like CJDNS and Byzantium are successful
because they focus on solving one chunk of the problem space and doing
it as well as possible without getting distracted by every shiny use
case that comes along. We also benefit from adherence to standards and
best practices that allow us to interoperate with the other projects
that are solving other chunks of the problem space.

That's my $0.02.

Ben the Pyrate

On 11/26/2012 09:25 AM, Eugen Leitl wrote:
> Guys, can you give me the beef with what you think
> is wrong with cjdns' design? Please make sure to
> look at the latest work, including L2 transport.
>
> I'll forward your comments to cjd.
>




----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE