This whitepaper gives an in-depth overview of Red/Black, which is a new Isode product that monitors and controls devices and servers, with a particular focus on HF Radio systems.


Isode Red/Black has three capabilities that distinguish it from the many service monitoring products available:

  1. It can operate over a secure boundary to enable monitoring and control of devices on the other side of the boundary. A key target, which gives the product its name, is Red/Black separation, which is a term used in cryptographic systems where user data on the Red side is always encrypted before being passed to the Black side.
  2. As well as monitoring, control of devices is provided. This is not intended to replace general device management, but enables core control of many devices to be provided securely to a single operator. This is particularly important where changes need to be coordinated across multiple devices.
  3. Communication chains. Red/Black enables devices to be shown following a communication chain where communication depends on a series of connected devices.  This can be set to reflect physical configuration. Where connectivity can be controlled by Red/Black, the UI enables operators to change connectivity.

Red/Black provides all this with a clean Web interface that supports monitoring and control of a wide range of device types. The UI is shown below.

This shows a portion of the UI, reflecting a black side view of a typical set of devices in a black side communication chain. Note that each device shows status with a “traffic light” indication and disabled devices are indicated clearly. In a normal operational scenario, you would expect to see all devices “green” and no devices disabled. This gives a clear top level status indication.

Things to note about the above screenshot:

  1. Selected device is clearly highlighted, with status and control information on the device shown in left hand column, with options to control the device.
  2. Devices to which the selected device is connected are shown clearly. This UI is the basis of communication chain reconfiguration.
  3. The monitored device is using a “mock driver” which generates random status parameters based on the device abstract specification. This is a convenient way to test and demonstrate the UI.
  4. A list of standalone devices (not in the communications chain) is shown at the bottom.
  5. Alerts are shown in the bottom right hand corner.  

Supporting HF Radio

Use with HF Radio configurations is a key target for Red/Black, although it is a general purpose product without any functions specifically tied to HF Radio.

Communication chains are important for HF Radio, with a typical chain being Application -> Modem -> Radio -> Antenna. Systems can have multiple components that can be built into chains. Operators need to build communication chains and set parameters that are consistent along the chain.

Communication chains are particularly important for older systems where applications use a dedicated link and should be disabled until the communication chain is operational. For modern applications using STANAG 5066, they will have communications multiplexed over STANAG 5066 and there is less need for control of the communication chain, although monitoring remains highly desirable. Communication chains are discussed in more detail in the Isode whitepaper [HF Circuits: Automation & Evolution with STANAG 5066].

In a typical set up, operators and applications sit Red side, with Crypto separation from Black side where hardware such as modems and antennae sit. To provide integrated monitoring, it is critical that monitoring and control can work across the Red/Black boundary.

For many HF deployments, the different components come from multiple product vendors and it is desirable to have an integrated management experience. Red/Black addresses this with a driver model, that allows drivers independent from the core product to be written for a wide range of devices.

Monitoring and Control functionality has been provided in some HF systems by RSC (Remote Supervision and Control) which is a Visual Basic  NATO provided tool. Red/Black is a COTS product, intended as a modern replacement for RSC.

The above screenshot shows an HF communications chain (red side view) with Isode applications running on red side, connecting across a red/black boundary with typical black side components. This is a long chain, and an operator will typically manage by zooming in to a specific section as shown in the next screenshot

Monitoring and Control Across a Boundary

A key feature of Red/Black is to provide monitoring and control across a secure boundary. The two sides of the boundary are referred to here as “Red” and "Black” which reflects the terminology used in HF communications deployments. Red/Black could be used across other secure boundaries (e.g., cross domain; organization perimeter) to provide monitoring and control of devices on the other side of the boundary.

Red/Black operates as a pair of servers. The Black side server will control and monitor only devices on the Black side. It will communicate with the Red side server in a secure manner across the boundary, enabling the Red side server to monitor and control the Black side devices. This provides the core separation.

The Red side server can also monitor and control Red side devices. This will allow a Red side operator to manage a communications chain that includes a mix of Red side and Black side devices. This is important for HF communications, where managed devices reside on each side of the Red/Black boundary.

Authentication and Roles

Red/Black servers require authentication and authorization to access. This is done using OAuth, which is primarily intended to be used in conjunction with Isode’s M-Vault product which supports OAuth and users provisioned using Isode’s Cobalt provisioning product. This is described in more detail in the [Isode OAuth] whitepaper.

