On Thu, Oct 27, 2005 at 01:23:48PM -0400, [EMAIL PROTECTED] wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > > - Both dark and open (maybe) freenet can be insulated from this via CBR > > > > links because nodes are of low order and links change slowly. - IF > > > > there > > > > is no fundamental problem with CBR links. I2P probably can't be. > > > > > > I'd posit that "IF" is appropriately questionable ;) > > > > I'm not sure why. There is a big problem with CBR *tunnels*. What is the > > big problem with CBR *links* ? > > 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. - Darknets, with cellular tunnel selection. > > In addition, you've got pipenet-esque issues. For the four > scenarios you described: > > > 1. Pure CBR. All node links are exactly 1kB/sec. Not practical for I2P, > > very wasteful for freenet. > > 2. Negotiated CBR based on current traffic level. > > 3. Negotiated CBR based on average long-term traffic level. > > 4. Negotiated CBR based on hosts available capacity. ~= #1, but more > > friendly to slower nodes. > > > > I think what jr is critiquing here is #2. I was thinking more #3. > > (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. > > For 2-4, how are the CBR rates negotiated? Sorry, below you're talking tunnels; I was talking links, to prevent external attackers (both passive and active) from exposing traffic. > > 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. > > (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. > > (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? > > 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. > > I'm not sure I understand (4). > > =jr > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFDYQrTWYfZ3rPnHH0RAgYQAJ4m8vROjE6J5tIFf/DqrPVB599LqgCfbwfO > X97OYyerUGjuU3ZR2P/YEQk= > =xOMM > -----END PGP SIGNATURE----- -- 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]
