On 3/22/06, Eric <[EMAIL PROTECTED]> wrote: > 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. > ... > 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. >
I think you're ignoring the fact that Cox can throttle your connection simply based on analysis of traffic volumes. They don't have to do any crypto at all, or inspect any packets deeply. Throttling rules would be set up that say "hey, here's one client getting data at high speed from a bunch of other folks simultaneously, and sending data quickly upstream to a bunch of people at the same time." Such a rule would be fairly straightforward to implement by tracking a few simple counters per client. I imagine Packeteer and the other traffic-shaping vendors already have something along those lines available. Such traffic-pattern throttling wouldn't step on VPN or SSL connections, as they're typically from a single host to single host. Basically, BitTorrent has a very unique traffic pattern that makes the encryption at best a temporary roadblock to traffic shapers. The vast majority of BT traffic is from copyright violators, so it's not like the imapcted users will complain about the throttling in any official capacity. As for the impact on "legitimate" BT traffic like Linux distros... well, I'm sure Cox doesn't care one bit. It's not like the Ubuntu project is going to sue Cox over BT traffic shaping. -- RPM _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
