STANAG-5066 CFTP messaging over MIL 188-110A

The transmission has been copied on 7788.0KHz/USB and consists of an emails exchange between an Algerian Navy ship (Rais Hamidou) and the Headquarter of French Navy in Toulon (COMTOULON).  Messaging is performed by Stanag-5066 CFTP protocol (Internet Messaging over ARQ) in half-duplex mode, carried by MIL 188-110A serial waveform (Fig. 1). Link is not negotiated/established using ALE but by means of voice-comms between the operators.

Fig. 1

Basically, CFTP (Compressed File Transfer Protocol), sometimes referred to as BFEM (Battle Force Email), is a file transfer mechanism and STANAG 5066 Annex F defines its use for message transfer. CFTP is specified to work over a point to point network - that is, to communicate between a pair of nodes, with both nodes able to send data.

Fig. 2 - S5066 bitstream synched on D_PDU SYNC

The CFTP protocol shall not be used for Formal or High Grade Military Messaging (military orders) and may be used for informal interpersonal e-mail only; anyway, I'm interested in the way the "boxes" travel and not in their contents.
In operation, when an email message is received at a S-5066 node (port 5066 on localhost), it is placed in an incoming mail folder (mail spool directory). The CFTP client, also called the Delivery Agent, removes the mail from this incoming folder and compresses the message and information about the message, e.g. size, id, recipients, etc. into a file which is then transferred to the destination node using the Edition-1 Basic File Transfer Protocol (BFTPv1)  PDUs which are then incapsulated into Data PDUs (Fig. 2) before to be sent to the HF modem. The structure of BFTPv1  PDU is shown in Fig. 3, along with the g-zipped file from the copied transmission.

Fig. 3 - BFTPv1 Protocol Data Unit Structure

Client Delivery confirmation is provided by the receiving node using the Message Acknowledgement, sent as the body-part (!) of a CFTP/RCOPv1 PDU:

Fig. 4 - BFTPv1 Message Acknowledgement Structure

The CFTP mail-file is built as specified in paragraph "F.14.6 Detailed Description of CFTP, ANNEX F to STANAG 5066 Edition 3":

Fig. 5 - CFTP email-file

Below, some details about the two STANAG-5066 nodes in the play:

node: EMMA046
tactical callsign: PI (papa india)
S-5066 address: 006.014.100.001 (official  NATO S-5066 address)
email domain: toulon.frenchnavy.fr
host: EMMA046 (Rockliffe SMTPRA 4.2.4)
site: COMTOULON Toulon, French Navy

node: BDSL472
tactical callsign: BD (bravo delta)
S-5066 address: 010.000.000.001 
(near-official NATO S-5066 address since the 010.001 block is assigned to Algeria)
email domain: rh.raishamidou.dz
host: BDSL472 (Windows NT 6.1; WOW64; rv:24.0)
site: corvette "Rais Hamidou", Algerian Navy

Rais Hamidou corvette, photo from wikipedia https://fr.wikipedia.org/wiki/Rais_Hamidou_(corvette)

The other labels in the emails headers offer some other informations:  

1) PC at COMTOULON run an SMTP daemon hosted on a Rockliffe MailSite based server (Rockliffe SMTPRA 4.2.4):
https://www.rockliffe.com/index.html

2) the "WOW64" in user-agent string means a 32-bit version of Internet Explorer is running on a 64-bit processor: so the ship is equipped with a 64-bit PC running Windows7 or Windows Server 7 (Windows NT 6.1)

By the way, it's interesting to note in the curious behavior of one of the two 188-110A modems and  precisely the one at the ship side of the link: the initial 2600Hz tone-beep is maintained for the duration of each single transmission time and does not affect the correct demodulation of the signal (Fig. 3)

Fig. 3

Although 188-110A is an auto-baud waveform, operators negotiate the speed and interleaver which will be used during the initial phase of the data transmission: this leads to think to inter-operability or deployment tests.

(due to confidentiality, wav file and bitstream are not avalilable. Sorry.)

a STANAG-5066 HF MailServer at work

this is a good example of a STANAG-5066 based HF Mail Server (an MTA, Mail Tranfer Agent) at work: the HF Mail Server receives one email transmitted by a wireless client (over-the-air path) which is addressed to multiple non-HF recipients, and then it takes care of each single delivery by forwarding each message through an infrastructured TCP/IP path and returns back the email transmitted notifications to the sender (Fig. 1). Just the copy of the over-the-air "notifications" allowed to retrace the scenario.

The transmission concerns HF mail tests from a Turkish HF newtork, most likely belonging to the Coast Guard, and was (accidentally!) copied by KarapuZ. The HF Mail Server sits in the middle and acts as default MTA for the turkhfmail.com domain, so it's  "transparent" to the users. Both the sender and the Mail Server are in the same STANAG-5066 HF network: respectively, 1.0.0.3 and 1.0.0.1 (S-5066 Addresses).

Fig. 1

The used HF waveform is STANAG-4285 with ARQ extension provided by upper STANAG-5066 data link protocol (Fig. 2), the channel is used in half-duplex mode.

Fig. 2

The transmission, as said, convey test emails in clear-text, so these are not critical/secure messages, however only the domain names are visible while the account names are obscured. As I mentioned several times, I'm only interested on the way the "boxes" travel on-the air and not in their contents.

Figure 3 shows the transmission of the email from a certain <user>@turkhfmail.com (the sender at gw-HF-mail) to some recipients belonging to different not-HF email domains. Notice that the Adobe license is the content used as test message (so nothing important, just a text).

Fig. 3

the HF mail server reports the emails status to the original sender by transmitting a single notification for each addressed recipient: in this case the sender is the HF mail server.

I wanted to illustrate more clearly two of those test notifications in order to understand the involved users and their role. Figure 4 shows the status notification of the email which is addressed to Directorate General of Coastal Safety, Figure 5 show the status of an email addressed to Selex ES headquarter in Turkey

Fig. 4

Fig. 5

The Turkish Directorate General of Coastal Safety is the client and the Italian Selex-ES is the solution vendor: it's quite obvious that these are the recipients since they are the most interested on the results of the tests. 

Some other informations can be acquired from the headers. 
1) The used protocol is CFTP (Compressed File Transport Protocol). CFTP is used to reliably send compressed SMTP e-mail over a STANAG-5066 HF subnetwork from one SMTP mail server to another. In operation, when an email message is received at a 5066 node, it is placed in an incoming mail folder (mail spool directory). The CFTP client, also called the Delivery Agent (DA), removes mail from this incoming folder and processes the mail for delivery over HF via 5066. The CFTP DA compresses the message and information about the message, e.g. size, id, recipients, etc. into a file. This compressed file is then transferred to the destination HF 5066 node(s).
2) User-Agent at the sender node is Mozilla/5.0 rv:12.0 Thunderbird/12.0.1 on Windows NT 6.1
3) The email domain name is turkhfmail.com, usually mail servers use mail.<domain name> as their hostname so I tried to nslookup mail.turkhfmail.com and got 212.156.62.66 (relay7.selex-comms.com.tr); the mail server is owned by Turk telekom and hosted directly by Selex-ES (Fig. 6)

Fig. 6

The HF mail server, as an MTA, also delivers messages from senders outside the HF network to STANAG-5066 HF recipients as shown in Figure 7

Fig. 7

It's worth noting the match of the mail server public IP address.