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

Danilo Brelih danilo.brelih at siol.net
Thu Nov 3 08:34:28 GMT 2022 

I 
asked for a feature request with developers at the N1MM+ logging program as written below. 

Hi 

Given the high number of abuses of the dxcluster network in the last period many sysops are making it mandatory to register on dxcluster systems in order to send spots to the network. Unregistered users will be able to receive spots normally but will not be able to send them. As a sysop myself I use a password to access the system I maintain also. The idea is to add a password field in the N1MM+ Telnet, Clusters, Options window under the field marked "Logon with". Only users with a password set on the dxcluster system use the password field. For those who do not (yet) use a password, it would be desirable to add a ticked "No password required" by default checkbox. Thanks, Dan S50U sys S50CLX 

GL Dan S50U 

----- Dne 3. Nov. 2022 ob 09:15 je The DXSpider Support list <dxspider-support at tobit.co.uk> napisal(a): 

> 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
>>> 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/20221103/7bfb087e/attachment-0001.htm>

More information about the Dxspider-support mailing list