Steven wrote:
So, I've concluded that these little bursts of packet loss are really just some failed equipment of the backhaul carrier, and that it isn't fixed yet is most simply explained by incompetence.
At first all I read in your graph was the latency drop. But yes now I see the underlying loss shift from green to a darker base. It can be crap hardware / connection or bandwidth overload. In those cases you can open a ticket with whatever data you can find and see what comes back. If you hit gold, ask them for a job if you want one :)
Latency drops are usually cutting legacy routers and needless layers out of the path, or more direct physical routes. Fewer hops are also sometimes seen with mpls or enabled by longer range optics layers in place of routers.
If there are any "stupid" adversaries left, they might show up as increase in latency / loss / hop count, rarely a decrease, unless their TTL editing is broken.
It's also will never be seen as a bad move to shut down a relay if adversary action is suspected until explained otherwise. Reasonable caution and consideration and input sought, whether public or private, is a good thing in this game.
Short bursts of packet loss like this, if someone was doing that deliberately with a set pattern, would have been an ideal way to watermark streams going in and out of the Tor network, to do some timing correlations.
Actually, there's a really interesting research subfield on *undetectable* watermarks -- that is, injecting a signal that is essentially noise unless you know the key that generated it, and then detecting that signal elsewhere in the network.
For papers in this area, check out https://www.freehaven.net/anonbib/#ndss09-rainbow https://www.freehaven.net/anonbib/#ndss11-swirl https://www.freehaven.net/anonbib/#pets13-flow-fingerprints
Roger points out some good papers, and has listed others previously that you can look for in the archives.
I often submit [reasonably or not] that, and as suggested in at least one of those papers... 1) if an adversary can inject / mod undetectables into, or otherwise unrevertably data tag, your encrypted datastream, you need to rethink that stream. 2) you can defeat network traffic analysis / timing / correlation by GPA's, including active fill / loss and modulation attacks upon the wire itself, by establishing fulltime dynamic fill traffic in place of otherwise voids in user demand load, and by enforcing strict expected and negotiated channel parameters with peers upon penalty of rejection, and by reclocking traffic that you pass. (This is meant p2p parameters, not a solution to rogue nodes otherwise privy to or generating underlying encryption layers over user cleartext content.)
I think the research and development fields on this topic regarding application to potential [overlay] networks (not just necessarily tor) are still very much wide open for those who would like to take them up :)
[cc: tor-talk, for the non relay ops aspect]