grarpamp:
On Thu, Aug 13, 2015 at 3:40 AM, Mike Perry mikeperry@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).