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

This chapter describes differences between RTI Security Plugins 6.1.0 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:

  1. The DataWriter either encrypts the SerializedPayload submessage element or encrypts the Data or DataFrag submessage elements.

  2. 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:

  1. 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.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.