1

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 Paxsonand other colleagues at Princeton and UC Berkeley

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?

• Whatever the API, it needs to name hosts, data,…10

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 addresses19

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