Martin Casado Stanford

1
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)

2
Enterprise Security is Important

• 8.7 billion information security industry (US
  alone)
• Intellectual Property Protection(Valve code
  leak)
• Downtimes are costly(Disney)
• User-information leaks are bad(California bill
  number SB 1386)
• Regulatory Compliance
• HIPAA
• Sarbanes Oxley

3
A Quick Look at IP

• Default on everyone can talk to everyone
• Trusted end-hosts, stupid network
• Decentralized (trust)
• Loosely bound end-points
• No hiding of information
• Communicating end points
• topology
• Worms are a testimony to the success of IP!

4
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

5
Retrofitting Security onto IP

• Designed for Security
• Firewalls, Router ACLS
• Port Security
• IDS/NDS/IPS (scan detection, anomaly detection,
  signature detection)
• VLANs
• Pushed Into Service
• Ethernet Switches
• NATs, Proxies

Application
Transport
Network
Datalink
Physical
6
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 dont provide adequate
security!!
7
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
• Cant declare policy simply

8
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

9
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

10
Provide Isolation Layer
Application
Transport
Introduce layer 2.5Isolation Layer
Network
Datalink
Physical

• Strictly defines connectivity

11
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
12

• 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
13
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)
• Dont reveal (sender, packet path,
  topology)(least knowledge)
• Immutable transport address allows fine grained
  access controls

14
SANE Details

• How is connectivity to the DC provided?
• How are keys established?
• How does the DC get the topology?

15
Connectivity to the DC

• Switches construct spanning tree
• Rooted at DC
• Switches dont learn topology(just neighbors)
• Provides basic datagram service to DC

16
Establishing Shared Keys

• Switches authenticate with DCand establish
  symmetric key
• Ike2 for key establishment
• All subsequent packets to DC have
  authentication header(similar to ipsec esp
  header)

17
Return Capabilities

• Added to all packets to DC
• Each switch adds a layer
• Look the same as DC issuedcapabilities
• Used by the DC to determine the
• Exact location of the sender

18
Establishing Topology

• Switches generate neighbor listsduring MST
  algorithm
• Send encrypted neighbor-listto DC
• DC aggregates to full topology
• No switch knows full topology

19
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 transport address (fine-grained)

20
Additional Considerations

• Fault ToleranceYoure not SANE youre INSANE
• Central control!
• Loss of adaptive routing!
• Attack resistance
• Data integrity
• Revocation
• Wide area issues

21
Fault ToleranceAdaptive Routing

• On failure, end-hosts must refresh capabilities
• Timeouts to detect failures
• Can result in request storm at DC
• Issue multiple capabilities(hand out n of the k
  shortest paths)
• More switch level redundancy(doesnt undermine
  security!)
• Path load balancing(randomly choose one of the k
  shortest paths)

22
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)

23
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

SW2
3
1
2
2
SW1
1
4
Esw1
1,4
MAC
CAP-ID
Expiration
3,2
MAC
2,1
MAC
Service port
MAC
Esw2
24
Attack Resistance And More Security!

• Intermediary data integrity checks
• Hiding switch IDs in authentication header
• Handling growth of trusted computing base
  usingthreshold crypto(n of k DCs must be
  compromised to generate capabilities)

25
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

26
Wide Area Issues

• IP Is used for
• Wide area routing
• Common framing (compatibility between end hosts)
• In Enterprise Doesnt provide
• Identification
• Location
• Local connectivity
• Internet connectivity provided by gateway
  (similar to NAT)

27
Implementation

• All components implemented in software
• Integrated with 9 workstations
• Managed our groups traffic for a couple of weeks

28
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)

29
Questions?
30
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
• Dont know whos communicating
• Dont know topology

31
Service Model
friends.ambient-streamsallow tal, sundar, aditya

• Users authenticate with DC
• Users publish services andaccess controls
• Users request capabilities forservices
• User positions on topologytaken from return
  capabilities

32
Connectivity to the DC

• Switches construct spanning tree
• Rooted at DC
• Switches dont learn topology(just neighbors)
• Provides basic datagram service to DC

33
Talk Overview

• Protection and IP
• The sad state of (current) affairs
• Our proposal

34
motivationIP vs. Security

• Abstractly
• Violates least privilege(Saltzer and Schroeder)
• Violates failsafe defaults(Saltzer and Schroeder)
• Violates complete mediation(Saltzer and
  Schroeder)
• Violates least knowledge
• Concretely
• IP addresses useless for enforcing security
  policy
• Can represent one or more hosts (NAT, DHCP)
• Or none at all (address forging)
• Routers have tremendous power
• Often know full inter-domain topology
• Trusted to generate topology
• No notion of isolation or access controls in the
  network

35
What to Do?
36
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 dont provide adequate
  security

37
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
payload
DC
Capability
Authentication
payload
FORWARD
Capability
payload
38
The Secure Architecture for the Networked
Enterprise (SANE)

• Add isolation layer (layer 2.5, like VLAN)
• Consists of centrally issued, encrypted source
  routes
• Source routes
• Provide all connectivity
• Are Opaque
• Are Non-composable
• Include transport addresses

Ethernet
SANE
IP ..
39
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 security at the lowest level

40
SANEBut, 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?
• Youre not SANE youre INSANE
• Central control!
• Loss of adaptive routing!

41
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
Ambient-streams
4
4
3
3
2
4
1