[tor-bugs] #16861 [Tor]: Pad Tor connections to collapse netflow records

[Tor Bug Tracker & Wiki]

#16861: Pad Tor connections to collapse netflow records
-------------------------+---------------------------
 Reporter:  mikeperry    |          Owner:  mikeperry
     Type:  enhancement  |         Status:  new
 Priority:  normal       |      Milestone:
Component:  Tor          |        Version:
 Keywords:               |  Actual Points:
Parent ID:               |         Points:
-------------------------+---------------------------
 The collection of traffic statistics from routers is quite common.
 Recently, there was a minor scandal when a University network
 administrator upstream of UtahStateExits (and UtahStateMeekBridge) posted
 that they had collected over 360G of netflow records to boingboing:
 https://lists.torproject.org/pipermail/tor-relays/2015-August/007575.html

 Unfortunately, the comment has since disappeared, but the tor-relays
 archives preserve it.

 This interested me, so I asked some questions about the defaults and
 record resolution, and did some additional searching. It turns out that
 Cisco IOS routers have an "inactive flow timeout" that by default is 15
 seconds, and it can't be set lower than 10 seconds. What this timeout does
 is cause the router to emit a new netflow "record" for a connection that
 is idle for that long, even if it stays open. Several other routers have
 similar settings. The Fortinet default is also 15 seconds for this. For
 Juniper, it is also 30 seconds (but Juniper routers can set it as low as 4
 seconds).

 With this information, I decided to write a patch that sends padding on a
 client's Tor connection bidirectionally at a random interval that we can
 control from the consensus, with a default of 4s-14s. It only sends
 padding if the connection is idle. It does not pad connections that are
 used only for tunneled directory traffic.

 It also gives us the ability to control how long we keep said connections
 open. Since the default netflow settings for Cisco also generate a record
 for active flows after 30 minutes, it doesn't make a whole lot of sense to
 pad beyond that point.

 This should mean that the total overhead for this defense is very low,
 especially since we have recently moved to only one guard. Well under 50
 bytes/second for at most 30 minutes.

 I still have a few questions, though, which is why I put so many people in
 Cc to this ticket. I will put my questions in the first comment.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16861>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online