[Dxspider-support] Forgeries

[IZ2LSC]

We are all senior developer with AI!
At least you agreed that what you proposed for partner identity is not a
solution against the flooding.
Perhaps do you also agree about the need to record the spot path?

73

Andrea

-->


On Wed, Mar 12, 2025 at 12:42 PM Rudy Bakalov <r_bakalov at yahoo.com> wrote:

> You apply different strategies to the two different use cases- one use
> case is partner identity and second is spots rates. Don’t mix the two.
>
> Rudy N2WQ
>
> Sent using a tiny keyboard.  Please excuse brevity, typos, or
> inappropriate autocorrect.
>
>
> On Mar 12, 2025, at 4:09 AM, IZ2LSC <iz2lsc.andrea at gmail.com> wrote:
>
> 
> Rudy,
> following your example:
> //
> 1/ Cluster A has defined SSID N2WQ-1 with FQDN cluster.n2wq.com as
> partner
> 2/ Cluster A receives a telnet connection request and the other party
> claims it is N2WQ-1
> 3/ Cluster A resolves the FQDN for N2WQ-1 to IP
> 4/ If the connection request from whoever claims to be N2WQ-1 originates
> from the resolved FQDN, the connection is accepted and partner handshake
> sequence begins
> 5/ Otherwise Cluster A drops the connection.
> //
>
> Now suppose that you are the sysop of Cluster A and I'm the bad guy
> managing N2WQ-1.
> Once I get your trust, I start flooding using N2WQ-1 as an intermediate
> node. Consider that as sysop of N2WQ-1 I can easily modify this node to
> accept everything, even forged spots.
> And you as Cluster A sysop you are fully convinced that N2WQ-1 is trusted
> so maybe the flooding is injected by someone else downward connected to
> N2WQ-1.
> And actually this is exactly what is happening today. We have an entry
> point and we are not able to identify it.
> What we lack, and I already raised this point months ago, is an
> effective way to track the path of each spot to get close to the source.
> Something like AS-PATH in BGP or Via header in SIP.
>
> 73s
>
> Andrea
>
> -->
>
>
> On Wed, Mar 12, 2025 at 2:20 AM Rudy Bakalov via Dxspider-support <
> dxspider-support at tobit.co.uk> wrote:
>
>> 1/ Cluster A has defined SSID N2WQ-1 with FQDN cluster.n2wq.com as
>> partner
>> 2/ Cluster A receives a telnet connection request and the other party
>> claims it is N2WQ-1
>> 3/ Cluster A resolves the FQDN for N2WQ-1 to IP
>> 4/ If the connection request from whoever claims to be N2WQ-1 originates
>> from the resolved FQDN, the connection is accepted and partner handshake
>> sequence begins
>> 5/ Otherwise Cluster A drops the connection.
>>
>> The FQDN acts like a shared key. It doesn’t need to be secret. Simple and
>> elegant.
>>
>> Rudy N2WQ
>>
>> Sent using a tiny keyboard.  Please excuse brevity, typos, or
>> inappropriate autocorrect.
>>
>>
>> On Mar 11, 2025, at 6:43 PM, Dirk Koopman via Dxspider-support <
>> dxspider-support at tobit.co.uk> wrote:
>>
>> 
>> There is no auth scheme that I can think of right now that does not
>> involve some kind of secret sharing between nodes. If we are going to go
>> down that road then we may as well just do the job properly and start to
>> use PKI SSL connections with each node connection pair giving each other a
>> PKI pair. We *may* be able to share the public keys around but we will need
>> to fiddle about with client PKI certs because each side needs to verify the
>> other. But that will result in a separate network of nodes that will trust
>> each. Then we will get the howls of protest about all those juicy "missing"
>> spots from outside this new (more) secure network.
>>
>> More knowledgeable information to square this circle gratefully received
>> (offline please).
>>
>> Dirk
>>
>> On 10/03/2025 19:12, Christopher Schlegel via Dxspider-support wrote:
>>
>> Nevermind. Theory, was not well thought out and I keep hitting
>> roadblocks...
>>
>> Chris, WI3W
>>
>> On Mon, Mar 10, 2025, 10:06 Christopher Schlegel <sutehk.cs at gmail.com>
>> wrote:
>>
>>> Dirk,
>>>
>>> How hard would it be to implement a hashed check into the PC92 protocol.
>>> I.e. I log into WI3W-2, receive a randomly generated number/string used to
>>> verify tx/rx between the user and node. Kind of like pub/priv keys but only
>>> to generate the check. As long as the check is valid keep the connection,
>>> if not, boot it.
>>>
>>> Or, something similar. Spot validation? I'd expect CPU processing to
>>> tick up a little, but most machines in use should not choke.
>>>
>>> 73,
>>>
>>> Chris, WI3W
>>>
>>> On Mon, Mar 10, 2025, 09:45 Mike McCarthy, W1NR via Dxspider-support <
>>> dxspider-support at tobit.co.uk> wrote:
>>>
>>>> A small number of nodes, yes, but with about 1/4 of the total users of
>>>> the global cluster network. VE7CC-1 alone has over 800 on any given day.
>>>>
>>>> On 3/10/2025 8:29 AM, Dirk Koopman via Dxspider-support wrote:
>>>>
>>>> > Which means that input from the CCluster/ARCluster system would
>>>> > disappear as they are still using the same protocol as we are and
>>>> > therefore just as untrusted as anyone else. Their big advantage is
>>>> that
>>>> > there are a relatively small group of nodes with an author (or other
>>>>
>>>> --
>>>> 73 de Mike, W1NR
>>>>
>>>> THAT was the equation. EXISTENCE!... SURVIVAL... must cancel out...
>>>> programming!
>>>>
>>>> - Ruk -
>>>>
>>>>
>>>> _______________________________________________
>>>> Dxspider-support mailing list
>>>> Dxspider-support at tobit.co.uk
>>>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>>>>
>>>
>> _______________________________________________
>> Dxspider-support mailing listDxspider-support at tobit.co.ukhttps://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
>>
>> _______________________________________________
>> 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/20250312/7a0b8f91/attachment-0003.htm>