xDL PDUs, BW2 & BW3 waveforms, and Harris 'Citadel' encryption

I spent some time to understand where and when the 'Citadel' encryption is applied to a message in the STANAG-4538 xDL implementation by Harris, eg in the RF-5800H transceiver, regardless of whether the message came from STANAG-4406 P-MUL or HMTP/CFTP and at least (!) in my copies.

HDL and LDL protocols exist in different variants, and a number n (eg xDLn) specifies the size of one forward transmission. For HDL the number n (24, 12, 6, or 3) should be multiplied by 233 bytes plus a 17-bit sequence number added by the protocol to give the total number of bytes in one forward Tx frame.  If the data segment is of length less than 233 bytes,  a sequence of null data bytes (of value zero) is appended to the data segment so as to extend it to length 233 in constructing the data packet.
In case the datagram is emptied and not all data packet positions have been filled with new packets, the remaining data packet positions are filled with repetitions of packets already residing in other positions. The HDL transmitter is at liberty to select packets from the current datagram to repeat as it pleases; the HDL receiver must inspect the sequence number of each packet received without errors, and use this information to discard duplicate packets.  Note: Whenever a packet is retransmitted, it is always placed in the same packet position within the Tx frame that it occupied in the previous transmission.
Fig. 1 shows the formation of two HDL3 forward transmissions.

Fig. 1 (not in scale)

For LDL, the number n (32, 64, 96,…,512) gives the number of bytes explicitly in a tx frame plus 25 bits due to LDL overhead, ie 17-bit sequence number plus 8-bit data reserved for future use. As for HDL, the tx frame length of the LDL protocol has discrete values, so that a data segment will be padded with 0 value bits if ist length is less than the packet length established for the current LDL transfer (32, 64, 96,…,512). Fig. 2 shows the formation of two LDL512 forward transmissions.

Fig. 2 (not in scale)

Now assume that a STANAG-4406 message shall be encrypted and transferred. P-MUL protocol segments a message into UDP/IP packets with a maximum length of the IP packet of 1500 bytes. If the length of the message to be transferred is 15 kbytes, a total of 11 IP consecutive packets are required for the message transfer. Consider now how the STANAG-4538 protocols operate when transferring one IP packet. At the arrival of the first IP packet at the sender station, a link to the destination node is set up by FLSU PDUs. Then, a 1500 byte datagram containing the first IP packet is transferred for example by using two HDL6 Data PDUs or three LDL512 Data PDUs, each related to one segment of the datagram and followed by an ACK in the reverse direction. 

The Citadel engine works on each datagram before to construct the xDL PDU, in case of the incoming datagram matches the length established for the current xDL transfer then the encryption could be seen as directly applied to the xDL PDU. Since the encryption adds overhead bits, the length of the datagram segments is chosen accordingly.

encryption in a HDL formation

The insertion of the encryption is more clear looking at xDL bitstreams from the real world. An HDL12 transfer is shown in Fig. 3: the presence of the Citadel "business card" is well visible just at the beginning of the PDU (Fig. 5).

Fig.3 - Citadel encrypted 1 x HDL12 transfer

Fig.4 - Citadel encrypted 1 x HDL12 transfer

An LDL32 transfer is shown in Figs. 5,6 : the presence of the Citadel pattern is well visible just in the first packet of the datagram.
 

Fig. 5 - Citadel encrypted 2 x LDL32 transfer

Fig. 6 - Citadel encrypted 2 x LDL32 transfer

Looking at Fig.2, the correspondence 1 LDL PDU = 1 data packet could wrongly lead to think to an encryption applied on data packet basis: the encryption insertion is more clear looking at HDLn, where 1 HDLn PDU = n data packets (Figs. 3,4).

Now look carefully at Fig. 5: each packet is indicated with its index followed by the dimension of the data segment, 32 bytes in this case (LDL32). That said, why five 8-byte rows, ie 40 bytes, are printed ? The same incongruity is verifiable in HDL packets: 240 bytes printed instead of the expected 233 (fig. 7)
 

Fig.7

LDL use burst waveform BW3 to transmit its PDUs. The number of payload bits is of the form 8n+25, where n = 32, 64, 96,..., 512 and the additional 25 bits are the overhead consisting of 17 bits of the sequence number + 8 bits for future use. A 32-bit Cyclic Redundancy Check (CRC) value is computed across the payload data bits in the data packet, and is then appended to the data packet. Then, 7 flush bits having the value 0 are appended to the (8n+57) bits of the data packet with CRC. In the example of Fig. 7 (LDL32) we obtain (8 x 32) + 57 + 7 = 320 bits that make the 40 bytes.

For what concerns HDL PDUs, these are transmitted by BW2 burst waveform. Each data packet is composed of a 1864 bits data-segment (233 bytes) + 17 bits of the sequence number. A 32-bit CRC value is computed across the 1881 payload data bits in each data packet, and is appended to the data packet. Then, seven encoder flush bits with values of zero are appended to the 1913 payload and CRC bits of each data packet to produce an Extended Data Packet (EDataPkt) of 1920 bits or just 240 bytes.

Juts another way to say that HDL is not BW2, and LDL is not BW3: xDL are protocols while BWn are waveforms.

For what concerns MDL protocol, it seems that the Citadel encryption is applied on the incoming datagram before its segmentation (Fig. 8).

Fig.8 -  MDL transfer using 3 x LDL32

Behavior of STANAG-4538 depends on vendor implementation as well as on its configurable parameters, so this post does not aim to show a sort of  fixed rule but just some cases of  transmissions that happened to hear.