On Thu, Oct 27, 2005 at 02:04:13PM -0400, [EMAIL PROTECTED] wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > CBR links only hide information from external adversaries. They're > > > transparent to internal adversaries. > > > > True enough. But there are ways to prevent internal attackers > > masquerading as zillions of nodes: > > - Costly identity via hash- and think- cash. > > Agreed, there are methods for minimizing Sybil with regards to the > P = (c/n)^h here. > > > - Darknets, with cellular tunnel selection. > > Depending on darknets for the peer selection is the same as saying > "dunno, let the user figure it out". But, thats a topic for another > discussion.
True, however it has the same effect as costly identity, and there are major economies of scale on hashcash, thinkcash, and IP address scarcity. > > > > > 1. Pure CBR. All node links are exactly 1kB/sec. Not practical for I2P, > > > > very wasteful for freenet. > > > > > > (1) is a nonstarter. You've just jacked the queueing times into > > > *hours* for most uses. That is, assuming people stop adding to the > > > queues and it doesn't fall into congestion collapse. > > > > Feasible for Freenet, including distributed pub/sub streams using > > passive requests. Not so sure about 1:1 streams! Remember that we've > > probably only got 20kB/sec or so upstream. > > We've already had these discussions about whether Freenet's routing > can deal with congestion, with the net result being "we'll see". > Now you're saying you'll enforce a maximum link capacity of 1KBps? If your node is connected to 20 other nodes, it's possible, as long as load is distributed reasonably evenly. It's certainly not optimal! Most of the load imbalance problems come from precisely that - load imbalance - some nodes having much more traffic than others. Anyway, load balancing is *totally* different in 0.7, using an algorithm based on TCP which occurs at the client-node level. > > Well, there are enough details not specified yet for us to continue > with the "we'll see" response, I suppose. > > > > For 2-4, how are the CBR rates negotiated? I don't know. If it was possible, would it be useful? > > > > Sorry, below you're talking tunnels; I was talking links, to prevent > > external attackers (both passive and active) from exposing traffic. > > Ah, you're right, though the above question still stands. Let me > revise my questions: > > > > 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. > > Still pertinent for CBR links. Why does it reduce the anonymity set of the traffic carried? Certainly there are node bandwidth issues... E.g. a router with 80kB/sec inbound and 5kB/sec outbound is probably downloading! > > > > (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. > > Still pertinent for CBR links, replacing "tunnel" with "link". How does the pipenet fail? The only failure I've heard of is the "kill one link and the whole network falls over" attack, which afaics is a perversity of CBR tunnels. CBR links would just keep going. > > > > (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. 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. > > > > > > Off the top of my head, I don't see a simple algorithm for achieving > > > reasonable CBR without leaking the flow. For instance, I2P uses a > > > token bucket for bandwidth limiting - every 100ms, we add in some > > > new tokens, and whenever we want to send out a packet, we wait until > > > we can grab enough tokens from the bucket. The 'always active' > > > state of such a scheme is CBR, but its patterns of downtime (when > > > tokens accumulate in the bucket) as well as its patterns of bursting > > > (when excess tokens are pulled from the bucket faster than they are > > > added) are visible. > > Needs adjustment for CBR links, but only by replacing the "tunnel > lifetime" variable with duration of the "long term" averaging. So the issue is how to make it work with bandwidth limiting? Well, IMHO outbound bandwidth limiting is more critical than inbound, as well as being easier, and we can negotiate some slack while we open a connection to a new node, or we can simply not allocate up to our capacity in the first place as in #1. > > > > I'm not sure I understand (4). > > Still pertinent for CBR links :) #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. For example: Alice is connected to Bob. Alice has a bwlimit of 10kB/sec. Bob has a bwlimit of 20kB/sec. Neither is connected to anyone else. So Alice uses the full 10kB/sec available. Then Alice connects to Claire. Claire has a bwlimit of 12kB/sec. Alice cuts Bob's quota to 5kB/sec and gives Claire 5kB/sec. Dodo connects to Bob. Dodo has a bwlimit of 80kB/sec. Bob gives Dodo 15kB/sec. Julie connects to Bob. Julie has a bwlimit of 16kB/sec but has already allocated 7kB/sec of it to Claire. Claire allocates 5kB/sec to Bob. Bob cuts Dodo's limit to 10kB/sec and gives 5kB/sec to Claire. Etc. The change in #3 is to make this dependant on not only the available bandwidth, but also its likely usage. > > =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]
