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

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

4

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

5

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.

6

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…

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.

9

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

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.

15

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…

16

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?

17