19 June 2017

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



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.

protocol data units

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?


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 Addresses

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.

You may read other posts about this topic by browsing the tag Swedish Army


Links:

No comments:

Post a Comment