11. Best Practices

11.1. Choosing the Granularity of Your Permissions Documents for DomainParticipants

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

When you use Builtin Security Plugins, the Permissions Document 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 Document is always sent during Authentication so that every DomainParticipant knows about every other DomainParticipant’s permissions. The Permissions Document is signed by the Permissions CA, which guarantees its authenticity.

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

Storage overhead: the shared Permissions Document will have multiple entries (corresponding to the permissions of multiple DomainParticipants). Thus, every DomainParticipant will need to store a bigger Permissions Document.
Network usage overhead: when two DomainParticipants discover each other, the shared Permissions Document still needs to be sent both ways, and it’s large. Individual Permissions Documents are smaller.
Processing and memory consumption overhead: the signature in the received Permissions Document needs to be verified against the Permissions CA’s digital certificate. The bigger the Permissions Document, the more computational power needed to verify its signature. Searching through a Permissions Document with multiple entries also increases the computational cost.

To avoid this overhead, we recommend using individual Permissions Documents 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 Document, any DomainParticipant trusting that Permissions CA can verify whether another DomainParticipant has the permissions it claims. For more information, see Contents of Your Permissions Documents.

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.

11.4. Keeping Governance and Permissions Compatibility Across Different Security Plugins Versions

Use the must_interpret attribute with a value of FALSE when a Connext release introduced an XML tag that is not supported in previous versions. XML tags that have must_interpret="false" will not trigger a parser error during XML validation.

For example, if a future version supports a hypothetical my_own_algorithms tag in the Governance Document, you could have:

...
<allowed_security_algorithms>
    <symmetric_cipher>
        <algorithm>AES128+GCM</algorithm>
        <algorithm>AES192+GCM</algorithm>
        <algorithm>AES256+GCM</algorithm>
    </symmetric_cipher>

    <my_own_algorithms must_interpret="false">
        <algorithm>CUSTOM+VALUE</algorithm>
    </my_own_algorithms>
</allowed_security_algorithms>
...

Other Connext releases that do not understand the my_own_algorithms tag will not fail during validation of the Governance Document. The XML parser will ignore my_own_algorithms and all its children.

Read How the Governance Document is Interpreted and How the XML is Validated in the Core Libraries User’s Manual for more information on the must_interpret attribute.