[aprssig] aprsis DOS in Poland, observation

[David Andrzejewski]

Do your embedded systems run over IP or RF or both?

Do we need (or want) additional authentication on RF?  I can see
arguments for both sides.  We don't really have any kind of strong
authentication on RF for most other modes.

As for LoTW being the CA, I'd caution that maybe we don't want a
singular organization to control the PKI.

- Dave/ad8g

On 9/7/2020 12:23, 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.
>
> Scott
> N1VG
>
> On 9/5/2020 10:07 AM, Mobilinkd LLC wrote:
>> Would it be worthwhile discussing whether to use PKI for APRS-IS
>> authentication?
>>
>> I just discovered that there is a registered X.509 extension for ham
>> radio callsigns and that we already have a CA in LOTW.
>>
>> https://perens.com/2019/07/02/yes-it-is-legal-to-use-cryptographic-signature-on-amateur-radio-and-thats-important/
>>
>> Kind Regards,
>>
>> Rob Riggs WX9O
>> Mobilinkd LLC
>>
>>
>> On Sat, Sep 5, 2020 at 6:15 AM Heikki Hannikainen <hessu at hes.iki.fi
>> <mailto:hessu at hes.iki.fi>> wrote:
>>
>>     On Fri, 4 Sep 2020, Bill Vodall wrote:
>>
>>     > Is aprs-is under a Denial of Services attack by jankesi and others?
>>     > Looks like multiple packets arriving every second.
>>
>>     The packet rate during the DOS abuse event last night was some
>>     1500-1700
>>     packets per second at peak.
>>
>>     https://www.dropbox.com/s/tztvaup286vzwnb/aprsfi-polish-abuse-20200904-traffic.png?dl=0
>>
>>     Some APRS-IS clients on the full feed could not take this traffic
>>     (too
>>     slow to process, or too slow network, buffers fill up) and got
>>     disconnected. As a network traffic rate, it was only around 1.4
>>     Mbit/s sec
>>     though. Due to a bug, the two APRS-IS data aggregator aprsc
>>     instances at
>>     aprs.fi <http://aprs.fi> crashed too, leaving aprs.fi
>>     <http://aprs.fi> without a data feed.
>>
>>     This is how it looked on the map, screen shot courtesy of Mateusz
>>     Szyper
>>     on the aprs.fi <http://aprs.fi> discussion group:
>>
>>     https://www.dropbox.com/s/5wbjtttkkw1munh/aprs-polish-abuse-20200904-map.jpg?dl=0
>>
>>     And here are a few sample packets, showing what the randomly
>>     generated
>>     packets looked like. The coordinates are random, in Poland, with the
>>     clear intention of polluting the map fully.
>>
>>     2020-09-04 19:48:27 EEST:
>>     CI37PA>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5031.68N\01844.35EZ jeszcze
>>     nie dojrzalem.
>>     2020-09-04 19:48:46 EEST:
>>     CI371PY-3>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5248.72N/01933.83EX sie
>>     draznic z ludzmi.
>>     2020-09-04 19:45:58 EEST:
>>     CI37PA-21>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5411.38N\01600.85E-2
>>     Jebane kurwy cebulaki.
>>     2020-09-04 19:48:56 EEST:
>>     CI37PA-20>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5051.97N/01543.24Eb masz,
>>     masz.
>>     2020-09-04 19:49:26 EEST:
>>     CI37PA-88>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5002.85N/02147.17Ec
>>     pomarancza kurwo niebieska.
>>
>>     Here's more, each source callsign emitted packets at random
>>     coordinates
>>     with comments from some pool of (obscene) text, so you can just
>>     pick one
>>     call and watch:
>>
>>     https://aprs.fi/?c=raw&limit=&call=CI37PA-9
>>
>>     I haven't looked at a large data set yet; these samples were from
>>     a very
>>     small set of a thousand packets that I took a quick look at now.
>>     These
>>     packets were injected using an igate call of SQ6KPO-1 but there's no
>>     reason why that could not be a random call in the future. Also,
>>     it would
>>     be *very* unlikely that SQ6KPO is the callsign of the person
>>     doing this
>>     abuse - it is more likely that the intention is to abuse him by

>>     using his
>>     callsign.
>>
>>     It's easy to write a client to do this kind of abuse, and easy to
>>     improve
>>     it (make more things random), and after that it's quite difficult
>>     to fully
>>     filter.
>>
>>     This is just to describe what happened, and what you should
>>     expect to see
>>     in the future. We've been lucky to have very little abuse and DOS
>>     attacks
>>     so far.
>>
>>        - Hessu
>>
>>
>>     _______________________________________________
>>     aprssig mailing list
>>     aprssig at lists.tapr.org <mailto:aprssig at lists.tapr.org>
>>     http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>
>
> _______________________________________________
> 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/31a24b5e/attachment.html>