no way to know what IP spoofing rule is applied
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Expired
|
Wishlist
|
Unassigned |
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-
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-
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).
This bug is > 365 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.
If the bug is still valid, then update the bug status.