Users will authenticate to Red/Black with their own credentials and be assigned one of three roles:

  • Administrator. Full rights to make changes and set up system configuration.
  • Operator. Rights to make some changes.
  • Viewer. Read only access.

This reflects a model where the primary users will be operators who will make changes that can be fully controlled from Red/Black and appropriate modifications for a running system. The operator function is considered in more detail below.

Note that users on Red side and Black side will be authenticated independently. There is no authentication across the Red/Black boundary.

Communication Chains & Other Devices

Many monitored devices will be able to form part of a communications chain and it is anticipated that Red/Black will commonly be used to monitor and control systems where the primary devices are linked in communication chains. There are three types of communication link shown by Red/Black:

  • Fixed link. This reflects a link that is externally configured, such as a cable connecting two boxes. A Red/Black administrator will configure Red/Black to reflect this link.
  • Application controlled link, where the application administrator will configure a link that is picked up by Red/black.
  • Operator controllable link. This reflects a link which can be configured by making changes to managed devices, for example by configuring a TCP connection. This type of link is controlled by Red/Black operators, which enables an operator to modify the communication chain using Red/Black.

The screenshot above shows how an operator can modify the communication chain, by selecting different devices. Note that devices in the communication chain are grouped in columns of similar types of devices, which makes it convenient to modify the communication chain.

Many traditional HF communication devices are connected using cables (fixed links). To enable operator switching, a common approach is to use devices which map from the cabled connection to TCP. Use of such devices enables operator switching of configuration. The illustrated communication chains use this in two places:

  • Audio switching, to give operator controlled connections between modem and radio.
  • RF switching, to give operator controlled connections between radio and power amplifier.

The list of columns in the communication chain is derived from the Device Family, which enables devices of different types to be grouped in the same column. New columns will be added when devices in a different family are added. Column ordering is automatically determined based on device type connectivity information.

Red/Black can also monitor and control devices which are not in the communication chain, as illustrated above. These devices can be completely independent or associated with one or more other devices. Some examples:

  • An Uninterruptible Power Supply (UPS) which would be associated with the devices it provides power to.
  • A thermometer device, which might be associated with a device whose temperature it is measuring.
  • An M-Vault Directory Server, which is not part of the communication chain, but provides support to servers which are.

Device Monitoring and Control

A primary goal of Red/Black is to monitor and control devices. The top level view in Red/Black shows a full list of devices, each of which has a “traffic light” status. In typical operation, most devices will be “green” (operating without error), so the high level view can be used to identify devices with issues. Devices can be selected to get more detailed information on a device, as shown below:

The core of the device display is a set of parameters associated with the device. This includes:

  • Generic information about the device, such as a description.
  • Read only parameters provided by the device, such as VSWR.
  • Parameters that can be set on the device by the Red/Black operator, such as transmission frequency.  

There are a number of generic capabilities shared by many devices.

  • Heartbeat. This is a mechanism to verify that the device is being monitored correctly.
  • Running Since. Reporting on how long the device is known to have been running.
  • Refresh. Send a request to the device to provide all parameters.
  • Reset. Instruct the device to perform a reset.
  • Power Off. Instruct the device to turn off.
  • Enable/Disable. This instructs the device to be active or not.

The Enable/Disable is key to building communication chains. Typically the change will begin with a device towards the application end of a communication chain (e.g., ACP 127 circuit or STANAG 5066 server) being disabled. Then the rest of the communication chain will be assembled, and any necessary parameters under operator control set in the devices in the communication chain. When the communication chain is ready, the device at the start of the chain will be enabled again.

Alerts and Rules

Devices are able to issue alerts of varying severity. Low severity alerts can be used to provide informative information that may be helpful to the operator and high severity alerts can warn of problems that need attention. Alerts are shown to the Red/Black operator in a number of ways:

  • For each device, an alert history can be viewed, so that the operator can see all alerts for a selected device.
  • Arriving alerts for any device are shown as a pop up on the Red/Black monitoring view.
  • Where a device has high severity alerts that have not been viewed by the operator (to be providedin a future release), this is shown visually in the display.

Red/Black also has a generic Rules capability (to be provided in a future release) that can be used to provide extended alerts and other actions. Some examples of how this capability can be used:

  • When a device parameter reports a value outside of a configured range, the operator is alerted.
  • Alerts can also apply between devices. For example if an Antenna has a configured frequency range, an alert can be generated if a radio in the communication chain is set to a frequency outside that range.
  • Rules can also lead to actions. For example if a thermometer associated with a device records a value above a certain level, the device will be turned off.

