[Dxspider-support] Secure node to node connection proposal

Mikel EA2CW ea2cw at gautxori.com
Sun Feb 26 11:16:49 GMT 2023


Thank you, Andy

I am simulating that kind of scenery at a local network, with 3 dxspider 
nodes and 2 cc-cluster nodes. Only 2 of the dxspider's are secured 
(using also ssh tunnels) and the rest only allowed to watch.

The key words you've used is "acceptable level of accuracy" . When 
running contests, I don't like to S&P after unaccurate spots, making me 
wasting time I could use to earn points.
I don't like -of course- DXSummit, but there is just a bit easier to put 
a fake spot using it than into the "normal" cluster net

73 and thanks again, Mikel

El 26/02/2023 a las 12:06, g4piq--- via Dxspider-support escribió:
> I run a cluster which is optimised to meet the needs of groups of contesters
> who I'm in various teams with (GB7MRS). It's actually currently isolated (in
> the traditional usage of set/isolate) from the rest of the network until I
> get round to implementing a local spot and global spot option.
>
> I think the only way that Mikel's proposal would work would be to have a new
> 'clean' network - with the sorts of controls which Mikel suggests, and a
> 'dirty' network - that looks like we have today (and is probably actually
> the existing network less those who leave to join the 'clean' one.)
>
> As a competitive contester - I want to receive the maximum number of spots
> received with the minimum latency with an acceptable level of accuracy. I
> would be happy to run a cluster with enforced registration and even
> passwords to send spots and to connect to the clean network. But I would
> also connect it to the 'dirty' network with an incoming hop count of 1 (I
> assume that is supported) to ensure my users saw all spots, but none were
> passed onto the rest of the clean network.
>
> BTW - my sense is that the big source of trouble is from DXSummit - that
> feels like the open gate which  needs addressing.
>
> 73
>
> Andy, G4PIQ
>
> -----Original Message-----
> From: Dxspider-support <dxspider-support-bounces at tobit.co.uk> On Behalf Of
> Iain Philipps via Dxspider-support
> Sent: 26 February 2023 09:44
> To: 'The DXSpider Support list' <dxspider-support at tobit.co.uk>
> Cc: Iain Philipps <iain.philipps at 77hz.net>
> Subject: Re: [Dxspider-support] Secure node to node connection proposal
> Importance: High
>
> This will be a GREAT way to shrink the cluster network.
>
> There are a  SIGNIFICANT number of SysOps who don't have the time to manage
> hundreds of users and passwords.
>
> This is *AMATEUR RADIO* not online banking. I understand we need to do
> something about the "spam", but alienating / disenfranchising SysOps is a
> *VERY* bad plan.
>
>
> 73 de WR3D
>
> -----Original Message-----
> From: Dxspider-support <dxspider-support-bounces at tobit.co.uk> On Behalf Of
> Mikel EA2CW via Dxspider-support
> Sent: 26 February 2023 09:36
> To: Keith Maton via Dxspider-support <dxspider-support at tobit.co.uk>
> Cc: Mikel EA2CW <ea2cw at gautxori.com>
> Subject: [Dxspider-support] Secure node to node connection proposal
>
> After a lot of hours with some sysops already here, I have wrote down a
> first proposal of the first -small- step we could take, rising a bit the
> node 2 node connections. Again, this is only a basic document to start, not
> an absolute and unique true.
> I expect to have an good open discussion among all us to define and agree
> the path to a better dx-cluster net.
>
> NODE<>NODE SECURE CONNECTION CRITERIA:
>
> 1. Unregistered users can connect and view spots, they cannot upload any
> info into the network.
>
> 2. Registered users can login, view and also upload spots, anns, etc.
>
> 3. All registered users must have a password. Registered users without
> password would not be acceptable.
>
> 4. All nodes to which the node is connected must meet the same requirements.
>
> 5. The connection between nodes must be between registered nodes and with
> password, that is:
>       - set/spider [node]
>       - set/reg <node>
>       - set/password <node>
>       - set/password <node> <password>.
>       (The /spider/connect/<server> files must be modified so that the
> password is used).
>
> 6. If possible, the connection between nodes should be made via ssh or other
> secure mechanism. (Already testing a ssh tunneling protocol with
> success)
>
> 7. The connection to the RBN servers is optional from each server, but the
> received RBN spots will not be forwarded to other nodes.
>
> After -I hope- achieving an agreement, I would want to start a net where all
> the clusters connected meet the agreed conditions.
> I ask you the sysops whom already meet them or with this aim, to contact me
> and other partners in the same position for a -probably- slow but firm
> evolution.
>
>
> POSSIBLE NEXT STEPS IN THE FUTURE
>
> * A protocol should be designed within the dx-cluster standard to share
> hashed passwords between nodes, avoiding the need to register multiple times
> the same user in different nodes and reducing the maintenance tasks of each
> sysop. This information, i.e. (user:hash:origin_cluster) could be later be
> broadcasted around the net and/or being also distributed via config files as
> we already do, i.e. with bad IPs, and stored on each node.
>
> * The connections of identified nodes / users to any node should be made
> always using secured connections. No more telnet usr/pwd open transmissions
> should be allowed.
>
> * The secure connection system should be implemented as a part of the server
> programs (as telnet is now) avoiding the added complexity of creating
> tunnels between each pair of servers. This system could be used for secure
> connection between nodes as well as for connection and identification of
> users, who could continue to access in an insecure way -without the ability
> to upload information to the network. It would keep the connection system of
> the current client softwares unchanged.
>
>
>
> Hope we can discuss all this among us, securing the future of an open, safe
> and not hierarchically structured. This philosophy is IMHO the one that has
> kept alive the dxcluster network during so many years/decades.
>
> Thank you and 73 de Mikel EA2CW
>
>
>
>
> --
> ea2cw at gautxori.com
> Bilbao, Bizkaia. IN83MG
> http://radio.gautxori.com
> http://qrz.com/db/ea2cw
> https://t.me/EA2CW
>
>
> _______________________________________________
> 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

-- 
ea2cw at gautxori.com
Bilbao, Bizkaia. IN83MG
http://radio.gautxori.com
http://qrz.com/db/ea2cw
https://t.me/EA2CW




More information about the Dxspider-support mailing list