Using IP Crypto over HF

Background and Requirements

Provision of HF TRANSEC above Modem

For HF communication, data encryption is done above the modem using Crypto placed between modem and Crypto, as illustrated below.

Traditionally, this has been performed using synchronous serial devices such as KIV-7. A modern approach to providing this architecture is set out in [STANAG 5066 TRANSEC Crypto Layer using AES and other Protocols - S5066-EP14] which is the basis for STANAG 5066 Ed4 Annex T.

Providing Type 1 Protection of User Data (COMSEC)

For Military communication over HF, it is usually required to protect all user data with a Type 1 Crypto product which must use Type 1 cryptographic algorithm.  Type 1 is defined by NSA for US use.  It is used in this specification to refer to a concept which is widely used.   Operation directly over the modem is a good architectural choice, as STANAG 5066 protocol includes sensitive information (addressing, protocol) which must be protected.

The synchronous serial devices in current use will need to be replaced medium/long term. Although STANAG 5066 Annex T provides a framework to achieve this, it is anticipated that some nations will not introduce Type 1 Crypto that can be used in this way, due to the high costs of accrediting such a capability.

Provided that Type 1 COMSEC can be achieved for user data, it is generally acceptable to provide protection at the modem level using a product with lower levels of accreditation. 

A general trend in military communications is to use IP Crypto. NATO have set out a vision of NII (networking and information infrastructure) IP Network Encryption (NINE).   This uses High Assurance Internet Protocol Encryptor (HAIPE) which is based on IPsec standards. Countries are developing modern HAIPE/IPsec solutions based on national crypto, with products such as TACLANES.  So, Type 1 IP Crypto products are widely available.

This whitepaper shows how COMSEC protection for HF can be provided with IP Crypto. 

Architecture

IP Crypto sits between red and black sides, providing separation. The details of this is provided in the following sections:

• Use of Open Specifications
• Extended IP Service
• Black Side.
• Red Side.
• Red/Black boundary.

Open Specifications

The approach described in this white paper is formally set out in the following open specifications:

1. “Providing STANAG 5066 services over UDP/IP” (S5066-APP4)
2. “Implicit IP Client over STANAG 5066” (S5066-APP5).  Optional.
3. “Providing Control Parameters for STANAG 5066 over IP through IP Crypto” (S5066-APP6)
4. “XML Control Messages for STANAG 5066 over IP through a Data Diode” (S5066-APP7)

This paper provides an overview of these specifications and rationale for the approach. These papers are published to enable interoperability and for potential inclusion in a future edition of STANAG 5066.

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 IP 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

 

Black Side Architecture

The black side architecture needs to transfer IP packets being sent through the IP Crypto. This is achieved using standard STANAG 5066 using STANAG 5066 Annex F.12 IP Client to do the IP transfer. Key points on the black side architecture:

1. All Data Transferred through IP Crypto.
2. Standard STANAG 5066 Server is used black side. No changes to STANAG 5066 are needed to support this architecture.
3. IP is the only black side service/application. An extended IP Client which can use one of two protocols:
   1. STANAG 5066 F.12 IP Client.
   2. Implicit IP specified in [Implicit IP Client over STANAG 5066 (S5066-APP5)] may be used. This transfers only IP payload (not headers), and receiver constructs IP headers from STANAG 5066 addressing. This can be done because there are a constrained number of addresses and mapping is mechanical. This is preferred, as it reduces overhead.
4. Data transfer between STANAG 5066 and modem is protected using crypto TRANSEC. Use of IP Crypto does not protect STANAG 5066 protocol, which is sensitive. However, accreditation requirements may be reduced as the IP Crypto is protecting all data. It is likely that AES following STANAG 5066 Ed4 will be used, as shown in the diagram.
5. STANAG 5066 can monitor and control the modem directly, as both modem and STANAG 5066 sit black side in this architecture.
6. QoS, reliability, flow control and error handling are handled across the red/black boundary by the Extended IP Client. These mechanisms are described in the red/black architecture section.

Red Side Architecture

On the red side, a SIS server provides the STANAG 5066 SIS service to all applications. This looks exactly like standard STANAG 5066 to all of the applications. This makes the service completely transparent to all the HF applications.
SIS Servers communicate with each other using IP, optionally with UDP over the IP. The IP passes through IP Crypto which provides red/black separation.

Key points on this architecture:

1. All Data through HF goes through IP Crypto.
2. Red side SIS Server provides a subset of the standard STANAG  5066 SIS Service. The following elements of service are not provided (these elements of service are not needed by any applications that Isode is aware of). Rank is removed in STANAG 5066 Ed4 and the first two services are deprecated:
   1. Hard Links.
   2. Expedited Data.
   3. Rank.
   4. TTL.
