17:05:05 <phrobb> #startmeeting TWS 2014-06-16
17:05:05 <odl_meetbot> Meeting started Mon Jun 16 17:05:05 2014 UTC.  The chair is phrobb. Information about MeetBot at http://ci.openstack.org/meetbot.html.
17:05:05 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:05:05 <odl_meetbot> The meeting name has been set to 'tws_2014_06_16'
17:05:06 <colindixon> is the meeting running?
17:05:12 <phrobb> yes :-)
17:05:29 <phrobb> #topic OpenDaylight Security Analysis
17:05:54 <colindixon> #link https://wiki.opendaylight.org/view/CrossProject:OpenDaylight_Security_Analysis going over this wiki page
17:06:11 <colindixon> #info was presented at the TSC on 5/29, then suggested as a TWS topic
17:11:22 <colindixon> #info 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
17:13:03 <colindixon> #info 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
17:15:44 <colindixon> #info review of controller plugins and their security, e.g., HTTP vs. HTTPS, TCP vs. TLS, etc.
17:18:01 <colindixon> #info colindixon asks are there good high-level statements we could make rather than (or in addition to) specific per-plugin transports
17:19:22 <colindixon> #info 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
17:20:01 <colindixon> #info 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)
17:20:47 <alagalah> networkstatic: +1
17:21:18 <networkstatic> alagalah ur alive!
17:21:30 <alagalah> networkstatic: barely
17:22:08 <colindixon> #link https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:_TLS_Support some information about adding TLS support OpenFlow Plugin
17:22:19 <alagalah> networkstatic: I think the expression is 10lbs of shit shoved into a 5lb bag
17:22:56 <networkstatic> ha, i hear u
17:23:13 <colindixon> #info 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
17:23:40 <colindixon> #info edwarnicke suggests that we try to get that implemented once so that others can reuse the same code rather than copy/pasting the samples
17:23:51 <alagalah> I back networkstatic implicitly
17:26:20 <colindixon> #info 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
17:26:36 <colindixon> #info the answer is that it’s on their minds, but there’s no decision yet
17:27:25 <colindixon> #info 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
17:27:50 * edwarnicke horray for the AAA project! :)
17:28:09 <networkstatic> there was a log message added to OSGI somewhat recently saying, change passwd etc.
17:28:36 <edwarnicke> networkstatic: I've seen that too :)  Its goodness, but probably not enough goodness :)
17:28:53 <networkstatic> bah, plausible deniability
17:28:58 <networkstatic> we told you so
17:28:59 <networkstatic> :)
17:33:58 <edwarnicke> networkstatic: You have been warned! ;)
17:35:33 <edwarnicke> #info colindixon: zeroconf is hard
17:35:50 <edwarnicke> #info unidentifiedspeaker: But the IETF has a draft that may tell you how ;)
17:36:14 <colindixon> #info 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
17:36:47 <colindixon> #info david lenrow asks if this is about infrastructure devices or other endpoints as welll
17:36:58 <colindixon> #info answer is that it’s about infrastructure for now and that will be made more clear
17:38:34 <colindixon> #info 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
17:41:21 <colindixon> #info controller clustering: discussion of securing Infinispan/JGroups
17:42:01 <colindixon> #info 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)
17:45:57 <colindixon> #info 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
17:46:55 <colindixon> #info 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
17:47:36 <dfarrell07> #info NMap scans against port 6633, 1830 and 6640 (+1 more to be documented) cause exceptions/bad behavior, see bugs 1174-6
17:47:43 <colindixon> dfarrell07: thanks!
17:47:47 <dfarrell07> np :)
17:49:00 <colindixon> #info 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
17:51:34 <colindixon> #info somebody (I forget who) suggested that we make sure to do fuzz testing
17:52:29 <colindixon> #info 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.
17:55:41 <cdub> colindixon: yes! (thank you, was about to say this)
17:57:32 <colindixon> #info 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
17:58:25 <colindixon> #info 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
17:58:28 <cdub> #info we have coverity account for ODL
17:59:01 <colindixon> thanks cdub
17:59:53 <cdub> #info we need a general security vulnerability process
18:00:04 <cdub> #info we have security@lists.opendaylight.org as a starting point
18:00:06 <colindixon> cdub: didn’t we establish that?
18:00:08 <colindixon> ok
18:00:10 <colindixon> yeah
18:00:11 <cdub> #info we need an actual owner
18:00:42 <dfarrell07> It doesn't seem like the scurity group is still meeting, btw (per my recent refactoring of wiki/Meetings)
18:01:30 <cdub> edwarnicke: trhere is no contact other than security@lists.opendaylight.org
18:01:55 <dfarrell07> colindixon + whoever else that was: Thanks, I'll update wiki/Meetings to refect that
18:02:24 <edwarnicke> cdub: Thanks :)  I went looking for it on the lists.opendaylight.org and didn't see it... which I suspect is intentional
18:03:11 <cdub> edwarnicke: all very fuzzy in my memory as well
18:03:43 <edwarnicke> cdub: I remember it all seemed like a very good idea at the time... but all I remember are the warm fuzzies ;)
18:03:49 <cdub> heh
18:03:54 <edwarnicke> cdub: Not the idea itself :(
18:08:09 <phrobb> #stopmeeting
18:08:13 <colindixon> #endmeeting