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

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

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

4. 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

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

6. 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

7. 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

8. 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

9. 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

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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

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

18. 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

19. 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

20. CloudPolice Hypervisor XYZ Filter for incoming/outgoing flows

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

22. 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)

23. 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

24. 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