diff options
| -rw-r--r-- | padding-spec.txt | 85 | ||||
| -rw-r--r-- | proposals/000-index.txt | 4 | ||||
| -rw-r--r-- | proposals/339-udp-over-tor.md | 13 | ||||
| -rw-r--r-- | proposals/BY_INDEX.md | 2 | ||||
| -rw-r--r-- | proposals/README.md | 2 | ||||
| -rw-r--r-- | tor-spec.txt | 10 |
6 files changed, 73 insertions, 43 deletions
diff --git a/padding-spec.txt b/padding-spec.txt index 825f1d7..ea16d8b 100644 --- a/padding-spec.txt +++ b/padding-spec.txt @@ -143,6 +143,12 @@ Table of Contents user traffic in that time period is multiplexed over a single connection (as it is with Tor). + Though flow measurement in principle can be bidirectional (counting cells + sent in both directions between a pair of IPs) or unidirectional (counting + only cells sent from one IP to another), we assume for safety that all + measurement is unidirectional, and so traffic must be sent by both parties + in order to prevent record splitting. + 2.2. Implementation Tor clients currently maintain one TLS connection to their Guard node to @@ -154,35 +160,41 @@ Table of Contents connections, and pad them, but otherwise not pad between normal relays. Both clients and Guards will maintain a timer for all application (ie: - non-directory) TLS connections. Every time a non-padding packet is sent or - received by either end, that endpoint will sample a timeout value from - between 1.5 seconds and 9.5 seconds using the max(X,X) distribution - described in Section 2.3. The time range is subject to consensus + non-directory) TLS connections. Every time a padding packet sent by an + endpoint, that endpoint will sample a timeout value from + the max(X,X) distribution described in Section 2.3. The default + range is from 1.5 seconds to 9.5 seconds time range, subject to consensus parameters as specified in Section 2.6. - If the connection becomes active for any reason before this timer - expires, the timer is reset to a new random value between 1.5 and 9.5 - seconds. If the connection remains inactive until the timer expires, a - single CELL_PADDING cell will be sent on that connection. + (The timing is randomized to avoid making it obvious which cells are + padding.) - In this way, the connection will only be padded in the event that it is - idle, and will always transmit a packet before the minimum 10 second inactive - timeout. + If another cell is sent for any reason before this timer expires, the timer + is reset to a new random value. -2.3. Padding Cell Timeout Distribution Statistics + If the connection remains inactive until the timer expires, a + single CELL_PADDING cell will be sent on that connection (which will + also start a new timer). + + In this way, the connection will only be padded in a given direction in + the event that it is idle in that direction, and will always transmit a + packet before the minimum 10 second inactive timeout. - It turns out that because the padding is bidirectional, and because both - endpoints are maintaining timers, this creates the situation where the time - before sending a padding packet in either direction is actually - min(client_timeout, server_timeout). + (In practice, an implementation may not be able to determine when, + exactly, a cell is sent on a given channel. For example, even though the + cell has been given to the kernel via a call to `send(2)`, the kernel may + still be buffering that cell. In cases such as these, implementations + should use a reasonable proxy for the time at which a cell is sent: for + example, when the cell is queued. If this strategy is used, + implementations should try to observe the innermost (closest to the wire) + queue that the practically can, and if this queue is already nonempty, + padding should not be scheduled until after the queue does become empty.) - If client_timeout and server_timeout are uniformly sampled, then the - distribution of min(client_timeout,server_timeout) is no longer uniform, and - the resulting average timeout (Exp[min(X,X)]) is much lower than the - midpoint of the timeout range. +2.3. Padding Cell Timeout Distribution Statistics - To compensate for this, instead of sampling each endpoint timeout uniformly, - we instead sample it from max(X,X), where X is uniformly distributed. + To limit the amount of padding sent, instead of sampling each endpoint + timeout uniformly, we instead sample it from max(X,X), where X is + uniformly distributed. If X is a random variable uniform from 0..R-1 (where R=high-low), then the random variable Y = max(X,X) has Prob(Y == i) = (2.0*i + 1)/(R*R). @@ -206,9 +218,6 @@ Table of Contents 15000 7499.5 7995 4999.5 9999.5 20000 9900.5 10661 6666.2 13332.8 - In this way, we maintain the property that the midpoint of the timeout range - is the expected mean time before a padding packet is sent in either - direction. 2.4. Maximum overhead bounds @@ -253,6 +262,13 @@ Table of Contents CELL_PADDING_NEGOTIATE to instruct the relay not to pad, and then does not send any further padding itself. + Currently, clients negotiate padding only when a channel is created, + immediately after sending their NETINFO cell. Recipients SHOULD, however, + accept padding negotiation messages at any time. + + Clients and bridges MUST reject padding negotiation messages from relays, + and close the channel if they receive one. + 2.6. Consensus Parameters Governing Behavior Connection-level padding is controlled by the following consensus parameters: @@ -277,11 +293,22 @@ Table of Contents - Default: 14000 * nf_conntimeout_clients - - The number of seconds to keep circuits opened and available for - clients to use. Note that the actual client timeout is randomized - uniformly from this value to twice this value. This governs client - OR conn lifespan. Reduced padding clients use half the consensus + - The number of seconds to keep never-used circuits opened and + available for clients to use. Note that the actual client timeout is + randomized uniformly from this value to twice this value. + - The number of seconds to keep idle (not currently used) canonical + channels are open and available. (We do this to ensure a sufficient + time duration of padding, which is the ultimate goal.) + - This value is also used to determine how long, after a port has been + used, we should attempt to keep building predicted circuits for that + port. (See path-spec.txt section 2.1.1.) This behavior was + originally added to work around implementation limitations, but it + serves as a reasonable default regardless of implementation. + - For all use cases, reduced padding clients use half the consensus value. + - Implementations MAY mark circuits held open past the reduced padding + quantity (half the consensus value) as "not to be used for streams", + to prevent their use from becoming a distinguisher. - Default: 1800 * nf_pad_before_usage diff --git a/proposals/000-index.txt b/proposals/000-index.txt index bdb5203..c2cc6a9 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -259,7 +259,7 @@ Proposals by number: 336 Randomized schedule for guard retries [ACCEPTED] 337 A simpler way to decide, "Is this guard usable?" [ACCEPTED] 338 Use an 8-byte timestamp in NETINFO cells [ACCEPTED] -339 UDP traffic over Tor [DRAFT] +339 UDP traffic over Tor [ACCEPTED] Proposals by status: @@ -270,7 +270,6 @@ Proposals by status: 327 A First Take at PoW Over Introduction Circuits 329 Overcoming Tor's Bottlenecks with Traffic Splitting 331 Res tokens: Anonymous Credentials for Onion Service DoS Resilience - 339 UDP traffic over Tor NEEDS-REVISION: 212 Increase Acceptable Consensus Age [for 0.2.4.x+] 219 Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x] @@ -312,6 +311,7 @@ Proposals by status: 336 Randomized schedule for guard retries 337 A simpler way to decide, "Is this guard usable?" 338 Use an 8-byte timestamp in NETINFO cells + 339 UDP traffic over Tor META: 000 Index of Tor Proposals 001 The Tor Proposal Process diff --git a/proposals/339-udp-over-tor.md b/proposals/339-udp-over-tor.md index 2dbe3b5..3c1a1d4 100644 --- a/proposals/339-udp-over-tor.md +++ b/proposals/339-udp-over-tor.md @@ -3,7 +3,7 @@ Filename: 339-udp-over-tor.md Title: UDP traffic over Tor Author: Nick Mathewson Created: 11 May 2020 -Status: Draft +Status: Accepted ``` # Introduction @@ -198,12 +198,6 @@ format. ``` struct udp_connected_body { - /* 5 bytes to distinguish from other CONNECTED_UDP cells. This is not - * strictly necessary, since we can distinguish by context, but - * it's nice to have a way to tell them apart at the parsing stage. - */ - u32 zero IN [0]; - u8 ff IN [0xFF]; /* The address that the relay has bound locally. This might not * be an address that is advertised in the relay's descriptor. */ struct address our_address; @@ -216,7 +210,7 @@ struct udp_connected_body { } /* Note that this is a subset of the allowable address parts of a CONNECT_UDP - message */ + * message */ struct address { u8 tag IN [T_IPV4, T_IPV6]; u8 len; @@ -233,8 +227,7 @@ struct address { ``` struct datagram_body { /* The datagram body is the entire body of the message. - This length is in the relay message header. - */ + * This length is in the relay message header. */ u8 body[..]; } ``` diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md index 0e9aa1d..f55bc61 100644 --- a/proposals/BY_INDEX.md +++ b/proposals/BY_INDEX.md @@ -256,5 +256,5 @@ Below are a list of proposals sorted by their proposal number. See * [`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): Randomized schedule for guard retries [ACCEPTED] * [`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): A simpler way to decide, "Is this guard usable?" [ACCEPTED] * [`338-netinfo-y2038.md`](/proposals/338-netinfo-y2038.md): Use an 8-byte timestamp in NETINFO cells [ACCEPTED] -* [`339-udp-over-tor.md`](/proposals/339-udp-over-tor.md): UDP traffic over Tor [DRAFT] +* [`339-udp-over-tor.md`](/proposals/339-udp-over-tor.md): UDP traffic over Tor [ACCEPTED] diff --git a/proposals/README.md b/proposals/README.md index 643cf53..b49573b 100644 --- a/proposals/README.md +++ b/proposals/README.md @@ -58,6 +58,7 @@ implementation. * [`336-randomize-guard-retries.md`](/proposals/336-randomize-guard-retries.md): Randomized schedule for guard retries * [`337-simpler-guard-usability.md`](/proposals/337-simpler-guard-usability.md): A simpler way to decide, "Is this guard usable?" * [`338-netinfo-y2038.md`](/proposals/338-netinfo-y2038.md): Use an 8-byte timestamp in NETINFO cells +* [`339-udp-over-tor.md`](/proposals/339-udp-over-tor.md): UDP traffic over Tor ## FINISHED proposals: implemented, specs not merged @@ -106,7 +107,6 @@ discussion. * [`327-pow-over-intro.txt`](/proposals/327-pow-over-intro.txt): A First Take at PoW Over Introduction Circuits * [`329-traffic-splitting.txt`](/proposals/329-traffic-splitting.txt): Overcoming Tor's Bottlenecks with Traffic Splitting * [`331-res-tokens-for-anti-dos.md`](/proposals/331-res-tokens-for-anti-dos.md): Res tokens: Anonymous Credentials for Onion Service DoS Resilience -* [`339-udp-over-tor.md`](/proposals/339-udp-over-tor.md): UDP traffic over Tor ## NEEDS-REVISION proposals: ideas that we can't implement as-is diff --git a/tor-spec.txt b/tor-spec.txt index 49516f4..234d209 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1684,6 +1684,8 @@ see tor-design.pdf. 14 -- RELAY_EXTEND2 [forward] [control] 15 -- RELAY_EXTENDED2 [backward] [control] + 16..18 -- Reserved for UDP; Not yet in use, see prop339. + 32..40 -- Used for hidden services; see rend-spec-{v2,v3}.txt. 41..42 -- Used for circuit padding; see Section 3 of padding-spec.txt. @@ -2435,3 +2437,11 @@ see tor-design.pdf. "2" -- supports congestion control by the Exits which implies a new SENDME format and algorithm. See proposal 324 for more details. Advertised in tor 0.4.7.3-alpha. + +9.13. "Datagram" + + Describes the UDP protocol capabilities of a relay. + + "1" -- [RESERVED] supports UDP by an Exit as in the relay command + CONNECT_UDP, CONNECTED_UDP and DATAGRAM. See proposal + 339 for more details. (Not yet advertised, reserved) |