3. All applications, including all IP services, operate over SIS. IP Services can use a red side STANAG 5066 IP Client Service or a PEP service for TCP and other applications.
4. SIS Server communicate with a new end to end protocol operating over either over IP or UDP, that carries SIS U_PDU, priority, ARQ/non-ARQ, SAP. This provides a simple end to end protocol. The protocol provides end to end acknowledgement option, to provide client acknowledgement service. This protocol is specified in [Providing STANAG 5066 services over UDP/IP - S5066-APP4].
5. S5066-APP4 recommends a direct mapping onto IP which is efficient. It also allows a mapping onto UDP, which is less efficient but may be needed for some deployments.
6. The S5066-APP4 protocol uses IP addressing, as IP addresses must be included, and it seems wasteful to include a second address. A SIS Server must map the STANAG 5066 addresses used by standard STANAG 5066 applications with IP addresses. A future extension might be provided to allow applications to use IP addressing and so avoid this mapping.
7. Controls additional to UDP for QoS, reliability and flow control are described in the Red/Black architecture section.

Red/Black Architecture

The core of the red/black architecture is separation by IP Crypto. In order to address QoS, reliability and flow control, additional information needs to flow in each direction. Red to Black crypto bypass is undesirable for security reasons. It is possible to pass necessary QoS information from red to black without a crypto bypass.

It is necessary to pass monitoring and control information from black to red side. This is achieved by a use of a data diode, which ensures that data only flows black to red. This might be a “physical” data diode that ensures unidirectional data transfer or it may be an XML Guard providing an application data diode service. Further details:

1. IP Crypto provides the COMSEC  and primary red/black separation. This can be used with standard IPsec and the architecture does not have any constraints on the IP Crypto used. IP Crypto will encrypt red side IP information (IPsec tunnel mode), as the IP addressing information is sensitive and should be considered as user data. 
2. IP Crypto key configuration can use two approaches:
   1. IPsec standard session setup (or equivalent) may be used between a pair of nodes not in EMCON (using ARQ transfer).
   2. HAIPE key pre-configuration (or equivalent) is necessary for broadcast, multicast and EMCON operation.
3. Priority and ARQ/non-ARQ need to be communicated from SIS Server (Red Side) to Extended IP Client (black side) to meet QoS objectives. This can be achieve with IP Crypto using one of two mechanisms (the details of which are specified in [Providing Control Parameters for STANAG 5066 over IP through IP Crypto]):
   1. DSCP.  This is preferred, as it is simple and expected to work in most cases; or
   2. Use of IP address (32 addresses needed for all priority ARQ combinations). This will be necessary for IP Crypto where DSCP is not transferred red to black.
4. Control information needs to flow black to red, and this is achieved with a data diode. There are two options for data diode mechanism:
1. An XML Guard (Application Data Diode); or
2. Physical Data Diode that can be interfaced with UDP or a proprietary mechanism
5. The following information needs to be send over the data diode:
1. SIS Flow Control. This enables black side flow control to be passed to red side SIS server and on to red side SIS clients. This ensures working flow control. It is why all data must go through SIS.
2. IP packet matching. Information on each IP packet sent, assigning an “IP ID” to each packet. This will include size, to/from address/, DSCP value, priority, ARQ/non-ARQ. This information will enable the black side to associate an IP ID with each packet sent.
   • NOTE.  Sending an IP packet to IP Crypto will generally lead to a matching packet being quickly sent.  However, it may lead to the IP Crypto sending IP packets to negotiate link setup. The IP Client needs to distinguish link setup packets, which will use a different IP protocol and not send acknowledgement.Red side also needs to allow for IP packet loss, which is expected to be very rare.
3. SIS Confirms and Rejects, using the “IP ID” from b, to enable red side to correlate confirm/reject to initial SIS request.  This ensures reliability.

The details are specified in [XML Control Messages for STANAG 5066 over IP through a Data Diode].

Performance Analysis

This section examines the overheads that are introduced by this approach to use IP Crypto and also provides reference for the subsequent analysis. Application overhead remains the same, as a standard SIS interface is provided by SIS server. Standard STANAG 5066 is used in both cases, and the overheads are going to be very similar. The comparison looks at each of the overheads introduced.

Notes:

1. Blackside IP has three choices. IPv4 headers may be larger than 20 bytes, but this is not expected in this sort of setup. Implicit IP can reduce this overhead.
2. IPsec has a 50 byte header. There is variable padding to address block crypto. AES has 16 byte blocks and so up to 15 bytes of padding.
3. SIS Server Protocol has two bytes in basic operation. If client confirm is used (not usually the case) this will add two bytes in the request and an additional return PDU.

MTU Size

This protocol adds considerable overhead to each STANG 5066 Unidata transferred. Ideally, a maximum STANAG 5066 MTU size of 2048 would be used. Common IP configurations limit IP MTU to 1500 bytes. Setting larger limits is possible, but would generally be operationally awkward. Tests made used a 1400 byte STANAG 5066 MTU.

