DDSSEC11 — Unclear Effectiveness of is_rtps_protected=true allow_unauthenticated_participants=true

Current specification allows for creating a participant with is_rtps_protected=true and allow_unauthenticated_participants=true.

According to "Table 21 – Description of the ParticipantSecurityAttributes - is_rtps_protected":

If is_rtps_protected is TRUE then:
(1) The DDS middleware shall call the operations on the CryptoKeyFactory for the DomainParticipant.
(2) The DDS middleware shall call the operations on the CryptoKeyExchange for matched DomainParticipants that have been authenticated.
(3) The RTPS messages sent by the DomainParticipant to matched DomainParticipants that have been authenticated shall be transformed using the CryptoTransform operation encode_rtps_message and the messages received from the matched authenticated DomainParticipants shall be transformed using the CryptoTransform operation decode_rtps_message.

In particular, I want to focus on (3). According to current specification, we should accept a not-signed RTPS message coming from an unauthenticated participant, independently of the "is_rtps_protected" value. I think this impacts the effectiveness of just using "is_rtps_protected". This is because it allows for an attacker to inject any RTPS message by properly tampering the GUID if that GUID has not been authenticated yet (at the very minimum, it enables for a time window that allows for injecting anything, until that GUID is actually authenticated).

I want to bring this up so we can discuss if this is actually the behavior we want (if this is the case, we should document the scenario I described above somewhere), or if is_rtps_protected=true should be incompatible with allowing unauthenticated participants. If that is the case, the alternative secure configuration would be to protect submessages themselves (by signing them).

Duplicates DDSSEC11-14 and its resolution (DDSSEC11-126)

Duplicates DDSSEC11-14 (and its already handled by its resolution DDSSEC11-126)