Home page logo
/

interesting-people logo Interesting People mailing list archives

Re: 2 on New P2P Privacy System from Univ. of Washington
From: David Farber <dave () farber net>
Date: Sun, 1 Mar 2009 12:54:08 -0500



Begin forwarded message:

From: "Michael O'Dell" <mo () ccr org>
Date: March 1, 2009 11:36:14 AM EST
To: dave () farber net
Subject: Re: [IP] Re: 2 on New P2P Privacy System from Univ. of Washington

I admit to no debate on Deep Packet Inspection by ISPs,
advertisers, or other assorted evesdroppers.

It is very, very simple and as black-and-white as they come:

        It is WRONG and Deeply Evil.

There is no righteous purpose, period. Full Stop.

The fact that various government agencies are very good
at it is irrelevant.

        "When the President does it, it's STILL Wrong."

To borrow a phrase from an alternate universe:

        "Deep Packet Inspection: Just Say NO!"

Yours for continuing moral clarity,
        
        -mo



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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault