[tor-relays] clarification on what Utah State University exit relays store ("360 gigs of log files")

[Mike Perry]

grarpamp:
> On Thu, Aug 13, 2015 at 3:40 AM, Mike Perry <mikeperry at torproject.org> wrote:
> >> But consider looking at average flow lifetimes on the internet. There may
> >> be case for going longer, bundling or turfing across a range of ports to falsely
> >> trigger a record / bloat, packet switching and so forth.
> >
> > This interests me, but we need more details to determine what this looks
> > like in practice.
> 
> NANOG list could link specific papers regarding nature of the internet.
> The various flow exporters have sensible default timeouts tend cover
> that ok for purposes intended.
> 
> > I suspect that this is one case where the switch to one guard may have
> > helped us.
> 
> In that various activities such as ssh, browsing, youtube, whatever
> are confined to being multiplexed in one stream, that makes sense.
> 
> > However, Tor still closes the TCP connection after just one
> > hour of inactivity. What if we kept it open longer?
> 
> The exporting host has open flow count limited by memory (RAM).
> A longer flow might be forced to span two or more records.
> The "flags" field of some tools and versions may not mark
> a SYN seen in records 2+, the rest of tuple would stay same.
> Active timeout gives periodic data on longer flows, typically
> retaining start time but implementations can vary on state.
> 
> Here's an early IOS 12 default...
>   Active flows timeout in 30 minutes (1~60)
>   Inactive flows timeout in 15 seconds (10~600)
> 
> Also consider what is wished to hide, big iso download,
> little http clicks, start time of some characteristic session
> rippling across or appearing at edges, active data pumping attack.
> And what custom flowish things and flow settings an adversary
> might be doing to observe those. Traditional netflow seems
> useful as idea base to form a better heuristic analysis system.

I submitted a proposal to tor-dev describing a simple defense against
this default configuration:
https://lists.torproject.org/pipermail/tor-dev/2015-August/009326.html

I'm also working on an implementation of that defense:
https://trac.torproject.org/projects/tor/ticket/16861

Anyone with netflow experience should feel free to chime in there (or
here if you are not subscribed to tor-dev), but please be mindful of the
adversarial considerations in section 3 (unless you believe that
adversary model to be invalid, but please explain why).


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150820/78985e4b/attachment.sig>