The Internet today and tomorrow:
social implications of evolving
technology
David Clark
MIT CSAIL
November 2008
1
Internet today: background

The forces that are shaping it are not just
technical.


Technical changes are real: wireless,
embedded computers, location sensing.
But perhaps more important is the deep
embedding in society.
Privacy and identity.
 Social networking as a platform.
 The role of the ISP.

2
Internet tomorrow: background

FIND (Future Internet Design) is a U.S. NSF
program to look at what our global network of 15
years from now should be.


Challenges us to think about why we built what
we built.



3
Similar efforts in Asia and Europe.
A lot we got right (perhaps surprising…)
A lot is almost an accident.
Could we, by design, mitigate some of the
issues we debate today?
FIND: 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.
The issues are centered in the broader context
within which the Internet is positioned.

4
It’s not the data plane.
Packets have proven their generality, and we have
polished the data forwarding function for years.
The FIND project must consider a broad range of
requirements.
Issues to consider









5
Security
Availability and resilience
Better management
Economic viability
Meet society’s needs
Support for tomorrow’s computing
Exploit tomorrow’s networking
Support tomorrow’s applications
Fit for purpose (it works…)
The role of the ISP

They forward packets.




They invest and manage risk.
They police (directly and indirectly).
They provide critical societal infrastructure.


They interconnect with their competitors.
The Internet cannot just be a creature of the private sector.
They want to profit from investment.


(Follow the money.)
Advertising


6
ISPs vs. Google. Deep packet inspection.
Manage usage and acceptable activities.
Neutrality and management

The net is not neutral and never has been.



The real discrimination (follow the money)
is at the points of interconnection.


7
We gave preference to interactive traffic in the
early days of the NSFnet.
ISPs block known security vulnerabilities.
Peering, transit, bargaining, routing, etc.
What the consumer sees is a side-effect of
interconnection negotiations.
Traffic management?

Usage does cost something. It is not free.


But it is not expensive.
For a typical big access ISP, might be $.05 or $.10
per GB.



But for a rural ISP (think small WISP), might be
10 times that.
Must deal with consequences of flat rate pricing.


Typical residential usage today may be 1% loading.
This is necessary. Otherwise nobody could afford
broadband.

8
Note that this has nothing to do with peak rate.
Again, has little to do with peak rate.
What is acceptable?


And how would we decide?
Is it acceptable for someone to profile my behavior?



If I opt in? If I get only select ads? If I can opt out selectively?
If it is “pre-anonymized” so it cannot be directly traced back to
me?
Is it acceptable for ISPs to limit what I do and how much
I send?

If limit is just measured in bytes, yes.




If limit is priority and service quality, yes.
If limit is performance variation among servers, it happens today
all the time.
To what extent should the ISP police the network?

9
Could limit using dollars. Moving to price tiers.
Inevitable, so get on to the issues.
A final comment

Being a residential broadband provider is a good
business.


There is a sense that (especially with respect to cable
guys), broadband is some marginal add-on to a highly
profitable cable business.




10
If big and (sub) urban.
This is silly.
ISPs pay for cable content. They get Internet content (“over the
top”) for free. Sometimes they get paid.
The issues are cost of delivery and who gets advertising
revenues.
They do not prefer one to another. They want them all.
Talk about tomorrow

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.


11
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.
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.

12
Desiderata
An aide-memoire
And that is a big issue.
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 framework:

Disclosure, 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 framework

Attacks on communication




Attacks on the host




Infiltration (can lead to most anything)
So either prevent infiltration or limit its consequences.
Attacks on information.
Denial of service

14
Confidentiality and integrity addressed with
encryption.
Availability?? The central objective of networks.
What else?
A special case of availability.
Availability

First, as much as possible, make the “what else” attacks
on communication into failures of availability.

Limit the range of attacks and responses.


Mechanism: wrap an end-to-end confirmation of identity around
a connection.


Cleanly makes many attacks on/by the network into an availability
problem.
Second, develop a theory of availability.

At a high level:



15
Think: what is excluded…?
All critical resources must be supported in a rich, heterogeneous,
diverse form.
It must be possible to detect and distinguish (to some degree)
failures.
The point of detection must be able to invoke different resources.

In general, only the end-points can detect failures.
Examples of attacks

Byzantine packet handling.


Re-routing, adding and dropping.
Only end-node can detect, so end-node must
be able to request re-routing.
Explicit
 Implicit



Multi-homed end-nodes
DNS corruption (pharming)

No architectural support today to mitigate this.

16
Design is redundant, but not in face of malice.
End-to-end checks

To turn misdirection attacks into “availability problems”,
need a means to confirm with whom you are
communicating.
 An issue of identity and shared information.



17
What notion(s) of identity will be suitable? (See below.)
“You” means the end-nodes, but not just the human. If
the end-node can be trusted, software can help.
 Corrupted end-nodes are a central issue here.
 Can a trusted helper node help?
