Isode’s Military Messaging Handling Solution

This white paper gives an overview of Isode’s solution to provide Military Message Handling Systems (MMHS). It looks at the products that Isode provides and the architecture used to provide a complete solution. It then considers core MMHS provision, strategic interconnection over fast links, and operation of constrained networks and HF Radio.
Connection to partner systems and interoperability is central to MMHS provision, as different organizations, nations and partners will deploy different systems with different architectures. This white paper sets out the interoperability of Isode’s MMHS with partner systems at various levels.

What is Military Messaging

Military Messaging, sometimes referred to a Formal Messaging or High Grade Messaging is a critical military service. It shares technologies with email and interfaces can be shared. It is important to appreciate that Military Messaging is a distinct and different service to email. The core difference is on the communicating entities. Email is between users or roles. Military Email can use many of the features and protocols described in this paper, so it is the communicating parties that are critical.

Military Messaging is communication between organizations, so messages come from organizations to organizations reflecting command and control between the organizations. There is not a single mailbox for the organization; rather mailboxes are assigned to roles with users granted access to the roles. Roles will create messages on behalf of an organization. Messages arriving at an organization are distributed based on content using the profiling mechanism described below. This organization/role/user hierarchy is the central distinguishing feature of Military Messaging.

Within organizations, mailboxes belong to roles, not to human users. Role-based mailboxes can be accessed by multiple human users and a human user can have access to multiple role based mailboxes associated with one or more organizations.  This leads to a service and information structure that is fundamentally quite different to email.

MMHS Local System

The core of a local MMHS system is illustrated above. The three local components are described below.External systems are considered in later sections of this paper.

Harrier

Harrier is Isode’s Military Messaging client, supporting a full range of military messaging capabilities with role based mailboxes. It is a Web client, so can be deployed without the need for any desktop software.
Features worth noting that distinguish the UI from a standard email client:

1. Security Labels are shown for each message.
2. Messages distinguish Action and Information recipients with independent precedence (FLASH, ROUTINE, etc) showing clearly the precedence affecting the current mailbox.
3. Setting DTG as well as recording filing time.
4. Showing and controlling “processed status”, with warnings on precedence based processing times.
5. Subject Indicator Codes (SICs)

Further information on Harrier can be found in the Harrier Product Overview.

M-Box

M-Box is a high performance message store, which holds all of the messages displayed in Harrier. Harrier accesses M-Box using Internet Message Access Protocol (IMAP).

Further information on M-Box can be found in the M-Box Product Overview.

Directory

Directory is central to Military Messaging, with core services defined by Lightweight Directory Access Protocol (LDAP), X.500 and the CCEB ACP 133 specification describe in the Isode white paper ACP 133: The Military Directort Standard.

The directory contains information to authenticate users and information on MMHS services. The MMHS model is that information on local and remote systems are held in the directory, so that it provides a “global” address lookup for MMHS services. Harrier makes use of this to look up for both Organizations and Roles with an address book function.

M-Vault is Isode’s directory server, which provides a secure high performance server with comprehensive implementation of the relevant standards. Further information on M-Vault is provided in the M-Vault Product Overview

Provisioning

Cobalt is Isode’s Web based provisioning system, which configures information in M-Vault.
Cobalt provides role based management of a range of information including:

• Users, with user information and password management.
• Roles, with information on which users can occupy each role.
• Military Distribution Lists, described below.
• Profiles, described below.
• Organizations, which are MMHS senders and recipients. This includes configuration of roles which can send messages on behalf of the organization and draft and release configuration.

Further information can be found in the Isode white paper Provisioning for Military Messaging Handling Systems.

Organizations

Users connect to Harrier using password-based authentication. This authentication is used against M-Box, M-Switch and M-Vault. Mailboxes are associated with roles, so Harrier and M-Box check the role provisioning from Cobalt. Harrier allows users to choose between the role mailboxes they can access and M-Box ensures that only authorized users are allowed access.
User authentication offers two models:
1. Authentication against users provisioned in M-Vault by Cobalt.
2. Authentication against users provisioned in Microsoft Active Directory. Applications connect to M-Vault to use information provisioned by Cobalt, but M-Vault performs authentication against Active Directory using LDAP Passthrough.

