This white paper gives a summary of Isode’s approach to providing products for HF radio, looking at current and future products, explaining the problems being addressed. The paper starts by looking at why HF Radio is an important technology for BLOS (Beyond Line of Sight) communication, despite its technical difficulties. The paper then sets out Isode’s “Everything above the Modem” vision for providing applications over HF Radio. It then considers current HF deployments, technical developments which can enable improvements and missing standards that inhibit them. It looks at the NATO BRE1TA, BRE2TA and BRIPES initiatives and how Isode’s current product set can meet the major requirements. Finally, it looks at Isode’s product road map and the set of open specifications needed to support these products and market requirements.


Why HF?

BLOS communication is critical for many military and other organizations. SATCOM is the increasingly dominant means of BLOS communication, with speed and reliability steadily increasing. SATCOM enables a wide range of real time and streaming services to be provided.

HF is a difficult communications medium with lower speeds than modern SATCOM. However, there are critical reasons why HF is important:

  • SATCOM does not reach all locations (e.g., Fjords, Jungles and Polar Regions).
  • Some countries cannot afford national SATCOM services and do not wish to rely on commercial services.
  • For SATCOM-Denied operation and to support C2D2E (Command and Control in a Denied or Degraded Environment). Satellites are vulnerable to physical attack and jamming is straightforward. 

For these reasons, it will generally be desirable to have an option to use HF services. It will often be configured as a back-up system that will switch in when SATCOM is not available.  

Isode’s HF Vision

Isode’s HF vision is summarized as “Everything above the Modem”. When an HF solution is deployed, we look to partner companies to provide the two interface components (Modems and ALE Units) and all of the underlying communications infrastructure.   Isode provides all of the software needed above this. A key Isode focus is application sets to support Formal Military Messaging, general purpose email, and XMPP real time messaging and presence. These are core Isode products. Isode also provides a framework to support other applications.

The choice of application needs to be tempered by the limits of HF: interactive streaming video is unrealistic, even with the very best HF communications. However, applications currently deployed over HF are very limited, and much more can be achieved. Isode aims to enable any plausible application to be supported over HF Radio.

While supporting applications is the primary goal, this needs a range of supporting and management technologies in order to deliver the applications effectively. These need to be considered as part of the total solution.

Current HF Deployments for Data

Improvements in Digital Signal Processing (DSP) have enabled significant improvements in HF over the last 30 years. In 1990, available HF waveforms went up to 1200 bps. Automatic Link Establishment (ALE) was introduced in the 1990s, and new faster waveforms such as STANAG 4539 were added, going up to 9600 bps and providing auto-baud. This period also saw the introduction of STANAG 5066 to provide data transfer over HF. HF deployment has been dominated by voice and by the three applications described below.

STANAG 5066

STANAG 5066 is the NATO data link protocol over HF, described in the whitepaper [STANAG 5066 - The Standard for Data Applications over HF Radio] and implemented in Isode’s Icon-5066 product. Use of STANAG 5066 is central to Isode’s approach of applications running over HF.

BRASS and ACP 127