To detect byzantine attacks, fault detection must be
integrated into the carriage of data.
 Security and management are entangled.
Economic viability

Fundamentals:




Our preferences:

18
Different parts of the network are built by
different actors.
Physical facilities (fibers, towers, etc.) require
capital investment.
Investors must be motivated to invest.
Facilities owners must not control the future of
the network. Just invest in it.
What happens today?

How do facilities owners operate and interact?

One answer is that they become ISPs.




ISPs serve a critical business function today.


19
Measure/model usage
Track customers and markets
Control routing.
They don’t just move packets, but manage capital
and risk. Important economic role.
But is this role fundamental?
Some specific requirements



20
ISPs must be able to model usage and demand
sufficiently well to make investment decisions.
Users must be able to select among paths through the
network that avoid failures.
The network design must allow users a degree of choice
among providers so as to impose the discipline of
competition.
A new idea--virtual networks

In a virtual network, facilities (routers, links, etc.)
are virtualized and then used by higher-level
service providers to implement different
networks, possibly using very different
architectures.



In a world of virtual networks, why would
someone invest in expensive facilities?

21
VPNs are a limited version of this idea today.
A new form of competition.
Owner does not control routing, so where should the
links go?
Another new ideas: futures




If investment in facilities is a “up-front” or “sunk”
cost, with a long period of depreciation and cost
recovery;
And virtual networks anticipate flexible access to
resources over a short term;
Then there must be some way to insulate
facilities investors from risk so that they will
invest.
Consider a futures market for bandwidth.

22
Happens today with really expensive cables.
A new interface

Do we need to standardize the interface
that defines this futures market?


Not sure, but if we do, it is an odd sort of
standard.


Not moving packets, but money.
Not just bandwidth, but in a location.

23
Has a lot in common with other commodity
markets.
Compare to spectrum auctions.
The alternatives?

Mandatory facilities unbundling.





Public sector investment.

24
As was called for in the Telecommunications Act of
1996 for access facilities.
As is being done in Europe today for access facilities.
Regulated rate of return or mandatory structural
separation.
Works where the motivation to invest is compelling.
Failure so far… (a controversial statement, I know.)
Interfaces define the industry

ISPs exist because of IP, and the protocols that
connect regions together.



Protocols define the services that can be
created across multiple regions.
So by creating protocols, we create
opportunities for service (e.g. revenue) creation.

25
There is no fundamental reason why ISPs look the
way they do.
Which are possible, which are dangerous?
Region interconnection


Old idea: BGP.
New ideas:







Interconnection of advanced services
Direct expression of business constraints
Routing overlays
Fault localization and correction
Interconnection of traffic aggregates
Short-term markets for service
Security issues


26
Control of DDoS
Detection of corrupted or untrustworthy regions
Observations

Management has a lot to do with
security,availability and economics.



27
These areas are not “modules”.
Cannot have a “security” or a “management”
design sub-group.
For all these areas, we have lots of great
ideas, but must sharpen the architectural
framework.
Information--moving up-layer


Old idea: an application issue (ignore it.)
New idea: need a framework

Naming and identity of information.


Independent of how you get it.
But: think about privacy.


Dissemination



28
If you shout for information, the whole world hears.
Swarms, P2P: (heterogeneous).
Should this be the basic service, or on top of a transport
service?
Improves availability of information if it is pushed into the
network.
Issues to consider









29
Security
Availability and resilience
Better management
Economic viability
Meet society’s needs
Support for tomorrow’s computing
Exploit tomorrow’s networking
Support tomorrow’s applications
Fit for purpose (it works…)
The role of identity

A requirement for identity comes up often:




30
Detect misdirection attacks on communication.
Detect invalid (unauthentic) pieces of information.
Validate identity/authority of incoming connections to
prevent infiltration attacks.
Allow application/network to pick desired
communication pattern, to insert the desired degree
of checking into the path between communicating
parties, depending on the degree of trust between the
parties.
Designing identity schemes

There is more than one way we could approach identity.

A private matter among end-nodes.


Signal of identity that is visible in the network.





Anonymity can only be revoked by its creators.
Probably need all in different circumstances, so
architecture should not constrain.
These are not choices to be made by technologists
alone.

Need a multi-disciplinary conversation.

31
Surveillance cameras in cyberspace.
Facilitate both policing (perhaps) and repression.
Third-party credentials vs. continuity-based familiarity.
Revocable anonymity.


E.g. encrypted or meaningless except at end points.
I am very fearful of getting this wrong.
Identity schemes imply deception

Both a human and a technical problem.

How do you know what information to trust?



Credentials? Continuity?
Collaborative filtering (trust again).
Identity itself should be rich and heterogeneous



How can we avoid illusion on the screen?
Remember that a human is not always present.

32
Integrity through availability.
Need ability (perhaps in restricted circumstances) to
delegate decision to a program.
Mechanism design


