yahoo-eng-team team mailing list archive

[Rui Zang <rui.zang@xxxxxxxxxxx>]

Public bug reported:

Basically all NFV use-cases would require this split. The current
approach for NFV is to turn things off and have the VNFs protect
themselves rather than the infra-structure supports security.  Even in
simple deployments, like cloud bursting, you'll need to be able to allow
the customer to control his addressing. The customer might want to do so
by having the router (which does the IPSEC tunnel termination) either
use ICMP RA (in case of v6/SLAAC) or DHCP (v4/v6) to control addressing
- as opposed to have openstack control the addressing. In this case, the
VNF only deals with addressing but it has to protect itself without
security groups.

** Affects: neutron
     Importance: Undecided
     Assignee: Rui Zang (rui-zang)
         Status: New

** Changed in: neutron
     Assignee: (unassigned) => Rui Zang (rui-zang)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1633280

Title:
  need a way to disable anti-spoofing rules and yet keep security groups

Status in neutron:
  New

Bug description:
  Basically all NFV use-cases would require this split. The current
  approach for NFV is to turn things off and have the VNFs protect
  themselves rather than the infra-structure supports security.  Even in
  simple deployments, like cloud bursting, you'll need to be able to
  allow the customer to control his addressing. The customer might want
  to do so by having the router (which does the IPSEC tunnel
  termination) either use ICMP RA (in case of v6/SLAAC) or DHCP (v4/v6)
  to control addressing - as opposed to have openstack control the
  addressing. In this case, the VNF only deals with addressing but it
  has to protect itself without security groups.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1633280/+subscriptions