<div dir="auto"><div>Any situation that allows the passcode method though is open to painting Poland, or anywhere really.  An open and published algorithm for generating them means your painter just needs to implement the generation of a random passcode and call for each instance, and then run lots of instances.  The rates mentioned for this attack wouldn't even stress the upstream on most home internet links for a single IP source.  </div><div dir="auto"><br></div><div dir="auto">Hessu mentioned this already, but rate limits may protect against an accidental situation...  but even forcing things right down to 2 packets per second as mused by Curt, 1500 - 2000 packets per second can be done with 750-1000 clients which can be done with unique IPs pretty easily meaning there is no way to block it if done on purpose.</div><div dir="auto"><br></div><div dir="auto">As such the effort to rate limit or implement signed access doesn't really make sense, if the passcode access is being made available because you're still leaving the system unlocked.  </div><div dir="auto"><br></div><div dir="auto">p<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon., Sep. 7, 2020, 2:51 p.m. Nick VA3NNW, <<a href="mailto:tapr@noseynick.com">tapr@noseynick.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Scott Miller wrote:<br>
> Please have mercy on us embedded implementers! PKI support would be <br>
> fine, as long as there's some other solution available for devices <br>
> that don't have the resources for asymmetric cryptography. A <br>
> pre-shared key, maybe, with any required crypto functions based on <br>
> something with low computational requirements like XXTEA.<br>
<br>
THIS. My guess is a fair solution would be something like:<br>
<br>
Connect with today's 4-to-5-digit passcode and you can connect but get <br>
your uplink rate-limited to something that's probably perfectly <br>
reasonable for embedded implementers, probably even "normal" RF igates, <br>
but won't allow you to paint poland with profanity<br>
<br>
Connect with Mutual TLS (LotW cert *OR* similar "proof you are a ham" <br>
from other national / international licensing bodies PLEASE) and you get <br>
a whole lot more uplink bandwidth, much more suitable for running <br>
high-bandwidth igates or popular APRS services. You probably COULD paint <br>
poland, or at least draw a few scribbles on it, but would be a great way <br>
to get your cert revoked / added to the "deny" list until you can get it <br>
replaced. On the assumption that some hams DO get hacked, but also <br>
recognising that some idiots CAN surprisingly get a ham license... Maybe <br>
a "3 strikes and you're out" rule or something?<br>
<br>
Connect with Mutual TLS (cert from / signed by "the backbone people" <br>
when you offered to host a backbone node) and you get all the uplink <br>
bandwidth you could can eat, FAR too much for RF, could definitely paint <br>
poland, BUT you'd get yourself banned from the backbone until your <br>
clearly-hacked cert can be replaced.<br>
<br>
PROBABLY no reason to limit DOWNLINK bandwidth? You can / will obviously <br>
use filtered downlink (or no downlink) for embedded applications and/or <br>
RF igates, and I'm not (yet) aware of any way it can be (ab)used for DoS <br>
except possibly DoSing your own downlink?<br>
<br>
I have somewhat assumed TCP above. UDP? "Discuss". Mutual DTLS?<br>
<br>
HTTP and some of the other submission protocols? "Discuss"<br>
<br>
OK, how about RF? Safe to assume you're already rate-limited enough <br>
and/or DF-able enough?<br>
<br>
73, Nick VA3NNW<br>
<br>
-- <br>
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.<br>
use Std::Disclaimer;    <a href="mailto:sig@noseynick.net" target="_blank" rel="noreferrer">sig@noseynick.net</a><br>
Xerox does it again and again and again and ...<br>
<br>
<br>
_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org" target="_blank" rel="noreferrer">aprssig@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
</blockquote></div></div></div>