Icon-PEP

The basic deployment model is shown below, a pair of IP applications (e.g., a Web client and a Web server) are 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.

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 in 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 to 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 [HF-PEP: STANAG 5066 TCP Performance Enhancing Proxy Protocol (S5066-APP9)]. 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 IP Client, leading to significant performance and reliability improvements.

HF-PEP operates over SLEP (SIS Layer Extension Protocol), specified in S5066-APP3. 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 [Measuring and Analysing HF-PEP for TCP communication and Web Browsing over HF].

Icon-PEP acts as an IP router and supports two models of IP routing:

1. Fixed routing. Icon-PEP configures IP networks associated with each peer STANAG 5066 node and routes IP traffic according to this. This can include a default route, which enables a mobile unit to route all traffic to a shore node by default.
2. NAT model, which is intended for a shore node to support traffic from any mobile unit without the shore node being aware of the IP networks used by the mobile unit. It does this by performing Network Address Translation (NAT). This mode only supports IP traffic initiated by a mobile unit. IP traffic then originates from Icon-PEP and does not use GRE.

Icon-PEP supports rules for IP and TCP traffic that allows 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)

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

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, so that queries and answers can be observed.

There is a special monitoring interface for TCP connection shown above. This shows active and recently closed TCP connections. HTTPS (secure HTTP) connections are explicitly listed. HTTP connections are shown with information on recent activity. It is recommended to avoid the overhead of TLS when operating HTTP over HF. Browsers re-use TCP connections, so the HTTP monitoring is helpful to observe Web traffic.

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.