Re: DPI -- Protecting the past from the future

[David Farber <dave () farber net>]

Begin forwarded message:

From: "Bob Frankston" <Bob19-0501 () bobf frankston com>
Date: March 1, 2009 11:18:09 AM EST
To: <dave () farber net>, "'ip'" <ip () v2 listbox com>
Cc: "'Lauren Weinstein'" <lauren () vortex com>
Subject: DPI -- Protecting the past from the future

Absolute control of the network means the absolute power to impose the  
naïve and counter-productive policies on our ability to communicate  
and our ability to create new value.

I could argue the technical points of the DPI rationales cited below –  
but I’ve done that too many times (though it can fun). The real  
question is why people insist on the necessity of value-based routing?  
There seems to be a failure to appreciate the intrinsic ambiguities  
I’ve written about.

DPI is an extreme case – it’s as if we weren’t just trying to recreate  
the intelligent network but going all the way to the psychic network.

But there is still the issue of trying to ban “bad” behavior. Once  
again have we forgotten the modem crises in which dialup users were  
indeed badly behaved and threatening the integrity of the phone  
network? Imagine if the carriers had been able to impose their well- 
intentioned but utterly naïve idea of how to run a phone system (like  
a railroad) on us. Not that the effort was well-intentioned, but even  
if it were it would have been problematic. We’ve seen this again and  
again be it Hush-a-Phone or Webcams. The “bad” is a necessary step on  
the path to “far better”.

Perhaps the kind of dichotomy that George Lakoff cited in Moral  
Politics can give us some understanding of the presumption that we  
must and that we can control the meaning of the bits in the network.

But there is also a business rationale – if we could do our own  
networking better without these policies then why do we hand control  
over to a telecom industry that insists on charging us for these  
“favors”?

Controlling malware and other problems is indeed important but  
fixating on DPI is a diversion – like assuming could solve our  
national security problems by just torturing a few more people.

-----Original Message-----
From: David Farber [mailto:dave () farber net]
Sent: Sunday, March 01, 2009 08:56
To: ip
Subject: [IP] Re: 2 on New P2P Privacy System from Univ. of Washington



Begin forwarded message:

From: "George Ou" <george_ou () lanarchitect net>
Date: February 24, 2009 8:15:27 PM EST
To: "'Lauren Weinstein'" <lauren () vortex com>, "'Richard Bennett'" <richard () bennett com
 >
Cc: nnsquad () nnsquad org, "'Paul Forbes'" <paul.w.forbes () gmail com>
Subject: [ NNSquad ] Re: New P2P Privacy System from Univ. of
Washington

So here we are with the debate on DPI.

DPI is good when we use it to:

* Inspect content to detect and block virus or malware signatures
* Inspect content to detect and block denial of service payloads
* Inspect content to detect and block spam
* Inspect content to detect replicate data to cache data so that unicast
audio/video delivery scales
* Inspect explicit DiffServ labels to properly prioritize traffic
* Inspect protocol headers to determine implicit prioritization label
in the
absence of explicit priority labels
* Inspect content to offer targeted advertising to pay for free wireless
broadband
* Inspect content to offer targeted advertising to pay for free cloud
email
e.g., Gmail
* Inspect content to offer targeted advertising when user explicitly
agrees
to terms and conditions


DPI is bad when we use it to:

* Inspect content to offer targeted advertising to users without
disclosure
or permission from user

George Ou

     [ I don't know whose set of good/bad values that's supposed to be.
       You?  Verizon?  Eric Schmidt?  Rush Limbaugh?  Wendy Carlos?
       It's certainly not mine.

             -- Lauren Weinstein
                NNSquad Moderator ]



-----Original Message-----
From: nnsquad-bounces+george_ou=lanarchitect.net () nnsquad org
[mailto:nnsquad-bounces+george_ou=lanarchitect.net () nnsquad org] On
Behalf Of
Lauren Weinstein
Sent: Tuesday, February 24, 2009 6:02 PM
To: Richard Bennett
Cc: nnsquad () nnsquad org; Paul Forbes
Subject: [ NNSquad ] Re: New P2P Privacy System from Univ. of Washington

