Transcript Presented

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
Topic # 1
1
Security Concerns in the Enterprise
• Current security solutions try to retrofit access
control into a permissive network
– ACL’s, 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
Topic # 2
2
Overview
• What’s 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
Topic # 3
3
What’s 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!
Topic # 4
4
What’s 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.
Topic # 4
5
What’s 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.
Topic # 4
6
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
Topic # 5
7
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
Topic # 5
8
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.
Topic # 5
9
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
Topic # 5
10
Slide borrowed from http://yuba.stanford.edu/~casado/sane.ppt)
Provide Isolation Layer
Ethernet SANE
Application
IP ..
Transport
Network
Datalink
Physical
Introduce layer 2.5
Isolation Layer
• Strictly defines connectivity
Topic # 5
11
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 capability’s
forward route.
Topic # 5
12
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)
Topic # 5
13
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 IPsec’s ESP
header.
Topic # 5
14
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.
Topic # 5
15
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
Topic # 5
16
Slide borrowed from
http://yuba.stanford.edu/~casado/sane.ppt)
SANE:
Action Sequence!
martin.friends.ambient-streams
Authenticate
Publish
Request
hi, I’m tal, my password is
martin.friends.ambient-streams
Authenticate
martin.friends.ambient-streams
1 4 3 4
4
Ambient streams
allow
sundar,
hi, I’mtal,
martin,
myaditya
password is
4 13 4 4
3 1 2 2 Ambient streams 4 4
Ambient streams
Client port
1 31 1 22
2 Client port 1 3 1 2 2
Client port
1
4
4
2
3
3
4 1
3 4 4
4
Ambient streams
1 3 1 2
2
Ambient streams
1 3 1 2
2
Client port
Topic # 5
Ambient streams
1 3 1 2
2
Client port
Client port
17
•Send link state information to
the DC
•Publish services at the•Provide
DC
default connectivity to
•Specify access controls
the DC
(export streams.ambient
allow tal)
Domain Controller •Validate capabilities
•Request access to services
•Forward packets base on
•Use appropriate capability
for each packet
capability
•Authenticates
switches/end•Enforce revocations
hosts
•Established secret with each
switch
Switches
•Contains network topology
•Hosts services (by name)
•Manages permission checking
•Creates and issues capabilities
SANE:
Overview
End-Hosts
Slide borrowed from
http://yuba.stanford.edu/~casado/sane.ppt)
Topic # 5
18
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
Topic # 5
19
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
Topic # 5
20
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
Topic # 5
21
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.
Topic # 5
22
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
Topic # 5
23
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
Topic # 5
24
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
Topic # 5
25
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
Topic # 5
26
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
Topic # 6
27
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
Topic # 6
28
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
Topic # 6
29
Evaluation
• The DNS and TCP request rates provide an estimate for
DC requests by end hosts in a SANE network – the peak
rate was < 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
Topic # 7
30
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.
Topic # 7
31
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
Topic # 8
32
Related Work
• Expanding the Link Layer
– Replacement of MST based forwarding with a linkstate 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)
Topic # 8
33
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!
Topic # 9
34
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
Topic # 10
35
Questions?
Topic #
36