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


On 07/15/2013 04:52 PM, Michael Rogers wrote:
> On 15/07/13 01:49, Mitar wrote:
>>> BTW, how do you propose to make Sybil nodes "impossible"?
> 
>> I don't. I am just making an argument, that maybe there is some way we (or 
>> I) don't yet know which would allow us to don't have to trust other nodes 
>> with anything else that they forward the packet. And if they don't, we can 
>> maybe detect that and remove them from the routing path. So at the end maybe 
>> it is not even important if Sybil nodes are possible or impossible. You just 
>> care if they forward the packet. If they do, this is it. If they don't (from 
>> whatever reason, being malicious or
>> just malperforming), you route along that, no? But to be able to route 
>> around, you have to be able to have multiple paths.
> 
> Hi Mitar,
> 
> If there's no protection against Sybil attacks then in general it's 
> impossible to route around faulty nodes or links. The problem is that in 
> order to detect faults, we have to associate some kind of reliability 
> measurement with some kind of node or link identifier (for example, "x 
> percent of packets sent via link y were delivered"). If there's no Sybil 
> protection then whenever we detect a node or link as being faulty, the 
> adversary can simply create a new identifier for that node or link.

At the switch layer, the path is a binary encoded list of interface
indexes of the interfaces through which the packet should pass, think
of it like driving directions.
Each node along the path modifies the packet, removing the forward
index and tagging it with the index of the interface from which it
came. This means you can send someone a switch frame with *anything*
in the label and when it gets to them, the beginning of the label
will contain a nicely formatted route leading back to you.

You can spoof a switch frame source but the path will always appear
to go through your node.

> 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. 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.

> 
> If we consider the most limited form of Sybil protection, where we know that 
> our immediate neighbours in the network aren't Sybils (for example, maybe 
> they're people we know in real life) but we don't know anything about the 
> rest of the network, then we can do a very limited form of fault detection: 
> we can measure the reliability of each neighbour, without speculating about 
> what the network beyond that neighbour looks like, and route around 
> unreliable neighbours.

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.

> 
> But that's not as easy as it sounds: if the adversary can distinguish between 
> different types of packet then she can treat them differently. For example, 
> if the network uses separate measurement packets and data packets,

It doesn't (of course you can guess based on size and flow information)

> 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.

> 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.
Can't spoof a switch frame source except to extend the length of the
path beyond your node.

> 
> This problem is known as Byzantine robust routing. It was first framed by 
> Radia Perlman in 1988, and so far nobody's come up with a solution that 
> doesn't require some kind of limit on the creation of identities. Many have 
> tried and failed. I was one of them. :-) I don't know enough about CJDNS to 
> know whether it's solved this problem, but I'll be pleasantly surprised if it 
> has.

If you want to cause trouble for cjdns, just exploit
https://github.com/cjdelisle/cjdns/issues/204 before I get off of my lazy
ass and fix it :)

Thanks,
Caleb


> 
> Cheers, Michael
> 
> -- Too many emails? Unsubscribe, change to digest, or change password by 
> emailing moderator at compa...@stanford.edu or changing your settings at 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJR5EjPAAoJECYAmptlsgnWmUsP/2f3PG5iYlJInZvBVzM73HVZ
codeKbXLD8NNBmaCA9l5nEeEdC5rCAYBB7woMjsXDSgr79SBZvZW8lha4tDOiPrT
0U2uamVBvKIH4VGkoGgAhhLTgmpLA5knZiWt6tnXk1Y0WaKN1RT4gLhLa/4mBoUL
cQP5QGvza5CqhtgeLrjTb0LGMsCqDL9AvfzoU7TsOM8wuxQYruRoRtTbPNBQjj4W
6R87+j/7BQtxcsd40NTvIraw4Ljxst3J3VfPdJI6RDdO1yWu0CVM/KMrpsSsZdKZ
dbKqVL7Fr/5RFkDPM7v4OufzQa0/FeSLYPwlD4PSIz2QYWgEtHKAHNJM4trxooOO
P6MPl4ka8GWqBM+7kVt1bKTd8cC+3oBgUjSXsP5Bcoiy+OeycwCXZXHxf2I0aO8n
zQcdkcn8s/6ZD+EVTTBVcjqgEsUXH4okAU1vL6G41/xEGFBCGJv9fbAPT0mQWkae
7Kb7K2xWmwENpKLiIFOKdh0fIT17/ToqAhNY5wldemWnNfDW/61NmMF+291h7scy
rD8VZSZjTVuPJwia2/L8po4F2HSj9obh5ZdyBapjrFmofFNwJHVScCQuYb0KpnAw
C+tR0P4fjYu2c6211YkSBrUTUCm0ccOEv3PXUAiXGPadZgzpAGoYfQ9gFb3hwCiK
uqTiuPbVaKdYum8eFzFy
=VS1P
-----END PGP SIGNATURE-----

--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Reply via email to