[aprssig] aprsis DOS in Poland, observation

[Scott Miller]

On 9/7/2020 5:59 PM, spam8mybrain via aprssig wrote:
> We can't ever stop people from being evil; we can only make it more 
> trouble than it's worth to be evil.
>
> My proposal assumes throttling per connection, with a lower throttling 
> rate for the completely compromised passcode authentication than for 
> PKI authentication. That way, Scott's telemetry devices, which 
> shouldn't be sending packets very fast any way (more than 1 every 10 
> seconds average would be excessive for that use case) would still 
> work, while the more stringent PKI authentication (much harder to 
> forge) would have a higher throttling threshold.
The Tracker4 functions as a standalone IGate, so it needs to be able to 
handle all of a local RF network's traffic.

But I think you're on the right track; the old passcode scheme should be 
acceptable for low-rate inputs and anything higher needs a higher 
standard of authentication. Just don't assume that for every IGate it's 
a trivial thing to handle PKI. Coincidentally I'm working on 
incorporating mbed TLS into a Tracker4 relative and the memory footprint 
is something like 20-60 kB of RAM and 60-250 kB of flash, depending on 
the feature set. That makes it the largest software component in the 
device by a huge margin - and all because Chrome won't let you turn on 
the mic in a browser unless the page is served over an HTTPS connection. 
There's absolutely no functional requirement for encryption or 
authentication in this use case, but Google's security policy (which 
isn't really a bad idea 99% of the time) imposes such a burden on the 
client that it has to use a larger microcontroller.

Scott
N1VG