Opened 3 years ago

Last modified 17 months ago

#19068 new task

Write and run a clique reachability test.

Reported by: yawning Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: stem, tooling
Cc: atagar, phw, catalyst Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

It would be useful to know what the full inter-relay connectivity graph looks like, and how far it differs from the "every relay can always reach every other relay" ideal.

https://www.sba-research.org/wp-content/uploads/publications/NavigaTor_preprint.pdf

This should be something doable with stem, and ideally we can run it periodically/automatically, and use it to do things like reject relays that have extremely poor connectivity.

Child Tickets

Change History (12)

comment:1 Changed 3 years ago by arma

Cc: atagar phw added

Yes please!

This was one of the original goals of Torflow.

And I feel like somebody did a test of this more recently, but I don't remember who and can't find the ticket. I am cc'ing two usual suspects in case they remember.

comment:2 Changed 3 years ago by teor

I've also done some work on this recently. I might even be able to provide the stem script.

comment:3 in reply to:  2 Changed 3 years ago by cypherpunks

Replying to teor:

I've also done some work on this recently. I might even be able to provide the stem script.

Great! Looking forward to it.

comment:4 Changed 3 years ago by teor

There's also this work in progress (not by me):
https://github.com/TheTorProject/bwscanner/blob/develop/bwscanner/detect_partitions.py

Some of the issues I ran into when writing a similar script:

  • network load - running these tests as fast as you can puts significant load on the network
  • what if a relay is down, rather than blocked?
  • making ~7000 connections through a single relay might overload it, particularly if it's low-bandwidth, file-descriptor limited, or behind a NAT box
  • connection testing is directional - sometimes relay A can initiate a connection to relay B, but relay B can't initiate a connection to relay A. But once they're connected, they can both exchange cells

comment:5 Changed 3 years ago by teor

Oh, and another:

  • if you collect timing information, it could be used to analyse relay load or the existence of existing circuits. So best to blur that information out.

comment:6 Changed 3 years ago by teor

And here is something I prepared earlier:
https://github.com/teor2345/onion-graph

comment:7 Changed 2 years ago by dgoulet

Component: Core TorCore Tor/Tor

comment:8 Changed 22 months ago by arma

See also #12131 for an overlapping ticket.

comment:9 Changed 22 months ago by catalyst

Cc: catalyst added

comment:10 Changed 22 months ago by ra

the question which specific relays have problems reaching other relays was already answered in #12131 (three years ago). being the main author of the NavigaTor paper mentioned by the OP, I can say that the code used for answering the question (https://bitbucket.org/ra_/tor-relay-connectivity/) shares some ideas of the NavigaTor code - as said in #12131. feel free to reuse it.
as far as I can remember, there were a couple of relays that had tremendous outbound connection issues (which looked kind of fishy but is probably due to firewall misconfiguerations) - see https://trac.torproject.org/projects/tor/attachment/ticket/12131/bad_outbound_connections.csv.

comment:11 Changed 21 months ago by dgoulet

Milestone: Tor: unspecified

Missing milestone.

comment:12 Changed 17 months ago by cypherpunks

just putting a pointer to David's related tor-project ML posting here:
https://lists.torproject.org/pipermail/tor-project/2017-October/001492.html

Note: See TracTickets for help on using tickets.