The M-Link Edge is used to provide an XMPP Boundary Guard service to protect organizational boundaries and provide Cross Domain services.


M-Link Edge can validate, constrain and transform the XMPP messages it handles. M-Link Edge enables boundary controls to be completely independent of the core XMPP service and, as a boundary service provided by M-Link Edge, can support multiple XMPP servers within an organisation.

Deployment Modes

The diagram above shows three possible deployment modes for M-Link Edge:

  1. Firewall with single M-Link Edge.
  2. Pair of M-Link Edges with Firewall.
  3. Pair of M-Link Edges with an XML Guard.

M-Link Edge uses the standard XMPP Server/Server protocol for connections to XMPP servers, connections to High Assurance Guards such as M-Guard use Guard Content eXchange Protocol (GCXP).

M-Link Edge is Web managed. M-Link Edge provides a boundary function and does not support directly connected users or Multi-User Chat rooms.

Firewall with a single M-Link Edge

This mode is appropriate for an organization needing XMPP boundary protection. M-Link Edge can validate and constrain or transform both inbound and outbound messages. M-Link Edge can communicate with multiple XMPP servers within the organization, providing a single route for external traffic.

Pair of M-Link Edges with Firewall

In this second deployment mode, two M-Link Edges are operated with a firewall between them.  This configuration would typically be used for a Cross Domain boundary, with one M-Link Edge in each domain and a firewall separating the domains.  The M-Link Edges would communicate using standard XMPP server to server protocol with strong authentication between the servers, so this architecture could be used with a different product (equivalent to M-Link Edge) on one side.

Each M-Link Edge server can be operated according to the policy on its side of the firewall allowing for independent and clearly decoupled control of the checks being applied on each side.

Pair of M-Link Edges with XML Guard

The final configuration is to use a pair of M-Link Edges connected by an XML Guard such as Isode's M-Guard product. This is for use in scenarios where the separation by firewall does not meet security requirements. The XML Guard can validate that the messages exchanged are XMPP and aligned to checks and constraints imposed by the M-Link Edges. The XML Guard does not apply additional checks; rather it is a formal validation of the checks applied by M-Link Edge.

Integration of an XML Guard between a pair of M-Link Edges provides a component that functionally acts like a single M-Link Edge, but with higher assurance of separation. This might be used in either of the previous architectures. This would act as one side in a Cross Domain configuration.

This architecture is described further in the Isode whitepaper [Isode's XMPP Cross Domain Solution]

M-Link Edge Capabilities

M-Link Edge can be configured in a number of different ways to provide an XMPP boundary service and allows:

  • Presence Folding. XMPP user presence can contain a lot of information that may be sensitive. Presence folding reduces this information to a small number of states (e.g., online/offline) so that only very basic presence information is made available outside the organization.
  • Message Folding. The ability to remove fields from message (e.g., HTML messages) or to remove entire message types (e.g., chat state notifications). This can be used for security reasons. It can also be used with presence folding to reduce bandwidth usage in constrained networks.
  • Security Label Checks. Access control is applied based on a Governing Security Policy, Security Label on the XMPP message, and Security Clearance associated with source and/or destination.
  • Security Label Relabeling. Security Labels are mapped to a Security Policy associated with the destination, using label equivalence mappings defined within the Security Policy. If XEP-0258 is used, the original label may be retained along with the new one, which is generally desirable.
  • Blocking of file transfer, by blocking in band file transfer and standardized file transfer requests.
  • Blocking MUC traffic or blocking 1:1 (MUC only).
  • Blocking encrypted traffic.
  • Enforcing message size limits.
  • Peer authentication controls, including ability to require TLS and Strong Authentication.

Other functions that can be provided in conjunction with the checking:

  • Alert of policy violations.
  • Restriction on use of select XMPP features/extensions (e.g., disable file transfers, VOIP)

XMPP Trunking & Peering Controls

Standard XMPP communication goes directly from the initial server to the final server. This works well in an open Internet environment. To support boundary checks, it is generally necessary to transfer XMPP messages through several servers. This indirect approach is known as “XMPP Trunking”, which is described in the Isode White Paper [Providing XMPP Trunking with M-Link Peer Controls].

M-Link provides peering controls which do three things:

  1. Configure the XMPP routing, including default routing, so that an XMPP Trunking architecture can be configured. This is done by defining peers as domains, which may optionally include subdomains.
  2. Allow protocol selection for each peer, which can either be standard XMPP Server to Server protocol or Guard Content eXchange Protocol (GCXP).
  3. Provide the filtering and control capabilities selected for each peer that are described above as M-Link Edge capabilities.

Peer controls are central to how M-Link Edge works. M-Link Edge uses peer controls to route messages and apply checks and filtering.

Peer controls can also be used in an M-Link server supporting users. Note that filtering and control is applied primarily on outbound traffic, with some inbound control. The primary use of peer controls in a standard M-Link setup is to route traffic to an M-Link Edge. This means that multiple M-Link servers can share a single M-Link Edge, and then M-Link Edge can support both inbound and outbound checks.