BRASS (Broadcast and Ship to Shore) systems are deployed by many NATO nations as part of their naval communication. A description of BRASS is given in the Isode white paper [Isode's Solution for BRASS (Broadcast and Ship to Shore)]. The BRASS service supports a single application: formal military messaging using the ACP 127 protocol.

The core of a BRASS service is a continuous HF broadcast, typically at 300-1200 bps, going out to multiple ships. There is a flow of ACP 127 messages, with RECAP messages sent at hourly intervals. The broadcast will generally go out on several frequencies (typically four or five) to allow ships to select a frequency that works. The BRASS Service will use OTAM (Off The Air Monitoring) to select the best frequencies to broadcast on. Ships may be in EMCON, and so not able to respond to broadcast messages.

In addition to the core broadcast, the BRASS service makes use of three types of point to point link:

  1. Ship to Shore. A special link that supports message flow from a ship to shore and request to re-send missing or corrupt messages. Frequency Assignment Broadcast (FAB) is used to allow ships to share a pool of HF frequencies for ship to shore communication.
  2. Ship to Ship: to support direct communications between ships.
  3. Maritime Rear Link (MRL). A link between selected ships (usually “Command Afloat”) and shore, supporting message flow in both directions.

STANAG 5066 provides a link layer over HF to ensure data integrity and reliability and to allow multiple applications to share an HF link. Modern BRASS systems will use STANAG 5066 ARQ for point to point links. However, it is not possible to use STANAG 5066  for ACP 127 broadcast, so BRASS broadcast operates without a link layer. This gives a number of problems; in particular messages can be corrupted in transit.

Link-11 / Link-22

Link-11 is a NATO Command and Control (C2) protocol which can be used over HF and other links to support tactical communication using standardized short message. Link-22 provides an update to Link-11 operation over HF. Link-11 and Link-22 define an HF link layer and do not use STANAG 5066. The approach is a fixed Timed Division Multiple Access (TDMA) approach, with specific mappings onto various waveforms. When Link 11/22 are used over HF, they need exclusive access to the HF modems. It is not possible to share with other applications, although there is potential to achieve sharing by defining a new Link 11/22 mapping onto STANAG 5066. Isode sees this as a desirable direction, to enable sharing of HF infrastructure.

STANAG 5066 CFTP

Compressed File Transfer Protocol (CFTP) is defined in Annex F of STANAG 5066 as the service and also known as Battle Force Email (BFEM). It provides a simple and efficient mapping of the standard SMTP mail protocol onto HF but provides only a subset of SMTP features. CFTP is widely used in Naval deployments to provide informal email services.

Improving HF Technology

Since the introduction of STANAG 5066 and the applications described above, new technology has enabled a number of improvements.

STANAG 4539

STANAG 4539, published in 2005, defines a new set of HF waveforms that give throughput of up to 9600 bps on a 3kHz channel. This gave significant performance improvements relative to the older waveforms and leads to opportunity to use a wider range of applications.

STANAG 4539 is also “auto baud”; the receiver can work out the transmission speed. This enables STANAG 5066 data rate change to be faster and more robust.

Automatic Link Establishment (ALE)

BRASS systems need a high level of operator support, in part to deal with ACP 127 and in part to handle link configuration and the associated frequency management. ALE can automate frequency selection and also replace the BRASS-specific FAB protocol. ALE is being increasingly adopted for use with STANAG 5066.

There are various ALE standards. 2G (second generation) ALE is the most widely deployed. 3G ALE has now been superseded by 4G ALE. 4G ALE provides all of the benefits of 2G (asynchronous) and 3G ALE (synchronous) as well use using “staring” to provide linking times of around 2 seconds. Use of ALE is seen as highly desirable for most HF deployments.

Wideband HF

STANAG 5069 which specified Contiguous Wideband HF (WBHF) and STANAG 4539 Annex H which specifices non-contiguous widedband (HFXL) are exciting developments. There are a number of STANAG 5069 products on the market. 4G ALE is needed with WBHF for bandwidth selection. HFXL will need special ALE.

Changes to STANAG 5066 are needed to usefully support applications running over WBHF/HFXL. Isode has proposed and implemented changes to address the two key problems in [Data Rate Selection in STANAG 5066 for Autobaud Waveforms (S5066-EP4)] and [STANAG 5066 Large Windows Support (S5066-EP5)].

Multi-node HF Networks

BRASS uses broadcast and point to point communication. STANAG 5066 Ed3 introduces two options to enable multiple nodes to share a single frequency. This can be helpful, to share use of a limited number of frequencies and to support multicast operation. The options are:

  • Annex K defines a CSMA (Carrier Sense Multiple Access) approach, which is a good choice where link utilization is low.  
  • Annex L defines a Wireless Ring Token Protocol, which is a good choice when link utilization is high.

A multi-node network has an explicit set of nodes which may all transmit, as distinct from a broadcast network where there is a transmitter and no direct response from other nodes. This enables two possibilities not available in broadcast systems such as BRASS:

  1. It enables pairwise ARQ communication between each pair of nodes on the network. Operating in this manner can be much more efficient that each pair of nodes looking for a dedicated frequency using ALE and then dropping the link after transmission, particularly where there are very few frequencies to use.
  2. It enables multicast communication, using protocols such as ACP 142. This allows messages to be sent once to multiple destinations, with efficient acknowledgement. It can enable significant optimization for some traffic patterns.

Multi-node networks provide a flexible option for HF networks.

Market Requirements for the New HF Technology

BRE1TA, BRE2TA and BRIPES

NATO introduced the BRE1TA (BRASS Enhancement 1 Technical Architecture) in 2008, as a vision for moving the BRASS program forward to take advantage of HF technologies introduced since the original BRASS design. The BRE1TA Capability Vision and Strategy presented in February 2008 was:

  1. Enhanced messaging: X.400 (STANAG 4406 Annex E) and Simple Mail Transfer Protocol (SMTP) over the air between shore & deployed forces.
  2. Directory services in accordance with X.500/Allied Communication Publication (ACP) 133
  3. Higher HF bandwidth and throughput with introduction of STANAG 4539 HF Data Modems
  4. Support for Automated Radio Control (ARC) and Automated Link Establishment (ALE) through the introduction of STANAG 4538 (3G ALE).
  5. Provision of IP over HF services (e.g. Data/Web) in conformance with STANAG 5066

The first four goals have been demonstrated as achievable, and the Isode solutions to support these are described below. The use of IP in the manner envisioned is not operationally viable. The issues with this are discussed below and an alternative viable approach is set out.

Subsequent to the original BRE1TA, two key HF developments have occurred:

  1. STANAG 5066 ed3 had introduced a framework for supporting multi-node networks and in particular Annex K (CSMA) and Annex L (Wireless Token Ring) that provide useful new capabilities for BRASS/BRE1TA type deployments.
  2. STANAG 5069 has introduced wideband HF (WBHF) capabilities up to 240 kbps using 16 contiguous 3kHz channels and the HFXL alternative using non-contiguous channels. 

NATO is actively procuring BRE1TA components with the BRIPES (BRASS IP Enhanced System) project. This extends the original BRE1TA requirements with multi-node networks using CSMA and WTRP. It also adds XMPP services, as described later and various management requirements, which are supported by current and planned Isode products.

Wideband HF has been deferred to an anticipated BRE2TA (enhancement 2) project.

National HF Refresh Projects

HF is an ongoing requirement for many nations. National systems are generally updated with a long lifecycle. The better procurements lead by investigating what is technically feasible and then intersecting this with operational requirements. This paper aims to give a useful summary of what is feasible.

Applications for HF

To operate efficiently over HF, applications need to be optimized. This section looks at applications and the Isode products that support them.

Messaging

Isode provides a comprehensive solution for both military messaging and informal email over HF with it’s M-Switch product. M-Switch supports several protocols optimized for operation over HF, which are described in the Isode whitepaper [Messaging Protocols for HF Radio]. Performance analysis is given in [Measuring Performance of Messaging Protocols for HF Radio].

Messaging Management

Messaging is a primary “bulk” application used over HF and operator management is critical, because queues can build up. Operators need to be able to delete and prioritize traffic under high load conditions. This needs to be used in conjunction with STANAG 5066 management, as at the application level it can be hard to distinguish between things not working and correct but slow HF operation. M-Switch provides the following MConsole operator features to support messaging management:

  • ACP 127 View, which has a number of necessary operator features to handle ACP 127-specific management.
  • ACP 142 View, which has specific multicast and EMCON support features.
  • General queue management View for CFTP, SLEP and other Messaging protocols where queues may build up.

Message Tracking is also important, which is supported in MConsole. It is desirable to use end to end notifications to confirm delivery, which is supported by modern messaging protocols.

Military Messaging

Formal Military Messaging is a key HF application, which currently is mainly provided using ACP 127. There are a number of downsides to using ACP 127:

  • The way that ACP 127 works in BRASS needs a high level of operator support.
  • Limited character set (including lack of lowercase letters).
  • No Attachments.
  • No Message Forwarding.
  • No Acknowledgements (Delivery Reports or Read Receipts).
  • Direct to modem mapping for broadcast means that messages can be corrupted.

Modern protocols can be used to provide a much improved military messaging service. The recommended message transport is ACP 142 “"P_Mul – A Protocol for Reliable Multicast Messaging in Constrained Bandwidth and Delayed Acknowledgement (EMCON) Environments". ACP 142 can be used over point to point, broadcast and multicast links using STANAG 5066 non-ARQ.

There are two protocols for military messaging that can be used over ACP 142:

  1. STANAG 4406 Annex E over ACP 142 is the NATO standard for constrained bandwidth operation. It is also the BRE1TA target.
  2. MULE (Multicast Email) specified in RFC 8494 enables  SMTP messaging operates over ACP 142 with military extensions provided using RFC 6477 as described in Military Messaging (MMHS) over SMTP.

This provides two excellent options to move forward from ACP 127. M-Switch facilitates migration as it supports both ACP 127/BRASS capabilities and ACP 142.

Isode’s Harrier client, shown above, can be used to provide military messaging services over both ACP 142 and ACP 127 with a modern Web interface.

Informal Messaging

Informal messaging (email) is a desirable service, typically provided over HF using CFTP (STANAG 5066 Compressed File Transfer). MULE over ACP 142 is Isode’s recommended protocol stack, with the following benefits over CFTP:

  • Use of ACP 142 enables multicast operation and supports EMCON.
  • Supports NOTARY, which enables control of Delivery Status Notifications, and in particular the ability to request positive DSNs for message tracking.
  • Support 8BITMIME and BINARYMIME which will optimize performance for binary data.
  • Removes the 128 MByte maximum message size, which will be important with move to WBHF.

Directory Provision Synchronization

Directory is a critical service for military communication and ACP 133 directory services enables directory provision in a federated manner using LDAP or X.500 access. BRE1TA requires such a directory service, which can be supplied by Isode’s M-Vault product.

Isode’s Cobalt (planned) product provides Web provisioning of users and accounts for the Isode applications. This can be used to provision users for a Mobile Unit (ship or plane) on shore, with replication to the Mobile Unit.

It would be inefficient to perform directory access over HF, so the sensible architecture is to have a directory server at each node, and to synchronize directory services over the HF link. 

Directory Synchronization can be provided in a simple and efficient manner over messaging, as described in [Directory Replication by Email and over 'Air Gap'] using Isode’s Sodium Sync product. It is straightforward to provide this service using the core messaging service to communicate directory updates.

XMPP Instant Messaging

Military Instant Messaging is a service that has become mission critical for many military deployments. XMPP is The NATO standard for real time messaging and presence, which is used in the NATO JCHAT service that uses Isode’s M-Link server. M-Link can be used with a number of XMPP clients, including Isode’s Swift product. M-Link provides a number of capabilities for constrained networks described in the Isode white paper [Operating XMPP over HF Radio and Constrained Networks].

M-Link supports optimized operation over HF using XEP-0365: Server to Server communication over STANAG 5066 ARQ. This enables efficient XMPP operation over HF, which has been demonstrated and measured in a UK MoD trial described in UK MoD XMPP over HF pilot.

Other HF Optimized Services

Two other services that Isode plans to provide over HF are:

  • Peer discover and throughput/latency testing. This will follow the protocols specified in HF Discovery, Ping and Traffic Load (S5066-APP2). This will facilitate network management.
  • Geolocation. It is important to know the location of Mobile Units. Current protocols to achieve this operate at modem level on black side. It would be desirable to operate over STANAG 5066, as this pushes information to red side and allows traffic to co-exist with other STANAG 5066 traffic. Isode will publish and implement an appropriate protocol.

IP Services

It is sensible that mission critical applications are provided using optimized protocols. However, it is impractical to do this for every service, so it is desirable to have mechanisms to support generic services that run over IP in high speed networks.

IP Client

STANAG 5066 defines an IP Client in Annex F.12, which provides a generic IP subnet service over HF. BRE1TA envisaged that this would give a generic way to provide IP services over HF, following a standard subnet architecture.

IP Client works well for some low volume services such as ICMP Ping. It is viable for services such as Domain Name Service, although inefficient as application timers lead to traffic duplication. Performance for services operating over TCP is dire.  This is a consequence of the architecture and not something that clever implementation can optimize. Measurements and detailed analysis are given in the Isode whitepaper [Measuring and Analysing STANAG 5066 F.12 IP Client]. This is problematic as most applications, including HTTP Web Access (a key BRE1TA target and base for many modern applications) use TCP.

HF TCP Proxy & Icon-PEP

To provide IP services over HF in a reasonably efficient manner, a central challenge is to provide a mechanism to support TCP-based applications efficiently. This can be done with a TCP PEP (Performance Enhancing Proxy) as shown in the diagram above supporting HTTP. By using an optimized protocol over HF, the system inefficiencies of TCP over IP Client can be avoided. Isode’s approach is to use [SIS Layer Extension Protocol (SLEP)] (S5066-APP3)]. Note that although this eliminates TCP inefficiency, it cannot address applications with short timeouts or significant hand shaking.

