On Friday 01 February 2008 17:20, Evan Daniel wrote: > On Feb 1, 2008 12:00 PM, Robert Hailey <robert at freenetproject.org> wrote: > > > > > > On Jan 31, 2008, at 6:48 PM, Evan Daniel wrote: > > > > > On Jan 30, 2008 5:49 PM, Matthew Toseland > > > <toad at amphibian.dyndns.org> wrote: > > > > > >> You also need an escape-route mechanism - a way to find an entrance > > >> into > > >> another network once regular routing has exhausted the local network. > > > > > > Doesn't this allow an attacker to selectively DOS the bottleneck > > > points by sending out requests for non-existant data? > > > > > > Evan Daniel > > > > If we allow the requestor to specify which network they are trying to > > get to, then maybe (but the node still can rejectoverload like any > > other). I think it would work better to the negative; specify which > > networks *not* to route to, this would not only help on a reject of a > > network-gateway node, but it also lets nodes w/o a good routing table > > to use the same mechanism. > > Even if the requestor can't specify a target network, I think it > works. If the model is that the request is first routed within the > network, and if that fails it tries to find an escape route -- then > that "escape route" is a bottleneck (by definition). > > The nodes using rejectoverload is insufficient, I think -- they'll > reject the attacker's requests and real requests with similar > probability, and so performance for real requests will degrade > substantially. Now the attacker only needs resources comparable to > the bottlenecks; they don't even have to know where those bottlenecks > are in order to seriously degrade the network topology. > > I'm not familiar enough with the details of the proposed ULPRs and how > USKs and Frost and the like check for new updates / messages, but it > seems possible that simple legitimate checks for new content would > have a similar effect. Of course, failure tables would help a lot > with that case, but they wouldn't help against a malicious attacker.
Could ULPRs help to resolve it? Would it be possible to estimate the demand for a key (in a way which doesn't favour single nodes that constantly rerequest, and is biased by links so that an attacker could only attack proportionately to the number of connections he has), in order to decide which requests to let through? > > Evan Daniel -------------- 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/20080201/f39d7371/attachment.pgp>