Draft & Release

Draft and release is a process to ensure that messages sent are appropriately approved. Harrier offers two related capabilities:

1. “Compose for Review” where a drafter can send a draft messages to multiple reviewers (in parallel), receive comments and update the draft.
2. “Releaser Model” where a drafter sends a message through a series of approvers before the message is passed to the final releaser who will send the message on behalf of the organization.

Cobalt provides flexible configuration of the release process, allowing some roles to send directly, with controls based on message precedence and SICs.

Draft and release is described in detail in the Isode whitepaper Isode’s Draft, Review and Release Solution.

Profiling

Message profiling distributes received messages based on message content. This function is central to MMHS to enable distribution of messages addressed to organizations. The core profiling capability is provided by M-Switch with configuration in Cobalt. Key functions provided include:

• Subject Indicator Codes (SICs) are used to identify action and information recipients. The use of SIC’s on a message enables the originator to specify meta-information associated with the message which enables the message to be distributed to appropriate roles. This is a primary mechanism for message distribution.
• Text. Matching of free text in subject, message body to control distribution.
• Distribution by message Handling and Message Instructions.
• Out of hours processing enables alternate additional processing based on message precedence at configured times. This enables rapid handling of high priority messages in hours where some role mailboxes are not monitored.
• Manual processing is provided for special SICs (e.g. AAA) and for messages where no recipients are identified. An operator will use a Web interface to review arriving message and assign recipients to handle it.

Further information can be found in the M-Switch Profiler Product Overview.

Distribution Lists

It is often convenient to use distribution lists to send messages to multiple organizations. M-Switch provides a military distribution list capability with features including:

1. Action and Information recipients. This separation and display by Harrier allows appropriate processing by the different types of recipient
2. The use of policy to define message submitters and priority mappings.
3. Control of attachments and maximum message size.

These distribution lists function along the lines of standard email lists.

ACP 127 also supports two specialized list mechanisms: AIGs (Address Indicating Groups) and CADs (Collective Address Designators). They are similar, with AIGs distinguishing action and information recipients. Membership of AIGs and CADs is managed in the ACP 133 directory with global membership. Expansion is handled by the ACP 127 subsystem, with local expansion only. AIGs and CADs can only be used with ACP 127.

MTFs & ADatP-3

Command and Control (C2) systems use MMHS to transfer MTF (Message Text Format) protocols such as ADatP-3 and APP-11. This is a critical part of C2 communication. Harrier facilitates transfer of MTFs between C2 systems.
Further information is provided in the Isode white paper C2 Systems use of MTF and Messaging.

Security Labels

Security Labels are a key feature of MMHS and every message will have a security label. Modern security labels are complex objects with classification and multiple categories configured according the a Security Policy specified in a Security Policy Information File (SPIF).

Access controls are made against the Security Clearance of both users and channels to ensure messages are only accessed when security policy permits it.

Harrier allows security label selection from a system catalog and a mailbox catalog, where the user can add custom security labels following the SPIF, noting that for modern security policie, a very large number of different labels are possible.

Harrier checks message security label against recipient clearance, and only permits message sending when this is allowed.

Further information is provided in the Isode white papers Access Control using Security Labels and Security Clearance and Security Label Capabilities in M-Switch Products.

Capability Checking

It is highly desirable to ensure that all messages sent are delivered. In addition to the security label checking noted in previous section, Harrier provides various capability checking options that can be configured with Cobalt:

1. Maximum line length. This is primarily for ACP 127 recipients that have a line length limit.
2. Restrict character set to IA5 or ITA2. This is primarily for ACP 127 recipients.
3. Prevent attachments. This is essential for ACP 127 recipients, but can also be used to constrain use.
4. Maximum message size. This is important for deployment on constrained networks.

Fire & Forget supported by Message Correction

A central MMHS concept is “fire and forget”. When an MMHS user sends a message, it becomes the responsibility of the MMHS provider to ensure that the message is delivered in a timely manner.