Abstract Devices

Red/Black is designed to monitor and control a very wide range of devices, from radios to servers such as Isode’s M-Vault directory server. It is not intended as a replacement for vendor-supplied management tools. Rather it gives basic monitoring and control of certain key parameters which might be needed by an operator taking an overall view of the system.

Central to the Red/Black design is the ideal of an Abstract Device specification which is an XML representation of the status and control parameters of a given device. The Red/Black UI is driven by Abstract Device specifications, so that the UI will fully adapt to any new device types that are added. This makes it straightforward to add new devices, which can be done by defining a new abstract device type without requirement to make any UI changes.

Devices are provisioned by adding a list of actual devices, each referencing the Abstract Device type of the device in question.  

Complex devices, such as Isode's M-Switch, can be represented as a heirarchy of devices, with the parent device only provisioned in Red/black and subsidiary devices created from the devices own configuration.

Product Architecture

The Red/Black architecture is shown above. The primary deployment model of Red/Black is with one server on each side of a Red/Black boundary. The goal of this is to enable operators Red side to monitor and control devices Black side. Both Red and Black side servers can monitored and configured with a standard Web browser. Devices are monitored and controlled through device drivers which are external to the core Red/Black server.

Separation between Red and Black sides is achieved by using a pair of XML Guards which act as application level data diodes:

  • One XML guard controls flow of status information from Black to Red.
  • The other XML guard controls flow of control messages from Red to Black.

The XML Guards are configured to ensure that only allowed information flows in each direction. Red/Black has a generic XML Guard design that could be used with any XML Guard, but it is primarily intended for use with Isode’s M-Guard product. 

Red/Black can be used as a single server to monitor and control locally connected devices. This can be appropriate in some scenarios where there is no significant separation of Red and Black side function.  

Device Drivers

For every device to be monitored/controlled in Red/Black there needs to be an Abstract Device specification and a device driver that supports that specification. Device Drivers use a simple protocol to talk to a local Red/Black server, which is specified to make it straightforward to write drivers. Isode provides a number of device drivers with Red/Black, in particular:

  • Drivers for Isode server products. This enables straightforward support of communication chains that include Isode applications.
  • Drivers for Modems/ALE Units supported by Icon-5066. This currently includes Collins and RapidM devices. 

Isode also supports three generic drivers:

  • Mock Driver. This can be used with any abstract device and it fakes behaviour of the device. It enables easy testing of abstract device specifications and communication chains without the need to use real devices or to write drivers.
  • Null Driver. Sometimes a communication chain will include a device which it is not possible to monitor (e.g., a Crypto box). The Null driver can be used in a communication chain so that such devices appear in the Web UI monitoring view, despite the fact that they are not actually monitored or controlled by Red/Black.
  • TCP Connect Driver. This connects to a device using TCP to provide a basic operational or not operational status value.
  • SNMP Driver (after release 1.0). SNMP used to be an important way to monitor and control devices. Although it is of decreasing importance, Red/Black provides a driver that enables configurable use of SNMP(v3) to monitor and control devices that provide this support.

Because device drivers use a standard protocol to talk to the Red/Black server, they can be written in any language. Isode provides a reference open source implementation available under an open source licence on Github. This includes a “mock radio device” with a Web UI and a C++ driver for that mock radio device. This is to facilitate development of device drivers.

Road Map

Red/Black 1.1 is the second release of Red/Black. It provides a complete management and authorization framework, with separation between red and black side provided by M-Guard.It enables monitoring of Isode provided servers and supported modems, as well as emulation of other devices.

A key target for Red/Black is to provide management of a range of black side devices. With the exception of HF Modems supported by Isode's Icon-5066 product (which have Isode supported drivers included in Red/Black) it is anticipated that these device drivers will be provided by systems integrators and other Isode partners using Red/Black. So a goal is to facilitate partners to develop such drivers, which will be necessary for full deployment.

An SNMP driver is planned for the next release, so that any SNMP device (red or black side) can be monitored and controlled by Red/Black.

Red/Black devices are monitored and controlled independently. A Rules Engine will be added, that enables relationships between device activity with automatic actions, for example to turn off a device if the temperature becomes too high or to switch in a different radio if one fails.