Presentation is loading. Please wait.

Presentation is loading. Please wait.

DIMACS Cloud Workshop, Dec. 8-9, 2011 PACE: Policy-Aware Application Cloud Embedding Y. Richard Yang Joint work w/ Erran Li, G. Wilfong, M. F. Nowlan,

Similar presentations


Presentation on theme: "DIMACS Cloud Workshop, Dec. 8-9, 2011 PACE: Policy-Aware Application Cloud Embedding Y. Richard Yang Joint work w/ Erran Li, G. Wilfong, M. F. Nowlan,"— Presentation transcript:

1 DIMACS Cloud Workshop, Dec. 8-9, 2011 PACE: Policy-Aware Application Cloud Embedding Y. Richard Yang Joint work w/ Erran Li, G. Wilfong, M. F. Nowlan, V. Liaghat, M. Hajiaghayi, H. Zhao, D. Li, C. Guo, and M. Zhang Y. Richard Yang Joint work w/ Erran Li, G. Wilfong, M. F. Nowlan, V. Liaghat, M. Hajiaghayi, H. Zhao, D. Li, C. Guo, and M. Zhang

2 DIMACS Cloud Workshop, Dec. 8-9, 2011 Motivation A key aspect of cloud computing is on-demand allocation of infrastructure resources to construct applications 2 Cloud On-demand App VM LUN Data Center 1 Data Center 2 VM LUN

3 DIMACS Cloud Workshop, Dec. 8-9, 2011 tier-1 Example Real App 3 Internet CE Tier-1 F1 (Firewall) S1S1 LB1 (Load balancer) IPS1(Intrusion prevention) F2F2 S2S2 LB2 IPS2 S3S3 S4S4 VLAN 300 VLAN 400 Tier-2 VLAN 100 R1R1 S5S5 IPS3 S6S6 VLAN 200 Tier-3 Logger

4 DIMACS Cloud Workshop, Dec. 8-9, 2011 App Structure Properties A real-world application is not a set of isolated resources (e.g., VMs/LUNs) Real world-applications are constructed with external entities (e.g., policy boxes) to enhance functionality, –95% web applications have severe vulnerabilities if deployed alone [WASC] 4

5 DIMACS Cloud Workshop, Dec. 8-9, 2011 Policy-Aware Application Cloud Embedding What is it? –Construct structured applications, according to application policies, in cloud settings 5

6 DIMACS Cloud Workshop, Dec. 8-9, 2011 Why Worry about PACE? 6  Example 1: Relocating tier-1 servers in VLAN 300 and 400 to cloud Issues IPS1 is used to monitor cross VLAN traffic. After relocation, cross traffic will not be monitored by IPS1 Tier-1 servers cannot reach tier-2 servers tier-1 Internet CE Tier-1 F1 (Firewall) S1S1 LB1 (Load balancer) IPS1(Intrusion prevention) F2F2 S2S2 LB2 IPS2 S3S3 S4S4 VLAN 300 VLAN 400 Tier-2

7 DIMACS Cloud Workshop, Dec. 8-9, 2011 Why Worry about PACE? 7  Example 2: Extending VLAN 200 and 100 VLAN 100 R1 S5 IPS3 S6 Data Center 1 VLAN 200 u3 v3 VLAN 100VLAN 200 u’3v’3 S7 L2 Extension Link Path1 Path2 Data Center 2

8 DIMACS Cloud Workshop, Dec. 8-9, 2011 PACE Key Components 8 Infrastructure Orchestrator App Policy API App App/Cloud Stat Provisioning System

9 DIMACS Cloud Workshop, Dec. 8-9, 2011 Policy Specification: Flow Policy Graph For each application, introduce Flow Policy Graph (FPG) as a compact, abstract representation of its embedding policy A FPG consists of –Nodes: equivalent application-level entities –Edges: QoS/reliability demand and distributed information flow control (DIFC) policy for traffic between nodes Focus on DIFC requirements 9

10 DIMACS Cloud Workshop, Dec. 8-9, 2011 tier-1 Example: Nodes 10 Internet CE Tier-1 F1 (Firewall) S1S1 LB1 (Load balancer) IPS1 (Intrusion prevention) F2F2 S2S2 LB2 IPS2 S3S3 S4S4 VLAN 300 VLAN 400 Tier-2 VLAN 100 R1R1 S5S5 IPS3 S6S6 VLAN 200 Tier-3 Logger VLAN 500

