DDSSEC11 — Determining the wire version of the DDS Security Protocol

In the case of the DDS-RTPS wire protocol, the version of the RTPS protocol can be determined from the RTPS header that starts each message.

DDS-Security adds messages to RTPS. In that sense it extends the protocol creating an SRTPS protocol (with additional builtin endpoints, submessages, and submessage elements). However there does not seem to be an obvious way to determine this version from just observing the packets on the wire.

Not having this version may complicate creating future revisions that do not break interoperability and also the development or use of packet level tools like wireshark.

One possible solution is to use the minor version of the RTPS protocol to also encode the version of the secure RTPS protocol. For example current version of RTPS is 2.2 we could say that from now onwards the "odd" version numbers represent "secure" versions of the proceeding "even" version. So the result of DDS Security RTF 1 will be RTPS 2.3 and the result of DDS Interoperability RTF3 will be RTPS 2.4. If these RTFs do not alternate we just skip the intermediate version. For example if DDS Interoperability RTF4 comes without an interweaving DDS-Security we just jump to RTPS 2.6

Proposal:
This DDS-Security RTF will cycle the version of RTPS to the next (2.3)
The current RTPS RTF3 will take that into consideration and indicate the range of sub-messages reserved for security. RTPS RTF3 will then set the RTPS protocol version to "2.4"

Onwards each RTF will update the RTPS version (assuming there are changes to the protocol) because they should know about each other.

In addition we need to say that the Plugin name has the version as part of the name and that the version should be parsed in a certain way to check compatibility. I.e. not require an exact match of the plugin names.

We should also add a "version" properties for each plugin as in dds.sec.auth.version and dds.sec.access,version, these would be propagated.
Also add a dds.sec.auth.common to have an overall version of the spec...

Revise version of RTPS and provide rules for plugin versions

Since the DDS-Security specification adds new RTPS submessages it should also update the version of RTPS to the next one (2.3).

The DDS-Security should spec should also "reserve" a range of RTPS Discovery parameterIds 0x1XXX for the use of the DDS-Security spec and future revisions.

Section 9.3.2 (DDS:Auth:PKI-DH Types) should indicate that the IdentityToken class_id should be parsed up to the last ":" character. The suffix after the column and interpreted as:
<PluginClassName>:<MajorVersion>.<MinorVersion>
If the <PluginClassName> or the <MajorVersion> differ, then the two participants should not attempt authentication.

Section 9.4.2.2 (DDS:Access:Permissions PermissionsToken) should indicate that the PermissionsToken class_id should be parsed up to the last ":" character. The suffix after the column and interpreted as:
<PluginClassName>:<MajorVersion>.<MinorVersion>
If the <PluginClassName> or the <MajorVersion> differ, then the two participants should not try to interpret the permissions document of the other participant.