19 June 2017

unid STANAG-5066 RCOP/UDOP client, Swedish Army "C2" integrator? (tentative)

[updated, 19 June]

As said in the previous post, in all the monitored transmissions the chosen 3G-HF service is the Circuit Mode, and 1200 bps MIL 188-110A is the used traffic waveform. Data are transferred by STANAG-5066 D_PDUs and both the RCOP (Reliable Connection Oriented Protocol) and UDOP (Unreliable Datagram Oriented Protocol) are used as basic end-to-end transport protocols, but so far the client protocol which run over S-5066 has not been yet identified. Me and S4538 (the nickname of a friend of mine) started to analyze these transmissions since several days and below are exposed the tentative results in order to get comments from out there, further posts will follow.

Figure 1 shows two bitstreams after MS-110A removal and after synced on 0xEB90 (S-5066 D_PDU synchronisation sequence): in this cases all the D_PDUs are of type 7 (non-ARQ delivery) and 0 (Simplex data transfer) and carry UDOP and RCOP protocol.

Fig. 1
It's interesting to note in Fig. 2 the initial same structures which are present in all the recordered copies, in both RCOP and UDOP cases, after the removal of the DTS overhead (D_PDU encapsulations):
 
Fig. 2
 Let's have a look at ASCII rapresentations of a series of decoded transmissions (Fig. 3):

Fig. 3
Data are structured as a series of headers having the format {<length>,<content>}:

{5,HWK01}{3,PFY}{3,001}{3,001}{10,1570853327}{0}{143,...}{0}
{5,HWK01}{3,ZHO}{3,001}{3,001}{10,2096500086}{0}{625,...}{0}
{5,HWK01}{3,ZHO}{3,001}{3,001}{10,2097463403}{0}{937,...}{0}
...
...

A possible explanation could be:

{5,HWK01}{3,PFY}
source and destination IDs

{3,001}
number of the current data-block (see later)

{3,001}
total number of data-blocks (see later)

{10,1570853327}
most likely a timestamp (see later)

{0}
unknown. So far, never seen something different at this position, probably marks the start of a data block (SOF).

{143,data-block}
number of bytes followed by data.

{0}
unknown.
So far, never seen something different at this position, probably marks the end of a data block (EOF).

The particular format of the headers {<length>,<content>}, the iteration of the transmissions and their duration, lead to think to a wrapper protocol that acts as a "bridge" to passing data between T-MMH systems (eg X.400 and ACP127 networks, although STANAG-4006 performs that task) or between C2 systems.

By the way, "The Sweidish Army uses C2 systems that are not interoperable and data must be manually transferred between them. Sweden began to integrate all the service's C2 systems, at all levels, in 2005 under the name SWECCIS. [...] Swedish Armed Forces HQ tasked FOA, FMV and FHS to propose a vision for a mobile military joint C2 system for 2010, this project has been expanded to include civilian C2 elements [...] the goal is a single C2 environment..." [1].
But these are only suppositions(!), although some clues come also from this picture [2]



For what concerns the timestamp header, it seems related to the "wrapped" data file. By examining consecutive transmissions, the granularity is in milliseconds and the Epoch Time started on Sat May 13 2017 00:00 CEST (GMT +2): possibly the date on which this "service" came into production?

***  structure of the protocol ***
In the cases depicted in Figure 4a, if the data-block length is greather than 1977 bytes then it is segmented into smaller blocks, each block consisting of the same {<length>,<content>} headers. The timestamp header remains unchanged while the current data-block header is updated.

Fig. 4a
Anyway, the max length of the data-block is not constant but depends on the length of the IDs, or better, on the length of the headers (Fig. 4b):

Fig. 4b
The max length of the data-block varies to match the max length of the transmission-block which appears to be  2051 bytes for both RCOP and UDOP protocols. The data-blocks are not filled if their length is smaller than the one allowed by the transmission block max length.

