NNSquad - Network Neutrality Squad
[ NNSquad ] Re: Blocking Comcast's Sandvine with simple firewall rules?
On Wed, Jul 2, 2008 at 11:58 AM, Lauren Weinstein <lauren@vortex.com> wrote: > > Nick, > > I understand that you are primarily interested in the technical side > of these issues, and not their broader policy ramifications -- you've > said as much explicitly. The controversial technical aspects of > your discussion below regarding QoS, etc. will be refuted by myself > and others in due course. I strongly disagree. I actually care deeply about policy. I just feel that what you are doing, and how you are going about things, has the potential to cause more damage than some of the network enforcements you disagree with, because I've already articulated my policy goals and am actively working towards them. Advertisement injection deeply offends me, which is why I was involved in the web tripwires work. (the collaboration began from a rant I gave on "Malice is a Feature" from the FIND PI meetihng a year ago, slides at http://www.icsi.berkeley.edu/~nweaver/find_panel_nw.ppt [1] How is that talk not entirely about caring about technical policy and the policy implications of the systems we build?) RST injection is, MOSTLY, not kosher, which is why I developed an effective detector for it. And I'm now critically interested in a key policy doctrine: Preventing usage-based caps/usage based pricing, as I believe that, more than anything else, would damage the health of the Internet for future applications. Its not as bad as my true nightmare of "intent based" pricing, but it is still too close to comfort for me. Thus I'm actively doing research which is about ensuring what I feel to be the best plausible policies. How can you say I'm not CRITICALLY interested in policy? It's just I'm a realist. I'm on the security response team for our enterprise network. My research area is often deep in the network stack. I've built a networking hardware prototype for Gigabit operation. And I understand just enough EE to know how much I hate analog, and therefore what a miracle Gigabit ethernet is over twisted pair, even over just 100M (1000T, cat6 is only good for 100 meters!), and what an incredible piece of engineering DOCSIS 3 is: able to send 150 Mbps downstream and 100 Mbps upstream over this crappy coax laid down 30 years ago. And I've said it repeatedly, and it gets ignored in this forum: Pick your poison: Usage caps/usage based pricing, application policing, or user fairness. You have not made a case that there is any alternative other than these three, barring the bandwidth-fairy arguments which require pulling new infrastructure for the last mile [2]. Because best effort and flat rate billing, in combination, has FAILED. It has failed for the ISPs (no business model) It has failed for the light users (they see congestion that they aren't contributing to) And it has failed for the heavy users (no economic model for greater provisioning). So, Lauren, if you want a policy: Pick your poison, and make a case for it. Or make a case that "Best Effort" is the optimum policy, in which case you need to explain why best effort hasn't failed. Because, in the policy question, I have: User fairness. As such, I've begun actively focusing my research on ensuring that the least-unpleasant policy outcome should come to pass. And the key to that is twofold: 1: Make the "bad" policies expensive (this group and others are good at that for traffic manipulation and wiretapping, but not so good for caps/billing.) 2: Make the "good" policies cheap! Unless you define what outcome you desire, and work to make the good policies cheaper than the bad policies, you will still get bad policies, just different bad policies. And if you succeed in making a "bad" policy more expensive than an "even worse" policy, is this a success? > One point I'll make right now -- you are inaccurately trivializing > the issues associated with detecting and dealing with ISP intrusions > into user data streams, and obviously such techniques are not > applicable to the detection of ISP wiretapping of user keyword or > other data in transit to other parties. Nor should it be the job of > Google, et al. to play policeman against ISP intrusions. That's > reversing where the responsibility should be -- ISPs shouldn't be > screwing around with user data in such manners in the first place. Actually, they are, IF the wiretapping is not coordinated with the DHCP server (and even then): You want to tag users, not IPs, and track across user behavior, which means you need to inject a tracking cookie or freeride on someone else's cookie onto the browser. If you tag the user (far easier, non-ambiguous, and allows you to CLAIM an opt-out), this leaves fingerprints both on the end user's system (the injected cookies), and even for a fully inline device like Phorm, a fingerprint on the server side when an SSL connection is made. Thus although wiretapping is not detectible, user tagging (a key portion of their business model) IS detectable. [3] Likewise, injected packets are always detectible with some probability because they create race conditions. Double-sided detectors should be able to detect most/all proxies, at least if they perturb the traffic. The key is: Know what you are looking for, know what the permutations must be, and then look for the permutations. Its not trivial, but it is less difficult than you think. EG, we have already shown that it is possible to detect page-modifiers (which would detect NebuAd's injected javascript) and to detect injected RSTs, both from a single side of the network. Likewise, I can tell you that my ISP does a "shape early" policy, where the start of large uploads receive more bandwidth (it starts off at 140 KB/s, quickly reducing to ~40 KB/s after about 1 MB.) regardless of congestion. And there are numerous papers on passive mesaurements on TCP which can tell you all sorts of information. So if I believe it is often straightforward to measure significant perterbations of the network, of the kind you are concerned about, it is because of experience in conducting such studies and seeing the results of other studies. > But even if for the sake of the argument we now assume that Comcast > is working hard to become the consumer angel of the ISP industry, > pure as the driven snow, we still have no valid way to predict what > their future actions might be -- and of course not everyone is a > Comcast customer. > > What of all the other ISPs that by your definitions are not as > "enlightened" as Comcast? What about all those other customers? > What are their options to be treated in the wonderful Comcastian > manner that you postulate, absent some sort of regulatory framework > to help force the issue -- or at least to provide subscribers with the > real story about what's going on with their own ISPs operations? So you watch and remain vigilent. And develop tools to monitor things. But at the same time, all this rhetoric that treats the ISP as an enemy is counterproductive. You aren't going to be able to make good policies cheaper if the ISP is the opposition. At worst, they are your Frenemy. Understand their problems, and their limitations. Make tools which solve their problems as well as your problems. And understand what policy outcome you actually desire, articulate it, and work towards it. [1] The only thing I'd change is I've decided I can't live with "Bits at QOS X are billed at X", as I've since now believe that usage based pricing is a disaster, but I'm starting to believe that long-baseline, network enforced fairness is reasonable. [2] and even when the Governmental Bandwidth Fairy shows up and pulls fiber to the home, you may still need to do traffic management: http://www.jaipa.or.jp/other/bandwidth/guidelines_e.pdf [3] And lets be honest here: What is the practical difference between NebuAd and Google? Google gets one-party consent (the content provider, NOT the user in most cases) to track the user's behavior in great detail across the Internet. To be honest, from a policy perspective, Google scares me MORE then NebuAd and Phorm. NebuAd and Phorm generate instant revulsion, but we have already accepted that Google knows effectively everything you do online.