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

[Ian Maude]

Hi Dirk et al,

Are we saying then that v2.0 has registration set as standard?  I really feel that this should be the case.  As someone who was there when Dirk implemented it during 9/11 (How many updates did you release that day Dirk?) and has been using it ever since on 2 cluster nodes, it is really no problem once you are on top of it.

A couple of small things I would like to see improved around registration though.  If a user asks for registration, it would be nice to be able to set/reg and get a response if the user is already registered.  That would save having to do stat/user to check every time.  Quite a lot of HRD users in particular think that if they reload their software, then they have to ask for registration again for some reason.

Again with HRD, there is a check box in the cluster options to increment the SSID if a user loses connection and then cannot log back in because the cluster thinks they are still there.  Whilst I understand the reason for this option, it breaks the registration as each SSID is deemed as a separate user for registration.  I wonder if registration could cover all SSID’s or even if this is a good idea?

As for stat/user, it would be nice to see if a user is *not* registered or does not have a password set.  Currently, nothing is shown for either if they are not implemented.  I really am. A ’show me either way’ type of guy (put it down to age).

The issue is of course, how to ‘persuade’ v1.0 nodes to upgrade to v2.0 as some sysops just seem to set up a node because they can and then don’t seem to bother with it as long as it runs.

Just a few thoughts

73 Ian

> On 2 Nov 2022, at 22:06, Dirk Koopman via Dxspider-support <dxspider-support at tobit.co.uk> wrote:
> 
> Most of this is achievable and/or a reasonable idea.
> 
> However, there are some things that I won't do, for a variety of reasons:
> 
> I WILL NOT distribute login information around the network. However one does it, it has a number of security risks associated with it. It's simply not going to happen. PS Even if it were, it certainly wouldn't be MD5 hashes.
> What I can do (and will implement) is a new PC41 type 6 message which will be structured like all the others PC41^6^user call^registration node call^user IP address[:IP address...]^H99. This will be sent on registration and on the next (configurable) 3 logins. Additional IP addresses will also cause PC41s to be sent. Thereafter they will be sent when a 'forward/opernam' command requests it using RCMD, or by the periodic, automatic process that (currently) happens for every user that has the node as the homenode - and now will happen if they are registered as well. This will change to every (configurable) 3 months (as opposed to the current 12 months). If any user has not logged onto node within the last (configurable) 12 months, then registration is cancelled. Nodes will also prune out known registered users if they have not seen a PC41 for a similar period. Anyone not seen in the last 36 months will be removed completely (in theory this happens already - but I am wondering whether it is actually working).
> The fact that a user has been registered on another node will be noted in the user file, BUT it will *STILL* mean that a user will need to register on this node. In other words: a registration on another node, that has been notified by PC41, is there to provide some confidence that data purporting to come from a known user on a known node and known IP address is probably OK. It also improves analysis and detection, after the fact, if something bad happens. 
> There has to be some "grit" in the system, so that bots will find it difficult to automate registration. I am open to suggestions, but forcing the sysop to confirm a registration they have been automatically been sent (either as SP or email) to them after a new registration request from a user, and the sysop then doing a manual 'set/register' for that user will certainly slow the bots down :-) But I am also happy to consider other, bot unfriendly, suggestions. 
> Suggestions for dealing with existing (long time) users will be gratefully received. 
> There will be NO AUTOMATED method of one sysop de-registering a user on the rest of the (new) cluster. Period. The whole business of deciding who is doing what to whom and then deciding if and at what level any sanction happens, is just a can of worms. There are some obvious things that happen that we could agree on, but how one goes about coordinating actions by independent sysops is difficult to impossible make happen.
> I'm not certain how one deals with the changeover to v2.0, given that the majority of spots and anns will still come from v1.0 - and this is important - committed DXers really don't care; just so long as they see the spots. Maybe add a single letter marker to user displayed version of the comment (S for suspicious or D for dubious?).
> One thing that I have noticed is that several spots/anns lately have the same comment sent by different calls. The "duplicates" could be intelligently deduplicated just by comment...
> 
> My 2 cents worth...
> 
> 73 Dirk G1TLH
> 
> On 16/09/2022 08:40, Joaquin via Dxspider-support wrote:
>> 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 <mailto: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/20221103/5658858b/attachment-0001.htm>