Summary

Military communication makes extensive use of text chat services, in particular those using IRC (Internet Relay Chat) and XMPP (eXtensible Messaging and Presence Protocol). The primary approach is use of group chat services to share information. These services are often deployed in hostile environments, and so it is important that they are resilient and will continue to operate when elements of the service fail. Communication needs to operate between partners and across security boundaries (Cross Domain).

This whitepaper looks at distributed deployment of XMPP and IRC services and in particular how resilient deployments and Cross Domain operation can be achieved.

Creative Commons License

Background

A lot of the background to this paper can be found in a companion whitepaper [Interconnecting XMPP and IRC] that covers:

  • Overview of IRC and XMPP.
  • How the Isode M-Link XMPP/IRC Gateway operates, and the benefits of this approach and how it enables easy operation, maximizes security and functionality capabilities for local XMPP users, and provides a solid migration approach from IRC to XMPP.

That paper looks at operations using standard XMPP MUC (Multi-User Chat). Federated MUC (FMUC) is a new standard, which federates MUC rooms together over multiple nodes, operating much more like an IRC channel. This is described further in the whitepaper [Federated Multi-User Chat: Efficient and Resilient Operation over Slow and Unreliable Networks].

Mixed FMUC and IRC Deployment

The following diagram shows how the Isode IRC/XMPP gateway operates with standard MUC. An IRC channel (which is like a simple XMPP MUC) is (usually) available on all of the nodes of an IRC network, and IRC clients connect locally to access the channel. On the XMPP side, there is a single MUC room running on the M-Link IRC/XMPP gateway. XMPP clients join the MUC directly, by connecting to the gateway, or indirectly by connecting via federated XMPP servers. In standard XMPP, the core messaging and presence service is federated, but MUC rooms operate on a single server.

In this next diagram we see how Federated MUC (FMUC) changes things. By federating the MUC room across multiple XMPP servers, including incorporation of the XMPP/IRC gateway, the XMPP side looks much more like the IRC side.

A key difference is that IRC channels are (usually) operated on all IRC servers in the system and IRC channels and servers are connected in the same way. With FMUC, MUC rooms are explicitly configured on two or more servers and then federated together using FMUC. Each FMUC federation of MUC rooms may have different configuration. An FMUC federation of MUC rooms is connected as an acyclic graph, but the XMPP servers on which the MUC rooms operate are fully connected. This gives more flexibility with the FMUC configuration, but the models remain very similar.

This architecture means that one or more IRC Channels operating over multiple IRC servers can be integrated with one or more FMUC rooms operating on XMPP servers. This will form an acyclic graph, such as the example illustrated above, comprising IRC channels distributed over multiple IRC servers (with IRC channel connectivity following IRC servers connectivity). A federation of MUC rooms (connected as an acyclic graph) operates on a set of XMPP servers (shown in blue) that are fully interconnected.

This approach with FMUC gives a number of advantages relative to using standard MUC:

  • The constraint of having MUC rooms only operating on the IRC Gateway M-Link server is removed.
  • In the event of a link between servers failing, operations can continue for the two halves. This disconnected operation is particularly important for constrained links, but the general survivability of the architecture is good.
  • The MUC federation gives local autonomy to management of MUC room membership, which can be helpful for a large deployment.
  • Traffic levels between servers are optimized.

It is clear that use of FMUC in conjunction with IRC gateways will often be very useful.

XMPP Gateways and Guards

IRC/XMPP gateways are very likely to be deployed in cross domain environments. Single domain deployments are much more likely to be able to operate with a single text messaging technology.

A detailed description of XMPP Gateways and Guards is given in the whitepaper [XMPP Boundary and Cross Domain Protection]. The rest of this section summarizes the key points from this paper.

An XMPP Guard will talk the XMPP S2S (Server to Server) protocol and sit between a pair of XMPP servers. In a very simple scenario, the XMPP Guard simply connects a pair of XMPP servers each supporting a single domain. In more complex scenarios, there may be many servers supporting many XMPP domains on each side of the guard. An XMPP Guard provides separation between XMPP domains and can provide checks on traffic being passed.

This diagram shows normal XMPP traffic flow. XMPP servers will route traffic directly to the server supporting the destination client. XMPP is not designed for operation with guards, and there is no standardized capability to support the traffic routing required. This sort of setup can be achieved by modifying DNS to get the "correct" routing and configuring the guards with modified certificates (so that connecting servers think they are the final destination). This approach is only usable for very simple configuration, and even then it is awkward to set up.

