Peering Controls in M-Link Edge

What is a Peering Control?

When an XMPP server initiates a connection to another XMPP server (e.g., to xmpp.isode.com) it will normally look up the domain in the DNS (Domain Name Service) and connect using the IP address determined from this lookup.

All products in the M-Link family allow configuration of a set of peering controls, which are checked prior to the standard DNS lookup. Each peering control relates either to a specific domain (e.g. xmpp.isode.com), or to a collection of subdomains (e.g. all subdomains of “isode.com”). A peering control can direct the connection to a domain or IP address configured as part of the peering control. Peer controls can be used to reject the traffic to another site entirely, restrict it to certain types, require particular security and authentication, and control the network connections used for the traffic.

M-Link Edge

M-Link User Server, M-Link Constrained Network Server and M-Link Edge are different products and, although they are all often generically referred to as “M-Link” each has different capabilities. When it comes to peering controls the product differences are particularly important to understand for users of M-Link Edge. A very simple configuration with M-Link User Server, M-Link Edge, and XMPP clients is shown below.

M-Link User Server is an XMPP server supporting XMPP clients (end users) that are directly connected to it. It may use peering controls to connect to a boundary server such as M-Link Edge or to enable checks and or actions when sending directly to another XMPP server.

M-Link Edge is a boundary server that has no directly connected clients, except operators (e.g MLC). It will always use peering controls to configure how XMPP traffic is routed.

A hybrid configuration where M-Link User Server provides boundary controls and supports local clients is possible, but would not generally be a useful or desirable configuration.

Standard XMPP Distributed Operation

The diagram below shows how standard XMPP distributed operation works. An M-Link User Serversupports (locally) one or more domains. An XMPP client is identified by a JID of the form “user@domain”. When an XMPP server needs to route a message to a JID it will do this on the basis of the domain. If the domain is not handled locally, it will look up the domain in DNS and connect directly to the appropriate XMPP server. This means that non-local XMPP traffic will go Client to Server 1 to Server 2 to Client. Messages will traverse either one or two XMPP servers.

A consequence of this is that standard XMPP does not support the boundary architecture shown in the previous section. Peering controls are used by Isode to enable configurations where messages are required to traverse three or more XMPP servers.

Supporting XMPP Gateways and Guards

In security-conscious organizations, the model of direct connectivity of XMPP servers is inadequate. When communicating between organizations or cross-domain there is a general requirement for application level checking of communication. M-Link Edge was designed to address this by provision of boundary services. Discussion of this requirement and different configurations for boundary checking is in the Isode whitepaper [XMPP Boundary and Cross Domain Protection].

Peering Controls in M-Link User and M-Link Constrained Network Servers

When an M-Link product is deployed in a configuration that uses an XMPP edge server (e.g., M-Link Edge), peering controls are used to route XMPP traffic to the edge server. There are two basic approaches:

1. Where a small number of XMPP servers are reached via the edge server, a peering control is specified for each of these XMPP servers, specifying to connect to the edge server.
2. Where most XMPP servers are reached via the edge server, a wildcard peering control is set up which will make the edge server be the default route. Additional peering controls are set up for each XMPP server that is contacted directly (to override the default route).

It can be seen that peering control configuration is a useful optional capability to enable deployment with XMPP edge servers. When deploying an XMPP edge server, it is important to understand that all XMPP servers in the system need this sort of capability. Note that in some very simple configurations that do not use TLS, DNS configuration can be used to enable use of an XMPP edge server by XMPP servers that do not support peering controls.

Peering controls can also be used to configure multi-server configurations in networks that do not use DNS.

Peering Controls in M-Link Edge

Peering controls are central to the way that M-Link Edge works. As an M-Link Edge server will be configured without real users (typically there will be an operator), configuring M-Link Edge is essentially about configuring peering controls so that XMPP traffic is correctly routed.

Links

The basic peering control mechanism is provided as a layer above the standard DNS lookup and operates over standard XMPP Server to Server protocol. Peering controls are checked first, and the configured domain is looked up in the same manner. peering controls can also be configured to use a special link. So peer controls are simply a control layer above the standard connection mechanism.

M-Link products allow you to configure “links”, each of which describes a set of characteristics for a particular network connection. There are two primary purposes for using links:

1. Constrained Network Support: Isode has developed an XMPP Optimized Server to Server protocol. This improves performance in constrained networks by removing handshaking from the standard protocols and is utilised by M-Link for Constrained Networks. Use of this optimized protocol is configured using a Link that specifies the configuration and parameters. Peering controls are then used to route traffic over the constrained link.
2. XML Guard Support:For a high security boundary it is useful to make use of an XML Guard. This is described in the Isode whitepaper [XMPP Boundary and Cross Domain Protection]. The optimized server to server protocol is used for guards, as this provides a simple XML stream, which is easier for an XML guard to handle than the full server to server protocol. Peering controls, which can be configured to use a number of different connection mechanisms, are used to configure the M-Link Edge on each side of the XML guard to route traffic to the Link configured for the XML guard.

Peer Control Checks and Actions

Peering controls enable a number of checks to be made on traffic using the peering control and options to modify the traffic:

• 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 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.
• 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.
• 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.
• Auditing of XMPP traffic.
• Alert of policy violations.
• Restriction on use of select XMPP features/extensions (e.g., disable file transfers, VOIP)

Conclusions

This whitepaper has described peering controls, which are an important option in all M-Link products and are fundamental to how M-Link Edge works.