1

Designing the Internet in 75 Minutes….

EE122 Fall 2011

Scott Shenker

http://inst.eecs.berkeley.edu/~ee122/

Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxsonand other colleagues at Princeton and UC Berkeley

Grading the Homeworks

• Going very slowly, my apologies

• Two graders, trying to work out inconsistencies

2

The Midterm

• Average score ~106 (80%)

• Will be handed back at end class

• Key will be published soon– A few stragglers…

• Regrading requests:– Sent to me (not TAs)– Cover sheet explaining why you think you deserve credit– Regrade will be over entire test

(except for two cases mentioned later)3

Problems 1 and 2

• Overall, scores reasonably high

4

Problem 3

• IPv6 headers the most frequently missed question

• IP checksum is only over header– The key was wrong on this, so it was misgraded!– Answer should be “none of the above”– Submit a regrade (1/2 point)

• DHCP all broadcast (I said “know this”)

• Order of packet headers– Not sure if you don’t know, or if question was unclear– Learn this for final….

• Packet from NAT to A should not have NAT’s address in the source field

5

Problem 4

• More mistakes on startup than on tear-down

• DNS should come first, then TCP.

6

Problem 5

• If packet arrives on port where switch would forward packet, switch drops it

7

Problem 6

• Justine, in a few minutes

8

Problem 7

• Class did quite well, some minor problems

9

Problem 8

• Most common mistake:– The prefixes to port 6

• Many people didn’t have a clue….(get one for final)

• The hardest problem to grade– Partial credit was difficult to assess

• Ask for a regrade if your prefixes were close to right, but I didn’t give you much credit

10

SPLIT HORIZON + POISON REVERSE

Never announce a path back to the node you got it

from.

4

B’s path to A:

BDEA

B announces “6” to C.

4

B’s path to A:

BCDEA

B announces “∞” to C.

SPLIT HORIZON + POISON REVERSE

Never announce a path back to the node you got it

from.

Beanbags….

• 20 leftover beanbags

• Soon to be a collector’s item

• Grab one if you can…

• I won’t make you route based on them!

15

Where Are We?

• Covered foundations (reliability, routing)

• Covered essentials of today’s architecture– Naming, web, TCP

• Rest of semester: various topics

• But today, I want to step back and ask:– How would you redesign the Internet?

• You’ve seen how it works, now fix it!16

Goal for Today

• Come up with a “clean-slate” design– Start from scratch– Make some basic design decisions

• We will ignore two topics that we will cover later– Congestion control– Advanced routing

• And we will assume: (anyone against these?)– Packet switching– Best-Effort

17

Process

• I ask questions

• You give answers

• Not all the same suspects, so I will ask the bean bag owners to answer questions…

18

Properties We Care About

• Reliability– What parts of architecture matter for reliability?

• Security– What parts of architecture matter for security?

• Evolvability– What parts of architecture matter for evolvability?

• Meeting application needs:– Will become clear as we get further….

19

Basic Scenario

• Alice wants to retrieve a movie from the Internet– Legally, of course

• Alice is sitting at host A

• Content on a variety of hosts around the Internet

20

Requirement #1: Getting Data Quickly

• What is biggest barrier to getting data quickly?

• Latency is the biggest barrier– How do you reduce latency?

• Getting nearby copies is crucial– Done by CDNs today, but what is a better alternative?

21

Requirement #2: Verifiable Content

• Done with keys today, but not well…

22

Requirement #3: Network Works

• Not taken down by attackers through DoS or other means….will discuss later

23

Keep these requirements in mind…

• Now, let’s consider some design questions….

24

Host Software

• What is 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/net25

Application/Stack Interface: API

• What does the application tell the “stack”

• API: Contact that host (packet send/receive)– Who knows where host is?

Application Stack Network (only)

• Alternative API: Get this data– Who knows where content is?

Application Stack Network (only)

• Which is better interface?26

API Continued….

• Do all applications want the same API?– Should SSH and HTTP use the same API?– What about streaming video?

• Can the API ever change?

• How can we make API extensible?

27

API

• What passes through API?– Addresses?– Names?

• Anything else?– Urgency?– Find different copy?

28

Name Resolution

• What should name resolution tell you?– Where a nearby copy of the name is– Crucial for named content, ok for anything else

• Need an infrastructure that:– Finds shortest paths– Handles failures– Scales

• Currrent approach is lookup-by-name– Go find name in distributed database of addresses– Is this a good fit for requirements?

29

Alternative: Route-by-name

• Routing is expressly designed to:– Finds shortest paths– Handles failures– Scales

• Why not build a routing infrastructure for names?

• Need not go at data speeds, must have huge routing table….– Area of active research and disagreement….

30

Name Resolution

• 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?

31

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?

32

Key Observation

• Names should be verifiable!

• And contain no other information

• What about today’s names?– Exactly the opposite!

33

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

34

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

35

Attaching Meaning to Names

• Outside of architecture– Why?

• Mechanisms to attach semantics to names:– Certificate authorities– Trusted databases– Webs of trust– Social networks– …….

36

Phishing

• The key to dealing with phishing is to allow users to verify identity– Is this person who I think it is?

• How could we do this?

• I have no answers….– One possibility: Google

37

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……38

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

39

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!

40

Other Topics

• Delivery models:– Multicast?– Anycast?– Anything else?

• Mobility:– Allow frequent updates in naming system– Provide current location– And make sure transport protocol doesn’t embed

addresses

41

Evolvability

• What prevents us from changing from IP to IPv6?

• How could we fix this?– Interdomain addressing separate from intradomain– Version number for IP (already have it)– Flexible forwarding hardware

• Must our new architecture have a narrow waist?– What prevents us from having multiple “IP”s?

• Could source-driven routing help?– Finding any viable path, not just the default path

42

The Dual Role of IP

• IP is a global addressing scheme

• It is also a universal packet format

• If we have the former (domain names), do we need the latter?

43