nick collide prevention ideas

[m de`jour <b4y2k@xxxxxxxxxxxx>]

I am not a subscriber to this list, so not being that familiar with the scope
of topics here, I can only hope I am reasching some of the intended target
audience, those with input to changing and modifying the ircd code.  If
another list is more appropriate, please feel free to forward.

Please bcc any comments and replies to me also, as I will not receive replies
to these lists.

-----------------------
This outlines several possible techniques to reduce abusive mass nick
collides.  My experience relates to IRCnet and some ideas are net-specific I
suppose, but others are general in nature.

There are peices of several different potential solutions.  As I was writing
about some ideas I have thought much about, a couple new, totally different
ideas came to me.  I added them at the bottom.  They just popped into my head
so I did not have time to think them thru but offer them for others to build
upon if promising.  Actually, these newer ideas seem simpler to implement and
would appear to be quite effective.  but I am not a net tech, just an irc
addict tired of wars, and collides seem to be the abuse of choice for the clan
kiddies.

Credits:
Few things are unique, revolutionary, and much "new" knowledge is simply an
incremental change from prior knowlege.  Parts of my overall ideas came from
the works of others, such as the new "un-collidable" !channels on IRCD2.10.x [
http://www.ircnet.org/channel_docs/pling.html ] and also the draft by Beeth [
http://akson.sgh.waw.pl/~chopin/uniqueID.txt ]

-------------------

Would some of the following ideas perhaps reduce nick collides?
[/me lives on IRCnet without TS]

suggestion:
Test for characteristics of collide conditions.  If any exist
then don't allow self-service pick-a-nick and/or exact nick
changes until collide conditions are abated.

Perhaps test for some or a combination of things like:
server reboots
or
server is split
or
total server count is < xx [some preset value]
or
queue is huge
or
lag is high
or
many kills [ or recent kill history as sometimes the same server
connects and collides over and over before someone intervenes
and conditions are corrected.
or
or ? [fill in whatever fingerprints might be used] 
or ? [as a profile that would match as many]
or ? [typical probable collide scenarios as possible] 

If such monitoring indicates any or a predefined combination of
characteristics exist that match "collide conditions", then when
a client either connects or requests a new /nick abcd1234

then:
if nick requested is < 7 char, server would add 3 random
characters
if nick requested is > 6 char, server would truncate to 6 then
add 3 random characters.

Alternately, if the nick length was increased to allow for
longer -server set- nicks, the server might force expand all
nicks to 9 characters if shorter, then add 3 random characters. 
for /nick able  server would expand it to able-----x\^.  Users
would not be able to request nicks over 9 characters.  Only
servers could set longer nicks, doing so when said collide
conditions exist.

simple trigger:
if net has 70 servers, then if servers-connected < 70, turn off
pick-a-nick and force all new nick requests to partial-random.

After collide conditions abate, users would then be allowed to
pick-a-nick normally.

When the server forces nicks to random, could others, with nick
watchers, then signal their clones or others to copy that random
nick and then lag collide?  Not if all servers enforced the
pick-a-nick lockout when "collide conditions exist" and detected
elsewhere.  Some allowances might be made for sick servers that
are juped, and if they had the pre-server connect client
connection test described below, perhaps they would satisfy some
concerns.

If when server detects general collide conditions, it would
force all new nick request to random, making it highly
improbable to match a target.  Matching many as in a large
channel, so as to collide all ops at the same time would seem to
be numerically improbable.  Process could be tested with a very
narrow set of profile conditions, even if it would only be
partially effective and then, after refining the process,
gradually broaden the profile parameters to include more
conditions while trying to avoid unnecessary restriction on
selection of specific nicks.

------------

Use the same technique colliders use to cure the problem.

The collide-kiddies have clients on both sides of a split.  Use that same
method against them, make an integrated client type connection to test the
waters before making the actual server connection.

This additional option might be to make a client connection before
the server connection and do a comparison on a random sampling
of nicks.  Perhaps, on some splits [< 5 servers?], have server
do whois on some or all clients connected to it via a client
type connection to one or more primary hub[s] on main side of
split before connect.  returns indicating an excessive number of
collides would occur on connect, would cause a mass forced nick
change to random prior to server connect.

Or the pre-server connect test client could stream a list of
nicks to the other side, like a /names list, which would merely test for
"ifexist". 
The large side would usually focus on nicks of ops, if possible, as it would
seem the most common abusive tactic is to use one or a few split
servers to collide ops on the main part of the net.  The
usa/europe link also seems to be a problem area as for IRCnet,
creating two rather large sides when split.
  
If an excessive percentage of the nicks on one side of the split
match those on the other side, force nick change to random
before connect.  If a disconnected server has 183 clients
connected, it would ask /whois nick for each of those 183 nicks
on main side hub[s] [or a random sampling of them], to see if
collisions would occur on connect.  If so, force nicks to random
before connect.  It may well be that someone on the large side
is targeting a lone op on the small side for collide.

Also, the hosts of such nicks could be logged for later review
by ircadmin.  If it appears a user was intentionally trying to
collide with 30 clones from the same host, etc., ircadmin could
change I line to allow less connections, change I line to i
line, remove i/I line and/or add k-line if appropriate.

===============================


New ideas...  hold the presses... seems much simpler but as I am
just conceiving it as I write, it is not thought through.. flame
me but be gentle ;)

1] Expand nick length to min. 15 characters, 
2] if user selects nick over 9 characters, all characters >9 are
forced to random by the server.

Is that simple enough?  collide proof nicks available on demand
and optional and so simple.

If someone wants an exact nick, they are free to pick any
available nick up to 9 characters.  If they want collide
protection, they simply request a 10-15 character nick.  The
server would assign the 10th - 15th characters at random.

  command /nick abcdefghi would be set exactly as requested, if
available.

however, if the user wanted nick collide protection, they could
request a 10-15 character nick, knowing and accepting that all
characters > 9 would be changed and set randomly by the server.

  command /nick abcdefghijklmno would be set by the server to
something like abcdefghi_6`Dh

The server would randomize all character > 9, IF any are
requested.  No one has to request or be assigned these random
nicks.  It would be an optional enhancement for those that
wanted the collide protection it offered.  the 1st 9 always stay
as requested with the user having no control over the 10-15th
characters.  near as I can count there are 43 valid characters
for nicks, I think ;) since there seems to be some confusion
that ^ = `? and [={ and ]=} for case matching, at least in my
mind.
If my feeble math is correct 3 rndchar > 80k; 6 rndchar > 6
billion. 

The 1st 9 character would stay as requested so finding a nick on
the channel nick list would remain easy as the nick would always
be alphabetically where expected.  For whois and notify
functions, the test could return all wildcard matches using the
characters given.  Notify may present problems but hey.. user
have the choice of being collide proof or visible on notify.. 
If they select the collide proof mode, they are probably in a
channel as an op where others would know where to look for them.


Pardon me but I'm brainstorming and creating as I write this..
;)

Also, there would be no need for lockout on quit of nicks since
those that wanted collide protection would accept changing,
partially random nicks.  On each connection, the server would
assign a new random nick.  No more lockout for short nicks
perhaps.  No TS, No locked out nicks,  Nirvana ;)  I have to be
overlooking something big I know.  It can't be this simple.

If a user wanted a long collide resistant nick, he could request
a 10-15 character nick at anytime, knowing that the server would
force all characters > 9 to random.  very little else need be
done.  These do not have to be totally unique to be effective. 
The general problem is colliding huge numbers of ops in large
contested channels.  If one or two lag collides occur from
someone trying by brute force nick request hoping to match the
random nick assigned to another, he might succeed matching a few
nicks a year, but never enough to collide a channel full of ops
at the same time.

--------------------

Also, if any of this makes since and a change in nick-length is
contemplated, it might be an appropriate time to consider
increasing the nicks available to users also.  allowing users to
choose 12 of 15 characters would still allow the 13-15th
characters to be forced to a random pool of over 80k possible
variations.  allowing user 12 and adding 6 would provide over 6
billion random nick variations on each base nick.

So, why not start allowing user-selected nicks greater than 9
characters?  that is not integral but since this idea would
require longer nicks anyway, it might also be considered.

Lets be bold, and let user select nicks up to 15 characters [as
to IRC-net which is now limited to 9]

Then add 5 random character spaces making the total 20.  Lets go
for broke and make it 20.. ;)  unless that presents too much
server loading.. ??

===================

additional alternatives:

also add a new command to ircd:  /rnick for random nick

This /rnick function would assign a totally random nick of 9 characters.

It would begin with a number.

Read that somewhere ;) Beeth I think - this leading digit part is not my own
orignal idea but neat..  and the /rnick function comes from a script I just
started testing.  Putting both functions together might well be the simplest,
easiest method to implement a satisfactory solution to mass collides.

Users could not request a specific nick starting with a number. 
Only servers would be able to assign nicks starting with digits
and all would be totally random 9 character nicks - all
beginning with a digit.  


those wanting collide protection merely request /rnick on
connect and they accept whatever the server assigns.

--------------------

for this to work, the strong anti-bot sentiment in some quarters
would need to be softened.  Non-abusive defensive chanserv
clients and bots should not be targeted because they chose to
take advantage of this increased collision protection
technique.  Being pragmatic, bots are needed for basic community
protection and survival on IRCnet.  Building a chat community requires
stability and consistancy.  IMHO, bots are the only practical way to provide
that on non-register nets like IRCnet.

If this is effective, perhaps fewer bots would be needed.
Now the primary threat is nick collides for which raw number
is the best means of survival.

If collides are controlled, DoS attacks on ops will possibly increase. :\
but raw numbers of connections are not needed for that,
only a number of different servers.



____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.