Providing XMPP Trunking with M-Link Peer Controls

XMPP Federation

Standard XMPP servers are fully mesh federated. When two XMPP clients communicate, the first client talks to its local server which connects directly to the server used by the second client, as shown below.

This fully connected architecture has a number of benefits:

1. It minimizes the number of hops, with only two servers involved in communication.
2. It minimizes end to end latency, which is important for real time messaging.
3. Configuration is picked up from DNS, so there is no routing configuration.
4. For communication between a pair of clients, the number of failure points is minimized.
5. The trust chain between two clients is minimized.

Standard XMPP federation is designed for an open Internet environment, where it is the ideal approach.

Where Federation Causes Issues

There are a number of situations where this simple fully-meshed federated approach causes issues.

The number of connections between servers in a fully-meshed architecture grows exponentially with the number of servers. This provides efficiency in an open environment. In a secure environment, such as military, every server is going to be protected by firewalls and each connection with another server will have policy and configuration implications. In such environments, it is desirable to limit the number of connections and fully-meshed does not do this.

For cross domain scenarios, such as connections between international military organizations, all traffic needs to go through boundary systems that perform appropriate security checks. This does not work with a fully-meshed configuration.

XMPP Trunking Architecture

A Trunking architecture has sparse connectivity between servers. Traffic routing needs to be configured at each server to provide full connectivity and all of the servers involved need to follow the trunking model. This does not work with XMPP servers following the XMPP standards, which expect fully-meshed operation.

Trunking using M-Link Peer Controls

Isode M-Link provides a Peering Control capability, which was initially developed in support of boundary and cross domain configuration.

Peering controls allow messages to be routed to a specific peer on the basis of a number of criteria:

• Specified domain (e.g., isode.com)
• Domain and subdomains (e.g., *.us).
• Default route

This allows for a flexible trunked configuration to be established. Peer control use of wildcards and no DNS dependency means that trunking configurations will be straightforward to establish. M-Link Peer controls will have an associated policy, which can support message checks, such as security labels to be applied.

Alternatives to Peer Controls

Peer Controls are the approach used in M-Link to support boundary and XMPP trunking. It is possible that other XMPP vendors or open source implementations could adopt similar or different approaches to support XMPP trunking.

For “non leaf” nodes of an XMPP trunking configuration, it is clear that special product capabilities are required. For “leaf nodes” in an XMPP trunking configuration it is possible to use an XMPP server that implements standard federation. Two things are needed to achieve this:

1. Special DNS configuration for all of the XMPP domains that are communicated with (including domains behind a cross domain boundary). This needs to be done for each full domain, as there is no wildcard mechanism available. For each domain supported, including MUC domains, DNS SRV records needs to be set up that point at the desired “XMPP trunk” node. This means that when an XMPP address is looked up, the “leaf node” XMPP server will connect to the correct server.
2. For the “XMPP trunk” node which the leaf nodes point to (e.g., and M-Link with peer controls), the TLS certificate used for the server needs to include (as an appropriate X.509 SubjectAlternateName) all of the domains which are being used by “leaf nodes”. This is because when a leaf node connects to the XMPP trunk node, based on lookup of a domain, it will expect to find that domain in the X.509 certificate used by TLS.

For a large number of domains, this is potentially quite awkward to configure and maintain reliably, particularly TLS certificates with large numbers of SubjectAlternateNames.

Trunked Architecture Examples

A very simple trunked architecture is a star configuration. This is straightforward to set up with peering controls. A server which is a “point”, is simply set up with a peering control that routes traffic to the centre node. The centre node might be a core national node connecting a number of separate national services. The centre node will have a peering control to route traffic to the domains managed by each of the star points, and may also have peering controls to route to other domains, and in particular cross domain.

In a boundary architecture, peering controls will be used to route to edge servers that control and check traffic flowing cross domain. A typical boundary architecture is shown below, with core connected national nodes in blue.

The boundary architecture also needs to interact with XMPP configurations on either side of the boundary. The servers on one side of the boundary need to be configured to correctly route traffic to the boundary. Use of a trunking architecture supported by peer controls is a convenient way to do this.

Conclusion

The standard XMPP fully-meshed federation approach is a good design and is ideal for deployment of XMPP in the open Internet environment. In more constrained environments such a military deployments of XMPP, an XMPP trunking architecture is preferable. An XMPP trunking architecture can be supported by M-Link Peering Controls.