[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:  needs_review
     Priority:  normal       |  Milestone:
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------

Comment (by yawning):

 Replying to [comment:13 mikeperry]:
 > Ok, I just pushed fixes for Nick's review to the neflow_padding-squashed
 branch, and have a new squashed patch at
 https://gitweb.torproject.org/mikeperry/tor.git/commit/?h=netflow_padding-
 squashed2.

 I'll look at this when I have a moment, which realistically will probably
 be sometime next week.  But chiming in a bit on your comments...

 I'd like to see how this interacts with the circuit scheduler since we can
 avoid sending padding if we have user payload to transmit instead.  If you
 do that already, great.  If not, interactions here need to be carefully
 considered (and the relevant optimizations made).

 [snip]

 > I'm still now sure what to do about the following:
 >  * Is there a way to test for a slow gettimeofday()? I noticed some
 TIME_IS_FAST ifdefs in util.c, but nothing sets that define. We *can* use
 time() if we need to, and it will still work fine, but we'll end up
 sending more padding due to truncation error in that case (which is why I
 added timestamp_active_highres in the first place).

 Systems with a slow `gettimeofday()` will likely have a slow `time()` as
 well, so I don't see much of a point here.  The only systems I can think
 of that fall under this that are relays are old Linux (who cares) and some
 of the BSD variants (FreeBSD in certain virtualization envs in particular,
 may be fixed).

 What matters here is "does the OS vDSO certain libc calls".

 >  * How should we check if there are too many libevent timers scheduled?
 Note that the code didn't (and still doesn't) schedule a callback unless
 we're within 1 second of the padding timeout. It just waits for the next
 invocation in those cases. That should mean that even if all connections
 are always idle, only 1/10 of them are scheduling timer callbacks (because
 the function is called once per second, and the timeout range is 10
 seconds wide). We can still check for to many timer callbacks anyway, and
 call directly in that case, but how do I do that? I've added an XXX in the
 code where we'd need to do this.

 If too many libevent timers are a problem, then why not use 1 libevent
 timer, and a doubly linked list of padding events? (Or a more
 sophisticated data structure if insertion is too expensive)...

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