1. Towards a Flow-level Network Security System Tim Hinrichs University of Chicago

2. Local Area Networks

3. Network Policy Examples “Every wireless guest user must send HTTP requests through an HTTP proxy.” “No phone can communicate with any private computer.” “Superusers have no communication restrictions.” “Laptops cannot receive incoming connections.”

4. Traditional Network Management Today networks are managed by low-level configuration of independent components, e.g. firewalls, proxies, routers. Dependent on underlying network. Examples –Block user access by adding an ACL entry. Requires knowing user’s IP address. –Force guests port 80 traffic through a proxy. Requires knowing the network topology and the location of each guest.

5. Example 10.0.0.1 10.0.0.25 Src IP Port Forward 10.0.0.1 80 10.0.0.25

6. Management by Component Configuration Benefits Efficiency of operation. Administrative fiefdoms enjoy autonomy. Drawbacks Inefficiencies of maintenance. Inconsistencies are likely.

7. Network Operating Systems Provide a programmatic interface to observe and control the entire network. Applications perform the actual management by making system calls. Two paradigm shifts –Logical Centralization: Applications are written as if network were present on single machine. –Abstraction: Applications are written in terms of abstract entities, e.g. users and hosts.

8. Example 10.0.0.1 10.0.0.25 Src IP Port Forward 10.0.0.1 80 10.0.0.25 Application: if (packet p originated from guest user && port is 80) then m := findproxy(); forward p to m on port 80

9. Management by Network Operating System Potential Benefits Efficiency of maintenance. Inconsistencies are less likely. Potential Drawbacks Inefficiencies of operation. Loss of autonomy.

10. Network Security An authorization policy is implemented as an application in a network operating system. The same is true for an authentication policy. Focus for today: a language for expressing authorization policies over networks.

11. NOX: A Network Operating System Natasha Gude Teemu Koponen Justin Pettit Ben Pfaff Martìn Casado Nick McKeown Scott Shenker Nicira Networks HIIT Nicira Networks Stanford University UC Berkeley

12. NOX Architecture Network View Network View App 1 App 2 App 3 OF Switch Wireless OF Switch NOX Controller PC Off-the-shelf hosts

13. Switch Abstraction OpenFlow switch abstraction is a flow table. Each flow table entry takes the form Switch executes the actions corresponding to the highest-priority matching header in table.

14. Operation Switch 1.Packet p reaches switch. 2. If p matches a flow entry Then apply the corresponding actions Else forward to the controller Controller 1.Packet p reaches controller. 2.Update view of network state. 3.Decide the route for the packet and inform the relevant switches of that route.

15. Application I/O Observation granularity: –Switch-level topology –Locations of users, hosts, middleboxes –Services offered, e.g. HTTP or NFS –Bindings between names and addresses –NOT the entire packet/flow state Control granularity: flows. Decisions about one packet are applied to all subsequent packets in the flow.

16. Programmatic Interface: Events NOX exposes network events to applications –Switch join –Switch leave –User authenticated –Flow initiated –… Applications consist of code fragments that respond to these events.

17. Example: Access Control function handle_flow_initialize(packet) usersrc = nox.resolve_user_src(packet) hostsrc = nox.resolve_host_src(packet) usertgt = nox.resolve_user_tgt(packet) hosttgt = nox.resolve_host_tgt(packet) prot = nox.resolve_ap_prot(packet) if deny(usersrc,hostsrc,usertgt,hosttgt,prot) then nox.drop(packet) else nox.installpath(p, nox.computepath(p)) function deny(usersrc, hostsrc, usertgt, hosttgt, prot) …

18. Scalability Events (per second) –Packet arrivals (10 6 ): handled by switches –Flow initiations (10 5 ) : handled by controller –View change (10): handled by controller Controller –Can be replicated. –Only global data structure: view. –One currently handles 10 5 flow initiations per second.

19. Related Work 4D project (2005): provide global view of network via centralized controller. SANE/Ethane (2007): extends 4D by adding users/nodes to the namespace and captures flow- initiation. NOX (2008): extends SANE/Ethane –Scaling for large networks. –General programmatic control of network. Maestro (2008): “network OS” focused on controlling interactions between applications. Industry: deep-packet inspection, firewalls, etc. are appliances--can be leveraged by NOX. Also, functionality similar to Ethane. For citations, see [Gude2008].

