.. include:: ../vars.rst .. _chapter-logging: *************************** Security Events and Logging *************************** The |SP| uses its own |LoggingPlugin| to notify you of security events. This |LoggingPlugin| supports the following logging methods (non-exclusive): * Using |CONNEXT|'s own builtin logging system to send security messages * Distributing security log messages over DDS By default, log messages are processed by the |NDDS_Config_Logger|. You can configure which logging methods to use by setting the :property:`logging.mode_mask` property. You can also adjust the verbosity level of the log messages with :property:`logging.verbosity`. See :numref:`RTI Security Plugins Properties for Configuring Logging`. If you distribute log messages over DDS using the |LoggingT|, the messages' log levels are used as the severity values of the :type:`BuiltinLoggingType`. If you are using the |NDDS_Config_Logger|, the messages' log levels are mapped to the values shown in :numref:`Mapping between Logging Plugin and Connext DDS Builtin Logging System`. See :link_um:`Controlling Messages from Connext DDS in the RTI Connext DDS Core Libraries User's Manual ` for more information on the |NDDS_Config_Logger|. See the following sections for more information about the different logging methods [#]_. * :ref:`p2_core/logging:Connext DDS Builtin Logging System` * :ref:`p2_core/logging:Distributed over DDS` .. [#] Before release 6.1.0 of |CONNEXT|, you could choose to redirect the security messages to a file by setting the :property:`logging.log_file` property. In |CONNEXT| 6.1.0, this property has been removed, and using it will result in a |DP| creation failure. You can still redirect the security log to a file by enabling the :value:`BUILTIN` flag in the :property:`logging.mode_mask property` (enabled by default) and configuring the |NDDS_Config_Logger| to use a log file or an output device (see :link_um:`Controlling Messages from Connext DDS in the RTI Connext DDS Core Libraries User's Manual `). Connext DDS Builtin Logging System ================================== When security logging is configured to be written to |CONNEXT|'s own builtin logging system (also known as *NDDS_Config_Logger*), you will see messages that use a JSON format and look something like the following: .. code-block:: text :class: break-lines [2020-09-11 16:17:06.477203] [CREATE DP] RTI_Security_CertHelper_loadPrivateKey:{"DDS:Security:LogTopic":{"f":"10","s":"3","t":{"s":"1599841026","n":"477193999"},"h":"rti-10636","i":"0.0.0.0","a":"RTI Secure DDS Application","p":"2788","k":"security","x":[{"DDS":[{"domain_id":""},{"guid":""},{"plugin_class":"Common"},{"plugin_method":"RTI_Security_CertHelper_loadPrivateKey"}]}],"m":"private_key is not encrypted, yet password is supplied. Aborting participant creation due to inconsistent configuration."}} [2020-09-11 16:17:06.477233] [CREATE DP] RTI_Security_AuthenticationData_create:{"DDS:Security:LogTopic":{"f":"10","s":"0","t":{"s":"1599841026","n":"477228999"},"h":"rti-10636","i":"0.0.0.0","a":"RTI Secure DDS Application","p":"2788","k":"security","x":[{"DDS":[{"domain_id":""},{"guid":""},{"plugin_class":"Authentication"},{"plugin_method":"RTI_Security_AuthenticationData_create"}]}],"m":"failed to read authentication.private_key_file"}} The mapping from the above format to the fields in the ``DDS:Security:LogTopic`` type (see :ref:`p2_core/logging:Builtin Secure Logging Topic`) is as follows: * ``"f"``: ``facility`` * ``"s"``: ``severity`` * ``"t"``: ``timestamp`` (within this field ``"s"`` refers to seconds, and ``"n"`` to nanoseconds) * ``"h"``: ``hostname`` * ``"i"``: ``hostip`` * ``"a"``: ``appname`` * ``"p"``: ``procid`` * ``"k"``: ``msgid`` * ``"m"``: ``message`` * ``"x"``: ``structured_data`` The messages may be preceded by additional information, such as timestamps or GUIDs, depending on the |NDDS_Config_Logger| format configuration and the message :link_api_cpp98:`NDDS_Config_LogLevel `. (See :link_um:`Format of Logged Messages, in the RTI Connext DDS Core Libraries User's Manual `.) By default, the |NDDS_Config_Logger| writes to the standard output, but you can configure it to use a log file or an output device such as a custom logging device or the Distributed Logger. (See :link_um:`Controlling Messages from Connext DDS in the RTI Connext DDS Core Libraries User's Manual ` and :link_um:`RTI Distributed Logger in the Core Libraries User's Manual `.) For messages logged through the |NDDS_Config_Logger|, the verbosity is per application. This affects both messages directly logged through the |NDDS_Config_Logger|, as well as the security events from the builtin |LoggingPlugin| if it is configured to go through the |NDDS_Config_Logger|. If not set, the verbosity will be left unchanged. Therefore, if no |DP| has configured the verbosity, it will be left to the default (:value:`ERROR`). However, if a |DP| has configured the verbosity, it will update it for all the |DPs| within the application. Logging Security Events through the Connext DDS Builtin Logging System ---------------------------------------------------------------------- To make the security log go through the |NDDS_Config_Logger|, enable the :value:`BUILTIN` flag with the :property:`logging.mode_mask` property within the :xmltag:`domain_participant_qos` (this is the default configuration, see :link_um:`Configuring QoS with XML, in the RTI Connext DDS Core Libraries User's Manual `): .. code-block:: xml com.rti.serv.secure.logging.mode_mask BUILTIN The granularity of the log messages depends on the verbosity level set for the security log. You can set the verbosity level as follows, :value:`DEBUG` being the highest verbosity level (see :ref:`p2_core/logging:Properties for Configuring Security Events and Logging`): .. code-block:: xml com.rti.serv.secure.logging.verbosity DEBUG Distributed Over DDS ==================== When the messages are distributed over DDS, the information will be logged using the :type:`BuiltinLoggingType`, following the DDS Security specification. For example, here is how the messages look in *RTI DDS Spy* (using the :command:`-printSample` option) when you use logging distribution over DDS: .. code-block:: text :class: break-lines 1543498637.929123 d +M DCB9C740 DDS:Security:LogTopic DDSSecurity::BuiltinLoggingType facility: 10 severity: DEBUG_LEVEL timestamp: sec: 1543498637 nanosec: 928903998 hostname: "localhost" hostip: "0.0.0.0" appname: "RTI Secure DDS Application" procid: "9654" msgid: "security" message: "received submessage from an endpoint that discovered me but that I haven't discovered yet; dropping submessage hoping it will be repaired. It will not be repaired if the endpoint did not properly share its MasterKeyId in its CryptoToken." structured_data: [0]: key: "DDS" pairs: [0]: name: "guid" value: "dcb9c740.7ecf85eb.42aa8349.1c1" [1]: name: "domain_id" value: "25" [2]: name: "plugin_method" value: "RTI_Security_Cryptography_preprocess_secure_submsg" [3]: name: "plugin_class" value: "Cryptography" Configuring the Logging Distribution ------------------------------------ To distribute the log messages over DDS, enable the :value:`SECURITY_TOPIC` flag with the :property:`logging.mode_mask` [#distributeEnable]_ property within the :xmltag:`domain_participant_qos` (see :link_um:`Configuring QoS with XML, in the RTI Connext DDS Core Libraries User's Manual `): .. code-block:: xml com.rti.serv.secure.logging.mode_mask SECURITY_TOPIC The granularity of the log messages depends on the verbosity level set for the security log. You can set the verbosity level as follows, :value:`DEBUG` being the highest verbosity level (see :ref:`p2_core/logging:Properties for Configuring Security Events and Logging`): .. code-block:: xml com.rti.serv.secure.logging.verbosity DEBUG For more details on configuring the Logging Distribution over DDS, see :numref:`RTI Security Plugins Properties for Configuring Logging`. Builtin Secure Logging Topic ---------------------------- When you distribute the security logging information over DDS, your |DP| will publish this information to the |LoggingT| (``DDS:Security:LogTopic``), as defined in the DDS Security specification. DDS samples in this topic will have the type :type:`BuiltinLoggingType` (``DDSSecurity::BuiltinLoggingType``). This type includes information about the logging level, the |DP| producing the message, a timestamp, etc. You can find the IDL description of the :type:`BuiltinLoggingType` in :file:`/resource/idl/builtin_logging_type.idl`. (See :ref:`p0_about/about_this_doc:Paths Mentioned in Documentation`.) Implementation Notes -------------------- Publication of the Builtin Secure Logging Topic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The ``DDS:Security:LogTopic`` (described in :ref:`p2_core/logging:Subscribing to the Builtin Logging Topic`) is published by the same |DP| that uses the |SP| to communicate securely. Therefore, this topic is published in a |SecDomain|, and the Governance and Permissions Files that apply to that |DP| also apply to this log topic. For this reason, the |PermissionsFile| must allow the ``DDS:Security:LogTopic`` to be published. By default, the ``DDS:Security:LogTopic`` is protected using |SubmsgProtection| set to :xmlval:`SIGN` [#]_ (see :ref:`p2_core/elements_dds_secure_system:Builtin Secure Logging Topic`). .. attention:: There is no option to use a separate “Builtin Logging” |DP| and to share it among multiple |DPs|. Custom QoS Profile for the Builtin Secure Logging Topic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The |SP| publish log messages using the QoS Profile specified by the property :property:`logging.security_topic.profile`. If this property is not set, the |SP| will use the :value:`BuiltinQosLib::Generic.KeepLastReliable.TransientLocal` profile by default, and the |SP| will set history.depth to 64 and publish_mode.kind to DDS_ASYNCHRONOUS_PUBLISH_MODE_QOS. If you specify a custom profile in the property :property:`logging.security_topic.profile`, only |PUB|, |TOPIC|, and |DW| QoS will be used from the specified profile. This is because the |DW| that distributes the log belongs to the same |DP| as the one instantiating the |SP|. As a result, you can use the custom profile for the logger if, for example, you want to change the logger's reliability, but you cannot use it to change the logger's identity (|PrivateKey| and |IdentityCert|). .. [#distributeEnable] Before release 6.1.0 of |CONNEXT|, enabling the logging distribution was done by setting the :property:`logging.distribute.enable` property to :value:`TRUE`. In |CONNEXT| 6.1.0, this property has been removed, and setting it will result in a |DP| creation failure. .. [#] In |CONNEXT| 5.3.0, the |LoggingT| did not use |SubmsgProtection| (which did not comply with the DDS Security specification). For backward compatibility, you can choose to disable |SubmsgProtection| in this topic with the :property:`access_control.use_530_logging_protection property` (see :numref:`Additional RTI Security Plugins Properties for Configuring Logging Distributed Over DDS`). Advanced Logging Concepts ========================= Interface Between the Logging Plugin and the Connext DDS Builtin Logging System ------------------------------------------------------------------------------- Log messages generated by the |LoggingPlugin| in the |SP| and those generated by the |NDDS_Config_Logger| (which is the default method) have a different structure. For example, the |LoggingPlugin| includes information about the process ID (procid) and the host (hostname, hostip) as fields of the ``DDSSecurity::BuiltinLoggingType`` type. To provide this information when using the |NDDS_Config_Logger|, security messages use a JSON format, as specified in :ref:`p2_core/logging:Connext DDS Builtin Logging System`. The log level values used by these logging systems are also different. :numref:`Mapping Between Logging Plugin and Connext DDS Builtin Logging System` shows the mapping between |LoggingPlugin| log values and the |NDDS_Config_Logger| log values. For example, messages marked as :value:`EMERGENCY`, :value:`ALERT`, :value:`CRITICAL`, or :value:`ERROR` in the |SP| are translated to :value:`ERROR` when using the |NDDS_Config_Logger|. .. list-table:: Mapping Between |LoggingPlugin| and |NDDS_Config_Logger| :name: Mapping Between Logging Plugin and Connext DDS Builtin Logging System :widths: 48 52 :header-rows: 1 :class: longtable * - |LoggingPlugin| (|SP|) Log Level Values [#]_ - |NDDS_Config_Logger| Log Level Values [#]_ * - :value:`DDS_LOGGING_EMERGENCY_LEVEL` |BR| :value:`DDS_LOGGING_ALERT_LEVEL` |BR| :value:`DDS_LOGGING_CRITICAL_LEVEL` |BR| :value:`DDS_LOGGING_ERROR_LEVEL` - :value:`NDDS_CONFIG_LOG_LEVEL_ERROR` * - :value:`DDS_LOGGING_WARNING_LEVEL` - :value:`NDDS_CONFIG_LOG_LEVEL_WARNING` * - :value:`DDS_LOGGING_NOTICE_LEVEL` |BR| :value:`DDS_LOGGING_INFORMATIONAL_LEVEL` - :value:`NDDS_CONFIG_LOG_LEVEL_STATUS_LOCAL` * - :value:`DDS_LOGGING_INFORMATIONAL_DEBUG` - :value:`NDDS_CONFIG_LOG_LEVEL_DEBUG` .. [#] These values correspond to the values listed in :property:`logging.verbosity` (see :numref:`RTI Security Plugins Properties for Configuring Logging`). .. [#] These values are described in :link_um:`Controlling Messages from Connext DDS in the RTI Connext DDS Core Libraries User's Manual `. Subscribing to the Builtin Logging Topic ---------------------------------------- To get the security logging information that is being distributed over DDS, you will need to create an application that subscribes to the |LoggingT|: * Topic name: ``DDS:Security:LogTopic`` * Type name: ``DDSSecurity::BuiltinLoggingType`` .. note:: Since the log messages are distributed in a secured domain, your subscriber needs an identity (|PrivateKey| and |IdentityCert|). In addition, it needs to have permission to subscribe to topic ``DDS:Security:LogTopic``; this permission needs to be included in its |PermissionsFile|. You can subscribe to the |LoggingT| with *RTI DDS Spy* using the :command:`-printSample` option. .. code-block:: text rtiddsspy -printSample -domainId -qosProfile Alternatively, to create a custom subscriber, you can start from the IDL containing the definition of the ``DDSSecurity::BuiltinLoggingType``, which can be found here: :file:`/resource/idl/builtin_logging_type.idl`. (See :ref:`p0_about/about_this_doc:Paths Mentioned in Documentation`.) With the IDL, you can run :command:`rtiddsgen` to generate type support code and example code. For example, the following command will generate all the files you need to access the ``DDS:Security:LogTopic`` topic from your |CONNEXT| application: .. code-block:: text rtiddsgen -language C -example x64Linux3gcc4.8.2 -unboundedSupport builtin_logging_type.idl .. important:: You need to use the command-line option :command:`-unboundedSupport` because ``DDSSecurity::BuiltinLoggingType`` contains strings without a specified limit. By default, :command:`rtiddsgen` will limit unbounded strings to 255 characters, unless you specify the :command:`-unboundedSupport` option. Without this option, the type support code will not be compatible with the type used by |SP|, and you won't be able to receive any messages. For more information about the use of unbounded support with builtin types, see :link_um:`Managing Memory for Builtin Types in the RTI Connext DDS Core Libraries User's Manual `. Properties for Configuring Security Events and Logging ====================================================== The following properties in the |DP| property configure Logging: .. list-table:: |RTI_SP| Plugins Properties for Configuring Logging :name: RTI Security Plugins Properties for Configuring Logging :widths: 40 60 :header-rows: 1 :class: longtable * - Property Name (prefix with :property:`com.rti.serv.secure.`) [#fPrefix]_ - Property Value Description * - :property:`logging.log_level` (deprecated) - :required:`Optional` The logging verbosity level. This setting applies to all methods of security logging (the :ref:`p2_core/logging:Connext DDS Builtin Logging System` and :ref:`p2_core/logging:Distributed Over DDS`). All log messages at and below the :property:`logging.log_level` setting will be logged. This property can take any of the following values: * :value:`0`: emergency * :value:`1`: alert * :value:`2`: critical * :value:`3` (default): error * :value:`4`: warning * :value:`5`: notice * :value:`6`: informational * :value:`7`: debug Notes: * This property is deprecated and may stop working in a future release. Use :property:`logging.verbosity` instead. * This property is incompatible with :property:`logging.verbosity` (i.e., if they are used simultaneously, participant creation will fail). :type:`Integer`: :value:`[0-7]` Default: :value:`3` (error) * - :property:`logging.verbosity` - :required:`Optional` The logging verbosity level. This setting applies to all methods of security logging (the :ref:`p2_core/logging:Connext DDS Builtin Logging System` and :ref:`p2_core/logging:Distributed Over DDS`). All log messages at and below the verbosity level will be logged. This property can take any of the following values (case sensitive): * :value:`SILENT` (least verbose) * :value:`EMERGENCY` * :value:`ALERT` * :value:`CRITICAL` * :value:`ERROR` (default) * :value:`WARNING` * :value:`NOTICE` * :value:`INFORMATIONAL` * :value:`DEBUG` (most verbose) This property is incompatible with :property:`logging.log_level` (i.e. if they are used simultaneously, participant creation will fail). :type:`Enum`: :value:`SILENT`, :value:`EMERGENCY`, :value:`ALERT`, :value:`CRITICAL`, :value:`ERROR`, :value:`WARNING`, :value:`NOTICE`, :value:`INFORMATIONAL`, :value:`DEBUG` Default: :value:`ERROR` * - :property:`logging.mode_mask` - :required:`Optional` Controls which logging methods are used to process the log messages produced by the |LoggingPlugin|. You can specify one of these possible values: * :value:`BUILTIN` * :value:`SECURITY_TOPIC` Or any combination of the above, separating each element by :value:`|`. For example: :value:`BUILTIN | SECURITY_TOPIC` When :value:`BUILTIN` is enabled, the |LoggingPlugin| will use the :ref:`p2_core/logging:Connext DDS Builtin Logging System`. When :value:`SECURITY_TOPIC` is enabled, the |LoggingPlugin| will create a |PUB| and |DW| within the same |DP| that is setting this property. There is no option to use a separate |DP| or to share a |DW| among multiple |DPs|. (See :ref:`p2_core/logging:Subscribing to The Builtin Logging Topic`.) :type:`Mask`: :value:`BUILTIN` | :value:`SECURITY_TOPIC` Default: :value:`BUILTIN` .. list-table:: Additional |RTI_SP| Properties for Configuring Logging Distributed Over DDS [#]_ :name: Additional RTI Security Plugins Properties for Configuring Logging Distributed Over DDS :widths: 40 60 :header-rows: 1 :class: longtable * - Property Name (prefix with :property:`com.rti.serv.secure.`) [#fPrefix]_ - Property Value Description * - :property:`logging.security_topic.profile` - :required:`Optional` QoS Library and QoS Profile used to create logging-related entities (|PUB|, |TOPIC| and |DW|). Must be a string of the format :value:`"QosLibraryName::QosProfileName"`. If the profile does not specify the :property:`fast_pool.pool_buffer_max_size` in the :property:`dds.data_writer.history.memory_manager` property, its value will be set to :value:`512`. :type:`String`. Default: :value:`"BuiltinQosLib::Generic.KeepLastReliable.TransientLocal"`, with history.depth = 64 and publish_mode.kind = DDS_ASYNCHRONOUS_PUBLISH_MODE_QOS * - :property:`logging.security_topic.queue.size` - :required:`Optional` Size of the logging thread queue, in bytes. :type:`Integer`. Default: :value:`50688` * - :property:`logging.security_topic.queue.message_count_max` - :required:`Optional` Maximum number of log messages in the logging queue. :type:`Integer`. Default: :value:`64` * - :property:`logging.security_topic.queue.message_size_max` - :required:`Optional` Maximum serialized size of a log message in the logging queue. :type:`Integer`. Default: :value:`792` * - :property:`logging.security_topic.thread.message_threshold` - :required:`Optional` Number of bytes to preallocate for the logging message string in the logging thread, beyond which dynamic allocation will occur. :type:`Integer`. Default: :value:`256` * - :property:`logging.security_topic.thread.plugin_method_threshold` - :required:`Optional` Number of bytes to preallocate for the plugin method string in the logging thread, beyond which dynamic allocation will occur. :type:`Integer`. Default: :value:`256` * - :property:`logging.security_topic.thread.plugin_class_threshold` - :required:`Optional` Number of bytes to preallocate for the plugin class string in the logging thread, beyond which dynamic allocation will occur. :type:`Integer`. Default: :value:`256` * - :property:`access_control.use_530_logging_protection` - :required:`Optional` How to set the value of :xmltag:`metadata_protection_kind` for the :ref:`p2_core/logging:Builtin Secure Logging Topic`. If :value:`TRUE`: the value will be :xmlval:`NONE`, which is consistent with |CONNEXT| 5.3.0 behavior. If :value:`FALSE`: the value will be :xmlval:`SIGN`, which is consistent with the behavior of the DDS Security specification. :type:`Boolean`. Default: :value:`FALSE` .. [#fPrefix] Assuming you used :value:`com.rti.serv.secure` as the alias to load the plugin. If not, change the prefix to match the string used with :property:`com.rti.serv.load_plugins`, followed by the :value:`.` character. .. [#] Before version 6.1.0 of |CONNEXT|, properties for configuring security logging distributed over DDS had a name starting with :property:`logging.distribute`. Starting with |CONNEXT| 6.1.0, these properties start with :property:`logging.security_topic`. Properties using the former names are deprecated but still usable. If you set a property using both the :property:`logging.distribute` and the :property:`logging.security_topic` forms, the latter will take effect and the former will be ignored. Logging Messages ================ :numref:`Log Messages` lists security-related events and the log messages they generate. .. list-table:: Log Messages :name: Log Messages :widths: 33 20 47 :header-rows: 1 :class: longtable * - Event - Log Level - Message * - Failed to allocate memory - :value:`EMERGENCY` - .. code-block:: text :class: break-lines-anywhere insufficient memory * - allow_unauthenticated_participants = FALSE, and discovered remote participant that is unauthenticable, i.e. has not enabled security - :value:`WARNING` - .. code-block:: text :class: break-lines-anywhere unauthenticated remote participant [participant ID] denied * - allow_unauthenticated_participants = TRUE, and discovered remote participant that is either unauthenticable or fails authentication - :value:`WARNING` - .. code-block:: text :class: break-lines-anywhere allowing unauthenticated participant [participant ID] * - Received invalid X509 certificate, from either remote or local participant - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere failed to decode certificate * - Couldn't verify certificate's signature against neither the certificate of the Identity Certificate Authority nor any alternative CAs - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere failed to verify certificate * - Certificate appears in Certificate Revocation List - :value:`ERROR` [#always_NDDS_Config_Logger]_ - .. code-block:: text :class: break-lines-anywhere certificate revoked * - Upon receiving HandshakeReplyMessageToken or HandshakeFinalMessageToken, couldn't verify challenge's signature against peer's certificate. Peer likely has mismatched private and public keys, so it’s an imposter. - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere failed to verify challenge signature * - Another participant has lost liveliness with this one before authentication was completed and is trying to re-authenticate itself (see :ref:`p2_core/authentication:Re-Authentication`). A new authentication should restore communication once the ongoing authentication times out. Or: Network traffic corruption during authentication. Or: Misbehaving remote participant during authentication. - :value:`NOTICE` - .. code-block:: text :class: break-lines-anywhere RTI_Security_Authentication_process_handshake:received unexpected handshake message, probably from a participant that lost liveliness with this one before ongoing authentication completed. Once current authentication times out, communication should be restored. * - RTI_Security_Authentication_process_handshake failed (see previous row). - :value:`STATUS_REMOTE` [#always_NDDS_Config_Logger]_ - .. code-block:: text :class: break-lines-anywhere DDS_DomainParticipantTrustPlugins_forwardProcessHandshake:!security function process_handshake returned VALIDATION_FAILED * - Couldn't verify permissions or governance file signature against either the certificate of the Permissions Authority or any alternative permissions authorities - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere Document signature verification failed. Make sure document was signed by the right permissions authority. * - Received signed permissions document that is not an XML document - :value:`ALERT` - .. code-block:: text :class: break-lines-anywhere received invalid signed permissions document * - Received signed governance document that is not an XML document - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere received invalid signed governance document * - Couldn't parse the permissions file for some reason, such as duplicate grants for the same subject name or no grant for the intended subject name - :value:`ALERT` - .. code-block:: text :class: break-lines-anywhere failed to parse permissions file * - Couldn't parse the governance file for some reason - :value:`ALERT` - .. code-block:: text :class: break-lines-anywhere failed to parse governance file * - Denied participant because there is a deny rule explicitly prohibiting the participant - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere participant not allowed: deny rule found * - Denied participant because there is no rule for the participant's domain ID, and the default is to deny - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere participant not allowed: no rule found for the participant's domainId; default DENY * - Denied writer or reader because there is a deny rule explicitly prohibiting the writer or reader - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere endpoint not allowed: deny rule found * - Denied writer or reader because there is no rule for the writer or reader, and the default is to deny - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere endpoint not allowed: no rule found; default DENY * - Parsed publish/subscribe rule in permissions file that does not apply to the writer/reader because no topic expressions match the writer/reader's topic - :value:`DEBUG` - .. code-block:: text :class: break-lines-anywhere This publish/subscribe rule doesn't apply because none of the rule's topic expressions match the endpoint's topic name of [topic name] * - Parsed publish/subscribe rule in permissions file that does not apply to the writer/reader because even though there's a matching topic expression, there are no matching partition expressions - :value:`DEBUG` - .. code-block:: text :class: break-lines-anywhere This publish/subscribe rule doesn't apply because none of the rule's partition expressions match with any of the endpoint's partitions * - Another participant, which is not using is_rtps_protected = true or is not using security at all, has sent this one an unprotected RTPS message that is not a participant announcement, handshake message, or key exchange message. This participant is using is_rtps_protected = true, so it drops the message. Or: Network traffic corruption after key exchange. Or: Misbehaving remote participant after key exchange. - :value:`STATUS_REMOTE` [#always_NDDS_Config_Logger]_ - .. code-block:: text :class: break-lines-anywhere MIGInterpreter_parse:received unencoded rtps message. Unacceptable due to is_rtps_protected = true * - Received authenticated content that has been tampered with, i.e. EVP_DecryptFinal_ex failed because the GCM or GMAC tag verification failed - :value:`ALERT` - .. code-block:: text :class: break-lines-anywhere DecryptFinal failed. Possible GCM authentication failure. * - Received submessage encrypted with a key whose MasterKeyId hasn't yet been exchanged via CryptoToken - :value:`DEBUG` - .. code-block:: text :class: break-lines-anywhere received submessage from an endpoint that discovered me but that I haven't discovered yet; dropping submessage hoping it will be repaired. It will not be repaired if the endpoint did not properly share its MasterKeyId in its CryptoToken * - Writing a log message over the LogTopic fails due to insufficient logging queue size - :value:`STATUS_LOCAL` [#always_NDDS_Config_Logger]_ - .. code-block:: text :class: break-lines-anywhere Failed to write log message of size = [message size] because the logging queue is full. Try to increase logging.security_topic.queue.message_count_max, which is currently [message_count_max]. * - Parsed publish/subscribe in permissions file that does not apply to the writer/reader because even though there's a matching topicexpression, the partition expressions in the QoS are not a subset of the ones in the - :value:`DEBUG` - .. code-block:: text :class: break-lines-anywhere This publish/subscribe rule doesn't apply because endpoint's partitions are not a subset of the rule's partition expressions .. [#always_NDDS_Config_Logger] This log message is logged using |CONNEXT|'s own builtin logging system, regardless of the logging method used.