15:06:26 <bryan_att> #startmeeting IPv6 Project Meeting #12
15:06:26 <collabot> 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 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:06:26 <collabot> The meeting name has been set to 'ipv6_project_meeting__12'
15:06:40 <bryan_att> #topic Gap analysis by Jonne
15:08:03 <bryan_att> #info IETF has done some work on router advertising
15:08:54 <bryan_att> #info RFC 6583 is implementation guidelines rather than features
15:09:16 <bryan_att> #info There are a few IPv6 related blueprints in the OpenStack pipeline
15:10:17 <bryan_att> #info topics Jonne is addressing are in the email
15:10:21 <bryan_att> #link http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2015-April/002136.html
15:11:17 <bryan_att> #info All these blueprints are new and all from the same contributor
15:12:13 <iben_> question: are these security fixes and bugs related ONLY to IPv6?
15:12:22 <bryan_att> #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 <iben_> or do they also effect IPv4?
15:13:36 <bryan_att> #link https://blueprints.launchpad.net/neutron/+spec/security-group-ipv6-ra-guard
15:13:57 <bryan_att> #info Bin: have these 2 BPs met the need?
15:16:38 <bryan_att> #info Sridhar: these are the BPs referenced in the wiki
15:16:40 <bryan_att> #link https://wiki.opnfv.org/ipv6_opnfv_project/topdown_usecase
15:17:26 <bryan_att> #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 <bryan_att> #info ... the 2nd is a more low-level security rule patch which did not make it to Kilo
15:18:44 <bryan_att> #info ... one more is in Kilo but not enabled for IPv6
15:19:09 <bryan_att> #info Jonne: the RA guard issue may be addressed for now, so the 1st line of the BP is addressed
15:19:50 <bryan_att> #info ... the fix has 2 parts; ML2 plugin patch, and a tab/switch in openstack which controls the feature
15:20:40 <bryan_att> #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 <bryan_att> #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 <bryan_att> #info ... this is similar to ARP spoofing protection
15:24:20 <bryan_att> #info Sridhar: if we can protect the ports for discovery, this helps avoid duplicate addresses also
15:24:52 <bryan_att> #info ... ARP is different as a protocol but they are similar enough that a common fix will work for both
15:25:42 <bryan_att> #info Srishar: in Neutron to do this we could use security groups, or IP tables (?)
15:27:38 <bryan_att> #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 <bryan_att> #info ... we need this to work beyond OpenVSwitch though; security group approach will work everywhere
15:28:49 <bryan_att> #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 <bryan_att> #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 <bryan_att> #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 <bryan_att> #info ... this is widely implemented; static rules might restrict IPv6 support given this dynamic nature of IPv6 addresses
15:32:10 <bryan_att> #info Sridhar: we don't support privacy extensions in Neutron yey
15:32:31 <bryan_att> #info Jonne: does Neutron support 2 different addresses on the same port?
15:33:03 <bryan_att> #info Sridhar: there is a related feature but need to look closer; it implements support for router ports
15:33:40 <bryan_att> #info ... the BP is approved for Kilo; multiple addresses per port is merged recently'
15:34:39 <bryan_att> #info ... a port is associated only with a single subnet which has a prefix; multiple interfaces with own prefix are required
15:35:08 <bryan_att> #info Jonne: these are virtual interfaces so you can arrange it, but that is not addressing what IPv6 intends
15:36:17 <bryan_att> #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 <bryan_att> #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 <bryan_att> #info Jonne: it should not be uncommon that the same router serves multiple addresses
15:38:19 <bryan_att> #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 <bryan_att> #info ... starting w/o internet connectivity, local addresses are used for internal communication and then mapped to a global address
15:39:16 <bryan_att> #info ... you can also assign local addresses that are not exposed outside for security
15:39:39 <bryan_att> #info ... servers might have local addresses, and clients both local and global addresses
15:40:24 <bryan_att> #info Sridhar: similar to local subnets e.g. 192, what is the role of ULA for that?
15:41:11 <bryan_att> #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 <bryan_att> #info ... selection rules helps the client use the correct address type for the communication based upon the address of the target
15:42:12 <bryan_att> #info ... source address selection rules in the host determine which address will be used, from the multiple that the host has
15:42:32 <bryan_att> #info ... an RFC defines these rules (link anyone?)
15:43:12 <bryan_att> #info Sridhar: makes sense, so the client can choose; afaik we don't support that so far in Neutron
15:44:13 <bryan_att> #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 <bryan_att> #info Jonne: that should be enough for 1st hop security
15:45:09 <bryan_att> #info Sridhar: agree; once this new patch is merged, we can extend it to new needs
15:46:00 <bryan_att> #info Bin: we will need those patches for the PoC Mark is working on so a VM can be a router
15:46:43 <bryan_att> #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 <bryan_att> #info Bin: Mark, have you had the chance to verify the patch?
15:47:18 <bryan_att> #info Mark: not yet, time is needed to test; will do so asap
15:48:23 <bryan_att> #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 <bryan_att> #info Sridhar: recommends we use the port security rules patch that is already in Kilo
15:49:37 <bryan_att> #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 <bryan_att> #info Bin: so this can be an OPNFV-specific extension for Juno
15:50:21 <bryan_att> #info ... for Kilo we can use the port security exension
15:50:41 <bryan_att> #info ... maybe in 2 weeks we can have testing of this for the PoC
15:51:24 <bryan_att> #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 <bryan_att> #info ... Iben, any update on lab IPv6 connection?
15:52:16 <bryan_att> #info Iben: working on the documentation project for R1 - no time this week
15:52:56 <bryan_att> #topic Jira use
15:53:18 <bryan_att> #info Bin: projects are using Jira; I will put action items into Jira
15:54:01 <bryan_att> #info ... we should also put documentation into git/gerrit as a starting point, as soon as time is available for that
15:54:27 <bryan_att> #info ... proposals are being discussed on the list; we should try to migrate to that when possible
15:54:43 <bryan_att> #topic Call Frequency
15:54:54 <bryan_att> #info Bin: should we maintain weekly calls?
15:55:20 <bryan_att> #info Iben: discussion is leaning toward every 2 weeks
15:55:39 <bryan_att> #info (general agreement)
15:56:08 <bryan_att> #info Bin: starting from next week we can convert to a meeting every two weeks
15:56:36 <bryan_att> #info ... the audio meetings do help clarify a lot in a short time; so we will continue them
15:56:52 <bryan_att> #info ... we can add additional meetings as needed
15:57:02 <bryan_att> #endmeeting