33
The previous discussion (very incomplete)
hints at the range of issues that designers
of a future network should consider.
A future network will have mechanisms
that (at a high level) are familiar, but they
may take very different forms.
Routing and forwarding



Forwarding: what a router does when it gets a packet.
Routing: computing the right paths to make forwarding
work.
Why should routers compute routes?



Issues: (examples…)




34
Why not make it a competitive business?
Let servers compute routes and download them into routers to
drive forwarding.
Resilience and route recovery.
Investment incentive.
Better security through diversity.
Better routes
Application design


Old view (simplistic): our machines talk.
New view:


Lots of servers and services.
Need for cross-application core services.



Modulate behavior based on trust.
Outsource security-related tasks to secure nodes.


Since the host is insecure.
Application design patterns and building blocks
should be part of the future network.

35
Identity management, social networks.
Social question: who is empowered and is this what
we wanted as the outcome?
Lots of things we did not discuss





36
Naming (of all sorts of things).
Location (physical).
Social context.
Other aspects of security (e.g., DDoS),
management, economics.
Computing and network technology.
Observations

Mechanism (e.g. routing) is a response to a set of
requirements, not a given.



The (new) interesting interfaces will not involve packets
but control, investment, social context, etc.
Technical design choices can shift the balance of the
social contract among the players.


Derive mechanism, don’t presume it.
Computer scientists are not trained to think in these terms, and
social scientists tend to take the technology as exogenous.
The role of the ISP is critical.

What will we be arguing about 5 years from now?

37
Policing, liability, advertising, out of date infrastructure.
38
Network management

Even less structured than security.



Possible decomposition:



Fault isolation and resolution.
Network planning and configuration.
Does this framing actually decompose the
problem?

39
No real consideration in original design.
Remote management of boxes.
Do we know the modules of management?
New ideas:

Critical interfaces:


Between layers to integrate application, network and technology.
Between regions to allow cross-domain capabilities.


Expression of end-user intent.



40
Critical in solving availability problem.
Better tools for abstracting the manager’s job.


This interface is fundamental. It reflects reality.
Critical in solving availability problem.
Default management automatic, just like dynamic host
configuration.
Instrumenting the data plane to detect problems.
Back to security


Earlier we discussed protecting
communication from attacks in the net.
Other aspects include:



Consider infiltration attacks.

41
Infiltration
DDoS attacks
Either prevent infiltration or limit
consequential damage.
Start from fundamentals

Node security

Classic end-nodes will always be insecure, but we can build
fixed-function nodes that are pretty good.


What parts do we have to work with?



Applications define the range of patterns of communication that
can be utilized, and what can be seen/modified in the
communication.
Elements in the network can examine what is revealed.
End-node controls the initiation of connections and what is
sent.


Encryption blunts the power of examination/modification.
Network controls topology and completion of connections.

42
Can we build secure virtual machines?
A tussle over availability.
Practice vs. theory

These asymmetries are understood in
practice…




43
Firewall topology
“Port 80” mode in apps.
VPNs.
But are not recognized or exploited in the
design of the network.
The design challenge

What trusted components, combined with
application modes that exploit them, can
protect untrustworthy end-nodes from
attack (in particular infiltration, sabotage
and exfiltration)?


The network can enforce the needed
patterns of communication.
Network elements can examine what the
application chooses to reveal.

44
Trusted and untrusted…
Prevent infiltration

Require identity as part of session initiation.


“Firewall of the future”


Represents a loss of privacy, so use selectively.
Host-centric actions.


45
Make port scans less effective.
Inspect incoming data for “bad stuff”.


Allow end-node (or trusted helper) to open ports dynamically.
Eliminate well-known ports.


Use agent to validate incoming service requests.
Virtual machines for risky actions.
Outsource risky apps to different machine.
Prevent exfiltration

If a machine is penetrated, limit the bad
consequences.



The problem with controlling theft:

46
Could be use as zombie, deletion or
corruption of data, or theft.
Theft is a major problem today.
How can an external agent tell if the transfer
is legitimate?
The dilemma

Two stories:

Foreign hackers penetrate a system and send
information back to their country.


Foreign citizens download public information from a U.S.
web site.


Their country try to block it.
What is the difference?



47
We try to block it.
We relabeled the actors.
In one case, had to penetrate the sender to implement the pattern.
In one case, the sender’s regime tries to block, in the other the
receiver’s regime tries to block.
The design challenge, part two

48
How can we design applications and
patterns of communication that can
distinguish between these two stories,
even if the sending machine has been
penetrated?
Distinguish the stories

In the first story:


In the second story:


Put the data into an open publish-subscribe or peer-to-peer
distribution system.
 Another example of the theory of availability.
 But protect the privacy of the requester…
Balance the interests…

49
Require that data being sent get an export permit (from a trusted
machine), that the user must concur, and that we get a strong
identity of the receiver before issuing the permit.
Don’t forget the third story, pushing information out.