Isode’s (planned) Icon-PEP product will provide an HF TCP Proxy to efficiently support TCP applications over HF. It will also support IP Client to support other IP applications, the choice of ARQ or non-ARQ can be configured based on IP or UDP protocol.

Application Mobility & Icon-Topo

When Mobile Units (typically ships and planes) using HF communication move, it is often needed to change ground stations. Optimal communication over HF uses application level protocols, so this re-rerouting needs to happen at the application level. Solving this problem is the target of Isode’s (planned) Icon-Topo product, which addresses:

  • Messaging communication between Mobile Units and Fixed Systems.
  • XMPP communication between Mobile Units and Fixed Systems.
  • Web access from Mobile Units to Fixed Systems.

Icon-Topo has two types of ground systems to support Mobile Units (MUs):

  • HF Access Points (HFAP). These are sites that will transmit/broadcast HF.
  • Fixed Access Routing Entry Points (FAREP). These are systems, possibly co-located with HFAPs, that fixed systems route to. Systems external to the FAREP can send traffic for an MU to the FAREP, without needing to know the location of the MU.

Messages and XMPP traffic can be sent to a FAREP, and it will be correctly routed to the right MU. An Icon-Topo operator can assign an MU to a new HFAP. Icon-Topo will change application routing configuration of FAREP, HFAPs and MU to reflect this change. This allows operators to assign MUs to FAREPs and managed underlying ALE and HF systems.

