Skip to content
Snippets Groups Projects

Core Tor Roadmap

Last edited by Cecylia Bocovich

This is a overview of core tor issues that impact the anti-censorship team. This is the result of roadmap planning with the network team and can be used as a reference and updated as needed.

Prioritized issues are grouped by topic.

IPv6 support

Our current story is that IPv6 only really works for vanilla bridges, because while you can only specify a single IP address in the "transport" line of extrainfo docs, you can specify multiple OR addresses. We have a suggested workaround (rdsys#73 (closed)) to optimistically test all IPs in our OR addresses with bridgestrap, but this isn't a great solution. Ideally, we could include multiple transport lines in the extrainfo doc.

  • Fix IPv6 bridges with a private/dynamic IPv4 address (tpo/core/tor#4847 (closed))

  • Multiple ServerTransportListenAddr entries should be allowed per transport (tpo/core/tor#11211)

  • Make IPv6-only bridges work (#23824)

  • No IPv6 support when suggesting a bindaddr to a PT (tpo/core/tor#12138)

    • note: related to IPv6 but should probably close

  • Which address should a multi-ORPort Tor put in its "transport" extra-info line? (tpo/core/tor#7962)

  • Implement Bridge Guards and other anti-enumeration defenses (tpo/core/tor#7144)

    • note: prereq for fixing tpo/core/tor#23824 (closed)?
    • Alternative design instead of needing to do tpo/core/tor#7144: For a truly v6-only bridge, which doesn't know how to reach any v4 address: Add a line in the bridge descriptor that says "I can't reach v4" and then the client can see that line and choose its paths better.

The following tickets are related and/or adjacent to this problem:

User side improvements

Make sure the bridges work for users and that they can bootstrap quickly and effectively.

  • tor fails to kill its pluggable transports when it's done using them (tpo/core/tor#21967)
  • We fetch bridge descriptors on every setconf and we retry way too aggressively (tpo/core/tor#40513)
  • Slow clients can't bootstrap because they expire their consensus fetch but then receive all the bytes from it anyway, making them expire their next fetch, putting them in a terrible loop (tpo/core/tor#16844) (every user on a bad network hits this)
  • Good bridge + bad bridge = no bootstrap (tpo/core/tor#40396 (closed))
  • Don't kill the managed proxy if a transport failed to launch (tpo/core/tor#7362 (closed))
  • "Pluggable Transport process terminated" but Tor keeps on going (and of course doesn't work) (tpo/core/tor#33669 (closed))

Network Health

Do we have enough bridges? Are these bridges working well? Are client circuits good?

  • Bridge Authority never assigns a Stable flag to bridges (tpo/core/tor#40449)
  • Option to start as a bridge by default, but change to relay if bw is super-high (tpo/core/tor#9323 (closed))
    • note: could be really cool, but looks like a lot of work
  • If your bridge is near your exit, Tor might surprise you by failing your circuit (tpo/core/tor#2998 (moved)) (also user improvement) (high priority)
    • notes: collaboration with network health, needs more information, probably low priority

UX for bridge operators

Making it easy to run bridges and keep them up to date

  • Place complete obfs4 bridge line in accessible location (tpo/core/tor#29128)
  • Bridge-Relay HOWTO wiki update for distros with apparmor, escalade log level when transport plugin process is killed (tpo/core/tor#40459)
  • Bridges should report implementation versions of their pluggable transports (tpo/core/tor#11101 (closed))

Make bridges more able to circumvent censorship

PT spec (Putting off for arti? Lower priority)

Unsorted

Low priority

Comments

    Please register or sign in to add a comment.