commit 8ee79e004dd83830446002a7fb0b1689c90130cb Author: Mike Perry <mikeperry-git@torproject.org> Date: Sun Sep 13 19:32:39 2015 -0700 Add overhead accounting information. Also fix a typo pointed out by Marc Juarez, and perform some other misc cleanups. --- proposals/xxx-padding-negotiation.txt | 49 +++++++++++++++++++++++++++++---- 1 file changed, 43 insertions(+), 6 deletions(-) diff --git a/proposals/xxx-padding-negotiation.txt b/proposals/xxx-padding-negotiation.txt index b7d4e75..a42bd6c 100644 --- a/proposals/xxx-padding-negotiation.txt +++ b/proposals/xxx-padding-negotiation.txt @@ -192,6 +192,8 @@ specified in Trunnel as follows: /* This payload encodes a histogram delay distribution representing * the probability of sending a single RELAY_DROP cell after a * given delay in response to a non-padding cell. + * + * Payload max size: 113 bytes */ struct burst_state { u8 histogram_len IN [2..51]; @@ -224,6 +226,8 @@ specified in Trunnel as follows: /* This histogram encodes a delay distribution representing the * probability of sending a single additional padding packet after * sending a padding packet that originated at this hop. + * + * Payload max size: 113 bytes */ struct gap_state { u8 histogram_len IN [2..51]; @@ -253,6 +257,7 @@ specified in Trunnel as follows: u8 remove_tokens IN [0..3]; }; + /* Payload max size: 227 bytes */ struct adaptive_padding_machine { /* This is a bitfield which specifies which direction and types * of traffic should cause us to transition to the burst @@ -264,7 +269,10 @@ specified in Trunnel as follows: }; /* This is the full payload of a RELAY_COMMAND_PADDING_ADAPTIVE - * cell. */ + * cell. + * + * Payload max size: 455 bytes + */ struct relay_command_padding_adaptive { /* Technically, we could allow more than 2 state machines here, but only two are sure to fit. More than 2 seems excessive @@ -346,7 +354,7 @@ histograms that the client uses locally will differ from the ones it sends to the upstream relay. On the client, the "SENT" direction means packets destined towards the -upstream, where as "RECV" means packets destined towards the client. +relay, where as "RECV" means packets destined towards the client. However, on the relay, the "SENT" direction means packets destined towards the client, where as "RECV" means packets destined towards the relay. @@ -489,7 +497,7 @@ possible. The risks from this proposal are primarily DoS/resource exhaustion, and side channels. -4.1. Rate limiting +4.1. Rate limiting and accounting Fully client-requested padding introduces a vector for resource amplification attacks and general network overload due to @@ -523,9 +531,38 @@ padding requests should be ignored: XXX: Should we cap padding at these rates, or fully disable it once they're crossed? Probably cap? -Proposal 251 introduced extra-info accounting at relays to enable us to -measure the total overhead of both link and circuit-level padding at -various relays. +In order to monitor the quantity of padding to decide if we should alter +these limits in the consensus, every node will publish the following +values in a padding-counts line in its extra-info descriptor: + + * write-drop-multihop + - The number of RELAY_DROP cells sent by this relay to a next hop + that is listed in the consensus. + * write-drop-onehop + - The number of RELAY_DROP cells sent by this relay to a next hop + that is not listed in the consensus. + * write-pad + - The number of CELL_PADDING cells sent by this relay. + * write-total + - The total number of cells sent by this relay. + * read-drop-multihop + - The number of RELAY_DROP cells read by this relay from a hop + that is listed in the consensus. + * read-drop-onehop + - The number of RELAY_DROP cells read by this relay from a hop + that is not listed in the consensus. + * read-pad + - The number of CELL_PADDING cells read by this relay. + * read-total + - The total number of cells read by this relay. + +Each of these counters will be rounded to the nearest 10,000 cells. This +rounding parameter will also be listed in the extra-info descriptor line, in +case we change it in a later release. + +In the future, we may decide to introduce Laplace Noise in a similar +manner to the hidden service statistics, to further obscure padding +quantities. 4.2. Malicious state machines