Tor 路由选择规范

为了翻译速度,个别翻译可能与原词汇含义相佐,请对照原文进行理解。如果需要实现相关协议,请查看原文,本翻译仅适用于简单了解协议。

原文链接:

当前的翻译版本提交 Hash: 9c86f54ba07355a968f982aed295e8b6597b4b89,对应 Github链接

1 常规操作

查看原文

1. General operation

Tor begins building circuits as soon as it has enough directory information to do so (see section 5 of dir-spec.txt). Some circuits are built preemptively because we expect to need them later (for user traffic), and some are built because of immediate need (for user traffic that no current circuit can handle, for testing the network or our reachability, and so on).

[Newer versions of Tor (0.2.6.2-alpha and later):
If the consensus contains Exits (the typical case), Tor will build both exit and internal circuits. When bootstrap completes, Tor will be ready to handle an application requesting an exit circuit to services like the World Wide Web.
If the consensus does not contain Exits, Tor will only build internal circuits. In this case, earlier statuses will have included "internal" as indicated above. When bootstrap completes, Tor will be ready to handle an application requesting an internal circuit to hidden services at ".onion" addresses.
If a future consensus contains Exits, exit circuits may become available.]

When a client application creates a new stream (by opening a SOCKS connection or launching a resolve request), we attach it to an appropriate open circuit if one exists, or wait if an appropriate circuit is in-progress. We launch a new circuit only if no current circuit can handle the request. We rotate circuits over time to avoid some profiling attacks.

To build a circuit, we choose all the nodes we want to use, and then construct the circuit. Sometimes, when we want a circuit that ends at a given hop, and we have an appropriate unused circuit, we "cannibalize" the existing circuit and extend it to the new terminus.

These processes are described in more detail below.

This document describes Tor's automatic path selection logic only; path selection can be overridden by a controller (with the EXTENDCIRCUIT and ATTACHSTREAM commands). Paths constructed through these means may violate some constraints given below.

Tor 一旦有了足够的目录信息,就会开始构建电路,参见 dir-spec.txt 第 5 节

有些电路时预先构建的,将会在稍后使用,用于用户流量。而有些则是迫切需要的,用于测试网络合可达性。

在 0.2.6.2-alpha 以后版本,如果共识包含出口(Exits)(典型状况),Tor 将会建立出口合内部电路。当启动完成后,Tor 将会准备处理一个请求退出电路的应用程序,该电路用于 Web 服务。
如果共识不包括出口,Tor 将只建立内部电路。这种情况下,之前的状态将会包含上述的“内部”。启动完成后,Tor 将准备处理一个应用程序,用于请求内部电路连接到隐藏服务的洋葱地址
如果未来共识中包括出口(Exits),则可能会出现退出电路

当客户端创建一个新的流(通过一个 SOCKS 连接建立或启动一个解析请求),将会将这个流附加到一个适当的闲置电路中(如果存在)或一个适当的正在工作中的电路
只有没有电路可处理请求时,才会启动一个新的电路。随着时间的退役,将会对电路进行旋转,避免一些分析攻击

为了构建一个电路,我们选择所有我们想要使用的节点,然后构建电路。有时,当我们需要一个包含特殊结束节点的电路,并且存在一个暂未使用的电路,那么可以将这个电路“分流”并扩展到新的出口

下面将更详细地描述这些过程,本文档仅仅描述了 Tor 自动路由选择的逻辑。控制器可能会使用EXTENDCIRCUITATTACHSTREAM手动路由选择,这种自定义的行为可能违反下面路由选择的约束。

1.1 术语

查看原文

1.1. Terminology

A "path" is an ordered sequence of nodes, not yet built as a circuit.

A "clean" circuit is one that has not yet been used for any traffic.

A "fast" or "stable" or "valid" node is one that has the 'Fast' or 'Stable' or 'Valid' flag set respectively, based on our current directory information. A "fast" or "stable" circuit is one consisting only of "fast" or "stable" nodes.

In an "exit" circuit, the final node is chosen based on waiting stream requests if any, and in any case it avoids nodes with exit policy of "reject :". An "internal" circuit, on the other hand, is one where the final node is chosen just like a middle node (ignoring its exit policy).

A "request" is a client-side stream or DNS resolve that needs to be served by a circuit.

A "pending" circuit is one that we have started to build, but which has not yet completed.

A circuit or path "supports" a request if it is okay to use the circuit/path to fulfill the request, according to the rules given below.
A circuit or path "might support" a request if some aspect of the request is unknown (usually its target IP), but we believe the path probably supports the request according to the rules given below.

路径
一个节点的有序序列
干净的路径
尚未被用于任何流量的电路
快速、稳定、合法节点
目录服务器给当前节点设置了FastStableValid标志
快速、稳定、合法的电路
只有快速、稳定、合法节点构成的电路

在退出电路中,如果需要等待流的请求,则可以根据实际请求的地址来选择出口节点。在任何情况下,出口节点都不会使用reject *:*的节点
而在内部电路中,出口节点选择策略和中间节点相同

请求
需要电路提供服务的客户端流或 DNS 解析
待定(pending)电路
已经开始创建,但尚未创建完成的电路
支持
可以使用电路来满足请求,则称为该电路支持请求
对于未知 IP 的请求,电路“可能支持”请求

1.2 中继带宽

查看原文

1.1. A relay's bandwidth

Old versions of Tor did not report bandwidths in network status documents, so clients had to learn them from the routers' advertised relay descriptors.

For versions of Tor prior to 0.2.1.17-rc, everywhere below where we refer to a relay's "bandwidth", we mean its clipped advertised bandwidth, computed by taking the smaller of the 'rate' and 'observed' arguments to the "bandwidth" element in the relay's descriptor. If a router's advertised bandwidth is greater than MAX_BELIEVABLE_BANDWIDTH (currently 10 MB/s), we clipped to that value.

For more recent versions of Tor, we take the bandwidth value declared in the consensus, and fall back to the clipped advertised bandwidth only if the consensus does not have bandwidths listed.

旧版本的 Tor 在网络状态文档中并未报告带宽,客户需要从中继公布的描述符中获取带宽信息

在 0.2.1.17-rc 之前的 Tor 版本,在提及带宽地方,实际上都是描述的都是公布的带宽,取节点声称的带宽与实际观察到带宽中的较小值。如果节点公布的带宽大于MAX_BELIEVABLE_BANDWIDTH(目前该值为 10 MB/s10 \space \text{MB/s}),则其带宽将会被视为MAX_BELIEVABLE_BANDWIDTH

在近版本的 Tor 中,优先使用共识中声明的带宽值。当共识中无带宽,则会将其压缩至公开带宽。

该部分标题序号错了,应该是 1.2 但是原文是 1.1,可以水一发 PR

2 构建电路

2.1 构建电路的时机

2.1.0 只在拥有足够信息时构建

查看原文

2. Building circuits

2.1. When we build

2.1.0. We don't build circuits until we have enough directory info

There's a class of possible attacks where our directory servers only give us information about the relays that they would like us to use. To prevent this attack, we don't build multi-hop circuits for real traffic (like those in 2.1.1, 2.1.2, 2.1.4 below) until we have enough directory information to be reasonably confident this attack isn't being done to us.

