Loading proposals/xxx-padding-negotiation.txt +43 −6 Original line number Diff line number Diff line Loading @@ -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]; Loading Loading @@ -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]; Loading Loading @@ -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 Loading @@ -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 Loading Loading @@ -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. Loading Loading @@ -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 Loading Loading @@ -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 Loading Loading
proposals/xxx-padding-negotiation.txt +43 −6 Original line number Diff line number Diff line Loading @@ -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]; Loading Loading @@ -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]; Loading Loading @@ -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 Loading @@ -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 Loading Loading @@ -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. Loading Loading @@ -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 Loading Loading @@ -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 Loading