Using queue monitoring and message tracking to ensure timely delivery is discussed below.

In most email systems, if there is an error of any sort, this gets passed back to the message sender. This approach cannot work with fire and forget. The approach taken with M-Switch is Message Correction, so that if a message is failed for any reason, it gets sent to a local operator.

The Message Correction UI presents the problem message to a local operator, who can perform corrective actions on the message including:

• Re-addressing the message. Important if message has an erroneous recipient.
• Removing attachments, which are a common reject reason.
• Adding or removing SICs.

Message Security

Isode’s local MMHS system is based on Internet mail protocols. These provide message security using the S/MIME standard. Harrier can handle S/MIME, including:

• Message signing using S/MIME
• Message header signing. This improves security, although this is not supported by many other systems
• Message encryption, including Triple Wrap

Further information can be found in the Isode white paper S/MIME for Military and High-Security Messaging.

TLS & Protecting Connections

The local MMHS system uses modern open standards and Isode protocols which can all be protected with TLS (Transport Layer Security). This is seen as important protection for an MMHS solution

Archive & Tracking

M-Switch archives messages to a local disk (for high performance) on arrival and departure.The double archive is important when protocol conversion occurs. M-Switch also records an audit log of all messages. Audit logs are processed and information held in an SQL Audit Database.

MConsole, the M-Switch management UI, can query the audit database and access archived messages by communicating to the appropriate M-Switch server. MConsole uses these functions to provide a number of views to present relevant message history to the operator and to provide a sophisticated message tracking capability. The audit database correlates message acknowledgements, which can be used to detect potentially lost message and prove historical operation without loss. Further information is provided in the Isode white paper Using Message Acknowledgements for Tracking, Correlation and Fire & Forget.

End to End Interoperability

Connecting to peer systems and necessary protocol conversions are covered in subsequent sections. It is useful to consider end to end interoperability as the local MMHS users are interacting with peer users over a potential mix of intervening protocols.

ACP 127

ACP 127 is the original MMHS system, which is still in widespread use. This is expected to continue for many years. Harrier provides support for all ACP 127 features. There is an issue in suppressing Harrier features which cannot be handled by ACP 127 recipients, in particular long lines, ITA2/IA5 character set restrictions and attachments. Harrier provides two means to address this:

1. Capability checking. By limiting message features to those supported by a given recipient, Harrier can provide good ACP 127 interoperability while not constraining services to more capable peers.
2. ACP 127 mode, where Harrier is constrained to ACP 127 compatible capabilities. This can be helpful in environments dominated by ACP 127.

MMHS over SMTP

A full MMHS service can be provided over SMTP, as described in the Isode white paper Military Messaging (MMHS) over SMTP. Isode’s work in this area, in particular RFC 6477 (Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail) has been adopted by a number of vendors and used to address national requirements for MMHS operating over SMTP. However, this approach is not a formal NATO or CCEB standard.

Isode’s local MMHS is internet email based, and so this is the native protocol for Isode MMHS.

STANAG 4406

STANAG 4406 is the current NATO MMHS standard. It is widely deployed, although some nations are moving away from it. Harrier provides the service capabilities for STANAG 4406. Considerations for using an Internet email based system to provide STANAG 4406 are discussed in the Isode white paper Using SMTP to provide a STANAG 4406 Military Messaging Service.

The Harrier UI is designed so that it provides minimal visibility of SMTP addresses (mostly in tool tips) and so the UI will feel natural to a STANAG 4406 user who might expect to see X.400 OR Addresses.

Strategic Connections & Cross Domain

This section considers the implication of connecting the Isode MMHS Local System to other systems over high speed links. This can be cross domain to other nations, networks or partners. This section also considers links within a domain to other MMHS Local Systems.

M-Switch

M-Switch provides connectivity to external services using SMTP, ACP 127 and X.400 P1 (for STANAG 4406) for fast links. M-Switch handles these protocols and manages protocol conversion between them as needed.

Security

