On Feb 1, 2008 12:00 PM, Robert Hailey <[EMAIL PROTECTED]> wrote: > > > On Jan 31, 2008, at 6:48 PM, Evan Daniel wrote: > > > On Jan 30, 2008 5:49 PM, Matthew Toseland > > <[EMAIL PROTECTED]> 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. Evan Daniel _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
