aboutsummaryrefslogtreecommitdiff
path: root/proposals/188-bridge-guards.txt
AgeCommit message (Collapse)Author
2023-10-12Wrap text proposals in backticks.Nick Mathewson
2020-07-31Mark proposals 188, 262, and 307 as reserve, with reasoning.Nick Mathewson
2015-10-30Add additional comments to prop#188 on bridge reachability self-testing.Isis Lovecruft
2015-09-21Update many proposal statuses.Nick Mathewson
Now I've updated the status of everything in my proposal-status list.
2015-09-10Update prop#188 to match implementation from #7144.Isis Lovecruft
* ADD a new section detailing loose-source routed circuits, including: - How the circuit should appear to the OP, the bridge, and the bridge guard, - How the hop(s) in the path is/are chosen, - How the first hop is handled and how circuit extension is handled, in a generalised sense (i.e. not specific to a bridge using bridge guards), - Which cell types are used and how they are chosen, - When the original create cell is answered (in relation to when cells are sent to the other additional hops), - What should be done when relay cells are received when the additional hops in the loose-source routed circuit are not fully constructed, - How the circuit crypto and cell digests for incoming/outgoing relay cells works (again, in a generalised sense, i.e. not specific to bridges using bridge guards), - How and whether a given relay cell is treated as "recognized", - Under what circumstances (based on whether a stream is attached and which relay command was sent) should cause a node which uses loose-source routed circuits to drop a relay cell or mark a circuit for close, and, - When and what statistics should be gathered for loose-source routed circuits. * UPDATE and clarify the example loose-source routed circuit construction (the original one from the proposal which was specific to a client using a bridge that uses bridge guards). * CHANGE the "Make it harder to tell clients from bridges" section which described the tradeoffs between using CREATE versus CREATE_FAST cells for the first additional hop (i.e. the bridge guard). Those concerns is no longer entirely relevant, since, in the meantime, we've introduced the NTor handshake and it's extremely likely that both the client and the bridge will use CREATE2 for all their hops. * ADD a new section on enumerating bridges via the behaviours inherent to bridge reachability testing. * REMOVE open question (from the very end of the proposal) regarding whether the standard guard selection algorithms are adequate. They are. (Even if they are convoluted and overly-complicated.)
2012-06-12add in a point that rransom and i independently came up withRoger Dingledine
2011-10-20Oops; commutative, not transitive.Nick Mathewson
2011-10-19Proposal for bridges to redirect traffic through guard nodesNick Mathewson