Configuration of MUs/HFAPs/FAREPs is stored in a replicated LDAP/X.500 directory. Servers on shore use multi-master replication, so updates can be applied at any node. Incremental directory replication (Isode Sodium Sync product) with transfer by messaging over HF keeps the MU directory synchronized. This is shown below.

Operators can configure nodes using Icon-Topo and provision users for any node using Cobalt from any shore location. The data will be efficiently replicated.

A key problem that Icon-Topo needs to address is that all routing changes need to happen at once, but propagation of directory updates over HF may take some time. Icon-Topo handles this by providing a scheduling layer over the directory, so that the changes are always made in context of the time they are to be applied. So, an operator may schedule a series of MU movements at times in the future. This information gets replicated ahead of the time that the changes need to be applied.

Icon-5066

Icon-5066 is Isode’s STANAG 5066 server. It sits above ALE Units and Modems, which are provided by Isode partners; A central Icon-5066 approach is to be ALE Unit and Modem independent, so that any devices can be supported with appropriate drivers. Applications and management above Icon-5066 are provided by Isode, as shown in the diagram below.

Icon-5066 is a software product with the following core characteristics:

  • Runs Windows or Linux.  
  • Multiple STANAG 5066 nodes can be configured in single service.
  • Flexible configuration to deal with wide range of deployments.
  • Supports Broadcast, Duplex and Half Duplex operation.
  • ALE support for connection to single peer; ALE connect prior to data transfer.
  • Support for 2G, 3G and 4G ALE.

