21. Support for RTI Real-Time WAN Transport

Real-Time WAN Transport is compatible with the Security Plugins. The integrity of the Binding Ping messages can be protected using The Lightweight Builtin Security Plugins as described in Binding Ping Messages Security. When using Cloud Discovery Service, the communication with this service can also be protected by Pre-Shared Key Protection as described in Security Considerations when Using Cloud Discovery Service.

Note

Additionally, to Pre-Shared Key Protection, Cloud Discovery Service and Real-Time WAN Transport can be protected with <<deprecated>> cryptography.rtps_protection_key and authentication.participant_discovery_protection_key. They are functional and intended for use legacy systems only. This functionality will be removed in the future and is not suitable for new deployments. For detailed description about legacy properties, please refer to Security Plugins 6.1.2 documentation.

21.1. Binding Ping Messages Security

Real-Time WAN Transport uses special RTPS messages called Binding Ping messages to open NAT bindings and to resolve UUID locators into public IP transport addresses. These PING messages are exchanged between DomainParticipants before they authenticate with each other (see Authentication), and they contain the UUID and the RTPS port of the locator with which they are associated (see Binding Ping Messages in the Core Libraries User’s Manual).

An outside attacker can try to modify Binding Ping messages in transit, in order to cause a failure in the protocol that establishes WAN connectivity between DomainParticipants. For details on this protocol, see Advanced Concepts in the Core Libraries User’s Manual.

To protect against this attack, the integrity of the Binding Ping messages can be protected by using Pre-Shared Key Protection that must be set in all DomainParticipants using the dds.sec.crypto.rtps_psk_secret_passphrase property and, optionally, dds.sec.crypto.rtps_psk_symmetric_cipher_algorithm (see Configuring Pre-Shared Key Protection). If the pre-shared_key is set, Real-Time WAN Transport protects by default the integrity and confidentiality of the Binding Ping Message. The decision of whether to protect only integrity, or to protect confidentiality as well, depends on the value of the rtps_psk_protection_kind XML tag in the Governance Document. In the case of Lightweight Builtin Security Plugins (which does not support the Governance Document), it is configured through the new dds.sec.access.rtps_psk_protection_kind property. The default value is ENCRYPT (protect both integrity and confidentiality). For details, see Table 5.3.

The following example enables security to protect the integrity of the Binding Ping messages in the ExternalParticipant QoS Profile, as described in Peer-to-Peer Communication with a Participant that has a Public Address in the Core Libraries User’s Manual.

Listing 21.1 External Participant Configuration to Protect Binding Pings

<dds>
  <qos_profile name="ExternalParticipant">
    <base_name>
      <!-- Loads the Security Plugins -->
      <element>BuiltinQosSnippetLib::Feature.Security.Enable</element>
    </base_name>

    <participant_qos>
      <transport_builtin>
        <mask>UDPv4_WAN</mask>
        <udpv4_wan>
          <public_address>50.10.23.45</public_address>
          <comm_ports>
            <default>
              <host>1234</host>
              <public>2345</public>
            </default>
          </comm_ports>
        </udpv4_wan>
      </transport_builtin>
      <property>
        <value>
          <element>
            <name>dds.sec.auth.identity_ca</name>
            <value>file:./identity_ca.pem</value>
          </element>
          <element>
            <name>dds.sec.auth.identity_certificate</name>
            <value>file:./identity_certificate.pem</value>
          </element>
          <element>
            <name>dds.sec.auth.private_key</name>
            <value>file:./private_key.pem</value>
          </element>
          <element>
            <name>dds.sec.access.permissions_ca</name>
            <value>file:./permissions_ca.pem</value>
          </element>
          <element>
            <name>dds.sec.access.governance</name>
            <value>file:./signed_governance.p7s</value>
          </element>
          <element>
            <name>dds.sec.access.permissions</name>
            <value>file:./signed_permissions.p7s</value>
          </element>
          <element>
            <name>dds.sec.crypto.rtps_psk_secret_passphrase</name>
            <value>data:,0:DGF1fq4fOmLCea06zV5z9JmXLqbw9XOopJpxCMaThCOx5XG</value>
          </element>
        </value>
      </property>
    </participant_qos>
  </qos_profile>
</dds>

21.2. Security Considerations when Using Cloud Discovery Service

