[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 : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp