[standards-jig] About outgoing packets.

Evan Prodromou evan at gaff.bad-people-of-the-future.san-francisco.ca.us
Sun Mar 16 20:38:28 UTC 2003

On Fri, Mar 14, 2003 at 04:12:09PM -0700, Peter Millard wrote:

> Edwin Zacharias wrote:

> > I understand why Jabber's stream protocol is used for
> > packets sent to you, but why is it used for sending
> > packets out?  Since you know the host for a user, such
> > as hamlet at denmark.gov, why not just connect directly
> > to denmark.gov and send it there?
> Yes, so it keeps clients simple, and it allows all packets from "serverA" to
> "serverB" to be multiplexed over a single TCP socket.

There are also various authenticity reasons. Currently Jabber uses
dialback authentication, which leverages the DNS system, to make sure that
packets labelled as being from Somebody at example.com really are coming
from the Jabber server for example.com. In turn, the Jabber server at
example.com uses password or other forms of authentication to make sure that
I'm Somebody.

In pictorial form:

   +------------------+                        +------------------+
   | Jabber server at |------------------------| Jabber server at |
   | example dot com  |                        | denmark dot gov  |
   +------------------+  authenticated by DNS  +------------------+
	    | authenticated by password
   | Client for       |
   | Somebody         |
Because of this authentication, if the server at denmark.gov receives a
packet along this pathway, they can be reasonably sure that the packet comes
from Somebody at example.com. (It's not foolproof, of course -- if the server
at example.com is buggy or compromised, it could send inauthentic packets.
But at least everyone would know that you can't trust stuff from example.com.)

If the client connected directly to the Jabber server for denmark.gov,
there'd have to be some other way to authenticate that they are who they say
they are. Such as...

     * Just forgetting about authentication. Caveat jabbor.
     * Have some kind of PKI system so that the client sends
       cryptographically signed packets.
     * Have some kind of password or credentials passthrough, where the
       client has to send authentication info to the denmark.gov server,
       which in turn passes them to the example.com server, which says
       whether they're OK or not. This is a pretty bad system.

So, all that said, it seems like a pretty good system -- both for sockets
frugality and for authenticity.


More information about the Standards mailing list