| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | | |
| | |
| | |
| | |
| | | |
Just fixing some line wrap and case (keywords like 'SHOULD' are uppercase by
convention).
|
| |\ \ \
| |/ /
|/| | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Also fix a typo pointed out by Marc Juarez, and perform some other misc
cleanups.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Changes:
* A zero machines.transition_burst_events means an immediate
transition to the burst state.
* Added RELAY_PADDING_TRANSITION_EVENT_BINS_EMPTY to allow a state
transition when the bins become empty.
* Change remove_tokens to allow client to specify removal direction
for non-padding packets.
* Make RELAY_COMMAND_PADDING_SCHEDULE take a variable number of scheduled
times.
* Increase and clarify rate limits.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Forgetting to specify the infinity transitions causes the state machine to
just shut down.
|
| | | | |
| | | |
| | | |
| | | | |
Also clarify terminology and address some formatting issues.
|
| | | | |
| | | |
| | | |
| | | | |
Also allow the histograms to be variable in size.
|
| |/ / /
| | |
| | |
| | | |
This is the version initially posted to tor-dev@lists.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Now I've updated the status of everything in my proposal-status
list.
|
| | | |
| | |
| | |
| | | |
Also let's get our pronouns correct
|
| | | |
| | |
| | |
| | |
| | | |
To be conservative, I'm saying that the proposal editors are everybody
with commit rights, except for Roger, who is way too busy :)
|
| |\ \ \ |
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* 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.)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* CHANGE updated date to today.
* REMOVE paragraphs detailing proposals #197 and #199 from the "stalled
proposals" section.
* ADD proposal #253 to the "proposals to take another look at" section.
* CHANGE the "since last time" section to reflect above changes.
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \ |
|
| | |/ / |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
The state of the art has advanced so much since this was written; this
simply wouldn't get done this way in a modern design.
|
| | | |
| | |
| | |
| | |
| | | |
Microdescriptors make the system described in this proposal not make
sense for current Tors -- it would need significant revision.
|
| | | |
| | |
| | |
| | |
| | | |
It would need heavy revision to work in modern Tor, and we might not
even want it.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
131 is obsolete for being incredibly old, and not being how we'd actually
like torcheck to work any more. It comes from a pre-tbb world.
211 is on reserve since nobody's asked for it in a while, and sensible
folk are maintaining torcheck now.
|
| | | |
| | |
| | |
| | |
| | | |
If we do implement something like this, it won't at all be with a
fetch; it will be with some kind of caching mechanism.
|
| |/ / |
|
| |\ \ |
|
| |/ /
| |
| |
| | |
Also add more data points to the padding timer distribution table.
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Patch by "teor" (Tim Wilson-Brown).
|
| | |
| |
| |
| | |
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
|
| | | |
|
| | | |
|
| | | |
|
