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. Steps to enforce security policy
(1) Create a packet filtering policy
Policy : 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. Security Policy with Port Group
AllowHTTP Group1
VM VM
2 P P 1
Group2 AllowDBAccess Group1
Security Policy
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. 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. 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. 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. 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. 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. 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.
