This specification defines data formats to communicate control information from a black side STANAG 5066 server in conjunction with use of IP Crypto and “Providing STANAG 5066 services over UDP/IP” (S5066-APP4).

The model is that a data diode is used on the security boundary between the SIS server and black side STANAG 5066 server. This specification is for use where the data diode is an XML guard. It defines XML format messages.

This version of the specification provides example XML messages. A future version of this specification will include an XML schema.

This document is part of the STANAG 5066 Application Protocol (S5066-APP) series. The complete set of documents in the series are:

  1. STANAG 5066 Application Protocol Index (S5066-APP1)
  2. HF Discovery, Ping and Traffic Load (S5066-APP2)
  3. SIS Layer Extension Protocol (SLEP) (S5066-APP3)
  4. Providing STANAG 5066 services over UDP/IP (S5066-APP4)
  5. Implicit IP Client over STANAG 5066 (S5066-APP5)
  6. Providing Control Parameters for STANAG 5066 over UDP/IP through IP Crypto (S5066-APP6)
  7. XML Control Messages for STANAG 5066 over UDP/IP through a Data Diode (S5066-APP7)
  8. HF File Transfer Protocol (HFFTP) (S5066-APP8)

1. 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 red to black 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

2. Transfer

This format can be transferred over:

  1. UDP.  
  2. IP.
  3. Interface to XML Guard or other interface.

3. XML Messages

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

3.1. 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>

3.2. 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>
	<Source>
		<IPv4>192.168.0.0</IPv4>
	</Source>
	<IPProtocol>51</IPProtocol>
	<Size>392</Size>
	<ImplicitIP/>
	<ARQ/>
	<Priority>7</Priority>
	<NotInOrder/>
	<NodeConfirmation/>
</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.

There is a very small risk that packets will be lost and this needs to be allowed for. 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 protocol information and other data on the IP can help accurate correlation.

3.4. 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>