QoS acts as a countermeasure by preventing flows on an
an anonymity-network node from interfering with each other.
However, an inevitable result is that when a flow is running
at less than its reserved capacity, CPU load on the node will
be reduced. This induces a temperature decrease, which af-
fects the frequency of the crystal oscillator driving the sys-
tem clock. This effect can be measured remotely by requesting
timestamps and deriving clock skew. This vector is not low hanging fruit  but it would be good to shut down for those who need higher assurance.
(The NFQUEUE-based fix for the latency is great beause this was a more practical real world attack)
TCP ISNs are not possible to block and needed for security anyway. Are a part of all modern OSs.
The only practical solution listed in the paper/slides 
> 23C3 Slide 30:
> Run CPU at full load - Inefficient and must be done with care since different types of tasks can have varying temperature effects
Deployment: on host out of reach of malicious code in vm.
Can disabling c-states accomplish the same?
> However, the suggestion of disabling c-states more or less obsolesces
> this suggestion, as the `stress` solution could easily decrease battery
> life by 2-3x, whereas I've never seen wattage even double from disabling
> However, the suggestion of disabling c-states more or less obsolesces this suggestion, as the `stress` solution could easily decrease battery life by 2-3x, whereas I've never seen wattage even double from disabling c-states.
> Another option with Linux is to use TCP sequence numbers, which
> are the sum of a cryptographic result and a 1 MHz clock.
> Over short periods, the high h gives good results, but as the
> cryptographic function is re-keyed every 5 minutes, main-
> taining long term clock skew figures is non-trivial.