Management

Good monitoring of the STANAG 5066 layer is vital operational support in order to verify that current operation is optimal and to note failures quickly. Icon-5066 provides Web monitoring (shown above) and a single node can be monitored from multiple locations.  Key features:

  • Show bound SAPs and activity. Modern STANAG 5066 systems are expected to support an increasing number of applications multiplexed by STANAG 5066. It is helpful to know which applications are operational and load being applied.
  • List of known peers, with information on current activity and ARQ windows.
  • Current Rx/Tx status, with progress bar on the current data transfer.
  • Previous Rx/Tx information, so that interaction and changes can be easily observed.
  • STANAG 5066 level performance metrics and analysis.
  • ALE connections and status.
  • Radio and Power Amplifier information, which can be helpful to diagnose problems.

Wideband HF

Icon-5066 provides full support for operation using STANAG 5069 (contiguous waveform) up to 240 kbps. Key capabilities:

  • Support for [STANAG 5066 Large Windows Support] (S5066-EP5), which is key to achieving good performance with wideband and higher narrowband HF speeds.
  • Support for [Data Rate Selection in STANAG 5066 for Autobaud Waveforms] (S5066-EP4). This is an alternative to STANAG 5066 Ed3 data rate change.  It allows data rate selection over the full range of STANAG 5069 speeds. It provides a superior rate selection model, which allows Icon-5066 to select more conservative speeds when only a small amount of data is being transferred. This improves resilience and performance.
  • Integration with 4G ALE, which selects channel bandwidth for a link.

