1. 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 Paxson and other colleagues at Princeton and UC Berkeley

2. Grading the Homeworks Going very slowly, my apologies Two graders, trying to work out inconsistencies 2

3. 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

4. Problems 1 and 2 Overall, scores reasonably high 4

5. 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

6. Problem 4 More mistakes on startup than on tear-down DNS should come first, then TCP. 6

7. Problem 5 If packet arrives on port where switch would forward packet, switch drops it 7

8. Problem 6 Justine, in a few minutes 8

9. Problem 7 Class did quite well, some minor problems 9

10. 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

11. SPLIT HORIZON + POISON REVERSE Never announce a path back to the node you got it from.

12. 4 B’s path to A: BDEA B announces “6” to C.

13. 4 B’s path to A: BCDEA B announces “ ∞ ” to C.

14. SPLIT HORIZON + POISON REVERSE Never announce a path back to the node you got it from.

15. 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

16. 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

17. 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

18. Process I ask questions You give answers Not all the same suspects, so I will ask the bean bag owners to answer questions… 18

19. 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

20. 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

21. 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

22. Requirement #2: Verifiable Content Done with keys today, but not well… 22

23. Requirement #3: Network Works Not taken down by attackers through DoS or other means….will discuss later 23

24. Keep these requirements in mind… Now, let’s consider some design questions…. 24

25. 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/net 25

26. 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

27. 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

28. API What passes through API? –Addresses? –Names? Anything else? –Urgency? –Find different copy? 28

29. 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

30. 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

31. 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

32. 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

33. Key Observation Names should be verifiable! And contain no other information What about today’s names? –Exactly the opposite! 33

34. 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

35. 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

36. Attaching Meaning to Names Outside of architecture –Why? Mechanisms to attach semantics to names: –Certificate authorities –Trusted databases –Webs of trust –Social networks –……. 36

37. 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

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

39. 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

40. 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

41. 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

42. 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

43. 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