Bulk Performance

HF performance is typically limited by bulk throughput. This can use large MTUs, and so the performance impact of IP Crypto is dominated by the overhead documented above. While 5-6% overhead is undesirable, this can be acceptable if necessary.

Operating at 75bps

The overhead of around 100 bytes per Unidata will add around 10 seconds at the bottom HF speeds of 75bps. Given that a typical protocol exchange will involve exchange of a number of such PDUs, this is an undesirable overhead. However, it will not prevent use of IP Crypto, even at these lowest speeds.

Isode Products for IP Crypto over HF

Isode has introduced two COTS products supporting all of the protocols in this specification:

1. Icon-IP. The black side Extended IP Client.
2. Icon-SIS. The red side SIS Server.

These products are at pre-release stage, and were used for the performance measurements in the next section. Isode is happy to make these pre-release products available to partners for testing. Progress to full product stage is dependent on commercial interest.

Performance Measurements

Performance measurements were made using Icon-IP and Icon-SIS to validate the theoretical performance calculations and the protocol specifications. Notes on the diagram:

1. Blue components are Isode products or test tools.
2. Icon-5066 and Icon-IP provide the black side service.
3. Icon-SIS provides red side service.
4. Test tool provides load of STANAG 5066 data.
5. IPsec is provided by the pfSense IP router that connects red to black sides.
6. Icon-IP communicates to Icon-SIS using UDP, which could be passed through a data diode.
7. HF simulated a clear 9600 bps link.

The test applied bulk load over an extended period and link utilization was measured. 1400 byte STANAG 5066 MTU size was used for all tests.

Test Layer	Utilization	Overhead
Direct Measurement using black side Icon-5066	92%	-
Measurement with IPsec turned off	93%	1%
Measurement with IPsec	87%	5%

Experience suggests that detailed timings can lead to measurement variations of order 1-2%. These measurements are in line with the theoretical analysis.

Comparison with STANAG 5070 Draft

STANAG 5070 draft specifies use of IP Crypto. Isode;s general view on STANAG 5070 draft is contained in S5066-S5070 Single HF Link Protocol. STANAG 5070 draft has the following characteristics:

• IP Crypto (NINE spec)
• Modified STANAG 5066 red side and black side
• Supports IP directly
• Supports STANAG 5066 Applications
• Data Diode black to red.

This architecture has much in common with the architecture set out in this specification. However, the details are complex do not appear viable. This section gives a tabular comparison of the two specifications.

Capability	This Specification	STANAG 5070
Black Side Server	Standard STANAG 5066	Modified STANAG 5066 (STANAG 5070 Annex D)
Red Side Server	Lightweight SIS Server	Modified STANAG 5066 Server
DSCP for QoS	Preferred option, but alternate option provided for IP Crypto that does not pass DSCP	Mandatory
Data Diode Protocol	Specified in S5066-APP7	Left for vendor implementation choice
Operation with EMCON, Broadcast and Multicast	Yes	Not in current STANAG 5070 version. Support planned.
HAIPE pre-configured key approach	Yes	Yes
IPsec Session Setup	Yes	Not in current STANAG 5070  (STANAG 5070 Annex E requires “The security association shall be pre-stored”).  Constraint may be relaxed in future version.
IP Crypto Type	Any, including commercial IPsec	IP Crypto compliant to STANAG 5070 Annex E.  NINE Crypto recommended. Commercial IPsec generally requires IPsec session setup
Flow Control from Black side applied to applications	Yes	Not defined in current version of STANAG 5070. Left for vendor implementation choice.
Handling Black Side Rejects	Yes	Not defined in current version of STANAG 5070
Handling user IP traffic sent directly to IP Crypto, without red side processing.	No Does not fit architecture	Yes Isode anticipates that performance will be poor.
Narrowband down to 75bps	Yes	Not in current version of STANAG 5070, as TDD approach is inefficient at very low speeds
Operation without IP Crypto	Yes	No

Technical Recommendations

The simple technical recommendation arising from this analysis is that it is preferable to use the TRANSEC crypto for COMSEC and not to use IP Crypto. Reasons:

1. Better throughput.
2. Significantly better performance at the lowest HF speeds.
3. Avoids the complexity of managing two cryptos.

Notes on Moving Forward with IP Crypto over HF

It is clear that use of IP Crypto with HAIPE type devices for operation over HF appears desirable for some nations.

The specifications set out here for IP Crypto over HF work well with acceptable overhead. The specifications and performance analysis have been verified using Isode’s Icon-SIS and Icon-IP products. If there is NATO desire to move forward with IP Crypto over HF, Isode recommends to incorporate these specifications into the next edition of STANAG 5066.