[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
       Status: Incomplete => Expired

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

Title:
  no way to know what IP spoofing rule is applied

Status in neutron:
  Expired

Bug description:
  [From the discussion in neutronclient bug 1182629]

  The discussion is that there is no way to confirm and update ip spoofing 
rules (which are established by neutron implicitly).
  The bug itself was reported about two years ago, and I am not sure we need to 
fix it now.
  I think it is still worth discussed when we discuss the next step of the API.

  The following are quoted from neutronclient bug 1182629.
  -----

  Robert Collins (lifeless) wrote on 2013-05-23: 
  Sure, I appreciate what the rules do - but the security-group-rule-list is 
showing no details, and the rules that are there are not described usefully. 
The port lists for DHCP in and out for instance, should be shown, but aren't. 
The IP addresses are wildcard for the most part - but not on the ip spoofing 
rule. So I don't understand why they shouldn't be shown in a useful manner.

  Aaron Rosen (arosen) wrote on 2013-05-23: 
  [snip related to the first point]
  The second thing is that in order to use security groups you need ip spoofing 
enabled. The reason for this is if ip spoofing was not enabled an instance 
could change it's source ip in order to get around a security group rule. IMO 
displaying the ip spoofing rules does us no good.

  Robert Collins (lifeless) wrote on 2013-05-25: 
  [snip related to the first point]
  Secondly, ip spoofing is definitely important - but we can modify the DHCP 
rule like so:
    -A quantum-openvswi-oaa210549-d -m mac --mac-source FA:16:3E:7F:4F:76 -s 
0.0.0.0/32 -p udp -m udp --sport 68 --dport 67 -j RETURN
  To be more tight: 0.0.0.0/32 is the address for DHCP requests; only that and 
the assigned address may be used.

  Akihiro Motoki (amotoki) wrote on 2013-06-05: 
  [snip related to the first point]
  Regarding the second point, specifying the source MAC actually changes 
nothing since a rule preventing source mac spoofing is evaluated before DHCP 
request allow rule, but it is better to add the source mac since the rules 
becomes more robust (e.g., we can consider a case where there is no rule for 
source mac spoofing).

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

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to     : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Reply via email to