[Dxspider-support] Network v2.0 - A PROPOSAL FOR DISCUSSION

[Luigi Carlotto IK5ZUK]

Hello Kin,
your proposal is very interesting!I think it should be a good idea to 
switch to a more secure network.

BTW it is important to know the opinion of the two software's 
developers, Dirk and Lee...

73 Luigi IK5ZUK

Il 16/09/2022 09:40, Joaquin via Dxspider-support ha scritto:
> Hi all,
>
> We have all seen the offensive spots that have been being sent to the 
> Net. Others know that in WW contests, malicious spots are sent in 
> order to cause the disqualification of an operator or team in that 
> contest. We also know that if an authentication policy is not applied 
> in our nodes, this will continue to happen and the sysops will always 
> follow behind trying to block the alleged offenders, but not only are 
> we late because the spot has already spread, in addition, the spotter 
> is usually an unassigned callsign or worse still, from an operator 
> that is not the one that actually sent that garbage. The bad thing is 
> that we block those operators without knowing if they are the cause.
> We also know that many of the nodes are not updated, so new features 
> and bug fixes are not applied to them. This makes it impossible for 
> the current network to evolve to a more secure and reliable one.
>
> How can progress be made without the collaboration of the sysops 
> community? An answer to this question may be this draft:
>
> Let's say the current Network is v1.0 and the new one will be called 
> v2.0.
>
> The Network v1.0 remains as it is today.
> The new Network v2.0 would be an evolution of v1.0 in such a way that 
> a series of functions would be incorporated:
> 1. Every connection (user-node, node-node) would be with 
> login/password authentication to be able to use the sending of 
> information.
> 2. The information of all users and nodes will always be at least 
> username, password, email if they are registered/validated.
> 3. Passwords will be stored encrypted (eg in MD5).
> 4. In order for a user registered/validated by a sysop on your node to 
> access any other v2.0 Network, this information will be sent to all 
> v2.0 nodes.
> 5. In the case of DXSpider, the current logging mechanism should allow 
> sending an email to the sysop.
> 6. A new command should be included that allows the sysop to send a 
> message (email) indicating that a certain user who is registered in 
> the v2.0 Network has broken the rules and that he proposes that he be 
> blocked/eliminated from the nodes.
>
> For both networks to cohexist initially:
> v2.0 <-> v2.0. Network v2.0 nodes with other v2.0 nodes will send and 
> receive the same information as they do now.
> v2.0 <-> v1.0. In the case of Network v1.0 nodes that connect to v2.0 
> nodes, the former will continue to function as before, but v2.0 nodes 
> will only maintain the link up, receiving the spots, ann, .. ., but 
> since v2.0 spots will not be sent, ann, ...
> v1.0 <-> v1.0. The interconnection between nodes of the Network v1.0 
> was safe as before.
>
> The idea is that the v1.0 nodes converge on the v2.0 Network without 
> being isolated, progressively disappearing when they realize that they 
> do not receive all the spots and their software is not updated.
>
> From a developer point of view, I think it would be possible to use 
> newer PCxx and CCxx with less impact if current software can be 
> adapted. And with some modifications for the current v1.0. But it is 
> still a job that takes time and effort.
>
> For this to work, the involvement of cluster developers and sysops is 
> necessary, especially those that have more users and therefore can 
> exert indirect pressure to promote change.
>
> What do you think of this proposal?
> Possible improvements?
> Infeasibility?
> Alternatives?
>
> Regards.
>
> Kin EA3CV
>
> sysop EA3CV-2, EA4URE-2,3,5
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support