Icon-PEP enables deployment of IP Applications over an HF Radio using a STANAG 5066 link layer. Icon-PEP supports IP packet switching and provides optimized support for TCP applications, such as Web Browsing and Command and Control (C2),  using a Performance Enhancing Proxy (PEP).

It generally provides two core services

1. Generic switching of IP packets over an HF network, causing it to act as an IP subnet. This enables support of any IP applications.
2. Optimized support for TCP over IP using a Performance Enhancing Proxy (PEP) to optimize TCP performance over HF.

You can learn more about Icon-PEP here.

TLS Proxy

The core TCP PEP capability provided by Icon-PEP is to provide a proxy for TCP streams over HF. This follows STANAG 5066 Ed5 Annex X.

When TLS (Transport Layer Security) is used over TCP with a basic Icon-5066 configuration, the TLS is end-to-end.

Icon-PEP 2.1 adds a capability to proxy the TLS, and break the TLS link as well as the TCP one. This improves performance over HF by removing handshaking and adding compression. It enables some applications to work over HF, which will not work without this capability due to application timeouts. These changes follow STANAG 5066 Ed5 Annex X and include support for SNI (Server Name Indication) and ALPN (Application Level Protocol Negotiation).
There are two modes:

1. Server Authentication. This is for applications such as Web browsing, which support authentication of the server. This mode can be used transparently, for example, to support Web browsing to many sites using HTTPS.

2. Two-Way Authentication. This is for applications using TLS client authentication. This is supported in Icon-PEP by configuring both ends of the connection

Direct Mode

The core model of Icon-PEP is to interface to an IP router using GRE, so that use of Icon-PEP is controlled by IP routing and is transparent to the user. This is enhanced by a NAT mode, which is designed for an Icon-PEP server on shore, where connections are initiated by Mobile Units. In NAT mode, Icon-PEP connects directly to the end TCP or UDP system, without using a connected IP router. This is helpful to support Mobile Unit mobility.

Icon-PEP 2.1 adds a new direct mode, so that there is no direct IP router connection on either side. TCP and UDP Applications connect directly to Icon-PEP. This provides a simpler configuration in scenarios where there is no benefit from the default IP Routing approach.

TAK Support

Icon-PEP provides a proxy that relays HTTP/2 streams and has built-in management of gRPC health checks. This enables efficient operation of this protocol stack over HF – the health checks lead to problematic overhead at low speeds.

This is a general-purpose capability. The key initial target is the support of TAK communication between two TAK servers.

Red/Black Monitoring

Overview View

A new view showing active parts of the Icon-PEP server to facilitate configuration analysis.

TTL Rule

A new capability is provided to specify a TTL (time to live) for IP data. This is used to control both the STANAG 5066 TTL parameter and the traffic queued by Icon-PEP. This can be helpful to avoid congestion, for example, if regular ICMP Pings are used for monitoring across an HF link.

Miscellaneous

• Various changes to improve resilience and performance.

• Buffers TCP data on the receiver side. This is helpful for scenarios where a server, such as a Web server, is sending lots of data; it avoids issues of the server timing out the link due to slow transfer.

• Improved error reporting in several scenarios.

• Option to save a trace of TCP transfer, which enables protocol analysis of Stream Data carried by Icon-PEP.

• Improved compression display on monitoring.

• Various minor UI improvements.