Here, "enough" directory information is defined as:

  • Having a consensus that's been valid at some point in the last REASONABLY_LIVE_TIME interval (24 hourts).
  • Having enough descriptors that we could build at least some fraction F of all bandwidth-weighted paths, without taking ExitNodes/EntryNodes/etc into account. (F is set by the PathsNeededToBuildCircuits option, defaulting to the 'min_paths_for_circs_pct' consensus parameter, with a final default value of 60%.)
  • Having enough descriptors that we could build at least some fraction F of all bandwidth-weighted paths, while taking ExitNodes/EntryNodes/etc into account. (F is as above.)
  • Having a descriptor for every one of the first NUM_GUARDS_TO_USE guards among our primary guards. (see guard-spec.txt)

有一种可行的攻击手段是目录服务器只给客户端一部分节点的信息,从而强制客户端选择一部分电路。

为了防止这种攻击,在构造多跳电路中(下面 2.1.1、2.1.2、2.1.4 描述的电路),只有客户端拥有足够的目录信息确保不存在上面提到的攻击时,才会构建电路

这里,“足够”的定义为:

  • 在最后一个合理的时间间隔REASONABLY_LIVE_TIME2424 小时)内达成共识
  • 拥有足够的描述符,使得我们在不考虑入口节点和出口节点的前提下,至少可以构建出 FF 的带宽加权路径(FFPathsNeededToBuildCircuits设置,默认为min_paths_for_circs_pct的数值,为 60%60\%
  • 获取到NUM_GUARDS_TO_USE个入口守卫描述符

2.1.1 客户端预构建

查看原文

2.1.1. Clients build circuits preemptively

When running as a client, Tor tries to maintain at least a certain number of clean circuits, so that new streams can be handled quickly. To increase the likelihood of success, Tor tries to predict what circuits will be useful by choosing from among nodes that support the ports we have used in the recent past (by default one hour). Specifically, on startup Tor tries to maintain one clean fast exit circuit that allows connections to port 80, and at least two fast clean stable internal circuits in case we get a resolve request or hidden service request (at least three if we _run_ a hidden service).

After that, Tor will adapt the circuits that it preemptively builds based on the requests it sees from the user: it tries to have two fast clean exit circuits available for every port seen within the past hour (each circuit can be adequate for many predicted ports -- it doesn't need two separate circuits for each port), and it tries to have the above internal circuits available if we've seen resolves or hidden service activity within the past hour. If there are 12 or more clean circuits open, it doesn't open more even if it has more predictions.

Only stable circuits can "cover" a port that is listed in the LongLivedPorts config option. Similarly, hidden service requests to ports listed in LongLivedPorts make us create stable internal circuits.

Note that if there are no requests from the user for an hour, Tor will predict no use and build no preemptive circuits.

The Tor client SHOULD NOT store its list of predicted requests to a persistent medium.

在作为客户端运行时,Tor 保持至少一定数量的电路,以便能够快速处理新的流。为了增加可能性,Tor 尝试选择我们最近使用(默认为一个小时)的端口来预测哪些电路是可用的。在启动时,Tor 将尝试维护一个 80 端口的干净、快速、出口电路;至少两个干净、快速、稳定的内部电路,以便于请求隐藏服务(如果还需要部署一个隐藏服务,则需要至少三个)

之后,Tor 将在预构建电路的基础上调整电路,试图针对每个近一个小时内使用过的端口保持两条干净、快速、出口电路。由于每个出口节点可能可用于多个端口,因此实际上并不需要维护特别多的电路。
如果在过去的一小时内还进行了隐藏服务的解析和连接,那么还将保持上述内部电路的可用性

整个电路中,最多只会有 1212 个干净的电路,即使预测需要更多也不会建立更多的电路。

只有稳定的电路,可以“覆盖”LongLivedPorts配置的选项。同样,LongLivedPorts中列出的对应端口的隐藏服务请求需要创建稳定的内部电路。

如果用户在一个小时内没有请求,那么 Tor 预测不会使用电路,因此不会建立预构建电路。

Tor 不应该将其预测的列表存储到可持久化的介质中。

如果是普通客户端,大概要建立 5 条左右的电路备用

2.1.2 客户端按需构建

查看原文

2.1.2. Clients build circuits on demand

Additionally, when a client request exists that no circuit (built or pending) might support, we create a new circuit to support the request. For exit connections, we pick an exit node that will handle the most pending requests (choosing arbitrarily among ties), launch a circuit to end there, and repeat until every unattached request might be supported by a pending or built circuit. For internal circuits, we pick an arbitrary acceptable path, repeating as needed.

In some cases we can reuse an already established circuit if it's clean; see Section 2.3 (cannibalizing circuits) for details.

当客户端的请求没有电路支持,将会创建一个新的电路来支持该请求。对于退出连接,将会建立一个出口为到任意一个将处理最多挂起请求的出口节点(在连接的节点中随机选择)的电路,重复知道所有未附加到电路的请求都拥有一个支持的可用电路(或正在创建的电路)

对于内部电路,将会选择任何可接受的路径,并根据需要进行重复

如果电路是干净的,可能会在某些特定情况下重用他们(详情可见2.3 节)

2.1.3 带宽及可达性测试电路

查看原文

2.1.3. Relays build circuits for testing reachability and bandwidth

Tor relays test reachability of their ORPort once they have successfully built a circuit (on startup and whenever their IP address changes). They build an ordinary fast internal circuit with themselves as the last hop. As soon as any testing circuit succeeds, the Tor relay decides it's reachable and is willing to publish a descriptor.

We launch multiple testing circuits (one at a time), until we have NUM_PARALLEL_TESTING_CIRC (4) such circuits open. Then we do a "bandwidth test" by sending a certain number of relay drop cells down each circuit: BandwidthRate * 10 / CELL_NETWORK_SIZE total cells divided across the four circuits, but never more than CIRCWINDOW_START (1000) cells total. This exercises both outgoing and incoming bandwidth, and helps to jumpstart the observed bandwidth (see dir-spec.txt).

Tor relays also test reachability of their DirPort once they have established a circuit, but they use an ordinary exit circuit for this purpose.

中继节点需要构建测试可达性和带宽的电路。每当中继节点成功建立了一个电路(启动时或 IP 改变时),需要进行指令的可达性测试。它们需要使用自己作为最后一条构建一条快速内部电路。一旦电路测试成功,则中继可以认为自己是可到达的,并且将会发布一个描述符。

我们将会部署多个测试电路(每次一条),直到有 NUM_PARALLE_TESTING_CIRC(4)条电路开启。接下来,将会进行带宽测试。首先需要向每条电路发送确定数量的数据。总计BandwidthRate×10/CELL_NETWORK_SIZE\text{BandwidthRate} \times 10 / \text{CELL\_NETWORK\_SIZE} (不超过CIRCWINDOW_START(1000)条数据)数据被分到四个电路中。这可以同时测试入站带宽和出站带宽,并快速将带宽提升到观测到的水平

一旦电路建立,Tor 中继也会测试其 DirPort 可达性,但将会使用普通的出口电路进行测试

2.1.4 隐藏服务电路

见第 4 节

2.1.5 失效电路速率限制

查看原文

2.1.5. Rate limiting of failed circuits

If we fail to build a circuit N times in a X second period (see Section 2.3 for how this works), we stop building circuits until the X seconds have elapsed.
XXXX

如果在 XX 秒构建一条电路失败 NN 次(具体见 2.3),那么将会停止构建工作,直到 XX 秒后

原规范这里存在未完成的内容

2.1.6 电路拆除时机

原规范这里存在未完成的内容

2.2 路径选择和约束

查看原文

2.2. Path selection and constraints

We choose the path for each new circuit before we build it. We choose the exit node first, followed by the other nodes in the circuit. All paths we generate obey the following constraints:

  • We do not choose the same router twice for the same path.
  • We do not choose any router in the same family as another in the same path. (Two routers are in the same family if each one lists the other in the "family" entries of its descriptor.)
  • We do not choose more than one router in a given /16 subnet (unless EnforceDistinctSubnets is 0).
  • We don't choose any non-running or non-valid router unless we have been configured to do so. By default, we are configured to allow non-valid routers in "middle" and "rendezvous" positions.
  • If we're using Guard nodes, the first node must be a Guard (see 5 below)
  • XXXX Choosing the length

For "fast" circuits, we only choose nodes with the Fast flag. For non-"fast" circuits, all nodes are eligible.
For all circuits, we weight node selection according to router bandwidth.

We also weight the bandwidth of Exit and Guard flagged nodes depending on the fraction of total bandwidth that they make up and depending upon the position they are being selected for.

These weights are published in the consensus, and are computed as described in Section "Computing Bandwidth Weights" of dir-spec.txt. They are:

Wgg - Weight for Guard-flagged nodes in the guard position
Wgm - Weight for non-flagged nodes in the guard Position
Wgd - Weight for Guard+Exit-flagged nodes in the guard Position

Wmg - Weight for Guard-flagged nodes in the middle Position
Wmm - Weight for non-flagged nodes in the middle Position
Wme - Weight for Exit-flagged nodes in the middle Position
Wmd - Weight for Guard+Exit flagged nodes in the middle Position

Weg - Weight for Guard flagged nodes in the exit Position
Wem - Weight for non-flagged nodes in the exit Position
Wee - Weight for Exit-flagged nodes in the exit Position
Wed - Weight for Guard+Exit-flagged nodes in the exit Position

Wgb - Weight for BEGIN_DIR-supporting Guard-flagged nodes
Wmb - Weight for BEGIN_DIR-supporting non-flagged nodes
Web - Weight for BEGIN_DIR-supporting Exit-flagged nodes
Wdb - Weight for BEGIN_DIR-supporting Guard+Exit-flagged nodes

Wbg - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests
Wbm - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests
Wbe - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests
Wbd - Weight for Guard+Exit-flagged nodes for BEGIN_DIR requests

If any of those weights is malformed or not present in a consensus, clients proceed with the regular path selection algorithm setting the weights to the default value of 10000.

Additionally, we may be building circuits with one or more requests in mind. Each kind of request puts certain constraints on paths:

  • All service-side introduction circuits and all rendezvous paths should be Stable.
  • All connection requests for connections that we think will need to stay open a long time require Stable circuits. Currently, Tor decides this by examining the request's target port, and comparing it to a list of "long-lived" ports. (Default: 21, 22, 706, 1863, 5050, 5190, 5222, 5223, 6667, 6697, 8300.)
  • DNS resolves require an exit node whose exit policy is not equivalent to "reject :".
  • Reverse DNS resolves require a version of Tor with advertised eventdns support (available in Tor 0.1.2.1-alpha-dev and later).
  • All connection reqUuests require an exit node whose exit policy supports their target address and port (if known), or which "might support it" (if the address isn't known). See 2.2.1.
  • Rules for Fast? XXXXX

构建电路首先需要为每一个电路选择路径。首先选择出口节点,而后选择其他节点,且每条路径遵循以下条件:

  • 同一路径不会多次选择同一节点
  • 同一路径不会选择在同一个家族内的多个节点(如果两台路由器在描述中的family条目里列出了另一台,则说明处于同一家族)
  • 同一路径不会选择同一个 /16 子网内的多个节点(除非设置EnforceDistinctSubnets 0
  • 不会选择未运行或无效的节点(默认情况下,允许在中间路由和会合点使用未验证的服务器)
  • 如果使用入口守卫,则入口节点必须为守卫节点
  • 原规范这里存在未完成的内容

对于快速电路,我们只会选择带有Fast的节点,而非快速电路则可以选择其他的节点

在所有的电路中,将会根据带宽计算节点的权重

实际使用中,还会根据ExitGuard标志的节点占总带宽的比例以及它们被选择的位置进行加权。权重在共识文件中公布,并在 diro-spec.txt 中计算带宽权重部分进行计算

  • Wgg: 带有Guard标志的节点处于入口守卫位置的权重
  • Wgm: 无标志的节点位于入口守卫位置的权重
  • Wgd: 带有GuardExit标志的节点处于入口守卫位置的权重
  • Wmg: 带有Guard标志的节点在中间节点位置的权重
  • Wmm: 无标志的节点位于中间节点位置的权重
  • Wme: 带有Exit标志的节点处于中间节点位置的权重
  • Wmd: 带有GuardExit标志的节点处于中间节点位置的权重
  • Weg: 带有Guard标志的节点在出口节点位置的权重
  • Wem: 无标志的节点位于出口节点位置的权重
  • Wee: 带有Exit标志的节点处于出口节点位置的权重
  • Wed: 带有GuardExit标志的节点处于出口节点位置的权重
  • Wgb: 带有Guard标志且支持BEGIN_DIR的节点权重
  • Wmb: 无标志且支持BEGIN_DIR的权重
  • Web: 带有Exit标志且支持BEGIN_DIR的权重
  • Wdb: 带有GuardExit标志且支持BEGIN_DIR的权重
  • Wbg: 带有Guard标志用于BEGIN_DIR请求的权重
  • Wbm: 无标志用于`BEGIN_DI请求的权重
  • Wbe: 带有Exit标志用于`BEGIN_DI请求的权重
  • Wbd: 带有GuardExit标志用于`BEGIN_DI请求的权重

严重怀疑这部分原规范存在错误

如果任意一种权重未达成共识,则继续执行默认算法设置。权重默认为 1000010000
此外,可能会同时构建包含多个请求的电路,每个请求都可能会对电路添加一定的约束:

  • 所有服务端的介绍电路以及会合电路应该是稳定的电路
  • 所有被认为需要长时间连接的电路需要稳定的电路(目前,Tor 根据long-lived设置的端口号来进行判断,默认为:21、22、706、1863、5050、5190、5222、5223、6667、6697、7300)
  • DNS 解析请求要求电路出口节点不应该是reject *:*
  • 反向 DNS 解析支持enevtdns事件的 Tor(0.1.2.1-alpha-dev 以后版本)
  • 所有连接都需要一个具有支持(或可能支持)目标地址和端口退出策略的出口节点
  • 快速规则xxxx 原规范这里存在未完成的内容

2.2.1 选择出口节点

查看原文

2.2.1. Choosing an exit

If we know what IP address we want to connect to or resolve, we can trivially tell whether a given router will support it by simulating its declared exit policy.

Because we often connect to addresses of the form hostname:port, we do not always know the target IP address when we select an exit node. In these cases, we need to pick an exit node that "might support" connections to a given address port with an unknown address. An exit node "might support" such a connection if any clause that accepts any connections to that port precedes all clauses (if any) that reject all connections to that port.

Unless requested to do so by the user, we never choose an exit node flagged as "BadExit" by more than half of the authorities who advertise themselves as listing bad exits.

如果要连接或解析的地址已知,则需要根据节点的退出策略来判断是否支持。由于很多情况下,地址以hostname:port的形式给出,而非ip:port,因此无法直接判断是否支持,这时需要猜测一个可能支持的出口节点。可能支持指允许所有 IP 和端口的节点(如果有的话)

除非用户要求,否则不会选择一个被半数以上权威目录服务器标记为BadExit的节点作为出口节点。

2.2.2 用户配置

查看原文

2.2.2. User configuration

Users can alter the default behavior for path selection with configuration options.

  • If "ExitNodes" is provided, then every request requires an exit node on the ExitNodes list. (If a request is supported by no nodes on that list, and StrictExitNodes is false, then Tor treats that request as if ExitNodes were not provided.)
  • "EntryNodes" and "StrictEntryNodes" behave analogously.
  • If a user tries to connect to or resolve a hostname of the form <target>.<servername>.exit, the request is rewritten to a request for <target>, and the request is only supported by the exit whose nickname or fingerprint is <servername>.
  • When set, "HSLayer2Nodes" and "HSLayer3Nodes" relax Tor's path restrictions to allow nodes in the same /16 and node family to reappear in the path. They also allow the guard node to be chosen as the RP, IP, and HSDIR, and as the hop before those positions.

用户可以通过修改配置来更改路径选择的默认行为

  • 如果配置了ExitNodes,则每个请求都将会使用ExitNodes中的退出节点(如果所有退出节点都不支持请求,且StrictExitNodesfalse,那么该配置无效)
  • EntryNodesStrictEntryNodes的行为与上述类似
  • 如果用户试图连接或解析<target>.<servername>.exit的主机名,那么将会将请求重写到<target>的请求,并且请求使用昵称或指纹为<servername>的节点为出口节点
  • 当设置HSLayer2NodesHSLayer3Nodes后,将会放宽 Tor 路径选择的限制,允许同一个 /16 子网或家族的节点出现在同一电路。同时还允许选择入口守卫节点作为 RP、IP、HSDIR 以及这些位置之前的节点

2.3 重用电路

查看原文

2.3. Cannibalizing circuits

If we need a circuit and have a clean one already established, in some cases we can adapt the clean circuit for our new purpose. Specifically,

For hidden service interactions, we can "cannibalize" a clean internal circuit if one is available, so we don't need to build those circuits from scratch on demand.

We can also cannibalize clean circuits when the client asks to exit at a given node -- either via the ".exit" notation or because the destination is running at the same location as an exit node.

在需要建立电路时,如果已有一个干净的电路,在某些情况下可以调整该电路以适应新的需求。
对于隐藏服务的交互,如果有一个干净的内部电路可用,那么可以拆掉该电路,从而不必从头开始构建电路。

当客户端请求在给定节点退出时或请求地址相同时,也可以重建已有的电路

2.4 放弃构建电路的时机

查看原文

2.4. Learning when to give up ("timeout") on circuit construction

Since version 0.2.2.8-alpha, Tor attempts to learn when to give up on circuits based on network conditions.

从 0.2.2.8-alpha 后,Tor 尝试根据网络条件来判断合适放弃电路构建

2.4.1 分布选择和参数估计

查看原文

2.4.1. Distribution choice and parameter estimation

Based on studies of build times, we found that the distribution of circuit build times appears to be a Frechet distribution. However, estimators and quantile functions of the Frechet distribution are difficult to work with and slow to converge. So instead, since we are only interested in the accuracy of the tail, we approximate the tail of the distribution with a Pareto curve.

We calculate the parameters for a Pareto distribution fitting the data using the estimators in equation 4 from: http://portal.acm.org/citation.cfm?id=1647962.1648139

This is:
alpham=s/(ln(U(X)/Xmn))alpha_m = s/(ln(U(X)/Xm^n))
where s is the total number of completed circuits we have seen, and
U(X)=xmaxuProdsxiU(X) = x_max^u * Prod_s{x_i}
with xix_i as our ii-th completed circuit time, xmaxx_{max} as the longest completed circuit build time we have yet observed, uu as the number of unobserved timeouts that have no exact value recorded, and nn as u+su+s, the total number of circuits that either timeout or complete.

Using log laws, we compute this as the sum of logs to avoid overflow and ln(1.0+epsilon) precision issues:
alpham=s/(uln(xmax)+Sumsln(xi)nln(Xm))alpha_m = s/(u*ln(x_max) + Sum_s{ln(x_i)} - n*ln(Xm))

This estimator is closely related to the parameters present in: http://en.wikipedia.org/wiki/Pareto_distribution#Parameter_estimation except they are adjusted to handle the fact that our samples are right-censored at the timeout cutoff.

Additionally, because this is not a true Pareto distribution, we alter how XmXm is computed. The XmXm parameter is computed as the midpoint of the most frequently occurring 50ms histogram bin, until the point where 10001000 circuits are recorded. After this point, the weighted average of the top 'cbtnummodes' (default: 3) midpoint modes is used as XmXm. All times below this value are counted as having the midpoint value of this weighted average bin.

The timeout itself is calculated by using the Pareto Quantile function (the inverted CDF) to give us the value on the CDF such that 80%80\% of the mass of the distribution is below the timeout value.

Thus, we expect that the Tor client will accept the fastest 80%80\% of the total number of paths on the network.

根据对构建时间的研究,可以发现电路构建时间符合 Frechet 分布。然而,给出的 Frechet 分布的分位点函数无法拟合,收敛较为缓慢。由于在这里,我们只需要讨论尾部的精度,因此可以近似使用 Pareto 分布的尾部。通过 http://portal.acm.org/citation.cfm?id=1647962.1648139 公式 4 计算 Pareto 分布的参数:
alpham=slnU(X)Xmnalpha_m = \frac{s}{ln\frac{U(X)}{Xm^n}}
其中,ss 是所有已完成的电路,且
U(X)=xmaxu×ProdsxiU(X) = x_{max}^u \times Prod_s{x_i}
xix_i 是第 ii 个已完成的电路所需的时间,xmaxx_{max} 是最长的电路构建时间,uu 是无法观测到的构建失败的数目,nnu+su+s 分别是所有电路中超时和完成的数目

使用 loglog 定律,来确保计算精度,避免溢出:
alpham=su×lnxmax+Sumxlnxin×lnXmalpha_m=\frac{s}{u\times ln{x_{max} + Sum_x{ln{x_i}}- n \times ln{Xm}}}
http://en.wikipedia.org/wiki/Pareto_distribution#Parameter_estimation 说明该估计值和参数密切相关,在这里被调整为处理样本超时的问题

另外,这并不是真正的 Paredo 分布,因为这里修改了 XmXm 的计算方式,XmXm 参数是出现次数最多 50ms50ms 直方图的中点,直到记录到 10001000 条电路的点。再次之后,使用cbtnummodes重点模式的加权平均值作为XmXm中点,所有低于这个值的时间被计算为这个加权平均的中点值

超时本身是通过使用 Pareto 分位点函数(反向 CDF)计算,从而提供 CDF 的值,使得分布质量 80%80\% 低于超时值

因此,期望 Tor 客户端可以接收网络路径总数中最快的 80%80\%

简单翻译,错误概率较大,仅供参考

2.4.2 需要记录多少数据

查看原文

2.4.2. How much data to record

From our observations, the minimum number of circuit build times for a reasonable fit appears to be on the order of 100. However, to keep a good fit over the long term, we store 1000 most recent circuit build times in a circular array.

The Tor client should build test circuits at a rate of one per minute up until 100 circuits are built. This allows a fresh Tor to have a CircuitBuildTimeout estimated within 1.5 hours after install, upgrade, or network change (see below).

Timeouts are stored on disk in a histogram of 50ms bin width, the same width used to calculate the Xm value above. This histogram must be shuffled after being read from disk, to preserve a proper expiration of old values after restart.

通过观察来看,电路构建的时间最少在 100100。为了保持良好的适应性,需要将 10001000 的最新的电路存储在环形数组中,客户端应该以每分钟一个的速度创建测试电路,直到构建 100100 个电路,这允许新运行的 Tor 将CircuitBuildTimeout设置为安装、升级、网络更改后的 1.5 小时

超过数据将以 50ms50ms 的直方图存储在磁盘中,宽度与 XmXm 相同。从磁盘读取后,需要重新对直方图进行洗牌操作,从而在重启后确保过期值得剔除

2.4.3 如何记录数据

查看原文

2.4.3. How to record timeouts

Circuits that pass the timeout threshold should be allowed to continue building until a time corresponding to the point 'cbtclosequantile' (default 95) on the Pareto curve, or 60 seconds, whichever is greater.

The actual completion times for these circuits should be recorded. Implementations should completely abandon a circuit and record a value as an 'unknown' timeout if the total build time exceeds this threshold.

The reason for this is that right-censored pareto estimators begin to lose their accuracy if more than approximately 5% of the values are censored.
Since we wish to set the cutoff at 20%, we must allow circuits to continue building past this cutoff point up to the 95th percentile.

应该允许超时得检录仅需构建,直到对应 Pareto 曲线的 cbtclosequantile(默认为 9595)的时间,或者是 60s60s(取两者中的较大值)

这些电路的实际完成时间需要被记录下来,如果总构建时间超过这个阈值,那么应该放弃电路并记录未知的超时值

这样做的原因是,如果超过 5%5\% 的值被审查, Pareto 估计值会失去准确性。这里将截至值设置为 20%20\%,必须允许电路继续建造超过这个截止值得 95%95\%

2.4.4 网络变化检测

查看原文

2.4.4. Detecting Changing Network Conditions

We attempt to detect both network connectivity loss and drastic changes in the timeout characteristics.

We assume that we've had network connectivity loss if a circuit times out and we've received no cells or TLS handshakes since that circuit began. We then temporarily stop counting timeouts until network activity resumes.

To detect changing network conditions, we keep a history of the timeout or non-timeout status of the past 20 circuits that successfully completed at least one hop. If more than 90% of these circuits timeout, we discard all buildtimes history, reset the timeout to 60, and then begin recomputing the timeout.

If the timeout was already 60 or higher, we double the timeout.

需要尝试检测网络连接丢失或超时。如果电路在超时时间内未收到任何数据或 TLS 握手响应,,那么认为网络连接丢失。而后暂停计算超时,直至网络活动恢复。

为了保证可以检测不断变化的网络条件,需要保存过去 2020 跳至少包含一跳得电路超时或非超时状态信息。如果超过 90%90\% 得电路超时,那么将丢弃所有构建历史记录,将超时重建为 6060 重新开始计算。如果超时已经达到 6060,那么超时时间将会加倍

2.4.5 控制行为得共识参数

查看原文

2.4.5. Consensus parameters governing behavior

Clients that implement circuit build timeout learning should obey the following consensus parameters that govern behavior, in order to allow us to handle bugs or other emergent behaviors due client circuit construction. If these parameters are not present the consensus, the listed default values should be used instead.

  • cbtdisabled

    • Default: 0
    • Min: 0
    • Max: 1
    • Effect: If 1, all CircuitBuildTime learning code should be disabled and history should be discarded. For use in emergency situations only.
  • cbtnummodes

    • Default: 3
    • Min: 1
    • Max: 20
    • Effect: This value governs how many modes to use in the weighted average calculation of Pareto parameter Xm. A value of 3 introduces some bias (2-5% of CDF) under ideal conditions, but allows for better performance in the event that a client chooses guard nodes of radically different performance characteristics.
  • cbtrecentcount

    • Default: 20
    • Min: 3
    • Max: 1000
    • Effect: This is the number of circuit build times to keep track of for the following option.
  • cbtmaxtimeouts

    • Default: 18
    • Min: 3
    • Max: 10000
    • Effect: When this many timeouts happen in the last 'cbtrecentcount' circuit attempts, the client should discard all of its history and begin learning a fresh timeout value.
  • cbtmincircs

    • Default: 100
    • Min: 1
    • Max: 10000
    • Effect: This is the minimum number of circuits to build before computing a timeout.
  • cbtquantile

    • Default: 80
    • Min: 10
    • Max: 99
    • Effect: This is the position on the quantile curve to use to set the timeout value. It is a percent (10-99).
  • cbtclosequantile

    • Default: 95
    • Min: Value of cbtquantile parameter
    • Max: 99
    • Effect: This is the position on the quantile curve to use to set the timeout value to use to actually close circuits. It is a percent (0-99).
  • cbttestfreq

    • Default: 60
    • Min: 1
    • Max: 2147483647 (INT32_MAX)
    • Effect: Describes how often in seconds to build a test circuit to gather timeout values. Only applies if less than 'cbtmincircs' have been recorded.
  • cbtmintimeout

    • Default: 2000
    • Min: 500
    • Max: 2147483647 (INT32_MAX)
    • Effect: This is the minimum allowed timeout value in milliseconds. The minimum is to prevent rounding to 0 (we only check once per second).
  • cbtinitialtimeout

    • Default: 60000
    • Min: Value of cbtmintimeout
    • Max: 2147483647 (INT32_MAX)
    • Effect: This is the timeout value to use before computing a timeout, in milliseconds.
  • cbtlearntimeout

    • Default: 180
    • Min: 10
    • Max: 60000
    • Effect: This is how long idle circuits will be kept open while cbt is learning a new timeout value.
  • cbtmaxopencircs

    • Default: 10
    • Min: 0
    • Max: 14
    • Effect: This is the maximum number of circuits that can be open at at the same time during the circuit build time learning phase.

客户端在实现自适应电路构建超时时需要村寻以下共识参数,以便处理错误或其他突发行为。如果参数不一致,应该使用默认值

名称 默认值 最小值 最大值 影响
cbtdisabled 0 0 1 所有电路构造时间超时自适应应该停止,历史将被丢弃。仅在紧急情况下使用
cbtnummodes 3 1 20 该值决定于 Pareto 参数得 XmXm 加权平均计算得模式数。当值为 33 时,在理想状态下会引入偏差(CDF 的 25%2 \sim 5\%),但当客户端选择性能特征完全不同的守护节点时,可能可以获得更好的性能
cbtrecentcount 20 3 1000 电路建造时间的数量,以保持跟踪以下后续的选项
cbtmaxtimeouts 18 3 10000 当 cbtrecentcount 最后阶段发生很多超时,客户端需要放弃所有历史,重新适应超时
cbtmincircs 100 1 10000 计算超时前的最小电路数量
cbtquantile 80 10 99 分位点函数曲线上设置超时值的位置,是一个 1099%10 \sim 99 \% 的百分比
cbtclosequantile 95 cbtquantile 参数的值 99 分位点曲线上设置超时值实际关闭电路的位置,是一个 099%0 \sim 99 \% 的百分比
cbttestfreq 60 1 INT32_MAX 描述构建测试电路以收集超时值的频率(单位:秒),仅用于记录数小于 cbtmincircs 的情况
cbtmintimeout 2000 500 INT32_MAX 允许的最小超时值(单位:毫秒),为了防止四舍五入到 00,每秒只会判断一次
cbtinitialtimeout 60000 INT32_MAX 计算超时前使用的超时值(单位:毫秒)
cbtlearntimeout 180 10 60000 当 cbt 学习一个新的超时值时,空闲电路保持打开的时间
cbtmaxopencircs 10 0 14 自适应期间电路同时开启的最大数目

2.5 错误处理

查看原文

2.5. Handling failure

If an attempt to extend a circuit fails (either because the first create failed or a subsequent extend failed) then the circuit is torn down and is no longer pending. (XXXX really?) Requests that might have been supported by the pending circuit thus become unsupported, and a new circuit needs to be constructed.

If a stream "begin" attempt fails with an EXITPOLICY error, we decide that the exit node's exit policy is not correctly advertised, so we treat the exit node as if it were a non-exit until we retrieve a fresh descriptor for it.

Excessive amounts of either type of failure can indicate an attack on anonymity. See section 7 for how excessive failure is handled.

如果扩展电路失败(创建失败或扩展失败),电路将被拆除,不再使用。相应的请求需要构建新的电路

如果流在“begin”阶段失败并出现EXITPOLICY错误,则我们认为出口节点的退出策略没有被正确声明,因此在该节点检索到新的描述符之前,不会再将其视为退出节点。

任何一种故障数量过多都可能是一种针对匿名性的攻击,具体可见第 7 节

3 将流附加于电路

查看原文

3. Attaching streams to circuits

When a circuit that might support a request is built, Tor tries to attach the request's stream to the circuit and sends a BEGIN, BEGIN_DIR, or RESOLVE relay cell as appropriate. If the request completes unsuccessfully, Tor considers the reason given in the CLOSE relay cell. [XXX yes, and?]

After a request has remained unattached for SocksTimeout (2 minutes by default), Tor abandons the attempt and signals an error to the client as appropriate (e.g., by closing the SOCKS connection).

XXX Timeouts and when Tor auto-retries.

  • What stream-end-reasons are appropriate for retrying.

If no reply to BEGIN/RESOLVE, then the stream will timeout and fail.

当一个支持请求的电路被建立,Tor 将会尝试将流附加到电路上,并发送BEGINBEGIN_DIRRESOLVE作为开始

如果请求无法成功完成,Tor 会考虑CLOSE中给出的原因

当一个请求在ScoksTimeout后(默认为 22 分钟)后仍未附加到流,Tor 会放弃尝试,并向客户端发送错误信号

如果没有针对BEGINRESOLVE的回应,则认为流超时

原规范这里存在未完成的内容

4 隐藏服务相关电路

查看原文

4. Hidden-service related circuits

XXX Tracking expected hidden service use (client-side and hidserv-side)

原规范这里存在未完成的内容

5 入口守卫

查看原文

5. Guard nodes

We use Guard nodes (also called "helper nodes" in the research literature) to prevent certain profiling attacks. For an overview of our Guard selection algorithm -- which has grown rather complex -- see guard-spec.txt.

使用保护节点(最早称为辅助接点)来防止某些分析攻击。关于选择入口守卫的算法,具体见 guard-spec.txt

5.1 守卫选择带宽权重共识

查看原文

5.1. How consensus bandwidth weights factor into entry guard selection

When weighting a list of routers for choosing an entry guard, the following consensus parameters (from the "bandwidth-weights" line) apply:

  • Wgg - Weight for Guard-flagged nodes in the guard position
  • Wgm - Weight for non-flagged nodes in the guard Position
  • Wgd - Weight for Guard+Exit-flagged nodes in the guard Position
  • Wgb - Weight for BEGIN_DIR-supporting Guard-flagged nodes
  • Wmb - Weight for BEGIN_DIR-supporting non-flagged nodes
  • Web - Weight for BEGIN_DIR-supporting Exit-flagged nodes
  • Wdb - Weight for BEGIN_DIR-supporting Guard+Exit-flagged nodes

Please see "bandwidth-weights" in §3.4.1 of dir-spec.txt for more in depth descriptions of these parameters.

If a router has been marked as both an entry guard and an exit, then we prefer to use it more, with our preference for doing so (roughly) linearly increasing w.r.t. the router's non-guard bandwidth and bandwidth weight (calculated without taking the guard flag into account). From proposal #236:

Let Wpf denote the weight from the 'bandwidth-weights' line a client would apply to N for position p if it had the guard flag, Wpn the weight if it did not have the guard flag, and B the measured bandwidth of N in the consensus. Then instead of choosing N for position p proportionally to WpfB or WpnB, clients should choose N proportionally to FWpfB + (1-F)WpnB.

where F is the weight as calculated using the above parameters.

当在一系列节点中按权重选择入口守卫,以下公式参数适用

  • Wgg: 带有Guard标志的节点处于入口守卫位置的权重
  • Wgm: 无标志的节点位于入口守卫位置的权重
  • Wgd: 带有GuardExit标志的节点处于入口守卫位置的权重
  • Wmg: 带有Guard标志的节点在中间节点位置的权重
  • Wgb: 带有Guard标志且支持BEGIN_DIR的节点权重
  • Wmb: 无标志且支持BEGIN_DIR的权重
  • Web: 带有Exit标志且支持BEGIN_DIR的权重
  • Wdb: 带有GuardExit标志且支持BEGIN_DIR的权重

详情参见 dir-spec.txt 中的带宽权重

如果节点同时被标记为GuardExit,那么我们会更倾向使用它(线性增加其权重)。

在 #236 建议中

如果拥有 Guard 标志,使用 Wpf 标识来自带宽权重线性权重,如果客户端在位置 pp 应用到 NN
如果不拥有 Guard 标志,则使用 Wpn表示,BB 表示的共识中 NN 的测量带宽
客户选择 NN 的概率应该是 F×Wpf×B+(1F)×Wpn×BF\times Wpf \times B + (1 - F) \times Wpn \times B,而非 Wpf×BWpf \times BWpn×BWpn \times B

其中 FF 是通过上述参数计算的权重

6 服务目的描述

查看原文

6. Server descriptor purposes

There are currently three "purposes" supported for server descriptors: general, controller, and bridge. Most descriptors are of type general -- these are the ones listed in the consensus, and the ones fetched and used in normal cases.

Controller-purpose descriptors are those delivered by the controller and labelled as such: they will be kept around (and expire like normal descriptors), and they can be used by the controller in its CIRCUITEXTEND commands. Otherwise they are ignored by Tor when it chooses paths.

Bridge-purpose descriptors are for routers that are used as bridges. See doc/design-paper/blocking.pdf for more design explanation, or proposal 125 for specific details. Currently bridge descriptors are used in place of normal entry guards, for Tor clients that have UseBridges enabled.

目前服务描述符中共有三种 “purposes”:通用、控制器、桥接

大多数的描述符属于通用类型,这些是共识中列出的描述符,以及正常情况下获取和使用的描述符

控制用途的描述符用于控制器,他们与普通描述符一样也会过期,并且在控制器CIRCUITEXTEND命令中使用。在其他情况下,Tor 在路径选择时会忽略他们

在开启UseBridges的 Tor 客户端,将会使用网桥代替入口守卫。具体可见doc/design-paper/blocking.pdf

7 守卫节点检测路径操纵

查看原文

7. Detecting route manipulation by Guard nodes (Path Bias)

The Path Bias defense is designed to defend against a type of route capture where malicious Guard nodes deliberately fail or choke circuits that extend to non-colluding Exit nodes to maximize their network utilization in favor of carrying only compromised traffic.

In the extreme, the attack allows an adversary that carries c/n of the network capacity to deanonymize c/n of the network connections, breaking the O((c/n)^2) property of Tor's original threat model. It also allows targeted attacks aimed at monitoring the activity of specific users, bridges, or Guard nodes.

There are two points where path selection can be manipulated: during construction, and during usage. Circuit construction can be manipulated by inducing circuit failures during circuit extend steps, which causes the Tor client to transparently retry the circuit construction with a new path. Circuit usage can be manipulated by abusing the stream retry features of Tor (for example by withholding stream attempt responses from the client until the stream timeout has expired), at which point the tor client will also transparently retry the stream on a new path.

The defense as deployed therefore makes two independent sets of measurements of successful path use: one during circuit construction, and one during circuit usage.

The intended behavior is for clients to ultimately disable the use of Guards responsible for excessive circuit failure of either type (see section 7.4); however known issues with the Tor network currently restrict the defense to being informational only at this stage (see section 7.5).

路径偏差防御是一种防御路由捕获的策略。恶意的守卫节点可以通过故意失效、阻塞电路来使电路扩展到非恶意的出口节点,使其网络利用率最大化。

极端情况下,这种攻击允许拥有 c/nc/n 网络的敌手对 c/nc/n 的网络去匿名化,破坏了 Tor 原始威胁模型 O((c/n)2)O((c/n)^2) 的特性。其还允许针对特定用户、网桥或保护节点进行攻击

路径选择共有两个操作点:构造期间、使用期间。在电路扩展中,可以通过诱导电路故障来操纵电路狗仔,从而导致 Tor 客户端使用新路径重试电路构造。在使用阶段可以通过滥用流重试特性,在流超时前,拒绝客户端的流测试响应。客户端将在新的路径重试该流。

客户端预期的行为是可以避免使用任何一种类型过度电路故障的守卫,然而目前 Tor 只在这里进行了限制性防御。

7.1 测试构建成功率

查看原文

7.1. Measuring path construction success rates

Clients maintain two counts for each of their guards: a count of the number of times a circuit was extended to at least two hops through that guard, and a count of the number of circuits that successfully complete through that guard. The ratio of these two numbers is used to determine a circuit success rate for that Guard.

Circuit build timeouts are counted as construction failures if the circuit fails to complete before the 95% "right-censored" timeout interval, not the 80% timeout condition (see section 2.4).

If a circuit closes prematurely after construction but before being requested to close by the client, this is counted as a failure.

客户端为每个守护维护两个计数器:

  • 一个电路通过该守护至少被扩展到两跳的次数
  • 成功通过该防护完成电路的数量

这两个数字的比率即为守卫电路的成功率。如果未能在 95%95\% 的右截断超时间隔之前完成,而不是在 80%80\% 之前完成,则将电路构建超时计算为构造故障。如果在构建过程中,用户要求关闭,也视为失败。

7.2 测试路径使用成功率

查看原文

7.2. Measuring path usage success rates

Clients maintain two usage counts for each of their guards: a count of the number of usage attempts, and a count of the number of successful usages.

A usage attempt means any attempt to attach a stream to a circuit.

Usage success status is temporarily recorded by state flags on circuits. Guard usage success counts are not incremented until circuit close. A circuit is marked as successfully used if we receive a properly recognized RELAY cell on that circuit that was expected for the current circuit purpose.

If subsequent stream attachments fail or time out, the successfully used state of the circuit is cleared, causing it once again to be regarded as a usage attempt only.

Upon close by the client, all circuits that are still marked as usage attempts are probed using a RELAY_BEGIN cell constructed with a destination of the form 0.a.b.c:25, where a.b.c is a 24 bit random nonce. If we get a RELAY_COMMAND_END in response matching our nonce, the circuit is counted as successfully used.

If any unrecognized RELAY cells arrive after the probe has been sent, the circuit is counted as a usage failure.

If the stream failure reason codes DESTROY, TORPROTOCOL, or INTERNAL are received in response to any stream attempt, such circuits are not probed and are declared usage failures.

Prematurely closed circuits are not probed, and are counted as usage failures.

客户端的每个守卫维护两个使用计数:

  • 使用次数
  • 成功次数

使用尝试是指将流附加到电路上的任意一种尝试过程。使用成功状态右电路上的临时标记记录,成功使用次数直到电路关闭前不会增加。如果在电路上接收到预期用于当前电路用途的正确识别的中继单元,则该电路被标记为成功使用。如果后续流附加失败或超时,则清除电路的成功使用状态,将其视为仅尝试使用。

当客户端要求关闭后,所有电路将使用RELAY_BEGIN单元进行探测,地址为0.a.b.c:25,其中a.b.c是随机 2424 位值。如果响应中得到了一个RELAY_COMMAND_END匹配上述随机值,则电路被视为成功使用。如果任何未识别RELAY在发送后被接收到,则认为出现了使用故障。

如果由于DESTROYTORPROTOCOLINTERNAL原因导致流失败,那么这些电路不会被探测,直接认为故障

过早闭合的电路不会被探测,将会被认为故障

7.3 扩展成功计数

查看原文

7.3. Scaling success counts

To provide a moving average of recent Guard activity while still preserving the ability to verify correctness, we periodically "scale" the success counts by multiplying them by a scale factor between 0 and 1.0.

Scaling is performed when either usage or construction attempt counts exceed a parametrized value.

To avoid error due to scaling during circuit construction and use, currently open circuits are subtracted from the usage counts before scaling, and added back after scaling.

为了提供最近守卫活动的平均值,同时保持验证正确性的能力,将成功计数乘以 0 \sim 1.0 之间的比例因子,定期进行缩放。

当使用或构造尝试计数超过参数化值时,将进行扩展。

为了避免在电路构造和使用过程中产生因缩放导致的错误,当前电路的缩放要从使用计数中减去,并在缩放后加回

7.4 参数化

查看原文

7.4. Parametrization

The following consensus parameters tune various aspects of the defense.

  • pb_mincircs
    • Default: 150
    • Min: 5
    • Effect: This is the minimum number of circuits that must complete at least 2 hops before we begin evaluating construction rates.
  • pb_noticepct
    • Default: 70
    • Min: 0
    • Max: 100
    • Effect: If the circuit success rate falls below this percentage we emit a notice log message.
  • pb_warnpct
    • Default: 50
    • Min: 0
    • Max: 100
    • Effect: If the circuit success rate falls below this percentage, we emit a warn log message.
  • pb_extremepct
    • Default: 30
    • Min: 0
    • Max: 100
    • Effect: If the circuit success rate falls below this percentage, we emit a more alarmist warning log message. If pb_dropguard is set to 1, we also disable the use of the guard.
  • pb_dropguards
    • Default: 0
    • Min: 0
    • Max: 1
    • Effect: If the circuit success rate falls below pb_extremepct, when pb_dropguard is set to 1, we disable use of that guard.
  • pb_scalecircs
    • Default: 300
    • Min: 10
    • Effect: After this many circuits have completed at least two hops, Tor performs the scaling described in Section 7.3.
  • pb_multfactor and pb_scalefactor
    • Default: 1/2
    • Min: 0.0
    • Max: 1.0
    • Effect: The double-precision result obtained from pb_multfactor/pb_scalefactor is multiplied by our current counts to scale them.
  • pb_minuse
    • Default: 20
    • Min: 3
    • Effect: This is the minimum number of circuits that we must attempt to use before we begin evaluating construction rates.
  • pb_noticeusepct
    • Default: 80
    • Min: 3
    • Effect: If the circuit usage success rate falls below this percentage, we emit a notice log message.
  • pb_extremeusepct
    • Default: 60
    • Min: 3
    • Effect: If the circuit usage success rate falls below this percentage, we emit a warning log message. We also disable the use of the guard if pb_dropguards is set.
  • pb_scaleuse
    • Default: 100
    • Min: 10
    • Effect: After we have attempted to use this many circuits, Tor performs the scaling described in Section 7.3.

下面的共识参数调整了各种方式的内容

名称 默认值 最小值 最大值 效果
pb_mincircs 150 5 开始评估构建速率前必须完成至少两跳的电路数
pb_noticepct 70 0 100 如果电路成功率低于这个百分比,会发出一个日志提醒
pb_warnpct 50 0 100 如果电路成功率低于这个百分比,会发出一个日志提醒
pb_extrempct 30 0 100 如果电路成功率低于这个百分比,将会发送一个更为严重的提醒。当 pb_dropguard 为 1 时,将会禁用该守卫
pb_dropguards 0 0 1 如果电路成功率低于 pb_extremepct ,当 pb_dropguard 为 1 时,将会禁用该守卫
pb_scalecircs 300 10 多个电路完成至少两个跳变后,Tor 执行 7.3 所述的缩放
pb_multfactor and pb_scalefactor 1/2 0.0 1.0 将 pb_multifactor/pb_scalefactor 得到的双精度乘以当前精度进行缩放
pb_minuse 20 3 评估构建率之前必须尝试的最小电路数
pb_noticeusepct 80 3 如果电路成功率低于这个百分比,会发出一个日志提醒
pb_extremeuspect 60 3 如果电路成功率低于这个百分比,会发出一个日志提醒。当 pb_dropguard 为 1 时,将会禁用该守卫
pb_scaleuse 100 10 尝试使用这些电路后,执行 7.3 所述的缩放

7.4 已知的障碍

查看原文

7.5. Known barriers to enforcement

Due to intermittent CPU overload at relays, the normal rate of successful circuit completion is highly variable. The Guard-dropping version of the defense is unlikely to be deployed until the ntor circuit handshake is enabled, or the nature of CPU overload induced failure is better understood.

由于中继会间歇性地 CPU 过载,因此电路的成功率是可变的。

电路握手启用或 CPU 过早导致的故障被更好的识别前,防御策略的守卫不太可能会部署,

X 旧版本记录

X.1 是否真的使用

查看原文

X.1. Do we actually do this?

How to deal with network down.

  • While all helpers are down/unreachable and there are no established or on-the-way testing circuits, launch a testing circuit.
    (Do this periodically in the same way we try to establish normal circuits when things are working normally.)
    (Testing circuits are a special type of circuit, that streams won't attach to by accident.)
  • When a testing circuit succeeds, mark all helpers up and hold the testing circuit open.
  • If a connection to a helper succeeds, close all testing circuits. Else mark that helper down and try another.
  • If the last helper is marked down and we already have a testing circuit established, then add the first hop of that testing circuit to the end of our helper node list, close that testing circuit, and go back to square one. (Actually, rather than closing the testing circuit, can we get away with converting it to a normal circuit and beginning to use it immediately?)

[Do we actually do any of the above? If so, let's spec it. If not, let's remove it. -NM]

如何处理网络故障:

  • 当所有的守卫都已关闭或无法到达,并且没有建立于正在进行的测试电路时,启动一个测试电路(将会与正常电路相同,周期性地进行测试。测试电路是一种特殊的电路,流不会附加到测试电路)
  • 当电路测试成功时,所有的守卫会被标记,并且保持测试电路可用
  • 如果与守卫连接成功,则会关闭所有测试电路;否则记录该守卫并测试下一个
  • 如果最后一个守卫被记录,并且已建立测试电路,那么将测试电路第一跳加到守卫列表的末尾。关闭该测试并重新开始(如果可以将关闭测试电路改为将其转换为正常电路会更好)

如果确实实现了上述内容,则进行说明;否则删除

X.2 处理可达性

查看原文

X.2. A thing we could do to deal with reachability.

And as a bonus, it leads to an answer to Nick's attack ("If I pick my helper nodes all on 18.0.0.0:*, then I move, you'll know where I bootstrapped") -- the answer is to pick your original three helper nodes without regard for reachability. Then the above algorithm will add some more that are reachable for you, and if you move somewhere, it's more likely (though not certain) that some of the originals will become useful. Is that smart or just complex?

处理可达性为 Nick 的攻击提供了一个答案。选择三个守卫,不考虑可达性。其算法可以添加更多可达的数据,从而使一些数据更为有用。

这是明智的选择还是过于复杂的选择?

X.3 关于守卫的担忧

查看原文

X.3. Some stuff that worries me about entry guards. 2006 Jun, Nickm.

It is unlikely for two users to have the same set of entry guards. Observing a user is sufficient to learn its entry guards. So, as we move around, entry guards make us linkable. If we want to change guards when our location (IP? subnet?) changes, we have two bad options. We could

  • Drop the old guards. But if we go back to our old location, we'll not use our old guards. For a laptop that sometimes gets used from work and sometimes from home, this is pretty fatal.
  • Remember the old guards as associated with the old location, and use them again if we ever go back to the old location. This would be nasty, since it would force us to record where we've been.

[Do we do any of this now? If not, this should move into 099-misc or 098-todo. -NM]

两个用户不太可能拥有完全相同的守卫列表,观察一个用户可以了解其入口守卫。如果想要改变守卫时,位置相会变化。这时有两个坏的选择:

  • 放弃老的守卫,当回到原来的位置是,不再使用原来的守卫。对于一个可能移动位置的笔记本电脑,这可能是致命的
  • 记住有关旧地点的守卫,如果回到旧地点则继续使用。这需要我们记录所有位置使用的守卫

现在有实现这些么?如果没有应该将其列入计划中。