Transcript EE 122: Introduction To Communication Networks

Designing the Internet
in 90 Minutes!
EE 122: Intro to Communication Networks
Fall 2010 (MW 4-5:30 in 101 Barker)
Scott Shenker
TAs: Sameer Agarwal, Sara Alspaugh, Igor Ganichev, Prayag Narula
http://inst.eecs.berkeley.edu/~ee122/
Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxson
and other colleagues at Princeton and UC Berkeley
1
News
• Project will be released today
• Ask a TA if something isn’t clear
• Igor has an announcement
2
Goal for Today
• Discuss some basic design decisions
– Propose some possible designs
• This is not about how the current Internet works
• This is about how you think it should work
– With a little help from me…..
3
Process
• I’ll ask lots of questions
• Sometimes I’ll wait for answers, sometimes not
– Not always the same people answering questions
– I may call on names from class list
 Not punitive, just trying to get your head in the game
• But no matter what, think about the question!
– Otherwise we are both wasting our time….
4
Why This Lecture? (which is risky)
• Textbook stresses mechanisms
– Design of IP, TCP, BGP, DNS etc.
• But does not discuss many alternatives
• Only by considering alternatives can one
understand what we have today
5
Basic Scenario
• Alice wants to retrieve a movie from the Internet
– Legally, of course
• Alice is sitting a host A
• Content on a variety of hosts around the Internet
6
Packets vs Circuits?
• Which kind of network should we use?
7
Host Software
• What is the structure of software on Alice’s laptop?
• Do applications interact directly with the network?
– Or is there a common interface?
• Possible organization
– Application
– “Stack”
– Network interface
• Two interfaces: application/stack, host/net
8
Service Model
• What service model does the network offer?
– Reliable?
– Assurances about delay?
– Multiple priorities?
• What service model does the API offer?
– Reliable?
– Assurances about delay?
– Multiple priorities?
• Who is responsible for reliability? Host or
Network?
9
API
• What does the application tell the “stack”
– Contact that host?
– Get this data?
• Do all applications want the same API?
– Should SSH and HTTP use the same API?
– What about streaming video?
• Can the API ever change? Should it be
extensible?
10
• Whatever the API, it needs to name hosts, data,…
Name Resolution
• What should name resolution tell you?
– Where a nearby copy of the name is
• Two approaches:
– Lookup in database
– Route-by-name
• Need an infrastructure that:
– Finds shortest paths
– Handles failures
– Scales
• Isn’t this a job for routing?
11
Name Resolution (continued)
• How does name resolution know about objects?
• Objects must be “registered”
• What prevents false registrations?
• Need to “verify” names
– How can I prove that this file’s name is X?
12
Naming (next six slides confusing)
• What gets named?
– Hosts?
– Data?
– People?
• What properties must a name have?
– Globally unique
– Persistent
– Verifiable
• What does a name tell you?
– Location? Anything else that might change?
13
Key Observation
• Names should be verifiable!
• And contain no other information
• What about today’s names?
– Exactly the opposite!
14
Principles about Naming Principals
• Principals are “responsible entities”
– Locus of trust
– Person, company
– Not files, etc.
• Principals can name objects
– Files, hosts, etc.
– Think of object names as P:L
(ex.: CNN:headlines)
• What should a name tell you?
– Principal: allows me to prove my name belongs to me
– Object: allows me to prove the object belongs to me
15
Identity
• What does Internet identity mean?
– Not a semantic statement
– Merely one of consistency
• Cryptographic notion of identity
– Associate each identity with a public key
– Can prove you are associated with that key by signing
with private key
• How do you tie names to public keys?
– Make names a hash of a key!
– This makes them verifiable
16
Attaching Meaning to Names
• Outside of architecture
– Why?
• Mechanisms to attach semantics to names:
– Certificate authorities
– Trusted databases
– Webs of trust
– Social networks
– …….
17
Phishing
• The key to dealing with phishing is to allow users
to verify identity
• How could we do this?
• I have no idea.
– But linking names to keys is a good start
– And depriving users of “human-readability” avoids
common errors
18
Back to API
• Should ask for content by name
• Let network figure out where closest copy is
– Through name resolution (route by name)
• Why not do it like today?
– App gets address
– Connects to address
• This forces application to know about addresses
19
Design so far (not like today’s net)
• Host Software:
– Application talks to stack through extensible API
– Stack talks to network
– Network service model: best-effort datagram delivery
– Applications refer to objects by name
 Do not know anything about low-level addresses, etc.
