[tor-relays] Connectivity issues; disabling my relay

[grarpamp]

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]