[crossfire] new metaserver
Brendan Lally
B.T.Lally at warwick.ac.uk
Fri May 27 12:04:49 CDT 2005
>>>
tchize at myrealbox.com
05/27/05 16:25 PM >>>
>
MM this doesn't look like what i had in mind during irc chat.
Ok, it is pretty close to what I believed you were thinking though (with a few modifications suggested by Rednaxela and TechII).
Let's see how what you suggest is different, then look at which ways your formal proposal is superior to what I have done currently.
>
Here is my
>
analysis of problem (no implementation done yet):
>
Problem:
>
Metaserver currently down
>
Reason:
>
DOS attack (polluted server list?)
>
Solution: Revise protocol
Concurred.
>
Things to care about:
>
- DOS resistance and prevent list pollution
>
- Redundancy to avoid downtime and easiness of redundant node creation
>
- Reliability of data
Yes, these are good properties to have.
>
- redundant node should be able to be hosted on any web enabled isp (no
>
active script)
In my system that is called a 'passive' node and can be used by the client, but not the server.
>
Analysis of current metaserver behavior:
>
Currently, when a public server starts, it registers to the metaserver, using
>
a simple protocol. It provides a server address, a description and a name.
>
After, it updates the metaserver on a regular basis to inform it about
>
current number of players. The metaserver keep track of servers for about one
>
day. This protocol is subjet to several limitations:
>
- Somebody could register lots of fake servers (DOS) resulting in client
>
having to download a huge list of servers.
yes, this has happened. The way I got round that is to try and connect to the reporting server, if they deny the connection, they aren't a real server.
>
- Somebody could register a server, faking another server, to gather
>
passwords.
Yes, this is justification for resolving the hostname properly.
>
- If the server crash and re-register to metaserver, old entry is not deleted,
>
resulting in pollution of list when a server is unstable.
Yes, this is currently an issue, iff the ip address changes
>
- The informations from metaserver can not be trusted in any way.
Why not?
>
- If metaserver crash, no client can see a list of servers
This has been partially resolved already, by Ryo's server cache patch.
>
- udp/ip used for registering make it easy to do impersonate ips (attacker
>
potentially untrackable)
Yes, although TCP isn't much better, web server logs can be helpful though.
>
The proposition i'll make to create a new handling for metaserver will address
>
all those limitations.
>
Prevention of fake servers and list pollution, limitations on DOS:
>
The list of public servers is something quite static. > Unless when used for
>
testing purposes, if someone starts a public server this is for at least a
>
few week. For this, i suggest the addition of server to the metaserver list
>
be something needing manual metaserver admin intervention. The sourceforge
>
bugtrack allows the creation of new named bugtrack lists. This is currently
>
the case for RFE (request for enhancement). I suggest to create a new buglist
>
named Server. This list will be used by server admins to request for the
>
register of their server in the metaserver list. Metaserver admins would then
>
check the validity of entry and process the registration. We could also
>
perhaps configure this list to request user authentification by sourceforge.
>
The request must contain the servername, the server ip address or dns address
>
(dynamic dns should be tolerated), the server admin email address, a server
MWedel pointed out that if you have a need to resolve the DNS name of the server then the implementation is more complicated, this is an assessement I am inclined to agree with.
>
public description.
>
Redundancy:
>
The list of servers would be made available in a serverlist file, available on
>
the metaserver root node. This list file will be downloaded on a regular
>
basis by mirror nodes. The client could connect either to the root node,
>
either to a mirror node to grab the list of public servers
Ah, there is a problem with allowing clients to connect to the root node. If they can connect directly, then it might get attacked/overwhelmed by requests. It seems better to hide the metametaserver/root node out of sight, behind a firewall where no one can attack it.
>
Trust of metaserver datas.
>
Because of replication between nodes, there should be a way to ensure the list
>
has not been tampered (preventing someone to fake a server). The client
>
should have a list a public keys corresponding to the keys of metaserver root
>
node admins. The server list must always be signed by a root metaserver node
>
admin, probably the one doing the manual update and client would check the
>
signature of list before using it.
At best you are bringing GPGME in as a dependancy, at worst you are creating a nightmare for key distribution.
What happens in the root node/metametaserver changes?
the keys that were used presumably are not in the hands of the new operators. Possibly something could be done with signing the new keys and fetching from a keyserver, but this is where the key distribution nightmare comes in.
>
DOS resistance:
>
The client should be always shipped with an uptodate static list of
>
metaservers and list of servers. If root metaserver node is down, meaning the
>
list of metaservers can not be found, client use cached metaserver list to
>
grab a mirror metaservers. If it can't connect to any metaserver, it uses the
>
cached server list and diplay it to user.
ok, how would that tie in with Ryo's cached server list?
>
Overall client process:
>
- get the metaserverlist from sf if possible and check signature. If anything
>
fails, fallback to cached list. If cached list fail, fall back to static list
You seem to be using the terms cached list and static list ambiguously, maybe I'm not following very well, which list is which, and where do you get them from?
>
- connect to a random metaserver in lsit and process a GET for the url listed
>
in the metaserver list. If this fail, or signature check fails, process to
Do you make crossfire illegal to run in some countries doing that? I think that there are probably some places that ban encryption altogether, and if not, there might be soon.
>
another metaserver.
>
- update cached metaserver list
>
- if all metaservers fails, process with cached server list and if it fails,
>
process with the static server list.
>
- update cached server list
>
- for each server in list, eventually connect to it and grab it's current
>
statistics (number of players, uptime, aso)
hold up, am I understanding that right? you want to connect to every server listed, with every player?
I'm not sure that would scale up too well...
>
Replication process:
>
This is quite easy, each mirror node just has, on a regular basis, to download
>
a specific file from root node and publish it. This could be done on any
>
linux box with a wget <root node> followed by an ftp <isp url>, the box
>
executing the mirroring script does not have to be the one serving the files.
>
(ie i can run a script twice a day on my dsl connected linux box to publish
>
the mirrored file to
http://users.skynet.be/tchize/server.list,
i don not
>
need my dsl linux box to be permanently connected (just twice a day).
a passive node can do that quite happily, an active node can do the same if it can run php.
>
Drawbacks:
>
metaserver does not keep anymore statical informations on server. Clients are
>
supposed to gather such information themself (note this is a quite common
>
behavior for first person shooter games)
Do they really do that? I would've thought they might get the ping times, but that is something somewhat different. (should clients get the ping times of servers, it might be useful information?)
Having said that, I don't play that many fps games, so wouldn't really know.
>
process of adding a new public server is a bit slow (wait for admin approval
>
and then replication)
My implementation is quicker to propagate (on average 0.5*update interval for the server chosen) - actually better than that, but the maths is complicated enough to stick to the high estimate.
It also allows the description or version to change without manual intervention.
>
Advantages:
>
DOS resistant
>
No single point of failure (isp's are quite difficult to DOS and even if all
>
metaserver are under heavy load client can still rely on on cached datas)
>
Server list can be trusted.
>
Mirror can be put on most ISP (personal web spaces gracefully provided by
>
provider)
my implementation allows all of these, even the last one partially (for passive nodes)
one exception, the metametaserver is a point of failure, but it is only so for the metaservers, not the rest of the system, and changing the metaservers should be easy. (compared to changing all the clients)
I am cautious of the excessive verification idea, if although contacting multiple servers for their metaserver list may be a good idea, since then one hostile server would get outvoted.
Furthermore, since the hostile server would get outvoted, it would be exposed as being disproportionatly outvoted, unless half the network were compromised, and then there are bigger problems.
how to propagate such information is an interesting question, or even whether such information /should/ be propagated.
More information about the crossfire
mailing list