[Dxspider-support] Some information

[IZ2LSC]

Let me clarify my position once for all because I see some speculations and
I'm not happy with that.

I'm in favor of a more secure network in fact I've already shared some
ideas, but:

1) I think that the way the senderverify is implemented today could be
easily bypassed by an attacker with medium-low knowledge about how the
cluster network works, so IMHO this alone would not prevent the issue.
2) The cost of what I consider an ineffective measure (point 1) is that we
are now dropping legitimate spots just because we cannot "verify" the
spotter callsign because it is behind a CC cluster. And we are not talking
about peanuts.

If we are all fine dropping the majority of the spots coming from CC
cluster then that's fine. But keep in mind that this is like separating the
2 networks.


73s

Andrea, iz2lsc


-->


On Sat, Feb 22, 2025 at 10:46 AM Iain Philipps <iain.philipps at 77hz.net>
wrote:

> What Keith says is the way forwards.
>
> Dirk has produced an appropriate mechanism for flagging / dealing with
> unverified spots. It **SHOULD** be responsibility of every sysop to
> verify those spot(ters) before passing the traffic forwards.
>
> Yeah – it’s not a banking application that requires high security – but
> just imagine if Google (other providers are available) decided to allow
> unverified users to send Emails. (YES! I know there are people there
> making fake accounts … most like just the same as there are here. But
> that’s a different issue.
>
> What I don’t get is the reluctance of (some) SysOps (regardless of
> software platform they’re running on) to deal with this in a responsible
> way.
>
> I’m done now.
>
>
>
>
> 73 de WR3D
>
>
>
> *From:* Dxspider-support <dxspider-support-bounces at tobit.co.uk> *On
> Behalf Of *Keith, G6NHU via Dxspider-support
> *Sent:* 22 February 2025 08:52
> *To:* iz2lsc.andrea at gmail.com; The DXSpider Support list <
> dxspider-support at tobit.co.uk>
> *Cc:* Keith, G6NHU <g6nhu at me.com>
> *Subject:* Re: [Dxspider-support] Some information
>
>
>
> This needs to be fixed by the nodes that are not reporting their users,
> it’s network evolution to maintain security and we need to stop pandering
> to sysops who won’t update or who are using software that doesn’t properly
> protect the network.
>
> 73 Keith G6NHU
>
> On 22 Feb 2025 at 08:44 +0000, IZ2LSC via Dxspider-support <
> dxspider-support at tobit.co.uk>, wrote:
>
> I collected the % of unverified spots received by my node in 24 hrs during
> a normal "peaceful" working day.
>
> This is the result.
>
>
>
>
> https://drive.google.com/file/d/1wSCPqdDAu4wF0_syKZkzArgCDZ-gxBFK/view?usp=sharing
>
>
>
> So if we really decide to drop unverified spots (that most of the time are
> real spots, not fake or forged) we are going to drop a lot of spots.
>
> I can understand this as a countermeasure during an attack.....but not
> during normal operations.
>
> Just a consideration about the side effects.
>
>
>
> 73
>
> Andrea, iz2lsc
>
>
>
>
> -->
>
>
>
>
>
> On Fri, Feb 21, 2025 at 8:07 PM Kin via Dxspider-support <
> dxspider-support at tobit.co.uk> wrote:
>
> Hi,
>
> I have been analysing how a CC Cluster node behaves with pc9x supposedly
> enabled, to see the suspect filtering.
>
> The only thing that seems to work correctly is PC92K, which only reports
> the
> node itself.
> The PC92A does not show all user connections and none from a partner.
> The PC92D does not show all user disconnections.
> The PC92C is not generated.
> I don't understand the point of generating some PC92s and not all of them.
> I think it would be better not to generate any if you can't generate them
> all. This would avoid ambiguities in the network.
>
> It is clear that with incomplete information, a CC Cluster will be greatly
> affected by filtering. But the vast majority (if not all - 1) do not use
> PC92 like ARC, DXNet and AK1A, all their users' spots will be flagged as
> suspicious.
>
> Have a nice weekend.
>
> Kin EA3CV
>
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20250222/e20e7b8b/attachment.htm>