[aprssig] aprsis DOS in Poland, observation

[Patrick]

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.

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.

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.

p

On Mon., Sep. 7, 2020, 2:51 p.m. Nick VA3NNW, <tapr at noseynick.com> wrote:

> Scott Miller wrote:
> > Please have mercy on us embedded implementers! PKI support would be
> > fine, as long as there's some other solution available for devices
> > that don't have the resources for asymmetric cryptography. A
> > pre-shared key, maybe, with any required crypto functions based on
> > something with low computational requirements like XXTEA.
>
> THIS. My guess is a fair solution would be something like:
>
> Connect with today's 4-to-5-digit passcode and you can connect but get
> your uplink rate-limited to something that's probably perfectly
> reasonable for embedded implementers, probably even "normal" RF igates,
> but won't allow you to paint poland with profanity
>
> Connect with Mutual TLS (LotW cert *OR* similar "proof you are a ham"
> from other national / international licensing bodies PLEASE) and you get
> a whole lot more uplink bandwidth, much more suitable for running
> high-bandwidth igates or popular APRS services. You probably COULD paint
> poland, or at least draw a few scribbles on it, but would be a great way
> to get your cert revoked / added to the "deny" list until you can get it
> replaced. On the assumption that some hams DO get hacked, but also
> recognising that some idiots CAN surprisingly get a ham license... Maybe
> a "3 strikes and you're out" rule or something?
>
> Connect with Mutual TLS (cert from / signed by "the backbone people"
> when you offered to host a backbone node) and you get all the uplink
> bandwidth you could can eat, FAR too much for RF, could definitely paint
> poland, BUT you'd get yourself banned from the backbone until your
> clearly-hacked cert can be replaced.
>
> PROBABLY no reason to limit DOWNLINK bandwidth? You can / will obviously
> use filtered downlink (or no downlink) for embedded applications and/or
> RF igates, and I'm not (yet) aware of any way it can be (ab)used for DoS
> except possibly DoSing your own downlink?
>
> I have somewhat assumed TCP above. UDP? "Discuss". Mutual DTLS?
>
> HTTP and some of the other submission protocols? "Discuss"
>
> OK, how about RF? Safe to assume you're already rate-limited enough
> and/or DF-able enough?
>
> 73, Nick VA3NNW
>
> --
> "Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
> use Std::Disclaimer;    sig at noseynick.net
> Xerox does it again and again and again and ...
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200907/9ce424d9/attachment.html>