Transcript A Hands-On Environment for Teaching Networks

SANE: A Protection Architecture
for Enterprise Networks
Martin Casado (Stanford)
Tal Garfinkel
(Stanford)
Aditya Akella (CMU/Stanford)
Dan Boneh
(Stanford)
Nick McKeown (Stanford)
Scott Shenker (ICSI/Berkeley)
2005
Stanford and ICSI
Enterprise Security is
Important
 $8.7
billion information security industry (US
alone)
 Intellectual Property Protection
(Valve code leak)
 Downtimes
(Disney)
are costly
 User-information
leaks are bad
(California bill number: SB 1386)
 Regulatory
 HIPAA
 Sarbanes
2005
Compliance
Oxley
Stanford and ICSI
A Quick Look at IP
 Default
on: everyone can talk to everyone
 Trusted
end-hosts, “stupid network”
 Decentralized (trust)
 Loosely
 No
bound end-points
hiding of information
 Communicating
end points
 topology
Worms are a testimony to the success of IP!
2005
Stanford and ICSI
IP and Security
 Default
ON  overly permissive
(“every psychopath is your next-door neighbor” – Geer)
 trusted
end-points  powerful users/attackers
 Stupid network  no defense in depth
 Proliferation of TCB  1 router is enough
 weak end-points  useless for discrimination
 No hiding of info  reconnaissance is easy
2005
Stanford and ICSI
Retrofitting Security onto IP
 Designed
for Security
 Firewalls,
Router ACLS
 Port Security
 IDS/NDS/IPS
(scan detection, anomaly
detection, signature detection)
Transport
 VLANs
 Pushed
Into Service
 Ethernet
Switches
 NATs, Proxies
2005
Application
Network
Datalink
Physical
Stanford and ICSI
Policies and Protection in Enterprises

Connectivity is difficult to reason about

Network config = sum of router and end-host
configs

Hard to express meaningful policies

Enterprise networks are brittle


Difficult to deploy new protocols, define new
policies
Easy to break existing policies
Yet, existing mechanisms don’t provide adequate security!!
2005
Stanford and ICSI
Short Recap
 IP
networks
 Default
on
 No support in network
 Decentralized trust
 Loosely bound end-points
 Proliferation of information
 Exisiting
enterprise security technologies
 Many
 Complex
 Can’t
2005
declare policy simply
Stanford and ICSI
Our Approach: SANE
(Security Architecture for the Networked
Enterprise)
Take an extreme point in design space…
 Default
on  Default off
 Decentralized trust  centralized
 No network enforcement  enforced per hop
 Meaningless IPs  Tightly bound end-points
 Transparent information  restricted
2005
Stanford and ICSI
When Does this make
sense?
Security
is paramount
Practical deployment strategy
 Fork-lift
upgrades
 New networks created often
Centralized
administration
Notion of principles (e.g. users)
Structured communication
2005
Stanford and ICSI
Provide Isolation Layer
Ethernet
SANE
IP ..
Transport
Network
Datalink
Physical
Introduce layer 2.5
Isolation Layer
 Strictly
2005
Application
defines connectivity
Stanford and ICSI
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
allow
sundar,
hi, I’mtal,
martin,
myaditya
password is
1 4 3 4 4
Ambient streams
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
Ambient streams
1 3 1 2 2
2005
1 3 1 2 2
Client port
Client port
Stanford and ICSI
Ambient streams
1 3 1 2 2
Client port
•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)
•Validate
capabilities
Domain Controller
•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
2005
Stanford and ICSI
Security Properties (Saltzer and
Schroeder)

Default off (capabilities provide all connectivity)
(failsafe defaults, least privilege)

Single, simple mechanism
(economy of mechanism)

Capability checked at every step
(complete mediation)
Capabilities bind end-hosts to location
 High level policy declaration


Fine-grained policies
(psychological acceptability)

Don’t reveal (sender, packet path, topology)
(least knowledge)

Immutable transport address allows fine grained access
controls
2005
Stanford and ICSI
SANE Details
 How
