2014年までの現在、RTI Connextを使用したDDS通信の場合、セキュアな通信を実現するにはDTLS/TLS transport plug-inを用いるのが一般的となっています。(2014年に"DDS Security"規格が定まったため、今後変化するでしょう。)
この時、当たり前のことですが、セキュアであるには同一内容のTopicが外部に流れないようにしなくてはなりません。
しかし、RTI Connextは「標準で」UDPv4およびshmem(どちらも平文)のtransport pluginが組み込まれています。
このため、DTLS/TLSを使用される際には、以下に記す例のように、必ずparticipant_qos.transport_builtin.maskにMASK_NONEを設定し、組み込まれているtransport pluginをすべて外してください。
<participant_qos>
(略)
<transport_builtin>
<mask>MASK_NONE</mask>
</transport_builtin>
その後、例えばDTLSを使用する場合に以下の様にしてDTLSのtransport plug inの組込みを指定します。
<property>
<value>
(略)
<element>
<name>dds.transport.load_plugins</name>
<value>dds.transport.dtls_plugin.dtls</value>
</element>
<element>
<name>dds.transport.dtls_plugin.dtls.library</name>
<value>libnddstransporttls.so</value>
</element>
<element>
<name>dds.transport.dtls_plugin.dtls.create_function</name>
<value>NDDS_Transport_DTLS_create</value>
</element>
<element>
<name>dds.transport.dtls_plugin.dtls.tls.verify.ca_file</name>
<value>cacert.pem</value> <!-- 暗号化通信用ファイル｡OpenSSLのツールを使用して作成>
</element>
</value>
</property>
participant_qos.transport_builtin.mask = MASK_NONE を行わなければ、同一内容のTopicがDTLS, UDPv4, shmemの全てで送受信されることになります。
また、DTLSを使用する場合、Topic用の鍵をpublisher側、subscriber側それぞれで下記の様に設定します。(TLSの場合も同様となります。)
<participant_qos>
(略)
<property>
<value>
<element>
<name>dds.transport.dtls_plugin.dtls.tls.identity.certificate_chain_file</name>
<value>rep_t1.pem</value> <!-- 暗号化通信用ファイル｡OpenSSLのツールを使用して作成>
</element>
</value>
</property>
</participant_qos>
なお、暗号化トランスポートを使用すると、Discovery Topicも暗号化されるため、解凍鍵を持つ相手を直接Discoveryしなければ、DDS通信は開始されません。(平文の場合は、他のParticipantoがDiscovery情報を伝えてくれます。しかし暗号化されている場合は、同じ暗号化設定がされていないとDiscovery情報のリレーを行えません。)
このため、participant_qos.discovery.initial_peersにて、接続先IPを明記することが強くお勧めいたします。
(これを行うことで、Discovery時間を可能な限り短くすることができます。
Discoveryについての詳細はUser's Manualの8.5.2 DISCOVERY QosPolicy (DDS Extension)をご参照ください。)