MASQ-Project
Enforce limits on `rate-pack` value
Currently the rate-pack values don't really have any thresholds - turns out they can be set to 0|0|0|0 and also very very high amounts.
Adjust the limits in Node to ensure this is not creating an attack vector or way to game the routing logic across the MASQ Network.
Will add suggested upper limit threshold in description here.
If there are going to be limits on rate-pack values, they can't be limits on what a user is allowed to set his own rate-pack values to, because remember, we're open source. Anybody can download the source, change the limits to whatever he wants, compile, and fire up a Node.
They'll have to be limits imposed during the processing of Gossip. If you Gossip that your rate-pack values are outside the specified limits, you get malefactor-banned. (Of course, we don't have malefactor banning yet, so for now you'd just get your connection dropped.)
Limiting rate packs shouldn't be necessary, and is only being considered because we haven't yet implemented other things we have planned.
For example, a high limit should be unnecessary because high rates should choke off traffic and create the same result as the offending Node being banned. The possible attack is that a Node could become very highly-connected and then raise its rates to confiscatory levels and block traffic. I have two problems with this. First, if it's highly connected, then the Nodes around it likely are as well, and traffic will organically route around it. Second, currently it could achieve the same goal much more simply by merely disappearing. There is yet no self-healing functionality in the Network; leaving a hole in it is the same as staying up but not serving any traffic.
A low limit should be unnecessary because it will attract huge amounts of traffic and produce high latency and poor performance. Currently, we can't detect high latency, so we have no defense against this attack. If we did, though, the high latency numbers would again organically route traffic around the attack.
One attack that we have not designed a defense for is the attack where an evil Node becomes a heavily-connected part of the Network and then, at a signal or the expiry of a timer, begins discarding all the traffic it receives. Note that latency detection would work as a defense against this too, because such a Node would quickly begin showing infinite latency; its undesirability would skyrocket, and traffic would be routed around it.
Perhaps instead of spending too much time on hard limits for rate packs, we should spend the time on self healing and latency detection. Those would solve the rate-limit problems and a number of others as well.
Based on discussion in our meeting @dnwiebe:
Local rate-limits (in the current units of wei of $MASQ) Minimum: 100 (don't allow zero) Maximum: 100000000000000 (representing max of 0.0001 $MASQ)
can use https://eth-converter.com/ to verify conversions
if integer is too large to store in the data object size, we can go smaller on the max