• Naming
– Names are “semantic-free” (not tied to location)
– They are cryptographically linked to principal
– Everything that you refer to is named directly
• Identity is tied to public key
20
Design so far (continued)
• Name resolution:
– Route-by-name to location
– Can ask for content directly
21
Security and Network Security
• What is network security?
– What aspects does the “network” have to handle?
– What about viruses?
• Minimal definition of network security
– Confidentiality: end-to-end encryption
– Integrity: end-to-end cryptography
– Provenance: end-to-end cryptography
 This is easy due to names being linked to keys
– Availability: huh?
• Everything else is host or application security…… 22
Carrying the packets
• After packet leaves host, what happens?
• What does the packet header carry?
– Destination?
– Source? Why? What about privacy?
23
Addressing
• How do you describe network locations?
• Network is comprised of “domains”
• Interdomain routing can just be done on domain
– Can ignore everything else until it arrives in domain
– Can make domains hierarchical
• Should interdomain routing know about internal
addressing?
• Result:
– Addresses that look like Domain:LocalAddress
– Back to the Future!
24
Interdomain Routing
• What freedom should domains have?
– Ability to decide which peers to route to
• How to embed that in routing algorithm?
– Cover later in semester
25
Intradomain Routing
• How do you compute routes?
– Shortest path? Highest bandwidth path?....
• What happens when there is a failure?
– How do you restore connectivity?
• Global recomputation?
– What happens in the meantime?
– Can you restore connectivity with “local” adjustments?
• Multiple routes?
– Allow host to choose another path
26
Back to Security
• All but availability handled
– Now look at threats to availability
• Attacks on control plane
– Make sure routers can’t lie about who they are
– Solved by naming
• Internal attacks on data plane
– Can’t stop; but hosts can use multiple paths to avoid
• External attacks on data plane
– Denial of service attacks
27
Denial-of-Service
• How do you handle denial of service?
– Make people ask before they send?
– Make people shut up if you want them to?
 Keep them from sending to you, not sending to anyone
• Must be able to reach source of packets
– Not necessarily a source field, but something like that
– Need accountability and anonymity!
28
Avoiding Congestion
• Alice finally starts to download her file
• How fast is the download?
• How is that determined?
• In general, how do we control congestion?
– Adaptive algorithms?
• How do we detect congestion?
• How do we react to congestion?
29
Sharing the Network
• Alice wants to get a file
• Bob wants to get a file
• How do you share the network between them?
• When the network is congested, who gets the
bandwidth?
– Fair allocation?
– Pricing?
30
Other Topics
• Delivery models:
– Multicast?
– Anycast?
• Mobility:
– Allow frequent updates in naming system
– Provide current location
– And make sure transport protocol doesn’t embed
addresses
• Protocol details:
– Lower-level details not embedded in implementations
31
Design since last summary
• Network Security:
– All handled by end-to-end crypto except availability
– Availability requires:
 Multipath routing (to avoid attacks on links)
 Defense against denial-of-service
• Addressing:
– Addresses separate interdomain from intradomain
 Domain:LocalAddress
– Interdomain routing cares only about the domain part of
the address
– Intradomain routing cares only about the local part of the
address
32
Design summary (continued)
• Need adaptive algorithms to control congestion
• Need way to share bandwidth among users
33
How is this different from today?
• Host software and service model: same
• API: currently embeds addresses
– Makes it hard to change underlying network
• Naming:
– Today
 Location specified in names (domains)
 No cryptographic content in names
 Resolution by lookup from database
– Problems
 Names are not persistent
 Makes it harder to find nearby copies of data
 Makes it harder to associate names with keys
34
Differences from today
• Network security:
– Provenance much harder today
– Availability: also much harder (below)
• Addressing:
– Today, mixes inter- and intra- domain addressing
– Scaling problems, inflexible
• Routing:
– Today, only computes single path
– Upon failure, must wait for global recomputation
35
Point of Today’s Lecture
• We could do much better than current architecture
• But for the rest of the semester we will focus on
the current design so you learn the basics
• Will revisit alternatives in the last two lectures
36