CSMA

STANAG 5066 provides a CSMA (Carrier Sense Multiple Access) approach for sharing a single channel in STANAG 5066 Ed3 Annex K. This is a good way to share a channel when load on the channel is relatively light.

The “jitter” approach defined in Annex K works well for a channel shared by a large number of nodes for ARQ protocols.  Collisions are avoided by a randomized timer on starting transmission. Although a potentially useful architecture, it is anticipated that large networks will generally use ALE to select frequency, with a separate channel for each 1:1 communication.

Icon-5066 supports basic Annex K operation and extends this with Slotted Option for STANAG 5066 Annex K (S5066-EP6). This provides an effective mode for a small number of nodes and facilitates non-ARQ protocols such at ACP 142. This is a good option for sharing a channel where load is light.

Token Ring

STANAG 5066 Ed3 Annex L defines Wireless Token Ring Protocol (WTRP), which provides the best model for sharing an HF channel between a set of nodes under higher load. It is particularly suitable for Naval surface wave communication, as reflected in the above diagram (which is taken from STANAG 5066).

Support for WTRP is planned in Icon-5066, following two new specifications:

  1. [HF Wireless Token Ring Protocol] (S5066-EP12) addresses a number of critical deficiencies in Ed3 Annex L and is offered as an update for use in STANAG 5066 Ed4.
  2. [STANAG 5066 Routing Sublayer] (S5066-EP13) adds a routing layer to STANAG 5066.  This is needed to support scenarios where not all WTRP nodes can communicate directly (e.g., “three ships in a line”). WTRP supports such topologies, but the routing layer is needed to exchange data.

M-Guard and Red/Black Separation

Military HF deployments have a red side where sensitive data is held and a black side where hardware such as radios reside. User data (red side) is always encrypted when it passed to black side. HF systems have the need to exchange data between read and black sides, which is discussed in this section.

M-Guard

M-Guard is an Isode product that provides an XML guard for checking XML content exchanged across network boundaries. M-Guard can act as an application-level data diode.

M-Guard is intended for use on red/black boundaries and it is planned to get product accreditation for this usage. M-Guard is provided as an appliance which can be run on hardware (e.g., Netgate SG-5100 reference hardware) or as a Virtual Machine.  