TLS link security is provided for SMTP. ACP 127 and X.400 P1 do not define any link security.
ACP 127 does not have any specification for message security. STANAG 4406 defines message signing and encryption based on Cryptographic Message Service (CMS). As part of its protocol conversion services, M-Switch can provide message signing and encryption services. It is necessary to handle this at M-Switch as signing and encryption are necessarily protocol dependent.

Further Information can be found on the M-Switch Encryption Product Page.

Operator Services & Monitoring

Modern high speed links operate with high reliability and messages are generally transferred in less than a second. Strategic links generally do not need a high level of monitoring, but MConsole can be used to monitor links and to alert operators to message delay and queue build up.

Directory

To support MMHS, directories need to be replicated. For a service using multiple locations for Isode Local MMHS systems, it is recommended to use M-Vault multi-master replication described in the Isode white paper ACID Multi-Master Replication in M-Vault Directory.

For replication with other ACP 133 directories, use of X.500 DISP (Directory Information Shadowing Protocol) is recommended where possible. For directories that do not use this, LDAP synchronization using Isode’s Sodium Sync product can be used.

Interoperability with Strategic Systems

ACP 127

ACP 127 has historically operated over serial lines, which M-Switch supports. Current ACP 127 deployments tend to use TCP for fast links, following procedures understood by ACP 127 vendors.

ACP 127 has a number of standardized variants. M-Switch supports ACP 127G, ACP126, ACP128, JANAP128 and DOI103S. ACP 127 also has national variants. M-Switch is designed so that it is straightforward to add support for such variants and a number are supported.

ACP 145 & STANAG 4406 Annex A

The NATO standard to support MMHS within a domain is STANAG 4406 Annex A. M-Switch supports this. Cross domain uses ACP 145, which specifies in detail how to use STANAG 4406 Annex A and includes directory replication. Further information is available in the Isode white paper ACP145 Isode Support of International MMHS Gateways.

HF Radio and Constrained Networks

MMHS needs to communicate with systems operating in constrained and degraded environments. Use of HF Radio is a key element of this. This section looks at Isode support for these environments.

BRASS

BRASS (Broadcast and Ship to Shore) is a service for ACP 127 based MMHS over HF. This is based on NATO specifications, with a number of national variants. This section gives a brief summary of the primary components. A more extensive description is given in the Isode white paper Isode’s Solution for BRASS (Broadcast and Ship to Shore).

Broadcast & Ship to Shore

The core of BRASS is a broadcast transmission on multiple HF frequencies that ships in any location can listen to. The broadcasts use slow transmissions with robust waveforms. ACP 127 broadcast is “direct to modem”, so there is no error checking. A key part of this is that ships can be receive-only (EMCON). A summary of transmissions is broadcast at intervals, which allows ships not in EMCON to request retransmissions.

Transmissions can be scheduled, to support submarines with regular HF listen periods.

MRLs

Maritime Rear Links (MRLs) are dedicated HF links to single ships, typically “command afloat”. These can be operated direct to modem, but modern MRL will use STANAG 5066 to ensure reliable and error free transfer.

OTAM

Off The Air Monitoring (OTAM) is a service provided by a remote site to check how well a given HF frequency is propagating, by comparing sent and received data streams. This enables the broadcast to select the best set of frequencies to use at a given time.

Ship to Shore

Ships not in EMCON will have links back to shore, sharing a set of HF frequencies.These links are used to send messages to shore and to request broadcast retransmissions. There are two approaches to selecting frequency.

ALE

A modern system will use Automatic Link Establishment (ALE) to establish a link using standard HF procedures and STANAG 5066 for link reliability. This can be fully automated.

FAB

Older systems us Frequency Assignment Broadcast (FAB) which is a 75bps broadcast from shore that allows a ship to select a frequency to transmit to shore. This requires operator support on the ship.

BRE1TA

In 2008, NATO started to define a more modern approach to HF Services named BRE1TA (BRASS Enhancement 1 Technical Architecture). This does not have a formal definition, but there is a broad consensus on the included services and that BRE1TA is restricted to narrow band HF (3 kHz channel). BRE2TA will extend BRE1TA to Wideband HF (up to 48 kHz channel).

