<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Rudy, </div><div>following your example:</div><div>//</div><div>1/ Cluster A has defined SSID N2WQ-1 with FQDN <a href="http://cluster.n2wq.com/" target="_blank">cluster.n2wq.com</a> as partner<div>2/ Cluster A receives a telnet connection request and the other party claims it is N2WQ-1</div><div>3/ Cluster A resolves the FQDN for N2WQ-1 to IP</div><div>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</div><div>5/ Otherwise Cluster A drops the connection.</div></div><div>//</div><div><br></div><div>Now suppose that you are the sysop of Cluster A and I'm the bad guy managing N2WQ-1.</div><div>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.</div><div>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.</div><div>And actually this is exactly what is happening today. We have an entry point and we are not able to identify it.</div><div>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.</div><div>Something like AS-PATH in BGP or Via header in SIP.</div><div><br></div><div>73s</div><div><br></div><div>Andrea</div><div><br></div><div><div dir="ltr" class="gmail_signature">--></div></div><br></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Mar 12, 2025 at 2:20 AM Rudy Bakalov via Dxspider-support <<a href="mailto:dxspider-support@tobit.co.uk">dxspider-support@tobit.co.uk</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"><div dir="auto"><div dir="ltr">1/ Cluster A has defined SSID N2WQ-1 with FQDN <a href="http://cluster.n2wq.com" target="_blank">cluster.n2wq.com</a> as partner<div>2/ Cluster A receives a telnet connection request and the other party claims it is N2WQ-1</div><div>3/ Cluster A resolves the FQDN for N2WQ-1 to IP</div><div>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</div><div>5/ Otherwise Cluster A drops the connection.</div><div><br></div><div>The FQDN acts like a shared key. It doesn’t need to be secret. Simple and elegant.</div><div><br></div><div>Rudy N2WQ</div><div><br id="m_2941978396387300667lineBreakAtBeginningOfSignature"><div dir="ltr"><div><span style="background-color:rgba(255,255,255,0)">Sent using a tiny keyboard. Please excuse brevity, typos, or inappropriate autocorrect.</span></div><div><br></div></div><div dir="ltr"><br><blockquote type="cite">On Mar 11, 2025, at 6:43 PM, Dirk Koopman via Dxspider-support <<a href="mailto:dxspider-support@tobit.co.uk" target="_blank">dxspider-support@tobit.co.uk</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<div>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.<br>
<br>
More knowledgeable information to square this circle gratefully
received (offline please).<br>
<br>
Dirk<br>
<br>
On 10/03/2025 19:12, Christopher Schlegel via Dxspider-support
wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">Nevermind. Theory, was not well thought out and I
keep hitting roadblocks...
<div dir="auto"><br>
</div>
<div dir="auto">Chris, WI3W</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Mar 10, 2025, 10:06
Christopher Schlegel <<a href="mailto:sutehk.cs@gmail.com" target="_blank">sutehk.cs@gmail.com</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">
<div dir="auto">
<p dir="ltr">Dirk,</p>
<p dir="ltr">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.</p>
<p dir="ltr">Or, something similar. Spot validation? I'd
expect CPU processing to tick up a little, but most
machines in use should not choke.</p>
<p dir="ltr">73,</p>
<p dir="ltr">Chris, WI3W</p>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Mar 10, 2025,
09:45 Mike McCarthy, W1NR via Dxspider-support <<a href="mailto:dxspider-support@tobit.co.uk" rel="noreferrer" target="_blank">dxspider-support@tobit.co.uk</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">A
small number of nodes, yes, but with about 1/4 of the
total users of <br>
the global cluster network. VE7CC-1 alone has over 800 on
any given day.<br>
<br>
On 3/10/2025 8:29 AM, Dirk Koopman via Dxspider-support
wrote:<br>
<br>
> Which means that input from the CCluster/ARCluster
system would <br>
> disappear as they are still using the same protocol
as we are and <br>
> therefore just as untrusted as anyone else. Their big
advantage is that <br>
> there are a relatively small group of nodes with an
author (or other <br>
<br>
-- <br>
73 de Mike, W1NR<br>
<br>
THAT was the equation. EXISTENCE!... SURVIVAL... must
cancel out... <br>
programming!<br>
<br>
- Ruk -<br>
<br>
<br>
_______________________________________________<br>
Dxspider-support mailing list<br>
<a href="mailto:Dxspider-support@tobit.co.uk" rel="noreferrer noreferrer" target="_blank">Dxspider-support@tobit.co.uk</a><br>
<a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" rel="noreferrer noreferrer noreferrer" target="_blank">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a><br>
</blockquote>
</div>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Dxspider-support mailing list
<a href="mailto:Dxspider-support@tobit.co.uk" target="_blank">Dxspider-support@tobit.co.uk</a>
<a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" target="_blank">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a>
</pre>
</blockquote>
<br>
<span>_______________________________________________</span><br><span>Dxspider-support mailing list</span><br><span><a href="mailto:Dxspider-support@tobit.co.uk" target="_blank">Dxspider-support@tobit.co.uk</a></span><br><span><a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" target="_blank">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a></span><br></div></blockquote></div></div></div>_______________________________________________<br>
Dxspider-support mailing list<br>
<a href="mailto:Dxspider-support@tobit.co.uk" target="_blank">Dxspider-support@tobit.co.uk</a><br>
<a href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support" rel="noreferrer" target="_blank">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a><br>
</blockquote></div>