OpenDDS and OMG DDS Security 1.1.? specification?

[DavidLoiselle]

Hi All, I am a developer working with Cyclone DDS and its code base. We will need security sooner then later. I was wondering when the security section of Cyclone DDS will be ready to use. Is there any documentation for its usage in Cyclone DDS and examples? In addition what level of security will be implemented, we are currently referencing the OMG DDS Security 1.1 specification as a starting place, Any documentation at the moment.
Any Cyclone DDS security assistance would be helpful...

David L.

[eboasson]

Hi David,

Thanks for asking, even if the question is one of the harder ones in the case of Cyclone. I've answered some related questions on #102, but that's hardly a reason for not answering your question directly.

The goal is definitely to do OMG DDS Security, the problem is how and when to get there. What I have been told is that ADLINK intends to donate the implementation from OpenSplice to Cyclone. I think Cyclone will remain close enough to OpenSplice for long enough in the parts that matter for that integration, so that it should be relatively easy to combine (at least for me). However, while I have no doubt that it will happen at some point, there is no hard promise for when that will happen. (I work for ADLINK, but that doesn't mean I get to make that decision or have much influence on it.)

Implementing DDS Security is a fair bit of work, and given that there are many ways in which I plan to improve Cyclone that cannot be had by (effectively) copying it from elsewhere — e.g., transient data, performance and footprint improvements, embedded systems support, zero-copy publish/subscribe, removal of strange limitations, handling multiple domains simultaneously, multiple network interfaces, OMG XTypes support, proper asynchronous publishers with latency budget and traffic shaping, just to name a few … — it seems to make the most sense to put the effort in things other than DDS Security at the moment.

That equation changes completely if someone were to step up and start implementing it, of course. The sooner it's there, the better, but it can only be done sooner with help.

In the mean-time, there's the protection against "casual eavesdroppers" that could be enabled with minimal effort (that's q_security.c that got included for reasons unknown to me, but it's there and therefore fair game wherever it is useful) and that can relatively easily be extended to do authentication. However, it is fundamentally based on a shared secret and commits just about every sin in the book in how it does things ... So it is about as useful as bringing nothing but a couple of t-shirts to Antarctica because being so far south the weather is bound to be pleasant there, if you know what I mean.

Then there is some TCP+TLS support, but that's obviously missing out on the strengths of DDS because of the use of TCP. Across a WAN it can make sense, but in a LAN, usually not so much.

My general attitude at the moment is that the best approach for now is to run over a VPN. It is far from ideal, but at least you get some real protection without immediately losing all the benefits of DDS.

[vfalico]

Hi eboasson,

While researching the security aspect, this caught my eye:

handling multiple domains simultaneously

I'm testing currently multi-domain approach and it seems to "just work" in the latest upstream (multiple dds_create_participant(D_NR..) via fork()). Do you know any kind of limitations?

Thanks!

[eboasson]

Hi @vfalico,

Via fork it should work just fine, the current limitation is on having two 2 domain participants attached to different domains in a single process at the same time. E.g., doing:

dds_create_participant(1, NULL, NULL);
dds_create_participant(2, NULL, NULL);

will not get you two participants, but (at most, strictly speaking) just one, and an error for the other(s).

The problem is simply that there are some global variables (like config and gv) that store all kinds of domain-specific things. Once those are initialised for domain X, the process is stuck with using domain X until all participants are deleted. The first one you create after that can freely choose the domain again.

Those global variables are an inheritance from OpenSplice's shared-memory architecture where a networking service process only ever needs to deal with a single domain. For Cyclone DDS, they need to be reorganised into a top-level domain type that all entities point to and that gets passed around through the DDSI stack. It is just a bit of boring work ...

[PradeepKiruvale]

Then there is some TCP+TLS support, but that's obviously missing out on the strengths of DDS because of the use of TCP.

I did not understand these statements, What kind of strengths we are missing here.

Across a WAN it can make sense, but in a LAN, usually not so much.

What do you mean by its not so helpful on LAN?

My general attitude at the moment is that the best approach for now is to run over a VPN. It is far from ideal, but at least you get some real protection without immediately losing all the benefits of DDS.

Why not without VPN?

[eboasson]

Hi @pradeepkj ,

I should get on my soapbox and write a long response but I'll try to give you a short response instead. Otherwise I'll spend too much time writing it 😁.

Then there is some TCP+TLS support, but that's obviously missing out on the strengths of DDS because of the use of TCP.

I did not understand these statements, What kind of strengths we are missing here.

Using TCP instead of UDP means no longer having multicast capability, and also means head-of-line blocking on individual connections. That means the zero-config discovery is gone, and that the scalability and real-time characteristics are no longer as good. Those are pretty major strengths of DDS.

Some of that can be recovered by adding a "discovery service". Cyclone DDS doesn't have one yet, but there are commercially available ones. For example, my employer's Vortex Link product will route discovery data and optionally application data, so that the configuration effort is limited to specifying where that Vortex Link can be found.

In such a configuration, DDS becomes quite comparable to the network architecture of ROS1 if only discovery data is handled; and if all data is routed, DDS behaviour moves toward that of MQTT. Of course there are still the QoS settings and the handling of historical data, but you do lose some of the nice properties — and incidentally, the properties you lose are the ones that made ROS2 start using DDS.

Across a WAN it can make sense, but in a LAN, usually not so much.

What do you mean by its not so helpful on LAN?

Over a WAN it is often useful to add routers and let all DDS traffic flow over a small number of TCP connections, as that typically matches best with the optimisations in the underlying infrastructure is. (A.k.a., the web is designed around TCP.) Most LANs (especially Ethernet) is pretty good with multicasting and give you highly reliable and pretty predictable delivery, so using UDP multicast is relatively speaking much more attractive.

My general attitude at the moment is that the best approach for now is to run over a VPN. It is far from ideal, but at least you get some real protection without immediately losing all the benefits of DDS.

Why not without VPN?

That was under the assumption that you need security and zero discovery. Using a VPN allows you to use DDS without having to worry about configuration issues and having a tried-and-tested, industry standard security mechanism. (But of course you still need to configure and maintain the VPN.)

Does that help clear things up?

[PradeepKiruvale]

@eboasson Thanks for the detailed explanation. I am clear about my questions now.