diff options
Diffstat (limited to 'spec/guard-spec')
-rw-r--r-- | spec/guard-spec/algorithm.md | 52 | ||||
-rw-r--r-- | spec/guard-spec/appendices.md | 8 | ||||
-rw-r--r-- | spec/guard-spec/circuit-creation-entry-guard-selection-1000-foot.md | 2 | ||||
-rw-r--r-- | spec/guard-spec/still-non-addressed-issues-sectiontodo.md | 2 |
4 files changed, 32 insertions, 32 deletions
diff --git a/spec/guard-spec/algorithm.md b/spec/guard-spec/algorithm.md index 5e30782..b18803b 100644 --- a/spec/guard-spec/algorithm.md +++ b/spec/guard-spec/algorithm.md @@ -4,7 +4,7 @@ <a id="guard-spec.txt-4.0"></a> -## The guards listed in the current consensus. [Section:GUARDS] +## The guards listed in the current consensus. \[Section:GUARDS\] By {set:GUARDS} we mean the set of all guards in the current consensus that are usable for all circuits and directory @@ -17,7 +17,7 @@ from any guard, so that all guards are usable for all circuits. <a id="guard-spec.txt-4.1"></a> -## The Sampled Guard Set. [Section:SAMPLED] +## The Sampled Guard Set. \[Section:SAMPLED\] We maintain a set, {set:SAMPLED_GUARDS}, that persists across invocations of Tor. It is a subset of the nodes ordered by a sample idx that @@ -130,7 +130,7 @@ adversary node. <a id="guard-spec.txt-4.2"></a> -## The Usable Sample [Section:FILTERED] +## The Usable Sample \[Section:FILTERED\] We maintain another set, {set:FILTERED_GUARDS}, that does not persist. It is derived from: @@ -185,9 +185,9 @@ filtering restrictions that we had in the past. <a id="guard-spec.txt-4.3"></a> -## The confirmed-guard list. [Section:CONFIRMED] +## The confirmed-guard list. \[Section:CONFIRMED\] -[formerly USED_GUARDS] +\[formerly USED_GUARDS\] We maintain a persistent ordered list, {list:CONFIRMED_GUARDS}. It contains guards that we have used before, in our preference @@ -247,7 +247,7 @@ traffic. <a id="guard-spec.txt-4.4"></a> -## The Primary guards [Section:PRIMARY] +## The Primary guards \[Section:PRIMARY\] We keep a run-time non-persistent ordered list of {list:PRIMARY_GUARDS}. It is a subset of {FILTERED_GUARDS}. It @@ -280,7 +280,7 @@ usable after all. <a id="guard-spec.txt-4.5"></a> -## Retrying guards. [Section:RETRYING] +## Retrying guards. \[Section:RETRYING\] (We run this process as frequently as needed. It can be done once a second, or just-in-time.) @@ -303,7 +303,7 @@ now from the fact that it was unreachable a few minutes ago. <a id="guard-spec.txt-4.6"></a> -## Selecting guards for circuits. [Section:SELECTING] +## Selecting guards for circuits. \[Section:SELECTING\] Every origin circuit is now in one of these states: @@ -385,7 +385,7 @@ In some cases (for example, when we need a certain directory feature, or when we need to avoid using a certain exit as a guard), we need to restrict the guards that we use for a single circuit. When this happens, we remember the restrictions that applied when choosing the guard for -that circuit, since we will need them later (see [UPDATE_WAITING].). +that circuit, since we will need them later (see \[UPDATE_WAITING\].). **Rationale** @@ -406,11 +406,11 @@ circuit through each, to give it a chance to succeed or fail. If ever such a circuit succeeds, we don't use it until we're pretty sure that it's the best guard we're getting. (see below). -[XXX timeout.] +\[XXX timeout.\] <a id="guard-spec.txt-4.7"></a> -## When a circuit fails. [Section:ON_FAIL] +## When a circuit fails. \[Section:ON_FAIL\] When a circuit fails in a way that makes us conclude that a guard is not reachable, we take the following steps: @@ -427,17 +427,17 @@ is not reachable, we take the following steps: below.) ``` -[Note: the existing Tor logic will cause us to create more +\[Note: the existing Tor logic will cause us to create more circuits in response to some of these steps; and also see -[ON_CONSENSUS].] +\[ON_CONSENSUS\].\] **Rationale** -See [SELECTING] above for rationale. +See \[SELECTING\] above for rationale. <a id="guard-spec.txt-4.8"></a> -## When a circuit succeeds [Section:ON_SUCCESS] +## When a circuit succeeds \[Section:ON_SUCCESS\] When a circuit succeeds in a way that makes us conclude that a guard _was_ reachable, we take these steps: @@ -466,17 +466,17 @@ guard _was_ reachable, we take these steps: [UPDATE_WAITING] below) ``` -[Note: the existing Tor logic will cause us to create more +\[Note: the existing Tor logic will cause us to create more circuits in response to some of these steps; and see -[ON_CONSENSUS].] +\[ON_CONSENSUS\].\] **Rationale** -See [SELECTING] above for rationale. +See \[SELECTING\] above for rationale. <a id="guard-spec.txt-4.9"></a> -## Updating the list of waiting circuits [Section:UPDATE_WAITING] +## Updating the list of waiting circuits \[Section:UPDATE_WAITING\] We run this procedure whenever it's possible that a `<waiting_for_better_guard>` circuit might be ready to be called @@ -516,9 +516,9 @@ them after all if the `<complete>` circuit goes down before <a id="guard-spec.txt-4.9.1"></a> -### Without a list of waiting circuits [Section:NO_CIRCLIST] +### Without a list of waiting circuits \[Section:NO_CIRCLIST\] -As an alternative to the section [SECTION:UPDATE_WAITING] above, +As an alternative to the section \[SECTION:UPDATE_WAITING\] above, this section presents a new way to maintain guard status independently of tracking individual circuit status. This formulation gives a result equivalent or similar to the approach @@ -540,7 +540,7 @@ these rules: 1. Primary guards are always usable. -2. Non-primary guards are usable _for a given circuit_ if every +1. Non-primary guards are usable _for a given circuit_ if every guard earlier in the preference list is either unsuitable for that circuit (e.g. because of family restrictions), or marked as Unreachable, or has been pending for at least @@ -553,20 +553,20 @@ these rules: Non-primary guards are unusable if they have not become usable after `{NONPRIMARY_GUARD_IDLE_TIMEOUT}` seconds. -3. If a circuit's guard is not usable or unusable immediately, the +1. If a circuit's guard is not usable or unusable immediately, the circuit is not discarded; instead, it is kept (but not used) until the guard becomes usable or unusable. <a id="guard-spec.txt-4.10"></a> -## Whenever we get a new consensus. [Section:ON_CONSENSUS] +## Whenever we get a new consensus. \[Section:ON_CONSENSUS\] We update {GUARDS}. For every guard in {SAMPLED_GUARDS}, we update {IS_LISTED} and {FIRST_UNLISTED_AT}. -[**] We remove entries from {SAMPLED_GUARDS} if appropriate, +\[\*\*\] We remove entries from {SAMPLED_GUARDS} if appropriate, according to the sampled-guards expiration rules. If they were in {CONFIRMED_GUARDS}, we also remove them from {CONFIRMED_GUARDS}. @@ -576,7 +576,7 @@ it, including {USABLE_FILTERED_GUARDS}, and {PRIMARY_GUARDS}. (Whenever one of the configuration options that affects the filter is updated, we repeat the process above, starting at the -[**] line.) +\[\*\*\] line.) ```text 4.11. Deciding whether to generate a new circuit. diff --git a/spec/guard-spec/appendices.md b/spec/guard-spec/appendices.md index 612ff4c..34368ad 100644 --- a/spec/guard-spec/appendices.md +++ b/spec/guard-spec/appendices.md @@ -11,7 +11,7 @@ CNS-1314637, CNS-1526306, CNS-1619454, and CNS-1640548. <a id="guard-spec.txt-A.1"></a> -## Parameters with suggested values. [Section:PARAM_VALS] +## Parameters with suggested values. \[Section:PARAM_VALS\] (All suggested values chosen arbitrarily) @@ -80,7 +80,7 @@ CNS-1314637, CNS-1526306, CNS-1619454, and CNS-1640548. <a id="guard-spec.txt-A.2"></a> -## Random values [Section:RANDOM] +## Random values \[Section:RANDOM\] Frequently, we want to randomize the expiration time of something so that it's not easy for an observer to match it to its start @@ -92,7 +92,7 @@ the past, chosen uniformly at random. <a id="guard-spec.txt-A.3"></a> -## Why not a sliding scale of primaryness? [Section:CVP] +## Why not a sliding scale of primaryness? \[Section:CVP\] At one meeting, I floated the idea of having "primaryness" be a continuous variable rather than a boolean. @@ -102,7 +102,7 @@ how it might work. To begin with: being "primary" gives it a few different traits: -1) We retry primary guards more frequently. [Section:RETRYING] +1. We retry primary guards more frequently. \[Section:RETRYING\] ```text 2) We don't even _try_ building circuits through diff --git a/spec/guard-spec/circuit-creation-entry-guard-selection-1000-foot.md b/spec/guard-spec/circuit-creation-entry-guard-selection-1000-foot.md index bbebb04..b31609f 100644 --- a/spec/guard-spec/circuit-creation-entry-guard-selection-1000-foot.md +++ b/spec/guard-spec/circuit-creation-entry-guard-selection-1000-foot.md @@ -6,7 +6,7 @@ A circuit in Tor is a path through the network connecting a client to its destination. At a high-level, a three-hop exit circuit will look like this: -Client <-> Entry Guard <-> Middle Node <-> Exit Node <-> Destination +Client \<-> Entry Guard \<-> Middle Node \<-> Exit Node \<-> Destination Entry guards are the only nodes which a client will connect to directly. Exit relays are the nodes by which traffic exits the diff --git a/spec/guard-spec/still-non-addressed-issues-sectiontodo.md b/spec/guard-spec/still-non-addressed-issues-sectiontodo.md index 89e60ba..38b0be4 100644 --- a/spec/guard-spec/still-non-addressed-issues-sectiontodo.md +++ b/spec/guard-spec/still-non-addressed-issues-sectiontodo.md @@ -1,6 +1,6 @@ <a id="guard-spec.txt-TODO"></a> -# Still non-addressed issues [Section:TODO] +# Still non-addressed issues \[Section:TODO\] Simulate to answer: Will this work in a dystopic world? |