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

Wed Nov 2 22:06:36 GMT 2022

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20221102/7e5557f7/attachment.htm>