17. Support for RTI Real-Time WAN Transport¶
Real-Time WAN Transport is compatible with the RTI Security Plugins. The integrity of the Binding Ping messages can be protected using a pre-shared key as described in Binding Ping Messages Security. When using Cloud Discovery Service, the communication with this service can be protected by a pre-shared key as described in Security Considerations when Using Cloud Discovery Service.
17.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 a pre-shared key that must be set in all DomainParticipants using
the cryptography.rtps_protection_key
property
(see Table 6.8).
When this property is set, Real-Time WAN Transport computes the HMAC over the Binding Ping
message using a shared secret derived from the pre-shared key.
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.
<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>com.rti.serv.secure.cryptography.rtps_protection_key</name>
<value>str:key0</value>
</element>
</value>
</property>
</participant_qos>
</qos_profile>
</dds>
17.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 a pre-shared key (the Participant Discovery Protection Key) that must be set in all DomainParticipants and Cloud Discovery Service:
DomainParticipants can set this pre-shared key using the
authentication.participant_discovery_protection_key
property (see Table 4.2).Cloud Discovery Service can set this pre-shared key by updating the
property
tag insidesecurity
tag (see Security Configuration in the Cloud Discovery Service User’s Manual).
Configuring the Participant Discovery Protection Key is mandatory to use Cloud Discovery Service with DomainParticipants that enable the Security Plugins and Real-Time WAN Transport.
Attention
The current version of Cloud Discovery Service does not support the Authentication Plugin as described in Authentication. To protect the integrity of participant announcements exchanged, configure the Participant Discovery Protection Key, as demonstrated in Listing 17.3.
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.
<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>com.rti.serv.secure.cryptography.rtps_protection_key</name>
<value>str:key0</value>
</element>
<element>
<name>com.rti.serv.secure.authentication.participant_discovery_protection_key</name>
<value>str:key1</value>
</element>
</value>
</property>
</participant_qos>
</qos_profile>
</dds>
<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>com.rti.serv.secure.authentication.participant_discovery_protection_key</name>
<value>str:key1</value>
</element>
<element>
<name>com.rti.serv.secure.cryptography.rtps_protection_key</name>
<value>str:key0</value>
</element>
</property>
</security>
</cloud_discovery_service>
</dds>
Note that, in addition to the Participant Discovery Protection Key, the examples
above also set the RTPS Protection Key to protect Binding Pings. Setting
this key is required if the cryptography.rtps_protection_key
property
is used by your DomainParticipants.
17.2.1. Protection Against a Cloud Discovery Service Participant Announcement Replay Attack¶
To protect against participant announcement replay attacks, Cloud Discovery Service computes an HMAC over the participant announcements it sends, using an epoch that is increased with every new participant announcement message:
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).
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 HMAC, 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).
The configuration of Cloud Discovery Service can be updated to use this property as follows:
<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>com.rti.serv.secure.authentication.participant_discovery_protection_key</name>
<value>str:key1</value>
</element>
<element>
<name>com.rti.serv.secure.cryptography.rtps_protection_key</name>
<value>str:key0</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>