M-Guard is a guard for checking XML content exchanged across network boundaries. M-Guard can act as an application-level data diode. This whitepaper complements the M-Guard Product Overview and provides supplementary information on M-Guard as well as a Road Map for the product’s evolution.

This paper starts by looking at the technical and commercial goals for introducing an XML Guard, and why this particular approach was chosen to address problems. It then looks at the internal design of M-Guard and choices made, particularly to support product accreditation. Finally, the product road map is set out.

Solution Goals for M-Guard

There are four specific solutions that Isode is targeting that require M-Guard. The first two of these are Cross Domain scenarios, where applications need to communicate across a security boundary between organizations or countries. Isode has two target applications:

  1. Instant Messaging and Presence using XMPP protocols, with the M-Link Edge product on each side of boundary.
  2. Messaging (SMTP, STANAG 4406 and ACP 127), using the M-Switch Edge (planned) product on each side of the boundary.

The other two target applications operate across red/black boundaries, where user data from red side is always encrypted at the red/black boundary. Isode’s two target applications are:

  1. STANAG 5066 crypto bypass support, so that Icon-5066 product (red side) can control and monitor modems and ALE (Automatic Link Establishment) units on black side.
  2. Control and monitoring of black side devices from the red side. Isode’s (planned) Red/Black product

An approach is desirable that can support future Isode products and can support third party applications with similar requirements.

Protection will always be across a network boundary. For many target customers, there will be a requirement that any product which sits on the security boundary is accredited. It makes sense to keep the boundary product (M-Guard) as simple as possible (but no simpler). A simple product will be lower cost to accredit and keeping things simple is usually helpful to ensure security. This leads to an approach where, to the largest extent viable, functionality is pushed out to the applications connecting to M-Guard, in order to minimize functionality in M-Guard.

By minimizing the M-Guard functionality, this helps to bring down the price of boundary protection, making the whole solution lower cost.

Why a Network Firewall is Insufficient

A common approach used at the boundary of two networks is a Network Firewall. This separates the networks and allows selected traffic through. M-Guard is performing a specialized firewall function, and it is useful to compare with a general-purpose network firewall that operates at the IP level.

A network firewall will typically allow traffic through on selected ports. An organization will use this to control which protocols are allowed across a boundary, and sometimes constraints on packet routing. There are two basic problems with this:

  1. There is no guarantee as to “correct” protocol use of the port. By opening up a port in anticipation of letting one type of traffic through, it might be used for a different type of traffic.
  2. Attacks can be made through the firewall. Consider a firewall that opens up port 25 to let SMTP traffic through. A malicious system could send SMTP to a server behind the firewall to exploit a vulnerability in that server.

This means that a basic network firewall is insufficient for the M-Guard target applications.

Network Separation

The network separation that is provided by a network firewall remains a critical part of how M-Guard is deployed. Typically, this will be achieved by operating M-Guard on a system with two network interfaces, one on each side. The M-Guard setup needs to ensure that all traffic will go through M-Guard and no traffic will go around it. Network separation is inherent to the architecture, with more controls than a firewall gives.


Isode has made a basic choice to keep things as simple as possible. If functionality is not needed in M-Guard, it can be pushed out to the applications using M-Guard. The aim is to improve security and to reduce cost.

Content Based Control

An architectural choice is that M-Guard checks are made on discrete blocks of content. This allows controls to be specified simply as “is this content allowed”. The model is that the checks are stateless, and that rules for whether a given content block is allowed are not dependent on anything other than the message.

Yes/No Decision

When content is sent to M-Guard, a simple yes/no decision is made. The expectation is that the system sending data to M-Guard understands the boundary policy rules and will only send allowed content. This means that M-Guard’s role is one of security policy enforcement. There is no content transformation. This approach simplifies M-Guard and leads to better security.


Not holding state is a key choice that helps simplicity and resilience of deployment when multiple guards are used. The order of processing is:

  1. Content arrives from producer.
  2. Rules and checks are applied. If anything fails, the content is rejected.
  3. Content is send to the consumer.
  4. Response comes back from the consumer.
  5. Content of response is validated. Usually the only valid response is “nil”. Any invalid response is discarded.
  6. Response is passed back to the producer.
  7. Message sent out is acknowledged.

