[Dxspider-support] Forgeries

Wed Mar 12 11:41:52 GMT 2025

 Here's a detailed concept for implementing a high performance rate limiting algorithm: https://claude.ai/share/bf9a3aef-a4c7-4ae0-8c18-d3d4c972ae81
Rudy N2WQ
    On Wednesday, March 12, 2025 at 04:09:17 AM EDT, 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 partner2/ Cluster A receives a telnet connection request and the other party claims it is N2WQ-13/ Cluster A resolves the FQDN for N2WQ-1 to IP4/ If the connection request from whoever claims to be N2WQ-1 originates from the resolved FQDN, the connection is accepted and partner handshake sequence begins5/ 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 partner2/ Cluster A receives a telnet connection request and the other party claims it is N2WQ-13/ Cluster A resolves the FQDN for N2WQ-1 to IP4/ If the connection request from whoever claims to be N2WQ-1 originates from the resolved FQDN, the connection is accepted and partner handshake sequence begins5/ 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 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

_______________________________________________
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/249d3117/attachment-0003.htm>