Designing the Internet in 75 Minutes….

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

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 casesmentioned later)

Problems 1 and 2 • Overall, scores reasonably high

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

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

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

Problem 6 • Justine, in a few minutes

Problem 7 • Class did quite well, some minor problems

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

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

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

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

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!

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!

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

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

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

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

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?

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

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

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

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

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?

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?

API • What passes through API? • Addresses? • Names? • Anything else? • Urgency? • Find different copy?

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?

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

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?

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?

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

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

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

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

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

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

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

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!

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

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

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?

Designing the Internet in 75 Minutes….