Icon-PEP

The basic deployment model is shown below; a pair of IP applications (e.g., a Web client and a Web server) is separated by HF. At a very high level, Icon-PEP is enabling this communication. The diagram omits components between IP Application/Icon-PEP and between Icon-PEP/HF Network.

The communication between a pair of IP applications proceeds over a sequence of IP subnets, each one connected by a router, as shown below. Icon-PEP enables an IP subnet to be created over HF, which forms one step in the complete IP communications setup.

The diagram below shows how Icon-PEP provides an IP subnetwork.

Icon-PEP operates over the STANAG 5066 HF Link layer, and connects to a STANAG 5066 server such as Isode’s Icon-5066 product using the STANAG 5066 SIS protocol. This cleanly decouples Icon-PEP from the STANAG 5066 link layer.

It is important to note that Icon-PEP connects to an IP router, and not directly to a host (end system) or to an application. This gives flexibility to support many applications and hosts with a single Icon-PEP server.

Icon-PEP communicates with one or more IP Routers using Generic Routing Encapsulation (GRE), specified in RFC 2784. GRE provides a simple mechanism to exchange packets between routers over IP, often described as a “GRE Tunnel”. Icon-PEP terminates the GRE tunnel from a connected IP router. This means that there is no requirement for a peer system to use GRE.

GRE is widely supported by Edge routers, and it is anticipated that Icon-PEP will generally connect to the deployed router. For subnets or single hosts that do not deploy a router, or where the deployed router does not support GRE, it is possible to use a software router, such as the one provided on many Linux systems or a product such as pfSense running in a virtual machine.

This mode of operation in Icon-PEP is referred to as “tunnel mode”. This is seen as an important mode of operation and is described as the default approach. A more detailed description of the protocol architecture and this mode is given in the Isode whitepaper [Providing TCP Services over HF Radio]. This paper also describes two more modes:

1. “Direct Mode”. This is a mode that enables TCP and UDP applications to connect directly to Icon-PEP.  This moves routing from the IP level to the application level. This approach can be helpful for some deployments.
2. “Simplified Shore Proxy”. This provides a simplified configuration that can be used to support Mobile Unit mobility. With this mode, connections must be initiated from the Mobile Unit.

Icon-PEP provides two services. The first is simply to switch IP packets. This follows STANAG 5066 Annex U “IP Client” services for operating an IP subnet over HF.   It simply transfers the IP packet. Icon-PEP provides controls based on the IP protocol used and ports within the protocol (e.g., ICMP, UDP). Packets can be handled differently based on protocol, including blocking, and choosing between ARQ and non-ARQ transfer.

Operation using IP Client is described in detail in the Isode whitepaper [Measuring and Analysing STANAG 5066 IP Client]. This shows that IP Client works well for some services, such as ICMP Ping, but not for others, including TCP. Icon-PEP supports IPv4 and IPv6, complying with STANAG 5066 Annex U.

The second service uses a performance-enhancing proxy (PEP) architecture to give optimized performance for TCP applications. In this TCP Proxy architecture, an application is communicating over TCP, running over IP in the normal manner. The TCP connection from each application is terminated at the point it interacts with Icon-PEP, rather than continuing on to the other application. Icon-PEP then communicates over HF using the HF-PEP protocol specified in STANAG 5066 Annex X. This approach means that only the data stream is passed over HF, rather than all of the TCP protocol with its overheads and functionality, such as ACKs (acknowledgements) and window-handling. The PEP approach avoids the issues with running TCP over the IP Client, leading to significant performance and reliability improvements.

HF-PEP operates over SLEP (SIS Layer Extension Protocol), specified in STANAG 5066 Annex W. SLEP provides the Stream Services used by HF-PEP, including data compression. SLEP communicates over STANAG 5066, using the local STANAG 5066 SIS (Subnet Interface Service) to connect. Icon-PEP is carefully tuned for HTTP usage, so that typical small transfers can be handled with a single HF round trip. Further details on HF-PEP and performance measurements using Icon-PEP are provided in the Isode whitepaper [Providing TCP Services over HF Radio].

Icon-PEP supports rules for IP and TCP traffic that allow control of traffic. Rules can match on:

• Protocol (port for TCP; protocol/port for IP).
• Source and Destination IP address matching against a list of IP subnetworks.

Rules can control:

• Blocking traffic that matches the rule.
• Setting non-default parameters for matching traffic
  1. STANAG 5066 Priority
  2. ARP/Non-ARQ choice (for IP traffic)
• Setting Time to Live (TTL) to prevent congestion from short-lived data.

Icon-PEP provides five monitoring options in the web monitoring interface. Three of these are primarily to support initial setup and detailed operational analysis:

1. Monitoring of all IP traffic over GRE with the router.
2. Monitoring of IP traffic (excluding TCP) exchanged with the STANAG 5066 server.
3. Monitoring of all Icon-PEP logging metrics.

There is a special monitoring interface for DNS (Domain Name Service) shown above. IP services make extensive use of DNS, and it is useful to monitor this independently, which enables DNS queries and answers to be observed.

There is a special monitoring interface for TCP connections shown above. This shows active and recently closed TCP connections. HTTP and HTTPS (secure HTTP) connections are explicitly listed.

HTTP and HTTPS  connections are shown with information on recent activity. Web browsers reuse TCP connections, so the HTTP monitoring is helpful to observe Web traffic. Note that TLS is proxied for HTTPS, which enables compression to be applied.  Compression is shown in the UI.

System Monitoring

Icon-PEP provides a UI, shown above, to show which components of the product are active.

Icon-PEP provides a control function, which allows an operator to enable or disable Icon-PEP. This may be useful in poor HF conditions, where it is desired to give priority to non-IP applications.

Icon-PEP can also be monitored and controlled from Isode’s Red/Black system monitoring product.