[quake3-bugzilla] [Bug 4045] New: Servers cannot be reliably identified

[bugzilla-daemon at icculus.org]

http://bugzilla.icculus.org/show_bug.cgi?id=4045

           Summary: Servers cannot be reliably identified
           Product: ioquake3
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P3
         Component: Misc
        AssignedTo: zakk at icculus.org
        ReportedBy: bugzilla at benmachine.co.uk
         QAContact: quake3-bugzilla at icculus.org


This has been brought to my attention while I was working on the master code
for Tremulous attempting to get compatibility with IPv6: if a server sends
heartbeats on both IPv4 and IPv6 addresses, there doesn't seem to be any way of
checking that these are in fact both the same server, and hence the client is
more or less obliged to list it twice.

An idea I discussed on the IRC channel the other day was the addition of a
sv_guid to be sent in infoResponses: if two servers have the same GUID, list
them once, perhaps with some indication of the multiple available interfaces.
The problem with this becomes more or less immediately obvious when you
consider the potential for abuse, where a griefer can take a server's GUID and
copy it in their own infoResponses and hence the client is faced with the
difficult problem of choosing which to display (or both). There was an idea to
hash the GUID with the client or server's IP, but both of these suggestions
destroy the original benefit of the commonality across IPv4/IPv6. People have
even suggested some kind of asymmetric encryption method, with the drawbacks of
requiring the exchange of at least 4 packets of larger-than-usual size, and the
difficulty of finding an implementation of the relevant algorithms that doesn't
require extra build dependencies or huge source files.
Other ideas are only sending the GUID to the master, which then has some way of
deciding which address to send to the client, or some method of indicating that
one server has two addresses. This poses a security problem but sounds a
reasonable solution so long as it can be done without breaking protocol
compatibility. Or a server could put all its addresses into its infoResponse,
and they could then be merged only be mutual agreement (which suffers a little
from the complexity of resolving grouped servers and the extra response string
spam).

-- 
Configure bugmail: http://bugzilla.icculus.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.