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 net=3 at htl=2, > net=5 at htl=4, 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080130/1ea112d4/attachment.pgp>
