An Introduction to the future of the Internet (part 1) David Clark MIT CSAIL July 2012 1 The Internet is a success So why would we want to rethink its design? It is not that some broad class of application is unsupported. Application designers have shown the broad utility of the Internet (within some limits). The issues are centered in the broader context within which the Internet is positioned. 2 It’s not the data plane. Packets have proven their generality, and we have polished the data forwarding function for years. Need to consider a broad range of requirements. Issues to consider 3 Security Availability and resilience Economic viability Better management Meet society’s needs Longevity Support for tomorrow’s computing Exploit tomorrow’s networking Support tomorrow’s applications Fit for purpose (it works…) In the beginning We really had no idea what we were doing. A lot we got right (perhaps surprising…) A lot was almost an accident. We did not understand: 4 How to write a standard Dynamics of control Correct system modularity Now We know a lot more Requirements have gotten a lot more complex 5 About requirements, design methods and mechanisms. Many more interests ask to be served. Daunting complexity Not just a technical problem Warning Computer scientists like to talk about mechanism and performance. (I am somewhat critical of this…) 6 Forwarding schemes: 54 and counting. This set of talks is more about requirements and design approaches. I will discuss mechanism, but as illustration. Outline of these lectures Look at some of these important objectives Describe some emerging proposals and approaches Sometimes conflicting, sometimes clear. (Sometimes my personal point of view.) So wander between requirements and mechanism. 7 What is wrong with the network of today? Why is it worth considering alternative designs? Mechanism is easier to think about. Requirements are more fundamental. Designing the future Explicit projects in US and EU to think about an Internet for the future. Ask what our global network of 15 years from now should be. US: FIND (Future Internet Design) and FIA (Future Internet Architecture) EU: Framework projects 8 Nebula, MobilityFirst, Named Data Networking, Expressive Internet Architecture (XIA), ChoiceNet PSIRP, PURSUIT, 4WARD, Haggle, Trilogy… Why take a longer view? Two ways to pick research topics: Look at the problems of today and try to fix them. Sometimes called “incremental”, which is NOT a bad word or a bad way to proceed. Describe a goal: where are we trying to get? An objective imposes a bias on forward progress. Sometimes called “clean slate”, which is often misunderstood. 9 Not a rejection of the present, nor a demand for a fork-lift replacement of the current network. Issues to consider 10 Security Availability and resilience Economic viability Better management Meet society’s needs Longevity Support for tomorrow’s computing Exploit tomorrow’s networking Support tomorrow’s applications Fit for purpose (it works…) What was that list?? Those were not requirements. They are a wish list. It is a big jump from any of these items to the design of mechanism. 11 Desiderata An aide-memoire And that is a big issue. Design methodology We must think about the process of moving from objectives to specific requirements to mechanisms and architecture. If the problem is too big to consider at once, must modularize the design process. 12 Beware an over-dependence on layering. That list of issues represents a broad set of criteria: Not just the “traditional”: performance/optimization, generality, new technology Implies a multi-dimensional assessment of new ideas. Implies tradeoff and balancing. We understand a lot more now than we did in 1974. This current work should be based on methodical design, analysis, theory. Security Use as a first example of a requirement. Hard and important. Why is the problem so hard? We don’t agree on the definition of good security We want different outcomes in different contexts. We cannot correct the insecurity of end-nodes. Old ideas: (good ideas, but not why we thought.) Confidentiality, integrity, availability How does this relate to firewalls, VPNs? 13 A balance among stake-holders. After the fact--not a part of the network A different modularity Attacks on the network Attacks on communication 14 A special case of availability. Information assurance. Infiltration (can lead to most anything) So either prevent infiltration or limit its consequences. Denial of service Confidentiality and integrity addressed with encryption. Availability?? The central objective of networks. What else? Attacks on the host Routing, supply chain Sign the information, not the connection. National security Who is responsible? Attacks on the network. Attacks on communication. 15 A contested space. Information assurance A contested space: end-node, network, application designer, user. DDoS. Confidentiality and integrity can be delegated to end-nodes. (contested) Availability is a shared responsibility. Attacks on hosts. The network. Unclear once you get deeply into it. National security. An ugly situation Everybody says we need better security, but. Security is an emergent property of a running system Depends on architecture, mechanism, allocation of responsibility, operational issues. Most of my security friends design mechanisms. 16 No agreement as to what that really means. No agreement as to which actors play which role in producing it. Much easier—does not make your head hurt… Doing better next time? The hypothesis of the future Internet research agenda is that we could do a better job if we freed ourselves from the constraints of the present. 17 Do we actually know enough to do that? What do we actually know about the fundamentals of network architecture, and its relation to these broad set of requirements?