Trouble in IMland

Stephen D. Williams sdw@lig.net
Tue, 15 Jan 2002 15:48:18 -0500 (EST)


> It seems to me that the great unspoken issue with IM is firewalls,
> which force all communiations to go through third parties.
>
> The fact that a large proportion of users are 'protected' from
> receiving incoming connections is a huge centralising force on the
> internet, and one which makes IM protocol developers jump through all
> kinds of hoops to deal with bulk traffic. If users could directly
> connect to each other, then centralised servers would only be needed
> for naming and presence information.

Absolutely.  Unfortunately, the trend for a number of reasons (spam,
'illegal' media trading, gaming traffic, desire to monopolize, desire to
charge more for 'servers') is to increase this.  Oddly, AOL is one of the
few ISP like entities that don't seem to tend to block incoming anything.

The home situation isn't as bad as corporate access though.  There are only
three things that consistently are allowed:

Outgoing http/https everyhwere but sometimes with restrictions (no java,
javascript, perm cookies, any cookies),

Ftp incoming always, outgoing sometimes.

Outoing TCP connections.  Much less allowed, but not unusual and generally
considered safe from external attacks but an easy way to compromise data by
insiders.


There is an elegant solution to all of this that I have proposed before:
distributed interchange servers.  The idea is that if you have a server that
supports rendevous, presence, pub/sub, media streaming and replication (one
to many broadcast) and other operations and you: A) make it open source, B)
get nearly every ISP to install and support, with C) some large corporate
support, you can solve many of these problems better than if you had
incoming access.  In other words, if you follow the model of distributed
email servers but with vastly more intelligence and semantics for advanced
communications methods, you can take Internet applications to the next level.

I'm very interested in designing and building this kind of server ability.
Again, you can see how it would work but getting to critical mass will be
difficult.  Any ideas about a legal killer app strategy would be
appreciated.  I'm very sure that this needs to be open source to succeed,
but there will be opportunities to charge for the service, traffic, addons,
etc. in some situations.


> I dont know if you ever took a look at TriangleBoy from SafeWeb, but it
> seemed to me that they had the kernel of an interesting idea; that is,
> to enable the direct connection between two parties via an intermediary
> that handled only the signalling part of the traffic between the two
> comminicating parties. Their protocol was one-way, it enabled http
> requests to be made of sites nominally blocked by filtering software.
> You connected to the intermidiary and made your request, the
> intermediary forwarded the request to the desitination with the return
> address spoofed to be the original requester. In this way only the
> requests and ACKs needed to be handled by the intermediary.

I did look at it, and it's very cool.  I don't believe it will work
everywhere, but it's certainly thinking along the right lines.

>
>>From a security standpoint, I dont see a whole lot of difference
>>between two consenting parties directly communicating and two
>>consenting parties communicating via an intermediary. I am not a
>>security expert, however.

It creates an explicit middle for potential man in the middle attacks.  If
you are safe from that, there is no difference.  If you aren't, you are
completely trusting the middleman.  Of course we trust many middlemen now:
phone companies, ISPs, banks, lawyers, etc.

>
> I do wonder if perhaps there might not be some firewall friendly
> mechanism by which an intermediary can facilitate the direct connection
> of two firewall protected parties. Neither party can recieve a
> connection, but both can initiate connections. Maybe the intermediary
> can facilitate this direct connection in a similar way to that of
> TriangleBoy.
>
> Im no expert in TCP, UDP or whatever, but perhaps someone on this list
> is and can think of a way to do this.

It just occurred to me at 4am last night that you might be able to spoof
this with ftp since nearly all firewalls allow incoming TCP connections for
FTP once they are requested by the ftp session.  The problem is that you
have to setup the connection to the same system you would be getting the
connection from so that doesn't help much.


> > ----------------------------------------------------
> Damien Morton, Technical Director, Dennis Interactive
>
> "Why is the moon more important than the sun?"
> "Because we need the light more at night!"
> -- Nasredin


sdw
-- 
sdw@lig.net http://sdw.st
Stephen D. Williams
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax Dec2001