11. Best Practices

11.1. Choosing the Granularity of Your Permissions Files for DomainParticipants

For better performance and reduced network usage, use individual Permissions Files for each DomainParticipant in your secure system. A Permissions File should only specify the permissions for the DomainParticipant loading it.

When you use RTI Security Plugins, the Permissions File specifies what a DomainParticipant is allowed to do, such as what Domains/Partitions it can join and what topics it can read/write. This Permissions File is always sent during Authentication so that every DomainParticipant knows about every other DomainParticipant’s permissions. The Permissions File is signed by the Permissions CA, which guarantees its authenticity.

Although a single Permissions File could technically be used to specify the permissions of every DomainParticipant in the system, this approach comes with a high overhead:

  1. Storage overhead: the shared Permissions File will have multiple entries (corresponding to the permissions of multiple DomainParticipants). Thus, every DomainParticipant will need to store a bigger Permissions File.

  2. Network usage overhead: when two DomainParticipants discover each other, the shared Permissions File still needs to be sent both ways, and it’s large. Individual Permissions Files are smaller.

  3. Processing and memory consumption overhead: the signature in the received Permissions File needs to be verified against the Permissions CA’s digital certificate. The bigger the Permissions File, the more computational power needed to verify its signature. Searching through a Permissions File with multiple entries also increases the computational cost.

To avoid this overhead, we recommend using individual Permissions Files for each DomainParticipant in your system, containing only the grants for that DomainParticipant. Security will not be affected by this implementation; since the Permissions CA signs the Permissions File, any DomainParticipant trusting that Permissions CA can verify whether another DomainParticipant has the permissions it claims. For more information, see Contents of Your Permissions Files.

11.2. Using Serialized Data Protection Along with Submessage/RTPS Protection

Depending on what parts of the communication you want to protect, you could enable Serialized Data Protection (to protect just user data), Submessage Protection (to protect both user data and metadata sent by your user endpoints), or RTPS Protection (to protect all the RTPS traffic sent by your participants).

One valid configuration would be to configure SIGN RTPS Protection, so we ensure the integrity of all the messages exchanged, and then configure ENCRYPT Submessage Protection so the confidentiality of the necessary topics is protected.

Depending on the protection you configure at one level, subsequent level protections could be redundant. For instance, if you set metadata_protection_kind to ENCRYPT, the confidentiality of both data and metadata sent by your user endpoints will be protected, hence there is no point in also having data_protection_kind at the same time. However, there are some use cases where you may want to enable multiple protection kinds at the same time.

For example, if you use Persistence Service and want to store samples in an encrypted format, you need to enable encryption for the data_protection_kind. Suppose you also want to encrypt sequence numbers, GUIDs, ACKNACKs, and HEARTBEATs – then you will also need to enable encryption for the metadata_protection_kind.

In conclusion, often, you don’t need both settings enabled – but there are some use cases where you need both settings enabled.

11.3. Using Separate Domains for Secure and Unsecure Participants

You can use Routing Service to address the use case where secure and unsecure participants need to talk to each other.