On Jan 30 2008, Robert Hailey wrote: >No, in the way I am thinking this is even expected; a node can >advertise whatever network-id it wants (just an integer), it is up to >the peers to make sense of it.
I don't see how that can be made robust against malicious nodes. >Some time in the future, using (for example) routed pings it breaks up >it's peers into groups. e.g. I can ping peer #3 through peer#2, so >they are on the same network. How do you authenticate the routed pings, to prevent an attacker from replying on behalf of another node? How do you prevent an attacker from forwarding pings but dropping (selected) requests? The attacker isn't necessarily interested in creating a dungeon (certainly not a detectable one) - he might just want to control a large region of the key space, either to monitor it or to censor selected keys, while responding normally to other requests. >Processing in order of largest-group first: for all these groups, we >advertise the most-common network id in that group towards all of >them; unless that id is taken by a larger group (already processed), >in which case a random id is assigned to that group (or the next-most >common?). Which is to say every 'group' has a distinct network id >(assigned & advertised by-us) favoring what they are advertising >already. Sorry, I don't understand the purpose of advertising - are nodes supposed to pay attention to what we think their network ID should be? What if an attacker sends hundreds of different network IDs to each node, or hundreds of copies of the same network ID that appear to originate from different nodes? >We choose our network id based on successes; I don't think it even >matters specifically how... Since all peers are advertising (possibly- >different) ids to us, we take the most-common id among peer's from >which >50% of our successes come from (for example). Anything that uses "most common" as a criterion is vulnerable to flooding and/or Sybil attacks. >I suspect it >would work even if we simply took the network id advertised to us by >the peer of our last successful request. An attacker could respond normally to requests but advertise a different network ID each time to prevent network IDs from stabilising. >We would need (1) a routing table, and (2) to be notified of other >networks somehow. Sorry to be negative but I don't think we're going to come up with a back-of-an-envelope solution to this problem. Routing in untrusted networks has received a lot of research attention recently because the US military is starting to deploy ad hoc wireless networks, and so far there are no good solutions that don't depend on a trusted certificate authority. Here's a review of some of the relevant literature: http://www.cs.ucl.ac.uk/staff/mrogers/literature-review.html#robust-routing http://www.cs.ucl.ac.uk/staff/mrogers/literature-review.html#anonymous-manet >And since there could be a *lot* of junk-network >information, we just keep a psuedo-LRU of recently seen network ids >(where multiple peers having the same network success: favoring the >peer with the more recent success than higher htl? but probably >promoting them both). Keep, say, 100-1000 network ids. An attacker could respond normally to most requests, advertising a different network ID each time to flood the LRU. Cheers, Michael
