no way to know what IP spoofing rule is applied

Bug #1427054 reported by Akihiro Motoki
6
This bug affects 1 person
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-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).

Tags: sg-fw
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

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.

Changed in neutron:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in neutron:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.