Cloud Discovery Service (CDS), in combination with Real-Time WAN Transport (RWT), plays a key role in facilitating the NAT traversal process. The service does this by resolving the public IP transport addresses associated with the UUID locators received from a DomainParticipant (P1) as part of its participant announcements (PA). For further details, see Transport Locators in the Core Libraries User’s Manual.

Once Cloud Discovery Service resolves the public IP transport addresses, it modifies the participant announcement sent by P1 to include these public addresses as part of the locators and sends the updated participant announcement to the other DomainParticipants so that they can establish communication with P1. NAT Traversal in the Cloud Discovery Service User’s Manual provides additional details on the protocol for NAT traversal with Cloud Discovery Service.

An outside attacker can try to modify or replay the participant announcement messages sent by Cloud Discovery Service to the DomainParticipants, in order to cause a failure in the protocol that establishes WAN connectivity between DomainParticipants. To protect against these attacks, you can protect the exchange of participant announcements between Cloud Discovery Service and the DomainParticipants through Pre-Shared Key Protection that must be set in all DomainParticipants and Cloud Discovery Service:

DomainParticipants can set the pre-shared key using the dds.sec.crypto.rtps_psk_secret_passphrase property (see Configuring Pre-Shared Key Protection).
DomainParticipants can, optionally, change the Pre-Shared Key Protection algorithm by setting up the dds.sec.crypto.rtps_psk_symmetric_cipher_algorithm property.
Cloud Discovery Service can set Pre-Shared Key Protection by updating the property tag inside security tag (see Security Configuration in the Cloud Discovery Service User’s Manual).

Configuring the Pre-Shared Key Protection is mandatory to use Cloud Discovery Service with DomainParticipants that enable the Security Plugins and Real-Time WAN Transport.

Note

Cloud Discovery Service’s Pre-Shared Key Protection support is based on the Lightweight Builtin Security Plugins. However, since Cloud Discovery Service only exchanges Participant Discovery traffic, there are no restrictions on the configuration for DomainParticipants to interoperate with Cloud Discovery Service enabling Pre-Shared Key Protection.

The following examples enable security to protect the integrity of the participant announcements in the InternalParticipant QoS Profile, as described in Peer-to-Peer Communication with Participants behind Cone NATs Using RWT and CDS in the Core Libraries User’s Manual, and configure Cloud Discovery Service accordingly.

Listing 21.2 Internal Participant Configuration to Protect Participant Announcements and Binding Pings

<dds>
  <qos_profile name="InternalParticipant">
    <base_name>
      <!-- Loads the Security Plugins -->
      <element>BuiltinQosSnippetLib::Feature.Security.Enable</element>
    </base_name>

    <participant_qos>
      <transport_builtin>
        <mask>UDPv4_WAN</mask>
      </transport_builtin>
      <discovery>
        <initial_peers>
          <element>rtps@udpv4_wan://50.10.23.45:2345</element>
        </initial_peers>
      </discovery>
      <property>
        <value>
          <element>
            <name>dds.sec.auth.identity_ca</name>
            <value>file:./identity_ca.pem</value>
          </element>
          <element>
            <name>dds.sec.auth.identity_certificate</name>
            <value>file:./identity_certificate.pem</value>
          </element>
          <element>
            <name>dds.sec.auth.private_key</name>
            <value>file:./private_key.pem</value>
          </element>
          <element>
            <name>dds.sec.access.permissions_ca</name>
            <value>file:./permissions_ca.pem</value>
          </element>
          <element>
            <name>dds.sec.access.governance</name>
            <value>file:./signed_governance.p7s</value>
          </element>
          <element>
            <name>dds.sec.access.permissions</name>
            <value>file:./signed_permissions.p7s</value>
          </element>
          <element>
            <name>dds.sec.crypto.rtps_psk_secret_passphrase</name>
            <value>data:,0:DGF1fq4fOmLCea06zV5z9JmXLqbw9XOopJpxCMaThCOx5XG</value>
          </element>
        </value>
      </property>
    </participant_qos>
  </qos_profile>
</dds>

Listing 21.3 Cloud Discovery Service Configuration to Protect Participant Announcements and Binding Pings