A better approach is to add flexibility into the XMPP server to route traffic through a guard. Isode's M-Link server does this by use of peering controls. You can configure explicit connections to guards, and then add rules such as "route traffic for domain X to guard A" and "route all traffic to guard B unless another route is explicitly configured". This configuration flexibility enables a wide range of guard configurations to be supported. When an XMPP Guard is deployed, it is desirable that all deployed XMPP servers on both sides of the guard support this type of configuration flexibility.

Isode’s M-Link Edge product is a basic XMPP Guard. M-Link Edge is the same product as M-Link, but used in boundary configuration. M-Link Edge provides a range of boundary capabilities including:

  • Security Label based Access Control..
  • Security Label transformations
  • Removal of potentially sensitive information from presence status.
  • Removal of certain types of traffic, such as file transfer requests and encrypted data.
  • Blocking MUC traffic or blocking 1:1 (MUC only).
  • Restricted message size.
  • Controls to require use of TLS and Strong Authentication.
  • Control of which users can send and receive traffic.
  • Traffic audit and archive.

M-Link Edge is a good choice as an XMPP Guard, where boundary separation is needed, and some basic checks made with system accreditation of the overall security.

XMPP Guards will often be deployed at boundaries where security checks are of utmost importance and use of an accredited guard will often be mandated. Isode provides an architecture to enable use of a standard XML Guard as the basis for a full XMPP Guard. The architecture is essentially an "M-Link Edge Sandwich", with M-Link Edge providing necessary XMPP protocol and marshaling capabilities and giving straightforward integration with an XML Guard.

Commercially, XMPP Guards are normally delivered as complete product, with M-Link Edge used as an OEM component by the guard vendor. Isode is collaborating with a number of gaurd vendors who are following this model.

Deploying XMPP and FMUC with Guards

It is straightforward to deploy FMUC with XMPP Guards. FMUC communication is simply XMPP messages, and these can traverse an XMPP Guard. Clearly, the XMPP Guard must be configured to allow FMUC messages through.

The diagram above shows the sort of configuration that is possible. Federated MUC rooms are connected in an acyclic graph, and an XMPP Guard may be used to separate any pair of nodes. Note that XMPP servers within a domain will be fully interconnected, but a set of Federated MUC rooms may be layered over this, and so you may find FMUC traffic being routed indirectly between a pair of XMPP Guards (as shown above) even though the underlying XMPP servers could connect directly.

Federated MUC rooms can be deployed across XMPP Guards in a flexible manner. There are a number of reasons why this may be useful. MUC will often be deployed in cross domain situations, where information is shared between partners or across national security domain boundaries. If standard MUC is used, a MUC room will need to be hosted in one domain with client access to the MUC room across the boundaries. There are a number of advantages to federating the MUC using FMUC so that the MUC room is distributed across the domains:

  • Traffic is optimized, so that there the flow of messages across the boundary is reduced to a minimum (rather than having traffic associated with each remote client connected to the MUC room). This optimization has several benefits:
    • Inherent saving of network bandwidth and cross domain performance.
    • Less traffic through the XMPP Guard.
    • Simplified XMPP Guard checking (as it only needs to review traffic between FMUC nodes, and not client traffic).
  • Clients get local access to a (federated) MUC room, improving client response time and resilience (a general benefit of using FMUC).
  • Disconnected operation is possible. It may be desirable for communication to happen within each partner group, even when the link is broken.

It is clear that it will often make sense to use FMUC in conjunction with XMPP Guards.

Adding IRC to the Mix

The above diagram shows how IRC could be added to a system with Federated MUC rooms and XMPP Guards. Deploying IRC into this sort of setup is quite likely as:

  • In a cross domain environment, different domains are more likely to use different protocols (IRC and XMPP), where a single domain will typically deploy with a single protocol.
  • IRC has only basic security. In particular there is generally no client authentication and no security label support. This makes it easy to deploy, but in a cross domain situation it will be essential to consider security across the boundary and deployment of guards.

We are not aware of any IRC guard solutions, which would in any event be difficult, due to the basic security provided by IRC. It therefore makes sense to gateway between IRC and XMPP in a single domain. When this is done, cross domain can be handled by XMPP Guards, as shown in the diagram above.

Conclusions

This paper has described how IRC and FMUC can be interconnected in a distributed environment, to give performance and reliability enhancements. XMPP Guards can be added in a cross domain environment.