An Introduction to the future of the Internet (part 1)

1. An Introduction to the futureof the Internet (part 1) David Clark MIT CSAIL July 2012

2. The Internet is a success • So why would we want to rethink its design? • It’s not the data plane. • Packets have proven their generality, and we have polished the data forwarding function for years. • 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. • Need to consider a broad range of requirements.

3. Issues to consider • 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…)

4. 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: • How to write a standard • Dynamics of control • Correct system modularity

5. Now • We know a lot more • About requirements, design methods and mechanisms. • Requirements have gotten a lot more complex • Many more interests ask to be served. • Daunting complexity • Not just a technical problem

6. Warning • Computer scientists like to talk about mechanism and performance. • (I am somewhat critical of this…) • Forwarding schemes: 54 and counting. • This set of talks is more about requirements and design approaches. • I will discuss mechanism, but as illustration.

7. Outline of these lectures • Look at some of these important objectives • What is wrong with the network of today? • Why is it worth considering alternative designs? • Describe some emerging proposals and approaches • Sometimes conflicting, sometimes clear. • (Sometimes my personal point of view.) • So wander between requirements and mechanism. • Mechanism is easier to think about. • Requirements are more fundamental.

8. 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) • Nebula, MobilityFirst, Named Data Networking, Expressive Internet Architecture (XIA), ChoiceNet • EU: Framework projects • PSIRP, PURSUIT, 4WARD, Haggle, Trilogy…

9. 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 mis-understood. • Not a rejection of the present, nor a demand for a fork-lift replacement of the current network.

10. Issues to consider • 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…)

11. What was that list?? • Those were not requirements. • They are a wish list. • Desiderata • An aide-memoire • It is a big jump from any of these items to the design of mechanism. • And that is a big issue.

12. 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. • 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.

13. 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 • A balance among stake-holders. • 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? • After the fact--not a part of the network

14. A different modularity • Attacks on the network • Routing, supply chain • Attacks on communication • Confidentiality and integrity addressed with encryption. • Availability?? The central objective of networks. • What else? • Attacks on the host • Infiltration (can lead to most anything) • So either prevent infiltration or limit its consequences. • Denial of service • A special case of availability. • Information assurance. • Sign the information, not the connection. • National security

15. Who is responsible? • Attacks on the network. • The network. • Attacks on communication. • Confidentiality and integrity can be delegated to end-nodes. (contested) • Availability is a shared responsibility. • Attacks on hosts. • A contested space: end-node, network, application designer, user. • DDoS. • A contested space. • Information assurance • Unclear once you get deeply into it. • National security.

16. An ugly situation • Everybody says we need better security, but. • No agreement as to what that really means. • No agreement as to which actors play which role in producing it. • 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. • Much easier—does not make your head hurt…

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