<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Do your embedded systems run over IP or RF or both?</p>
<p>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.</p>
<p>As for LoTW being the CA, I'd caution that maybe we don't want a
singular organization to control the PKI.<br>
</p>
<p>- Dave/ad8g<br>
</p>
<div class="moz-cite-prefix">On 9/7/2020 12:23, Scott Miller wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7509a074-6649-fcde-2ef7-bbe2cbb635e2@opentrac.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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.<br>
<br>
Scott<br>
N1VG<br>
<br>
<div class="moz-cite-prefix">On 9/5/2020 10:07 AM, Mobilinkd LLC
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEox9HFyGTVbqQ87uM+wJuf9YM9kDf0oSAZpSqAmJyjH7s+5WQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="ltr">
<div>Would it be worthwhile discussing whether to use PKI for
APRS-IS authentication?<br>
</div>
<div><br>
</div>
<div>I just discovered that there is a registered X.509
extension for ham radio callsigns and that we already have a
CA in LOTW.</div>
<div><br>
</div>
<div><a
href="https://perens.com/2019/07/02/yes-it-is-legal-to-use-cryptographic-signature-on-amateur-radio-and-thats-important/"
moz-do-not-send="true">https://perens.com/2019/07/02/yes-it-is-legal-to-use-cryptographic-signature-on-amateur-radio-and-thats-important/</a></div>
<div><br>
</div>
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">Kind Regards,<br>
<br>
Rob Riggs WX9O<br>
Mobilinkd LLC<br>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Sep 5, 2020 at 6:15
AM Heikki Hannikainen <<a href="mailto:hessu@hes.iki.fi"
moz-do-not-send="true">hessu@hes.iki.fi</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">On Fri, 4 Sep 2020, Bill
Vodall wrote:<br>
<br>
> Is aprs-is under a Denial of Services attack by jankesi
and others?<br>
> Looks like multiple packets arriving every second.<br>
<br>
The packet rate during the DOS abuse event last night was
some 1500-1700 <br>
packets per second at peak.<br>
<br>
<a
href="https://www.dropbox.com/s/tztvaup286vzwnb/aprsfi-polish-abuse-20200904-traffic.png?dl=0"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.dropbox.com/s/tztvaup286vzwnb/aprsfi-polish-abuse-20200904-traffic.png?dl=0</a><br>
<br>
Some APRS-IS clients on the full feed could not take this
traffic (too <br>
slow to process, or too slow network, buffers fill up) and
got <br>
disconnected. As a network traffic rate, it was only around
1.4 Mbit/s sec <br>
though. Due to a bug, the two APRS-IS data aggregator aprsc
instances at <br>
<a href="http://aprs.fi" rel="noreferrer" target="_blank"
moz-do-not-send="true">aprs.fi</a> crashed too, leaving <a
href="http://aprs.fi" rel="noreferrer" target="_blank"
moz-do-not-send="true">aprs.fi</a> without a data feed.<br>
<br>
This is how it looked on the map, screen shot courtesy of
Mateusz Szyper <br>
on the <a href="http://aprs.fi" rel="noreferrer"
target="_blank" moz-do-not-send="true">aprs.fi</a>
discussion group:<br>
<br>
<a
href="https://www.dropbox.com/s/5wbjtttkkw1munh/aprs-polish-abuse-20200904-map.jpg?dl=0"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.dropbox.com/s/5wbjtttkkw1munh/aprs-polish-abuse-20200904-map.jpg?dl=0</a><br>
<br>
And here are a few sample packets, showing what the randomly
generated <br>
packets looked like. The coordinates are random, in Poland,
with the <br>
clear intention of polluting the map fully.<br>
<br>
2020-09-04 19:48:27 EEST:
CI37PA>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5031.68N\01844.35EZ
jeszcze nie dojrzalem.<br>
2020-09-04 19:48:46 EEST:
CI371PY-3>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5248.72N/01933.83EX
sie draznic z ludzmi.<br>
2020-09-04 19:45:58 EEST:
CI37PA-21>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5411.38N\01600.85E-2
Jebane kurwy cebulaki.<br>
2020-09-04 19:48:56 EEST:
CI37PA-20>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5051.97N/01543.24Eb
masz, masz.<br>
2020-09-04 19:49:26 EEST:
CI37PA-88>APDR16,WIDE3-3,qAC,SQ6KPO-1:=5002.85N/02147.17Ec
pomarancza kurwo niebieska.<br>
<br>
Here's more, each source callsign emitted packets at random
coordinates <br>
with comments from some pool of (obscene) text, so you can
just pick one <br>
call and watch:<br>
<br>
<a
href="https://aprs.fi/?c=raw&limit=&call=CI37PA-9"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://aprs.fi/?c=raw&limit=&call=CI37PA-9</a><br>
<br>
I haven't looked at a large data set yet; these samples were
from a very <br>
small set of a thousand packets that I took a quick look at
now. These <br>
packets were injected using an igate call of SQ6KPO-1 but
there's no <br>
reason why that could not be a random call in the future.
Also, it would <br>
be *very* unlikely that SQ6KPO is the callsign of the person
doing this <br>
abuse - it is more likely that the intention is to abuse him
by using his <br>
callsign.<br>
<br>
It's easy to write a client to do this kind of abuse, and
easy to improve <br>
it (make more things random), and after that it's quite
difficult to fully <br>
filter.<br>
<br>
This is just to describe what happened, and what you should
expect to see <br>
in the future. We've been lucky to have very little abuse
and DOS attacks <br>
so far.<br>
<br>
- Hessu<br>
<br>
<br>
_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org" target="_blank"
moz-do-not-send="true">aprssig@lists.tapr.org</a><br>
<a
href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org" moz-do-not-send="true">aprssig@lists.tapr.org</a>
<a class="moz-txt-link-freetext" href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" moz-do-not-send="true">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<a class="moz-txt-link-freetext" href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a>
</pre>
</blockquote>
</body>
</html>