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
Attachment:
0x9FC527CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev