CS 736 – Spring 2006
Lecture 28: Midterm Review
- Performance
- Papers:
i. LFS
ii. NFS
iii. AFS
iv. Frangipani / Petal
- General Problems
i. Latency: do things faster
1. E.g. RPC turn around
ii. Throughput
1. Handle more requests/operations per second
iii. Scale out: run on bigger data sets on more machines
1. Handle more data on more computers / faster computers
2. Run well on a cluster with a billion clients
- General Solutions
d. Locality
i. LFS logs
e. Partitioning – distribute load to multiple servers
i. AFS
ii. Petal
iii. Frangipani
f. Replication – more read throughput
i. AFS
ii. Petal
g. Caching
i. AFS
ii. NFS
h. Change data structures
i. Logging in LFS, Petal, Frangipani
ii. Message lists in Grapevine
i. Batching – reduce startup costs
i. Delayed write / group commit in LFS / Frangipani, NFS
j. Idempotent operations / stateless operation
i. NFS everything
k. Callbacks / leases – reduce server load
i. AFS
ii. Frangipani
l. Move work to client
i. AFS name translation
m. Notifications – notify other participant of semantically interesting events
i. AFS callbacks, Petal locks
n. Delay work
i. LFS – segment cleaning
o. Multi-level policy
i. Petal global / physical maps
- Reliability
- General design principles
1. QUESTIONS: Why? What if you donŐt have this?
ii. Error confinement
iii. Failure Detection
iv. Reconfiguration / recovery
- Failure Models
i. Timing – miss a deadline
ii. Output – produce incorrect output
iii. Omission – skip an output
iv. Crash – skip an output, produce no more output
v. Byzantine
1. Anything can happen, including malicious behaviors
- General Approaches
i. Fault Avoidance
1. Prevention: make sure bugs never enter code
2. Removal: Remove bugs from existing programs
3. Work-around
a. Fire walls
ii. Fault Tolerance
1. Redundancy – execute multiple times
2. Diversity: multiple versions for deterministic bugs. Can also be diverse environment (change how memory allocated, scheduling works)
3. Isolation: confine errors to a single component
4. Modularity: keep components small
5. Error detection: why important if have isolation?
a. A: Needed for availability if doing wrong things
6. Recovery
a. Forwards / Backwards
b. Concealing / revealing
iii. Where do you provide fault tolerance
a. In the application?
b. In a library
c. In the OS
d. Around a component (e.g. Nooks)
e. In the HW
2. If everything above layer X is identical, can tolerate faults at X or below automatically
a. E.g. FT unix -> HW, OS faults
b. E.g. Hypervisor -> HW faults
c. E.g. Nooks -> driver faults (everything else is above)
d. E.g. Disco -> OS faults
3. If have some diversity above X, can tolerate heisenbugs above layer X
a. Process pairs – execute different streams
b. Checkpoint / restart: if restart far enough back
4. If have diversity, can tolerate bohrbugs above layer X
- Security
- Key threats:
i. Privacy – uncontrolled release of sensitive information
ii. Integrity – uncontrolled change to sensitive information
iii. Denial of service – uncontrolled prevention of service
iv. QUESTION: How does subverting a web site or taking over a machine and using it to DDOS a server count?
- Basic approach
i. Guard enforcing access control : impenetrable wall with a door
ii. Authorization check : guard demands something it can check against its database
iii. Protected information
iv. Decision procedure
v. SIMPLEST solution: complete isolation
1. Reject everything
2. QUESTION: what makes security hard? Limited sharing / communication
- Design principles: What does it mean, why important? What if donŐt have? Examples?
i. Economy of mechanism
ii. Fail-safe defaults
iii. Complete mediation
iv. Open design
v. Separation of privilege
vi. Least privilege
vii. Least common mechanism
1. Minimize attack surface
viii. Psychological acceptability
ix. Work factor
x. Auditing + police can replace tight controls
xi. Defense in depth
xii. Assume malicious inputs
- Systems
i. Needham and Schroeder
1. Secret Key vs. Public key
2. On-line vs off-line
3. QUESTION: When use secret key?
a. When humans need to remember a key
b. When servers have little power
4. QUESTION: When use public key
a. When have a can distribute certificates out-of-band (e.g. with browser / OS)
b. When no simple trust relationship
5. QUESTION: How handle authentication between realms / domains?
a. Referrals
b. Certificate chains
ii. Kerberos
1. Protocols
a. AS, TGS, AP protocols
b. Time stamps
c. Authenticators
d. Sign / seal/ connection security
2. User keys vs. server keys
iii. Terra
1. QUESTION: What does it provide?
a. Assurance of what SW running on a remote computer
b. How provided? Each layer acts as AS for next upper layer, signs key + certificate
c. Remote system can verify certificate chain
2. QUESTION: What problems can it solve>?
a. Spyware?
b. Gaming?
c. Password sniffing terminals?
iv. Philosophy
1. Economics
a. Who has the benefit, attacker or defender?
b. How can risk be reduced?
c. How can security be used to an advantage other than to reduce likelihood of attack
i. DRM / Terra: lock-in
d. How would insurance improve security of systems?
i. Expose cost of unlikely events , mgmt practices
ii.