Delivery-Date: Mon, 30 Jun 2014 17:26:39 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID
	autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 86A301E0C4A
	for <archiver@seul.org>; Mon, 30 Jun 2014 17:26:38 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id ED63A2F784;
	Mon, 30 Jun 2014 21:26:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 30CE62F681
 for <tor-talk@lists.torproject.org>; Mon, 30 Jun 2014 21:20:31 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id PnoMQawswijE for <tor-talk@lists.torproject.org>;
 Mon, 30 Jun 2014 21:20:31 +0000 (UTC)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com
 [IPv6:2607:f8b0:400c:c01::22b])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 0CD232E76D
 for <tor-talk@lists.torproject.org>; Mon, 30 Jun 2014 21:20:31 +0000 (UTC)
Received: by mail-ve0-f171.google.com with SMTP id jz11so8837441veb.30
 for <tor-talk@lists.torproject.org>; Mon, 30 Jun 2014 14:20:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :content-type; bh=TcnCe22Byds7DGxtGPo/Fh8woi6Z2Im1tsLwLmY1pIk=;
 b=n6HqL/nJDzYoUmL4xFx8gBWgsi7kZAoty5K3QdjV5z1n6cEpHhR48OTUvWSNrtW0vZ
 v/BzRU8Ii/L6mClyK09DAds0RUdzZSJrmFZjKAErl2Camm+AzRp1MGFF9MszMU4o9pM9
 cxGQQufMXua6tzHIDFwcIwmm3uNQ9HGnCjkcdxgZDgmEZ8WT1U4BucpDfHgtU0q3lLcS
 kjPTVWXPx9g76we4MWjJW1bGZHs0MNSGvOUyGtpA8ZGIsFTybxSi57E2oUaftMk7gdV7
 TiIBnzraIrQL6o3qogh51kIsbKImxP+zFPijmEJj8N8E4J4wnj+tvp2PJ+t1quKhUI4j
 8/Ag==
MIME-Version: 1.0
X-Received: by 10.58.196.231 with SMTP id ip7mr2895405vec.47.1404163228643;
 Mon, 30 Jun 2014 14:20:28 -0700 (PDT)
Received: by 10.221.65.198 with HTTP; Mon, 30 Jun 2014 14:20:28 -0700 (PDT)
In-Reply-To: <CAJVRA1T+vF-7oX6HC5d5UaBDpOrdSUCRjbUbX+cAFm_0S--DmA@mail.gmail.com>
References: <CAJVRA1Tydi5nB544ggjZM2BvPXC=zGr_8AReO0qP_pxQ3me4UA@mail.gmail.com>
 <CAD2Ti2_F_Zbt8uL5s=hNXaNapnof2KSOPZFVgN3B-qxp5JtQqA@mail.gmail.com>
 <CAJVRA1QzUniu3cLgqLitZR7tp4TchrqD+Ak_Os0Hrm2Oe9aScw@mail.gmail.com>
 <DUB121-W20A3812716DFD202050E82C81B0@phx.gbl>
 <20140627153801.0000732c@unknown>
 <CAJVRA1SWot6NxuTQp+KTYRz-f2HWy0S+N=CHRQ2aWgeX1j_5Lg@mail.gmail.com>
 <20140628111900.00000808@unknown>
 <DUB121-W272A32F9E91A912C390F4FC81A0@phx.gbl>
 <CAOsGNSRgZfy7Z5UgNeDR5pR1E4n2zkB2U9=2w8uQhUfw+C_Raw@mail.gmail.com>
 <DUB121-W1569A0B26038589393C77C8050@phx.gbl>
 <20140629123120.GG7408@moria.seul.org>
 <20140629182427.00004bd3@unknown>
 <CAJVRA1Rmky8cgEvdViQAAcJ1kFUzjQhCHqgsgP19c33-hbDWkQ@mail.gmail.com>
 <DUB121-W43F2345CAFFFDA68EFB8A5C8050@phx.gbl>
 <CAJVRA1T+vF-7oX6HC5d5UaBDpOrdSUCRjbUbX+cAFm_0S--DmA@mail.gmail.com>
Date: Mon, 30 Jun 2014 17:20:28 -0400
Message-ID: <CAD2Ti29L21HrA_rLkKwM2doCtq2JVrffdRxa=iAcrZC+FkwNvA@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] Illegal Activity As A Metric of Tor Security and
	Anonymity
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On Mon, Jun 30, 2014 at 2:15 AM, coderman <coderman@gmail.com> wrote:
> 1) compute the cost of global traffic analysis.  we have big data mark

> specifically UPSTREAM model collection at backbone peering points.

> this is just one part of a series of costs; how much raw DPI capacity
> (it is finite)? how much memory/storage for backtrace to some hours
> window? 30day window? how much engineering time (earth human hours) to
> implement the collection, classification, and analysis of all flows in
> daily time? in near-real-time (<60sec)? how is accuracy beyond doubt
> identified? how much does additional accuracy in shorter time cost?

Along your three posts relative to the above...

Netflow at scale is a challenge but not an impossibility. First
address creating, recording and searching the flows. Then induce a
client/server to [regularly] create traffic you can spot and search
for it [1]. You don't need full take / DPI for that. And once a tap
is in place you can use it for both at once. Excluding the secret
tap itself [2], estimating costs of netflow per bandwidth is a
matter of common commercial parts. (Storage is fixed, but there are
probably some speedups to be had in creating, filtering and search
with custom gear.) ISP's routinely utilize netflow for engineering
metrics and security things.

[1] Tor, I2P, high latency, low latency, store-forward, etc...
perhaps with any non busy / non full of chaff / non fixed cell size
system this could be recognizably induced. And the list of relays
in these networks is known which allows you to select and handoff
those flows for dedicated analysis.

[2] Getting enough taps out there and at the right places to ensure
that your searches have some useful hit rate... now that seems the
hard and expensive part if you don't have some cooperation/force
with the Tier-n's.

For this induced purpose it's probably cheaper and easier to Sybil
up a bunch of nodes than to tap the internet. Yet I'd not discount
the possibility and value of some larger attempt at global analysis
like that. Especially since ISP's and researchers already do it on
their own scales.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

