headers
Evan Daniel | 1 Feb 2008 18:20
Picon

Re: Alpha, Darknet routing, et al.

On Feb 1, 2008 12:00 PM, Robert Hailey <robert@...> wrote:
>
>
> On Jan 31, 2008, at 6:48 PM, Evan Daniel wrote:
>
> > On Jan 30, 2008 5:49 PM, Matthew Toseland
> > <toad@...> 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
(Continue reading)

Permalink | Reply |
headers
Michael Rogers | 2 Feb 2008 17:31
Picon
Picon
Favicon

Re: Alpha, Darknet routing, et al.

Evan Daniel wrote:
> 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.

Are you sure RejectedOverload isn't adequate? If a gateway node becomes 
overloaded, the other nodes in both subnets will route around it, so 
traffic will stop crossing between the subnets but routing within each 
subnet should continue to work. AFAICS it would only be a problem if the 
gateway node was unavoidable in one or both of the subnets (eg ring 
topology with no shortcuts).

Cheers,
Michael
Permalink | Reply |
headers
Matthew Toseland | 1 Feb 2008 18:57
Picon

Re: Alpha, Darknet routing, et al.

On Friday 01 February 2008 17:20, Evan Daniel wrote:
> On Feb 1, 2008 12:00 PM, Robert Hailey <robert@...> wrote:
> >
> >
> > On Jan 31, 2008, at 6:48 PM, Evan Daniel wrote:
> >
> > > On Jan 30, 2008 5:49 PM, Matthew Toseland
> > > <toad@...> 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).
>
(Continue reading)

Permalink | Reply |
headers
Robert Hailey | 1 Feb 2008 19:33

Re: Alpha, Darknet routing, et al.


On Feb 1, 2008, at 11:57 AM, Matthew Toseland wrote:

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?

I guess you could add to the failure table which distinct links have requested a given key, and be more likely to let those through with more links (once the failure is timed out). It doesn't seem very granular, as I would suppose (in a small world network) that a re-request from a non-peer node would be very likely to show up on a different connection.

--
Robert Hailey

_______________________________________________
Devl mailing list
Devl@...
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Permalink | Reply |
headers
Evan Daniel | 1 Feb 2008 19:25
Picon

Re: Alpha, Darknet routing, et al.

On Feb 1, 2008 12:57 PM, Matthew Toseland <toad@...> wrote:
> > 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?

I think ULPRs will do a good job of preventing legitimate traffic from
creating such an effect.  A malicious attacker, however, would have no
reason to repeat keys, so any technique that simply tries to make
re-requests more efficient would have no effect.  Biasing on
popularity is probably a good thing, and if it can be done in a
relatively attack-proof manner, might be the solution.

Do we have any understanding of how well network clusters will
correlate with content clusters?  That is, if there are effectively
two networks, especially if they result from cultural and language
barriers, to what extent will the two sides be uninterested in
communicating with each other?  I think having a ballpark answer to
that question will go a long way in determining how big a problem this
really is, and also what sort of solutions might be appropriate.  Of
course, it sounds hard to answer :)

Evan Daniel
Permalink | Reply |
headers
Michael Rogers | 4 Feb 2008 02:45
Picon
Picon
Favicon

Re: Alpha, Darknet routing, et al.

Evan Daniel wrote:
> Do we have any understanding of how well network clusters will
> correlate with content clusters?  That is, if there are effectively
> two networks, especially if they result from cultural and language
> barriers, to what extent will the two sides be uninterested in
> communicating with each other?  I think having a ballpark answer to
> that question will go a long way in determining how big a problem this
> really is, and also what sort of solutions might be appropriate.  Of
> course, it sounds hard to answer :)

But all the interesting questions are hard to answer. :-) I asked a 
friend who works on computational trust and he pointed me to some papers 
by Jennifer Golbeck:

http://www.cs.umd.edu/~golbeck/publications.shtml

The short answer appears to be "somewhat".

Cheers,
Michael
Permalink | Reply |

Gmane