XML Control Messages for STANAG 5066 over UDP/IP through a Data Diode (S5066-APP7)

Requirements

The (red side) SIS server needs to flow control its clients in line with the black side STANAG 5066 server. So, flow control needs to be communicated black to red side.

When messages are sent using UDP over S5066-APP7, any rejections and node confirmation of delivery needs to be communicated from the black side STANAG 5066 server. This needs a mechanism to associate rejections and confirmations to the original message. This is done by the black side assigning an ID to each inbound message and communicating this with a message to red side.

When messages are delivered, a data diode message is provided to enable red side to determine if there is message loss.

Transfer

This format can be transferred over a choice of data diode mechanisms including:

1. UDP used in conjunction with a physical data diode. This is an unreliable mechanism. The protocols specified here are designed so that messages can be repeated in order to increase reliability.
2. Interface to XML Guard acting as an application data diode. This mechanism will provide reliable transfer.

XML Messages

This section shows by example a set of XML messages to be sent from black to red.

Flow Control

Two XML packets are defined, representing Flow On and Flow Off messages

<Flow  xmlns=’http://isode.com/s5066-app7/0/’>
		<on/>
</Flow>

And

<Flow  xmlns=’http://isode.com/s5066-app7/0/’>
		<off/>
</Flow>

IP Packet Correlation

There is a need to correlate IP packets. The approach is the black side will assign an ID to each packet sent, with an integer ID one greater than the previous on. It will report the ID and information about the IP packet to red side using the following message.

IPSent xmlns=’http://isode.com/s5066-app7/0/’>
               <IP-ID>123456</IP-ID>
                <Source>
                        <IPv4>192.168.0.0</IPv4>
                </Source>
                <Dest>
                        <IPv4>192.168.0.0</IPv4>
                <Dest>
                <IPProtocol>51</IPProtocol>
                <Size>392</Size>
                <DSCP>55</DSCP>
                <ECN>2</ECN>
                <ARQ/>
                <Priority>7</Priority>
                <NotInOrder/>
  </IPSent>

Basic operation is that red side will send a packet and then wait for the matching IP packet to be sent.  It can then correlate the IP ID to the STANAG 5066 message sent.   This enables status messages to be sent back correctly. It is envisaged that IP packets will be sent lock step, where a packet is sent by red side and it waits for an ack.  It will resend if needed.

There is a very small risk that packets will be lost and this needs to be allowed for.  Red side needs to correlate based in information in this message. DSCP (6 bits encoded as int) will set ARQ, Priority and Order.  These will often be the same for a sequence of packets.

The ECN (2 bits encoded as int) is expected to be passed unchanged red to black.  This enables additional correlation to help detect missing packets.

A more complex issue is that the IP Crypto, when receiving a packet, may start to negotiate security credentials with its peer.   This can lead to a sequence of packets being sent before that actual data is sent.   The IP protocol information and other data on the IP can help to distinguish these non-data packets.

Node Confirm and Reject

If an IP packet sent over STANAG 5066 gets a reject, the following message is sent:

<Reject  xmlns=’http://isode.com/s5066-app7/0/’>
		<IP-ID>123456</IP-ID>
		<Reason>2</Reason>
</Reject>

If an IP packet confirms node delivery, then the following message is sent. Note that Node Delivery is always requested for ARQ black side. Red side will return to client if the client requested it.

<NodeConfirm  xmlns=’http://isode.com/s5066-app7/0/’>
		<IP-ID>123456</IP-ID>
</NodeConfirm>

Inbound Data

IP traffic also flows from Black to Red.  This traffic is reported over the data diode using a similar mechanism:

<IPReceived xmlns=’http://isode.com/s5066-app7/0/’>
		<IP-RCV-ID>123456</IP-ID>
		<Source>
			<IPv4>192.168.0.0</IPv4>
		</Source>
		<Source>
		<IPv4>192.168.0.0</IPv4>
		</Source>
		<IPProtocol>51</IPProtocol>
		<Size>392</Size>
		<DSCP>55</DSCP>
		<ECN>2</ECN>
		<ARQ/>
		<Priority>7</Priority>
		<NotInOrder/>
</IPReceived>

IP-RCV-ID is assigned one greater than previous.  This allows red side to detect loss, but not to address it.

There is possibility of loss of either this datagram (which may be repeated to increase reliability) or of the IP packet on which it is reporting. Loss of this datagram can be inferred by IP-RCV-ID sequence number gaps. Risk of loss is low. Red side needs to correlate the datagrams, to handle loss on startup. The additional information enables this.

1. If DSCP and ECN can be set and are passed by the IP crypto, these can be set with increasing values to provide robust correlation,
2. The other three parameters can be determined from SIS. These will match values inside the encrypted IP packet, and so can also provide correlation.

Red to Black Protocol

There is a similar protocol for diode going red to black side, which addresses the risk of loss of IP packets going black to red. It is a simple resend request for a packet of a given ID.

IP Packet Correlation

There is a need to correlate IP packets. The core approach is the black side will assign an ID to each packet sent (IP-RCV-ID), with an integer ID one greater than the previous one as described in the inbound data section. This message is used by red side to request resend of a specific message:

<ResendRequest xmlns=’http://isode.com/s5066-app7/0/’>
		<IP-RCV-ID>123456</IP-RCV-ID>
</ResendRequest>