On 02/24 14:15, Richard Bennett wrote:
> I think there's a big difference between technologies that can be
> "abused by evil people" and those that are *meant to be used by
> criminals in the commission of crime*. There's no legitimate reason  
to
> mask the identities of the members of a P2P swarm in any free and
> democratic country, and no chance of doing so anywhere else.

This is a remarkable statement.  I assume Richard means it in the
context of illicit use -- but of course what is meant by "illicit"
varies widely.  In some countries, negative comments about the
leadership can get you thrown into a dungeon or your brains blown out
by government edict, courtesy of a bullet to the base of your skull.

But we know that all use of P2P is not illicit by most definitions,
and the percentage of illicit material in overall P2P usage is
(according to the figures I've seen) dropping at a significant rate.

For those of us who still believe in the Fourth Amendment to the U.S.
Constitution (obviously an ever smaller cult), the concept of
anonymity is important, since around that revolves much of the entire
problem of unreasonable search and seizure, and the related protection
of legal activities.

> This Washington U. stuff is just garbage.

I'm sure the U. of W. team appreciates your respectful technical
analysis of their efforts, Richard.

> Are we doomed to transmitting a unique copy of
> the entire packet stream of each episode of "American Idol" to each  
of
> its 50 million viewers, or can we relax the layering dogma enough to
> cache copies of the stream close to the end user?

Bullpucky.  That's a completely specious argument, and you know your
technology well enough to realize that.  So do most people reading this
list, I'll wager.

> Solving this problem will require some awareness of the content by  
the
> delivery system, and that's not a bad thing, is it? According to
> neutralist dogma, it's the Original Sin. So the choice appears to be
> this: efficient networks or neutral networks, pick only one.

No, the real choice is being honest about technological realities, vs.
psuedo-political spins leading us toward technology's inner circle
of hell.

There are a multitude of topologies that would well serve mass
distribution of media content over the Internet that could be deployed
without creating the kind of anticompetive, inappropriately skewed and
limited frameworks that have become the center of the current
neutrality debate.  The question is whether or not these topologies
can be economically and effectively deployed given the existing
warped, largely unreglated Internet telecom landscape that we must
build upon to move forward.

--Lauren--
NNSquad Moderator




Begin forwarded message:

From: "David P. Reed" <dpreed () reed com>
Date: February 26, 2009 8:07:01 AM EST
To: nnsquad () nnsquad org
Subject: [ NNSquad ] Re: New P2P Privacy System from Univ. of
Washington

Ou engages in egregious misrepresentation of the technical matters he
suggests.  I question his expertise and credentials based on this
performance.   I suspect his goal is FUD, since he lists a collection
of implausible, infeasible, and lunatic hypotheticals to shift the
argument to one about "values" where he can talk about good "ends"
that would justify a slippery slope toward means.

Technical comments regarding the achievability of the proposed
"motivations" hypothesized are intercalated below.  Essentially, Vint
Cerf is right.  If you want a memorable example: DPI can't stop
pictures of children naked being consumed by predators either.  It
doesn't matter if the cause is good if the means don't achieve the
goal within acceptable policy and economic bounds!  Invoking bad
things as reasons for a technically unsound and infeasible remedy
sounds like a marketing campaign in the drug industry: "Got spam? Buy
DPI! It cures all your ills, just trust George Ou".
George Ou wrote:
> DPI is good when we use it to:
> * Inspect content to detect and block virus or malware signatures
>
*Blocking* is not technically feasible, contrary to claims.  In order
to block such content, one would have to buffer many sequential
packets in a flow, holding all packets in a buffer, and only deliver
packets when a unit of application data (such as an email) is
complete.  While programes like driftnet and etherpeek can sometimes
copy such systems, a DPI based system that observed TCP packets *while
buffering them* would so seriously disrupt the TCP flow control that
the end system would experience disruption.  As Vint Cerf said, this
can only be done by higher level protocols at endpoints.

Detection of content that spans multiple packets is barely possible:
requires massive history and reassembly: a packet inspecting appliance
in the network is really a massively ineffective place to do it.
> * Inspect content to detect and block denial of service payloads
>
Denial of service typically involves large numbers of packets, not
specific payloads. Packet counting based on destination is not "deep
packet inspection" - it's inspecting IP headers, which routers can do
because it's outtside the envelope.

Payloads that result in denial of service are tied very closely to
applications.  Servers that are conservative on what they accept as
requests (checking length fields, validity of fields) control their own.

Conclusion: blocking infeasible, detection possible but in the wrong
place.
> * Inspect content to detect and block spam
>
Analysis is same as viruses above, plus the important issue that spam
is marketing material, and the recipient may not want a censorious ISP
deciding that marketing of perfectly legal things via email is "bad".
Let the recipient route his/her mail through a spam filter, where it
is less costly to do the filtering than it is at the packet level, and
the filtering can be chosen by the user based on his/her definition of
"unwanted" in the official spam definition: bulk, unwanted, commercial
email.
> * Inspect content to detect replicate data to cache data so that
> unicast
> audio/video delivery scales
>
Taking end-to-end traffic streams apart after buffering them to
reassemble the entire stream, to do a "diff" to determine that the
data is the same is also infeasible. Today every kind of media is
capable of being personalized - in a web browser you don't see the
same page view that everyone else does, because the source
personalizes the data for each customer (ad insertion, if nothing
else, is done at the source server).  This is also true of video
media, the dandy of "multicast" aficionados who think people watch
video live in a 1950's 3 network model.
Complex media cannot be transparently cached.  Any caching that is
useful is source-controlled, using app layer assembly - which Akamai
and others support.
> * Inspect explicit DiffServ labels to properly prioritize traffic
>
Diffserv labels are not deep packet inspection.  They are IP protocol
labels, and standardized independent of application.  They are on the
envvelope.

Conclusion here: author doesn't understand diffserv.
> * Inspect protocol headers to determine implicit prioritization
> label in the
> absence of explicit priority labels
>
There is no technical term: "implicit prioritization label".  The idea
that one can infer priority required by end user from random inputs
like port numbers is out there in the culture, but there are no
studies that show psychological intent can be inferred by reading
protocol headers.  This like reading entrails.
> * Inspect content to offer targeted advertising to pay for free
> wireless
> broadband
>
Since one cannot do this in real time, it depends on an assumption:
that a single user shares the IP address, and therefore can be
understood by the stream of all packets coming from that address.
Advertisers (maybe not ISPs?) want to know people or context, not IP
addresses.  Google is in a good place because one search query,
coupled with a cookie that tracks the particular personal computer
being used, provides strong targeting.  The DPI approach is costly and
less targeted. Financially a weak proposition.

No clarity on how insertion might happen based on DPI.  Would either
need to share information with servers (sell to Google or other ad
based companies) or do forcible insertion by changing expected
content.  For example, intercepting HTTP GETs by DNS forgery and
returning other content.

Google and other app layer systems already tell their users their
policies with respect to this data, and one can choose not to use
Google.  Not ttrue for ISPs.
> * Inspect content to offer targeted advertising to pay for free
> cloud email
> e.g., Gmail
>
Same as above.  App services  can do it better, user knows they do it,
and user chooses.
> * Inspect content to offer targeted advertising when user explicitly
> agrees
> to terms and conditions
>
User has an easy way to let this happen, as with Gmail, just buy your
content services ion the form of an server-based application, from a
vendor who adds that "feature". Technically easy, no DPI required.
>
> DPI is bad when we use it to:
>
> * Inspect content to offer targeted advertising to users without
> disclosure
> or permission from user
>
The disclosure/permission issue is real.  But the technical issues are
the same.






-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com




-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com