20. FSL: A Flow-based Security Language Tim Hinrichs Natasha Gude Martìn Casado John Mitchell Scott Shenker University of Chicago Nicira Networks Stanford University UC Berkeley

21. NOX Operation

22. SECURITY POLICY

23. NOX Operation

24. FSL FSL: Flow Security Language [Hinrichs2009] Balances the desires to make expressing policies natural and implementing policies efficient. User source Host source Access point source User target Host target Access point target Protocol

25. Features Distributed policy authorship External references Conflicts, conflict detection, conflict resolution Incremental policy authorship via priorities Analyzability High Performance: 10 4 queries/second Layered language: LogicData Keywords Conflict Resolution Prioritization

26. Datalog with Attachments Syntax h :- b 1,…,b n,c 1,…,c m h must exist. Every variable in the body must appear in h. No external reference occurs in h. Nonrecursive sentence sets. Semantics –Statement order is irrelevant. –Every sentence set is satisfied by exactly one model.

27. Keyword: allow “Superusers have no communication restrictions.” allow(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- superuser(U src ) superuser(bob) superuser(alice)

28. Keyword: deny “No phone can communicate with any private computer.” deny(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- phone(H src ), private(H tgt ) deny(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- private(H src ), phone(H tgt ) private(X) :- laptop(X) private(X) :- desktop(X)

29. Keyword: visit “Every wireless guest user must send HTTP requests through a proxy.” visit(U src,H src,A src,U tgt,H tgt,A tgt,Prot,httpproxy) :- guest(U src ), wireless(A src ), Prot=http

30. Current Keyword List allow: allow the flow deny: deny the flow visit: force the flow to pass through an intermediary avoid: forbid the flow from passing through an intermediary ratelimit: limit on Mb/second

31. Negation “Every user except a guest can ssh into any server.” allow(U src,H src,A src,U tgt,H tgt,A tgt,ssh) :-  guest(U src ), server(H tgt )

32. Traditional Security Mechanisms NAT: disable incoming connections for laptops deny(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- laptop(H tgt ) VLAN: isolate machines a,b,c vlan(a), vlan(b), vlan(c) deny(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- vlan(H src ),  vlan(H tgt ) deny(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :-  vlan(H src ), vlan(H tgt )

33. Conflicts Conflicts are vital in collaborative settings because they allow administrators to express their true intentions. Authorization systems cannot enforce conflicting security policies. deny avoid visit allow ratelimit deny avoid visit allow ratelimit

34. FSL Usage Overview Combined Policy Analysis Engine Authorization System Policy 1 Policy n …

35. Conflict Resolution No conflicts: conflicts are errors. Most restrictive: choose instructions that give users the least rights. Most permissive: choose policy instructions that give users the most rights. Cancellation: a flow with conflicting constraints has no constraints.

36. Conflict Resolution as a Tool Fixing the conflict resolution mechanism allows certain policies to be expressed very simply. Example (Open Policy): allow everything not explicitly denied. allow(U src,H src,A src,U tgt,H tgt,A tgt,Prot) deny(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- phone(H src ), private(H tgt ) deny(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- private(H src ), phone(H tgt )

37. Incremental Policy Authoring To tighten a FSL policy, one needs only to add statements to it. The conflict resolution strategy ensures that the most restrictive constraints are used. To relax a FSL policy, it is therefore insufficient to simply add statements.

38. Prioritized Policies Borrow a mechanism from Cascading Style Sheets (CSS). To relax security incrementally, FSL allows one policy to be overridden by another policy. P 1 < P 2 A request constrained by P 2 is only constrained by P 2.

39. Example P 1 P 2 allow(U src,H src,A src,U tgt,H tgt,A tgt,Prot)  U src =ceo allow(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- superuser(U src ) superuser(bob) superuser(alice) deny(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- phone(H src ), private(H tgt ) deny(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- private(H src ), phone(H tgt ) private(X) :- laptop(X) private(X) :- desktop(X) visit(U src,H src,A src,U tgt,H tgt,A tgt,Prot,httpproxy) :- guest(U src ), wireless(A src ), Prot=http allow(U src,H src,A src,U tgt,H tgt,A tgt,ssh) :-  guest(U src ), server(H tgt )

40. Cascaded Policy Combination Combined Policy 1,1 Policy 1,2 Policy 1,m 1 … Policy n,1 Policy n,2 Policy n,m n … …

41. Cascaded Policy Combination Combined Policy 1 Policy n … 1.Flatten cascades. 2.Combine results.

42. Features Distributed policy authorship External references Conflict detection/resolution Incremental policy authorship via priorities Analyzability High Performance: 10 4 queries/second Layered language: LogicData Keywords Conflict Resolution Prioritization

43. Analysis Algorithms Flattened Cascade: a policy cascade expressed as a flat policy. Group Normal Form: every rule body consists only of external references (and =). Conflict Conditions: conditions on external references under which there will be a conflict. Conflict-free Normal Form: equivalent policy (under conflict resolution) without conflicts.

44. Performance Example “No phone can communicate with any private computer.” deny(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- phone(H src ), private(H tgt ) deny(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- private(H src ), phone(H tgt ) private(X) :- laptop(X) private(X) :- desktop(X)

45. Performance Example Compiled bool deny (U src,H src,A src,U tgt,H tgt,A tgt,Prot) { return (phone(H src ) && private(H tgt )) || (private(H src ) && phone(H tgt )); } bool private(X) { return laptop(X) || desktop(X); } Assume the existence of functions for phone, laptop, desktop.

46. FSL Complexity Query processing is PSPACE-complete in the size of the policy. If the number of arguments are bounded by a constant, query processing takes polynomial time in the size of the policy. If the tallest possible call stack is 1 (ignoring external references), then query processing takes linear time in the size of the policy.

47. Implementation Tests Flows/sMem (MB) Rule Matches 0 rules103,69900 100 rules100,94212 500 rules85,37314 1,000 rules76,336210 5,000 rules54,416930 10,000 rules46,9563852

48. Deployment Experiences On a small internal network (about 50 host), NOX has been in use over a year, and FSL has been in use for 10 months. We are preparing for two larger deployments (of hundreds and thousands of hosts). So far, policies are expressed over just a few classes of objects. Thus, we expect policies to grow slowly with the number of principals.

49. Ongoing Work Currently, each flow initiation requires contacting a central controller. The route for that flow is cached at the router. Working to generalize this caching scheme. Each trip to the central controller caches more than just the route for one flow.

50. Related Work Comparison Limitations Not using FOL, Modal logic, Linear logic No existential variables No recursion Fixed conflict resolution scheme No delegation No history/future-dependent policies Centralized enforcement Limited metalevel operations Novel language features Access control decisions are constraints. Conflict resolution produces constraint set For citations, see [Hinrichs2009].

51. [Gude2008] N. Gude, et. al. NOX: Towards an Operating System for Networks. Computer Communications Review 2008. [Hinrichs2009] T. Hinrichs, et. al. Design and Implementation of a Flow-based Security Language. Under review. Available upon request. References

52. Questions Network View Network View App 1 App 2 App 3 OF Switch Wireless OF Switch NOX Controller PC Off-the-shelf hosts

53. Backup

54. NOX Security Issues Switch communication with Controller. Preconfigure switches with Controller credentials. Hosts, users must authenticate. Spoofing Ethernet addresses. Options: (1) Physically connect one switch port to one host. (2) Use link-level encryption.

55. Examples Combined allow(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- superuser(U src ) superuser(bob) superuser(alice) deny(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- phone(H src ), private(H tgt ) deny(U src,H src,A src,U tgt,H tgt,A tgt,Prot) :- private(H src ), phone(H tgt ) private(X) :- laptop(X) private(X) :- desktop(X) visit(U src,H src,A src,U tgt,H tgt,A tgt,Prot,httpproxy) :- guest(U src ), wireless(A src ), Prot=http allow(U src,H src,A src,U tgt,H tgt,A tgt,ssh) :-  guest(U src ), server(H tgt ) Statement order is irrelevant.

56. Cascade Properties Every Cascade can be expressed as a non-cascaded policy. P 1 : A :- B P 2 : C :- D P 1 < P 2 : A :- B, D C :- D Flattening a cascade requires time linear in the size of the cascade: O(|P 1 < … < P n |)