David D. Clark: “Designing an Internet” | Talks at Google

David D. Clark: “Designing an Internet” | Talks at Google

scientists don’t normally write books. We write 12-page papers
we submit to sitcoms. So it was somewhat
of a surprise to me when I realized I
was writing a book. I’d written several
chapters of it before I figured out
what was going on. And I think it was a friend
of mine that said, by the way, have you noticed
you’re writing a book? And I sort of said, oh. The short-term
motivation for this book was a project that the
National Science Foundation funded, which several of
us encouraged them to do, called the Future Internet
Architecture project. The research
community sort of gets sucked in to the reality of the
short-term internet, everything that’s wrong with it. So if you look at a lot of
the networking research, it’s fairly short term. And we made an argument
that at least some people in the community
ought to be asking, what should the internet
of 15 years from now, what should the internet of
20 years from now look like? So they did this project called
Future Internet Architecture, and pushed a few
people in the community to go do some
long-term research. And I had a grant from
NSF to sort of look across all the
projects and integrate what was being learned. And after I’d been doing
that for several years, I realized that the result
was probably book-sized. But of course, the
idea of writing alternative
architecture papers has been going on in the research
community since 1990. We’ve had a whole
bunch of proposals for, well, you could
have built it like this. You could have
built it like that. And when I started
to go back and look at all of those
proposals, you realize you can’t compare
proposals unless you understand the problem
they’re trying to solve. So a lot of what this book
is about is requirements. And people say, oh,
requirements is so boring. I want to develop
this cool technology. Show me something neat. But in fact, when
you actually ask, what are the requirements
for a successful internet, it becomes a very, very
interesting conversation. So this book is in part
about requirements. It is in part about
alternative ways you could have
built an internet. I think I identified 26
alternative proposals that have been published that
I go through in the book. Not in painful
depth, I assure you. And to a certain
extent, the book is also a personal history,
because over the decades since I started working on
the internet, which was 1975, my understanding of what
problem we were solving has completely changed. And if I can say just a little
bit about my personal history, in the 1970s, we
were just trying to get the protocols to work. And it’s important to
remember how little we knew or how little we were
sure of back then. There were people that
absolutely believed you could not write a protocol
specification precise enough that two people working
only from the spec could actually write
interoperable code. They simply didn’t
think you could do it. And of course, today, the
idea of writing a standard is sort of like, well,
I’ll write one today. But we didn’t know how to do it. And in fact, we spent something
like two years with the TCP standard in which we
alternatively debugged our code and debugged the spec,
and debugged the code and debugged the spec. And it’s because you had to
learn how to write a spec. Then in the 1980s, which is
when I chaired the Internet Activities Board,
we were getting big. And the 1980s was the
computer scientist response to getting big, which is we only
know one way to scale a system. Or at least back then,
the reflexive thing to do is to make it a hierarchy. So we made routing
into a hierarchy. We had the exterior gateway
protocol, which today is BGP. And we had the interior
gateway protocol. We made the domain name
system hierarchical. It used to be a list that
John Postel maintained. You can download the file. That didn’t work. And we had to organize
the standards committee. We made that hierarchical too. We created an IETF and created
areas and working groups. And then in the 1990s,
aside from the web, the thing that happened was
it started to get commercial. And that was a
surprising decade, because we didn’t know what
the commercial internet would look like. In the 1980s and the
first part of the 1980s, the core of the internet was
the NSFNET run by the National Science Foundation. And people were playing
around with the idea that there should be little
for-profit experiments around the edge. But when the NSF declared they
were going to shut down NSFNET and we were going to
have a commercial core, we sort of looked
around and said, whoa. We don’t know what this
is going to look like. And in fact, BGP, the
Border Gateway Protocol, it’s interesting. It’s the first
protocol I participated in designing where
the specific goal was to shape industry structure. And we didn’t understand
in the 1970s and 1980s that we were shaping
industry structure. But in the 1990s, this
became painfully clear. But my personal experience
in the 1990s was– well, I’ll tell you
a specific story. In the first part of the
1990s, I put a lot of work into quality of service. And we built
DiffServ and IntServ and all this kind of stuff. And we were trying to get
it deployed in the internet. And we went to Cisco and said,
put this stuff in your router. And they said, we
like a customer. Go find me a customer. So I went to the largest ISP at
the time, and I went to the CTO and I said, hey. There’s this cool
DiffServ stuff, and you ought to put
this in your network. And he said, no. I like clean answers, but
that wasn’t the one I wanted. I said, why not? And he said the following
wonderful sentence. He said, why should I
spend a lot of money so Bill Gates can
make a lot of money selling internet
telephony for Windows? And I said, ah. The competitive interface,
the specification of the internet protocol, which
is a cut point in the stack, is a money insulator. And you guys know this,
because you live above that, and you constantly
watch ISPs trying to figure out how to suck
into your value proposition. They’re trying to pull
money down into their layer. And I’ve talked to some ISPs. Actually in Europe, the
problem is more substantial. I was talking to one
of the ISPs in Europe, and they were trying
to figure out how to suck money out of Google. So then I said, well, why
are you trying to do this? And they said, well,
Google has some, and that was the
depth of their logic. And by the way,
then the CTO said the following
interesting thing to me. He said, and by the way, if
I did put quality of service into my network, why would I
turn it on for anybody but me? It was 1995. We didn’t know to call it
network neutrality back then, but all of a sudden, I
realized there was a problem. So I realized that the
technologists were not in charge of the
future of the internet. I hired an economist. I’ve had a political scientist
that’s worked for me. I’ve collaborated with lawyers. I’ve become painfully
multidisciplinary. This is usually a symptom
that you’re over the hill, but I’ve been doing
it for a while. So the book is in large
part about requirements, and the requirements
are not just technical. There’s a chapter in there
on economic viability. What does it mean? How do you think about designing
a protocol or set of protocol– what I call in the
book the architecture– so that it is viable as
an industry structure? In fact, there’s some nice
economic theory about this. There’s an economist– one
of my favorite economists is a man named Ronald Coase. And he is famous for
having articulated what’s called the theory of the firm. And I said, why do firms exist? It’s a really
interesting question. If you naively believe
your Economics 101 class, which is to say competition
disciplines the market and you always want to buy the– you want to pick price and
quality for your procurements, so why do you have a big firm? Why isn’t the firm
lots of little firmlets that are constantly
competing with each other? And he made the point that
the process of negotiation, of finding the price,
finding the quality, that the negotiation
itself was costly. He called it transaction
cost, and he pointed out that if transaction
costs are too high, then it’s cheaper to
build that– pull that decision into the firm. And so in some sense,
planning, which is what happens inside a firm,
competes with competition to see which one’s
more efficient. And the interfaces where you’re
most likely to see competition are the ones where the
transaction cost is lowest. And one of the ways we can
make the transaction cost low is to have a clean
specification on the internet, on the interface, which is to
say that protocol boundaries define industry boundary. The reason internet service
providers look the way they do is the internet protocol was
specified the way it was. And if we had specified
it differently, the industry structure
would be different. Now every economist I’ve
spoken to said, well, duh. But I didn’t get this. There was another
famous conversation I had with an economist, and
I put this in the book too. He doesn’t like me
to tell this story and name him because he’s
worried that somebody might think the conversation
was actually serious, but he does work for Google. And he said to me, the
internet’s about routing money. Routing packets
is a side effect, and you screwed up the
money routing protocols. And I said, I didn’t design
any money routing protocols. And he said, that’s what I said. And whenever we
look at dysfunction, for example, the
failure of quality of service in the internet, it’s
not because it doesn’t work. Technically, it works just fine. It’s because it didn’t
work economically. And this was this wonderful
quote from the CTO. Why should I spend money
to put this stuff in so that the apps running on
top of it work better, but the apps aren’t paying me? I said, oh, OK. So there’s a tremendous
dislocation there. So there’s a chapter in
the book on economics. There are a couple other areas
that we clearly screwed up in the internet. A very technical one,
which is very geeky, is network management. And it’s really hard to get
the networking community to work on network
management, because they want to polish the data plane. I’m going to optimize. We are taught to optimize. So I’m going to get the
packets to flow 10% faster. I’m going to fill that
gigabit link 100% full. But in the early
days of the internet, our telephone company friends–
when they weren’t busy saying to us, it won’t work, it
won’t work, it won’t work, which is what they mostly said– said, if you don’t attend
to network management in the very beginning,
you’re going to build a system that’s
impossible to manage. And you should engineer into
every one of your data plane protocols– that wasn’t
the word they used– management tools. And we didn’t do that. So there’s a chapter in
the book on management. If you want your internet
to be successful, your protocols have to
last for a long time. The internet’s been
around longer than– I guess it’s not
longer than Unix, but about longer than
most anything else in the internet space. And what is it that
you did if you set out to build a system that
would last a long time? It turns out there are
absolutely conflicting theories in that space. One theory is
requirements change, and so your architecture
has to adapt. Your system has to
change over time, because the requirements
will change. And so flexibility
and adaptability is key to longevity. But there’s a
competing theory, which is, the thing that makes
your network survive is the stability as
a platform layer. And IP, the internet
that I’ve been concerned with, the stuff
up there, the guys– you guys are just apps, right? You’re not the internet. You’re apps. Now to the user,
you’re the internet. Facebook’s the internet. Twitter’s the internet. But you know, as a network
engineer, I just move bytes. OK. But the stability
of the platform, the fact that the IP layer is
not going to change rapidly, makes it an inviting
place for innovators to come and sit on top. And as soon as you
have innovators sitting on top of you, then
they will demand that your platform survive
so that they can survive. And so you’re in
a virtuous circle there in which the
platform doesn’t change. But how do you deal with
changing requirements in that space? Well, people have argued
that periodically, you just have to throw
it out and start over, which is one of the reasons
why we encouraged the National Science Foundation to think
about a Future Internet Architecture project, because
maybe that time will come. I had a friend who was
in a different business. He was in the
automobile industry, and he talked to me about
the history of carburetion. I don’t know whether
anybody here’s ever worked on a carburetor. Yeah, OK. It’s the spaghetti code of
the automobile industry. If you ever took a
carburetor– little vacuum tubes and vacuum
tubes and vacuum tubes. But they’re so mature. They were so good that
nobody could displace them, and they were just fantastic. And the fuel injection
guys were stalking them from the other side
of the street, saying, this would work better,
but it wasn’t mature. But what killed carburetion
was a sudden, dramatic change in requirements. Simultaneously, the need
to be very fuel efficient– remember, the fuel embargo. How many of you were
born in the fuel embar– oh my God. And the need– [? Dan’s ?]
back there, yes, right. You remember the fuel embargo. Right. And the need to be
very fuel efficient and cost effective
and good performance. And when they had to deal with
[INAUDIBLE] emission control, and when they had to
deal with all of that once the carburetion guys
couldn’t quite do it, the fuel injection
guys took them. And the only place you
can find a carburetor today is on my lawnmower. Which, that’s not true. Mine now is electric. But carburetors held
off fuel injection for, like, 20, 30 years. So it’s pretty
frustrating to live on the other side of the street,
stalking the success story, saying, well, maybe they’ll
stumble and I can take them. But that was the whole
idea behind the sort of episodic replacement theory. So there’s a chapter in
my book on longevity. I outline 27 competing
theories about how a system can be designed
so it’ll live a long time. So there’s a chapter
on economics. There’s a chapter on longevity. There’s a chapter on management. And as I said, there’s also a
chapter on my personal history, my journey of discovery. These various
transformative conversations I’ve had with economists, which
caused me to hire an economist. There’s also a long discussion
in the book on security. You can’t talk
about the internet today without talking
about security. And I confess, I’ve
gotten somewhat grumpy. When I go to Washington and
people say, why didn’t you think about security
from the very beginning, you dot, dot, dot. And the answer is, well,
we did think about security from the very beginning. We maybe didn’t
think about it right. We sure tried to think about it. But the thing you
got to remember is when somebody says, I want
the internet to be more secure, or they say, the current meme
is the internet’s broken, what does that mean? What does it mean to say
the internet’s broken? I just don’t know. But you have to take
that aspirational word. I want more security. It’s a motherhood word. You know, cheap secure. And you have to break it down
into actionable elements. So if you want to talk
about security holistically, you have to sort of say, well,
what’s a way of breaking it up into actionable components? And when you do
that, you realize that different parts
of the ecosystem are responsible for different
parts of the problem. And I thought I would give
you just a couple examples in that space, because security
is such a hot topic right now. Remember, to me, the
internet is not Facebook. The internet is not Google. The internet is not Twitter. The internet is a general
platform that carries packets, and apps can be
built on top of it. And you can build any
kind of app you want. You know, when Tim Berners
Lee came along and invented the web, we all said, oh,
what a fantastic thing. It just naturally ran
on top of our platform. And then when
nobody was looking, we went around and fixed
all sorts of things that would work better. But you know, the illusion
was it’s just an app. It just happened. And when video
streaming starts, we knew we were going to do video– we were streaming video on
the internet in the 1980s. It’s just, it wasn’t
commercially viable. We knew we could stream video. We knew we could. We just had to wait for enough
people to have broadband and for the cost to come down. It’s a cost issue. There were some curves. We were watching
the curves, which is, how much does it cost
Netflix to mail out a DVD and mail it back? And what is the cost
going to be to stream this stuff over the internet? You could see those
curves come together. Now Netflix also had a
horrendous licensing problem. They didn’t have
the licensing rights to send the stuff online, so
there’s another issue there. We’ve re-engineered
a lot of the internet again to make video
streaming work. I mean, you guys know that. You’ve put a lot of
effort into YouTube. You know how much effort
you’ve put into it. Netflix and YouTube
together are 50% of all the traffic flowing into
most ISPs today, American ISPs. And other countries are
suffering the same fate as Netflix shows up. But you have to go
back to security. When you begin to break
the problem into parts, you realize that security
is not a dimension along which you’re optimizing
and there’s perfection out there. It doesn’t work. Security is a
multidimensional space in which different
objectives actually compete with each other and
different stakeholders compete with each other. And to build a successfully
secure internet is to say you have built
a compromise in which all of the actors will allow
your solution to survive. If you perfect privacy
schemes, this guy from the NSA shows up and says, can I
have a little word with you? And he does security too. He calls it national
security, but it’s security. If you build a network
that’s completely encrypted, of course, all the
people that wanted to look at what you
were doing so that they could gather demographic
information about you get cranky. So there are all these
tensions in the system. But I wanted to say a couple
things about security, because it is so important. I broke the problem in the
book into four parts, which is people who trust each other
are trying to communicate, and there’s a third party
who’s trying to interfere. Steal, modify, block. That’s the classic problem
of information security. The second problem is I connect
to you and you attack me. You know, I go to a website
and it downloads malware, or I download email,
and it turns out to be spam or have a
malicious attachment. The third problem is the
mechanisms of the internet that I’m talking about
are themselves broken. And most of the mechanisms in
the internet today are broken. And the fourth one is
denial of service attacks, because that’s sort
of a special category. Just thought I’d say a few words
about some of these things. If you look at the basic
services of the internet today, they all suffer
from poor security. The domain name
system is insecure. The certificate authority
system is insecure. The routing protocol
BGP is insecure. And you might say, why is this? Why? Why, why, why, why? The basic vulnerability in
the border gateway protocol is that I can announce that I’m
the best route to someplace, and if somebody believes me,
some of my traffic comes here. So I think of a
while back, there was some Google traffic
that went to Russia, and there was apparently
some Nigerian who said, it was all my fault.
I’m terribly sorry. Don’t blame me. This is weird. We knew this vulnerability
existed in 1983. It’s documented that we knew the
vulnerability existed in 1983. So you could say,
why the rude word do we still have the problem
if we knew it existed in 1983? And the answer is
not a technical one. First of all, there are
bitter, unending debates about what component
of that insecurity is actually the most
important to fix. What is the security
vulnerability we’ve really got to deal with? And if you can’t get people
to agree on the requirement, you’re never going to get
them to agree on a solution. Some people think
that the problem is attack on the
interexchange of packets or the exchange of packets
across an exchange. Some people think it’s the
injection of false routing, and they disagree about
what the thing is. The second problem
is the people who suffer are not the people
who would have to pay. It’s another example of, why
should I pay a lot of money to save him money? If Comcast puts a
whole lot of money into making sure that
their routing is perfect, do they make any more money? No. Other people have
fewer attacks on them, but those are other people. Do those other
people pay Comcast? No. Now I’ve talked to Comcast,
and they do put a lot of effort into this, because they
want to be good citizens. But the other problem is
they can’t do it alone. They may be the biggest consumer
ISP in the United States, but they need other
people to do things. So there’s a huge
coordination problem. So if you have a
problem where people can’t agree on what
the problem really is, there’s what the economists call
a negative externality, which is, I have to spend money
so he can save some. And there’s a terrible
coordination problem, and there’s nobody in charge. In the whole essence
of the internet, there’s nobody in charge. Oh, we love it, Whoopee. OK, there’s nobody in charge. Makes it really hard
to fix these problems. So the discussion
of economics relates to the discussion of security. I want to come back to a couple
other aspects of security, because I’ve been
thinking about it a lot. I talked about the classic
communications or information security problem,
which is, I want to have a trusted
conversation with you, and somebody’s
trying to mess it up. The classic solution is,
here come the cryptographers over the hill. We’re going to
encrypt everything, and then everything
will be great. And crypto is not pixie dust. You can’t sprinkle
it on a problem and make the problem go away. I was talking to a
counterintelligence friend of mine, and he
said, only amateurs think you have to
break the crypto. We just mess with the keys. And if you look at
the horrible problems we have today with a
certificate authority system– which in fact,
Google is, I think, leading the charge to
try to make it better. And the reason why we
have horrible problems with the certificate
authority system, which have to do with lack of trust,
a lack of understanding of which actors were trustworthy,
an inability to coordinate a global system in which
people are definitionally untrustworthy,
cryptographers tend to say, well, you over there. You go solve the key problem. No. That’s where the problem is. Everybody go over there and
solve the key management problem. That is the key issue. Oh, God. I said it. That’s the key issue. I’m sorry. Forgive me. But there’s one other
thing I wanted to say about information security. If we teach this in school, we
say, there are three elements. Sometimes six, but the
most important ones are confidentiality,
integrity, and availability. And in the early days
of the internet when we were trying to figure
out how to do security, we were trying to figure
out who we could talk to. And the only people we could
find to talk to– this is 1970s– was the National
Security Agency. And we went down there
and said, help us think through network security. They only had one concern,
which was disclosure control. They said, you know, if
the spy steals the stuff, it’s gone, man. So you’ve got to just
have 100% attention to disclosure control. And what that meant–
and by the way, the integrity on the internet’s
really easy, because what comes out is supposed
to be what goes in, and you can usually tell. But their attitude
was, you know, if you think you’ve got a data
leak, just turn the network of, because it was not at
the time operationally central to what they do. So there’s a tremendous
gravitational pull to confidentiality or
disclosure control. But there are three
elements to this story. There’s disclosure
control, there’s integrity, and there’s availability. This is called the
CIA triad, which is not to be confused with the
Central Intelligence Agency. And availability is an
element of security. You can’t solve availability
by sprinkling crypto on it. It doesn’t work. Availability involves using
resources that are trustworthy. If there’s a DNS that’s
sending you to the wrong place, you have to be able to know
enough to stop using it. If you’re being routed
through an inappropriate part of the internet, you have
to be able to avoid it. We do not have in
computer science a general theory
of availability. But if you look at what my
security friends have done, they have paid a great
deal of attention to disclosure control
and integrity, and they have absolutely
screwed up availability. I had an interesting little
annoying event the other day in which I was trying to
download an update of a Python module. And I went to it,
did all the things. You know, pip install. Whatever the hell you type. I don’t remember what you type. And the thing came
back and it said, the signing certificate
for the code is invalid. It’s probably out
of date, and so you can’t download the module. I said, what? What’s plan B? There was no plan B. You
can’t download the module. And I’m sure my security friends
thought, good day’s work. OK? We prevented with a
very low probability– almost certainly,
the certificate was out of date because
the guy’s an idiot and he didn’t update it. It’s a 0% chance that it
was actually malicious, but they stopped me cold. Now my attitude is,
they carried out a 100% successful
security-related attack on me along the dimension
of availability. And consumers– I’m sorry. I hit that word. Users, what they want to
do is get their job done. And we keep saying,
why do people click through these warning boxes? Never mind that the warning
boxes are inexplicable. They click through
them because they have to get their job done. And anybody who has designed
a security system which stops the user dead and
doesn’t give them a plan B has failed Security 101. But that’s not the
way we teach it, because we focus on integrity
and disclosure control, and so we sprinkle crypto on
everything and hope it’s done. Flame off. The other thing I want
to say about security– and there’s a long
chapter about this– is this idea of being attacked. I attach to a website. It sends me malware. Some of my friends
who are very technical say, yeah, we
really have to focus on the correct implementation
of applications. You know, they too can
have buffer over us. Oh my God. Don’t tell me about
another buffer overrun. The misbehavior you get,
let us say, on the web today is not because of
implementation bugs. It’s because of bad design. No, I’m sorry. It won’t take back. Not bad. Because of deliberate
design decisions. That is to say, the way
the system functions is insecure by design. Now that shouldn’t
surprise you, because it’s very hard to imagine
anything as complicated as the web that doesn’t
have risky modalities. I mean, I can hit somebody
on the head with a hammer. So the risky modalities in
the web are not surprising. But in fact, conscious
decisions were taken to put functionality
into the web that was known to be risky. When the idea of downloading
active code first came up, every security person I knew
was standing on the sidelines, saying, that’s the stupidest
idea I’ve ever heard. You’re all going to die. You’re all going to die. Why would you download code from
somebody that you don’t know. You know? We tell our kids, don’t
take cookies from strangers. Why would you take
code from a stranger and run it on your computer? And we actually talked
to NSA about this, and they said, inspecting
code to see whether it’s malicious is a fool’s errand. The only way you can reliably
have downloads of active code is that you have a very clear
sense of whether the sender is trustworthy. You’ve got to be embedded
in a space of trust. But if we have risky
modalities in the applications, you can’t expect the
packet layer to fix that. The application guys
have to fix this. And they have to take
the responsibility for understanding how to balance
this feature-rich space that everybody loves– you know, what did you
get for downloading codes? My God, you got flash. You got animated dancing cats. And boy, that’s worth it. Against the security risks. And it is an
application problem. But that’s not something
that is understood when you go to Washington. They say, the internet’s broken. Fix it. OK. And you get some draconian ideas
in Washington, some of which I hope I have
helped to stamp out. I had a Senate staffer
a while back say to me– this sounds like nonsense,
but you understand exactly what he was saying. He said, why don’t packets
have license plates? And I know what he meant. He meant, why isn’t there
some identifier in a packet that a third party
like a policeman can look at to unambiguously
understand who sent it? OK, why aren’t all
actions on the internet accountable to a person? Well, I mean, there are lots
of good answers to that, one of which is socially,
it’s a terrible idea. It eliminates any possibility
of anonymous action on the internet,
and I think there’s a space for anonymous action. Furthermore, who would
issue those identities in a global world? Almost certainly,
sovereign states would assert their right
to issue those identities. So what would it mean if I
have a packet that goes by and it says that the
identity of this– the sender of this packet is verified by
the sovereign state of Iran. Do I feel better now? But if you don’t have an
accountable internet, what do you have? And there’s been very little
attention paid to this. So although my book
is about internet, I actually spend
a certain amount of time talking
about applications. And one of the projects
we’re currently doing at MIT is to see whether we can
think in a more methodical way about how to help
application designers deal with this trade-off
between embedding risky actions because
they’re feature-rich and dealing with the fact
you only want to use them in a context where the people
you’re communicating with, you trust. So the book has some
of my personal history. I talk about stories
from the 2000s as well as the 1900s and 2010s. There’s a chapter on, what
does it mean for a network to meet the needs of society? Chapter on requirements. We have one on
management, as I said. Availability,
security, longevity. And then there is a discussion
in the book of alternative. So why– and I’m going
to stop in a second. Why are people proposing
alternatives to the internet? It actually does what
it does pretty well. And what it does is move packets
from machine A to machine B. The reason they’re
proposing alternatives is because they wanted to
do something different, not because they think it
could do exactly what it does better than it does. And they want to put
more features in, because that’s what
engineers always want to do. They want to add features. People here familiar with
the expression second system syndrome? It’s when you built a system
that sort of does something pretty well, and you say, I’m
going to build a second one. It’s going to do everything. No. Fail. OK. So what have they
talked about putting in? Well, one thing that
they’ve talked about adding is, well, you send a
packet to a machine, but most people don’t
want to get to a machine. They want to get to a service
that’s on the machine, or they want to get to some
information on the machine. So why don’t we tell
the network what service you’re trying to get to? Or why don’t we tell the
network what information you’re trying to get to? Why don’t packets have the
names of information in them? This is an idea that’s been
around for a long time. I think it was first proposed
around 1995 by David Cheriton, I think. It now goes by the name of
information-centric networking. And it creates a really
interesting problem. How do you build
a routing protocol that can route to a
few billion things, as opposed to the internet
today, which is routing to a few million things? But that’s not the real
interesting question. The interesting
question is, do you want to give– do
you, Mr. Google, do you want to
give to the network the control over
where the network goes to retrieve a piece
of information, or do you want to keep that
control inside your firm? Protocol design is actually over
industry structure and balance of power. And there’s a lot of
discussion in the book that adding more
features to the network may, in fact, be empowering
the wrong person, whether it’s a state that would like
to carry out surveillance or an ISP that might like
to manipulate to get money across that money insulator. And the future is not being
defined by technology. The future is being
defined by these forces. Economic forces,
political considerations, contention in the
industrial space. And that’s why I’m
no longer running a purely technical group. But I think I
should stop and take questions for a little while. AUDIENCE: I had heard some
interesting stories about how they originally set up
protocols between the big ISPs to transfer packets
between each other. I had heard that the fact
that at zero cost between them was an interesting story. Have you heard that one? DAVID D. CLARK: Ha. In the original structure
of the internet, little ISPs bought
servers from big ISPs. We call that service transit. Other people might
call it long distance. You pay them and they
get you everywhere. But the ISPs that
are at the top have to interconnect in order
to exchange traffic with each other. Now that’s not getting
to the whole internet. That’s just getting to, I
want to get to your customers, and you want to get to mine. And there is an
apocryphal story, which I think is in the book,
but it’s an apocryphal story– I can’t figure out
whether it’s true– that those first few commercial,
wide area internet providers had to figure out the
business terms on which they were going to interconnect. So they understood
the technical terms on which they [INAUDIBLE] the
business terms of the issue. And they got together, and
there was a conversation. And at one point,
so the story goes, one of the guys in
the room said, oh. I thought you were
going to pay me money. And it’s complicated
when you’re having a conversation with somebody
and you’re bargaining, and you don’t even know which
way the money’s going to go. A friend of mine totally
broke a car dealer. It was just amazing. He wanted to buy a
new car, and so he was trading in a used car. But his mother had
recently reached that age where she can no longer
drive, so he actually was trading in two
cars to buy a new car. And when they worked
out the bargain, he got the car and the
dealer had to give him money. And the dealer said,
you just broke my brain. I understand the math,
but if I give you the car, you’re supposed
to give me money. The idea that I’m giving you the
car and I’m giving you money– it just stopped him totally. So there was a
conversation in which somebody said, wait a minute. I thought the money was
going to go the other way. And so as the story
goes, all of a sudden, the people in the room who
were technical businessmen suddenly realized that if they
let the lawyers in the room, there would be a
three-year negotiation. And so they stood
up and said, quick, before the lawyers get
here, I don’t pay you. You don’t pay me. Shake hands. We interconnect. Let’s get out of here. And thus, so it is said,
revenue-neutral peering was born. Now that’s been disputed
over and over and over again. The latest dispute,
of course, being whether people like
Google and Netflix have to pay to
interconnect with ISPs. And that was three years ago. It was a serious, nasty dispute,
which led to lots of congestion on the internet. Some other questions. AUDIENCE: Sure. So as two pieces. One is when you
talk about security, one of the more recent
excitements at least, for instance, around the TLS 1.3
has been the conflict between end-to-end security and
folks who are, for instance, running a data center and
need to know what’s going on in their data
center, or wanting to– so there’s end to end,
but then there’s also, you’re running
across my equipment. I need to know what
you’re doing or what’s being done so that bad
actors can’t come in. And then another piece that’s
somewhat correlated to this– and I’m curious to
your viewpoints– is the tussle that’s going on
now between network management and visibility versus– so pervasive
encryption versus being able to manage the networks
in a reasonable fashion, and how to manage
that discussion. DAVID D. CLARK: I don’t
have definitive answers to either one of
those questions. The questions are
very well formed. When a data center
says, I want to be able to see what
you’re doing, I want to be able to see
what people are doing, or some actor says, I want to be
able to see what you’re doing, that is the fundamental tension. Who is responsible
for protecting me? If I’m talking to
you and I trust you, and you and I have an
encrypted conversation, I don’t want a third party
looking at what we’re doing. Now am I messing
up their system? Well, that’s an issue
that they have to police. Do they have to see
exactly what I’m sending to see whether they’re
messing up the situation? If I think you may
be attacking me, then end-to-end encryption
is the whole wrong idea. I mean, I explain this
by a real world analogy. If you’re sending me
letters, you probably assume that you don’t want
somebody opening those letters. But if you think they’re full of
anthrax, then all of a sudden, oh, I do want– yeah. And I want them dressed in a
hazmat suit and well trained, and they know exactly
how to deal with it. And that, in fact, is
the tension between two of the fundamental
security goals that you and I ought to be able
to have a secure conversation if we trust each other. And it would be lovely
to have a third party to protect me if I think
you’re going to attack me. And the transition there
is not under the control of a third party. It should be my decision
about whether I trust you or my decision about
whether I would like a trusted third party
protecting the transaction. So I don’t want people
unilaterally saying, my job is to look at
everything you’re doing. I want them to say,
hey, I want you to do something [INAUDIBLE]. I don’t trust this person. Now the question of
network management, that’s come up again
and again and again. And I have to say, I am
reasonably not sympathetic to the more extreme
arguments that say, I have to be able to
see everything you can do, so I manage it. I think in particular, what’s
going on in the mobile networks today where they’re
recoding the video and doing all this kind of stuff
reflects the fact that we made some bad engineering decisions. And the incredible capacity we
have in the wireline network is not matched by
the capacity we have. You know, the wireless
network, they’re just capacity constrained. And so they say, we have to
engineer our way out of this. And because there is
this barrier between what the application guys
are prepared to do and what the network has to
do, the system is– again, there are these
protocol interfaces. They have to say, well, I
have to fix these problems, but I sort of have to
fix them on my own. So I’m going to try to
figure out what you’re doing and transcode it and
all this kind of thing. And the wireless
guys for a long time have been saying, you know,
this layered model sucks. Because if we had better
integration between what the application guys did and
what the network did, then, in fact, the
application guys could do a better job of helping
us manage our network. But those are different
firms, and they may actually be in competition
with each other. So in the end, there’s
a technical problem, which is a lack of
standards to create cross-layer coordination. But there’s also a
tension between companies that, in fact, have
adverse interests. And I don’t believe we should
sacrifice end-to-end security as a stopgap there. We should force people to solve
the problem the right way. Which is to say, let’s
build new protocols that go across layer– that provide the transparent
performance information across layers. This woman looks like
she wants the mic back. [LAUGH] I saw her reaching out for it. AUDIENCE: Sorry, yes. Yes, I completely agree that
one shouldn’t sacrifice. But there’s a challenge both in
it going the other direction, and also if we want to have
protocols communicating between the applications
to the network, then it becomes a trust but
verify kind of challenge. And what information
do you want to put in? Like, with [? quick, ?] there
was a whole discussion about, is it safe to expose a single
bit of information that could be used to determine
round trip times, right? So there’s a challenge
of, what information is– how do you agree on
what information is safe to expose to the network? And how does the network
trust that information from the application when
there’s not a potentially cost or economic or other
type of challenge to requesting as
much as you want? DAVID D. CLARK: And
that’s a very tricky one, because there’s no
venue in which we can have that discussion today. If you go to the IETF– although IETF is
slowly shifting. They’re incredibly uncomfortable
having a conversation whose motivation
relates to what I might call industry structure. The– do you disagree? AUDIENCE: I think there’s some
pieces that are shifting there. DAVID D. CLARK: There are
pieces that are shifting. I agree with that. But to have a conversation
in which different actors with adverse interests get
together and design a protocol is a very tricky thing. You need some very
fair-minded people who are sitting in the
middle to basically try to arbitrate this
thing, and I don’t think we have the structure to
try to make that happen today. I certainly ran into that. I’ve run into that over
the years multiple times. Well, let’s take
some other questions. I saw somebody with
a hand over here. AUDIENCE: So you mentioned
the insecurity of BGP as an example of an instance
where you have a problem where you would need multiple
ISPs to adopt technology to improve something. But if you have
just one on board, it doesn’t get you
anywhere, and so they don’t want to be the first one. So in that case or
anything similar, do you think there’s
any possibility of positive progress being made
with government regulation, saying, hey, by
2025, you all need to support SBGP if you’re
going to operate in America, for instance? Or is that a dead end? DAVID D. CLARK: The question
is, how much does it help if we do it domestically? You know, if traffic
from a Google site ends up in Russia
because some packet which was either erroneous or
malicious emerges from Nigeria, you know, probably
the traffic was not originating– that Google
traffic was not originating in the United States. It was originating at a Google
cache somewhere in Europe. I don’t know where. On the other hand,
you could say, at least we could secure
the domestic experience. And maybe when
people go overseas, they should understand that
it’s going to get worse. I think– let me
give you an analogy. When we came to understand that
there were certain certificate authorities that
were not trustworthy, the Chinese, a subsidiary that
was issuing fake certificates saying that Google’s over
here and Facebook’s over here, we’re the sovereign
state of China. We’re going to do
whatever we want. And they don’t necessarily
say, and by the way, we don’t like you very much. But the implication
there is if we’re going to attack Google,
that’s our sovereign– what are we going to do? OK. So what you guys proposed
was certificate transparency. And the idea behind certificate
transparency is you can issue– you, Mr. China, can issue
any certificate you want, but you have to put
it in the public log so that anybody can see it. And our browser won’t
honor that certificate unless it’s also in the log. So you can lie, but you
can’t lie in private. And we’re putting using social
discipline, which is actually a better way to try
to discipline a trust space than technical tools. OK. And some of the most interesting
proposals to deal with BGP do not involve adding SBGP
or something like this. They involve various
kinds of public logs. Which, if you choose
to put something in it, will make your world
better if I check it. And it becomes voluntary. So I think the way
we’re moving is probably not to have continuing
fights over secure BGP, secure origin BGP,
all that stuff. But perhaps something
that sits alongside it, which is kind of a log system
in which the actors that are interested in
improving their security have an action they can take. That is to say, it’s
in their interest so we don’t have this
misaligned interests. But I think that’s the way to
make progress in this space. AUDIENCE: And I apologize if
this sounds like trolling, but when you say public
log, do you mean blockchain? DAVID D. CLARK: No. Look at what Google’s done
with certificate transparency. It is not blockchain. Google is saying, trust me. Actually, they’re not. They’re saying,
trust any two people. Trust any two organizations,
one of which is Google. The certificate
transparency log, you have to write
your assertion, either the fake or the real
one, to two logs, one of which does not belong to one, and
one that belongs to Google. So no, it does not
have to be blockchain. Blockchain to me
in almost all cases is overkill, whether you
think it’s a good idea at all. To me, blockchain is an example
of somebody trying to design– I was talking about applications
that have risky modalities. To me, blockchain is
an example of somebody trying to build a
restricted application functionality into a
system in which nobody has to trust anybody. You know, I can do– look. The basics, it’s
just like, you’re going to pay me money, right? And you and I have to have no
trust in each other whatsoever, because we trust the mechanism. It’s a purely technical
solution to creating a trustworthy transaction
in a trust-free space. The real world doesn’t
usually work that way. The world actually works
much more efficiently, because it’s willing to make
a few trust assumptions. And I don’t know what
China thinks about Google, but most people are
willing to believe that the certificate
transparency log that Google runs–
which, in fact, is blockchain in the sense
that it’s forward change. You can’t go back
and change things. It’s not literally a
blockchain, but it’s a forward changing protocol. And by the way,
the reason Google did that is to
protect themselves. That is to say, somebody
could come to Google with a court order
or a small nuke and say, I want you to go
in and change that entry. They can’t do it in a
way that can’t be seen. They can’t fake an entry,
even if they’re being coerced. So the structure of the thing
protects them from coercion. And I think that was actually
a more important engineering decision than Google
is not trustworthy. But that makes it more
trustworthy, because look. They say, you
know, we can’t even be coerced into changing
the [INAUDIBLE].. So it’s blockchain-ish,
but it’s certainly not a zero trust blockchain. SPEAKER 2: Please join
me in thanking Dr. Clark. [APPLAUSE]

Danny Hutson

5 thoughts on “David D. Clark: “Designing an Internet” | Talks at Google

  1. I'm only studying for my Network+, and so, I have a very beginner understanding of networking and IT. But even I found this really interesting.

  2. I love how Google disables comments on any remotely controversial video. I hate hearing any opinions that go against my own. Thank you for protecting my fragile ego Google. I don't know what I would do without you

Leave a Reply

Your email address will not be published. Required fields are marked *