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