1. Resonance: Dynamic Access Control in Enterprise Networks Ankur Nayak, Alex Reimers, Nick Feamster, Russ Clark School of Computer Science Georgia Institute of Technology

2. Motivation • Enterprise and campus networks are dynamic • Hosts continually coming and leaving • Hosts may become infected • Today, access control is static, and poorly integrated with the network layer itself • Resonance:Dynamic access control • Track state of each host on the network • Update forwarding state of switches per host as these states change

3. State of the Art • Today’s networks have many components “bolted on” after the fact • Firewalls, VLANs, Web authentication portal, vulnerability scanner • Separate (and perhaps competing) devices for performing the following functions • Registration (based on MAC addresses) • Scanning • Filtering and rate limiting traffic

4. Authentication at GT : “START” 3. VLAN with Private IP 7. REBOOT Switch .1. New MAC Addr 2. VQP 6. VLAN with Public IP VMPS New Host 4. Web Authentication 5. Authentication and Scanning Result ta Web Portal, Scanner

5. Problems with Current Architecture • Access Control is too coarse-grained • Static, inflexible and prone to misconfigurations • Need to rely on VLANs to isolate infected machines • Cannot dynamically remap hosts to different portions of the network • Needs a DHCP request which for a windows user would mean a reboot • Monitoring is not continuous Idea: Express access control to incorporate network dynamics.

6. Resonance Methodology • Step 1: Associate each host with generic states and security classes • Step 2: Specify a state machine for moving machines from one state to the other • Step 3: Control forwarding state in switches based on the current state of each machine • Actions from other network elements, and distributed inference, can affect network state

7. Applying resonance to START Infection removed or manually fixed Quarantined Registration Failed Authentication Successful Authentication Still Infected after an update Operation Clean after update Authenticated Vulnerability detected

8. Resonance: Step by Step DHCP Server Web Portal Openflow Switch Controller 1. DHCP request 2. Web Authenticai- tion Internet 4. To the Internet 3. Scanning New Host

9. Preliminary Implementation: OpenFlow • OpenFlow: Flow-based control over the forwarding behavior of switches and routers • A switch, a centralized controller and end-hosts • Switches communicate with the controller through an open protocol over a secure channel • Why OpenFlow? • Dynamically change security policies • Central control enables • Specifying a single, centralized security policy • Coordinating the mechanisms for switches • Granularity of control. VLANs don’t provide that granularity

10. Resonance Controller: NOX • NOX: Programmatic interface to the OpenFlow controller • Ability to add, remove and reuse components • We are building the Resonance controller using NOX

11. Research Testbed

12. Potential Challenges • Scale • How many forwarding entries per switch? • OF switches support ~130K flow entries and 100 wildcard entries. • How much traffic at the controller? • Performance • Responsiveness • Security • MAC address spoofing • Securing the controller (and control framework)

13. Summary • Resonance: An architecture to secure and maintain enterprise networks. • Preliminary design • Application to Georgia Tech campus network • Planned evaluation • Many challenges remain • Scaling • Performance Questions?