M-Guard communicates using the open Guard Content eXchange Protocol (GCXP). This gives a secure mechanism for transferring content to and from M-Guard. GCXP enables new applications to make use of M-Guard. It also enables different XML guards to be used by applications that support GCXP.

STANAG 5066 Crypto Bypass

STANAG 5066 is designed for the server to sit red side, as it handles un-encrypted user data and has sensitive information in the protocols. STANAG 5066 needs to communicate with modems and ALE units that sit black side. Basic operation can be achieved with just a crypto box. Additional communication across the red/black boundary is needed for:

  1. Modem speed and interleaver control. This is desirable to optimize performance in varying conditions. This is often of high importance.
  2. Communication of ALE setup. This is a part of modern HF communication and needed for WBHF bandwidth selection.

The lack of appropriately secure crypto bypass has led to two situations:

  1. Operation at fixed speed without ALE, where security accreditation will not approve any crypto bypass.
  2. System accreditation of simple crypto bypass approaches.

Icon-5066 can utilized M-Guard to provide modern secure crypto bypass, as shown below.

Icon-5066 remains red side, and the interaction with M-Guard is configured as a special proxy modem driver that communicates with two M-Guard instances (which may be running on a single appliance).  

On black side is a separate Modem Control server (part of the Icon-5066 product set) that communicates with the same M-Guard pair and communicates directly with black side modem and ALE unit. 

Communication between red and black side is two unidirectional flows of XML messages, which can be controlled by M-Guard to ensure that only allowed monitoring and control messages pass across the boundary.

Red/Black

HF systems have a related and more generic management problem. Operators will generally have primary access on red side. It is convenient to be able to monitor and control black side devices from red side, particularly in scenarios where there is no direct physical access to black side systems (e.g., a remote transmit site).

Isode’s (planned) Red/Black product addresses this, by providing Web monitoring and control of arbitrary black side devices. It works in the following way:

  • There are red and black side Red/Black servers communicating securely through a pair of M-Guard servers across the red/black boundary. Message flow can be limited to agreed control and monitoring with provisioned black side devices.
  • Devices types are defined by an abstract (XML) device specification.   
  • Devices of various types can be provisioned on both red and black sides.
  • Red side Web UI can manage devices on both sides, with the UI automatically generated from device type specification and provisioning.
  • Each black side device type will need a driver to be developed. This communicates with red/black using a simple protocol. Isode will provide a number of sample device drivers in multiple programming languages to facilitate device driver development.

Encryption Approaches

Data is always encrypted at the red/black boundary. This section describes three approaches to achieve this.

Synchronous Serial

STANAG 5066 Ed3 Annex D defines use of a synchronous serial interface as the means of interface to the lower layers.   This is then used in conjunction with synchronous serial crypto devices such as KIV-7 with clocking provided by the modem. Icon-5066 provides support for synchronous serial hardware to achieve this integration.

Use of special hardware increases costs, reduces deployment flexibility and makes system redundancy and failover harder to achieve.

Use of synchronous serial also leads to performance problems which are hard to address. This is described in the Isode white paper Reducing Turnaround Times in STANAG 5066.

These problems with synchronous serial and national crypto modernization problems are expected to lead to replacement of synchronous serial medium/long term.

Modem Layer Crypto and Icon-TRANSEC

The STANAG 5066 crypto architecture as shown above is specified in the STANAG 5066 specification. This is a good architecture - the difficulties are with use of synchronous serial, not with the architecture.

[STANAG 5066 TRANSEC Crypto Layer using AES and other Protocols] (S5066-EP14) specifies a software approach to providing this crypto layer. It defines specific support for the AES encryption algorithm and gives a framework for supporting other algorithms. It specifies an efficient HF-oriented approach to maintaining crypto synchronization.

Icon-TRANSEC is a planned Isode product that supports “STANAG 5066 TRANSEC Crypto Layer using AES and other Protocols” (S5066-EP14). It is built as a discrete product so that it performs encryption only and can be accredited independently from Icon-5066 and can be run as an appliance with Icon-5066 red side and Modem black side.