11 DIMACS Cloud Workshop, Dec. 8-9, 2011 Example: FPG Nodes 11 LB1LB1ExEx T1- V300 T1- V400 T3- V200 T3- V100 T2- V500 LB2LB2

12 DIMACS Cloud Workshop, Dec. 8-9, 2011 Distributed Information Flow Control Graph based information flow control (IFC) representation –Default “off” policy: no inter-node communications –Edge DIFC annotation indicates required declassifier(s) to allow inter-node communication Declassifiers may be either hardware or software appliances 12

13 DIMACS Cloud Workshop, Dec. 8-9, 2011 FPG: IFC Declassifier A declassifier is identified by its function class, instance configuration, and optional a name, e.g., –F: a firewall pipe declassifier –IPS: an IPS pipe declassifier –LOG: a replication declassifier A declassifier can have internal state –Two declassifiers with the same name is a single instance 13

14 DIMACS Cloud Workshop, Dec. 8-9, 2011 Edge Direction and Multiple DIFC Declassifiers Edges are directional: the two directions of traffic between two nodes can have different DIFC policies –We call each direction a link –By default, assume that two links of the same edge have the same DIFC policy Multiple DIFC declassifiers may be specified on the same link –The semantics is ordered execution 14

15 DIMACS Cloud Workshop, Dec. 8-9, 2011 Example: Annotating FPG with DIFC 15 LB1LB1ExEx T1- V300 T1- V400 T2- V500 T3- V200 T3- V100 F/acl1;f1 LB2LB2

16 DIMACS Cloud Workshop, Dec. 8-9, 2011 Example: Annotating FPG with DIFC 16 LB1LB1ExEx T1- V300 T1- V400 LB2LB2 T2- V500 T3- V200 T3- V100 F1 ips1, log1 ips1, log1 F2 ips1, log1 F2 ips1, log1 F2 ips1, log1 F2 Same instance required for correlation

17 DIMACS Cloud Workshop, Dec. 8-9, 2011 Example: Annotating FPG with DIFC 17 LB1LB1ExEx T1- V300 T1- V400 LB2LB2 T2- V500 T3- V200 T3- V100 F1 ips1, log1 ips1, log1 F2 ips1, log1 F2 ips1, log1 F2 ips1, log1 F2 ips1,log1 ≠ log1, ips1

18 DIMACS Cloud Workshop, Dec. 8-9, 2011 Example: Annotating FPG with DIFC 18 LB1LB1ExEx T1- V300 T1- V400 LB2LB2 T2- V500 T3- V200 T3- V100 F1 ips1, log1 ips2 ips2, F2 ips3 ips2, F2 ips3 ips2, F2 ips1, log1 F2 ips1, log1 F2 ips1, log1 F2 ips1, log1 F2 Same ACL used on 4 edges. Does the app really want it?

19 DIMACS Cloud Workshop, Dec. 8-9, 2011 From FPG to Cloud Embedding Given –A network N; –Applications and their policies represented by FPGs Determine –Forwarding in the network and/or –Allocation of resources to satisfy FPGs. 19

20 DIMACS Cloud Workshop, Dec. 8-9, 2011 From FPG to Cloud Embedding Embedding depends on multiple factors –New app vs migration/extension –Declassifier deployment locations In-network devices (e.g., correlating/learning IPS) End devices (hypervisors) –Network forwarding mechanisms Traditional spanning tree, flow table, flow table w/ encapsulation, L2/L3 tunnels, PSwitch 20

21 DIMACS Cloud Workshop, Dec. 8-9, 2011 Why is Embedding (Theoretically) Hard? A Special Embedding Problem: the k-paths-tree problem: –An application with K+1 nodes a root R and a set of source nodes (VMs) S = {s 1, s 2,..., s K } already deployed –A set of distinct policy function instances M = {x 1, x 2,..., x K }, whose locations in the network are already deployed –Policy: Each edge i, 1 ≤ i ≤ K, s i -> R needs delcassifier x i 21

22 DIMACS Cloud Workshop, Dec. 8-9, 2011 NP-Reduction 22 If tree-based forwarding, it is NP-hard to determine feasibility of embedding. We reduce the NP-complete problem k-node-disjoint-path problem to our problem Given an instance of k-node-disjoint path problem, we compute an instance of our policy embedding problem

23 DIMACS Cloud Workshop, Dec. 8-9, 2011 NP-Reduction 23 t1t1t1t1 t1t1t1t1 t2t2t2t2 t2t2t2t2 tKtKtKtK tKtKtKtK s1s1s1s1 s1s1s1s1 s2s2s2s2 s2s2s2s2 sKsKsKsK sKsKsKsK G

24 DIMACS Cloud Workshop, Dec. 8-9, 2011 NP-Reduction 24 t1t1t1t1 t1t1t1t1 t2t2t2t2 t2t2t2t2 tKtKtKtK tKtKtKtK s1s1s1s1 s1s1s1s1 s2s2s2s2 s2s2s2s2 sKsKsKsK sKsKsKsK G RR x1x1x1x1 x1x1x1x1 x2x2x2x2 x2x2x2x2 xKxKxKxK xKxKxKxK NP-hardness still holds even if DC is fat-tree.

25 DIMACS Cloud Workshop, Dec. 8-9, 2011 Flow-Table Forwarding Embedding  Assume app entities and declassifiers’ locations at the network are given, what is the condition to make flow- table forwarding only enforcement possible? 25 LB1LB1ExEx T1- V400 LB2LB2 T2- V500 T3- V200 T3- V100 F1 ips1, log1 ips 2 ips2, F2 ips3 ips2, F2 ips3 ips2, F2 ips1, log1 F2 ips1, log1 F2 ips1, log1 F2 ips1, log1 F2 T1- V300

26 DIMACS Cloud Workshop, Dec. 8-9, 2011 Embedding w/ Flow Table Forwarding 26 Consider each app edge A s → A d with x 1,x 2,..., x K For notation, let A s == x 0, A d == x K+1 AsAsAsAs AsAsAsAs AdAdAdAd AdAdAdAd x 1, x 2, …, x K There exist paths p 0,... p K, where path p i is from x i to x i+1, such that No policy conflict: Each p i is conflict free, i.e., it does not traverse a declassifer that conflicts with the given x 1 to x K. No forwarding conflict: If a switch x belongs (not tail) to multiple paths in {p 0, … p K }, then the incoming ports are distinct among these multiple paths.

27 DIMACS Cloud Workshop, Dec. 8-9, 2011 Example: Feasible 27 LB1LB1T1T1 ips, log log, ips LB1 T1 log ips s1 s SrcDstinPortOPort LB1T113 LB1T132 … SrcDstinPortOPort LB1T112 LB1T123 LB1T131 …

28 DIMACS Cloud Workshop, Dec. 8-9, 2011 Example: Infeasible 28 LB1LB1T1T1 ips, log LB1 log T1 ips s1 s s3 path(LB1→ ips) and path(log → T1) forwarding conflict on switch 2/port 1

29 DIMACS Cloud Workshop, Dec. 8-9, 2011 Handling Forwarding Infeasibility 29 If infeasibility is due to forwarding conflict, and L2 encapsulation is allowed, add next-hop MAC to resolve forwarding conflict.

30 DIMACS Cloud Workshop, Dec. 8-9, Previous Proposition assumes that placement of app and declassifiers is given. What if we have placement flexibility? Placement of App and Declassifiers Placement App entities (VMs) and declassifiers Placement App entities (VMs) and declassifiers Orchestrator Forwarding to enforce PFG ✔

31 DIMACS Cloud Workshop, Dec. 8-9, 2011 Placement: Cloud Setting  A physical cloud network G(V, E)  Each physical node v in the cloud has capacity:  Function C : V → N : C(v) is # of VMs that it can host  Function Fx : V → N: Fx(v) is # of contexts of declassifier type x that it can host.  Each physical link has bandwidth:  Function B : E → N : B(e) is amount of available bw 31

32 DIMACS Cloud Workshop, Dec. 8-9, 2011 Placement: Batch Embedding  For each cloud location pair a → b, compute M paths: R 1 (a → b), …, R M (a → b)  For each cloud location pair a → b and sequence of declassifiers x 1,x 2,..., x K, compute set of feasible flow-table forwarding paths P a → b  Hence each app with a FPG can be served by picking one feasible flow-table forwarding path for each of its FPG links  Need to refactor FPG to extract shared declassifiers 32

33 DIMACS Cloud Workshop, Dec. 8-9, 2011 Placement: Batch Embedding  A batch set R of app requests to be handled  Let p be a feasible embedding of app request r  y rp : indicator {0, 1} variable of using p to satisfy r 33

