On Thu, Oct 27, 2005 at 02:46:42PM -0400, [EMAIL PROTECTED] wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > > > In any case, 2-4 must use a CBR no higher than the individual nodes' > > > > > free capacity, and the rate selected reduces the anonymity set of > > > > > the traffic carried to the order of other links with similar rates. > > > Why does it reduce the anonymity set of the traffic carried? > > Extreme example, for clarity: > > if everyone has 10 links and there is only one sequence of peers in > the whole network pushing 100KBps, with everyone else is pushing > 1KBps, if you are able to pull more than 10KBps of low latency data, > you know you're getting data from one of the peers with the fast CBR > links (since everyone else can only send at 10KBps max).
Right. This is one of the reasons why selecting peers on grounds of
throughput is a bit dodgy!
A tunnel which does 15kB/sec will *have to* go through only the
100kB/sec nodes. The solution to this is to enforce a maximum tunnel
transfer rate, or not to select nodes on grounds of performance. Or to
allow tunnels to split up and recombine for such situations.
>
> > > > > (2), if I understand correctly, means the tunnel stays constant at
> > > > > the tunnel's negotiated CBR rate at all times. This fails pretty
> > > > > clearly in the same way pipenet does.
>
> > 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? This would require the
attacker to kill a lot of nodes. 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! I don't see that it's any worse with CBR though. One
obvious countermeasure is for adjacent nodes to tell you whether the
targetted node is up, through their own links.
>
> > > > > (3), if I understand correctly, means the tunnel doesn't do any CBR,
> > > > > beyond some algorithm that verifies that by the end of the tunnel's
> > > > > lifetime, the total number of messages transmitted equals what it
> > > > > would have transmitted if it were CBR'ed like (2). Right?
>
> > Not true. We adjust the CBR bitrate according to the long term rate of
> > real data transmission. Certainly there are issues with doing this in a
> > way which won't give away the real data transmission rate, but a
> > combination of quantization and the right kind of averages should make
> > something usable.
>
> Ok, I misunderstood. I don't really understand how it'd work now,
> but perhaps one could come up with something.
>
> > And even if it does give away the *rate*, it won't give away the
> > individual packets for timing/forwarding correlation attacks, as
> > we have been discussing, which become increasingly easy over
> > time without CBR.
>
> The importance of the rate is for correlating related flows of
> packets. Perhaps it wouldn't be an issue if every packet's routing
> is independent - is this what you're getting at?
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?
>
> > So the issue is how to make it work with bandwidth limiting?
>
> Nah, I was just talking about how one particular token bucket based
> algorithm could fit into what I thought you were proposing. I don't
> know any concrete algorithm, but one might be able to come up with
> something when necessary.
Ahh, okay. Not what I was proposing.
while(true) { sleep(fixed); send_packet }
:)
>
> > #4 IIRC was to negotiate a bitrate with each node, independantly
> > of the actual data transferred, just on the basis of each involved
> > node's links. So essentially it's a more flexible variant on #1.
>
> Ah, ok.
>
> =jr
--
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital 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]
