NNSquad - Network Neutrality Squad

NNSquad Home Page

NNSquad Mailing List Information

 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ NNSquad ] Re: Blocking Comcast's Sandvine with simple firewall rules?


Nick,

I suspect we're now reaching the readership's tolerance level for this
discussion, so we're going to have to wrap this up as far as the list
is concerned.

I'm glad to hear that you're interested in policy issues.  I've
received material from you recently where you suggested the
opposite, but I'll gladly let that pass.

And yes, there are a variety of techniques (in what's likely to
become a continuing arms race) to detect some of those ISP behaviors
that you say (and I agree) are offensive.

But assuming workable detection mechanisms, what then?  When we
detect something, do we go hat in hand, genuflecting before the ISPs
to beg for reasonable opt-outs?  What if any opt-outs aren't reasonable
or if opt-outs aren't made available at all?  And how many people will
know about, understand, and avail themselves of opt-outs even if they
are available?  The default is where most people live.

For that matter, why should we have to be jumping through ISP measurement,
detection, and opt-out hoops in the first place, especially when it comes
to those "offensive" ISP behaviors that we both dislike intensely?

In a truly competitive ISP marketplace, many of these issues would be
largely in the noise.  But in the U.S. at least, with so few useful
ISP choices in most areas, the unregulated ISP operating environment
has created a "wild west" mentality where consumers are increasingly at
a disadvantage, even when it comes to knowing the basic aspects of
what they're really paying for when it comes to Internet access.

As for your equating of Google with NebuAd and Phorm ... you're dead
wrong and I believe your associated Google Fear is unrealistic, but
I won't risk the further good will of the readership by launching
into a discourse on this right now.

--Lauren--


> 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.