SANE: A Protection Architecture for Enterprise Networks

1
SANE A Protection Architecture for Enterprise
Networks

• Authors Martin Casado, Tal Garfinkel, Aditya
  Akella, Michael J. Freedman
• Dan Boneh, Nick McKeown, Scott Shenker
• Presented by Michael Haggerty

2
Security Concerns in the Enterprise

• Current security solutions try to retrofit access
  control into a permissive network
• ACLs, packet filters and other middleboxes
• SANE a single protection layer that governs all
  connectivity in the enterprise
• Uses a centralized solution to grant access to
  services

3
Overview

• Whats wrong with existing technology
• Security Architecture for the Networked
  Enterprise (SANE)
• Domain Controller
• Point to Point Communications
• Interoperability
• Fault Tolerance
• Additional Features
• Attack Resistance
• Resource Exhaustion
• Can SANE handle the overhead?
• Related work
• My Opinion
• Conclusion

4
Whats wrong with existing technology?

• Complexity of Mechanism
• Security policy is distributed among VLANs, ACLs,
  firewalls, NATs, ect.
• Configuration is complex
• Based on address and physical ports rather than
  authenticated end points
• When a small change occurs it can require complex
  reconfiguring
• Common response it to secure at one point
  (firewall)
• SANE allows high level policies to be expressed
  centrally policies are enforces and configured
  by a single source!

5
Whats wrong with existing technology?

• Proliferation of trust
• Switches and routers must correctly export link
  state, calculate routes and perform filtering
• Overtime these functions have become more complex
  leading to more vulnerabilities.
• SANE proposed to replace this with simple,
  minimally trusted forwarding elements in order to
  reduce the number of trusted elements to one
  centrally managed controller.

6
Whats wrong with existing technology?

• Proliferation of Information
• Topology information is easy to gather in
  enterprise networks
• Switches and routers will routinely broadcast
  information about topology in plaintext (OSPF)
• Ping (traceroute) and ARP scans, port scanning
  and SNMP
• Filtering ICMP and changing SNMP passphrases are
  common defenses
• SANE hides the network structure as well as the
  location of critical services and hosts from
  unauthorized network entities.

7
SANE

• SANE seeks to provide protection robust enough
  for government, military and financial networks
• Robust means protection from insider
  (authenticated uses and switches) and
  outsider(unauthorized user plug into the network)
  threats.
• SANE works in the enterprise
• Enterprise networks are carefully planned and
  centrally manages
• Most hosts are clients connecting to predictable
  services (mail, file and print, HTTP proxies or
  ssh gateways).
• Most clients are already authenticated via LDAP
  or Active Directory
• Able to quickly adopt new protection architecture

8
SANE

• Domain Controller (DC)
• Central component of the SANE network and is
  responsible for
• Authenticating users and hosts
• Advertising available services
• Deciding who can connect to these services
• Allows hosts to communicate by handing out
  capabilities

9
SANE

• The DC performs 3 main functions
• Authentication Service
• Authenticates principles and switches
• Maintains symmetric keys with each for secure
  communication
• Network Service Directory (NSD)
• Replacement for DNS (each service has a unique
  name)
• Maintains an Access Control List (ACL) for each
  service
• When a principal wants to access a service it
  looks it up in the NSD and returns a capability
  if it is allowed to access it.

10
SANE

• The DC provides 3 main functions (continued)
• Protection Layer Controller
• Responsible for generating, maintaining and
  revoking capabilities
• A capability is a switch-level source route from
  the client to a server
• Encrypted in layers to prove they originated from
  DC and to hide topology
• Keeps a complete view of the topology
• Adapt the network when things go wrong

11
Provide Isolation Layer
Slide borrowed from http//yuba.stanford.edu/casa
do/sane.ppt)
Application
Transport
Introduce layer 2.5Isolation Layer
Network
Datalink
Physical

• Strictly defines connectivity

12
Packet types in a SANE network

• HELLO packets are used for immediate neighbor
  discovery and thus are never forwarded.
• DC packets are used by end hosts and switches to
  communicate with the DC they are forwarded by
  switches to the DC along a default route.
• FORWARD packets are used for most host-to-host
  data transmissions they include an encrypted
  source route (capability) which tells switches
  where to forward the packet.