This places reliability requirements onto the applications using M-Guard and enables simplification of M-Guard.


M-Guard can operate as an application level data diode, with application content being exchange through the Guard instance in only one direction. The Guard support supports optional control information (success or failed transfer) for use in providing reliability delivery. This can be disabled when not required by the application and undesirable for the deployment.

Unidirectional operation is desirable for several reasons:

  1. It can support scenarios where content flows in one direction only.
  2. It is straightforward to support bidirectional content flow by using a pair of M-Guards.
  3. Rules for one direction of content flow can be specified simply and cleanly.
  4. As a simplification, it improves security.


M-Guard content is XML encoded. XML is a flexible language that enables a wide range of information to be specified. It enables M-Guard to be used to support a wide range of applications.

XML has a number of standardized mechanisms for specifying syntax and rules, including:  XML Schema; Xpath; Schematron; and RELAX NG. This makes XML attractive, as these mechanisms can be used to specify exactly which messages are allowed through a guard and give options for specifying rules using an appropriate language. It also allows M-Guard to use widely used open source components to provide these checks. This reduces the amount of custom-developed functionality in M-Guard.

Why an Isode Product?

There is a clear functional case for an XML Guard to support Isode’s target solutions. There are a number of XML Guards available; It is useful to consider why Isode has chosen to bring another one to market.

It is desirable to have product choice. Isode’s solutions that use M-Guard are designed so that they can use any XML Guard. This will give Isode customers the choice to use M-Guard or to use another XML guard where benefits are perceived.

Isode sees two key reasons why there is a need to introduce the M-Guard product:

  1. Many of the XML Guards on the market are very complex and powerful products, often designed to support use of Web applications. The additional functionality is not helpful from a security perspective and can add to integration and product cost.
  2. Isode wishes to offer a “complete solution” without a mandatory third-party dependency.

Guard Content eXchange Protocol (GCXP)

A key part of the M-Guard design is use of Guard Content eXchange Protocol (GCXP) to connect applications to M-Guard on either side. GCXP provides a simple protocol to exchange XML messages with a Guard. It used Compact Binary Object Representation (CBOR) as specified in RFC 7049.

Isode has provided GCXP as an open specification (currently in Appendix B of the M-Guard Manual). Isode has also provided a C++ open source reference implementation of GCXP with a permissive license.

There are two goals with this very open GCXP approach:

  1. It will facilitate development of third-party applications making use of M-Guard.
  2. It will facilitate use of Isode applications with alternative XML Guards to M-Guard, by enabling provision of GXCP interfaces to the XML Guard.

Architectural Approaches & Accreditation

This section looks at key choices made in M-Guard, particularly in context of planned accreditation.

Source Availability

While M-Guard is distributed as an appliance, Isode can supply source code to accreditors and to partners needing the source code as part of a system accreditation.

Open Source

It is a goal of M-Guard to maximize use of open source packages, where these packages are widely used and so subject to community scrutiny. Use of widely used and tested packages helps ensure security of the M-Guard server. It also enables keeping the M-Guard server code base small, which improves security and reduces cost of accreditation.

The following key open source packages are used.

  1. The NanoBSD variant of FreeBSD. This is the base appliance platform for M-Guard. It is chosen as a compact security-oriented platform suitable for this type of appliance.
  2. Boost. Widely used C++ support libraries.
  3. OpenSSL. Widely use TLS and cryptographic product.
  4. LibXML2. Widely used XML library, with comprehensive rule and checking support.

Modular Open Architecture

Where possible, the M-Guard architecture is modular. A modular structure with clear interfaces supports accreditation. Detailed design documents are available to those requiring them for accreditation purposes. 

Separation of M-Guard Console and Syslog

The M-Guard appliance is designed so that it has the necessary minimum of functionality on the appliance, with management functionality pushed externally.

Audit and event recording is done with Syslog on a special management network interface. This includes an option for operation over TCP, including Reliable Event Logging Protocol (RELP). Use of Syslog can be easily shown using a GUI syslog tool in demonstration setups. In an operational setup, one of many syslog management systems can be used to record M-Guard activity and to alert system operators according to policy.

