HF networks mapping from on-air signals

The aim of the post is to illustrate an "hand" method to draw HF networks from STANAG-5066 Protocol Data Units (PDUs) that are exchanged over HF radio between peer HF nodes: mainly, the DATA-ONLY type 0 D_PDUs (Simplex data transfer) will be used here.
According to the STANAG-5066 terminology, a node (or HF node), is an implementation of the profile described in the main body and mandatory annexes to the S-5066 profile. The node is generally assumed to include the HF (modem and radio) and cryptographic equipment required for communications. A subnetwork is a collection of nodes. As a whole, a subnetwork provides a reliable networked data-transport service for external users or clients (client applications). 
It may happen that in certain deployments the client applications (clients) reside inside the same physical machine that run the node as well as deployments in which the clients reside in a LAN(s), behind the HF node.

To map a certain STANAG-5066 HF network we need to know the IP adresses of the nodes which belong to that network: it can be done by recording the transmissions from that network and analyzing the S-5066 D_PDUs which compose the bitstream obtained after the removal of the overhead added by the used HF waveform (S4285, MS188-110A/B,...). If the heard transmissions are in plain-text (not encrypted) then source and destination IP addresses will be found in the headers of the D_PDUs (fig. 1). These on-air addresses will be associated to the routing indicators in the HF address table of the 5066 software.

fig. 1

The D_PDU headers can be highlighted by synchronizing the bitstream on the 16-bit Maury-Styles sequence 0xEB90 since all D_PDUs, regardless of type as seen in previous posts in this blog, begin with that same sync. Sometimes, change the polarity may be necessary (fig. 2). The sync sequence 0xEB90 causes a marked 1776 bit ACF, that makes a 222 bytes period, in case of DATA-ONLY type D_PDUs.

fig. 2

As specified in Annex C of S-5066, the Size-of-Address Field  specify the number of bytes in which the source and destination address are encoded. The address field may be from one (1) to seven (7) bytes in length, with the source and destination address of equal length.
Since the D_PDU header must be made up of an integer number of bytes, addresses are available in 4-bit increments of size: 4 bits (or 0.5 bytes), 1 byte, 1.5 bytes, 2 bytes, 2.5 bytes, 3 bytes, and 3.5 bytes.
In the headers of figure 2 the size of address field is the binary 111 or decimal 7, so half of the bits, 3.5 bytes, are assigned to the source and the other half to the destination. By dividing the addresses field we get the 0.0.0.203 as the source IP, and 0.0.0.90 as the destination IP of the peers (figs. 3a,3b).

fig. 3a

fig. 3b

The "Group Address" can be likely found in D_PDU headers: as above, these addresses are obtained by looking at size of address field as in figs 4,5.

fig. 4

fig. 5

Transmissions that exchange data are usually preceeded by MS 188-141A handshakes which allow to build and populate a sort of basic "HF pairings table" [1] for each organization you want monitor, consisting of the ALE calls and their (on-air) IP addresses. With a little luck you can receive HF emails and henance your pairings-tables by adding the e-mail addresses (fig. 6).

fig. 6

Below some simple mappings of little(!) pieces of real HF networks: although the IP addresses come from real-world, some node names are fictional. Countries and  Mil/Gov/Diplo authorities and organizations are intentionally omitted.

As said, we focused on the DATA-ONLY type 0 D_PDUs but source and destination IP addresses are available also from the other D_PDU types (up to 15). By the way, since type 0 D_PDU send segmented C_PDUs, they are used in conjunction with a basic selective automatic repeat request type of protocol such as the ACK-ONLY type 1 D_PDU (fig. 7).
 

fig. 7

What has said above is an hand-method to obtain the addresses, a great help comes from protocol analyzers which can do the work for you.  Anyway, comparisons between results and bitstreams is always a good practice:  exotical IP addresses may come from corrupted frames (fig.8) which are ignored by the parser.

fig.8

As a final note, I want to advise that this post is not an hostile attempt or an encouragement to grab reserved informations since the heard transmissions are in clear-text and a rich documentation of STANAG-5066 D_PDUs is widely known and publicly downloadable from NATO and other web sites.
I have only shown the "boxes"  and not their contents: contents are encrypted and anyway I am not interested in them but only in the technical aspects of such communications. Likely, further posts on this topic will follow.


[1] the so-called "HF Domain Map" and "HF Address Table" as they appear in some 5066 system packages: it's worth noting the similarity with the "HF Pairing table". Thanks to my friend Marco for these screenshots!