For a few days I have been monitoring the 20.5 MHz/USB frequency, thanks to the KiwiSDR owned by IZ6BYY [1], recording some transmissions such as the sample in Figure 1, by the way such transmissions are not at all frequent. Data transfer is via the HF waveforms MS-110A and STANAG-4539 (MS-110B App.C), the links are managed by BW5 FLSU (Fast Link SetUp protocol) bursts and therefore everything happens according the "circuit mode service" of STANAG-4538 (1).
 |
| Fig. 1 - the transmission being analyzed |
HF layer
The symbol rate of both waveforms is 2400 Baud, but it was not immediately detectable. In fact, in Figure 2a the automatically detected baud rate value is about 100 Bd (!): a value that is clearly inconsistent. I then used the "modified amplitude detector" function (Figure 2b) which shows a solid continuous line of 2400 Hz and therefore the correct value of 2400 Bd. But the function also reveals faint horizontal lines that "should" represent the baud rate and harmonics and which - unfortunately - should not be there and therefore fool the automatic detection (in PSK modulation the amplitude of the carrier signal remains constant). As a further test I used the automatic detection after the "hard-limited amplitude control" (Figure 2c) and in this case the result is the expected one.
 |
| Fig. 2 - Baud rate measurements |
Apparently, there is a superimposed 100 Hz signal: according my friend cryptomaster it could be the residual ripple from a full-wave rectifier operating on a 50 Hz AC mains supply, which is then imperfectly filtered by smoothing capacitors.
 |
| Fig. 3 - residual ripple from a full-wave rectifier operating on a 50 Hz AC mains supply |
The ACF values of MS-110A and STANAG-4539 signals (in the current sample) are respectively ~66.6 ms and ~119.5 ms which - at the speed of 2400 Bd - make 160 symbols frames for MS-110A and 287 symbols frames (256 symbols data block + 31 symbols mini-probe) for STANAG-4539. Actually the length of MS-110A frames is 40 symbols (20 symbols data block + 20 symbols mini-probe) but at slow data rates the length of the scrambler (160 symbols) matches 4 frames and originates the 66.6 ms ACF. Bitmaps and ACFs are shown in Figure 4 (note the four MS-110A frames within the 66.6 ms interval).
 |
| Fig. 4 - Bitmaps and ACFs |
Figure 5 displays PSK8 constellations that appear "odd" or "twisted" compared to an ideal one. Instead of distinct, equally spaced points on a single circle, we see a slight amplitude variation and a twisted/spiral arrangement of the points. This odd appearance is most likely due to the superposition of the 100 Hz signal, as already highlighted during the baud rate measurement.
 |
| Fig. 5 - "twisted" PSK8 constellations |
data-link layer
The demodulation of the signals inevitably "suffers" from the non-perfect PSK8 constellations, however it is still possible to analyze the resulting bitstreams and find a 1776-bit period that reveals the use of the STANAG-5066 suite at the data-link layer, presence which is also confirmed by some detections of the 16-bit synchronisation sequences 0x90EB, typical of that Standard.
 |
