[tor-dev] Proposal: Padding Negotiation

[Michael Rogers]

On 12/09/15 01:34, Mike Perry wrote:
> 4.1. Rate limiting
> 
> Fully client-requested padding introduces a vector for resource
> amplification attacks and general network overload due to
> overly-aggressive client implementations requesting too much padding.
> 
> Current research indicates that this form of statistical padding should
> be effective at overhead rates of 50-60%. This suggests that clients
> that use more padding than this are likely to be overly aggressive in
> their behavior.
> 
> We recommend that three consensus parameters be used in the event that
> the network is being overloaded from padding to such a degree that
> padding requests should be ignored:
> 
>   * CircuitPaddingMaxRatio
>     - The maximum ratio of padding traffic to non-padding traffic
>       (expressed as a percent) to allow on a circuit before ceasing
>       to pad. Ex: 75 means 75 padding packets for every 100 non-padding
>       packets.
>     - Default: 100
>   * CircuitPaddingLimitCount
>     - The number of padding cells that must be transmitted before the
>       ratio limit is applied.
>     - Default: 500
>   * CircuitPaddingLimitTime
>     - The time period in seconds over which to count padding cells for
>       application of the ratio limit.
>     - Default: 60

Without disputing the need for limits, I wonder whether the ratio of
padding to non-padding traffic during a fixed time period is definitely
the right thing to limit. I'm guessing that the research showing that an
overhead of 50-60% is effective applies to website fingerprinting - what
about other applications?

Consider a chat client that sends a very small amount of very bursty
traffic. It will be hard to choose a padding distribution that provides
any useful concealment of the real traffic pattern without risking
exceeding the padding-to-traffic limit during some time periods. But
this client is hardly a threat to the network, even if it sometimes
sends more padding than traffic.

Calculating the ratio over the whole lifetime of the circuit would be an
improvement, but the problem would still arise at the start of the
circuit's lifetime (it seems like the appropriate value of
CircuitPaddingLimitCount would be application-dependent).

I'm not sure what to suggest here, but it seems a shame to have a
super-flexible way to specify padding distributions and then impose
limits that mean clients will only use simple padding distributions that
they can be sure will stay within the limits.

> XXX: Should we cap padding at these rates, or fully disable it once
> they're crossed?

If the ratio exceeds the limit and the relay stops padding, will the
client know that the circuit's no longer protected? Perhaps the safe
thing would be to kill the circuit?

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 1731 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151014/c98d4a7a/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151014/c98d4a7a/attachment-0001.sig>