<dds>
  <cloud_discovery_service name="CDS">
    <transport>
      <element>
        <alias>builtin.udpv4_wan</alias>
        <receive_port>2345</receive_port>
        <property>
          <element>
            <name>dds.transport.UDPv4_WAN.builtin.public_address</name>
            <value>50.10.23.45</value>
          </element>
        </property>
      </element>
    </transport>
    <security>
      <property>
        <element>
          <name>dds.sec.crypto.rtps_psk_secret_passphrase</name>
          <value>data:,0:DGF1fq4fOmLCea06zV5z9JmXLqbw9XOopJpxCMaThCOx5XG</value>
        </element>
      </property>
    </security>
  </cloud_discovery_service>
</dds>

21.2.1. Protection Against a Cloud Discovery Service Participant Announcement Replay Attack

To protect against participant announcement replay attacks, Cloud Discovery Service uses Pre-Shared Key Protection which ensures that a message was not manipulated by an external attacker. Participant announcements may, optionally, contain a monotonic epoch number, which increases with every new participant announcement sent. A DomainParticipant will not accept a message that was tampered with or contains an epoch number lower or equal to the one previously received by this DomainParticipant. The protection mechanism can be modelled with the following formula:

\[m = \mathrm{PSK}_k\left(\mathtt{PA} \parallel \mathtt{nonce\_prefix} \parallel \mathtt{epoch}\right)\]

Where:

k is a shared secret derived from the Participant Discovery Protection Key.

nonce_prefix is a number bounded to the Cloud Discovery Service or DomainParticipant sending the participant announcement.

epoch is a number that is increased with every new participant announcement.

The concatenation of the nonce_prefix and the epoch is a nonce that should be unique during the system’s life. In the case of regular DomainParticipants, the nonce_prefix is randomly generated on the DomainParticipant creation, with low chance of collision. In the case of Cloud Discovery Service, the nonce_prefix is derived from the Cloud Discovery Service service name (see XML Tags for Configuring RTI Cloud Discovery Service). Both the nonce_prefix and epoch are fields of RTI-specific PID_SAMPLE_SIGNATURE.

Attention

Different instances of Cloud Discovery Service must have different service names. Otherwise, the nonce_prefix would collide and your system may experience issues with discovery and connectivity loss.

The epoch is initialized with a timestamp obtained from the monotonic clock of the host where Cloud Discovery Service is running. After validating the PSK, a DomainParticipant will not accept participant announcements from Cloud Discovery Service with an epoch smaller than or equal to the last epoch received. This is how the replay attack is avoided.

With this epoch initialization schema, restarting the Cloud Discovery Service instance will be okay because the epoch will be initialized to a value greater than the last one used before the Cloud Discovery Service instance was restarted. However, a restart of the host where Cloud Discovery Service runs will be problematic because the new instantiation of Cloud Discovery Service will use an epoch smaller than the last one published since the monotonic clock counter is reset after the host restart. The result is that the participant announcements sent by the Cloud Discovery Service instance will be ignored by the DomainParticipants already present in the system, and new DomainParticipants will be vulnerable against replayed Cloud Discovery Service messages.

To prevent this situation, you can set the dds.participant.discovery_config.signature_validation_persistent_state_file property in Cloud Discovery Service to store the value of the epoch in a file every time it is increased. A Cloud Discovery Service instance will initialize its epoch to the value contained in the file, if the file exists. For further details on Cloud Discovery Service security configuration, see Security Configuration in the Cloud Discovery Service User’s Manual).

Protection against participant announcement replay attacks can be enabled in Cloud Discovery Service with the following example:

Listing 21.4 Cloud Discovery Service Configuration to Protect Against Participant Announcement Replay Attacks

<dds>
  <cloud_discovery_service name="CDS">
    <transport>
      <element>
        <alias>builtin.udpv4_wan</alias>
        <receive_port>2345</receive_port>
        <property>
          <element>
            <name>dds.transport.UDPv4_WAN.builtin.public_address</name>
            <value>50.10.23.45</value>
          </element>
        </property>
      </element>
    </transport>
    <security>
      <property>
        <element>
          <name>dds.sec.crypto.rtps_psk_secret_passphrase</name>
          <value>data:,0:DGF1fq4fOmLCea06zV5z9JmXLqbw9XOopJpxCMaThCOx5XG</value>
        </element>
        <element>
          <name>dds.participant.discovery_config.signature_validation_persistent_state_file</name>
          <value>cds_epoch.bin</value>
        </element>
      </property>
    </security>
  </cloud_discovery_service>
</dds>