| Fig. 6 - an MS-110A decoded bitstream |
The bitstreams have been analyzed using the "STANAG-5066 Dissector" tool [2]; below the traffic-flow output from one of the demodulated bitstreams (S4539.txt) that clearly shows the use of the ARQ DATA-ONLY (simplex) transfer mode; traffic flows from node 001.001.001.101 to node 001.010.010.110 (STANAG-5066 address):
Further "technical" information can be extracted by examining the data transfer frames as for examle the one shown in Figure 7 (frame #26 of 49):
 |
| Fig. 7 - a STANAG-5066 frame |
As shown, the source and destination Service Access Point Identifiers (SAP ID, equivalent to the “ports” of the TCP protocol) have value 9 (1001 binary) and according to STANAG-5066 they refer to an IP based client/application, more precisely the traffic consists of segmented IPSec (IP Security) packets sent by node 001.001.001.101 to node 001.010.010.110.
user-to-user data
For further analysis of the IP packet we need to extract and edit a "reassembled" C_PDU and then save it as an HEX dump file. Figures 8,9 show an example.
 |
| Fig. 8 - an extracted STANAG-5066 C_PDU |
We have to remove the first 6 bytes, ie the headers of C (Channel Access Sublayer) and S (Subnetwork Interface Sublayer) Protocol Data Units:
00 07 99 4B 5E 4F
where:
00 C_PDU type (0 = data)
07 S_PDU type (0 = data)
99 S_PDU source & destination SAP IDs (1001 & 1001)
4B 5E 4F S_PDU control and TDD fields
After removing these first 6 bytes you can copy and paste the hexadecimal data and save it to a .txt file, as for example "hex_dump_001.txt":
 |
| Fig. 9 - HEX dump file |
The HEX dump file can be now analyzed by using the well-known "wireshark" tool [3]: first click "File" -> "Import from Hex Dump", select the file to be imported, set offsets to "none" and Encapsulation Type to "Raw IP" then click Import (Figure 10).
 |
| Fig. 10 - wireshark: import from hex dump file |
Figure 11 displays the hexadecimal and ASCII representation of the imported IP packet. You can see the bytes that make up the IP header and the subsequent ESP (Encapsulating Security Payload) header and its (encrypted) payload. In summary, this image shows an IPSec (IP Security) ESP packet traveling from the IP addresses 192.168.10.48 to 192.168.1.48. The ESP protocol provides confidentiality, data origin authentication, data integrity, and anti-replay services for IP packets. This type of packet is common in VPN connections or other secure network communications.
 |
| Fig. 11 - imported IP packet |
The IP header can also be parsed by using the tool CyberChef [4], obviously getting the same results.
 | |
| Fig. 12 - CyberChef IP parser |
Further analysis is not possible since the IP packets payloads are protected by encryption, however some comments can be added.
The first one concerns the HF waveforms. As seen in Figure 1, HF traffic is conducted in STANAG-4538 "circuit mode". The FLSU Request specifies the traffic waveforms that will be used during the circuit mode service: for example, STANAG-4285 can be specified as the traffic waveform. Once circuit mode begins, any station can initiate transmissions using the specified traffic waveform. Indeed, quoting Annex C to STANAG-4538 "For circuit mode connections, the called station can issue a FLSU Confirm with a different modem parameter (data rate or interleaving), but it shall not change the waveform selection". Well, this is in contrast to what I saw, ie two different waveforms: MS-110A 600bps/S and STANAG-4539 (MS-110B App.C) 4800bps/S, and 9600bps/S also. Although MS-110B superseding MS-110A, Appendix C uses a completely different framing.
Unlike typical IP networks where addresses might be dynamically assigned via DHCP, STANAG-5066 addresses are generally statically configured and are part of the network's design and planning, ie each STANAG-5066 server or device is manually configured with its unique address (Figure 13).
 |
| Fig. 13 - manually assignment of a STANAG-5066 address |
While STANAG-5066 has its own addressing, it can also provide IP and IPv6 address translation for its subnetwork addresses to allow IP-based applications to communicate over the HF link. In such cases, the mapping between STANAG 5066 addresses and IP addresses would also be part of the static configuration. For example, the sample being analyzed shows the matches:
[STANAG-5066] [IP]
001.001.001.101 192.168.10.48 source
001.010.010.110 192.168.1.48 dest
Well, about seven years ago (respectively november and october, 2018) I found these matches:
[STANAG-5066] [IP]
001.001.001.101 192.168.2.48 source
001.003.003.103 192.168.12.48 dest
001.001.001.101 192.168.1.48 source
001.005.005.105 192.168.14.48 dest
Assuming that it is the same HF network(!) and trusting in the goodness of the decoders, you may see that the STANAG-5066 node 001.001.001.101 was always the sender and had 3 different IP mappings (192.168.10.48, 192.168.2.48, 192.168.1.48), as well as the IP node 192.168.1.48 had two different STANAG-5066 mappings (001.010.010.110, 001.001.001.101). Obviously over the time the servers/devices may have changed as well as the related configurations, furthermore only three samples are not so significant.
However, it must be said that ESP protocol may work in "tunnel" and "transport" mode. In tunnel mode, the entire original IP packet (including its original IP header) is encapsulated and becomes the payload of a new, outer IP packet. This means you will see two IP headers:
* an outer IP header that contains the source and destination IP addresses of the IPSec gateways or tunnel endpoints.
* an inner (original) IP header that contains the actual source and destination IP addresses of the end-hosts. This inner header is encrypted along with the original payload(!).
In transport mode, the original IP header is retained. There is only one IP header in the packet. This header contains the source and destination IP addresses of the actual end-hosts communicating.
I can't reliably determine whether these IPSec ESP headers are operating in transport or tunnel mode, thus the above IP addresses may belong to tunnel endpoints (tunnel mode) or directly correspond to the ultimate source and destination hosts (transport mode).
By the way, according to Annex N to STANAG-5066 (Guidance on Address Management in STANAG 5066 Networks) the address range 1.0.0.0-1.255.255.255 is managed by US DoD and includes US Armed Forces and Homeland Security as major S’5066 users.
(1) In the context of STANAG-4538, when we talk about "circuit mode service," we generally refer to establishing a dedicated, continuous connection between two points for the duration of the communication. This is in contrast to the packet mode service, where data is broken into discrete packets and sent independently via xDL protocols.
https://disk.yandex.com/d/LSGj4GzIpjBYOg
https://disk.yandex.com/d/iZNNGFhziG5opA
[1] https://iz6byy.k1fm.us/
[2] http://i56578-swl.blogspot.com/2021/02/a-stanag-5066-off-line-dissector.html
[3] https://www.wireshark.org/
[4] https://gchq.github.io/CyberChef/
