Towards a Flow-level Network Security System Tim Hinrichs

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 users 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
Src IP Port Forward 10.0.0.1 80
10.0.0.25
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
Application if (packet p originated from guest
user port is 80) then m findproxy()
forward p to m on port 80
Src IP Port Forward 10.0.0.1 80
10.0.0.25
10.0.0.25
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 Nicira
Networks Nicira Networks Stanford University UC
Berkeley
12
NOX Architecture
App 1
NOX Controller
Network View
App 2
App 3
PC
OF Switch
Wireless OF Switch
OF Switch
Off-the-shelf hosts
13
Switch Abstraction

• OpenFlow switch abstraction is a flow table.
• Each flow table entry takes the form
• ltheader counters, actionsgt
• Switch executes the actions corresponding to the
  highest-priority matching header in table.

14
Operation

• Switch
• Packet p reaches switch.
• If p matches a flow entry
• Then apply the corresponding actions
• Else forward to the controller
• Controller
• Packet p reaches controller.
• Update view of network state.
• 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 (106) handled by switches
• Flow initiations (105) handled by controller
• View change (10) handled by controller
• Controller
• Can be replicated.
• Only global data structure view.
• One currently handles 105 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
FSLA Flow-based Security Language

• Tim Hinrichs
• Natasha Gude
• Martìn Casado
• John Mitchell
• Scott Shenker

University of Chicago Nicira Networks Nicira
Networks Stanford University UC Berkeley
21
NOX Operation
22
NOX Operation
SECURITY POLICY
23
NOX Operation
24
FSL

• FSL Flow Security Language Hinrichs2009
• Balances the desires to make expressing policies
  natural and implementing policies efficient.

• Protocol

• User source
• Host source
• Access point source

• User target
• Host target
• Access point target

25
Features

• Distributed policy authorship
• External references
• Conflicts, conflict detection, conflict
  resolution
• Incremental policy authorship via priorities
• Analyzability
• High Performance 104 queries/second
• Layered language

Prioritization
Conflict Resolution
Keywords
Logic
Data
26
Datalog with Attachments

• Syntax
• h - b1,,bn,?c1,,?cm
• 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(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
• superuser(Usrc)
• superuser(bob)
• superuser(alice)

28
Keyword deny

• No phone can communicate with any private
  computer.
• deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
• phone(Hsrc) , private(Htgt)
• deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
• private(Hsrc) , phone(Htgt)
• private(X) - laptop(X)
• private(X) - desktop(X)

29
Keyword visit

• Every wireless guest user must send HTTP
  requests through a proxy.
• visit(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot,httpproxy
  ) -
• guest(Usrc) , wireless(Asrc) , Prothttp

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(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,ssh) -
• ?guest(Usrc) , server(Htgt)

32
Traditional Security Mechanisms

• NAT disable incoming connections for laptops
• deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
• laptop(Htgt)
• VLAN isolate machines a,b,c
• vlan(a), vlan(b), vlan(c)
• deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
• vlan(Hsrc), ?vlan(Htgt)
• deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
• ?vlan(Hsrc), vlan(Htgt)

33
Conflicts

• Conflicts are vital in collaborative settings
  because they allow administrators to express
  their true intentions.
• Authorization systems cannot enforce conflicting
  security policies.

34
FSL Usage Overview
Policy 1
Policy n

Combined Policy
Analysis Engine
Authorization System
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(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot)
• deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
• phone(Hsrc) , private(Htgt)
• deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
• private(Hsrc) , phone(Htgt)

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.
• P1 lt P2
• A request constrained by P2 is only constrained
  by P2.

39
Example

• P1
• P2
• allow(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) ?
  Usrcceo

allow(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
superuser(Usrc) superuser(bob) superuser(alice) de
ny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
phone(Hsrc) , private(Htgt) deny(Usrc,Hsrc,Asrc,Ut
gt,Htgt,Atgt,Prot) - private(Hsrc) ,
phone(Htgt) private(X) - laptop(X) private(X) -
desktop(X) visit(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Pro
t,httpproxy) - guest(Usrc) , wireless(Asrc) ,
Prothttp allow(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,ssh)
- ?guest(Usrc) , server(Htgt)
40
Cascaded Policy Combination
Policy 1,m1
Policy n,mn


Policy 1,2
Policy n,2

Policy 1,1
Policy n,1
Combined Policy
41
Cascaded Policy Combination

• Flatten cascades.
• Combine results.

Policy 1
Policy n

Combined Policy
42
Features

• Distributed policy authorship
• External references
• Conflict detection/resolution
• Incremental policy authorship via priorities
• Analyzability
• High Performance 104 queries/second
• Layered language

Prioritization
Conflict Resolution
Keywords
Logic
Data
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(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
• phone(Hsrc) , private(Htgt)
• deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
• private(Hsrc) , phone(Htgt)
• private(X) - laptop(X)
• private(X) - desktop(X)

45
Performance Example Compiled

• bool deny (Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot)
• return (phone(Hsrc) private(Htgt))
• (private(Hsrc) phone(Htgt))
• 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
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
References

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

52
Questions
App 1
NOX Controller
Network View
App 2
App 3
PC
OF Switch
Wireless OF Switch
OF Switch
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(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
  superuser(Usrc)
• superuser(bob)
• superuser(alice)
• deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
  phone(Hsrc) , private(Htgt)
• deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) -
  private(Hsrc) , phone(Htgt)
• private(X) - laptop(X)
• private(X) - desktop(X)
• visit(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot,httpproxy
  ) - guest(Usrc) , wireless(Asrc) , Prothttp
• allow(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,ssh) -
  ?guest(Usrc) , server(Htgt)

Statement order is irrelevant.
56
Cascade Properties

• Every Cascade can be expressed as a non-cascaded
  policy.
• P1 A - B
• P2 C - D
• P1 lt P2
• A - B , ?D
• C - D
• Flattening a cascade requires time linear in the
  size of the cascade
• O(P1 lt lt Pn)