#opendaylight-meeting: TWS 2014-06-16

Meeting summary

1. OpenDaylight Security Analysis (phrobb, 17:05:29)
   1. https://wiki.opendaylight.org/view/CrossProject:OpenDaylight_Security_Analysis going over this wiki page (colindixon, 17:05:54)
   2. was presented at the TSC on 5/29, then suggested as a TWS topic (colindixon, 17:06:11)
   3. goal of this document is to record the the current state security-related things in OpenDaylight and then recommendations as to ways to improve/change things (colindixon, 17:11:22)
   4. went over several considerations w.r.t. OSGi: chiefly (i) how to do bundle isolation/permissions and (ii) locking down remote access to the OSGi runtime with a focus on Karaf (colindixon, 17:13:03)
   5. review of controller plugins and their security, e.g., HTTP vs. HTTPS, TCP vs. TLS, etc. (colindixon, 17:15:44)
   6. colindixon asks are there good high-level statements we could make rather than (or in addition to) specific per-plugin transports (colindixon, 17:18:01)
   7. one suggestion is that we recommend: (i) encrypt all communication that leaves the controller and (ii) do bidirectional authentication, i.e., controller authenticates itself and the other end authenticates itself to the controller (colindixon, 17:19:22)
   8. edwarnicke also points out that the table of where we lie in terms of that is a good idea to track where we are with respect to each plugin (colindixon agrees strongly) (colindixon, 17:20:01)
   9. https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:_TLS_Support some information about adding TLS support OpenFlow Plugin (colindixon, 17:22:08)
   10. networkstatic suggests (and colindixon and alagalah +1) that we should provide sample implementations of the “right” security stuff for commonly used stuff, e.g., JAX-RS and Netty (colindixon, 17:23:13)
   11. edwarnicke suggests that we try to get that implemented once so that others can reuse the same code rather than copy/pasting the samples (colindixon, 17:23:40)
   12. edwarnicke asks if there’s been any discussion of the tension between the ease of having default login/passwords for developers vs. how to make sure we don’t accidentally make it easy for real people to use it and leave default passwords as a security vulnerability (colindixon, 17:26:20)
   13. the answer is that it’s on their minds, but there’s no decision yet (colindixon, 17:26:36)
   14. edwarnicke suggests having a default password at launch, but require first login to reset it, that way if somebody discovers the default password doesn’t work, you know things are somehow bad (colindixon, 17:27:25)
   15. colindixon: zeroconf is hard (edwarnicke, 17:35:33)
   16. unidentifiedspeaker: But the IETF has a draft that may tell you how ;) (edwarnicke, 17:35:50)
   17. talking about secure bootstrap of the infrastructure: that is finding the devices and getting them attached to the controller (possibly through multiple hops) in a secure way (colindixon, 17:36:14)
   18. david lenrow asks if this is about infrastructure devices or other endpoints as welll (colindixon, 17:36:47)
   19. answer is that it’s about infrastructure for now and that will be made more clear (colindixon, 17:36:58)
   20. there is a discussion about how easy things are to classify as infrastructure and not infrastructure with respect to things like vSwitches and NFV; these difficulties are acknowledged, but the idea seems to be you first boot/discover the physical infrastructure and then you can boot/discover the virtual infrastructure (colindixon, 17:38:34)
   21. controller clustering: discussion of securing Infinispan/JGroups (colindixon, 17:41:21)
   22. colindixon points out that we will likely be using Akka in addition to this and we need to look into this (Jan Medved says we aren’t going to be using zeroMQ) (colindixon, 17:42:01)
   23. colindixon we should specify high-level intent of what we should be doing for all of these points, so that as the underlying technology changes we can do the right things (colindixon, 17:45:57)
   24. colindixon asks if we have a way to enumerate the ports we think OpenDaylight has open and what we think is listening on them and how we think it’s secured (colindixon, 17:46:55)
   25. NMap scans against port 6633, 1830 and 6640 (+1 more to be documented) cause exceptions/bad behavior, see bugs 1174-6 (dfarrell07, 17:47:36)
   26. one way to build the list of ports would be using a combination of things like NMap and netstat, it would be great if we could automate building that list and then we could tell when/if it changes (colindixon, 17:49:00)
   27. somebody (I forget who) suggested that we make sure to do fuzz testing (colindixon, 17:51:34)
   28. somebody (I forget who) also suggested that we figure out if we want to recommend different security approaches for service providers vs. data centers, etc. (colindixon, 17:52:29)
   29. the overall recommendations at the end of this document seem to mostly involve high-end (non-free) software to test things and provide vulnerability analysis (colindixon, 17:57:32)
   30. colindixon says some of this seems antithetical to open source software development and asks if there are different ways other open source projects do things (colindixon, 17:58:25)
   31. we have coverity account for ODL (cdub, 17:58:28)
   32. we need a general security vulnerability process (cdub, 17:59:53)
   33. we have security@lists.opendaylight.org as a starting point (cdub, 18:00:04)
   34. we need an actual owner (cdub, 18:00:11)

Action items

1. (none)

People present (lines said)

1. colindixon (34)
2. edwarnicke (8)
3. cdub (8)
4. networkstatic (6)
5. phrobb (4)
6. dfarrell07 (4)
7. alagalah (4)
8. odl_meetbot (3)