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 two interface components (Modems and ALE Units) and all of the underlying HF 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. Then there is a framework to support a wide range of generic IP services over HF, in particular Web browsing over HF, plus a number of HF-specific services.

The choice of applications deployed 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.

In order to support applications, there needs to be a range of supporting and management technologies to deliver the applications effectively. These need to be considered as part of the total solution.There also needs to be careful planning for switching between HF and other data links.

Legacy HF Deployments for Data

In 1990, available HF waveforms such as STANAG 4258 went up to 1200 bps and were used with just the two data applications: ACP 127 and Link-11. These systems are still in use and central to a lot of HF application planning.

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 a selected ship (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 optimal to use STANAG 5066  for ACP 127 broadcast, so BRASS broadcast generally operates without a link layer. This gives a number of problems; in particular messages can be corrupted in transit.

Link-11

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.

Improving HF Technology

Improvements in Digital Signal Processing (DSP) have enabled significant improvements in HF over the last 30 years. 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

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. It is widely replacing older narrowband HF waveforms.

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

Automatic Link Establishment (ALE)

Automatic Link Establishment (ALE) is a key capability for automating link setup and is expected to become universal for point to point links.

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.

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.

STANAG 5066

STANAG 5066 is the NATO data link protocol over HF, described in the Isode 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.

STANAG 5066 Ed 1 was published in 2000, and was designed to work with non-autobaud waveforms and without ALE. Support of autobaud waveforms was partially addressed in Ed2 (2005).

The latest version is Ed4, summarized in the Isode white paper [STANAG 5066 Edition 4], which introduces the standard and also shows Isode’s central role in developing this standard. Ed4 provides full support for autobaud waveforms and specifies use of ALE by STANAG 5066.

STANAG 5066 CFTP

Compressed File Transfer Protocol (CFTP), also known as Battle Force Email (BFEM), is specified in Annex V of STANAG 5066 ed4. 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.

CFTP has generally replaced the older HMTP (HF Mail Transfer Protocol) and is expected to be replaced by ACP 142/MULE in the future.

Link-22/NILE

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. Link-22 is often referred to as NILE (NATO Improved Link Eleven). The approach is a fixed Timed Division Multiple Access (TDMA) approach, with specific mappings onto various waveforms.

When Link 22 is used over HF, it needs exclusive access to the HF modems; It is not possible to share with other applications. It would be possible to achieve sharing by defining a new Link 11/22 mapping onto STANAG 5066, which Isode sees as a desirable direction. This is described in the Isode white paper [Tactical Data Links: Potential Communication Enhancements.]

Most Recent HF Standards

This section looks at the most recent HF Standards which are relevant to HF deployments and are expected to be important for data applications over HF.

Wideband HF

STANAG 5069, which specifies Contiguous Wideband HF (WBHF) and STANAG 4539 Annex H, which specifies non-contiguous wideband (HFXL) are important new standards giving possibility for greater throughput and improved reliability. There are a number of STANAG 5069 products on the market. 4G ALE is needed with WBHF for bandwidth selection.

STANAG 5066 Ed4 addresses support of STANAG 5069 contiguous WBHF, addressing issues in Ed3 that limited use to narrowband HF.

Multi-node HF Networks

BRASS uses broadcast and point to point communication. Other current deployments are point to point. STANAG 5066 provides 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 WTRP (Wireless Token Ring 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 than 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

These goals have been demonstrated as achievable, and the Isode solutions to support these are described below.

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

1. STANAG 5066 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 has procured 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 that deliver BRE1TA capabilities.

Wideband HF has been deferred to an anticipated NATO 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 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 its 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 using an underlying Audit Database. 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 is still commonly 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. Isode's 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 and 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, and enables message routing between the different protocols.

A key gap in migration away from ACP 127 is support for broadcast and a full BRASS replacement. Isode has proposed protocols to achieve this in HF Broadcast Protocol (HFBP) S5066-APP11 .

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, commonly 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 (DSNs), 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 may be helpful with the 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 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. This provisioning is described in the Isode whitepaper [Provisioning for Military Messaging Handling Systems].

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

• Peer discovery and throughput/latency testing facilitate network management. Isode currently provides this service, which we plan to update to follow the protocols specified in HF Discovery, Ping and Traffic Load (S5066-APP2).
• File transfer optimized for HF is provided by Isode's HFFTP product, following the protocols specified in HF File Transfer Protocol (HFTTP) -S5066-APP8.
• 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 plans to provide this service using the protocols specified in HF Location & Information Sharing Protocol - S5066-APP10.

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. This can enable a wide range of IP Services to be provided over HF.

IP Client

STANAG 5066 Ed4 defines an IP Client in Annex U (updating and enhancing STANAG 5066 Ed4 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.

Isode’s Icon-PEP product supports IP Client, which is useful to provide low volume UDP services such as DNS and supporting services such as ICMP Ping.

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 Icon-PEP provides an HF TCP PEP service. This uses [HF-PEP: STANAG 5066 TCP Performance Enhancing Proxy Protocol (S5066-APP9)], which in turn makes use of the streaming service specified in  [SIS Layer Extension Protocol (SLEP) (S5066-APP3)].The diagram above shows how Icon-PEP supports the TCP PEP model and connects efficiently over HF. Note that although the TCP PEP architecture eliminates TCP inefficiency, it cannot address applications with short timeouts or significant hand shaking. However, this is not an issue for a wide range of applications. Further information on this architecture and Icon-PEP is provided in the Isode whitepaper [Measuring and Analysing HF-PEP for TCP communication and Web Browsing over HF]. 

HTTP Services and Web Browsing

Many modern applications run over HTTP, the Web protocol, which in turn runs over TCP. This is important both for embedded applications and to support a user Web service. The core messaging services provide “push” services, useful to send data to mobile units. Web browsing provides a complementary “pull” service to allow mobile units to access data. Icon-PEP can be used to provide a Web service which when appropriately configured can provide a viable service using narrowband HF. This is described in the Isode whitepaper [Measuring and Analysing HF-PEP for TCP communication and Web Browsing over HF]

Application Mobility & Icon-Topo

When Mobile Units (typically ships and planes) using HF communication move, they will quite often need to change ground stations as they carry out their path. 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 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 manage underlying ALE and HF systems. The Icon-Topo UI to configure this is shown below with a map based UI.

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.

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. Further details are provided in the Icon Topo Whitepaper.

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 on a single server.
• Flexible configuration to deal with wide range of deployments.
• Supports Broadcast, Duplex and Half Duplex operation.
• ALE support for connection to single peer.
• Configuration of HF Networks and ALE parameters.
• 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 have a 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. This follows STANAG 5066 Ed4, including support for new data rate selection mechanisms, large window support and 4G ALE.

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 the Slotted Option added in STANAG 5066 Ed4. 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 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).

WTRP is supported in Icon-5066. More information can be found in the whitepaper [Wireless Token Ring Protocol].

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 passes 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. M-Guard is provided as a software appliance which can be run on hardware (e.g., Netgate 6100 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 utilize M-Guard to provide modern secure crypto bypass, as shown below.

Icon-5066 remains red side, and communicates control and monitoring information with two M-Guard instances (which may be running on a single appliance).  

On black side is a separate Proxy 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 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 for the device. This communicates with red/black using a simple protocol. Isode provides a C++ driver to facilitate device driver development.

Further details on Red/Black are provided in Red/Black Whitepaper

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 Ed4 Annex T 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 encryption algorithms. It specifies an efficient HF-oriented approach to maintaining crypto synchronization.

Icon-TRANSEC is a planned Isode product that supports STANAG 5066 Ed4 Annex T.

Isode Serial Proxy Protocol (ISPP) is an internal Isode protocol that is used within 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)

Prototypes of these products have been implemented and performance measurements to validate the architecture are included in the white paper.

New Open Protocol Specification Summary

The vision set out in this paper needed 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 S5066-APP1. This is a series of specifications to be used in conjunction with STANAG 5066 that do not need changes to STANAG 5066 Core.

These are open specifications. Most of the S5066-EP series specifications have been included in STANAG 5066 Ed4, and so these are mainly of historical interest.

Isode is strongly advocating that Block Based EOTS (S5066-EP8) is included in STANAG 5066 Ed5, which is now being considered by NATO.

All of the S5066-APP series specifications have either been implemented by Isode or are planned for implementation. They are referenced earlier in this paper.

Isode believes that all of the S5066-APP series specifications would add value to STANAg 5066 Ed5. A detailed proposal is in the Isode white paper STANAG 5066 Edition 5 Proposed Additions.

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.