15:06:26 #startmeeting IPv6 Project Meeting #12 15:06:26 Meeting started Fri Apr 10 15:06:26 2015 UTC. The chair is bryan_att. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:06:26 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:06:26 The meeting name has been set to 'ipv6_project_meeting__12' 15:06:40 #topic Gap analysis by Jonne 15:08:03 #info IETF has done some work on router advertising 15:08:54 #info RFC 6583 is implementation guidelines rather than features 15:09:16 #info There are a few IPv6 related blueprints in the OpenStack pipeline 15:10:17 #info topics Jonne is addressing are in the email 15:10:21 #link http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2015-April/002136.html 15:11:17 #info All these blueprints are new and all from the same contributor 15:12:13 question: are these security fixes and bugs related ONLY to IPv6? 15:12:22 #info Whether there is a gap is unclear - the blueprints e.g. reference neighbory discovery protection and snooping but it's unclear what is intended 15:12:22 or do they also effect IPv4? 15:13:36 #link https://blueprints.launchpad.net/neutron/+spec/security-group-ipv6-ra-guard 15:13:57 #info Bin: have these 2 BPs met the need? 15:16:38 #info Sridhar: these are the BPs referenced in the wiki 15:16:40 #link https://wiki.opnfv.org/ipv6_opnfv_project/topdown_usecase 15:17:26 #info ... have submitted a patch for a default rule preventing VMs from accessing IPv6 RA, e.g. to avoid a fake router attack 15:18:24 #info ... the 2nd is a more low-level security rule patch which did not make it to Kilo 15:18:44 #info ... one more is in Kilo but not enabled for IPv6 15:19:09 #info Jonne: the RA guard issue may be addressed for now, so the 1st line of the BP is addressed 15:19:50 #info ... the fix has 2 parts; ML2 plugin patch, and a tab/switch in openstack which controls the feature 15:20:40 #info Sridhar: we will need to configure ports to disable the security in Horizon; if you want to run a real router the default security will have to be disabled 15:22:57 #info Jonne: re enabler discovery inspection, when discovery is initiated from the right nodes they have identifying information; in OVS a trigger could ensure that discovery messages are properly formatted, e.g. have identifying info which is correct for the source of the message 15:23:18 #info ... this is similar to ARP spoofing protection 15:24:20 #info Sridhar: if we can protect the ports for discovery, this helps avoid duplicate addresses also 15:24:52 #info ... ARP is different as a protocol but they are similar enough that a common fix will work for both 15:25:42 #info Srishar: in Neutron to do this we could use security groups, or IP tables (?) 15:27:38 #info ... the other is to use OpenVSwitch to filter invalid requests; a patch to implement protection is in the works but only addresses IPv4 yet 15:28:07 #info ... we need this to work beyond OpenVSwitch though; security group approach will work everywhere 15:28:49 #info Jonne: this can't just be a static filter; to really do this "inspection" you must do it in OpenVSwitch as the security rules are static 15:30:02 #info Sridhar: the rules do need to be dynamic in nature; neutron automatically adds group rules using IP tables; we can extend this feature to solve this goal also 15:30:57 #info Jonne: this is the same logic and works well for IPv4. But in IPv6 multiple addresses/prefixes can be assigned, or privacy addresses (random 64-bits in some fields) 15:31:44 #info ... this is widely implemented; static rules might restrict IPv6 support given this dynamic nature of IPv6 addresses 15:32:10 #info Sridhar: we don't support privacy extensions in Neutron yey 15:32:31 #info Jonne: does Neutron support 2 different addresses on the same port? 15:33:03 #info Sridhar: there is a related feature but need to look closer; it implements support for router ports 15:33:40 #info ... the BP is approved for Kilo; multiple addresses per port is merged recently' 15:34:39 #info ... a port is associated only with a single subnet which has a prefix; multiple interfaces with own prefix are required 15:35:08 #info Jonne: these are virtual interfaces so you can arrange it, but that is not addressing what IPv6 intends 15:36:17 #info ... address allocation by routers will include various type of prefixes; the risk is w/o multiple prefixes per link, there is a disincentive for NAT; that is not intended by IPv6 15:37:07 #info Sridhar: for address prefixes that are not exposed to the WAN; is that common or would two different routers serve the different address types? 15:37:24 #info Jonne: it should not be uncommon that the same router serves multiple addresses 15:38:19 #info ... in a large net with multiple layers, the last router serves one address up and multiple down; internal addresses are filtered at the border 15:38:55 #info ... starting w/o internet connectivity, local addresses are used for internal communication and then mapped to a global address 15:39:16 #info ... you can also assign local addresses that are not exposed outside for security 15:39:39 #info ... servers might have local addresses, and clients both local and global addresses 15:40:24 #info Sridhar: similar to local subnets e.g. 192, what is the role of ULA for that? 15:41:11 #info Jonne: the idea is not that the end-host gets local addresses and communicates thru a NAT; the goal is a computationally unique address used for internal use, and a global address for external communication 15:41:45 #info ... selection rules helps the client use the correct address type for the communication based upon the address of the target 15:42:12 #info ... source address selection rules in the host determine which address will be used, from the multiple that the host has 15:42:32 #info ... an RFC defines these rules (link anyone?) 15:43:12 #info Sridhar: makes sense, so the client can choose; afaik we don't support that so far in Neutron 15:44:13 #info Bin: so for IPv6 security groups, it depends upon the port security extension targeted for Liberty; beyond Liberty, are there any other gaps we should address e.g. via a new BP? 15:44:47 #info Jonne: that should be enough for 1st hop security 15:45:09 #info Sridhar: agree; once this new patch is merged, we can extend it to new needs 15:46:00 #info Bin: we will need those patches for the PoC Mark is working on so a VM can be a router 15:46:43 #info Sridhar: a patch disabling anti-spoofing rules was put into Juno; but for Kilo we can use the patch that was just merged 15:46:56 #info Bin: Mark, have you had the chance to verify the patch? 15:47:18 #info Mark: not yet, time is needed to test; will do so asap 15:48:23 #info Bin: when Mark has verified that, Sridhar can update the patch for the security rules that we want for the Kilo release 15:48:49 #info Sridhar: recommends we use the port security rules patch that is already in Kilo 15:49:37 #info ... I can make the feature a configurable parameter in horizon; the patch just disables the rules; but we need to make sure we note that the patch should not be approved upstream, is just for testing 15:49:52 #info Bin: so this can be an OPNFV-specific extension for Juno 15:50:21 #info ... for Kilo we can use the port security exension 15:50:41 #info ... maybe in 2 weeks we can have testing of this for the PoC 15:51:24 #info ... in addition to verifying the patch, updating the diagram for the PoC to reflect what we need to do without the patch 15:51:45 #info ... Iben, any update on lab IPv6 connection? 15:52:16 #info Iben: working on the documentation project for R1 - no time this week 15:52:56 #topic Jira use 15:53:18 #info Bin: projects are using Jira; I will put action items into Jira 15:54:01 #info ... we should also put documentation into git/gerrit as a starting point, as soon as time is available for that 15:54:27 #info ... proposals are being discussed on the list; we should try to migrate to that when possible 15:54:43 #topic Call Frequency 15:54:54 #info Bin: should we maintain weekly calls? 15:55:20 #info Iben: discussion is leaning toward every 2 weeks 15:55:39 #info (general agreement) 15:56:08 #info Bin: starting from next week we can convert to a meeting every two weeks 15:56:36 #info ... the audio meetings do help clarify a lot in a short time; so we will continue them 15:56:52 #info ... we can add additional meetings as needed 15:57:02 #endmeeting