Hi,
I've been working on a massive hosting XMPP service and trying to get
my head around the operational problems that the current S2S rules
introduce. Basically, for each domain hosted (and in our case they
include services for MUC, FT, and PubSub per hosted domain), we need
8 TCP connections for bi-directional communications per pair of local-
remote domains, worst case. Even with modern kernel event TCP APIs,
it adds up.
I've worked out a small proposal that I would like to get feedback
on. It would change S2S to use a lot less TCP while keeping the
certificate-based security.
Concepts used in the text:
* XMPP domain: a domain used by a XMPP service, either for C2S or
other services like MUC, FT, and PubSub;
* XMPP host: a system of one or more servers that host XMPP domains.
Each XMPP host will have a DNS name. For example, My.ISP could have a
XMPP host named xmpp.my.isp.
Each XMPP domain hosted at My.ISP would use xmpp.my.isp in their DNS
SRV records. For example, saramago.lit would announce the following
SRV records:
_xmpp-server._tcp.saramago.lit. 600 IN SRV 5 0 5269
xmpp.my.isp.
_xmpp-server._tcp.chat.saramago.lit. 600 IN SRV 5 0 5269
xmpp.my.isp.
_xmpp-server._tcp.ft.saramago.lit. 600 IN SRV 5 0 5269
xmpp.my.isp.
_xmpp-server._tcp.pubsub.saramago.lit. 600 IN SRV 5 0 5269
xmpp.my.isp.
A XMPP domain pessoa.lit (hosted at another XMPP host named
xmpp.other.isp) also has equivalent records.
When pessoa.lit wants to communicate with saramago.lit, the following
protocol would be used:
1. pessoa.lit XMPP host, xmpp.other.isp, establishes a XMPP stream
with xmpp.my.isp. The current spec is used but the domains used in
the stream handshake would be xmpp.other.isp and xmpp.my.isp.
this first step would create a secure, authenticated and, given
proper certificates for both xmpp.my.isp and xmpp.other.isp, a
trusted connection between the two XMPP hosts. Using improvements to
the protocol discussed previously in this list, this stream could
even be a bidirectional stream over a single TCP connection.
2. XMPP host xmpp.other.isp then sends a XMPP domain stream
activation request. It generates a random key, signs it with
pessoa.lit certificate and encrypts it with saramago.lit certificate.
Then it sends this request to xmpp.my.isp.
3. XMPP host xmpp.my.isp decrypts the request and checks the
signature of the random key. If the signature matches, it signs the
key with saramago.lit certificate, and encrypts with pessoa.lit
certificate. This response is sent to XMPP host xmpp.other.isp.
4. XMPP Host xmpp.other.isp decrypts the response with pessoa.lit
certificate and checks the signature using saramago.lit certificate.
If the signature matches, the channel between saramago.lit and
pessoa.lit is deemed trusted and ready to be activated.
5. XMPP host xmpp.other.isp sends a activate stanza with both
domains. The channel is now active bi-directionally.
This process can be execute multiple times per connection between the
two XMPP hosts, supporting multiple domains in the same connection.
This protocol will radically reduce the number of TCP connections a
XMPP host will need to support multiple domains, while keeping the
certificates-based security in place. The problem is that it's not
backwards compatible. It would require a new _xmpp-federation._tcp
(just a suggestion) record. This is required because the initial
domain in the XMPP stream is not the destination XMPP domain but the
destination XMPP host name.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
