Transcript Designing a future Internet: Architecture and
1
An Introduction to the future of 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.
Outline of these lectures
7 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.
Designing the future
8 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?
9 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.
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
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?