-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> This is one of the reasons why selecting peers on grounds of
> throughput is a bit dodgy!
Aye, though ignoring throughput is a sure fire way of losing all of
the users (due to congestion and loss). I2P is trying to walk
between the two extremes by organizing peers into tiers (based on
locally gathered information) but selecting within those tiers
randomly. This removes the trivial attacks that e.g. Tor is open
to, and the iterated hill climbing should help us offer reasonable
throughput.
We don't need our peer selection to find the *fastest* peers, merely
peers that are *fast enough* and have the capacity to spare.
Fast enough for what? Fast enough to work without scaring away the
users :)
> The solution to this is to enforce a maximum tunnel transfer rate
Per-tunnel throttles have promise, but they only really make sense
against certain powerful adversaries. We've got this marked up for
deployment in I2P 3.0 at the moment, as most users won't require it,
at least not at the start.
> Or to allow tunnels to split up and recombine for such situations.
Well, this we do now - people control how many tunnels they use in
parallel, and can adjust it dynamically.
> > > How does the pipenet fail?
> >
> > Congestion along the path exposes chaff - if you have a sequence of
> > peers with link level CBR @ 10KBps and you're pulling 10KBps of
> > data, if one of them chokes and you keep getting data, you know its
> > not that path.
>
> Purely the extreme blending attacks, then?
Blending is an active attack, what I described is purely passive.
Congestion happens on the live net for a whole host of reasons.
Normal network scarcity, machine load, etc.
An active blending attack, of course, would be sufficient, but I'm
not sure you'd need to do anything 'extreme' like DDoS the entire
network. Sure, you probably wouldn't get a guaranteed confirmation,
but you'd get reasonable data to correllate further.
> Lets see, we have 10kB/sec of data coming into Mallory's node from
> a particular tunnel. He has 5 peers. One at a time, we kill all the
> other links of each of our peers. When we get to the right one, our
> stream stops. When we let him connect again, the stream should come
> back. That's what you're thinking of? Hmm, that's a powerful
> attack!
Hmm, no, that wasn't what I was thinking of, but a global active
adversary, as you describe, is pretty nasty
(ot: Mallory is a guy?)
> Hmm, so you completely write off the timing attack ("in a 5 second
> interval, nothing came in except this packet from A, and nothing went
> out except this packet to B")? On the grounds that it's very unlikely
> that all the nodes on the tunnel will be that idle that this can work,
> even over the whole lifetime of the tunnel?
No router is ever entirely idle for 5 seconds (if one is, we're not
doing our job of spreading the load well enough :)
But I do also agree that both timing and traffic flow analysis are
very powerful tools for the adversaries who can mount them.
I'm not sure about how the link level CBR you describe though:
> while(true) { sleep(fixed); send_packet() }
This is a sure fire way to run into serious queueing issues. As
long as the real data is less than the amount this will let through,
you're fine (blending in chaff to reach the CBR), but once you
exceed it, you've got the RED/tail drop/etc strategies to work
through, assuming the queue is finite.
In turn, the implications of blending attacks (such as the one
mentioned earlier [1]) depend upon what queueing strategies are
used. Whatever is used will require further analysis.
[1] http://www.cl.cam.ac.uk/users/sjm217/papers/oakland05torta.pdf
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDYVywWYfZ3rPnHH0RAn4BAJ4uIR3L+6TobghLZ2syP7zXIDptQQCggDta
csqHD82/96gULbow7+lu2GQ=
=vM5v
-----END PGP SIGNATURE-----
_______________________________________________
chat mailing list
chat@freenetproject.org
Archived: http://news.gmane.org/gmane.network.freenet.general
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/chat
Or mailto:[EMAIL PROTECTED]