34 DIMACS Cloud Workshop, Dec. 8-9, 2011 Primal to Dual 34

35 DIMACS Cloud Workshop, Dec. 8-9, 2011 Online Embedding based on Dual Comment –Gives a B-competitive fractional embedding use rounding to convert to actual embedding A negative result: no o(|R|)-comp. online embedding 35

36 DIMACS Cloud Workshop, Dec. 8-9, 2011 Simplification: Extension/Migration Embedding Policy-aware embedding can be simpler if –policy has been enforced in an original network and –cloud (public/private data centers) is used for extension/migration 36 ExEx T1- V400 LB2LB2 T2- V500 T3- V200 T3- V100 F1 ips1, log1 ips 2 ips2, F2 ips3 ips2, F2 ips3 ips2, F2 ips1, log1 F2 ips1, log1 F2 ips1, log1 F2 ips1, log1 F2 T1- V300 LB1LB1

37 DIMACS Cloud Workshop, Dec. 8-9, 2011 Setting 37 Assume each app entity is enforced as a VLAN in original network Original Network Cloud Private/Public Center VLAN x VLAN y Migrate or copy as template

38 DIMACS Cloud Workshop, Dec. 8-9, 2011 Solution: PACE Proxy 38 Introduce S proxy and V target Original Network Cloud Private/Public Center VLAN x VLAN y Migrate or copy as template v target VLAN x VLAN y S proxy L2 tunnel

39 DIMACS Cloud Workshop, Dec. 8-9, 2011 Solution: PACE Proxy 39 Link each serving switch of each migrated/extension template to S proxy in original w/ VLAN label Original Network Cloud Private/Public Center VLAN x VLAN y Migrate or copy as template v target VLAN x VLAN y S proxy VLAN y VLAN x

40 DIMACS Cloud Workshop, Dec. 8-9, 2011 Solution: PACE Proxy 40 Configure forwarding tables of S proxy and V target to enforce policies back at original network Original Network Cloud Private/Public Center VLAN x VLAN y Migrate or copy as template v target VLAN x VLAN y S proxy VLAN y VLAN x Encapsulation using QinQ or MACinMAC

41 DIMACS Cloud Workshop, Dec. 8-9, 2011 Summary 41 Cloud deployment faces policy-aware embedding issues Introduce Flow Policy Graph as a DIFC based approach to capture policies –Future work: integrated label based DIFC Cloud embedding efficiency depends on –Network forwarding mechanisms (flow table is promising) –Placement algorithms (competitive fractional alg. But worst case can be bad) Extension/migration can provide simpler solutions for embedding –Introduced the proxy approach for enforcing at original –May also compute mirrors to enforce at both

42 DIMACS Cloud Workshop, Dec. 8-9, 2011 Thank You

43 DIMACS Cloud Workshop, Dec. 8-9, 2011 Preliminary Evaluations A campus network –50 routers and 1000 switches Policies inferred based on topology properties and route distribution graph Scope of a policy –If both endpoints are in the same VLAN, the scope is all nodes in the broadcast domain of the VLAN –If endpoints are in different VLAN, the scope is all nodes reachable (based on route distribution graph and ACLs) within the security zone –Scope is extended to include relevant nodes in remote data center 43

44 DIMACS Cloud Workshop, Dec. 8-9, 2011 Evaluation (Cont’d) Policy violation without PACE – BGP redistributions routes to remote data center into base networks –three types of communication: UU sessions (among relocated servers) UL2domain (between relocated and those remaining at the same L2 domain) UExternal (between relocated and those outside the campus network). 44

45 DIMACS Cloud Workshop, Dec. 8-9, 2011 Evaluation (Cont’d) Overhead of policy enforcement 45

46 DIMACS Cloud Workshop, Dec. 8-9, 2011 Setup for algorithm evaluation  Three typical data center structures Bcube, Dcell, and fat-tree Bcube: 2187 leaf nodes and 4 levels of 3-port mini-switches Each switch has 150 middlebox instances Each leaf node has 300 VMs Each link has a bandwidth of 1Gbps Dcell(32,1): 1056 leaf nodes Each leaf node has 500 VMs each switch has 1000 middlebox instances each link has bandwidth 1Gbps Fat-tree with k = 24: 3456 leaf nodes; three middlebox placements: (I) aggregation switch, (II) half aggregation, half access (III) access switch  Application request: average number of VM and middleboxes is 50 and 60, average bandwidth is 350Mbps Evaluation (Cont’d) 46

