On this page you'll find information on M-Link Edge, a product based on M-Link which is used to provide an XMPP Boundary Guard service to protect organizational boundaries and provide Cross Domain services.

M-Link Edge is a specialized XMPP server with no connected users that controls XMPP message flow to and from general purpose XMPP servers.  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.

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

  1. Firewall with single M-Link Edge. This allows an organization to control XMPP traffic in and out of the organization.
  2. Pair of M-Link Edges with Firewall. This will be used for Cross Domain configurations, where checks are made on both sides of the boundary. The M-Link Edges will communicate across the firewall with standard XMPP protocol.
  3. Pair of M-Link Edges with XML Guard. This is for Cross Domain configurations that require security beyond that which can be provided with a firewall. An XML Guard can validate that traffic is only XMPP conforming to the rules controlled by M-Link Edge.

For more information on XMPP boundary checking, see the whitepaper [XMPP Boundary and Cross-Domain protection].

M-Link Edge Capabilities

M-Link Edge, based on M-Link, 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 using the Security Label on the XMPP message based on a Governing Security Policy and Security Clearance associated with source and/or destination.
  • Security Label Transformation. 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.
  • Filtering of XMPP IQ (Information/Query) messages.
  • Blocking of file transfer and VOIP, by blocking standardized in band file transfer and standardized file transfer and VOIP negotiation requests.
  • Dirty Word checking to block messages which contain any of a configured list of words.
  • Blocking MUC traffic or blocking 1:1 (MUC only).
  • Blocking encrypted traffic.
  • Enforcing message size limits.
  • Controls, based on JID or sending and receiving user, on who can send to who.
  • Peer authentication controls, including ability to require TLS and Strong Authentication.

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

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

Deployment Modes

There are three possible deployment modes for M-Link Edge:

Firewall with 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. 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.

Isode's recommended approach to use XEP-0361 “Zero Handshake Server to Server Protocol” to connect between M-Link Edge and an XML Guard.  This approach has been validated with several XML Guards.

Further details are given in the Isode whitepaper [XMPP Boundary and Cross Domain Protection] .

High Availability

The deployment modes above are shown with single M-Link Edges. Where high availability is needed, all of these architectures can be supported with multiple M-Link Edges in active-active configuration using IP load balancers.

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 XEP-0361 Zero Handshake Server to Server Protocol.
  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 only outbound traffic. 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.

Use of peering controls is described in more detail in the Isode whitepapers [XMPP Boundary and Cross Domain Protection].