This document describes an end to end protocol over UDP or direct over IP. This protocol specifies an approach of providing the STANAG 5066 service over UDP/IP. This is to enable STANAG 5066 to be used over IP and in particular to make of IP Crypto including IPsec and HAIPE.

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)

Black Side IP over HF is provided using a black side STANAG 5066 system. To provide the full service, this protocol needs to be used with two other capabilities to communicate service elements with the black side STANAG 5066 system:

  1. Some STANAG 5066 service elements needs to be communicated out of band to the black side STANAG 5066. Approaches to achieve this are specified in [Providing Control Parameters for STANAG 5066 over UDP through IP Crypto] (S5066-APP6).
  2. Confirmation and Rejects need to be provided from black side, as well as flow control. An approach to achieve this is specified in [XML Control Messages for STANAG 5066 over UDP through a Data Diode] (S5066-APP7).

It is anticipated that the black side STANAG 5066 system will provide TRANSEC using AES and the mechanism defined in [STANAG 5066 TRANSEC Crypto Layer using AES and other Protocols (S5066-EP14)].

1. Architecture

This specification specifies behavior of a SIS server, as shown in the diagram above. Notes:

  1. SIS Clients communicate with the SIS Server using standard STANAG 5066 SIS protocol. Applications using SIS will operate in a standard manner.
  2. SIS servers communicate end to end using the protocol specified in this document, either over UDP or direct over IP.
  3. It is anticipated that this protocol will be sent through IP Crypto to a black side STANAG 5066 system.
  4. Some service requirements (ARQ and Priority) need to be communicated out of band to the HF subsystem. This can be achieved by using [Providing Control Parameters for STANAG 5066 over UDP through IP Crypto] (S5066-APP6).
  5. Control information from the HF subsystem is needed to provide the SIS service. An approach to this is specified in [XML Control Messages for STANAG 5066 over UDP through a Data Diode] (S5066-APP7).

2. Extended IP Service

The natural and simplest way to deploy IP Crypto is in an environment where all applications run over IP. This is not viable for HF. Many IP applications, particularly bulk applications and HTTP over TCP will not run efficiently when IP is mapped directly only HF as an IP subnet using STANAG 5066 F.12 IP Client. This is discussed in the Isode whitepaper [Measuring and Analysing STANAG 5066 F.12 IP Client].  

A number of applications built for HF have optimized protocols over STANAG 5066 and it is highly desirable to use these protocols.

As a consequence, IP Crypto needs to be used in a special manner.

The architecture described here provides an extended IP service by:

  1. Additional control information from red to black side using the mechanisms set out in [Providing Control Parameters for STANAG 5066 over UDP through IP Crypto] (S5066-APP6); and
  2. Additional control information from black to red using a data diode as specified in [XML Control Messages for STANAG 5066 over UDP through a Data Diode] (S5066-APP7).

This extended IP service is contrasted to standard IP in the following table.

Capability Extended IP Service Standard IP Service
IPv4/IPv6 Source and Destination Addressing Yes Yes
Unreliable (non-ARQ) data Yes Yes
Reliable (ARQ) data Yes No
Handling black side data loss Yes No
Priority Yes No
Flow Control Yes No

 

3. STANAG 5066 Services Provided

The following STANAG 5066 Services are not provided by this specification:

  1. Hard Links. These are not used by any SIS applications.
  2. Expedited Data. This is not used by any SIS applications.
  3. Management Protocol. STANAG 5066 defines framework protocol, but no use of it.
  4. Rank.   There is no variation of handling based on Rank.
  5. TTL.  It is not possible for the application to set TTL, so default will always be used.

For Unidata, the “Non-ARQ with Errors” service is not provided.

Omitting these services is not expected to have any practical impact.

Only destination SAP is used. There does not appear to be operational benefit of allowing source SAP to be different.

4. Providing Services and Protocol

This STANAG 5066 SIS services are provided as follows.

4.1 Bind

Bind services are provided locally by the SIS server. The server shall enforce a maximum of one connection per SAP.

The MTU will be determined based on constraints of the underlying system. For older systems, it may need to be reduced to ensure no IP fragmentation. Each PDU will need to be included in a U_PDU of max size likely to be 2048 in the black side STANAG 5066 system. There will be overheads from IP transport and IP crypto. As a consequence the MTU is expected to be set to a value slightly less that 2048 to allow for these overheads.

4.2 Keep Alive

The SIS server shall send Keep Alives at intervals.

4.3 Flow Control

Flow control shall be provided to SIS clients based on information from the HF subsystem, provided by a mechanism following S5066-APP7 or equivalent.

4.3 Unidata

Unidata requests and indications and client confirmation are provided by the UDP protocol specified below.

Node confirmation and rejects shall be provided to SIS clients based on information from the HF subsystem, provided by a mechanism such as the one specified in S5066-APP7.

Unidata priority, “in order”, and ARQ/non-ARQ information is included in the protocol defined below, so that this information can be supplied to the receiving system in S_UNIDATA_INDICATION. This information shall also be communicated to the HF subsystem following S5066-APP6 or equivalent procedure.

Unidata is carried in UDP using the following format.

  MSB
7
6 5 4 3 2 1 LSB
0
0 Version = 0 Not Used In Order ARQ Node Confirm Client Confirm Type=0
1
SAP
Priority
2
3
Confirmation ID (optional)
4



n
U_PDU




The PDU is encoded as follows:

  1. Version is set to 0 for this version of the Protocol.
  2. The Type field is set to 0 for U_PDU
  3. If client confirmation is requested, Client Confirm is set to 1, and the optional Confirmation ID is included in the PDU.
  4. If Node Confirmation is requested, the Node Confirm bit is set to 1.  This is to communicate service requested to the receiving client.
  5. If ARQ is requested, the ARQ bit is set to 1.
  6. If “in order” is requested, the “In Order” bit is set to 1.
  7. SAP is set to the SAP.
  8. Priority is set to the STANAG 5066 requested priority.
  9. U_PDU is the U_PDU.

Client Confirmation is provided using the following PDU, when client confirmation is requested and the U_PDU is delivered to the client.

  MSB
7
6 5 4 3 2 1 LSB
0
0 Version = 0
Not Used
Type=1
2
3
Confirmation ID

Type value is set to 1 for the Client Confirm.  Confirmation ID shall be the value taken from the arriving U_PDU.

These PDUs shall be sent over UDP.   The UDP destination port shall be 95066 or another value agreed for the deployment.  IP fragmentation shall not be used.

IPv4 or IPv6 may be used.   Note that no STANAG 5066 addressing is used in protocol.  SIS servers must map provided STANAG 5066 source and destination addresses into equivalent IPv4 or IPv6 addresses. 

The provided Rank of Unidata is ignored.

The provided TTL of Unidata is used to set a timer if Node or Client confirmation is requested.   In the event of the timer expiring and no reject or confirmation for the Unidata being received, the SIS server shall reject the Unidata with reason “TTL expired”.