Published on

  • Be the first to comment

  • Be the first to like this


  1. 1. Improving Packet Filtering feature (API and Driver) Akihiro Motoki, NEC 2012/10/17
  2. 2. Motivation• Demands for fine-grained packet filtering – Beyond security group ACL • Security group just defines incoming ACL from the Internet (outside of OpenStack). • ACLs for inter-VM communication – Dynamic rule configuration • Allow only during a limited period E.g.: Bare-metal support, TFTP only allowed during boot – Admin enforces “additional security policies” for tenants • Anti- MAC/ARP spoofing (like nova-compute does)
  3. 3. Steps to enforce security policy (1) Create a packet filtering policyPolicy : AllowHTTP (dst_port=80) (3) Binding a security policy (4) Packet filtering rule is and a quantum port enforced on a real network. Actual rule: AllowHTTP(dst_port=80) for Port-id: xxxxxxxx Port-id : xxxxxxxx (2) Create a Quantum port After a port is created, security policies are enforced in real. Flexible binding between port and policy is needed.  Introducing a notion of “port group”
  4. 4. Security Policy with Port Group AllowHTTP Group1VM VM 2 P P 1 Group2 AllowDBAccess Group1 Security Policy
  5. 5. Packet Filtering Policy { "filter": { "priority": "<Priority number of this filter rule (1-65535)>", "condition": { "in_group": "<Incoming Quantum port group>", “out_group": "<Outgoing Quantum port group>", "src_mac": "<Source MAC address>", "dst_mac": "<Destination MAC address>", “ethertype” : <L3 protocol type (IPv4/IPv6/…)> "src_cidr": "<Source IP address>", "dst_cidr": "<Destination IP address>", "protocol": "<L4 Protocol (TCP/UDP/ICMP/…)>", "src_port": "<L4 source port number>", "dst_port": "<L4 destination port number>" }, "action": "<Action for matched packets (ACCEPT or DROP)>" } }• in/out_groups will be bound to quantum ports.• Either of in_group or out_group can be ‘*’.• Non-‘*’ in/out_group are bound to quantum ports, the security policy is applied to the associated ports.
  6. 6. Rule after bound with a port { "filter": { "priority": "<Priority number of this filter rule (1-65535)>", "condition": { "in_port": "<Incoming Quantum port ID>", “out_port": "<Outgoing Quantum port ID>", "src_mac": "<Source MAC address>", "dst_mac": "<Destination MAC address>", “ethertype” : <L2 protocol type (IPv4/IPv6/ARP)> "src_cidr": "<Source IP address>", "dst_cidr": "<Destination IP address>", "protocol": "<L3 Protocol (TCP/UDP/ICMP)>", "src_port": "<L4 source port number>", "dst_port": "<L4 destination port number>" }, "action": "<Action for matched packets (ACCEPT or DROP)>" } }• This rule is applied to a physical network.
  7. 7. Driver model• Driver model is suitable. – There are several implementation options for packet filtering. • Linux iptables, OVS flow rules (on compute nodes) • SDN/OpenFlow controller (on a logical netwrok) • Firewall appliance or gateway router • Combination of the above Packet Filter REST-API – In the real implementation, there are two options: • Driver class (using import_class) Packet Filtering Support • Mixin class Driver Driver Driver FW iptables OpenFlow Appliance
  8. 8. Driver interface where? Registering Packet Filter Policy Add port binding(Add Group) Option 1 Option 2 Common Filtering Policy Mngmnt Common Request Enforcing rule for a port Driver Filtering Rule Enforcing Driver Configure devices Network devices
  9. 9. Security group support• Security group can be implemented on top of this API. • Create a port group • Convert packet filtering policy from security group rule. Security Group API Packet Filter API Security Group Support Method call Packet Filtering Management Driver
  10. 10. Other topics• “admin_flag” – Both tenant and admin can use the packet filtering API. – There are cases where admin enforces security policies for tenants. These policies should be invisible to tenants.
  11. 11. Proposal• Define a more flexible model for packet filtering – Security Group is implemented on top this interface.• Use Driver model approach to accept multiple implementation.