Subject: [Nel] A small document for your consumption

From: Vincent Archer <[email-masked]>
Date: Fri, 13 Apr 2001 11:34:53 +0200

While waiting for the whole load, here's a quick and short document. Look
at it, and critique your hearts out...

Client server connect

This document describes quickly the connection process of a client to a world
running a NeL-based system.

Abbreviations
-------------

LS: The login service (one overall)
WS: The welcome service (one for each world)
FES: The front-end service (N per world)

Steps
-----

1: The client initiates a connection to the login service, using the supplied
   IP and port from the configuration file, with the help of the DNS for IP
   resolution.

   Note: DNS spoofing or configuration file modification can lead to LS
   spoofing and hacking of the login/password information of the client.
   However, DNS is needed for flexibility of the login service location.

2: The client submits its login, password, and system capabilities.

3: The LS checks the login/password validity, and builds the list of all
   available worlds according to account information and current system
   settings. This list contains world names and the IP for the WS of that
   world.

   Note: DNS is not used in that step.

4: The client selects the world it wants to log on, and submits the IP address
   of its world service to the LS.

5: The LS sends a notification to the selected WS of the client's connection
   desires. It generates and submits a single-use cookie to validate the
   incoming connection.

   Note: The cookie includes the client's IP, as seen by the LS (to avoid
   address translation problems) for validation.

6: The WS selects a FES to accept the client connexion, and submits the cookie
   to the FES.

7: The FES acknowledges its capacity to accept the client to the WS.

8: The WS acknowledges its capacity to accept the client to the LS, and
   indicates the IP/port of the selected FES.

9: The LS acknowledges the login request to the client, and indicates the
   IP/port of the selected FES.

10: The client disconnects from the LS.

11: The client initiates a connection to the indicated FES.

12: The client sends the submitted cookie to the FES.

13: The FES validates and acknowledges the cookie.

Side notes
----------

Whenever a world starts, the WS establishes a permanent link with the LS,
using an encrypted link (it is assumed that the LS and WS are located on two
physically and probably geographically distinct networks). A 'SHARD' message
serves as authentification, and the WS then updates the LS with its state,
name and IP address. The WS may have a list of valid IP/port address for WS
to avoid the occasional pirate server registration.

-- 
Vincent Archer                                         Email: [email-masked]

Nevrax France.                              Off on the yellow brick road we go!

---

From: Thierry Mallard <[email-masked]>
Date: Mon, 16 Apr 2001 21:59:43 +0200

>    However, DNS is needed for flexibility of the login service location.

Possibly this can be partially avoided by providing your own DN Server's IP ?
(dunno precisly how the client would connect to it, but still...)

> 2: The client submits its login, password, and system capabilities.

In plaintext ?

>    settings. This list contains world names and the IP for the WS of that

Maybe the use of challenges would be more secure, but i'm not a specialist in
this matter :-(

>    of its world service to the LS.

Would it be good if the client could select several worlds ?
(then the negociation following could use this to get a good WS)

> [...]

I wonder if it couldn't be more interesting if the client disconnects from LS
_after_ having initiated the connection to the FES. Then, if something goes
wrong, the client could goto 4 directly.

Best regards,

-- 
Thierry Mallard              | http://vawis.net
GnuPG key on wwwkeys.pgp.net | http://erlang-fr.org (new)
key 0xA3D021CB               | http://worldforge.org

---

From: Thierry Mallard <[email-masked]>
Date: Tue, 17 Apr 2001 08:33:31 +0200

>    desires. It generates and submits a single-use cookie to validate the

The LS <--> WS connection should be studied, perhaps ?
(if it wasn't intended in this document, then let's see that later.. ;-) )

[ *err.. ok i just read the end on the original mail, just forget it* ]

> 7: The FES acknowledges its capacity to accept the client to the WS.

So the WS is (or can be?) a load-balancer to all the FES in a given world ?
-- the balancing being done at network level, not process level --

> 13: The FES validates and acknowledges the cookie.

IMHO, as said in the other mail, the client should then disconnect from the
LS ; not before. The downside I see in this case would be the extended time of
connection (steps 11 et 13), which will lead to more network load. I don't see
how important that would be.

> Side notes

ok, so i should have read the whole document before arguing ;-))

Hope this helps..

---

From: Vincent Archer <[email-masked]>
Date: Tue, 17 Apr 2001 12:27:13 +0200

I'll answer both posts at the same time...

> (dunno precisly how the client would connect to it, but still...)

There are two ways you can find out a server:

1) Hardcode the IP address (then, you cannot move the server)
2) Use DNS for dynamic IP (then, the hardcoded address is the root of the
	DNS tree - which, hopefully, changes even less often than we will)

You can't specify your "own DNS". Using that is basically the same as
using method 1: you still have to put a server at a static IP that gives
you off the dynamic IP.

> > 2: The client submits its login, password, and system capabilities.

If we assume the link has a crypt method in it, why not.

Three possible methods for password submission

1) Plaintext, assuming the connection has a form of crypt in place
2) MD5/crypt password. Spoofable, since:
	a) You can capture the MD5/crypt string
	b) You have the client source, so can hack it to send the static
		crypted password instead of crypting the - unknown - plaintext
3) MD5 for a dynamic challenge. A good example: the server sends you the
	current date when you connect, and you use that date as the first
	bytes of the MD5 digest.

> (then the negociation following could use this to get a good WS)

Not good. Typically, the client will connect to the world the player has
a character he wants to play today :)

However, the client may use the IP addresses of the WS to ping them and
figure out which connection is better (when selecting its first world).

> -- the balancing being done at network level, not process level --

The WS *is* the load balancing mechanism. Since he's aware of all FES
up and running, and knows their load right now, he's best suited to
determine which FES can afford to manage a new character.

> wrong, the client could goto 4 directly.

Hmmm, that might be good, yes.