grarpamp: > On Thu, Aug 13, 2015 at 3:40 AM, Mike Perry <mikeperry@xxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays