Course Name- CSc 8320 Advanced Operating SystemsInstructor- Dr. Yanqing ZhangPresented By- Sunny Shakya

Latest AOS techniques, applications and future work : CLOUDPOLICE

OutlinePart 1 – Context and Motivation

Access control for clouds: why and what?Limitations of traditional mechanisms

Part 2 – CloudPolice ApproachOperation

Future Work

ContextInfrastructure as a Service virtualized

clouds

Traffic internal to cloud

Hypervisor

VM

VM

VM

ContextCloud 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

meTenant

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

communicationPolicy: weighted bandwidth allocation

between tenants

Tenant 1 Tenant

2

Ad Networ

k 1

Ad Networ

k 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 tenantReduce bandwidth and slow down machinesAttackers more powerful: higher bandwidthsBarrier is lower: pay for attacking hosts

Tenant 1

Ad Networ

k 1

Ad Networ

k 2

Database

Tenant 3 Tenant 2

DoS

Hence, the problem

Want access control in clouds thatIs resilient to DoSSupports rich inter-tenant policiesScales

100k servers10k tenants

Tolerates high dynamicity100k 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 thatIs resilient to DoSSupports rich inter-tenant policiesScales

100k servers10k tenants

Tolerates high dynamicity100k VMs started per day, more than one per second

Traditional access control mechanisms not well suited to meeting these requirements

Existing Access ControlAccess control in Cloud is provided usingVLANsFirewalls

Originally designed for enterprise environments

But clouds != enterprises

Clouds != EnterprisesEnterprises are not multi-tenant

Few DoS concerns between departmentsTypically simpler policies

Clouds have different network designsHigh bisection bandwidths, multiple paths,

different L2/L3 mixMany 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 VM VM

Sufficient and advantageous to implement access control only within hypervisorsTrustedNetwork independentFull software programmability flexibleClose to VMs block unwanted traffic before

network and help DoSEasy deployability

CloudPoliceSufficient and advantageous to implement access control only within hypervisors

Hypervisor

VM VM VM

CloudPolice Policy Model

Group = set of tenant VMs with same access control policy

CloudPoliceSufficient and advantageous to implement

access control only within hypervisors

Hypervisor

VM VM VM

Policy = set of RulesRule = IF Condition THEN Action

CloudPolice Policy Model

CloudPoliceSufficient and advantageous to implement

access control only within hypervisors

Hypervisor

VM VM VM

Condition = logical expression with predicates based on:• Group of sender• Packet header• Current time• History of traffic

CloudPolice Policy Model

CloudPolice

Hypervisor

VM VM VM

Action: • Allow• Block• Rate-limit (token

bucket)

CloudPolice Policy Model

CloudPoliceSufficient and advantageous to implement

access control only within hypervisors

Hypervisor

VM VM VM

Action: • Allow• Block• Rate-limit (token

bucket)

CloudPolice Policy Model

Applied per

flow

source VMsource group

CloudPolice

Hypervisor

X Y Z

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 allowIF group = B blockIF group = C & port = 80 rate-limit to 100Mbps

Y’s group policy:

Z’s group policy:

IF …

IF …

Policy could also be specified / updated

by VM

Installed by provider service that starts VMs

CloudPolice

Hypervisor

X Y Z

Filter for incoming/outgoing

flows

CloudPolice

Hypervisor

X Y Z A B C

Hypervisor

Start flow to C

Control Packet

CloudPolice inserts control packet before the flow

CloudPolice

Hypervisor

X Y Z A B C

Hypervisor

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 WorkExtend CloudPolice

Policies with application-level semantics (dynamic policies)

Policies based on group-wide stateBeyond access control?

More flexible actions, e.g., send to middleboxPerformance isolation framework

ReferencesPopa 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