Course Name- CSc 8320 Advanced Operating Systems Instructor- Dr. Yanqing Zhang Presented By- Sunny Shakya Latest AOS techniques, applications and future work : CLOUDPOLICE

Outline Part 1 – Context and Motivation Access control for clouds: why and what? Limitations of traditional mechanisms Part 2 – CloudPolice Approach Operation Future Work

Context Infrastructure as a Service virtualized clouds Traffic internal to cloud Hypervisor VM

Context Cloud computing requires network access control Access control policy of tenant X - what network traffic is tenant X willing to accept Tenant X Y can talk to me Tenant Y

Why Access Control in Clouds? For isolation Policy: deny incoming traffic from any other tenant Tenant 2 Tenant 1

Why Access Control in Clouds? For inter-tenant & tenant-provider communication Policy: weighted bandwidth allocation between tenants Tenant 1 Tenant 2 Ad Network 1 Ad Network 2 Database Share bandwidth fairly among tenants regardless of #VM sources Tenant 3

Why Access Control in Clouds? DoS protection One tenant can attack another tenant Reduce bandwidth and slow down machines Attackers more powerful: higher bandwidths Barrier is lower: pay for attacking hosts Tenant 1 Ad Network 1 Ad Network 2 Database Tenant 3 Tenant 2 DoS

Hence, the problem Want access control in clouds that Is resilient to DoS Supports rich inter-tenant policies Scales 100k servers 10k tenants Tolerates high dynamicity 100k VMs started per day, more than one per second Traditional access control mechanisms not well suited to meeting these requirements

Hence, the problem Want access control in clouds that Is resilient to DoS Supports rich inter-tenant policies Scales 100k servers 10k tenants Tolerates high dynamicity 100k VMs started per day, more than one per second Traditional access control mechanisms not well suited to meeting these requirements

Existing Access Control Access control in Cloud is provided using VLANs Firewalls Originally designed for enterprise environments But clouds != enterprises

Clouds != Enterprises Enterprises are not multi-tenant Few DoS concerns between departments Typically simpler policies Clouds have different network designs High bisection bandwidths, multiple paths, different L2/L3 mix Many new topologies: FatTree, BCube, DCell, etc. Limited Scalability

Goal Network Access Control for Clouds that is: 1. Independent of network topology and addressing 2. Scalable (millions hosts, high churn) 3. Flexible (rated access, fair access) 4. Robust to (internal) DoS attacks

CloudPolice Hypervisor VM Sufficient and advantageous to implement access control only within hypervisors Trusted Network independent Full software programmability  flexible Close to VMs  block unwanted traffic before network and help DoS Easy deployability

CloudPolice Sufficient and advantageous to implement access control only within hypervisors Hypervisor VM CloudPolice Policy Model Group = set of tenant VMs with same access control policy

CloudPolice Sufficient and advantageous to implement access control only within hypervisors Hypervisor VM Policy = set of Rules Rule = IF Condition THEN Action CloudPolice Policy Model

CloudPolice Sufficient and advantageous to implement access control only within hypervisors Hypervisor VM Condition = logical expression with predicates based on: Group of sender Packet header Current time History of traffic CloudPolice Policy Model

CloudPolice Hypervisor VM Action: Allow Block Rate-limit (token bucket) CloudPolice Policy Model

CloudPolice Sufficient and advantageous to implement access control only within hypervisors Hypervisor VM Action: Allow Block Rate-limit (token bucket) CloudPolice Policy Model Applied per flow source VM source group

CloudPolice Hypervisor XYZ Policies for X, Y and Z CloudPolice Each hypervisor needs to know for hosted VMs: group and policy X’s group policy: IF group = A  allow IF group = B  block IF group = C & port = 80  rate-limit to 100Mbps Y’s group policy: Z’s group policy: IF … Policy could also be specified / updated by VM Installed by provider service that starts VMs

CloudPolice Hypervisor XYZ Filter for incoming/outgoing flows

CloudPolice Hypervisor XYZ ABC Start flow to C Control Packet CloudPolice inserts control packet before the flow

CloudPolice Hypervisor XYZ ABC CloudPolice verifies policy of destination VM If allowed, packets are forwarded to destination VM Block/rate-limit If blocked or rate limited, send control packet to source hypervisor to block or rate-limit source (flow/VM)

Future Work Extend CloudPolice Policies with application-level semantics (dynamic policies) Policies based on group-wide state Beyond access control? More flexible actions, e.g., send to middlebox Performance isolation framework

References Popa et. al “CloudPolice: Taking Access Control out of the Network,” Hotnets 10, October 20-21, 2010, Monterey, CA, USA. X. Yang, D. J. Wetherall, and T. Anderson. “A DoS-limiting Network Architecture,” In ACM SIGCOMM, 2005