is connectivity to the DC provided?
 How are keys established?
 How does the DC get the topology?
2005
Stanford and ICSI
Connectivity to the DC
 Switches
construct spanning tree
Rooted at DC
 Switches don’t learn topology
(just neighbors)
 Provides basic datagram service to DC
2005
Stanford and ICSI
Establishing Shared
Keys
 Switches
authenticate with DC
and establish symmetric key
 Ike2 for key establishment
K
 All subsequent packets to DC
have “authentication header”
Ksw4
sw1
(similar to ipsec esp header)
2005
Stanford and ICSI
Ksw1
Ksw2
Ksw3
Ksw4
Ksw3
Ksw2
Return Capabilities
 Added
to all packets to DC
 Each switch adds a “layer”
 Look the same as DC issued
capabilities
 Used by the DC to determine the
 Exact location of the sender
2005
Stanford and ICSI
payload
payload
payload
Establishing
Topology
generate neighbor lists
during MST algorithm
K
 Send encrypted neighbor-list
to DC
 DC aggregates to full topology
 No switch knows full topology
Ksw1
Ksw2
Ksw3
Ksw4
 Switches
Ksw4
sw1
2005
Stanford and ICSI
Ksw3
Ksw2
Summary of mechanism
 Default
connectivity to DC (via MST)
 All principles authenticate (switches, users)
 Users publish/request services from DC
 DC returns encrypted source route
 Provides
all host-to-host connectivity
 Opaque
 Non-composable
 Include
2005
transport address (fine-grained)
Stanford and ICSI
Additional Considerations
 Fault
Tolerance
“You’re not SANE you’re INSANE”
 Central
control!
 Loss of adaptive routing!
 Attack
resistance
 Data
integrity
 Revocation
 Wide
2005
area issues
Stanford and ICSI
Fault Tolerance:
Adaptive Routing
 On
failure, end-hosts must refresh capabilities
 Timeouts
 Can
to detect failures
result in “request storm” at DC
 Issue multiple capabilities
(hand out n of the k shortest paths)
 More switch level redundancy
(doesn’t undermine security!)
 Path load balancing
(randomly choose one of the k shortest paths)
2005
Stanford and ICSI
Fault Tolerance:
DC: Single Point of Failure?
 Exists
today (DNS)
 Capability generation is fast
(crummy implementation = 20k – 40k per second)
 Replicate
DC
 Computationally
(multiple servers)
 Topologically (multiple servers in multiple places)
2005
Stanford and ICSI
Attack Resistance
Capabilities





Onion-encrypted source routes
Encryption means, encrypt + MAC
Each “layer” using a secret key
shared by the DC and the switch
10 hops = 164 byte header
Contain



path information
Expiration
Unique ID
MAC
1,4
MAC
3,2
SW2
2
2
1
SW1
4
Esw1
MAC
2,1
MAC Service
Esw2
2005
1
3
Stanford and ICSI
port
CAP-ID Expiration
Attack Resistance:
And More Security!
 Intermediary
data integrity checks
 Hiding switch IDs in authentication header
 Handling growth of trusted computing base using
threshold crypto
(n of k DCs must be compromised to
generate capabilities)
2005
Stanford and ICSI
Attack Resistance:
Revocation
 Request
from DC
 sent back along incoming path
 Switches maintain small CAMs
 If CAMs fill, switches generate new keys
 too many revocations = loose privileges
payload
2005
Stanford and ICSI
Wide Area Issues
 IP
Is used for
 Wide
area routing
 Common framing (compatibility between end hosts)
 In
Enterprise Doesn’t provide
 Identification
 Location
 Local
connectivity
 Internet
connectivity provided by gateway
(similar to NAT)
2005
Stanford and ICSI
Implementation
 All
components implemented in software
 Integrated with 9 workstations
 Managed our group’s traffic for a couple of weeks
2005
Stanford and ICSI
Future Work
 Research
connectivity in the enterprise
 Real implementation with hardware switches
 Extend to multiple domain case
 Plug into existing directory services (AD, LDAP)
 Use DC as a KDC (a la kerberos)