47 DIMACS Cloud Workshop, Dec. 8-9, 2011  Comparison of online fractional algorithm with integral one Evaluation (Cont’d) 47

48 DIMACS Cloud Workshop, Dec. 8-9, 2011 S1 IPS1 S2 Remote Data Center u1 v1 Path1 S3 IPS2 S4 S5 IPS3 u’1 v’1 Path2  Problem when end hosts communicate directly in remote: a simple example when topology mismatch Why Worry about PACE?

49 DIMACS Cloud Workshop, Dec. 8-9, 2011 Existing policy preservation techniques: – Virtualization layer support: Vmware introduces Virtual Service Domain (VSD) which allows a group of VMs to be protected by virtual appliances – Switch support: data center switch supports port policy migration with attached VM, e.g. Voltaire switch However, for performance and availability of functionality, some policies must be enforced in network Existing Work

50 DIMACS Cloud Workshop, Dec. 8-9, 2011 Feasibility and Optimality  Depends on routing and policy enforcement mechanisms available in the base network and remote network  Feasibility: Key factors in the design space affecting feasibility policies –Where to enforce At base At remote Both base and remote –Connection/remote capabilities Remote is spanning-tree: determine feasibility is NP-hard Pswitch, and Openflow L2 or L3 tunnels: feasible by constructing two primitives---Mosaic Proxy, Mosaic Mirror  Optimality: objectives and constraints depends on deployment scenarios –Objectives: 1.Minimizes total path length 2.Minimizes cost: cost of network extension includes VM rental cost, Internet cost, middlebox cost –Constraints: application performance constraints including bandwidth, delay, jitter

51 DIMACS Cloud Workshop, Dec. 8-9, Mobility Data Routing Energy efficient forwarding

52 DIMACS Cloud Workshop, Dec. 8-9, 2011 Feasibility: L2 Tunnel??  Key idea: implement a logical S proxy to enforce policies in the base network Can be implemented using QinQ or MACinMAC 52

53 DIMACS Cloud Workshop, Dec. 8-9, 2011 Feasibility: L2 Tunnel?? R1R1 ueue L2domain(U) u’ 3 u2u2 S proxy S7S7 S5S5 v target v’ 3 VLAN 100 VLAN 200 IPS 3 S6S6 u3u3 v3v3 VLAN 100VLAN 200 VLAN 100 VLAN 200 VLAN 100 VLAN 200 VLAN 100 VLAN 200 Remote Data Center L2 extension Link Multihop Path 53

54 DIMACS Cloud Workshop, Dec. 8-9, 2011  Key idea: compute a minimal topology in remote data center to enforce policy constraints in remote. Compute the layer 2 domain L2domain(U) of migrating end host set U Compute the layer 3 cutset L3Cutset(U) of U Replicate L2domain(U) and L3Cutset(U) Minimize nodes needed in remote data center Tunnel traffic from L3Cutset routers to its remote replica Mirror 54

55 DIMACS Cloud Workshop, Dec. 8-9, 2011 R1R1 ueue L3Cutset(U) L2domain(U) u2u2 S7S7 S5S5 IPS3 S6S6 u3u3 v3v3 VLAN 100 VLAN 200 VLAN 100 VLAN 200 Remote Data Center ukuk RkRkR’1 S’7 S’5 IPS’1 S’6 U’3 V’3 VLAN 100 VLAN 200 VLAN 100 VLAN 200 U’k R’k L3 Secure Tunnel Multihop Path vtarget Mirror 55

56 DIMACS Cloud Workshop, Dec. 8-9, 2011 Our solution framework Topology Annotated with Device Types & Capabilities Remote Data Center Capabilities Policy Specification Enterprise network configure files Enterprise network reconfiguration Remote Data Center Provisioning Application cloud embedding steps: 1. Infer application policy from enterprise router, switch, middlebox config files, and neighbor info 2. Compute annotated topology 3. Specify remote data center capabilities 4. Automatically reconfigure enterprise network 5. Provision network in remote (application embedding)


Download ppt "DIMACS Cloud Workshop, Dec. 8-9, 2011 PACE: Policy-Aware Application Cloud Embedding Y. Richard Yang Joint work w/ Erran Li, G. Wilfong, M. F. Nowlan,"

Similar presentations


Ads by Google