On Fri, 2006-03-17 at 07:09 -0800, Robert Wohleb wrote: > This morning I was > surprised to find my download and upload speed higher than normal. Hell, > a 2.8GB download i supposed to complete in 12 hours. That hasn't > happened for a while on Cox. Hopefully this isn't a fluke. I'll report > back if this keeps up.
As far as I can tell, Cox stopped sniping bittorrent and gnutella connections with reset packets the day or the day after I told them that I'd expose their practices. Maybe they started again afterwards. Or maybe they only stopped corrupting my and my friends' traffic. If encrypting your connections gives a speed boost, then maybe some more investigating needs to be done. > I'm sure it is also only a matter of time before > Cox gets around this if this is really helping. I doubt it. Provided that bittorrent end to end encryption means something akin to Diffie-Hellman key exchange at the start of each connection, there are two ways "around" this, that I can think of, both of which suck for Cox: 1. Content-based whitelisting, meaning you can't make any kind of connection in or out unless Cox can identify the type of traffic by its content. If Cox can't determine the content of the connection because it's encrypted and Cox has not broken the encryption, then Cox terminates the connection. This would mean lots of work for Cox, and lots of support calls from lots of unhappy customers ("My streaming video never works!" "I'm sorry, but we haven't programmed our systems to track all of your streaming video viewing yet. You'll have to wait."). 2. A man in the middle attack, meaning Cox decides to break the encryption, which is a mostly straightforward process in this case. This creates several interesting problems. The first is that Cox would have to attempt such an attack on each unidentifiable connection ("Oh, that's not HTTP. Better mess with it."). The result would be that any connection using a protocol that Cox's system isn't set up to interpret and that is NOT using bittorrent end to end encryption (think multiplayer games, NFS, whatever) would almost certainly be corrupted. This is maybe worse for the end user than whitelisting. The second is that provided Cox wants to keep its activities secret (as seems to be the case so far), it would have to throttle encrypted bittorrent connections instead of terminating them entirely. That would mean that a Cox computer would have to participate in each encrypted connection from start to finish. Let's be conservative and say that there are 5,000 bittorrent connections in and out of humboldt county via Cox's network at any given time. Then Cox's servers would have to perform the encrypting and decrypting work normally parcelled out to 10,000 home PCs continuously.* Eric *P.S. There is a neat game to be played here. Suppose that Cox can purchase enough computing power to do the job (hardware+software+electricity +maintenance), and that the massive P2P throttling system pays for itself in bandwidth savings. Then suppose peer to peer developers start layering symmetric ciphers. Then the CPUs participating in the peer to peer network will be a little more loaded down, but Cox will need a much larger throttle farm to do the job. Will P2P users not be able to participate in the network because they don't have fast enough computers to do all the encryption? Or will Cox decide that the throttle farm costs more to operate than they are saving in bandwidth? Who will give up first?
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users