Isode Serial Proxy Protocol (ISPP) is an internal Isode protocol that is used withing Icon-5066 to abstract out serial data functionality in a manner appropriate for STANAG 5066 data transfer. It is a “vertical” protocol with no end to end implications. ISPP is used to communicate between Icon-5066 and Icon-TRANSEC (red side).

Icon-TRANSEC can communicate directly with an HF modem (black side) using the “vertical” TCP protocol specified in MIL-STD-188-110D Annex A. Icon-TRANSEC can also communicate with ISPP black side which allows use of an Icon-5066 modem driver to communicate with modems using serial or proprietary data interfaces.

IP Crypto

It is important to provide COMSEC encryption to provide appropriately secure protection of user data. Isode believes that the technically best architecture to achieve this is to provide COMSEC as part of the TRANSEC specified in the previous section.  

There is clear interest to utilize IP Crypto devices in HF systems, so that products following the HAIPE security architecture such as TACLANES can be used with HF to provide COMSEC. This allows use of accredited crypto and avoids the need to either use synchronous serial or to accredit new HF modem level crypto.

Isode has specified four open protocols and an architecture to achieve use of IP Crypto with STANAG 5066. This is set out in the white paper [Using IP Crypto over HF]. This approach moves STANAG 5066 from red side to black side and uses IP Crypto at the red/black boundary. It is specified by building new protocols around STANAG 5066 and does not need any changes to STANAG 5066.

Isode plans two new products to support this architecture:

  1. Icon-SIS (red side).
  2. Icon-IP (black side)

New Open Protocol Specification Summary

The vision set out in this paper needs a number of new protocols. Isode has defined the necessary protocols in two series:

  1. STANAG 5066 Extension Protocols. Index in S5066-EP1. This is a series of specifications that makes changes to the core of STANAG 5066.
  2. STANAG 5066 Application Protocols. Index in S5006-APP1. This is a series of specifications to be used in conjunction with STANAG 5066 that do not need changes to STANAG 5066.

These are open specifications, offered to NATO for inclusion in the planned STANAG 5066 Ed4. A list of the specifications needed by the capabilities set out in this whitepaper are listed below.

Specification Title Notes
S5066-EP2 STANAG 5066 Padding DPDU Improves performance and reliability
S5066-EP4 Data Rate Selection in STANAG 5066 for Autobaud Waveforms Improved rate selection. New speeds needed for WBHF
S5066-EP5 STANAG 5066 Large Windows Support Improves WBHF and fast narrowband performance
S5066-EP6 Slotted Option for STANAG 5066 Annex K Improves CSMA for small networks
S5066-EP7 Advertising Extended Capabilities Facilitate interoperability with new features
S5066-EP10 Extension DPDU Allows more D_PDUs to be added
S5066-EP12 HF Wireless Token Ring Protocol Update to Annex L to address critical problems
S5066-EP13 STANAG 5066 Routing Sublayer Support for WTRP data transfer in partially connected systems
S5066-EP14 STANAG 5066 TRANSEC Crypto Layer using AES and other Protocols Modern approach to modem layer crypto
S5066-APP2 HF Discovery, Ping and Traffic Load Facilitates testing and network discovery
S5066-APP3 SIS Layer Extension Protocol (SLEP) RCOP and UDOP replacement. Streaming service needed for HF TCP PEP
S5066-APP4-7   A set of protocols to support use of IP Crypto with STANAG 5066

There is ongoing work on STANAG 5066 Ed4.  FMV (Sweden) are leading the update and Isode is leading the technical work. We have publised drafts of STANAG 5066 Ed4, they incorporate the functionality of all of the extension protocols (EPs) listed above.

Conclusions

This paper has set out a vision for modern application deployment over HF. This requires a wide range of capabilities at all layers of the stack and is very different to older deployments where simple applications were built directly over the modem. It shows how modern protocols can be supported well and sets out new open protocols and Isode products to achieve the vision.