DDS Interoperability Wire Protocol Avatar
  1. OMG Specification

DDS Interoperability Wire Protocol — Open Issues

  • Acronym: DDSI-RTPS
  • Issues Count: 4
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Provide a pre-shared key protection mechanism

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    There is an inherent DoS network amplification attack that exploits peer-to-peer discovery. See https://issues.omg.org/browse/DDSIRTP26-6

    This issue should be addressed by DDS-Security. Likely using some pre-shared key mechanics to protect all messages not otherwise protected. For example, the authentication handshakes.

  • Reported: DDSI-RTPS 2.5 — Fri, 12 Nov 2021 16:24 GMT
  • Updated: Fri, 12 Nov 2021 16:24 GMT

Network amplification

  • Status: open  
  • Source: Trend Micro Inc. ( Federico Maggi)
  • Summary:

    Details available to RTF members

  • Reported: DDSI-RTPS 2.5 — Fri, 24 Sep 2021 13:16 GMT
  • Updated: Thu, 21 Oct 2021 08:15 GMT

Section 9.4.2.9 Timestamps shows 'seconds' as 'long' instead of 'unsigned long'

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    RTPS version 2.3 updated modified Time_t to have the 'seconds' be of type unsigned long so that there would be no rollover in 2038.

    This matches when it is shown in the IDL definition in 9.3.2.1 'IDL Definitions'

    However Section 9.4.2.9 Timestamps illustrates the 'Timestamp' sub-message element with a 'long' instead of 'unsigned long' for the seconds part. It should be changed to illustrate 'unsigned long' as in:

    Timestamp:

    0...2...........8...............16.............24. .............32 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                 unsigned long    seconds                      | 
    +---------------+---------------+---------------+---------------+ 
    |                 unsigned long    fraction                     | 
    +---------------+---------------+---------------+---------------+
    
  • Reported: DDSI-RTPS 2.5 — Thu, 10 Jun 2021 23:32 GMT
  • Updated: Thu, 10 Jun 2021 23:32 GMT

Inconsiastent notation used to represent bit positions pictorially

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The spec uses two numbering schemes for bits:

    For example 9.4.1 (Overall Structure)

    0...2...........7...............15.............23. .............31
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

    But then in 9.4.4 (Mapping of the RTPS Header)

    0...2...........8...............16.............24.............. 32
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

    It should be consistent. The more correct scheme appears to be:

    0...2...........8...............16.............24. .............32 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    

    With this scheme the number represents the number of bits that appear before the number (the "." positions). The other scheme seems inconsistent. "0" is placed ahead of the bit of that order, but '7' and the rest are placed after.

  • Reported: DDSI-RTPS 2.5 — Thu, 10 Jun 2021 22:20 GMT
  • Updated: Thu, 10 Jun 2021 22:20 GMT