Management is performed by M-Guard Console which is a Pure Java GUI. M-Guard Console communicates securely with the M-Guard Appliance using Secure Shell. M-Guard Console Provides a number of functions:

  • Configuring M-Guard Instances on the appliance.
  • Appliance setup and management, including backup and update.
  • Guard instance version control.
  • Management of Rule Catalogs and Application Profiles.

Normalization Checks

XML allows a number of variants. These are undesirable for a guard, because of potential to create a covert channel. Application profiles will define a set of required normalization checks. M-Guard will ensure that this normalization has been applied, by applying the normalization checks and verifying the that binary data is unchanged.

Normalization also aids in development of content checks, whether part of the profile or part of a rule catalog. Typically, both syntax canonicalization (e.g., XC14N 1.1) and semantic normalization (e.g., XSLT and NFC) should be performed.

Independent Implementation

Although M-Guard supports protocols used in other Isode products, the M-Guard implementation is entirely independent. One reason for this is to prevent systematic errors with code common to M-Guard and applications using M-Guard.


M-Guard appliance mandates use of TLS for all connections. This is seen as important security. Use of two-way strong authentication for all connections is seen as good practice and encouraged.

In the closed M-Guard environment, it is awkward to securely check certificate validity. For this reason, it is generally recommended to use a complete PKI for configuring M-Guard and the applications connecting to it. This means than in the event of certificate compromise, the entire PKI can easily be replaced.

Guard Chaining

M-Guard communicates with GCXP on both sides. GCXP has been designed so that it is possible to chain multiple M-Guards together in sequence. This can be desirable to apply independent checks or where the different M-Guards are under independent management control.

Application Profile Separation

Although M-Guard has a primary goal of supporting  a number of Isode applications, it is delivered as a “pure” XML Guard product. It is expected that applications using M-Guard will either:

  1. Provide an Application Profile and associated rules as a part of the application, for loading through M-Guard Console; or
  2. Make use of a third party Application Profile.

Delivery Approach

The Isode M-Guard Product is a Software Appliance. It can be delivered to run on appropriate hardware (current reference platform is Netgate SG-5100). It can also be run in a virtual environment (currently Microsoft Hyper-V and  Oracle VirtualBox).

It is anticipated that needs will arise for operation of M-Guard on special hardware (e.g., Tempest Accredited). Isode anticipates working with hardware OEM partners to deliver such solutions as a complete hardware appliance.

Road Map

This section sets out some key enhancements to M-Guard in future updates.

Application Profile

M-Guard 1.0 provides a set of rules from one or more Rule Catalogs to control the M-Guard checks. It is planned to develop an Application Profile approach, where the protocol being checks has a baseline profile defined in an appropriate formal language, for example as an XML Schema. Where appropriate, rules can be defined to constrain the Application Profile, so that individual deployments can tune the application profile to deployment needs.

Hardware Failover

M-Guard can be configured to support failover to a redundant appliance upon various sources of failures. The stateless design is key to achieving this. A future version of M-Guard will support Common Address Redundancy Protocol (CARP) to allow failover to a hot standby system.

Isolation of Guard instances running on an appliance

Currently Guard instances run as separate unprivileged processes under the NanoBSD operating system. It is planned to isolate the Guard instances from each other and the operating system by running each in a separate virtualized system environment known as a Jail. Each instance will effectively run as if each was deployed on a separate appliance, with it's own hostname, IP addresses and TLS configuration.

Rate Control

Some Isode applications of M-Guard need rate control, as a mechanism to limit potential covert channel.


It is planned to extend M-Guard with the ability to audit the content of every message transferred, in addition to the current syslog recording.

Physical Data Diode

M-Guard acts as an application data diode. It is planned to enable use of M-Guard with a physical data diode, which can operate with a very high level of security accreditation. Because there is no return path at all, there is potential for data loss in such a configuration.  It is possible to minimize data loss by use of appropriate forward error correction (FEC) techniques, dependent on the API offered for diode integration.