13. What’s Different Between the RTI Security Plugins and the OMG Security Specification¶

This chapter describes differences between RTI Security Plugins 6.1.1 and the OMG DDS Security specification (version 1.1). This section does not include additional features, but differences that can be considered as known issues (either missing functionality or behaviors from the RTI Security Plugins that conflict the DDS Security specification).

13.1. Differences Affecting Builtin Plugins to be Addressed by Next DDS Security Specification¶

13.1.1. Access Control¶

13.1.1.1. Mutability of Publisher PartitionQosPolicy¶

The DDS Security specification, Section 7.3.5 Immutability of Publisher Partition Qos in combination with non-volatile Durability kind, defines the kind of DataWriters that a Publisher must contain in order for its PartitionQosPolicy to be immutable. These DataWriters meet the following two criteria:

The DataWriter either encrypts the SerializedPayload submessage element or encrypts the Data or DataFrag submessage elements.
The DataWriter has the DurabilityQosPolicy kind set to something other than VOLATILE.

The next version of the specification will change the first criterion to be the following:

The TopicSecurityAttributes for that DataWriter have is_read_protected set to TRUE.

The second criterion still applies. The Security Plugins use this new criterion to determine PartitionQosPolicy immutability. (is_read_protected corresponds to enable_read_access_control in the Governance Document, see enable_read_access_control (topic_rule).)

13.2. Differences Affecting Builtin Plugins¶

13.2.1. General¶

13.2.1.1. Support for Infrastructure Services¶

The DDS Security specification, Section 7.1.1.4 Unauthorized Access to Data by Infrastructure Services, describes the mechanism for preventing unauthorized access to data by infrastructure services. To support this capability, certain functions have an output parameter called relay_only. While Security Plugins functions include this additional parameter, the Security Plugins do not implement this mechanism, and the parameter is currently not used or populated. As such, the relay tag under the Permissions File’s allow_rule and deny_rule is ignored.

13.2.2. Access Control¶

13.2.2.1. Placement of the <default> rule in the Permissions File¶

The DDS Security specification, 9.4.1.3.2.3 Rules Section, specifies that the default rule, if present, must appear after all allow and deny rules. The Security Plugins do not check the default rule’s placement.

13.3. Differences Affecting Custom Plugins¶

13.3.1. Authentication¶

13.3.1.1. Revocation¶

The DDS Security specification, Section 8.3.2.12 AuthenticationListener, describes the mechanism for revoking identities. The Security Plugins do not implement this mechanism. This release supports looking up a certificate revocation list (CRL) during DomainParticipant creation and discovery (see Certificate Revocation).

13.3.1.2. Discovery Failure If Exchanging Fewer Than Two Handshake Messages¶

If two DomainParticipants use a custom authentication plugin in which at least one DomainParticipant does not send any handshake messages, then the endpoints of the DomainParticipants may fail to discover each other. Such a plugin is possible according to the DDS Security specification, Figure 9 - Authentication plugin interaction state machine (if validate_remote_identity() returns VALIDATION_OK in at least one DomainParticipant), and the specification gives no indication that such a plugin should result in discovery failure.

The DDS Security specification, Table 55 - Description of built-in authentication protocol indicates that the builtin authentication plugin uses three total handshake messages: two from one DomainParticipant and one from the other DomainParticipant. The Security Plugins builtin authentication plugin follows this approach, so the discovery failure will not happen unless you are using a custom authentication plugin.

13.3.2. Access Control¶

13.3.2.1. check_local_datawriter_register_instance¶

The DDS Security specification, Section 8.4.2.9.7 Operation: check_local_datawriter_register_instance, describes the check_local_datawriter_register_instance() operation. The Security Plugins do not implement this operation.

13.3.2.2. check_local_datawriter_dispose_instance¶

The DDS Security specification, Section 8.4.2.9.8 Operation: check_local_datawriter_dispose_instance, describes the check_local_datawriter_dispose_instance() operation. The Security Plugins do not implement this operation.

13.3.2.3. check_remote_datawriter_register_instance¶

The DDS Security specification, Section 8.4.2.9.15 Operation: check_remote_datawriter_register_instance, describes the check_remote_datawriter_register_instance() operation. The Security Plugins do not implement this operation.

13.3.2.4. check_remote_datawriter_dispose_instance¶

The DDS Security specification, Section 8.4.2.9.16 Operation: check_remote_datawriter_dispose_instance, describes the check_remote_datawriter_dispose_instance() operation. The Security Plugins do not implement this mechanism.

13.3.2.5. check_local_datawriter_match / check_local_datareader_match¶

When calling check_local_datawriter_match() / check_local_datareader_match(), the subscription_data and publication_data parameters are not set.

13.3.2.6. Revocation¶

The DDS Security specification, Section 8.4.2.10 AccessControlListener interface, describes the mechanism for revoking permissions. The Security Plugins do not implement this mechanism.

13.3.2.7. PermissionsToken¶

The DDS Security specification, Table 10 Additional parameter IDs in ParticipantBuiltinTopicData, mentions PermissionsToken as a new parameter in ParticipantBuiltinTopicData. The Security Plugins send this parameter, but when receiving this parameter, it is not used in any Access Control functionality. The builtin Access Control Plugin is specified to use PermissionsToken to validate the Access Control plugin name and version of previously authenticated remote participants.

13.3.2.8. check_remote_topic¶

The DDS Security specification, Section 8.4.2.9.12 Operation: check_remote_topic, describes the check_remote_topic() operation, which receives a TopicBuiltinTopicData as an input. Instead of invoking this operation when the remote DomainParticipant creates a certain Topic, Connext DDS invokes this operation when discovering the first DataWriter or DataReader belonging to that Topic-DomainParticipant combination.

This distinction matters if the implementation of check_remote_topic() considers any of the QosPolicies within the TopicBuiltinTopicData structure. (The builtin plugins do not consider these QosPolicies.) For example, if a DomainParticipant, P1, creates two DataReaders of the same topic, another DomainParticipant, P2, will call check_remote_topic() only when it discovers the first DataReader. If the second DataReader’s DeadLineQosPolicy matches that of P1’s TopicQos and the first DataReader’s DeadlineQosPolicy does not match, then check_remote_topic() will receive the wrong DeadlineQosPolicy as part of the input TopicBuiltinTopicData. This problem will only occur if check_remote_topic() considers the DeadlineQosPolicy when deciding whether to return TRUE or FALSE.

13.3.3. Cryptography¶

13.3.3.1. inline_qos for encode/decode_serialized_payload¶

The DDS Security specification, Table 38 - CryptoTransform interface, indicates that the encode_serialized_payload() operation outputs an extra_inline_qos parameter and that the decode_serialized_payload() operation inputs an inline_qos. Connext DDS does not support either of these parameters.