2005
Stanford and ICSI
Questions?
2005
Stanford and ICSI
Properties: Revisited
 Least
Privilege
(only given resources necessary)
 Failsafe
Defaults
(can only talk to DC by default)
 Least
Mechanism
(capabilities provide all connectivity)
 Psychological
acceptability
(access controls use high level contructs)
 Least


Knowledge
Don’t know who’s communicating
Don’t know topology
2005
Stanford and ICSI
Service Model
 Users
authenticate with DC
 Users publish services and
access controls
 Users request capabilities for
services
 User positions on topology
taken from return capabilities
2005
Stanford and ICSI
friends.ambient-streams
allow tal, sundar, aditya
Connectivity to the DC
 Switches
construct spanning tree
Rooted at DC
 Switches don’t learn topology
payload
(just neighbors)
 Provides basic datagram service to DC
2005
Stanford and ICSI
payload
payload
Talk Overview
 Protection
and IP
 The sad state of (current) affairs
 Our proposal
2005
Stanford and ICSI
motivation:
IP vs. Security

Abstractly

Violates least privilege(Saltzer and Schroeder)
Violates failsafe defaults(Saltzer and Schroeder)
Violates complete mediation(Saltzer and Schroeder)
Violates least knowledge

IP addresses useless for enforcing security policy



Concretely
●
●

Routers have tremendous power
●
●

2005
Can represent one or more hosts (NAT, DHCP)
Or none at all (address forging)
Often know full inter-domain topology
Trusted to generate topology
No notion of isolation or access controls in the network
Stanford and ICSI
What to Do?
2005
Stanford and ICSI
Policies and Protection in
Enterprises

Connectivity is difficult to reason about

Network configuration a sum of router and end-host configs
Hard to express meaningful security policies
 Enterprise networks are brittle




Difficult to deploy new protocols, define new policies
Easy to break existing policy
Yet, existing mechanisms don’t provide adequate security
2005
Stanford and ICSI
The Basics
Three SANE packet types
 HELLO: emitted by each switch to gather neighbor list
(link state) and build spanning tree
 DC: packets destined to the DC
 FORWARD: capability routed packets between end hosts

HELLO
DC
payload
Capability Authentication
FORWARD Capability
2005
payload
payload
Stanford and ICSI
The Secure Architecture for
the Networked Enterprise
(SANE)
 Add
“isolation layer” (layer 2.5, like VLAN)
Ethernet
 Consists
SANE
of centrally issued, encrypted source
routes
 Source routes
 Provide
all connectivity
 Are Opaque
 Are Non-composable
 Include transport addresses
2005
IP ..
Stanford and ICSI
Our Approach: Start from
Scratch
 Secure
network architecture by design
 Leverage characteristics unique to Enterprise
 Default off (failsafe defaults)
 Simple (least mechanism)
 Provide minimum resources necessary (least privilege)
 Declare security policy using high level statements
(tal can access martin.streams.ambient)
(psychological acceptability)
 Enforce
2005
security at the lowest level
Stanford and ICSI
SANE:
But, but, but ……
 How
are capabilities constructed?
 How is connectivity to the DC provided?
 How does the DC get the topology?
 What happens on network failure?
 “You’re
not SANE you’re INSANE”
 Central
control!
 Loss of adaptive routing!
2005
Stanford and ICSI
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
allow
sundar,
hi, I’mtal,
martin,
myaditya
password is
1
1
4
3
4
4
1
3
1
2
2
4
3
4
3
1
2
1
4
2
Ambient-streams
Tal’s client port
Ambient-streams
2
Tal’s
1 client
3 port1
4
2
1
2005
3
3
4
1
4
3
1
2
2
4
4
Ambient-streams
2
2
Tal’s client port
1
4
3 4
1
3
1
Ambient-streams
3
Ambient-streams
1
2
2
Tal’s client port
Tal’s client port
Stanford and ICSI
Ambient-streams
2
4 1
2
Tal’s client port