← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1427054] Re: no way to know what IP spoofing rule is applied

 

[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


References