1 / 23

The Protection Problem in Enterprise Networks

The Protection Problem in Enterprise Networks. Martin Casado PhD Student in Computer Science, Stanford University casado@cs.stanford.edu http://www.stanford.edu/~casado. Talk Focus. Negative affects of protection measures on edge networks Motivated by anecdotes from real networks

braden
Download Presentation

The Protection Problem in Enterprise Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Protection Problem in EnterpriseNetworks Martin Casado PhD Student in Computer Science, Stanford University casado@cs.stanford.edu http://www.stanford.edu/~casado

  2. Talk Focus • Negative affects of protection measures on edge networks • Motivated by anecdotes from real networks • Introduce Ethane

  3. Network Examples • National Lab, Small-moderate size business, academic, hospital • Security sensitive • More LAN than large routable network

  4. Problems Areas • Inflexibility • Loss of Redundancy • Filtering woes

  5. Problems • Inflexibility • Loss of Redundancy • Filtering Woes

  6. Inflexibility Firewall + Router L2 Switch • If one is compromised, can’t sniff traffic of others • Can’t enumerate how many hosts on network • Can only get “out” through proxy • Prevent rogue connections

  7. Inflexibility Firewall rulesACCEPT 192.168.1.20 Firewall + Router L2 Switch • If one is compromised, can’t sniff traffic of others • Can’t enumerate how many hosts on network • Can only get “out” through proxy • Prevent rogue connections

  8. Inflexibility Firewall rulesACCEPT 192.168.1.20 • Turn of ARP • Static ARP cache ca:fe:de:ad:be:ef 192.168.1.20 Firewall + Router L2 Switch • Turn of ARP • Static ARP cache • Ca:fe:d0:d0 192.168.1.1

  9. Inflexibility • No DHCP • Also insecure • Might undermine firewall rules • Might undermine static ARP cache Firewall rulesACCEPT 192.168.1.20 • Turn of ARP • Static ARP cache ca:fe:de:ad:be:ef 192.168.1.20 Firewall + Router • Turn of ARP • Static ARP cache • Ca:fe:d0:d0 192.168.1.1

  10. Inflexibility • No DHCP • Might undermine firewall rules • Might undermine static ARP cache Firewall rulesACCEPT 192.168.1.20 • Turn of ARP • Static ARP cache ca:fe:de:ad:be:ef 192.168.1.20 Firewall + Router • Port Security • Tie MAC address to Port ca:fe:de:ad:be:ef 192.168.1.20 L2 Switch • Turn of ARP • Static ARP cache • Ca:fe:d0:d0 192.168.1.1

  11. Inflexibility • Topology (ports, interfaces) and addresses sprinkled throughout configuration state • No distributed maintenance like routing tables • Difficult to move machines • Moving machines can be bad • Indirection points (e.g. ARP, DHCP) insecure(.. often removed) • MAC addresses everywhere • Chew up memory • No aggregation 

  12. Problems • Inflexibility • Loss of Redundancy • Filtering Woes

  13. Loss of Redundancy

  14. Loss of Redundancy • Easier to reason about/verify • Proxies are a catalyst • Distributed firewalls are not the solution • Lack of good support for L5 routing (does anyone have this turned on?) • Existing solutions exacerbate the problem • “do everything” proxies • Single bridge NACs

  15. Problems • Inflexibility • Loss of Redundancy • Filtering Woes

  16. Filtering Woes • Filtering done on the datapath today • Generally limited filtering state (so can have large forwarding tables) • Common problem is running out of ACLs • MAC addresses everywhere • Chew up memory • No aggregation  • In some networks, forwarding tables + filters doesn’t make sense ..

  17. Ethane: Towards a Solution • Centrally declare network policy • Authenticated end-hosts • Central-arbiter grants permission to connect on a per flow basis • Central-arbiter has fine grained control of routes

  18. Ethane martin.friends.ambient-streams Authenticatehi, I’m tal, my password is Publishmartin.friends.ambient-streamsallow tal, sundar, aditya First packet tomartin.friends.ambient-streams Authenticatehi, I’m martin, my password is Global Network Policy: (allow all martin using rtp)

  19. Ethane: Properties • Flexibility • Dynamic bindings are secure(movement is easy) • Security policy independent of topology • Redundancy • More switches != more configuration state • Fine grained control of routes allows L5 routing • Permission checks done on connection setup(taken off data path)

  20. Thanks! ?

  21. Isolation • Networks exist today with differing levels of sensitivity • Casino • Financial • Medical • Government/Military • Want reasonable Isolation • No DDoS from less secure to more • No data exfiltration from more secure to less • Note, VLANs generally insufficient This is not solely a governmentnetwork problem

  22. Today’s Solution (really) heavyweight,application proxy(cannonicalization + fuzzy timers) OR …

  23. Isolation Cont … • Obviously suboptimal • Management • Number of components (MTTF) • Could use same components, separate queues, TDM • Consolidation on the road-map for some very large networks

More Related