Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] CJDNS hype

Michael Rogers michael at briarproject.org
Tue Jul 16 02:51:29 PDT 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Caleb,

Thanks for your reply. I'm not trying to cause trouble for CJDNS, as
you put it - I'm just pointing out that robust routing without a
central authority is a problem with a long research history that
contains some widely applicable results. I think some of those results
probably apply to CJDNS, but I don't know much about how it works, so
I've responded inline asking for more detail on some of your responses.

More generally, could you explain how CJDNS detects and routes around
faults?

On 15/07/13 20:09, Caleb James DeLisle wrote:
>> The adversary can create imaginary networks of arbitrary size and
>> structure, composed entirely of Sybil identities, to absorb our
>> measurement resources. It's like playing whack-a-mole with an
>> infinite number of moles. ;-)
> 
> Which will all have a common route prefix.

Could you explain what a route prefix is and how you can be sure that
a set of Sybil identities will share a route prefix? How is the route
prefix used in detecting and routing around faults?

> Lazy cjdns will not route to your absurdly long path if it has
> short paths to the destinations it wants to reach. It will also not
> care much about your zillion nodes because it has fast nodes
> already in it's routing table and they're working just fine.

Could you explain why a set of Sybil identities will produce an
absurdly long path, and how you can be sure that the routing table has
already been populated with fast non-Sybil nodes?

It sounds like you're saying that a Sybil attack won't work because
the victims have already populated their routing tables prior to the
attack - but what about a new node joining the network after the
attack has started?

> You can feign existence of as many nodes as you want but you can't
> feign low latency and short labels, in fact the more nodes you
> generate, the longer your labels will become to accommodate them
> all, your (comparatively) high latency links with long switch
> labels look just like a terrible route which cjdns finds and
> rejects all of the time.

It's true that you can't feign low latency. But if low latency is the
way to get traffic routed through you, the adversary can add genuinely
fast nodes and links to the network, in order to attract lots of
traffic, in order to selectively drop certain traffic.

I don't see why you can't feign short labels. If short labels are
desirable, surely a node can store the label from each incoming packet
and replace it with an empty label, so the packet appears to originate
from the node itself? Then if a response is received, the node can
restore the old label (reversed) and send the packet on its way?

What's the basis for preferring one route over another in CJDNS?
Latency, hop count, label length, some mixture of those things?

>> the adversary can deliver measurement packets but drop data
>> packets. If the packets carry source or destination addresses,
> 
> They don't, only route labels which route to the next hop in the
> recursive routing which is usually but not necessarily the
> destination.

Nevertheless, a node could selectively drop traffic bound for certain
recursive routing hops, while forwarding other traffic, right?

The point I was trying to make in my previous email is that whatever
information the packets carry to distinguish one packet from another,
the adversary can use that information to target certain packets while
maintaining the appearance of high overall reliability.

>> the adversary can drop packets with certain sources or
>> destinations while keeping her overall reliability high. The
>> adversary may be able to manipulate the reliability measurements
>> without dropping packets, for example by spoofing addresses or
>> forging measurement packets.
> 
> Can't spoof a packet because the IPv6 address is the public key
> hash.

Is every packet signed with the corresponding private key? Seems like
that would be expensive.

> Can't spoof a switch frame source except to extend the length of
> the path beyond your node.

As I mentioned above, you can also truncate the path so it appears to
start at your node. That could be useful to the adversary if short
paths are used preferentially, for example.

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJR5RehAAoJEBEET9GfxSfM63wIAJwR9RPImmHk2SobGbvxgGFd
58OdNmZaq/8CbmdbIXN/CaiaewkmWTA+5iQlKGPoKVatbZOFzl0XFXxrYF77giYa
z0vFQf7cDGTspStGfpKHqvs87rahzN7MCs8nV3nBXItaOnkglu96of3RhMrni0Xw
2tNBpOzNile38etFdcgnrSZt3JhecJcAwbPEj09WcVjtXcow435XJxeqvg3oUve4
esbj2dYvAHWIBl/BFjhCJEO8q9Yl0XfyE88TRg40pUyQM5qrr0UabCTX4LBa9Vz7
mA1lTjXVp7Lrw+qzwgwg2sNVKwC7Q8GKVfvtJL5axTQGdwPq38/slVCGTt6rrGM=
=x+AG
-----END PGP SIGNATURE-----



More information about the liberationtech mailing list