Re: [tor-talk] Matryoshka (fill traffic in networks?) [was: Are TOR holes intentional?]

[Zenaan Harkness <zen@xxxxxxxxxxxx>]

On 6/18/15, grarpamp <grarpamp@xxxxxxxxx> wrote:
> On Thu, Jun 18, 2015 at 12:51 AM, Roger Dingledine <arma@xxxxxxx> wrote:
>> but it sure looks like another case of somebody not understanding the
>> research field, and thinking that solving the traffic confirmation
>> attack is easy, without actually thinking through the engineering side,
>> the scaling side, or the statistics side.
>
> There's certainly no easy solution to all problems. Though
> there could be value in those that put more odds in your favor,
> even though they do not yield 100% solution or protection.
>
> If you rarely tx but then emit something [unique or timely]
> that pops out at some [rare] destination, you're done for.
> I think we've seen posts from some people who slow crawl the
> web 24x7 when their client is running just to add cover at their
> end for their interspersed real web activity.

For a potentially useful project to many: software to crawl and cache
popular news sites into a content addressed darknet/ localnet cache,
so that folks can browse the daily news without using exit nodes.

Trust network above that is a separate task entirely.

For bonus points, have the content addressing be in git.


>> But even full scale padding, ignoring the practical side of how to get a
>> Tor network that can afford to waste so much bandwidth
>
> Waste is an incorrect, negative term for designed in padding (fixed
> set of lengths) or fill (empty links) or chaff (ratio) or whatever this is.
>
> A design where fill traffic gets out of the way when real data is
> being sent might have periods of congestion or underutilization
> of the link depending on the distance in hops the fill is managed
> over, and the speed of the sensing and feedback controls.
> Seems that might need to be as fast as you could initiate a first
> packet across, unless you inhibit that packet until ready.

Just as the disadvantages of HFT (high frequency trading) can be
handled with a trade-window model (all trades are batched into a 1s,
or 10s or whatever window to be resolved by the exchange at the end of
each window), "inhibit packet until ready" makes me think this might
be applied to Tor networks - specifying a "relatively high" minimum
latency for new session initiation. But again, it's the type of
problem/solution potential which needs genuine analysis to know if
there's going to be a non-trivial privacy enhancing benefit. I can
only make assumptions sorry.


>> doesn't provide
>> protection in the face of active attacks where you induce a gap on one
>> side and then observe the gap on the other side. And it might even be
>> the case that these gaps happen naturally by themselves, due to network
>> congestion and so on, so maybe passive observers will be winners even
>> against a design that does full padding.
>
> I've said that fill seems useful against passives, not actives.
> However a design may actually be possible such that any disturbance
> or deficiency in fill might be possible to make up from other sources.

E.g. your entry point (e.g. ISP) introduces "random peak bandwidth
drops/ latency holes" and when the ISP's incoming networks fail to
keep up their side of this same bargain, the link deteriorates
completely.

This implies an ISP who is on the side of the users, at this point a
rare thing (if it exists at all).


> In other words, if I knock you off the net, the remaining path your data
> would have taken to your endpoint will still be filled so as not to expose
> the far end as being tied to you (if the fill management scope of the
> network is finer grained than just the end nodes negotiating end-to-end
> with each other (ie: I think the entire net will need to negotiate their
> own
> mesh of fill peers as an underlying management layer, with possible
> cues from above)). You get knocked off, your former peers sense this
> and recalc their fill sources and sinks.

This 'feels' like it has potential. Except I think it presumes that at
least your starting node(s) (eg ISP) are not actively adversarial to
you - but are we assuming this anyway with current Tor? (Sorry for my
ignorance.)


>> tl;dr the whole premise of this person's blog post is flawed, since
>> their design likely does not work as they think it does.
>
> While someone's design may be insufficient to solve some problem,
> it does add value in the form of talk of possible solutions and trialing
> them. Thereby others can try different / related avenues to a solution.

A thought I've pondered for a couple years now - and now in this
context, let's say my geographic neighbour and I each have an ISP
uplink, and wireless connection between one another.

If my "underlying fill traffic network" (physical/PHY layer, at least
from my perspective as an end user) can somehow include the private
connection between my neighbour and I, and if the ISP actively targets
one of us and crimps the connection, and then the neighbour similarly
("pro-actively") crimps his connection in 'almost parallel', could
this provide some level of plausible deniability of the exit-node
traffic being correlated to either one of us?

(Expand algorithmically to more than one neighbour.)


Is it worth beginning an "ISP end user fill traffic protocols best
practices RFC" for those ISPs who genuinely want to do the right
thing, legally as well as by their customers?

Or is the multiplexing of the last-node-before-the-home (eg the ISP's
DSLAM ADSL modem bank) simply not capable of such things?

I guess what I'm asking: what's the ideal way to roll out
community-/state- wide internet networking infrastructure, from a
respect-the-uesrs-privacy perspective?


>> For background see e.g.
>> http://freehaven.net/anonbib/#danezis:pet2004
>
>> This is a great area for further research:
>> http://freehaven.net/anonbib/#ShWa-Timing06
>> http://freehaven.net/anonbib/#active-pet2010
>
> I don't mean that Tor specifically needs to investigate or implement
> fill, but that since the research area is probably not complete,
> and that no operational net is trying it, it's worth continued work.

Let's keep asking the questions and attempting to answer them, and see
if we can't eliminate the benefit logically (without having to wait
for a high fallutin' acamedic paper).

Eg 1: there are fibre-optic "DSLAMs" (modem banks? - dunno the term
sorry), which simply broadcast all client downlinks to all end-points,
and it's only the end point modems which "do the right thing" and
ignore their neighbour's traffic.

In this scenario, there may only be 2Gbps of bandwidth shared amongst
1000 homes. If all homes jump on the "maximize fill traffic"
bandwagon, each will get at most a fixed 2Mbps link - fast by many
standards, but nowhere near what would be achieved in a
forget-about-privacy scenario.

And then, what should happen at the ISP level?

What sort of protocols would make sense for ISP interconnection - to
other ISPs, to upstream ISP/ national backhaul, to international
(usually expensive) links?

Eg 2: ADSL DSLAM - can this device scale reasonably to all homes
connected to this DSLAM?


In either scenario, do we need to start thinking new equipment, or
just new protocols - since fill-traffic is a type of protocol and as
we've read, proposals have been made for ethernet-level fill traffic.


> If anyone knows a good list that does or would serve as home for
> such work, please say so as I'm unaware of any.

Clear thinking, ask the hard questions, gather answers, write it up in
an RFC or draft "paper", post for review, and it'll eventually get
archived at the usual places - even if the answers are "we can't do X
and Y for reasons A and B" - these would be very useful answers.
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk