-
Notifications
You must be signed in to change notification settings - Fork 357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenDDS and OMG DDS Security 1.1.? specification? #116
Comments
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 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. |
Hi eboasson, While researching the security aspect, this caught my eye:
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! |
Hi @vfalico, Via 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 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 |
I did not understand these statements, What kind of strengths we are missing here.
What do you mean by its not so helpful on LAN?
Why not without VPN? |
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 😁.
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.
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.
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? |
@eboasson Thanks for the detailed explanation. I am clear about my questions now. |
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.
The text was updated successfully, but these errors were encountered: