Currently, ICMP type and code are represented via port_range_min and 
port_range_max when icmp protocol is specified. See 
 (Just the state of things, I’m not commenting on how bad it is).

I would also like to see improvements to the security groups API as well, with 
additional parameters —source-port-range-min and —source-port-range-max to 
specify source ports on security group rules for blueprint ovs-firewall-driver. 
Upon review, it was recommended to me to create an extension on top of the 
existing security groups extension to not interfere with existing security 
groups extension API implementations. If you’d like to continue, you should 
probably follow that route also.

Amir Sadoughi

On Mar 3, 2014, at 7:39 AM, Xuhan Peng 
<pengxu...@gmail.com<mailto:pengxu...@gmail.com>> wrote:

I created a new blueprint [1] which is triggered by the requirement to allow 
IPv6 Router Advertisement security group rule on compute node in my on-going 
code review [2].

Currently, only security group rule direction, protocol, ethertype and port 
range are supported by neutron security group rule data structure. To allow 
Router Advertisement coming from network node or provider network to VM on 
compute node, we need to specify ICMP type to only allow RA from known hosts 
(network node dnsmasq binded IP or known provider gateway).

To implement this and make the implementation extensible, maybe we can add an 
additional table name "SecurityGroupRuleData" with Key, Value and ID in it. For 
ICMP type RA filter, we can add key="icmp-type" value="134", and security group 
rule to the table. When other ICMP type filters are needed, similar records can 
be stored. This table can also be used for other firewall rule key values.
API change is also needed.

Please let me know your comments about this blueprint.

[2] https://review.openstack.org/#/c/72252/

Thank you!
Xuhan Peng
OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to