[jdev] Single host, multi service. -was [ANN] Google Talk engineering manager live chat

[Kevin Smith]

On 24 Sep 2005, at 22:35, Hal Rottenberg wrote:



>> If you want to run a MUC service on its own domain then you have  
>> to setup
>> the DNS entries, if you dont want to have to setup those entries  
>> then follow
>
>>> So, let's say you have the choice between two IM systems. One you  
>>> can
>>> double click an exe, wait 5 minutes and then it all "just works".
>>
>> What IM system would this be?, I find it hard to believe any IM  
>> system is
>> going to be externally connectable without some kind of DNS  
>> entries being
>> setup.
>
> Ooh, ooh I know this one!  Your server or workstation already has an
> external DNS entry.  The problem is that you've only got ONE.

RD has been saying for the last several mails that he agrees that it  
should be possible to run your muc services without an extra dns  
entry, I think. But there's a world of difference between running  
your muc server on the same dns entry as your jabber server, and  
pretending you have entries that you don't. For years there have been  
two different camps of people in the computing world. Those that say  
"well, this gives the users what they want, there are security  
implications, but it's unlikely anyone will find/abuse them" and  
those that have said "we must do this the Right Way(tm)". I'm firmly  
of the opinion that we should not be adding features which we know  
open security holes like this. We *know* that this adaption of the  
protocol creates a previously non-existent situation where stanzas  
may be sent to a malicious user. If we're all honest with ourselves,  
if anyone came up to us and said "I have a feature here that makes  
sysadmins lives easier and makes no difference to the user, except,  
by the way, it means that in the case of a temporary dns resolution  
failure potentially malicious servers can trivially impersonate us.  
Should I do it?" we'd be saying no faster than most people could draw  
breath. So I really think we shouldn't do it, any of us. The next  
question we'd probably ask is "isn't there another way?".

So...some people find it very difficult to set up a jabber server  
together with the associated components because of the quantity of  
dns entries required. What we need to look at (imnsho) is not how to  
fake the dns entries, but to remove the requirement altogether.

Let's please quickly agree that it's something to address, and that  
second-guessing dns entries isn't the way to do it. Then lets equally  
quickly address any problems with doing it such that any server  
implementors who're interested in providing services without this  
limitation can do so.

First point of discussion. Is there anything which this dns second- 
guessing provides us which having all our components on a single host  
doesn't? I think no, please discuss

Second point of discussion. Is there anything prohibiting us from  
having multiple components on a single host at the moment? The first  
few that come to mind are listed below, what others have I missed?

1) Programmers will have to stop making assumptions about jids based  
upon how they look and instead look at what they can do. Psi assumes  
that any jid without a user@ part is a service, it's filthy, it's  
always been filthy and we've always known it's been filthy. We do it  
because we can. It's not a good reason for not changing. When people  
start breaking the assumptions the coders have used for these rules,  
the code will be fixed. This isn't a good reason to not progress.

2) Name collisions. As has previously been noted, this is easily  
avoided through prefixes and there's probably much nicer methods.

3) Disco. Servers may end up supporting some (a lot) of features that  
you wouldn't expect. Who is this actually a problem for? If users go  
browsing the disco entries for the server they may be suprised by  
some of the entries but realistically how many users go browing the  
server disco? Sysadmins do and they won't be suprised by their own  
entries. Is there a technical problem with this? Tijl asked this in  
the other thread so I'm continuing the asking in this (newly broken)  
one. If there's no technical problem, there's no problem here.

4) JEP-045. I've just been through the muc jep, and I can't find  
anything which prohibit it sitting on the main server. The pertinent  
lines seem to be:
---
# Each room is identified as <room at service> (e.g.,  
<jdev at conference.jabber.org>), where "room" is the name of the room  
and "service" is the hostname at which the multi-user chat service is  
running.
# Each occupant in a room is identified as <room at service/nick>, where  
"nick" is the room nickname of the occupant as specified on entering  
the room or subsequently changed during the occupant's visit.
# A user enters a room (i.e., becomes an occupant) by sending  
presence to <room at service/nick>.
---
To me, none of these seem to be an issue beyond the previously  
mentioned (avoidable) collisions.
Have I missed anything.

Sorry for the silly length of the email, but it covers one point I  
feel quite strongly about (implementing known security holes), and  
another that has previously frustrated me (the multiple dns entries  
thing) so I'd like to see these things addressed.

/K


--
Kevin Smith
Psi Jabber client maintainer (http://psi.affinix.com/)
Taekwon-do club captain (outgoing), University of Exeter
Postgraduate (PhD) Research Student, Computer Science, University Of  
Exeter