For a fewer days I have been monitoring the 20.5 MHz/USB frequency, thanks to the KiwiSDR owned by IZ6BYY [1], recording any transmissions specified as the example in Figure 1, by the way specified 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 so 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 utilized the "modified amplitude detector" function (Figure 2b) which shows a solid continuous line of 2400 Hz and so the corrcet value of 2400 Bd. But the function besides reveals faint horizontal lines that "should" represent the baud rate and harmonics and which - unfortunately - should not be there and so fool the automatic detection (in PSK modulation the amplitude of the carrier signal remains constant). As a further test I utilized the automatic detection after the "hard-limited amplitude control" (Figure 2c) and in this case the consequence is the expected one.
 |
| Fig. 2 - Baud rate measurements |
Apparently, there is simply 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 velocity 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 dimension of MS-110A frames is 40 symbols (20 symbols data block + 20 symbols mini-probe) but at slow data rates the dimension 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 4 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 perfect one. alternatively of distinct, equally spaced points on a single circle, we see a slight amplitude variation and a twisted/spiral arrangement of the points. This unusual 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, nevertheless it is inactive possible to analyse the resulting bitstreams and find a 1776-bit period that reveals the usage of the STANAG-5066 suite at the data-link layer, presence which is besides confirmed by any detections of the 16-bit synchronisation sequences 0x90EB, typical of that Standard.
 |
| Fig. 6 - an MS-110A decoded bitstream |
The bitstreams have been analyzed utilizing the "STANAG-5066 Dissector" tool [2]; below the traffic-flow output from 1 of the demodulated bitstreams (S4539.txt) that clearly shows the usage 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 1 shown in Figure 7 (frame #26 of 49):
 |
| Fig. 7 - a STANAG-5066 frame |
As shown, the origin 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 mention 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 request 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 gotta remove the first 6 bytes, i.e. 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 kind (0 = data)
07 S_PDU kind (0 = data)
99 S_PDU origin & 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 utilizing the well-known "wireshark" tool [3]: first click "File" -> "Import from Hex Dump", choice the file to be imported, set offsets to "none" and Encapsulation kind 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 safety 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 kind of packet is common in VPN connections or another safe network communications.
 |
| Fig. 11 - imported IP packet |
The IP header can besides be parsed by utilizing the tool CyberChef [4], evidently getting the same results.
 | |
| Fig. 12 - CyberChef IP parser |
Further analysis is not possible since the IP packets payloads are protected by encryption, nevertheless any comments can be added.
The first 1 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 utilized during the circuit mode service: for example, STANAG-4285 can be specified as the traffic waveform. erstwhile circuit mode begins, any station can initiate transmissions utilizing 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, i.e. 2 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 mostly statically configured and are part of the network's plan and planning, i.e. 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 besides supply IP and IPv6 address translation for its subnetwork addresses to let IP-based applications to communicate over the HF link. In specified cases, the mapping between STANAG 5066 addresses and IP addresses would besides be part of the static configuration. For example, the example 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 7 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 2 different STANAG-5066 mappings (001.010.010.110, 001.001.001.101). evidently over the time the servers/devices may have changed as well as the related configurations, furthermore only 3 samples are not so significant.
However, it must be said that ESP protocol may work in "tunnel" and "transport" mode. In tunnel mode, the full first IP packet (including its first IP header) is encapsulated and becomes the payload of a new, outer IP packet. This means you will see 2 IP headers:
* an outer IP header that contains the origin and destination IP addresses of the IPSec gateways or tunnel endpoints.
* an interior (original) IP header that contains the actual origin and destination IP addresses of the end-hosts. This interior header is encrypted along with the first payload(!).
In transport mode, the first IP header is retained. There is only 1 IP header in the packet. This header contains the origin and destination IP addresses of the actual end-hosts communicating.
I can't reliably find 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 straight correspond to the eventual origin 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 scope 1.0.0.0-1.255.255.255 is managed by US DoD and includes US Armed Forces and Homeland safety as major S’5066 users.
(1) In the context of STANAG-4538, erstwhile we talk about "circuit mode service," we mostly mention to establishing a dedicated, continuous connection between 2 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/