STANAG 5066

STANAG 5066 is a core underlying service for BRE1TA, provided HF link level services shared by applications, including MMHS. Isode’s Icon-5066 product provides STANAG 5066.

Military Messaging

NATO specifies that links of slower than 20 kbps need to use STANAG 4406 Annex E to support MMHS. STANAG 4406 Annex E is based on ACP 142, which provides multicast services. Detailed information provided in Isode white paper ACP 142: SMTP & STANAG 4406 Messaging for HF Radio and other Constrained Networks.

Directory

MMHS depends on a global directory and so it is vital to keep directory services on mobile units up to date. Isode achieves this by an efficient incremental replication using HF Messaging transport and updates by Isode’s Sodium Sync product. This is described in the Isode white paper Directory Replication by Email and over ‘Air Gap’.

Other Services

MMHS is only one part of BRE1TA which includes other services such as email, XMPP chat and Web browsing. More information is provided in the Isode white paper Isode’s HF Vision, Road Map & Products.

Operator Services & Monitoring

When constrained links are used, there is the need for more operator control and ongoing operator presence. MConsole provides a number of services oriented towards constrained networks:

1. Provision of message vetting, to enable control of which messages are sent over constrained links.
2. Queue monitoring for ACP 127 and ACP 142, enabling operator re-ordering of queues and removal of messages (vetting off).
3. Detailed operator support for ACP 127 links, which is particularly important for broadcast links and direct to modem links. This enables manual operator control of links and ACP 127-specific services such as message repair.

HF System Management

Shore systems supporting MMHS over HF have a significant number of hardware and software components. It is often necessary to reconfigure communication chains to support changing operational systems. Isode’s Red/Black product supports this. It is described in the Isode white paper Red/Black Overview.

Mobile Unit Mobility

Although HF Networks have wide coverage, they are not global. Partnership between nations allows support of mobile unit mobility by switching communication to different HF networks. This capability is supported by Isode’s Icon-Topo product. Details are provided in the Isode white paper Supporting Mobile Unit mobility over multiple HF Networks using Icon-Topo.

Mobile Unit Interoperability

Communication with mobile units is primarily a national concern, but is of wider significance when mobile unit mobility is considered.

ACP 127 Broadcast

ACP 127 Broadcast protocol and procedure is known from NATO documents, although the detailed specifications are not in a referenceable document. There are also national variations of the format. Care needs to be taken to ensure that all parties are using the same detailed variant.

ACP 127 Point to Point

Legacy ACP 127 can be direct to modem, although modern systems should be using STANAG 5066 and Connection Oriented Stream Service to achieve reliable error free operation. Care needs to be taken to align detailed ACP 127 formats and options for each end of the link.

ACP 142

ACP 142 is a CCEB standard. It provides straightforward interoperability. Some variants are noted.

Operation over IP for VHF/UHF/Satcom

ACP 142 specifies operation over IP using User Datagram Protocol (UDP). This makes it suitable for a wide range of slow and constrained IP networks.

Operation over STANAG 5066 for HF

STANAG 5066 specifies a mapping of ACP 142 directly onto STANAG 5066. It is strongly recommended for HF to use this mapping and not use IP (which leads to significant performance degradation).

STANAG 4406 Annex E

NATO specifies use of STANAG 4406 Annex E over ACP 142 for MMHS over constrained links.

MULE

RFC 8494 (Multicast Email (MULE) over Allied Communications Publication (ACP) 142) specifies use of Internet email over ACP 142. This provides a good option for operating MMHS over HF.

Solution Evolution

This white paper has set out Isode’s MMHS solution “as is”. This section considers how this solution will evolve.

Isode products are released with a two level version number (e.g., Icon-5066 2.0). Releases are fully supported for five years after initial release and update versions are issued as needed over this period. Functional changes are avoided in update releases, so the customers can simply drop in update releases.

Isode products evolve and new releases with new functions are issues for many reasons:
1. Open standards alignment is a high priority for Isode and we try to keep up with open standards.
2. Addressing customer requirements.
3. New technologies that enable product and service improvements.