On Wednesday 30 January 2008 19:02, Robert Hailey wrote: > -- #2 -- Avoiding dungeons > > The only way I am aware of defining a dungeon is as a separate network > whose likelyhood of success is effectively-zero, and even then only if > it is not a substantial portion of our peers (which probably means we > are in the dungeon).
I use "dungeon" in the same sense as "rabbit hole" - a small subnetwork which is very poorly connected to the outside world, but big enough for a request to get stuck in. > > > As you say, it might be possible to use the fraction of DNFs to detect > > dungeons, but then an attacker could request nonexistent keys from a > > particular range to make that part of the network look like a dungeon. > > If we use "percentage of successes," or time-based... yes. I recommend > a small constant instead; e.g. a given network-group (as assigned > above) is NOT a dungeon if we have (say...) 2 successes from them > (collectively). Or perhaps we should just make this the default > behavior: routing groups ordered by collective successes, label the > last several of them a dungeon (if they have less than... 4 peers to > them). A dungeon by the above definition might well have successes from time to time. > > -- #3 -- Favoring other networks > > We would need (1) a routing table, and (2) to be notified of other > networks somehow. I suggest such a packet following successes (like > opennet path folding), saying "this success came from [EMAIL PROTECTED], > [EMAIL PROTECTED], etc." 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. Presuming that > the identification algorithim stabilizes, certainly routing to a > distant network given an id (or a counter-example set!) would not be a > problem. We would have to be mindful that the routing information > could be easily tampered with; so rather than telling a potential > attacker "this packet is trying to find location=x on network=y", it > would be more to the effect "location x, not on network=y,z,w" in > which case if a node only knows about those networks it RNFs. You also need an escape-route mechanism - a way to find an entrance into another network once regular routing has exhausted the local network. Anyway, simulations would be fascinating. Although IMHO dealing with timeouts is more immediately urgent.
pgpPw77qFQCdE.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
