#opnfv-meeting: IPv6 Project Meeting #12

Meeting started by bryan_att at 15:06:26 UTC (full logs).

Meeting summary

  1. Gap analysis by Jonne (bryan_att, 15:06:40)
    1. IETF has done some work on router advertising (bryan_att, 15:08:03)
    2. RFC 6583 is implementation guidelines rather than features (bryan_att, 15:08:54)
    3. There are a few IPv6 related blueprints in the OpenStack pipeline (bryan_att, 15:09:16)
    4. topics Jonne is addressing are in the email (bryan_att, 15:10:17)
    5. http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2015-April/002136.html (bryan_att, 15:10:21)
    6. All these blueprints are new and all from the same contributor (bryan_att, 15:11:17)
    7. 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)
    8. https://blueprints.launchpad.net/neutron/+spec/security-group-ipv6-ra-guard (bryan_att, 15:13:36)
    9. Bin: have these 2 BPs met the need? (bryan_att, 15:13:57)
    10. Sridhar: these are the BPs referenced in the wiki (bryan_att, 15:16:38)
    11. https://wiki.opnfv.org/ipv6_opnfv_project/topdown_usecase (bryan_att, 15:16:40)
    12. ... 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)
    13. ... the 2nd is a more low-level security rule patch which did not make it to Kilo (bryan_att, 15:18:24)
    14. ... one more is in Kilo but not enabled for IPv6 (bryan_att, 15:18:44)
    15. Jonne: the RA guard issue may be addressed for now, so the 1st line of the BP is addressed (bryan_att, 15:19:09)
    16. ... the fix has 2 parts; ML2 plugin patch, and a tab/switch in openstack which controls the feature (bryan_att, 15:19:50)
    17. 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)
    18. 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)
    19. ... this is similar to ARP spoofing protection (bryan_att, 15:23:18)
    20. Sridhar: if we can protect the ports for discovery, this helps avoid duplicate addresses also (bryan_att, 15:24:20)
    21. ... ARP is different as a protocol but they are similar enough that a common fix will work for both (bryan_att, 15:24:52)
    22. Srishar: in Neutron to do this we could use security groups, or IP tables (?) (bryan_att, 15:25:42)
    23. ... 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)
    24. ... we need this to work beyond OpenVSwitch though; security group approach will work everywhere (bryan_att, 15:28:07)
    25. 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)
    26. 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)
    27. 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)
    28. ... this is widely implemented; static rules might restrict IPv6 support given this dynamic nature of IPv6 addresses (bryan_att, 15:31:44)
    29. Sridhar: we don't support privacy extensions in Neutron yey (bryan_att, 15:32:10)
    30. Jonne: does Neutron support 2 different addresses on the same port? (bryan_att, 15:32:31)
    31. Sridhar: there is a related feature but need to look closer; it implements support for router ports (bryan_att, 15:33:03)
    32. ... the BP is approved for Kilo; multiple addresses per port is merged recently' (bryan_att, 15:33:40)
    33. ... 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)
    34. Jonne: these are virtual interfaces so you can arrange it, but that is not addressing what IPv6 intends (bryan_att, 15:35:08)
    35. ... 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)
    36. 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)
    37. Jonne: it should not be uncommon that the same router serves multiple addresses (bryan_att, 15:37:24)
    38. ... 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)
    39. ... starting w/o internet connectivity, local addresses are used for internal communication and then mapped to a global address (bryan_att, 15:38:55)
    40. ... you can also assign local addresses that are not exposed outside for security (bryan_att, 15:39:16)
    41. ... servers might have local addresses, and clients both local and global addresses (bryan_att, 15:39:39)
    42. Sridhar: similar to local subnets e.g. 192, what is the role of ULA for that? (bryan_att, 15:40:24)
    43. 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)
    44. ... 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)
    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)
    46. ... an RFC defines these rules (link anyone?) (bryan_att, 15:42:32)
    47. Sridhar: makes sense, so the client can choose; afaik we don't support that so far in Neutron (bryan_att, 15:43:12)
    48. 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)
    49. Jonne: that should be enough for 1st hop security (bryan_att, 15:44:47)
    50. Sridhar: agree; once this new patch is merged, we can extend it to new needs (bryan_att, 15:45:09)
    51. 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)
    52. 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)
    53. Bin: Mark, have you had the chance to verify the patch? (bryan_att, 15:46:56)
    54. Mark: not yet, time is needed to test; will do so asap (bryan_att, 15:47:18)
    55. 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)
    56. Sridhar: recommends we use the port security rules patch that is already in Kilo (bryan_att, 15:48:49)
    57. ... 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)
    58. Bin: so this can be an OPNFV-specific extension for Juno (bryan_att, 15:49:52)
    59. ... for Kilo we can use the port security exension (bryan_att, 15:50:21)
    60. ... maybe in 2 weeks we can have testing of this for the PoC (bryan_att, 15:50:41)
    61. ... 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)
    62. ... Iben, any update on lab IPv6 connection? (bryan_att, 15:51:45)
    63. Iben: working on the documentation project for R1 - no time this week (bryan_att, 15:52:16)

  2. Jira use (bryan_att, 15:52:56)
    1. Bin: projects are using Jira; I will put action items into Jira (bryan_att, 15:53:18)
    2. ... 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)
    3. ... proposals are being discussed on the list; we should try to migrate to that when possible (bryan_att, 15:54:27)

  3. Call Frequency (bryan_att, 15:54:43)
    1. Bin: should we maintain weekly calls? (bryan_att, 15:54:54)
    2. Iben: discussion is leaning toward every 2 weeks (bryan_att, 15:55:20)
    3. (general agreement) (bryan_att, 15:55:39)
    4. Bin: starting from next week we can convert to a meeting every two weeks (bryan_att, 15:56:08)
    5. ... the audio meetings do help clarify a lot in a short time; so we will continue them (bryan_att, 15:56:36)
    6. ... we can add additional meetings as needed (bryan_att, 15:56:52)


Meeting ended at 15:57:02 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. bryan_att (77)
  2. collabot (3)
  3. iben_ (2)


Generated by MeetBot 0.1.4.