►
Description
Suzanne Woolf moderates the Internet Architecture Board's Technical Plenary at IETF 97 in Seoul. Nick Sullivan of Cloudflare and Andrew Sullivan of Dyn provide background and insights. An active Q/A and comment session follows.
A
A
A
It
was
obvious
that
there
were
things
to
learn
here
that
went
beyond
one
large
providers,
no
good
very
bad
day
or
the
challenges
in
providing
one
particular
service
to
the
modern
Internet.
This
was
an
attack
on
part
of
the
internet
architecture
itself,
so
we
asked
Nick
Sullivan
here
to
Nick
Sullivan
to
come
and
talk
with
us
from
cloudflare.
A
We
also
asked
our
own
Andrew
Sullivan
to
speak
to
the
subject
both
because
and
in
spite
of
him
being
an
employee
of
dying,
the
provider
who
was
attacked
and
an
IV
member,
so
he's
here
in
both
capacities,
but
we're
hoping
both
of
them
will
provide
some
insight.
Some
perspective
on
masculine
or
net
attacks,
but
primarily
we
think,
there's
some
underlying
and
concerning
observations
to
make
here
and
would
like
to
see
some
discussion
of
the
implications
of
perhaps
new
insight
on
vulnerabilities
of
the
architecture
of
the
Internet
itself.
B
Okay,
hello,
everybody
thank
you
for
having
me
I'm
Nick
Sullivan
from
cloud
player,
I'm,
going
to
kind
of
go
over
some
lessons
that
we've
learned
in
terms
of
this
is
coming
on
sun
in
terms
of
dealing
with
large
attacks
and
really
staying
online,
so
the
talks
called
how
to
stay
online
and
it's
it's
starts
with
starts
with
a
little
bit
of
a
dark
tone,
but
d
dos
it
exists
and
it's
going
to
be
part
of
all
of
our
futures
and
running
infrastructure
is
difficult,
especially
in
a
hostile
environment
and
I.
Think.
B
The
main
reason
that
I'm
here
is
is
can
be
described
in
this
Twitter
account
if
you
follow
it.
This
is
this
shows
the
MER
I
botnets
and
all
the
attacks
as
as
they
go
on
live,
and
this
is
not
something
particularly
new.
Botnets
exist,
they've
existed
for
a
long
time.
This
is
just
an
example
of
botnets
at
a
larger
scale
and
they
send
a
mix
of
attacks.
So
when
you
think
about
DDoS
or
when
you
talk
to
someone
about
D
dust,
this
is
really
what
you
think
about.
Generally.
B
Is
this
sort
of
reflection,
amplification
attack
using
some
amount
of
compromised
machines
and
reflecting
off
of
a
protocol
that
does
not
valid
valid
a
source
address,
perhaps
using
UDP
ntp
and
DNS
or
two
of
these
examples?
And
this
this
still
goes
on,
but
it's
not
really
the
majority
of
the
type
of
attacks
that
we
see
nowadays.
So
what
I'm
going
to
cover
here
is
the
popular
txt.
We
see
now
in
2016
what
what
are
people
actually
doing
and
these
break
down
into
three
main
categories.
Some
of
these
are
old.
B
Some
of
these
have
been
around
forever.
This
is
these
are
not
they
shouldn't
be
new
to
anyone
but
I'm,
going
to
describe
ways
that
when
you
see
a
tax
of
these
types,
add
magnitudes
that
are
very
large
what
you
can
do
so
dns
flood,
syn
floods,
https
flood
I,
don't
have
to
explain
to
anyone
in
this
room
how
DNS
works,
but
when
it
comes
to
attacks
on
DNS,
there
are
two
main
types.
First
is
direct
attacks
on
the
authoritative
dns
server
from
a
botnet.
B
B
The
question
is:
if
you're,
faced
with
a
flood
of
requests
at
your
authoritative,
dns
and
they're,
not
from
resolvers
that
you
know,
then
you
should
be
very
suspicious.
The
DNS
architecture
is
built
to
go
from
the
endpoint
stub
resolvers
to
be
recursive
resolvers
to
the
authoritative
dns,
and
if
you
see
a
lot
of
packets
and
a
lot
of
requests,
you
should
probably
just
drop
them,
and
this
is
potentially
safe,
and
this
is
really
the
only
way
to
stay
online
for
direct
to
authoritative
attacks.
B
B
B
Dns
flood
survival
kit,
so
this
is
this
is
one
idea.
This
is
one
one
thing
that
used
to
be
done
quite
a
lot
for
actually
protecting
aids,
these
type
of
large
attacks
and
that's
no,
no
routing
ip's.
You
take
the
IP,
that's
under
attack
and
you
advertise
it
upstream
so
that
it
basically
falls
off
the
internet.
This
is
a
pretty
dangerous
thing
to
do
and
it
has
lots
of
cushions
lately.
Attackers
have
been
flooding
entire
subnets,
making
this
very
unreasonable
in
terms
of
of
a
defense
mechanism.
B
Furthermore,
these
glue
records
that
you
use
to
point
to
your
DNS
servers.
They
have
long
ttls
and
changing
them
is,
is
not
something
that's
very
feasible
at
the
moment.
So
this
is
not
something
I
would
recommend
at
the
current
point,
but
there
are
two
main
techniques
to
keep
yourself
up.
If
you're
running
this
sort
of
authoritative
DNS
infrastructure,
the
first
is
spreading
the
load
and
then
the
second
is
filtering,
filter,
fast
and
filter.
Often
one
way
to
spread
the
load
is
to
run
any
cast
network.
This
allows
you
to
spread
the
load
geographically.
B
Network
hardware
does
not
scale
linearly
in
price.
If
you
have
a
10
gig
piece
of
hardware
that
it's
not
going
to
cost
ten
times
more
to
buy
a
hundred
gig
version,
it's
it's
really
horizontally.
If
you
can
make
sure
that
the
amount
of
traffic
at
each
of
your
data
centers
is
low,
it's
cheaper,
it's
easier
to
handle
spreading
the
load
not
only
geographically,
but
within
the
data
center.
B
Ecmp
is
a
good
way
to
do
this
filtering
packets,
going
down
from
the
top
of
the
rack
to
the
actual
DNS
application
filters
as
early
and
as
soon
as
you
can.
There
are
different
mechanisms
you
can
use
at
different
levels
that
can
handle
different
amounts
of
packets.
If
you're,
if
the
request
gets
to
your
DNS
application,
you
might
as
well
just
answer
it
at
that
point.
So
the
main
point
of
handling
the
main
way
to
handle
large
flood
is
to
make
sure
that
only
legitimate
packets
get
to
your
application.
B
There
are
a
number
of
ways
of
doing
this.
One
is
iptables
BPF
rules.
These
are
very
powerful
techniques
that
you
can
use
to
match
and
block
packets
inside
the
kernel,
and
these
can
be
automated,
which
is
very
important.
There
are
tools,
open
source
tools
to
create
BPF
rules
that
match
attax,
but
this
is
not
something
that
works
with
a
static
configuration.
B
You
really
have
to
move
fast
and
and
change
them
at
very
often,
because
if
you
have
too
many
rules,
it
can
cause
problems
in
in
other
situations,
so
heuristics
machine
learning,
attacks,
change
the
attacks
that
you're
going
to
see
from
one,
but
Annette
are
not
the
ones
that
you're
going
to
see
from
the
other
one
and
it's
going
to
change
from
time
to
time.
So
this
has
to
be
very
dynamic,
but
you
do
have
the
ability
to
sample
from
different
places
to
see
what
the
types
of
attacks
signatures
are
and
figure
them
out.
B
B
Dns
floods
are
sort
of
very
closely
tied
to
this
other
type
of
attacks
which
are
taxed
to
go
through
the
recur,
sir.
This
is
when
which
attackers
will,
from
their
botnet
sent
attacks,
send
DNS
messages
that
end
up
at
your
authoritative
server,
but
they
go
through
recursos.
This
is
very
different.
You
do
not
want
to
block
and
drop
these
attacks.
The
right
response
is
to
answer.
Recursive
DNS
is
and
is
making
requests
for
legitimate
customers,
and
they
treat
what.
However,
you
answer
their
requests
as
relevant
state
for
them.
B
So
if
it's
possible,
the
whitelist
known
recursive
DNS
servers
do
so.
This
is
very
helpful
and
the
right
thing
to
do,
because,
if
you
rate
limit,
this
can
cause
some
negative
effects,
including
an
amplification
of
of
the
request,
as
the
recursive
preservers
try
to
test
to
see
whether
you're
back
online
or
not,
if
so
rate,
limiting,
is
not
a
very
effective
method
for
this.
Really,
you
have
to
handle
the
packets
one
technique
that
was
suggested,
for
this
is
every
request
that
comes
through.
B
Dns
attacks
are
not
the
only
types
of
attacks.
What
made
this
botnet
and
a
lot
of
the
current
attacks
very
damaging
is
that
they
go
through
multiple
protocols
and
multiple
types
attacks,
sin
floods.
This
is
classic.
This
is
this
has
been
around
forever,
but
it's
it's
still
very
effective.
If
you
don't
configure
your
tcp
stack
perfectly,
it
can
cause
some
serious
problems
using
BGP
Annie
cast
on
the
TCP
side.
B
Also
lets
you
say,
I
understand
which
regional
non-regional
IPS
you
should
expect
send
packets
from,
and
there
are
IP
IP
tables,
vpf
rules
that
you
can
build
for
this
as
well.
So
sin
floods
also
very
difficult
to
handle,
but
they're
often
mixed
with
the
DNS
attacks.
Https
floods.
This
is
much
more
common
and
this
takes
up
server
resources
by
sending
HTTP
requests
over
an
established
connection.
B
The
good
thing
about
HTTP
is:
is
it
handles
rate-limiting?
Very?
Well,
you
can
rate
limit
by
request
rate
limit
by
volume
and
for
these
types
of
attacks,
a
simple
tcp
reset
will
get
you
a
long
way.
If
the
attack
is
https,
the
attackers
may
try
to
take
advantage
of
some
asymmetry
of
the
cryptography
and
there
are
ways
to
mitigate
that
using
elliptic
curves
as
one
there
are
proposals
for
things
like
client
puzzles,
but
those
are
not
implemented.
B
So
it's
probably
going
to
get
worse,
though
there
are
ways
to
think
that
it
may
end
up
getting
better
one.
One
key
thing
is
for:
if
there
is,
there
is
a
viral
aspect
to
this.
So
if
you
have
a
device,
that's
going
to
be
compromised,
it
has
to
be
found
to
be
compromised.
Ipv6
has
a
place
here
in
making
things
difficult
to
to
find
by
scanning
the
entire
internet.
B
Building
these
IOT
devices
is
really
really
closely
tied
to
the
economics.
Margins
are
very
thin,
so
things
like
a
secure
by
default,
open
source
software.
If
that
was
available,
people
would
use
it
investing
less
time
in
in
development,
helps
your
margins
secure,
firmware,
update
life
cycles.
These
things
are
very
hard,
as,
as
we've
seen
from
from
the
windows
desktops
to
iOS
to
Android,
it
takes
a
long
time
a
lot
of
perseverance
in
a
lot
of
developer
effort
to
build
these
ecosystems
that
allow
you
to
update
these
software
software
pieces.
It's
it's
not
sure.
B
It's
not
clear
that
in
the
IOT
case
that
this
is
something
that
is
in
the
near
future.
Another
piece
is
attribution
if
you
know
where
the
attacks
are
coming
from
currently
source
IP
is
something
that
can
be
spoofed.
Net
flow
is
something
that
can
help
identify
real
sources
even
without
source
IPS.
This
is
something
to
think
about
now:
I've
kind
of
described
some
technical
ways
to
protect
against
ddos
and-
and
these
shouldn't
really
not
be
new
to
anyone
here.
B
Enterprises
is
to
not
have
to
pay
a
lot
of
money
for
these,
these
very
large
attacks.
Luckily
many
internet
protocols
are
asymmetrical
and
they
have
great
caching
semantics
broadcast
HTTP,
for
example.
So
you
have
extra
extra
capacity
on
ingress
if
you're
mixed,
if
you're
using
multiple
protocols
in
the
same
data
center
scrubbing
centers.
Sometimes
these
can
be
very
expensive
because
they're
single-use
and
you
pay
for
the
maximum
of
the
bandwidth.
So
it's
it's.
B
It's
good
to
spread
things
out,
keep
things
spread
out
and
distribute
the
load
and
filter
early,
and
this
is
sort
of
a
sunny
final
end
to
this.
But
I
wish
it
wasn't
this
way,
but
staying
online
now
requires
scale.
So
this
is
this
is
something
where
you
have
to
be
big.
You
have
to
be
smart
and
you
have
to
have
tools
and
you
have
to
work
together
with
other
people
to
try
to
stop
the
attacks
close
as
possible
to
the
edge
and
the
techniques
I
described
here.
Try
to
approximate
this
as
much
as
possible.
B
It's
it
is
possible
to
survive
these
large
attacks
and
it
is
possible
to
survive
in
an
internet
ecosystem
and
with
attackers
have
exceedingly
large
bandwidth.
But
this
this
involves
really
paying
attention
and
doing
things
right
on
multiple
levels,
all
the
way,
through
your
stack
and
thinking
about
your
architecture
and
building
things
so
that
they
can
handle
it,
and
that's
the
end
of
my
sunny
presentation.
Thank
you.
A
C
C
So
this
is
this:
is
the
problem
with
naming
you
see
that
you
need.
You
need
unique
names.
We
should
have
had
a
hierarchical
system
and
then
everything
would
have
worked
up.
So
so
I
want
to
talk
a
little
bit
about
about
what
happened
during
this
bad
day
and
then
I
also
want
to
talk
a
little
bit
about
what
it
means
for
the
internet.
C
So
what
happened?
Okay
well
on
these
were
attacks
against
some
dine
in
infrastructure,
and
it
was
noticed
because
on
there
were
some
systems
that
depended
upon
us.
You
know
customers
on
and
and
and
that's
what
happens
you
know
you
get
one
of
these
things.
Nobody
knew
about
us
at
all
before
before
this
event
and
our
marketing
people
are
really
of
two
minds
about
this
whole
thing.
Right.
C
C
I
have
you
know
I'm
now
useless
to
my
employer,
and
what
this
meant
was
that
our
NOC
and
the
operations
people
did
all
the
work
and,
like
you
know,
knocks
and
operations
people
do
whenever
there's
a
crisis,
they
did
a
great
job,
so
I
want
to
thank
them
and
also
a
couple
of
people
that
dine
Chris,
Baker
and
Phil
Stanhope
in
particular,
fed
me
some
of
these
things,
so
they
fed
me
this
stuff.
But
of
course
the
conclusions
are
mine
and
all
the
mistakes
are
mine.
C
In
any
case,
this
led
me
to
some
questions
about
about
the
DNS
infrastructure.
Now
our
infrastructure
is
an
any
caste
based
system
that
is
mostly
transit
driven.
There
are
reasons
for
that,
but
the
primary
thing
is
that
we
we
did
this
because
we
had
a
system
that
allowed
us
to
do
certain
kinds
of
management
to
avoid
exactly
this
kind
of
problem,
so
it
didn't
work
out
in
this
case,
but
in
the
past
it's
worked
very
well
for
us
and
the
on,
and
the
point
of
this
is
to
get
this.
C
This
system,
which
is
fairly
large,
it's
it's
it's
in
18
sites
and
and
the
the
diversity
of
this
thing
was
arranged
in
such
a
way
that
you
didn't
tend
to
have
on
this
kind
of
problem.
So
what
happened
on
on
the
21st
of
October
about
1110
UTC?
We
had
a
thing
start
up
and
was
like
the
normal,
normal
D
das
and
he's
happen
all
the
time
it
was
targeted
me.
C
You
know
across
our
systems
and
the
NOC
started,
doing
the
usual
run
books
that
they
always
do
for
this
kind
of
thing
and
then
suddenly
the
whole
thing
changed
and
it
moved
to
this
u.s.
East
region.
You
know
we're
doing
the
same
dns
tricks
that
everybody
else
is
doing
in
this
area.
So
we've
got
these
regions
and
what
happened
was
there
were
way
more
addresses
than
normal,
but
also
the
attack
pattern
was
a
little
different
than
normal.
I'm
going
to
talk
about
that
in
a
minute,
so
this
caused
some
resolution
failures.
C
That
is
things
just
didn't
get
answered
and
also
it
caused
some
long
latency
on
things
which
those
of
you
who
are
familiar
with
the
dns.
You
know
that
if
the
latency
is
long
enough,
it's
just
like
the
thing,
isn't
there,
because
you
just
ignore
it.
This
lasted
until
about
13
20
UTC,
and
then
we
had
another
one.
So
this
you
know
we
put
in
some
mitigations
and
the
mitigations
worked
and
the
the
attack
stopped
and
they
were
mopping
up.
C
The
way
knock
always
does,
and
of
course,
while
they
were
mopping
up,
another
attack
started
only
this
targeted
all
of
the
servers
in
the
world
that
we
had.
So
we
knew
a
little
bit
about
how
this
thing
had
worked
and
but
of
course,
we
hadn't
actually
made
the
changes
globally.
So
naturally
it
was
still
widely
observable.
This
we
recovered
by
about
1700
UTC,
but
there
was
some
sort
of
hangover
that
we
still
haven't
completely
figured
out
what
what
happened
there.
C
C
So
what
was
unusual
about
this
was
actually
that
you
know.
We've
seen
lots
and
lots
of
sort
of
standard
amplification
attacks,
but
this
particular
attack
had
a
really
really
high
proportion
of
tcp
and
we
don't
normally
see
that
in
these
kinds
of
attacks,
because
normally
it
involves
a
lot
of
state
on
the
attacker
side
as
well.
So
they
don't
do
it
and
there's
very
little
spoofing
on
in
this
or
I
shouldn't,
say
very
little
but
comparatively
low
spoofing.
C
We
have
definitely
confirmed
40,000
addresses
involved
in
this
botnet,
but
maybe
something
like
a
hundred
thousand
addresses
in
the
botnet.
Now,
you're
probably
saying
to
yourself
gee:
that's
not
a
very
big
buck
net
on,
but
think
a
little
bit
about
DNS
and
TCP
and
what
happens
when
you've
got
a
hundred
thousand
members
of
your
botnet
and
they're
all
opening,
say
ten
TCP
connections
to
your
DNS
servers
and
you
can
see
how
this
thing
can
can
expand
fairly
quickly.
The
other
thing
about
this
was,
of
course,
as
we
started
to
have
problems.
C
We've
never
had
this
problem
before,
but
on
the
recovery
retransmissions
by
some
of
the
resolvers
actually
served
as
a
sort
of
second
front.
So
we
got
this
sort
of
second
wave
amplification
which
caused
us
some
problems.
We
definitely
had
a
mere
I
bet
on
baseball
net.
We've
done
done
a
bunch
of
forensics
on
this.
C
We've
identified
pretty
much
where
these
things
were
and
and
not
who
was
behind
it,
and
we
still,
as
I
said,
don't
exactly
understand
what
this
hangover
was,
but
it
did
cause
a
sustained
outage,
even
though
everything
was
up
and-
and
we
haven't
completely
explained
that
I
want
to
emphasize
that
I
do
not
believe
this
is
a
one-off.
On
the
there
was
a
previous
attack.
Just
you
know
a
couple
of
weeks
before
this.
That
was,
you
know
very
very
large.
C
We
saw
we
know
that
the
mere
I
bought
nut
code
is
out
there,
but
you
know
it's
is
being
improved
upon
by
by
various
people,
but
it's
not
the
only
botnet
code.
That's
out
there
either
right,
I'm
sure
you
all
have
your
favorite
ddos
example.
So
what
showed
up
in
the
press
was
Internet
of
Things
takes
down
these
people
and
that's
what
the
problem
is.
Internet
of
Things
is
bad
and
evil
right
on,
so
it's
a
mirror.
I
botnet
and
those
of
you
who
aren't
familiar
with
this.
C
That's
using
these
Internet
of
Things
devices
that
are
easily
compromised,
and
there
was
an
Internet
of
Things
dimension
to
this
attack,
but
I
really
want
to
emphasize
I.
Don't
think
that
that's
the
main
story,
because
this
attack
pattern
uses
the
very
thing
that
makes
the
internet
strong
and
it's
using
it
to
attack
the
way
the
internet
works.
I
think
that
this
is
an
irony
right.
What
we've
got
here
is
an
attack
of
irony
against
the
internet.
It's
it's
astonishing
to
me
so
back
in
the
easy
time.
What
would
happen
is
the
attackers.
C
Would
you
know
by
a
bunch
of
things
in
some
provider
they
would,
you
know,
go
and
check
in
kato
or
something
like
that
and
make
sure
that
spoofing
was
allowed
from
there
and
then
they
would
set
up
their
botnet
and
they'd.
Have
their
botnet
army
and
they'd.
Send
you
a
lot
of
stuff-
and
this
was
a
you
know-
typically
UDP,
and
there
was
a
lot
of
spoofing
and
so
on.
These
were
cheap
and
effective.
C
But
what
happened,
of
course
is
that
people
got
better
at
scrubbing
and
they
got
better
at
soaking
these
things
up,
because
you
know
you
just
you
just
you
just
outrun
them
and
it
turned
out
not
to
be
that
hard.
You
know
the
cost
of
transits
going
down,
cost
of
processing
is
going
down,
and
so
people
said
well
we'll
just
win
this
thing
forever.
C
I
remember
actually
being
mocked
a
couple
years
ago,
when
I
said
that
you're
gonna
run
out
of
money
before
they
run
out
of
compromise
host
and
everybody
said
now
will
will
will
beat
them
well,
I'm
afraid
we're
here.
So
the
first
answer
to
all
of
this
is
to
get
really
big
right.
This
has
been.
This
has
been
the
answer.
What
you're
going
to
do
is
you're
going
to
have
like
you
know,
lots
and
lots
of
any
caste.
C
You
can
have
CDNs
all
over
the
place
and
everything
like
that
and
what
I'm
worried
about
here
is
that
what
we're
building
is
no
longer
an
intranet,
but
in
all
the
Garko
net
that
you
can't
actually
participate
in
running
services
online.
Unless
you
get
really
huge
on-
or
at
least
you
know,
large
enough-
that
you're
spending
a
significant
amount
of
money
on
your
infrastructure.
C
That
doesn't
seem
to
me
to
be
the
internet
that
I
thought
I
wanted
to
build,
and
it
might
be
that
that's
the
thing
that
we've
built
but
I
think
we
better
ask
ourselves
whether
we
should
be
so
proud
of
that.
If
that's
what
we've
got
here,
there
are
problems
with
this.
It
creates
monoculture,
it
creates
the
associated
security
problems.
C
It
also
means,
of
course,
that
the
distributed
nature
of
the
internet
that
we
keep
talking
about
is
no
longer
true,
because
you've
got
these
giant
providers
who
are
involved
with
everything,
and
it
makes
for
high
barriers
to
entry
and
I.
Don't
think
that
that's
a
great
a
great
arrangement,
nevertheless,
I
think
it's
obvious
that
the
Internet
of
Things
is
going
to
create
continue
to
create
these
kinds
of
problems.
It
encourages
this
ubiquitous
connectivity
and
even
very,
very
lightweight
systems.
Things
that
are
not
very
powerful
on.
C
You
know,
have
enough
power
to
open
a
few
TCP
connections
and
and
so
on,
and
you
know
what
they
used
to
say
about
the
budget
right,
like
a
billion
here,
a
billion,
they
are
pretty
soon
you're
talking
real
money.
Well,
the
same
thing
is
true
here:
if
you've
got,
you
know
millions
and
millions
of
these
devices
all
over
the
place,
you're
going
to
have
a
lot
of
compromise
about
hosts
and
and
they
make
they
make
that
available.
C
The
other
thing,
of
course,
I
want
to
point
out,
is
that
this
people
talk
about
the
Internet
of
Things
here,
but
it
isn't
only
that
right.
A
lot
of
the
devices
that
we're
talking
about
aren't
really
Internet
of
Things
devices
so
much
as
there
are
just
consumer
devices
and
their
intended
to
connect
to
anything
at
all,
so
they
don't
have
a
hub.
They
don't
have
a
home
that
they
call
back
to
or
anything
like
that.
They
just
connect
to
anything
they
can
and
those
things
are
compromised
about
as
well.
C
Now
the
vulnerabilities
are
pretty
bad.
One
of
my
colleagues
did
some
did
some
work
on
this
and
discovered
I
mean
we
had
like
4.1
million
unique
a
records
hanging
around,
so
he
did.
He
did
some
poking
at
it.
He
found
ten
percent
of
the
devices
in
the
sample
were
affected.
Now
three
hundred
devices
doesn't
maybe
seem
like
very
much,
but
of
course,
this
was
only
4.1
million
IP
addresses,
which
also
isn't
very
much.
C
The
other
thing,
though,
that
he
noticed-
and
he
put
this
on
a
slide
that
he
presented
some,
where
was
this
use
case-
encourages
owners
to
open
them
to
the
Internet.
This
really
bothered
me
because
it
seemed
to
me
that
the
whole
point
of
this
was
to
connect
everything
to
the
internet.
That's
why
we're
here,
and
so,
if
our
answer
to
this
is
well,
we
really
need
to
discourage
people
from
connecting
things
to
the
internet.
In
order
to
prevent
the
security
from
getting
out
of
control
on
the
internet,
then
we
have
failed
completely.
C
So
remember
that
we
have
this
dumb
network
that
we
wanted
to
build.
We
wanted
to
maximize
the
intelligence
at
the
edge
you
could
still
have
a
dumb
device
or
whatever
you
know,
these
Internet
of
Things
devices
aren't
that
smart,
but
they're
still
supposed
to
be
smarter
really
than
the
network
they're,
not
the
net,
the
network's
not
supposed
to
be
making
the
decisions.
This
is
all
you
know.
It's
got
all
the
usual
good
stories.
You
know
the
permission
list,
innovation
at
the
edge
that
we
all
talk
about
and
so
on.
C
The
problem
is
that
this
is
what
makes
for
the
attack
that
we're
talking
about.
It's
a
really
bad
story.
When
those
end
devices
can
attack
you-
and
it's
not
just
compromise
about
things
right,
you
know
you
could
you
could
do
this
by
leaving
a
lot
of
devices
in
coffee
shops
all
over
the
place
and
they're
all
perfectly
secured,
because
they're
controlled
by
the
bad
guys
that'd
be
that'd,
be
another
way
to
run
this
attack.
C
You
could
do
this
by
compromising
a
whole
bunch
of
you
know,
machines
that
have
not
been
updated
in
a
long
time
and
they've
all
got
ubiquitous
connectivity.
That's
another
way
to
do
this.
There's
lots
and
lots
of
ways
to
do
this.
The
insecurity
of
devices
is
not
the
main
problem.
It's
not
DNS
or
UDP
specific,
so
things
like
bcp
38,
don't
solve
solve
it
and
if
you
add
more
providers,
it
doesn't
automatically
solve
the
problem.
C
It
just
causes
more
barriers
to
entry,
because
what
happens
is
you're
in
an
arms
race
and
you're
in
an
arms
race
against
people
who
have
an
infinite
supply
of
hosts,
so
they
can
throw
at
you
I've
heard
people
already
making
actual
proposals
like
this.
So
the
first
one,
of
course
people
said
well.
The
government
should
mandate
bcp
38,
which
wouldn't
even
have
worked
in
this
case.
So
so
that's
not
a
very
interesting
thing.
C
There
are
people
who
want
to
give
licenses
for
connections
either
to
devices
or
to
humans
that
that'd
be
a
fun
thing
to
do.
We'll
get
a
global,
worldwide
internet
license.
Police
I've
definitely
heard
people
talking
about
and
I
think
this
is
coming
folks,
so
be
ready
for.
It
I
believe
that
people
are
going
to
implement
the
submission
port
for
DNS,
so
large
large
recursive
zar
going
to
get
preferred
access
to
authority
of
servers
and
everybody
else
is
going
to
have
to
talk
to
thrum
through
some
recursive.
C
If
you
think
that
that
we
have
a
problem
in
the
concentration
and
the
mail
in
the
mail
world,
imagine
if
we
do
that
for
the
DNS
too,
and
now
we
have
changed.
You
know
the
nature
of
the
internet
quite
a
lot.
There
are
lots
and
lots
of
things
that
we
could
do
in
order
to
reduce
the
openness
of
the
Internet.
In
order
to
solve
this
problem
now,
fifty
years
ago,
there
was
a
big
change
to
the
automotive
industry
prior
to
the
publication
of
this
book
by
Ralph
Nader
unsafe.
C
At
any
speed,
I
mean
this
book
is
mostly
famous
for
destroying
the
Corvair
right.
Corvair
was
a
car
in
North
America,
and
was
it
destroyed
that?
But
but
the
more
important
thing
that
this
book
did
was
change
the
nature
of
the
automotive
industry
in
North
America
from
an
almost
completely
unregulated
system
where
people
could
build
stuff,
and
they
just
you
know,
put
them
on
the
roads
and
no
big
deal
into
a
very
heavily
regulated
industry
and
and
people
even
automotive
industry
people.
C
So
I
got
a
quote
from
him
right:
Bob
Lutz,
who
was
a
big
automotive
industry
person.
He
has
now
come
to
believe
that
this
book
had
a
seminal
effect,
because
it
made
sure
that
there
was
definitely
a
role
for
government
in
automotive
safety,
Bob
Lutz,
who
opposed
every
single
one
of
the
regulations
that
came
from
this.
He
still
thinks
it
was
a
good
idea.
C
Transformative
technologies
like
the
automotive
automobile
and
like
the
internet,
attract
attention
from
cultures
and
the
culture.
If
it's
transformative
enough
the
track,
the
culture
says:
okay,
we're
going
to
let
you
in
we're
going
to
make
our
our
lives
around
you.
But
what
we're
going
to
do
is
we're
going
to
extract
rules
about
about
what
you're
going
to
do
from
that
we're
going
to
start
imposing
rules
on
you
and
I
think
that
the
internet
is
at
that
point
we're
facing
it
now.
I
think
there
are
things
that
we
could
do
ourselves.
C
One
of
the
problems
with
with
regulating
the
internet
is
that
the
structure
is
not
like
the
automotive
world
right,
so
so
the
car
world,
the
thing
about
it
was
the
cars
are
in
a
place
and
the
and
the
roads
were
mostly
publicly
owned,
but
neither
of
those
things
is
true.
On
the
internet,
the
the
infrastructure
is
mo,
firstly,
privately
owned
and,
of
course,
the
way
that
the
structure
works,
the
network
of
networks
of
networks,
and
so
on
means
it
is
very
hard
to
know
exactly
whose
behavior
it
is
you
need
to.
C
You
need
to
change
on.
So
there
are
things,
however,
that
we
could
do
there
are
built
on
this
on
this
kind
of
system.
We
could
ask
ourselves
whether
devices
or
applications
or
whatever
could
advertise
the
kinds
of
traffic
they
want
to
send
or
whatever
we
could.
We
could
try
to
get
applications
to.
You
know
work
in
some
kind
of
scope
so
that
you
know
whether
you're
supposed
to
be
inside
this
network
or
not-
and
these
are
you
know,
general
on
questions
that
I
have
I,
don't
know
what
the
answer
is.
C
C
It
could
be
that
there
are
various
kinds
of
feedback
mechanisms
that
we
want.
I
I
will
note
that
you
know,
for
instance,
source
quench
doesn't
work
anymore,
but
maybe
you
need
something
like
that.
I,
don't
know
what
the
right
answer
is:
I'm,
not
proposing
that
we
revive
source
quench.
So
please
don't
get
up
to
the
microphone
and
tell
me
that
on
I
guess
the
general
thing
that
I
want
to
point
out,
however,
is
twofold.
C
First
of
all,
we
have
to
be
very
careful
here
because
it's
really
easy
to
propose
simple
solutions
that
actually
just
invite
a
new
kind
of
attack.
So
we
move
the
problem
around
and
I've
already
heard
people
complaining
about
DNS
SEC
in
this
way
right,
DNS
SEC
solved
the
problem
with
spoofing
and
it
solved
that
by
making
the
DNS
and
an
excellent
amplifier-
and
so
maybe
this
is
you
know
something
to
think
about.
C
The
second
thing
is
I
believe
that
if
we
do
not
think
about
and
answer
these
questions
ourselves,
somebody
else
is
going
to
answer
those
questions
for
us
and
it's
not
going
to
be
answered
in
rooms
that
look
like
this.
No
t-shirts
are
going
to
be
involved,
so
not
all
regulation
is
automatically
bad
and
I
want
to
emphasize
that
right,
I.
C
The
fact
of
the
matter
is
that
the
automotive
industry
was
not
putting
seat
belts
in
cars
and
there's
lots
of
evidence
to
suggest
that
wearing
your
seat
belt
during
a
collision
makes
it
less
likely
that
you're
going
to
die,
and
that
seemed
like
the
sort
of
thing
that,
like
would
just
be
obvious.
Okay,
so
we'll
put
seatbelts
in
all
the
car,
but
but
the
automotive
industry
wouldn't
do
it.
That
was,
in
fact,
what
Ralph
Nader's
complaint
was
that
the
industry
was
more
interested
in.
C
The
problem
with
this
kind
of
regulatory
environment
is
that
it
causes
long
lead
times
and
it
creates
perverse
incentives.
One
of
the
interesting
things
about
the
North
American
automotive
market
is
that
the
the
rules
were
different
for
cars
and
trucks.
So
what
we
saw
was
this
explosion
in
light
truck
on
the
traffic
on
the
US
and
Canadian
roads,
and
the
reason
for
that
was
that
the
incentives
were
set
up
so
that
the
automotive
industry
had
a
reason
to
push
those
things.
C
So
we
want
to
be
careful
about
that
and
that's
the
reason
that
I
say
we
are
the
people
who
ought
to
tackle
this
problem.
We
have
to
tackle
this
problem
because
we
understand
the
technology.
We
understand
what
the
what
the
incentives
are,
and
we
understand
the
the
nature
of
the
underlying
thing
and
if
we
don't
do
it
ourselves
and
we
don't
tackle
some
of
these
perverse
incentives,
somebody's
going
to
come
along
and
do
it
for
us,
so
I
don't
have
a
magic
solution
for
you.
C
I
wish
I
did,
but
I
hope
that
this
has
been
a
little
bit
of
food
for
thought
and
I
hope
that
we
can
have
a
interesting
and
useful
discussion
here
in
the
IETF
plenary.
All
of
you
are
smarter
than
I
am
so
the
chances
are
good
that
you're
going
to
be
able
to
come
up
with
something
better
than
I.
Would
anyway,
thanks
very
much.
A
E
Call
upon
question
to
you,
Andrew
what
you
just
described
with
with
the
car
example,
was
Nader
pointing
to
existing
solutions
that
were
not
implemented
by
the
market.
The
seatbelt
was
already
available
as
I
leave.
I
think
that
we
are
in
a
different
situation
here.
We
don't
seem
to
have
the
fundamental
solutions.
E
C
This
work,
it
does.
Okay,
it
just
doesn't
have
a
little
light,
so
I
don't
have
an
indicator.
So
it's
true
that
the
seatbelt
was
something
that
that
already
existed,
but
actually
Nader's
book
is
really
instructive.
I
I,
like
the
automotive
example,
just
because
it's
so
transformative,
but
you
can
find
this
in
other
kinds
of
industries.
Actually
Nader's
complaint
was
not
just
that
they
wouldn't
implement
stuff.
That
was
known
already,
but
they
wouldn't
do
any
research
on
on
alternatives
either,
so
they
weren't
they
weren't
working
on
on
other
kinds
of
stuff.
C
They
weren't
trying
to
find
new
things.
They
weren't
trying
to
make
the
car
more
fuel-efficient
or
or
safer,
or
anything
like
that
and
I-
think
that
both
of
those
kinds
of
things
are
going
to
be
important
both
for
our
industry
and
for
other
industries.
But
I
think
you
know
we're
the
ones
who
can
talk
about
this.
One.
F
G
Kathleen
Moriarty
second
d,
so
Andrew
I
wish
you
were
I,
hope,
you're
right
that
this
is
a
turning
point
but
evidence
looking
out
at
interest
in
system
hygiene.
It's
you
know
for
IOT,
it's
not
there
for
open
source.
You
know
if
you
talk
to
leaders
of
open
source
efforts,
they're
literally
saying
you
and
exclaiming
that
security
will
come
later
right.
So
even
these
big
efforts
that
have
seen
that
have
leaders
who
have
seen
things
fail,
having
not
had
security
built
in
from
the
beginning
are
still
proceeding
in
that
way
because
they
think
features
first
matters.
G
G
C
C
They're
already
electrical
authorities
who
are
just
dying
to
extend
their
on
their
power
into
the
network.
So
I
think
that
we
have
a
self-interest
here
in
our
industry
and
we're
going
to
have
to
figure
out
how
to
convince
our
collective
industry
that
we
need
to
put
put
the
money
into
this
now.
One
thing
that
we
might
want
to
do
is
is
redefine,
at
least
at
the
standards
level.
C
G
So
that
just
hit
a
trigger
I
mean
if
anyone's
interested
in
helping
on
data
models
to
validate
security
of
different
device
types,
whether
it's
yang
or
something
else
sockem
is
going
to
be
open
to.
It
is
open
to
contributions,
but
they'll
they're,
also
very
flexible,
on
what
is
used
to
do
that.
Validation.
Knowing
that
different
device
types
will
use
different
interfaces,
and
so
they
have
to
be
accommodating
of
that,
and
that's
one
way
to
get
towards
hygiene
and
automated
checking
of
it.
So
help
is
welcome.
H
First
of
all,
I
want
to
thank
the
IAB
for
putting
on
a
really
great
technical
topic.
It's
really
well
done.
Congratulations
to
Kathleen
and
Andrew,
and
the
rest
of
the
ideas
and
the
other
speaker
from
CloudFlare
I
just
wanted
to
say
that
first
of
all,
I
really
enjoyed
your
presentation.
Andrew
I'm.
Also
the
person
who
wrote
out
mud
with
a
manufacturer
usage
description
document
which
you
can
find
in
the
ops
area,
working
group
I
think
Andrew.
H
That
your
point
is
that
there
is
room
for
everybody
to
be
part
of
the
solution
here.
So
what
is
it
that
endpoint
manufacturers
need
to
do?
What
is
it
that
router
and
security
manufacturers
need
to
do?
What
is
it
that
governments
need
to
do
and
what
is
it
that
consumers
need
to
do
and
I
suggest
that
the
I?
H
I
A
J
Bye-Bye
thanks
juan
carlos
well.
My
comment
is
actually
following
up
from
from
Elliot's
I.
Think
he's
got
a
point
that
nowadays
we
we
have
evolved,
so
we
can
learn
definitely
from
from
from
the
past
and
examples
you
gave
it
about.
The
automotive
industries
are
very
valid,
but
we
can
also
learn,
from
instance,
from
the
IANA
transition
that
moved
to
a
multi-stakeholder
idea.
J
So
I
think
and
I
wouldn't
agree
that
we
are
in
the
best
position,
but
not
only
as
the
technical
community,
but
also
representing
manufacturers
are
commercial,
the
Civil
associations
and
so
on,
because
we
need
incentives
we
make.
We
need
to
make
this
thing
work
and
it's
in
everyone's
interest,
so,
instead
of
promoting
the
alienation
that
lately
is
happening
a
lot
between
no,
this
is
my
realm.
This
that's
your
realm,
we're
different!
We
don't
speak
to
each
other.
I
would
actually
encourage
us
trying
to
get
these
communities
work
together
and
basically
make
make
the
internet
work.
J
D
This
is
hummus
I,
think
it's
a
good
idea,
as
Andrew
said
to
us
start
the
dialogue,
but,
as
you
have
put
up
on
the
slides
the
solutions
on
that
not
the
only
solution
you
mentioned
there
is
one
that
is
quite
natural
for
this
type
of
community.
You
have
equipment,
network
equipment,
manufacturers
in
your
in
your
I
be,
and
so
the
solution
is,
of
course
you
have
a
firewall
in
the
network
that
filters
traffic,
and
that
illustrates
the
problem.
While
you
say
we
need
to
reach
out
or
you
need
to
be
inclusive
and
so
on.
D
You
actually
need
to
get
these
other
people
on
board
because
they
are
currently
working
on
all
different
venues,
and
specifically,
there
are
very
few
chip
manufacturers
in
the
IDF
who
could
contribute
this
also
from
the
rest
of
the
value
chain
of
that
industry.
That
makes
it
very
difficult
to
come
up
with
a
solution
that
they
would
even
recognize.
D
D
If
it
will
solve
the
problem
at
all,
because
those
parties
who
had
not
been
interested
to
use
any
security
mechanisms,
they
will
hardly
be
interested
to
implement
or
even
know
about
this
other
security
mechanism.
So
it's
like
it
sounds
a
little
bit
bizarre
band.
They
haven't
done
the
obvious
thing.
Why
would
they
do
like
manufacturer
certificates
with
some
new
innovative
description,
but
some
fireballs
in
every
network,
so.
C
I'm
really
glad
that
you
pointed
out
that
there
are
multiple,
multiple
ways
or
multiple
levels
that
we
got
to
tackle
this
at
and
I
agree
with
you.
I
I
was
sort
of
trying
to
keep
the
the
examples
of
light,
just
because
I
I
mean
that
the
potential
here
is
very
wide
but
I
think
you're
exactly
right,
but
we
don't
want
it.
C
F
I
henning
short
20
I
spent
my
days
in
Washington
these
days
and
the
notion,
not
you
can
just
say,
vasava
next
to
you
or
after
the
next
big
one.
On
whatever
and
we've
had
similar
problems
on
pcs
on
mobile
devices
and
most
of
those
are
not
protocol
problems,
it's
not
like
somebody
discovered
a
vulnerability
in
a
crypto
algorithm
or
in
TLS
or
whatever
visa.
Just
pretty
dumb
implementation
problems,
as
in
HUD
coding.
Passwords
is
not
exactly
a
bcp
level
thing
that
we
need
to
write
up.
F
I
and
I
would
bet
none
of
the
manufacturers
that
were
involved
in
that
particular
botnet,
recognizing
that
is
just
one
instance,
are
presented
or
have
ever
attended
the
IETF
I
an
unlikely
to
to
be
quite
honest
and
the
excitations
from
a
day
isn't
going
to
change
my
behavior
mind,
actress,
recognizable
and
I.
Think
government
people
are
smart
enough
to
recognize
incentives,
and
currently
we
are
none.
I
and
hanas
mentioned
PCI,
DSS
and
I
think
that's
an
instructive
example.
F
We
are
case
you
don't
know
what
it
is
it's
where,
if
you
accept
credit
cards
on
your
web
server,
you
have
to
get
certified
every
month.
Somebody
pokes
your
web
server
and
make
sure
that
you
have
implemented
over
CVE
remedies
that
are
they
are
otherwise.
You
don't
get
to
accept
credit
cards.
That's
not
a
not
governmental
thing.
That's
because
we
have
two
big
entities:
Visa
and
MasterCard,
primarily
I'd
control.
That
particular
thing
I'm,
not
sure,
that's
a
better
option,
I,
not
so
I
do
encourage
people
to
come.
F
Talk
to
government
agencies
and
I
certainly
be
happy
to
talk
to
people.
I
do
advise
that
the
we
will
solve
it
somehow
at
some
point
indefinite
in
the
future,
with
some
magic
is
not
a
good
starting
point
of
that
discussion,
and
because
usually
that
means
somebody
in
the
political
realm
will
have
to
take
the
blame
because
they
haven't
done
anything
and
be
usually
much
more
visible
than
the
people
in
this
room.
F
I
hate
to
say
so,
I'm
solutions
are
very
much
is
a
fertile
time
for
poop
proposing
solutions,
but
they
can't
just
be
Oh,
we'll
all
just
sing,
Kumbaya
no
room
and
we'll
all
just
get
together
and
won't
solve
that
magically.
Simply
because
there's
no
evidence
that
it
has
worked
for
the
past
20
years,
yeah.
A
This
is
absolutely
true.
Anybody
who
thinks
these
problems
are
new
should
go
back
and
read
about
what
happened
when
people
realize
that
they
were
going
to
be
cable
box
is
always
on
on
the
internet,
I'm
going
to
close
microphone
lines
now,
because
we
need
to.
We
still
need
time
for
the
IB
and
IC
is
true,
but
Sarah.
K
The
other
are
the
aspirational
ones.
Thou
shalt
eventually
reduce
pollution
by
some
amount.
Those
only
makes
sense
if
we
have
a
good
basis
for
believing
we
know
how
to
achieve
those,
even
if
we
don't
know
now
how
to
we
have
a
skill
set.
That
says
we're
probably
going
to
be
able
to
for
much
of
this
topic.
My
sense
is
we're
not
there.
We
need
to
be
obviously
the
low-hanging
fruit
I
characterized
as
standards
with
teeth.
K
A
comment
that
was
just
made
hints
at
a
point
that
we
we
need
to
keep
in
mind.
The
Internet
has
been
under
attack
many
times
at
the
architectural
level.
They
weren't
necessarily
my
level,
and
some
of
them
have
been,
but
many
of
them
have
not
been.
We
have
exceeded
limits,
we've
exceeded
styles
of
use
and
we
have
broken
things:
NSFNET
broke
the
backbone
routing
a
service.
In
fact
it
was
being
broken
periodically,
but
NSFNET
institutionalized
it
and
forced
the
creation
of
BGP
in
the
late
80s
and
I
I.
K
Think
there
may
have
been
more
than
one
of
these,
but
there
was
a
burst
of
activity
to
deal
with
TCP
congestion
to
deal
with
certain
kinds
of
efficiencies,
and
there
were
was
almost
a
a
cornucopia
of
efforts,
some
of
them
very
disciplined,
some
of
them
very
narrow.
We
don't
really
have
an
equivalent
marketplace
of.
What
really
is
research?
L
L
I
Tom
Herbert
so
I'd
like
to
give
one
example
in
the
open
source
community,
where
we're
trying
to
address
part
of
this
problem,
so
I
believe
Nick
mentioned
that
CloudFlare
was
using
iptables
and
BPF
and
we're
getting
about
1.2
million
packets
per
second
drop
over
the
past
year.
We've
actually
been
looking
at.
This
number
is
really
pretty
bad,
mean
think
about
it,
and
we
can
increase
that
by
tenfold
with
something
called
Express,
datapath
xdp,
and
it's
kind
of
interesting,
because
we've
been
working
on
this
and
people
kept
asking
us
why.
I
M
James
would
ya
I
my
ears
perked
up.
One
I
saw
that
slide.
That
talked
about
the
you
must
be
this
tall
to
ride,
problem
and
I
know.
This
is
a
discussion
about
what
the
internet
architecture
itself
might
be,
potentially
a
a
thing.
That
is
something
you
could
point
fingers
at
as
this
is
why
we
have
so
much
risk
in
our
in
our
system
and
I
think
to
myself
okay.
M
So
what
are
the
architectural
features
of
the
internet
that
that
make
it
so
that
it's
a
playground
for
asymmetric
warfare
right
and
the
first
thing
that
comes
to
mind
there
is
that
well,
some
years
ago,
I
was
the
technical
editor
for
an
RFC
that
described
the
simple
security
characteristics
of
residential
gateways,
where
the
idea
was
unmanaged
home
networks,
but
gosh
they
have
to
have
a
firewall.
That
is
completely
unmanaged
by
people
and
I
worked
on
that,
despite
really
not
wanting
to,
because
from
my
perspective,
I
wanted
there
to
be.
M
You
know
a
transparent
ability
to
get
in
and
out
of
home
networks
so
that
it
was
possible
to
build
applications
that
you
didn't
have
to
be
running
a
secure
data
center
with
lots
of
centralized
pipes,
you
could
distribute
data
around
the
edges
of
the
network
and
maybe
have
another
way
of
making
something
that
was
robust
against
distributed.
Denial-Of-Service
attacks
I'm
not
sure
whether
that's
necessarily
a
way
to
solve
this
problem,
but
we
kind
of
built
an
architecture
that
says
no,
that's
not
going
to
be
possible
at
all.
M
We
always
turn
on
firewalls
that
block
incoming
connections
from
you
know.
Unexpected
remote
addresses
arbitrary
remote
addresses
can't
get
through
these
firewalls
because
they're
always
turned
on,
and
it
seems
to
me,
like
we
sort
of
did
that
on
purpose.
I,
don't
know
how
we
can
change
that
part
of
the
architecture,
because
there
seems
to
be
like
widespread
consensus
that
this
is
all
good
and
that's
what
we
have
to
do.
But
it's
the
thing
that
makes
the
internet
an
asymmetric
warfare
playground.
M
So
if
we're
going
to
live
in
a
world,
that's
forever
going
to
be
asymmetric
warfare
until
the
end
of
time.
Maybe
we
just
kind
of
have
to
hope
that
people
who
do
policy
and
regulations
will
tell
us
how
they
want
it
regulated,
and
then
we
can
build
technology
to
apply
those
policies,
but
we're
not
a
policy
development
organization.
Here,
we're
just
like
engineers.
C
So
so,
yes,
but
I,
think
you
put
your
finger
on
on
something
here,
so
so
I
think
you're
right
that
we
made
an
actual
decision
at
some
point
to
to
to
change
that
right.
We
pretend
that
we've
got
this
this.
You
know
dumb
network
with
all
the
intelligence
out
of
the
edge
and
so
on,
and
then,
if
you
look
at
it,
actually
we've
got
classes
of
network
on
that
are
in
there.
C
So
it's
already
false
you've
got
access,
networks
versus
you,
know,
infrastructure
networks
and
providers,
networks
and
so
on,
and
these
are
really
different
classes
of
network.
They
have
different
properties
and
on
we,
we
sort
of
pretend
to
ourselves
that
they're
all
the
same,
but
they
really
aren't
at
least
the
way
they're
deployed
today.
C
The
deployment
is
not
really
it's
not
really
completely
separate
from
the
architecture
right
that
there's
this
idea
that
you've
got
the
architecture
and
then
you've
got
this
completely
separate
thing
of
deploying
it
and
I
think
that
that's
that's
sort
of
lying
to
ourselves.
But
what
this
means,
of
course,
is
that
we
could
decide
that
what
we
wanted
to
do
was
build
on
protocols
that
that
tended
to
distribute
data
in
a
secure
way
instead
intended
to
push
things
back
out
to
the
edge.
Now.
C
Maybe
we
got
to
do
that
in
a
network
that
doesn't
allow
the
sort
of
arbitrary
and
a
point-to-point
connect
connection
that
the
original
internet
model
had.
But
but
if
we
think
about
this
in
terms
of
the
kinds
of
services
and
data
that
we
push
to
various
places,
it
could
be
that
actually,
what
we
would
be
doing
is
recreating
that
on
that
older
feature
and
the
reason
to
do
that
is
because
the
purpose
of
all
of
this
was
to
get
the
data
moving
around.
C
And
so
maybe
what
we've
got
is
like
this
hangover
of
this
kind
of
kludgy
middle
thing,
with
all
the
firewalls
in
between
and
so
on.
And
yet
you
still
might
end
up
with
the
properties
of
pushing
the
things
out
to
the
edge
so
that
the
applications
that
are
living
out
there
on
the
edge
would
have.
We
have
the
local
freedom
to
do
these
kinds
of
things.
I.
C
Don't
know
how
all
of
that
sort
of
picture
of
the
future
plays
out,
but
it
seems
to
me
that
if
we
started
talking
about
about
alternatives
to
the
way
we've
deployed
stuff
that
looked
along
these
lines,
it-
and
actually
you
know,
turn
our
gaze
to
a
system
that
was
there
in
the
past.
We
might
learn
something
from
it
and
maybe
we
could
build.
Maybe
we
could
recreate
some
of
the
advantages
that
we
had
before
well,.
C
C
C
N
Eric
nordmark,
so
I
think
it's
clearly
that
from
an
operational
sort
of
the
scale
of
the
internet,
the
thing
you
talked
about
in
terms
of
the
focus
on
how
do
we
cope
with
these
attacks
right
or
you
sort
of
malicious
load?
Spikes,
that's
something
that
we
have
to
figure
out
how
to
get
better
at.
But
as
people
point
out,
this
is
a
symmetric
in
terms
of
the
cost
to
the
attacker
versus
the
cost.
To
defend
against
that.
If
you
have
these
things
with
admin,
admin
username
password,
the
cost
to
attack
is
close
to
zero
right.
N
O
Glee
at
two
things,
first
of
all,
for
the
nat64
network,
so
the
IB
recommends
that
all
networking
standards
assume
a
use
of
ipv6
henceforth
and
be
written,
so
they
do
not
require
IP
before
I
would
posit
that,
if
we're
here
at
the
ITF
to
do
work,
then
that's
what
the
default
would
be.
Six
only
network
should
be
so
we
should
make
the
network
nat64
by
default,
because
that's
what
we're
trying
to
do
here
we're
trying
to
design
protocols.
So
with
that
in
mind,
another
thing!
O
So
if
we
want
we
like
end-to-end
right
and
if
we
want
the
Internet
to
be
end
to
end-
and
we
want
it
to
be
secure,
then
the
security
has
to
be
at
the
edges
right.
Otherwise,
we
can't
continue
the
existing
model
now
before
we
throw
away
the
model
which
try
to
fix
it
now.
The
observations
here
is
I.
Think
the
security
models
of
I,
don't
think
any
of
our
protocols
are
broken.
O
I,
don't
think
we
can
fix
any
protocols
to
fix
this
problem
because
the
protocols
aren't
you
attack
vector
seems
to
me
that
the
attack
vector
is
code
that
nobody
cares
to
update
because
they
have
absolutely
zero
incentive
to
update
it.
Now,
it's
like
into
I
write
code
that
goes
into
Android
right
and
you
know
it's
a
billion
devices
and
manufacturers
updated.
They
don't
update.
It
may
be
the
update
it.
Maybe
they
don't
for
an
IOT
device.
O
There
is
absolutely
zero
incentive
to
put
any
security
at
all
in
your
initial
build
because
it
means
that
you're
going
to
be
behind
somebody
else
and
I,
don't
see
I,
don't
see
a
good
way
around
that
except
to
say,
okay,
you
map,
you
must
be
this
tall.
You
know
to
connect
to
the
internet
now.
What
would
our
role
be
in
that
our
role
might
be
to
say?
Okay,
here's
a
protocol
that
we
can
build
so
that
advice
can
say
in
a
in
a
secure
way.
O
Here's
the
latest
security
update
that
I
have,
and
it's
signed
by
my
manufacturers
key
and
I
support
all
these
TVs
and
I
fix
them,
and
so
after
a
while,
once
we
have
that
trusted
at
the
station,
we
can
say:
okay,
well,
okay,
here's
a
bunch
of
bad
devices
and
we
can
try
to
decide
what
to
do
about
them
and
and
that's
a
technical
solutions,
not
attacking
a
problem.
But
it's
providing
a
means
that
that
somebody
could
use
to
solve
the
problem
in
ways
that
are
not
going
to
necessarily
change
the
model
completely
and
so
I.
C
Well,
I
mostly
agree
with
you,
but
I
have
a
little
quibble,
I
think
with
one
of
your
premises,
which
is
that,
like
the
the
protocols
aren't
broken
so
I
agree
with
integrating
with
you
that
individual
protocols
may
be
accepting
the
DNS
are
not
broken
in
their
in
their
fundamental
I.
Think
what
I
am
partially
arguing
is
that
what
we've
done
is
we've
designed
we've
designed
a
system
which
has
as
its
property
this
this
basic
vulnerability
and
and
the
the
solution
to
that
cannot
be
well.
C
But
we
passed
that
thing
some
time
ago
and
we
haven't
done
anything
about
our
model
of
who
gets
to
join
and
I.
Think
the
problem
that
I'm
that
I'm
worried
about
is
that
the
network
doesn't
have
any
other
on
protections
against
this.
It's
really
just
got
like
once
you're
in
you're
in
you
know
our
bodies
don't
work
that
way.
C
You
know
you
get
through
the
skin
and
you're
still
going
to
be,
like
you
know,
defended
against,
whereas
what
we've
got
really
is
you
get
through
the
skin
and
hey
you're
wide
open
here,
and
that
seems
to
me
like
a
difference
that
we
could
do
something
about
if
we
adopted
a
sort
of
immune
response,
a
sort
of
environment
to
this,
so
I
likely
suggest
the
suggestion
that
you
make
that
what
you
could
do
is
say:
hey,
wait!
A
minute!
We've
sent
out
this
this
inoculation
against
this
problem
and
you're
not
behaving
like
you're
inoculated.
O
C
O
B
Yeah
so
I'm
a
little
bit
more
tempered
on
on
that
I
kind
of
agree
with
you
that
if
we
can
build
software
or
do
work,
that
makes
it
easier,
cheaper
and
reduces
the
friction
for
people
building
these
devices
to
have
security
by
default.
I
think
it
doesn't
solve
things
in
a
one
hundred
percent
case,
but
the
more
security
we
have,
the
better
and
and
that's
sort
of
one
of
the
main
points
of
my
presentation
is
that
it
is
about
scale
it's
you
can
handle
something
that's
ten
times
bigger,
maybe
not
a
hundred
times
bigger.
B
P
My
name
is
George
terrigenesis
and
I'm
working
for
hallway.
First
of
all,
I
would
like
to
thank
you
for
this
interesting
and
important
session
that
you
organized.
In
addition
to
that,
I
would
like
to
mention
that,
in
addition
to
the
security
challenges
that
you
that
you
have
discussed
that
somehow
stimulate
simulators
to
think
on
redesigning,
maybe
the
internet
architecture,
there
are
also
other
challenges
that
are
related
to
privacy,
so
protection
of
personal
data
and
then
data
ownership.
And
in
addition
to
that,
you
mentioned
regulation.
P
The
European
Commission,
European
Parliament,
is
actually
working
on
the
general
data
protocol
protection
regulation.
So
they
have
already
defined
certain
regulation
on
privacy
and
there
is
all
they
are
also
grabs
on
technology
so,
and
this
might
also
stimulate
us
to
think
also
in
that
area.
So,
in
addition
to
security,
also
privates
type
of
topics.
Q
Roland
Dobbins
arbor
networks,
I
mitigate
DDoS
attacks
for
living
and,
unfortunately,
business
is
very
good.
A
couple
of
comments.
There
are
a
lot
of
best
current
practices
at
all
seven
layers
of
the
OSI
model
and
at
the
entire
communications
chain
across
the
Internet
that
if
we
could
waive
our
metric
wines
and
have
them
implement
it
immediately,
the
asymmetries
that
are
so
heavily
in
favor
of
the
attackers
right
now
will
be
greatly
greatly
reduced.
Q
We
would
still
have
ad
dodge
problem,
but
it
would
be
much
more
more
manageable
with
regards
to
regulation
I'm,
a
big
fan
of
what's
called
back
door
regulation
and
what
I
mean
by
that
is.
There
are
regulations
in
place
having
with
things
like
insurance,
for
example,
different
types
of
insurance.
The
organizations
have
to
carry
different
types
of
policies
and
levels
of
policies
that
they
have
to
carry
the
cause
of
laws
and
regulations
that
are
often
transnational
in
nature.
Q
I
said
you
know,
I'd
really
like
to
have
an
in-depth
chat
with
you
about
your
quote:
cyber
unquote
policies
that
you're
writing,
because
I
think
you
have
a
lot
of
unsecured
risk
that
you're
on
a
hook
for
and
that
you
and
your
friends
and
the
actuarial
Association
is
really
need
to
be
briefed
on
this
and
so
I
think
that
that's
a
one
way
to
get
in
some
backdoor
regulation,
essentially
through
the
end
of
the
insurance
underwriters
they'll.
Let
them
understand
that
they
need
to
start
really
auditing
organizations
that
they
write
policies
for
another.
Q
Another
comment:
I
have
in
terms
of
regulation.
Is
the
government's
actually
have
a
fantastic
way
to
regulate
without
regulating
it's
called
the
RFP.
The
request
for
proposal
on
governments
can
specify
vendors
that
they
purchase
things
from
services
from
including
things
like
internet
transit
and
so
forth.
They
can
specify
that
verifiable
steps
have
been
taken
by
those
organizations
to
implement
reasonable
on
best
current
practices
dead.