• REVOKE packets revoke a capability before its
  normal expiration they are forwarded back along
  a capabilitys forward route.

13
SANE Communication with the DC

• SANE builds a minimum spanning tree with the DC
  as root using HELLO packets
• No switch learns the entire topology just their
  neighbors
• The spanning tree is only used to establish
  default routes for forwarding packets to the DC
  (DC packets)

14
SANE Communication with the DC(continued)

• Switches authenticate with DC and establish
  symmetric key
• IKE2 used for key exchange
• Keys used to establish confidentiality, integrity
  and replay defense with the DC via an
  authentication header similar to IPsecs ESP
  header.

15
SANE Communication with the DC(continued)

• All capability requests and link state requests
  traverse the MST.
• As the DC packet traverses the MST a request
  capability is generated as an encrypted onion
  packet (containing the previous and next hop)
• DC uses these requests to communicate back to the
  sender, to learn about the topology and identify
  misbehaving senders.

16
SANE Point to Point Communications

• Server publishes service under a unique name to
  the DC
• Client communicates with DC to authenticate and
  obtain capability
• DC communicates network path to client
• Client communicates with server via capability
  communicated from DC

17
Slide borrowed from http//yuba.stanford.edu/casa
do/sane.ppt)
SANEAction Sequence!
Publishmartin.friends.ambient-streamsallow tal,
sundar, aditya
Authenticatehi, Im tal, my password is
martin.friends.ambient-streams
Requestmartin.friends.ambient-streams
Authenticatehi, Im martin, my password is
1
2
1
4
4
3
3
2
4
1
18

• Send link state information to the DC
• Provide default connectivity to the DC
• Validate capabilities
• Forward packets base on capability
• Enforce revocations

SANEOverview

• Publish services at the DC
• Specify access controls(export streams.ambient
  allow tal)
• Request access to services
• Use appropriate capability for each packet

Domain Controller

• Authenticates switches/end-hosts
• Established secret with each switch
• Contains network topology
• Hosts services (by name)
• Manages permission checking
• Creates and issues capabilities

Switches
End-Hosts
Slide borrowed from http//yuba.stanford.edu/casa
do/sane.ppt)
19
SANE Revoking Access

• A DC can revoke a capability
• A client can report a misbehaving sender for a
  misused capability
• How?
• Victim sends a revocation request
• DC verifies that the requester is on the
  capabilities path
• DC returns a signed packet of type REVOKE
• If a switch receives traffic from a revoked
  capability it will silently drop the traffic

20
Interoperability with non SANE network components

• Translation proxies translate between IP naming
  events and SANE events. (ie map DNS requests to
  DC service lookups)
• Gateways provide service similar to a NATs.
  Position on the perimeter to allow for
  connectivity to the wide area.
• Broadcast link layer broadcasts are forwarded
  to the DC and the DC will reply

21
Fault Tolerance Can a centralized solution be
feasible?

• Replicating the DC
• The DC is logically centralized this does not
  mean it has to be physically centralized!
• Have a MST rooted to each DC
• Distributed Load
• Recovering from network failure
• It is the end hosts responsibility to detect
  network failure.
• Switches to end host communication is not allowed
  and would allow for more DoS attack paths
• End host will communicate failure to DC which
  will issue new capabilities to end host

22
Additional Features

• Middleboxes and Proxies Traditionally proxies
  are placed at choke points. In a SANE network
  proxies can be placed anywhere and the DC can
  insure that traffic passes through them
• Mobility When a client changes access points it
  can request a new capability and REVOKE its old
  one.
• Anti-Mobility SANE can prevent hosts and
  switches from moving by disallowing access if
  they do
• Centralized logging The DC is an ideal place
  for network wide communications logging.

23
Attack Resistance

• Access Control Lists (ACLs)
• The NSD uses ACLs for directories, preventing
  attackers from enumerating services. This will
  prevent an attacker from discovering a particular
  application which may have a known vulnerability.
• Encrypted Source Routes and Link-State Updates
• Prevent attackers from learning the topology or
  enumerating services
• Authenticated Network Components
• Authenticated switches cannot lie about their
  connectivity or create arbitrary links. Spanning
  tree and routing attacks are thwarted due to the
  DCs centralized control

24
Resource Exhaustion

