Proposal: the 'token' solution - Informal part

["Mario 'BitKoenig' Holbe" <Mario.Holbe@xxxxxxxxxxxxxxxx>]

Hi,

since Helmut 'delta' Springer - *.de BIC representant - seems to got
lost somehow, I need to release the proposal at myself acting as
part of *.de opers to keep my own deadlines :)


We all know about existing problems on IRCNet, so I don't
need to describe them here.

Viewing at this problems, 11 german IRC Operators met
at 02/12/2000 to discuss the problems, interferences and
possible solutions.

Here is one of them to discuss it in public.

We think that the network should work mostly without manual
interference of opers or services. This way there's neither
an easy way to manipulate things nor a personal responsibility
of the admin.

One of our big problems at the moment are attacks against
users to disconnect them and make them loose their state
(states interesting in here are channel related states -
voice, chanop, ...).
We know, there are other ones, but we need to solve some,
not only one and we need to solve them fast and this
solution ist a fast to establish one, so we concentrate on
this for the first.

The well known solution for this problem will be some kind
of persistent channel registry, which we (IRCNet) refuse for
serveral reasons (privacy, admin power, admin responsibility,
channel ownership, distributed database, religion ,).

Another solution to this problem might be an 'on the fly
channel registry' which allows user to regain his status
on reconnect after a 'bad' (collision, ping timeout, ...)
signoff for a short time.
This solution has the advantage of neither establish a
structure to own or control channels nor to store really
persistent data.

We call this solution a 'token' (we're not calling it
'Cookie' for obvious reasons). This token will be assigned
to a client and saves it's state, if it disconnects for some
unusual reason (everything except QUIT, Oper KILL, ?) and
lives for a short time (15 minutes?).
If the user comes back and requests the token, it will
restore the client state on the channels the client was
before and is now (server MODE changes).
The token has to be safe against guessing and DoS.
The token will be only local to the server, it has not
to be distributed to other servers, so no new server-to-
server communication has to be established.
The token solution gives no 100% solution for the takeover
problem - at least not for #channels and netsplits, but
it does for !channels and we loose nothing for #channels,
we'll win a bit for them but not 100%.

Implementation details, DoS and abuse concerns will be
discussed at ircd-dev@xxxxxxxx

We don't want to do this as just another ugly patch, we
want to establish it in the ircd upstream code and
release it as new ircd version.

Therefor this mail (thread) should establish an informal
discussion about that solution and should help to find out,
if such a solution will be accepted and used or not by
a majority of IRCNet admins.

We have a rough concept, we have designers to clean it,
we have coders to implement it, we have admins and users
to test it. What we need is a 'go', so we put up some
milestones for it. Here they are:
12/02/2000 meeting *.de opers, discussion
13/02/2000 first version of meeting protocol
15/02/2000 final version of meeting protocol released to *.de opers
17/02/2000 'token' proposal released to Beeth and discussion about it
18/02/2000 release of informal proposal to ircd-users
           release of technical proposal to ircd-dev
	   start of discussions
19/02/2000 start design phase
23/02/2000 finish design phase
           start implementation phase
25/02/2000 finish discussion
28/02/2000 final descision of Beeth to put it in upstream or not
20/03/2000 finish implementation phase
           start test phase
01/04/2000 finish test phase
04/04/2000 release of new ircd upstream version (if so)

We'd be glad, if we could reduce the time for the whole stuff of
course :)

I put up a website containing delta's first proposal released to
Beeth, this informational proposal and the technical proposal at
https://irc.tu-ilmenau.de/token/ and I'll try to keep it up to date
with every new information concering the token solution.

Now it's yours, what's your opinion about it?


regards,
   Mario, BitKoenig
-- 
Mario 'BitKoenig' Holbe <Mario.Holbe@xxxxxxxxxxxxxxxx>
http://WWW.RZ.TU-Ilmenau.DE/~holbe/

User sind wie ideale Gase - sie verteilen sich gleichmaessig ueber alle Platten