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

[grarpamp]

On Sat, Aug 22, 2015 at 1:09 AM, Mike Perry <mikeperry at torproject.org> wrote:
> As such, I was only able to discover that its default inactive/idle
> timoeut is 30s. I couldn't find a range.

> What I really need now is any examples of common routers that have a
> default inactive/idle timeout below 10s, or allow you to set it below 10s.

Not common unless you consider all the places where
software is being used as a network tap, whether by legit
operator, or by adversary.

nProbe can timestamp in milliseconds.
[ 21] %LAST_SWITCHED              %flowEndSysUpTime
SysUptime (msec) of the last flow pkt
[ 22] %FIRST_SWITCHED             %flowStartSysUpTime
SysUptime (msec) of the first flow pkt
[152] %FLOW_START_MILLISECONDS    %flowStartMilliseconds        Msec
(epoch) of the first flow packet
[153] %FLOW_END_MILLISECONDS      %flowEndMilliseconds          Msec
(epoch) of the last flow packet

Some define and assignment logic sets the defaults.
It's software so anyone could adjust the options to at least
fall within the "hardcoded" integer type... 1 to u_short. That
doesn't mean it's sensible or that other bits in the code won't
need munged, I didn't look.

u_short idleTimeout, lifetimeTimeout, sendTimeout;
#define DUMP_TIMEOUT    30 /* seconds */
readOnlyGlobals.idleTimeout = DUMP_TIMEOUT;
readOnlyGlobals.lifetimeTimeout = 4*DUMP_TIMEOUT;
      readOnlyGlobals.idleTimeout = atoi(optarg);
      readOnlyGlobals.lifetimeTimeout = atoi(optarg);
      if(readOnlyGlobals.lifetimeTimeout == 0) {
        readOnlyGlobals.lifetimeTimeout = 1;
  printf("[--lifetime-timeout|-t] <timeout>   | It specifies the
maximum (seconds) flow\n"
         "                                    | lifetime
[default=%d]\n", readOnlyGlobals.lifetimeTimeout);
  printf("[--idle-timeout|-d] <timeout>       | It specifies the
maximum (seconds) flow\n"
         "                                    | idle lifetime
[default=%d]\n", readOnlyGlobals.idleTimeout);


> I think these devices are wandering into the "adversarial admin"
> territory (see section 3 of the proposal). I want to focus on the case
> where the adversary demands/sniffs/exploits routers likely to be
> installed in most networks.

Sniffs...
Lavabit was [nearly/actually] forced to install devices on
his network for some while, so I see no "Sorry, my
vendors config range doesn't support it" distinction here.
Telecoms like AT&T don't fight, and Vampires don't care.

Demands...
The point with the NICs is that even 100Gbit taps are old news.
With that comes deployment of flow / bro / etc like things
that use them and the logs get saved because humans love
to create collect and save useless stuff... to supply on demand.
Software taps are popular, probably moreso at the network
edges... universities, corp, regional / city, colo, etc.
But costs are dropping, tech is rising, depts are doing these things.

Yes, a legit operator may be unlikely to adjust, or
to set the timeouts too low on their own free will since:
1) why, 2) storage space, 3) processing cpu / bandwidth

Exploits...
It's all software in the end.

I know, I'm partly diverging from legit operator context.