Why 2051 bytes? The maximum transmission unit (MTU) for S-5066 Subnetwork Interface is 2048 bytes when using point-to-point transmitting mode (ARQ or NON-ARQ), so the clients are responsible for segmenting larger messages into User Protocol Data Units (U_PDUs). The Subnetwork Interface Service will discard any U_PDU submitted by a client where the U_PDU is greater in size than the MTU size, but clients shall accept larger U_PDUs when receiving data. 
Note that we see the U_PDUs plus the 12-byte overhead due to C_PCI, S_PCI, and RCOP/UDOP headers added by S-5066 (Fig. 4c), so - unless null bytes - likely the MTU used by this protocol is 2035-2039 bytes. It's worth noting that the U_PDUs are sent un-segmented and that the Apllication Identifier is 0x8008, that just belongs to the values which are available for user-defined applications (S-5066 Annex F, table F5).
 
Fig. 4c


The transmsission blocks at the sending S-5066 node are then splitted in un-filled "chunks" of 200 bytes length and sent to S-5066 port (Fig. 5).

Fig. 5

Indeed, looking at the hex rapresentation of an UDOP transmission block (Fig. 6) we see that the 200-byte chunks are sent twice, unless the last chunk and the first chunk of the successives data-blocks. This makes sense to improve the reliability, since the nature of UDOP protocol itself (it's a basic connection-less protocol) and the use of S-5066 non-ARQ service. 

Fig.6

*** nature of the data ***
For what concerns the nature of the data, since the {<length>,<content>} headers  are in plain-text, the encryption if any is performed upstream before this protocol.
A termed here "magic string", in the form  ZLLLL (ie "Z" followed by 4 uppercase letters), appears in the first 40 bytes of the data-block and it is always preceeded by the 34-byte sequence 0x7E0862...61D5EE20 (Fig. 7). In case of a multi-blocks transfer the magic string is present only in the first block ( Fig. 4a). So far, the seen values are: empty, ZXPBC, ZXPBD, ZRTBC, and ZRTBD. This is another unclear point and needs further observations.

Fig.7
The data obtained after the removal of the headers do not exhibit particular structures or recognizable patterns, unless the firts 40 bytes followed by the magic string. 


*** S-5066 HF network ***
For what concerns the HF network, they have tens(!) of channels. Anyway, at least from a monitoring by S4538, each channel is always used with the same RCOP/UDOP protocol.
So far, matching S-5066 addresses and src/dest headers we got:

[006.046.000.zzz] block
HWK01   006.046.000.028, 006.046.000.102
ZMK002  006.046.000.037

[006.046.001.zzz] block
DWY  006.046.001.009
PFY    006.046.001.010
ZHO   006.046.001.028
RJY    006.046.001.029
GZL   006.046.001.030
HEH,HEH002  006.046.001.34
CAU   006.046.001.046

In the vast majority of the cases (almost 99%) traffic is originated from 006.046.000.zzz block nodes (HWK01,ZMK002) to 006.046.001.zzz block nodes. Very few traffic in the reverse direction. Maybe 006.046.000.zzz block is assigned to the main (strategic?) nodes of the net?
Anyway, it's interesting to note that in some transmissions the same ID "HWK01" appear in both the src and dest blocks, although with different S-5066 addresses (anyway belonging to the same block 006.046.000.zzz):

Fig.8
where:
{5,HWK01}{5,HWK01} have the S-5066 addresses 006.046.000.102 and 006.046.000.028

Perhaps two possible reasons:
a) the ID HWK01 acts like a sort of ZIP-code or global-ID with different users/services, each with a distinct S-5066 Address 
b) these are two physical instances. As shown in [2] they have separated Rx and Tx stations. Maybe this is a information transfer from one Tx to its corresponding Rx station which logically share the same ID.

Helps, comments and recordings are welcome!
(to be continued) 

Links:

No comments:

Post a Comment