UDP datagrams sent via STANAG-5066 over async MS-110A (IP over HF)

i56578-swl.blogspot.com 1 dzień temu

This is simply a casual catch while I was exploring the 14 MHz band (14963.5 KHz/USB to be precise): the data transmission occurred after the usual MS-141A 3-way handshake between the ALE nodes 101 (caller) and 102 (called). Recording thanks to linkz KiwiSDR [1]. The utilized HF waveform is MS-110A in 300bps/Long mode (Figure 1).

Fig. 1 - MS-110A 300bps/L waveform

The resulting bitstream after MS-110A decoding uses 8N1 asynchronous framing (1 start bit, 1 halt bit) as shown in Figure 2.

Fig. 2 - 8N1 framing in demodulated bitstream

Examining the 8-bit bitstream after removing the start/stop bits, it must be noted the presence of the 16-bit Maury-Styles synchronization series 0xEB90 (LSB transmitted first) which identifies the STANAG-5066 Data Transfer Protocol Data Units (D_PDUs) frames (1).

Fig. 3 - STANAG-5066 sync sequences

I then decided to process the 8-bit bitstream utilizing the STANAG-5066 dissector tool [2] obtaining interesting results which I comment below. The STANAG-5066 transfer consists of 2 frames which are fundamentally a repetition (2): Figure 4 shows the first D_UDP frame.

Fig. 4 - first frame of the STANAG-5066 transfer

a) The D_PDU is type: 7 NON-ARQ DATA, i.e. Non-ARQ data transfer. Indeed, as Figure 1 shows, the data transmission is not followed by feedback ACK bursts. The "Delivery confirmation = none" flag is an additional confirmation of the NON-ARQ data transfer mode.

b) STANAG-5066 Addresses are
Source node address: 011.020.100.101
Destination node address: 011.020.100.102
Note that the last 3 digits of the addresses (101 and 102) correspond to the respective MS-141A ALE addresses utilized during link management.
If 11.20.y.z are actual STANAG-5066 addresses (not fake or dummy addresses), the nodes belong to an Armenian political or organizational network (STANAG-5066 Table N-9 — mediate East National Addressing Schema). besides note that in STANAG 5066, addresses are logical identifiers that reflect political or organizational belonging, not physical location.

c) The utilized "Source and Destination Service Access Point" is 9 (1001 binary): this identifies an IP-type Client/Application, according to STANAG-5066 #F.1.2 Standardized Assignment of Service Access Point Identifiers. Thus, this is simply a real-world example of IP over HF.

d) The "Client Application ID" field serves to identify the application (i.e., higher-level protocol) utilizing the connection.

For further analysis of the IP packet we request to extract and edit a "reassembled" C_PDU, provided by the dissector tool, and then save it as an HEX dump file. 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 00 99 40 6D 9F
where:
00 C_PDU kind (0 = data)
00 S_PDU kind (0 = data)
99 S_PDU origin & destination SAP IDs (1001 & 1001)
40 6D 9F 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.txt" (Figure 5).

Fig. 5

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. The consequence of the IP packet analysis is shown in Figure 6.

Fig. 6 - IP packet analysis

a) The first interesting thing to note are the values of the source/destination IP addresseses: 192.168.101.15 and 192.168.102.15, here besides we see a repetition of the "digits" 101 and 102. Sumarizing:
ALE address: 101 - STANAG-5066 address: 011.020.100.101 - LAN IP address: 192.168.101.15
ALE address: 102 - STANAG-5066 address: 011.020.100.102 - LAN IP address: 192.168.102.15

b) As expecetd, since the Non-ARQ kind D_PDU, the IP packet transports an User Datagram Protocol (UDP, a connectionless communication protocol) datagram with destination port 2753.
According to the authoritative IANA service registry [4], the UDP port 2753 is registered as "de-spot". This means that if an application declares it uses UDP 2753, it’s conventionally associated with a service called de-spot, but that name doesn’t correspond to any widely known mainstream protocol like DNS or DHCP. It’s a registered but obscure / application-specific designation, port 2753 seems to be utilized by circumstantial monitoring tools without a universal standard service name.

c) The UDP datagram transports the 16 bytes payload [0x]:
00 10 00 03 06 00 72 c6 c0 a8 65 0f 00 00 0c c3
I asked ChatGPT to effort to break down the payload byte by byte, it's something like "mission impossible" I know, but any results are worth attention.

1. 00 10 → Possibly a message kind or any identifier (2 bytes). Hex 0x0010 = 16 decimal (just the dimension of the message!)
2. 00 03 → Another 2-byte field, could be message kind or command. Hex 0x0003 = 3 decimal.
3. 06 00 → Could represent a flags field, version, or sub-type. Hex 0x0600 = 1536 decimal.
4. 72 C6 → frequently a transaction ID, session ID, or another 2-byte value. Hex 0x72C6 = 29318 decimal.
5. C0 A8 65 0F → This looks precisely like an IPv4 address in hex: C0 A8 65 0F → 192.168.101.15 (just the IP address of the sender!)
6. 00 00 → Possibly padding, reserved, or a 2-byte zero field.
7. 0C C3 → Could be a port, checksum, or any another 2-byte value. Hex 0x0CC3 = 3267 decimal.

The exact meaning depends on what application protocol is encapsulated inside the UDP packet. As seen, the IP address in UDP payload matches the origin address in IP header: by itself, UDP doesn’t care about IP addresses, payload fields just contain whatever the application protocol puts there (data/metadata).
I do not know why the origin IP address is repeated in the UDP paylod, possibly it's due to protocol design, NAT traversal, or validation (heartbeat/keepalive message?): I think that a network specialist could clarify the question and the utilized application protocol.

As is usual in SIGINT analysis, I followed a bottom-up approach, that is, I started from the HF bitstream and worked my way up to the application layer protocol. Top-down flow of the data is shown in Figure 7.

Fig. 7 - data flow during transmission

Every now and then I halt for a fewer hours to monitor the channel (14963.5 KHz) but up until the time of writing I have not had the luckiness of listening specified transmissions, neither simple MS-141A exchanges.

https://disk.yandex.com/d/qUCfb7EBQyIKxg

(1) As per STANAG-5066 "C.3.2 Generic detailed D_PDU structure": All D_PDUs, regardless of type, shall begin with the same 16-bit synchronisation (SYNC) sequence. The 16-bit series shall (5) be the 16-bit Maury-Styles (0xEB90) series shown below, with the least crucial bit (LSB) transmitted first: (MSB) 1 1 1 0 1 0 1 1 1 0 0 1 0 0 0 0 (LSB).

(2) most likely the D_PDU frame is repeated to supply any increased probability of receipt and reliability.