What are some notable differences between cjdns and tinc?

[dalanmiller]

Came across tinc the other day and was wondering what the major differences are?

[ghost]

Excellent question, I've been meaning to have a look at tinc for a while so I did that now. I hope this helps, let me know if you have more questions.

The major differences I see on first glance:

Tunneling

Cjdns can tunnel arbitrary IPv4/IPv6 traffic just like tinc, although tinc might be a bit more flexible here. The important distinction is that cjdns builds an encrypted overlay network, and cjdns's IPTunnel is one protocol on top of that, with e.g. the fc00::/8 network being another, and the Pathfinder DHT yet another. There can be any number of protocols on top of cjdns's overlay network.

Routing

tinc claims "full mesh routing" which is technically true, but a bit of an exaggeration. In lack of a routed overlay network, tinc tries do establish direct connections between nodes that want to exchange data. If one of the ends or (both) are behind NAT, a node in between will try to facilitate hole-punching similar to STUN. My experience with IPFS is that NAT traversal is brittle and hairy.

Cjdns does packet switching on top of its overlay network, and uses Pathfinder to discover and maintain routes through the network. There is no need for a direct connection between two nodes that want to communicate.

Address allocation

tinc doesn't seem to take any part in address allocation, instead it advises to use DHCP or MDNS/avahi.

• http://www.tinc-vpn.org/examples/zeroconf-ip-and-dns/
• http://www.tinc-vpn.org/examples/

tinc seems to be able to carry arbitrary IPv4 and IPv6 networks, while cjdns operates strictly within fc00::/8. Cjdns's advantage here is that its IP addresses are double-SHA512 hashes of the node's public key. This makes address spoofing impossible.

Crypto

Cjdns uses its own CryptoAuth protocol for secure connections between peers, which uses ed25519, poly1305, and salsa20, included in djb's cnacl.

SPTPS (Simple Peer-to-Peer Security) is the protocol which tinc nodes use to establish a secure connection between each other.

SPTPS is based on TLS 1.2, but has been simplified: there is no support for exchanging public keys, and there is no cipher suite negotiation. Instead, SPTPS always uses a very strong cipher suite: peers authenticate each other using 521 bits ECC keys, Diffie-Hellman using ephemeral 521 bits ECC keys is used to provide perfect forward secrecy (PFS), AES-256-CTR is used for encryption, and HMAC-SHA-256 for message authentication.

-- http://www.tinc-vpn.org/documentation-1.1/Simple-Peer_002dto_002dPeer-Security.html#Simple-Peer_002dto_002dPeer-Security

The 1.0 branch uses OpenSSL exclusively. Although this library is well known and widely available, it has two drawbacks: it is quite large and its license is not completely compatible with the GPL. In 1.1 there will be an abstraction layer that allows tinc to be linked with different cryptography libraries. At least OpenSSL and libgcrypt will be supported.

-- http://www.tinc-vpn.org/goals/

Layer 2 vs. Layer 3

It looks like tinc can transport Ethernet frames too. Cjdns is limited to IPv6.

• http://redmine.the.re/l2mesh/l2mesh.html

[Kubuxu]

About Ethernet frames, @magik6k was doing some experiments with Level 2 tunnelling over cjdns.

[dalanmiller]

Thank you very very much for the detailed explanation @lgierth, I think there's a lot of development mindshare in this domain at the moment (just based on anecdotal zeitgeist) and for developers/tinkerers it makes it really easy to not worry about NAT and setup your private infrastructure with something like cjdns.

Is hyperboria/cjdns now the main development repo instead of cjdelisle/cjdns?

[Kubuxu]

cjdelisle/cjdns is still the main repo, hyperboria/cjdns is community curated repo with issue tracker so cjdelisle can focus on the software and we can solve smaller bugs, pull request smaller changes in bigger batches and so on.

[christianbundy]

In lack of a routed overlay network, tinc tries do establish direct connections between nodes that want to exchange data. If one of the ends or (both) are behind NAT, a node in between will try to facilitate hole-punching similar to STUN.

Does this mean that Tinc only uses other nodes to negotiate traversal whereas cjdns actually routes your traffic through those nodes? I'm imagining something like this, where the solid line is the main connection and the dashed lines is just for traversal:

[ghost]

The cjdns graph is definitely accurate, about tinc I'm not sure -- you'd have to ask the tinc people or their documentation, my comment above is already 2.5 years old.

[florianjacob]

Does this mean that Tinc only uses other nodes to negotiate traversal whereas cjdns actually routes your traffic through those nodes?

Not quite, tinc would start with forwarding traffic through e and simultaneously try to negotiate a direct connection between d and f, using NAT traversal techniques if necessary. If that succeeds, it will transparently switch over the flow of packets to the new direct connection, if not, traffic will continue to be forwarded through e.

[kpcyrd]

@florianjacob interesting! do you happen to know if tinc is going to retry periodically to check if a direct connection can be established at a later point in time (eg after switching networks)?

[florianjacob]

@kpcyrd there's definitely a retry when switching networks, as the tunnel has to be renewed anyway due to the IP address change. I'm not totaly sure of regular periodic retries though when you don't swtich networks, as I never have sat behind NATs that couldn't be traversed.

[cosmojg]

Is there any chance that Hyperboria will ever be tinc-compatible?

[kpcyrd]

@CosmoJG no, this is out of scope