Commit 606626d6 authored by Burnleydev's avatar Burnleydev
Browse files

Add Network Health tooling using Rust and arti notes

parent bfa22950
# Tor Hackweek Project: Network Health tooling using Rust and arti
Summary: Network health has a series of tools in order to query the consensus,
search for patterns and correlate relays. This project is to rewrite some of
them into one unified tool written in Rust and using arti for any Tor related
interactions such as looking up the consensus or creating circuits for testing
connectivity.
Skills: Love, Passion and Legos
# Team:
* dgoulet
* juga?
# Feature ideas:
* Search relays with in the latest consensus by:
- Fingerprint (RSA and/or ED)
- Contact info (pattern, regex?)
- Bandwidth values
- AS
- Nickname (pattern, regex)
- Versions
- Flags
- ...
* Network stats
- Relay counting by flags or versions
- Extra info information such as "how many overload relays do we have"
- Count onion service bandwidth
* Bad relays config
- Generate bad relay dirauth configuration
* Network test
- Test Exit DNS
- Test ORPort/Dirport
- Test connectivity IPv4/IPv6
# Nick's Notes:
* For "network test", probably best to use tor-proto crate for low-level fine-grained network usage.
- Possibly, give tor-circmgr the ability to create circuits with specific paths?
- Possibly, consider `tracing` crate for fine-grained events during testing, to analyze timing?
- Look for opportunities to make these APIs simpler or better.
* For search and stats:
- For some of this info, will need to teach tor-dirmgr about fetching ns consensus and routerdesc documents. Also will need to teach tor-netdoc about fetching and parsing ns consensus documents.
- This may warrant refactoring tor-dirmgr.
- Consider sqlite or similar to build a relational database of decoded relay information.
- Consider tools to export the existing state of the network as json, xml, or something else so that arbitrary other scripting tools can handle it.
- Consider clap as a CLI-building tool.
- It might be convenient to teach tor-dirmgr to operate in a "cache-only" mode that just looks at the cache of another dirmgr, and doesn't fetch the directory. Ideally, this would be able to run concurrently with another process that is actually updating the directory.
- For future-proofing, consider making a variant routerdesc/consensus parser that retains recognized data and allows searching it.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment