8. Data Tagging

Data tagging is the ability to add labels or tags to data. You can use data tags to add attributes to the exchanged data, thus providing applications and services with additional metadata. Data tags allow you to label the data produced by a specific DataWriter, so matching DataReaders can use these labels to enrich the samples that come from that DataWriter.

Connext implements data tagging through the DATATAG QosPolicy (see DATATAG QosPolicy in the Core Libraries User’s Manual). This policy allows you to associate a set of tags in the form of (name, value) pairs with a DataWriter or DataReader. As defined by the DDS Security specification, the DataWriter data tag is implemented as an immutable DataWriterQos; the DataReader data tag is implemented as an immutable DataReaderQos. Therefore, this QoS policy cannot be modified after the Endpoint has been created.

As a consequence of the above, the metadata for all samples from a DataWriter is the same. Therefore, the tag is only exchanged in the Endpoint Discovery phase, instead of being sent with each sample. This approach allows for high performance and directly supports typical use cases where each application or DomainParticipant writes data on a Topic with a common set of tags. For use cases where an application needs to add different metadata depending on some criteria, it can create multiple DataWriters with different tags, and use the appropriate DataWriter depending on the metadata the application wants to associate with the sent samples.

The Access Control Plugin can determine whether a DomainParticipant has permission to publish or subscribe using certain tags. More concretely, you can grant DomainParticipants permission to publish or subscribe to specific Topics with specific data tags, as described in Data Tags.

8.1. Example Use Case

Consider the example where a DDS application in an aircraft owned by American Airlines® sends information about its status to nearby airports. To identify the flight, each status update should contain the flight number. You can implement this behavior using data tags. Before the take-off of flight AA1234, you can set the data tag (flightNo, AA1234) for the DataWriter publishing the StatusUpdate Topic. An attacker may want to set a different data tag – for instance, using a different carrier prefix and number, like (flightNo, AS4321). To avoid this scenario, the Airlines Status Updates Consortium should ensure that the Permissions Document for an aircraft only has permission to publish status updates for the flight numbers that they could potentially have. Hence, this American Airlines aircraft would have the following permissions:

<allow_rule>
  <publish>
    <topics>
      <topic>StatusUpdate</topic>
    </topics>
    <data_tags>
      <tag>
        <name>flightNo</name>
        <value>AA*</value>
      </tag>
    </data_tags>
  </publish>
</allow_rule>

If this aircraft tries to publish with a flightNo tag that does not start with AA, it will not be allowed to join the system. More generally, the Access Control Plugin will ensure that Endpoints associated with a data tag can only communicate if they have permission to have that data tag.

8.2. Limitations

Data tags permissions enforcement is not designed as a mechanism to provide data-based permissions, but as a mechanism to create rules around what metadata DataWriters and DataReaders can announce (as part of their discovery information).

In this sense, even if the Access Control Plugin can grant a DomainParticipant permission to create DataWriters and DataReaders with specific data tags, it cannot prevent that DomainParticipant from publishing or subscribing to Topics without announcing any data tags. In other words, the Access Control Plugin cannot enforce the presence of a certain tag. Therefore, if an entity does not present any data tags, it will be allowed in the system.

Using data tags as a mechanism to provide data-based permissions is not supported, nor defined in the current OMG DDS Security specification. Therefore, you can not deny DataWriters or DataReaders with no data tags from joining the system. For example, consider a grant containing the following allow_rule in a Permissions Document:

<allow_rule>
  <publish>
    <topics>
      <topic>Square</topic>
    </topics>
    <data_tags>
      <tag>
        <name>Title</name>
        <value>Engineer</value>
      </tag>
    <data_tags>
  </publish>
</allow_rule>

This grant will not prevent a malicious insider from creating a DataWriter with no data tags and then publishing fake status updates on the Topic Square.

Note that you can read the announced data tags at the application level and make decisions based on that information (see on_subscription_matched and on_publication_matched callbacks). For example, you could decide to ignore a remote DataWriter that has announced no data tags. However, bear in mind that the participant can still join the system before the application ignores it. Therefore it will have access to the symmetric keys associated with the Topic, retaining access to the data shared through the wire.

In conclusion, data tags permissions enforcement should only be used as a mechanism to limit what metadata a DomainParticipant can announce. In order to restrict DomainParticipant access to Topics based on a DataWriter/DataReader-level categorization, Partitions can be used instead.