• Flooding Flooding attacks are handled through
  revocation. Rate-limits for capabilities
  requests DC tell neighbors to disconnect it if
  limits are violated
• Revocation State Exhaustion SANE switches must
  keep a list of revoked capabilities. An attacker
  might try to fill the list up by dumping a huge
  list of revoked capabilities at one.
• If revocation lists fills the switch dumps and
  reloads
• DC tracks number of revocations per sender
  sender can be removed from ACLs if sends to many
  REVOKEs

25
Handling Malicious Switches

• Switches have minimal functionality in SANE but
  could potentially sabotage by
• Falsely advertising a smaller distance during MST
  build, which would cause additional DC traffic to
  flow through it.
• Start dropping packets degrading service
• Attract traffic by falsifying link-state updates
  colluding nodes can attract traffic without
  detection SANE avoids this by requiring
  switches to authenticate

26
Handling Malicious DCs

• DCs are highly trusted entities in SANE a
  compromise of the DC can hand total control to an
  attacker
• This can be avoided by replication of the DC and
  distributing the trust among several DCs
• Spread cryptographic responsibility so that 2 or
  more DCs are required to issue a capability
• An attacker gains no advantage by taking only 1
  DC
• DC synchronization is an issue SANE uses
  standard Byzantine agreement protocols

27
Taking SANE for a Test Drive

• Interconnected hosts on a 100Mbps Ethernet
• Had to change MTU size to 1300 bytes on hosts to
  provide room for SANE headers. (only change)
• DCs preloaded with public keys of the switches
• Capabilities use 8b, switch IDs 32b, service IDs
  16b, innermost layer uses 24B and each additional
  layer uses 14B 10 switch limit need 164B for
  SANE header

28
Taking SANE for a Test Drive

• Client looking for HTTP would be directed to the
  DC for authentication (until user authenticates
  all request to DNS are routed to the DC via a
  translation proxy)
• Once user is authenticated the translation proxy
  would handle requests and grant capabilities to
  the end user

29
Evaluation

• Goal to show that SANE can fit into an
  enterprise network and can handle the workload
• DC was able to issue 40,000 capabilities at worst
  over 10 hops
• Switches were able to saturate 100Mbps networks
  up to 10 hops
• Data collected from Lawrence Berkley National Lab
  for 34 hours in Jan 2005.
• 47 million packets collected 20,849 DNS request
  and 145,577 TCP connections

30
Evaluation

• The DNS and TCP request rates provide an estimate
  for DC requests by end hosts in a SANE network
  the peak rate was lt 200/sec
• 200 times lower than what unoptimized worst case
  DC could handle using a 10 hop network
• Concurrent TCP connection peaked at 1111 median
  was 27. At worst case the DC can handle 40 time
  more request during a network link failure.
• Packet carrying the forward and return
  capabilities would be at most 0.4KB in size
  adding a maximum of 0.646Mbps of control traffic

31
Results

• Only a few DCs would be needed on a network with
  tens of thousands of hosts
• DC replication is probably more relevant to
  ensure uninterrupted service in the event of DC
  failure.

32
Related Work

• Network Protection Mechanisms
• Firewalls protection of network perimeters
• Distributed Firewalls are similar to SANE
• Dealing with Router Complexity
• Routers can make firewalls irrelevant by routing
  around them
• 4D Architecture (Rexford) routing should be
  separate from forwarding and policies should be
  centralized

33
Related Work

• Expanding the Link Layer
• Replacement of MST based forwarding with a
  link-state forwarding
• Using a Directory Service instead of ARP
• Capabilities for DDoS Prevention
• Using network enforced capabilities on the WAN
• Unlike SANE capabilities are built on-route (no
  central control)

34
My Opinion

• Proposed solution is lacking
• No comparison to Directory based Network
  Operation Systems (NOS) currently available
• Microsoft Active Directory
• Novell Directory Services
• Does not adequately show how SANE is better than
  existing models
• Experiments show that SANE can fit into a network
  but do not show that it makes a network more
  secure!

35
Conclusion

• SANE adds a layer to the network stack
• Centralized control via Domain Controllers that
  use cryptography to authenticate all switches,
  users and servers.
• ACLs used to issue capabilities and routing paths
• Onion Layering hides Network Topology

36
Questions?