►
From YouTube: IETF100-IRTFOPEN-20171116-0930
Description
IRTFOPEN meeting session at IETF100
2017/11/16 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
A
A
So
if
you
can't
hear
me
signal
quickly,
because
I
I
might
not
actually
be
able
to
keep
the
discipline
to
use
the
mic
as
close
as
it
needs
to
be
this,
the
sound
here
is
difficult.
Okay,
so
welcome
to
the
IETF
99s
IRT
F
open.
We
were
told
last
night.
This
is
really
IETF
99
and
that
we
lost
track
of
one
or
we
went
one
ahead.
So.
A
A
In
addition,
I
wanted
to
add,
since
we
have
the
ability
to
add
to
process
more
readily
than
the
ITF
does
that
we
follow
the
anti-harassment
policies,
and
this
is
just
a
pointer
to
them,
since
there
wasn't
actually
a
mention
of
that
last
night
in
the
plenary,
either
that
we
have
them
and
that
there's
an
Ombuds
I
actually
happen
to
also
be
one
of
the
Ombuds
team.
So,
as
you
have
a
concern
about
something
in
our
Gees,
there's
two
other
people
on
that
team,
so
you
can
certainly
consult
Linda,
Klee
forth
or
Pete.
A
If
you
need,
if
you
have
a
concern
and
we're
we're
especially
interested
in
just
having
everybody,
have
a
voice
and
speak
up,
it
turns
out.
We
have
one.
So
thank
you
so
much
I
apologize
for
your
run.
Somebody
kindly
ran
ran
for
another
connector,
okay,
and
next
is
that
there
is
going
to
be
a
good
bit
of
photography
during
the
set
this
session
because
of
the
prizes,
and
if
you
have
a
concern
to
not
be
photographed,
we
have
a
policy
that
you
can
inform
the
photographer.
A
A
And
I'm
going
to
give
a
little
bit
more
extended
update
because
with
the
long
plat
panel
and
so
on,
I
volunteered
not
to
give
an
update
during
the
plenary
last
night
in
case
you're
wondering
it's
not
that
we
don't
exist
or
that
we
were
dissolute.
It's
that
we
actually
tried
to
give
some
time
back
and
there
we
can
have
a
little
open
mic
session.
A
If
you
have
some
questions
about
the
IRT
F
as
well
before
we
start
the
prizes
and
then
at
the
end
one
of
the
discussion
topics
that
the
current
idea
is
the
idea
of
having
some
sort
of
lightning
talk
session.
That
would
be
like
the
kinds
of
lightning
talks
or
or
these
some
numbers
of
other
names
that
that
take
place
at
research
meetings
and
it
would
be
actually
IETF
and
I.
Rtf
lightning
talks
mixed
up
together,
possibly
in
an
evening
if
we
don't
get
bits
and
bytes
back
so
be
thinking
about
that.
A
A
I'll
introduce
the
a
and
RP
speakers
when
we
get
to
them,
but
we
have
very
good
speakers.
This
is
the
last
of
the
2017
awardees
this
time.
Okay,
so
in
overview
as
you
as
you
know,
because
you're
here
the
IRT
every
focuses
on
the
kinds
of
tasks
that
are
not
standards,
engineering,
basically,
but
that
seem
important
to
the
IETF
and
to
the
Internet
community
to
be
tackled
by
people.
We
tend
to
work
on
Applied
Research.
We
wouldn't
we're
not
so
likely
to
have
a
theoretical
program
here,
although
I
suppose
we
could
we're
organized
into
para.
A
A
parallel
to
the
working
groups
called
research
groups,
as
you
know-
and
there
is
an
internet
research
steering
group
which
is
all
of
the
research
group
chairs
and
some
at-large
members
and
I'll
introduce
them,
but
that's
the
basic
picture
of
the
IRT
F
and
it's
been
around
as
long
as
the
IETF
has
been
around
with
different
organizational
relationships.
Our
current
relationship
is
a
close
tie
to
the
IAB.
A
A
Similarly,
the
output
of
of
working
groups
is
RFC's,
but
the
group
where
the
working
groups
does
not
a
research
group
does
not
have
to
be
RFC's.
It
could
just
be
code,
it
could
be
a
hackathon,
it
could
be
a
series
of
publications
in
a
journal.
It
could
be
an
agenda,
that's
used
for
for
another
body,
you
know
for
a
scholarly
body,
it
could
be
a
project
of
other
sorts,
and
all
of
that
is
cool.
A
A
Some
groups
aim
to
to
do
their
work
well
enough
to
solve
some
hard
problems
and
then
transition
to
creating
a
working
group
most
recently
disruption.
Tolerant
networking
has
done
that,
and
this
is
this
is
certainly
one
of
the
modes
that
we
like,
but
we
would
not
be
publishing
standards
track
through
the
publishing,
informational,
experimental
or
open
source
or
whatever
up
to
the
time
that
there's
a
transition
to
IETF
and
then
the
other
thing
is
that
some
groups
do
perform
roles.
A
There
are
of
service
to
the
standards
track,
so
that
one
of
the
key
examples
of
that
is
that
the
cipher
G
produces
those
crypto
reviews
that
are
sometimes
extremely
important
and
normatively
required
for
documents
in
the
ITF,
and
that
is
done
with
with
very
close
ad
sponsorship.
So
that
is
another
model.
A
A
The
research
mailing
lists
and
all
the
wiki
links
can
be
found
on
IRT
F,
dot
org,
and
we
are
restructuring
that
page
you'll
see
some
changes.
My
email
officially
I
RTF,
chair
IR
s,
G,
is
available.
I
didn't
get
enough
time
to
put
in
the
picture
where
the
cats
are
not
just
looking
at
the
TV
they're
actually
typing,
because
that's
actually
what
we're
looking
for,
but
you
can
start
out
by
reading
the
way
they
are.
A
Those
are
my
cats,
they're
they're
at-large
members
of
the
IRS
G
in
a
spirit
yeah.
Oh
so
many
out.
This
was
where
the
picture
of
the
Taiping
cats
will
be
later.
So
how
do
you?
How
do
research
groups
originate?
You
may
wonder
about
that
too,
and
some
of
them
have
been
around
a
long
time,
so
their
origins
are
lost
in
time.
A
Perhaps
I'm
going
to
start
requiring
research
group
chairs
to
know
who
all
where
the
chair
is
going
back
to
the
beginning,
because
we
some
groups
have
really
different
feelings
and
structures
now,
but
but
it
would
be
good
for
them
to
actually
have
a
sense
of
their
past
as
well
as
their
future.
But
the
main
thing
about
research
groups
is
that
they
originate
more
more
freely
than
the
ITF
groups.
Do
we
are
very
interested
in
making
sure
we
don't
block
something
new?
A
That
could
be
important,
that
perhaps
we
don't
appreciate
well
not
by
we
I
mean
me
and
the
IRS
G,
but
it
also
you
so
so
it
turns
out
that
you
can
propose
a
group
and
with
some
tweaking
to
make
sure
that
it
has
a
sensible
charter
and
that
the
that
it
has
a
mission,
and
it
has
some-
you
know,
vision
of
what
it
should
be
doing.
It
can
run
for
three
meetings
in
a
status
of
proposed
research
group
before
being
considered
for
for
a
more
long-term
gig,
and
we
have
two
of
those
right
now.
A
So
the
and
the
way
that
we
do
the
evaluation
is
they
get
to
three
meetings.
And
then
the
chair
has
a
kind
of
review
with
the
with
with
the
chairs
of
those
groups
to
talk
about
how
things
have
gone,
but
also
we
will
start
to
have
some
more
some
more
requests
for
a
review
by
the
community
and
by
the
IRS
J
there.
A
So
here's
the
celebri
of
research
groups
and
I'm
happy
to
tell
you
that
last
meeting
everybody
met
this
meeting
everybody,
but
the
decentralized
internet
group
met
and
they
met
informally,
so
I
they're,
actually
not
yet
counting
as
having
had
one
of
their
meetings.
But
we
won't.
We
don't
do
that
for
too
long
and
you
can
see
what
they
are.
They
have
a
wide
range
of
topics,
I'm
actually
quite
interested
in
soliciting
a
privacy,
research
group,
and
if
you
have
an
interest
in
that,
you
should
talk
to
me.
A
We
still
have
human.
Several
of
these
groups
still
have
to
meet
ahead
of
us
and
I.
Don't
have
the
schedule
right
in
my
head,
but
if
any
of
the
chairs
would
like
to
pitch
their
working
group
at
the
mic
for
the
rest
of
the
meeting,
I
beat
you.
Could
you
certainly
can
do
that
h,
h,
RPC
every?
Would
you
like
to
come
up
and
say
word
their
meeting
Friday
morning?
Who
else
is
still
to
me?
They
apologize
for
not
memorizing,
okay,
so
pan
RG,
maybe
you'd
like
to
mention
pan
proposed
research
group.
B
Okay,
this
is
totally
embarrassing,
but
at
the
HR
PC
I'll
be
giving
an
analysis
of
treatment
of
law
policy
and
politics
in
the
history
of
the
RFC's,
with
a
special
emphasis
on
the
first
decade
when
there
was
a
great
deal
of
discussion
about
these
issues,
and
that
and
you
want
to
say,
your
name
does
Sandra
Bremen.
Yes,.
C
So
that
should
be
a
really
great
session
an
hour.
You
want
to
say
a
little
more
about
HIPC
I'm,
Avril,
Dori
I'm,
one
of
the
co-chairs
of
the
group
that
Sandra's
going
to
speak
at
so
she
already
said
the
good
stuff.
But
you
know
another
thing,
though
about
the
group
is
we
just
got
one
RFC
out
and
it's
going
to
be
time
to
sort
of
look
at
okay.
We've
got
some
other
things
that
are
in
the
works,
but
how
do
we
continue?
So
it's
a
great
time
to
get
involved
in
terms
of
how
we
continue.
C
D
E
Co-Chair
with
Kuchar
yeah,
we
actually
did
did
have
a
problem
with
attendance
by
people
who
were
doing
active,
work,
we're
still
serving
in
start-up
mode,
and
we
just
were
having
problems
getting
enough
active
participation,
so
I,
so
so
yeah.
We
are
going
to
be
we're
talking
about
doing
an
interim
in
conjunction
with
nd,
SS
and,
of
course,
we'll
be
meeting
in
London.
But
we
thought
it
was
a
better
idea
to
not
meet
rather
than
have
a
bad
meeting.
A
Okay-
and
we
have
had
very
good
meetings
of
the
group
so
far
and
I
will
put
out
a
report
with
my
observations
about
the
groups
on
the
discuss
list.
That's
something
that
I
need
to
gather
by
their
cadence
for
Brian
will
say
something
about
the
pan
that
proposed
research
group
as
well
path,
aware,
networking.
F
We're
gonna
have
our
second
meeting
of
the
path
or
networking
repro
post
research
group
right
after
lunch,
actually
I
think
we
might
be
in
here,
I'm,
not
sure,
so
the
30
second
elevator
pitch
is
we're.
Looking
at
it's,
it's
kind
of
a
it's
kind
of
a
fuzzy
sort
of
architecture,
sort
of
thing.
It's
like
what
what
could
we
do
in
a
world
in
which
the
end
points
have
a
more
active
participation
in
this
election
that
has
that
their
traffic
takes,
and
this
came
out
of
an
observation
about
a
lot
of
sort
of
disconnected
work.
F
That's
happening
in
this
space
in
the
IETF
sort
of
things
like
IP
views,
excitement
routing
things
like
peas,
multipath
transport
protocols,
work
on
these.
How
do
all
of
these
fit
together?
And
what
can
we
do
with
this
stuff?
So
we're
trying
to
figure
out
we're
drawing
a
box
around
what
it
is
we
want
to
do
and
we're
still
trying
to
figure
out
about
interest
in
the
room
in
this
community
is
this
correct,
is
entirety
of
research
group?
Is
there?
Are
there
other
things
that
we
should
be
doing
in
this
space?
F
We're
doing
a
partial
review
of
sort
of
the
whole
story
early
in
the
group,
because
we
had
an
unfortunate
conflict
with
the
ideas
both
in
Prague
or
first-time
Syrians,
like
okay
for
those
of
you
who
didn't
come
to
the
first
meeting,
here's
what
we're
trying
to
do
and
a
few
presentations
we're
sort
of
diving
deep
on
what
we
see
is
research
into
mechanisms
for
realizing
paths,
awareness
in
the
internet.
So
some
of
these
are
things
that
people
know
about
work.
F
A
A
One
thing
that
I
hope
to
do
is
move
this
slot
into
a
lunchtime
so
that
we
can
make
sure
that,
since
we
always
have
some
a
lot
of
interest
in
the
in
the
prize
when
their
presentations,
we
actually
have
some
ability
to
not
conflict
with
people,
for
that
and
in
general
I
think
we're
just
at
the
same
mercy
of
of
time
like
everybody
else,
but
the
the
groups
cover
you
know
span
from
there.
I,
don't
wanna
call
other
things
out
too
much,
but
but
there's
lots
going
on.
A
We
also
have
recently
talked
about
having
documents
which
are
in
two
different
groups,
because
network
coding
and
IC
and
RG
have
interesting
interaction
between
between
their
work,
where
they
can
support
each
other.
So
we
may
have
parallel
work
going
on.
That
is,
is
really
co-sponsored
by
two
groups
and
we
don't
need
to
have
it
owned
by
one
group.
We
actually
have
the
freedom
to
do
that
as
well.
A
Okay,
you
could
see
the
membership,
so
the
chairs
are
our
members
of
the
IRS
G.
If
you
go,
if
you
write
to
the
IRS
G
mailing
list,
you'll
get
all
these
people
and
then
we
have
some
at-large
members
as
well,
who
especially
helped
to
tie
us
back
to,
for
example,
the
transport
area.
Spencer
is
one
of
our
at
large,
because
transport
and
an
IRC
have
a
lot
of
relationship.
A
Essentially
it's
a
best
paper
prize
for
all
possible,
published
papers
and
applied
networking
and
I
like
to
say
security
too,
because
we
have
an
interest
in
security,
applied
security
topics
and
you'll
see.
We
have
had
a
number
lots,
so
they
are
four
previously
published
papers,
we're
not
very
strict
about
the
deadline,
but
it
should
be
the
last
couple
of
years
and
somebody
numb
or
either
nominates
their
own
paper
and
themselves
or
a
paper
and
the
speaker
and
the
speaker
is
specifically
nominated
in
order
to
come
and
give
a
presentation.
A
The
Internet
Society
funds,
it
primarily,
but
there
are
some
sponsors
as
well
and
you
might
be
a
sponsor.
If
you
think
you
could
it's
not
a
large
amount,
but
we
certainly
would
love
that
you
can
talk
to
AIESEC
about
that
and
thank
you
to
Comcast
for
being
a
current
sponsor
as
well
as
thank
you
to
Isaac.
A
The
process
starts
with
a
yearly
call
for
papers.
I
hope
you
all
saw
it
because
I
tried.
We
tried
to
get
it
everywhere
and
if
we
didn't,
we
need
to
do
better
and
it
completed
on
November
5th.
We
actually
got
our
largest
number
ever
almost
60
submissions
and
very
good
ones
to
boot,
which,
in
my
estimation,
I'm
not
the
only
reviewer.
Obviously
we
have
a
peer
reviewing
committee,
that
is
from
academics
and
from
industry,
and
you
can
check
on
the
link
there.
A
If
you
want
to
see
more
about
the
call
for
papers,
the
original
call
who's
on
the
program
committee,
things
like
that
and
then,
before
the
end
of
the
year,
we
will
be
actually
before
the
middle
of
December.
We
will
be
selecting
all
six
and
then
start
to
announce
the
ones
for
2018.
So
that
is
how
that
actually
happens.
That's
where
they
come
from.
That's
where
Roland
and
Paul
came
from
from
last
year's
group,
so
there's
also
the
confusion,
because
we
have
to
A&R
things
and
people
sometimes
say
well.
A
Did
you
mean
the
W
or
the
P?
What
is
the
difference
between
those?
So
it
seemed
reasonable
to
deconflict
that
for
you
today,
they
both
have
an
annual
call.
A
and
RP
calls
for
nominees
a
and
our
W
calls
for
papers,
and
our
W
gives
a
prize
for
an
already
published
paper.
I,
sorry
piece,
yeah
I'm
doing
it
myself
wrong
and
ANR
W
gathers
new
papers,
new
submissions,
air
workshop
submissions,
the
prize
there's
two
presentations
at
each
ITF.
A
Okay,
so,
hopefully
you're
no
longer
confused
and
you
might
want
to
follow
us
at
at
in
Retta
fo,
which
is
our
twitter
handle,
and
we
also
have
a
facebook
page
and
you
will
notice
that
roland
is
in
this
picture
because
he
has
been
an
awardee
before,
but
it
was
a
great
sort
of
triumphant
picture
to
attract
people's
attention
and
I
tribute
to
this
picture.
The
large
increase
in
the
submissions.
So
thank
you
to
the
people
in
that
picture
and
thank
you,
too
Olaf
for
taking
such
a
good
picture.
A
G
Hi
Aaron
Falk,
so
some
of
you
may
recognize
me
as
the
host
of
the
Pecha
Kucha,
which
is
actually
tonight
and
I,
but
I'm
here,
because
there's
an
idea
under
discussion
to
take
the
the
lightning
talk
idea
that
has
Pecha
Kucha
has
been
kind
of
a
fun
thing
and
trying
to
actually
make
it
available
for
people
to
present
new
ideas.
So
more
of
a
serious
lightening
talk
session,
so
I'm
sort
of
at
the
center
of
a
small
group.
That's
doing
some
brainstorming
on
this,
so
just
to
be
clear.
G
We're
talking
about
doing
a
lightning
talk
session
at
the
IETF
sometime
during
the
week.
That's
not
going
to
conflict
with
working
groups
or
research
groups
and
if
you
have
ideas
as
or
opinions
as
to
whether
you
think
that's
a
good
idea
or
not
or
if
it's
something
that
you've
got
some
ideas
on
people
who
might
be
interested
in
participating.
G
G
The
kind
of
thing
that
they're
doing
in
dispatch,
but
to
a
broader,
more
general
audience
so
I
would
love
to
see
researchers
come
and
throw
up
a
couple
of
slides
on
stuff
that
they
think
that
they're
doing
and
so
I
think
this
is
kind
of
a
natural
fit
to
the
a
and
our
PA
and
our
W
discussion,
and
hopefully
some
stuff
that
will
come
out
of
this
will
lead
to
new
research
groups.
Thank.
A
A
Okay,
so
I'm
going
to
introduce
our
first
an
RP
Prize
winner,
although
not
I'll,
introduce
you
briefly
because
you
introduce
yourself
and
your
slides
as
well,
but
Paul
Emmerich
is
from
the
Technische
universität
münchen
in
Germany
and
he's
going
to
present
moongeun,
which
is
a
really
interesting
high
speed
packet
generator
and
I
will
hand
you
the
dongle.
Now,
let's
see
you
need
just
the
this
one.
H
I
Okay
yeah,
thank
you
for
the
introduction
and
yeah
I'm
here
to
talk
about
my
package.
Generic
emulsion
and
I
will
just
start
this
rough
introduction.
Who
I
am
where
I
come
from
and
then
I
will
go
over
a
few
aspects
of
Mugen.
I
won't
bore
you
with
any
details
about
the
implementation
or
performance
evaluation
or
how
we
built
it.
I
I
There
wasn't
a
really
good
software
package
generator
that
you
could
just
use,
and
that
did
all
the
things
I
wanted
to
and
in
the
end,
I
always
ended
up
modifying
some
code
of
some
software
package
generator
to
get
it
to
do.
The
things
I
wanted
to
was
kind
of
annoying,
and
so
I've
addressed
this
idea
of
building
a
Pecha
generator
to
start
to
really
get
even
to
really
be
able
to
do
what
I
wanted
to
do.
I
I
had
to
build
this
first
and
now
it
seems
to
have
consumed
almost
everything
about
the
teasers
and
it's
mostly
about
the
package
generator
now.
So,
where
do
I
work
at
what
was
the
context
that
this
work
is
being
done
in?
This?
Is
the
networking
group
at
the
thematics
faculty
Technical
University
of
Munich?
We
are
a
relatively
large
group
of
about
20
people,
plus
some
external
guys,
and
we
do
a
broad
range
of
network
research
topics
that
ranges
from
everything
from
your
usual
traffic
measurement
and
analysis.
I
Where
we
look
at
look
at
traffic,
you
look
at.
We
have
a
mirror
port,
our
internet
uplink.
Where
we
look
for
animalist
here
we
do
internet
byte
scans.
We
do
everything
we
have
our
own
autonomous
system
for
just
for
research
stuff
and
for
doing
internet
scans.
Then
we
do,
of
course,
all
your
hotbar
things
from
software-defined
networking
and
yeah
Internet
of
Things
and
the
usual.
We
do
a
lot
of
security
and
privacy
research
as
well
and
peer-to-peer
networks
and,
of
course,
the
performance,
analysis
and
modeling
part
where
I'm
at
this
is.
I
This
is
really
the
subgroup
that
working
in
and
what
are
we
doing
there?
It's
well
the
the
main
research
question
or
the
main
question
that
we
have
is
that
packet
processing
becomes
more
and
more
complex
networks
become
more
and
more
complex.
It's
no
longer
just
a
few
simple
boxes
that
switch
all
out
your
packets.
There
are
more
software
components,
India,
there's
the
important
passwords
from
software-defined
network
to
network
function,
virtualization,
and
even
even
when
this
is
done
in
hardware.
I
It
often
a
software
component
to
it,
and
it's
often
even
done
in
software
nowadays,
instead
of
in
hardware.
Just
just
last
year,
we
had
a
project
in
the
5g
area
where
we
worked
was
a
big
company
who
were
interested
in
in
doing
some
performance,
research
of
software
components
in
the
5g
back
and
where
a
lot
of
stuff
is
being
virtualized,
their
virtualized
network
functions
doesn't
need
to
be
chained
together.
It's
quite
unclear
how
the
how
it
impacts
the
performance
if
you
have
different
things
competing
for
the
same
resources.
I
If
you
have
different
configurations
that
then
run
in
software
that
can
compete
for
hardware
sources
from
bandwidth
to
cache,
to
memory
to
whatever,
and
so
the
research
questions
are
from
the
assembler
thing.
What
are
the
important
performance,
metrics
sure
performance
metrics,
you
can
just
go
to
let's
say
of
C
2544
defines
measure
these
things
on
your
box,
but
it
doesn't
really
work
well
for
a
for
a
software
device
compared
to
a
hardware,
wise
yeah,
it's
20
years
old
and
was
designed
for
hardware
devices
there.
I
I
How
do
you
keep
that
stuff,
manageable
and,
of
course,
how
can
you
predict
performances
modules?
How
do
you
can
can,
if
you
are
planning
a
network,
and
you
want
to
know
how
much
harder,
how
much
softer
to
buy
what
hardware
to
buy?
How
can
you
do
that?
How
can
you
kind
of
get
a
model
for
the
for
the
behavior
for
the
performance
and
kind
of
predict
what
you
need
to
buy?
I
That
really
makes
work
work
easier.
Is
that
it's
fully
automated
test
workflow?
That
means,
if
I,
want
to
run
a
network
experiment
on
and
benchmark
something
I
really
write
a
script
that
defines
everything
that
starts
starts
from
I
want
to
use
this
this
and
that
server
I
want
to
configure
the
switch
that
way
or
I
know
that
they
are
directly
connected
and
then
there's
a
management.
I
The
data
and
already
has
some
basic
stuff
puts
them
in
a
Drupada
notebook,
and
so
we
can
start
running
analysis
of
the
data.
On
top
of
that,
this
is
really
nice,
especially
with
the
knife.
Buddha
have
a
big
collection
of
operating
systems
and
kernel
versions.
So
if
I
want
to
run
a
test,
how
to
see
how
the
front
kernel
versions
evolved
and
then
I
want
to
maybe
afterwards
I
think
oh,
this
might
be
another
good
metric.
Then
I
can
just
boot
the
whole
thing
again
and
run
the
test
and
the
whole
thing
again.
I
Instead
of
having
to
cope
with
downgrading
an
operating
system
or
anything.
So,
let's
get
to
the
the
main
part
of
the
talk.
Really
is
lost
just
a
longer
introduction
is
this
about
packet
generators,
so
this
is
a
big
packet
generator,
but
you
might
have
seen
or
anything.
There
are
a
few
problems
with
these
big
harder
boxes.
First
of
all,
they
are
big.
Second,
they
are
quite
expensive
and,
as
I've
heard
some
the
nice
guy
from
into
explains
it
like
this.
So
the
problem
is
them.
Shipping
around
extra
boxes
doesn't
scale.
This
is
I.
I
Think
true,
because
often
if
you
have
multiple
labs
and
you
don't
have
a
package
generator
for
each
of
them,
then
or
you
might
want
some
hardware
features
that
are
not
available
and
the
end
people
often
go
back
to
this
fancy
commodity
hardware.
Here,
a
few
normal
network
cards,
they
are
quite
cheap.
Comparatively
they
are
readily
available.
I
Whereas
if
you
use
a
software
package
generator,
it's
typically,
it
might
be
slow,
it
might
be
imprecise,
it
might
be
unreliable,
it
might
just
give
a
different
society
every
time
you
run
it,
and
this
is
the
problem
that
I'm
really
trying
to
solve
here,
I'm
trying
to
combine
the
advantages
of
both
software
and
package
on
our
software
and
hardware
packet,
generators,
that
is,
software
typically
cheap
and
flexible
and
hardware,
typically
very
precise
and
accurate,
and
so
the
five
main
design
goals
that
I
had.
First
of
all,
it
had
to
be
fast.
I
If
you
will
show
a
few
examples
of
how
our
typical
moonshine
script
looks
like
it's
always
its
core,
it's
always
an
explicit
multi-threading
and
explicit
multi-core,
because
that
is
really
the
only
way
to
scale
to
higher
speeds.
Sure,
a
single
10g
link.
You
can
fill
that
up
those
minimum
size,
packets,
meaning
about
50
million
packets
per
second.
Those
are
single,
CPU
call
it's
not
too
hard,
as
long
as
you're
not
doing
too
complicated
things,
but
as
soon
as
you
go
beyond
that,
you
need
to
be
able
to
run
multiple,
multiple
threads
at
the
same
time.
I
I
I
It
really
integrates
very
well
with
lower
other
things
and
you
can
get
direct
access
to
the
packet
memory
without
pesky
things
like
bound
checks
or
anything,
but
just
be
careful
when
you
write
your
test,
then
another
another
thing
that
was
traditionally
very,
very
challenging
for
software
package.
Generators
is
time,
stamping,
meaning
that
you
want
to
maybe
do.
Maybe
people
often
only
evaluate
their
a
few.
If
you
read
some
academic
papers
about
that
great
new,
whatever
out
or
whatever
switch,
they
often
only
give
you
ok.
I
This
is
the
number
and
throughput
that
man
uses
this
million
packets
per
second
or
even
though
us
disband
versus
typically
the
software
devices
I
was
tricked
by
packets
per
second
and
not
by
banthas,
but
you
rarely
see
latency
because
it
was
just
so
hard
to
measure
as
a
software
package
generator
and
especially
in
academia.
People
really
have
these
big,
expensive
hardware
boxes.
So
I
really
wanted
to
change
that
and,
of
course
turns
out
time.
Stamping
doing
it
precisely
in
software
is
a
challenging
problem.
I
But
if
you
read
the
data
sheets
of
your
typical
commodity
mix
carefully,
you
can
find
some
tricks
how
you
can
convince
the
heart
that
two
times
ten
packets,
basically
the
the
the
hardware,
often
has
support
for
the
PTP
time
synchronization
protocol,
which
needs
to
support
hardware
time
stamping
in
order
to
work
properly.
And
if
you
then
craft
packets
and
trick
the
hardware,
a
little
bit
actually
drive
a
little
bit.
I
Then
you
can
get
the
hardware
to
time
stamp
almost
arbitrarily
packets,
and
this
gets
really
nice
result
and
really
nice
insights
into
software
or
hardware
boxes
that
just
weren't
possible
with
software
time.
Stamping
another
thing
that
is
quite
quite
the
interesting
thing
and
was
more
more
important
than
I,
initially
thought
was
doing
rate
control,
meaning
controlling
the
traffic
that
assented
that
is
to
get
between
packets,
like
if
you
want
to
send
one
million
packets
per
second.
I
There
I
can
send
a
thousand
packets
sleep
for
some
time
for,
like
a
millisecond
sent
another
thousand
packets
sleep
for
one
more
millisecond,
and
then
you
get
at
the
million
packets
per
second.
But
I
can
also
sleep
between
each
packet,
for
one
microsecond
or
I
can
do
a
fancy,
Poisson
process
or
any
more
complex
pattern,
and
this
turned
out
to
be
hugely
important
than
investigating
software
systems
and
an
aspect,
that's
unfortunately
often
ignored,
and
then,
of
course,
I
wanted
to
make
it
open
source.
I
Because
what's
the
point,
if
only
I'm
using
it
I
wanted
to
make
it
really
easy
to
use
and
freely
available,
you
can
check
it
out
on
github
and
what
I'm
now
going
to
show?
You
is
just
just
only
only
a
few
well
measurements
and
and
a
few
sites.
Basically
and
I,
don't
want
to
bore
you
with
the
details.
I
This
is
really
a
point
that
I
really
like,
because
it
was
just
so
much
more
important
than
I,
initially
thought,
and
it's
so
often
just
ignore
what
people
just
send
a
burst
of
packets
and
say:
oh,
the
average
is
fine,
let's
call
it
a
day,
okay,
so
this
is
kind
of
kind
of
big,
confusing
graph,
but
it's
actually
really
easy.
This
is
a
really
simple
test
set
up.
I
What
I
did
here
was
I
took
two
servers
connected
them
as
two
10g
links
and
one
mooned
run
on
one
of
them
and
different
package
generators,
but
that
sort
of
on
paper
and
open
research
on
the
other
one
and
just
forward
packages
open
twist
which
no
fancy
packet
modification.
Nothing,
no
fancy
open,
V
switch
configuration
just
sent,
take
packets
from
one
part
and
send
him
out
on
the
other,
using
the
normal,
open,
V
switch
kernel,
module
I.
Think,
okay,
there's
a
really
boring
test.
I
But
if
you
dig
down
into
even
such
a
simple
software
software
forward
in
case
it
really
shows
you
what
kind
of
complexity
is
hidden
behind
the
seemingly
simple
example.
So
this
graph
shows
the
x-axis
is
overload,
meaning
I'm
increasing
load
in
this
case
was
restricted
to
one
flow.
The
forwarding
device
was
restricted
to
one
CPU
core,
because
if
you
go
motocross
Numa,
then
this
opens,
and
you
can
so
the
simplest
possible
thing
and
I
configured
moongeun
to
use
different
different
sizes.
I
The
default
I
just
generated
constant
bit
rate
traffic,
meaning
a
constant
gap
between
the
packets,
and
this
is
the
baseline
of
this
measurement,
meaning
a
hundred
percent,
and
the
measured
thing
here
is
the
latency
relative
to
that
case.
So
what
you
would
expect,
if
you
run
your
packet
generators
a
few
times
on
the
same
case,
you
would
expect
the
device
under
test
to
show
the
same
latency
response,
because
why
would
it
be
different?
And
especially,
you
would
expect
to
get
the
the
same.
I
Latency
result
if
using
different
packet
generators,
if
you
don't
change
your
device
and
a
test,
but
what
we
did
in
the
past,
we
had
different
package
owner,
doesn't
get
completely
different
results
for
the
latency
of
this,
the
same
device
and
a
test
to
be
investigated
estrada,
and
this
graph
is
what
I'm
varying
here
was.
The
different
graphs
in
that
diagram.
Here
is
just
the
burst
size,
meaning
the
baseline
one
packet
sleep
for
some
time,
one
packet
and
so
on,
and
then
four
packet.
I
Sixteen
packets
are
the
two
packets
and
so
on
and
see
how
the
latency,
relatively
to
the
base
case,
changes
and,
as
you
can
see,
even
with
something
as
a
burst
size
of
four
or
16.
You
can
quickly
get
a
relative
latency
that
differs
by
a
hundred
percent,
or
so
so
you
just
get
a
completely
different
asides
just
by
changing
how
the
packets
are
spaced
on
the
wire,
without
even
going
into
anything
from
the
content
of
the
packets.
I
I
We
have
another
paper
on
this,
where
we
compared
a
lot
of
different
software
package
generators
on
how
reliable
you
can
generate
what
we
configure
them
to
do
at
first,
it
turned
out
to
be
very
hard
to
even
get
them
to
send,
didn't
try
to
send
CBR
traffic,
some
claimed
to
send
CBR
traffic,
but
then
have
some
optimizing.
Oh
sorry,.
A
I
I
Sometimes
in
there
sometimes
had
a
kernel
component
and
that
then
fetch
them
together
well
to
make
it
faster,
but
it
was
not
very
helpful
and
then
they
lied
to
you
and
even
even
when
we
managed
to
configure
it
it
they
still
send
out
bursts
because
it
turns
out
it's
only
hard
to
send
an
individual
packet
to
a
network
cut
it's
just
not
what
they
are
designed
to
do
and
in
mundo-
and
this
is
better
but
there's
not
a
detail.
I'm
going
to
bore
you
about
a
12
page
paper
about
it.
I
I
I
Sd
SD
was
had
before
it's
basically
the
baseline
with
collecting
the
latency
here
for
the
CBR
case,
and
it
looks
really
weird
at
first,
it's
okay,
it
seems
to
be
increasing
and
there's
one
we
had
spiked
the
Spikers,
completely
reproducible
across
different
systems,
different
things
and
right
before
overloads,
it
drops
completely
latency
latency
gets
better.
This
is
also
completely
reproducible.
Consider
more
measurement
points
in
there,
because
when
I
first
saw
this
I
was
like
well
as
can't
be
I
need
to
measure.
Maybe
destroy
study
different,
but
it
just
reliably
drops
there.
I
I
was
having
kind
of
okay
kind
of
works,
also
hard
to
measure,
because
by
default
the
UNIX
can
you
find
in
most
distributions
doesn't
report
the
CPU
time.
Consumed
per
interrupter
can
be
at
100%,
CPU
load,
but
edge
drop
reports.
You
are
at
10%
because
it
doesn't
account
enter
up
time
properly
unless
you
sit
there
acute
time,
accounting,
selector,
compiling
economy
or
directly
with
the
CPU
performance
counters,
and
this
is
completely
different,
piped
off.
So
now
this
kind
of
looks
weird
and
they're.
I
The
reason
why
it
looks
weird
is
really
that
the
that
these
algorithms,
that
try
to
estimate
rate
and
so
on,
they
don't
play
well
with
CBR
traffic.
They
kind
of
get
confused
and
there
are
a
few
state
machines.
If
you
get
them
unready,
it
keeps
switching
between
two
states
all
the
time,
because
they
get
surgery
confused
by
the
CBR
traffic.
Then
I
don't
know
exactly
what
happens,
but
you
get
these
motor
sites.
So
let's
use
APIs
or
process
instead
and
there
just
looks
much
smoother
and
the
site
is
much
more.
I
What
you
would
expect
and
the
only
thing
I'm
changing
between
these
two
measurements
is
again
their
time
between
packets,
in
this
case
from
CBR
to
Prasad
and
much
more
reasonable
result.
And
if
you
look
at
real
world
traffic,
it's
of
course
you
all
know
that
really
old
sitcom
paper
about
how
you
shouldn't
model
your
Internet
traffic
proposal
process,
but
that's
only
really
true
for
larger
timescales.
I
If
you're
running
your
test
of
a
few
minutes
or
whatever,
then
you
can
use
a
Poisson
process
to
reasonably
approximate
what
real
traffic
looks
like
and
then
you
get
these
nice
nice,
smooth
suicides
and
more
in
more
realistic
scenario,
which
is
also
what
this
is
about.
So
what
does
the
latency
measurement
of
look
like
if
you
want
to,
if
you
know,
installed
Mundra,
and
you
want
to
drill
down
into
an
really
one
measurement?
I
You
get
these
nice
histograms,
which
are
just
some
way
to
represent
how
the
latency
is
distributed
and
typically
for
many
cases
you
want
to
see
the
F
instead,
but
a
histogram
is
well
easier
to
see
visually.
So
what
you
can
see
here?
These
are
just
measurements
of
a
few
systems.
The
first
one
is
a
software
for
water
running
directly
on
the
machine.
You
can
clearly
see
there's
some
interrupt
sorting
going
on,
so
you
get
this
uniform
distribution
kind
of
neat
and
the
second
one
there's
a
virtual
machine
and
the
virtual
switch
and
everything
involved.
I
Then
we
get
this
long.
Tail
distribution
and
I
actually
cut
it
off.
Yet
it's
actually
long
tail
and
there
are
some
of
those
cases,
there's
also
an
interesting
thing
to
measure.
They
are
just
just
if
you
work
until
99.99%
I
love
some
latency
measurement,
and
then
you
see
some
horrible
results
there.
If
you,
if
you
are
benchmarking
a
virtual
machine
or
anything,
this
can
also
be
a
big
problem,
and
it's
also
another
thing
where
you
can
get
probably
a
whole
PhD
on
how
this
happens,
why
it
happens,
how
to
measure
it
and
a
hacker
box.
I
This
is
just
something
to
show
how
precise
this
really
is,
because
if
you
note
the
x-axis
it's
and
microseconds
and
only
goes
up
to
3.5,
microseconds,
typically
saying
the
position
of
the
Mundra
and
hardware
time,
stamping
approach,
it's
typically
plus
minus
and
plus
minus
subscribe
nanoseconds.
That
is
quite
good
for
most
things
that
typically
typically
agencies
of
the
hardware
box.
Its
new
range
of
a
microsecond,
or
maybe
500,
nanoseconds
to
a
few
microseconds,
a
software
box
around
ten
microseconds.
I
If
it's
good
and
a
hundred
efforts
during
some
parts
having
stuff-
and
you
can
see
here-
is
a
nice
bimodal
distribution,
and
this
is
who's
just
an
example
where,
if
you
want
to
break
it
down
to
one
way
or
your
latency
or
anything,
it
doesn't
really
work,
because,
what's
the
average
of
this?
What's
the
meaning
of
the
average
of
this
is
really
nothing
so
really.
G
I
Of
the
median
of
this,
it
has
two
clearly
distinct
paths
in
the
hardware.
In
this
case
it
was.
It
was
an
output
part
that
was
used
by
multiple
input
parts
and
they
are
just
two
cases
either.
It
goes
to
the
cut
through
pass
if
there's
no
packet
being
queued
from
the
other
port
or
there's
a
packet
being
Cureton,
so
it
gets
queued
for
a
short
time
then
goes
to
the
other.
I
If
you
look
at
the
example
scripts
and
if
you
look
at
your
basic
assembly
script
that
generates
different
UDP
flows
and
to
report
sir
sites,
you
should
quickly
get
an
idea
of
how
to
modify
it
for
your
needs
or
how
to
act.
Multiplayer
things
and
the
way
we
do
multi-threading
is
respond
completely
independent,
virtual
virtual
machines,
virtual
machines,
in
the
sense
of
a
language
implementation,
virtual
machine
for
the
just-in-time
compiler,
and
that
is
really
they
are
really
completely
independent.
And
there
are
nice
api's
that
allow
you
to
talk
between
these.
I
These
independent
sets,
but
their
main
ideas
are
shared.
Nothing
approach,
because,
in
the
end,
what
you
want
to
generate
as
multiple
flows
and
they
are
often
independent
from
each
other
or
you
can
break
them
down
into
a
few
independent
chunks,
and
that
makes
it
really
really
high
performance.
And
we
have
to
look
at
the
examples
to
get
an
idea
of
what
I
mean
by
this.
So
and
I.
Don't
know
so
a
quick
except
I,
don't
know
how
much
time
I've
left,
there's
no
clock
how
much
time
I
got
left.
I
Great
this
seems
perfect,
so,
okay,
I'm
gonna,
show
this
example
and
in
this
case,
and
this
example
is
based
on
our
the
excellent
example.
This
is
also
something
we
wanted
to
test
the
exam
and
then
the
package.
You
know
that
is
almost
VX
and
I.
Don't
know
that's
protocol
and
well,
but
for
you
and
so
there,
the
first
thing
that
you
can
do
is
you
can
dynamically
general
design
a
a
complex
take
of
headers?
And
really
these
are
just
ahead.
I
Us
moon
drain
is
still
a
low-level
package
generator,
not
a
traffic
generator,
meaning
there's
no
protocol
logic
behind
that
you're
just
sending
out
packets
and
the
protocol
logic
is
like
absolute
minimum
like
we
implement
up
and
NACP
and
whatever
you
you
expect
for
basic
functionality
and
there's
like
the
hashing
algorithm
to
get
the
source
port
of
the
expand
and
so
on
and
to
check
some
check
some
stuff
and
check
some
of
loading.
But
it's
not
the
traffic
generator
can't
build
a
tcp
stream
from
it.
I
I
There's
a
VLAN
tag
is
enough,
remembers
another
ipv4
header
and
UDP,
oh
by
the
way
everything
we
have
is
also
a
p
v6
capable
because
the
guy
who
wrote
the
body,
the
protocols,
tech
stuff,
he
really
likes
ipv6,
and
so
all
the
examples
also
do
ipv6
yeah
and
once
you
have
that
thing
it
gets
just-in-time
compiled
and
the
next
thing
you
do
is
you
create
a
memory
pool
with
a
packet
archetype,
meaning
this
is
just
some
some
basic
packet.
This
is
quite
memory
pool.
This
is
just
Maps.
I
If
you
know
duplicate,
then
you
will
see
how
this
maps
to
the
PDK
stuff,
and
then
you
fill
each
of
your
packets
with
the
archetype.
This
means
you
AVX
dance,
Texas,
initially
an
empty
packet.
You
tell
it.
Okay,
I
wanted
to
be
a
the
exam
tech
packet
and
then
you
can
call
this
magic,
filler
method,
which
is
very
slow.
But
you
only
do
this
once,
and
this
has
nice,
nice
setters,
basically
for
all
the
headers.
I
You
have
in
your
stack
with
the
names
that
you
defined
before
and
you
can
do
stuff
like
lookup
and
MAC
address
here
and
you
can
basically
set
settings
and
then
you
can
tell
it
to
calculate
the
checksums
and
the
scheduler
checksum
is
again
a
magic
message
that
goes
through
the
whole
stack
and
knows
that.
Okay,
there
is
this
checksum
and
to
calculate
that
or
adjust
either
example.
Just
does
it
for
one
thing,
but
there's
also
another
method
that
does
it
for
all
the
things
in
your
header,
because
I
think
I'm,
using
or
flirting
here.
I
Okay
now
this
is
basically
the
initialization
I
defined
my
stack
I
defined.
What
I
wanted
to
look
like,
and
then
there
are
some
boilerplate
code
like
commands
and
argument
handling
and
and
whatever
and
and
then
the
next
thing
is
you
write
the
actual
transmit
loop,
meaning
you
write,
the
the
core
of
the
of
your
transmit
loop
of
your
package
generate
a
test
script,
and
this
is
this
is
so
completely
different
from
other
package
generators,
because
in
the
end,
it's
it's
not
really.
A
package
generator
pose.
I
It's
a
it's
a
framework
for
writing
package
generators
and
you
write
your
own
one
based
on
one
of
the
examples
and
a
lot
of
boilerplate
code.
So
what
you
do
here?
You
allocate
some
buffer
array
in
this
case.
It's
default
back
size
and
yes,
this
example
sends
out
bursts
unless
we
configure
that's
right
after
I
can't
go
into
the
details
about
how
the
right
control
works
and
then
you
at
the
actual
main
loop,
that
just
checks
is
the
process.
They're
learning,
meaning
that
someone
press
control
sees
and
sick
term
or
did
another
task?
I
Stop
it
and
we
tell
it
okay,
nice.
We
want
some
packets
on
our
memory
pool
and
we
just
get
the
packets
with
the
packet
archetype
that
we
previously
filled.
We
iterate
over
these
packets
and
again
cast
them
to
the
to
detect
that
post
period
compared
this
castle
operation
is
a
completely
free
operation.
There's
no
circus
behind
you,
it's
just
the
equivalent
of
a
see
cast,
and
it
doesn't
do
anything.
Besides
tell
the
compiler.
Okay
I
want
to
use
these
offsets
for
my
packets
and
then
I
can
just
access
these
packets.
I
I
In
the
newer,
a
scripting
language
there
are
I've
talked
to
two
people
from
some
companies
they're
like
basically,
oh,
but
our
at
least
engineers.
They
are
not
programmers,
they
can
just
click
on
the
X
jeogori
and
click
the
start
button.
We
can't
use
this
okay,
so
let's
make
it
somewhat
easier
and
in
this
case
at
a
config
file
to
it
there's
some
new
work.
I
The
work-in-progress
might
be
completely
buggy,
but
completely
buggy,
but
might
contain
bugs,
and
so
and
in
this
config
file
we
just
define
defined
flows
to
give
the
flow
a
name,
and
we
tell
that
the
packet
type
a
few
predefined
packet
types.
Otherwise,
you
can
use
the
magic
magic
protocol,
it's
taxing
again
and
then
this
is
basically
the
same
syntax.
Just
with
a
few
syntactic
sugar
things.
I
You
need
to
tell
it
if
it's
a
MAC
address,
you
need
to
tell
it
if
it's
nappy
address
and
then
you
can
define
things
like
ranges
or
random
Rangers,
which
then
get
basically
well
not
compiled
to
code,
but
they
basically
it's
efficient.
In
the
end,
it
works
for
us
a
lot
of
anonymous
functions
and
magic.
In
this
case.
This
is
your
typical
simplest
example.
Please
don't
copy
paste
and
run
it,
because
that
ipv6
others
as
one
of
my
first
service
and
then
once
you
have
key
he's
pretty
of
these
flows.
You
can
purify.
I
Flosser
can
define
your
own
one.
Then
you
can
under
moonshine
simple
interface,
that
in
start
and
the
name
of
your
flow
on
which
device
to
send
on
which
device
you
want
to
receive.
If
you
want
to
just
see
counters,
for
how
much
stuff
is
getting
back
and
then
you
can
set
a
few
parameters
like
the
packet
rate
like
if
you
want
to
use
per
so
for
control.
I
If
you
want
to
use
whatever
how
many
shots
you
want
to
use
bypassing
the
same
device
multiple
times,
you
can
combine
different
flows,
you
can
set
time
limits
for
individual
flows
and
so
on,
and
you
get
then
per
flow
packet,
counters
and
yeah.
What
you
also
can
do
here,
which
is
it's
often
quite
annoying,
to
be
back
something
like
this,
because
in
the
end,
you
want
to
know
what
it's
actually
sending
out
and
then
you
might
end
up
using
TCP
dump
on
your
destination
device
or
dumping
message.
Here's
like
I,
simply
debugging
interface.
I
That
can
show
you,
okay,
giving
this
config
file
in
this
configuration.
The
packets
that
I'm
going
to
send
out
would
look
like
this.
Here's
an
example
of
five
packets,
and
these
are
the
fields
that
are
being
randomized
or
modified,
and
this
is
still
work
in
progress.
In
particular,
I
know
that
I
just
recently
broke
the
Poisson
process
for
the
traffic
generation,
so
yeah
I'm
working
on
this,
we
got
it
fixed
by
next
week,
somehow
work
on
outright
a
duplicate,
no
idea.
I
I
said
I
couldn't
share
the
actual
code
for
the
for
the
DDoS
attacks
for
legal
reasons,
which
apparently
something
about
hacker
tools
and
France
or
so,
but
they
contributed
in
escort,
and
it
should
be
relatively
simple
to
build
some
in
SD
dos
testing
device
based
on
top
of
that.
So
this
is
interesting
because
it
uses
the
complex
protocol
six
and
then
the
last
thing
I
want
to
point
out.
This
is
really
interesting
because
they
actually
used
Mundra
how
it
was
intended
to
be
used.
I
Most
people
just
use
my
standard
example
script,
which
sends
out
randomized
to
DP
packets
and
say:
okay,
it
gets
me
the
number
of
flows
I
type
in
there
and
it
gets
me
latency,
that's
good
enough
and
they
maybe
change
one
line
in
the
code.
But
these
guys
and
we
open
a
few
project.
They
really
build
a
nice
test
harness
around
moon
drain,
but
they
actually
use
much
support.
I
So
I
hope
you
found
this
kind
of
tutorial
style
lesson.
Useful
I,
hope,
maybe
to
find
a
few
new
users
for
some
things.
That
has
a
broad
range
of
applications,
as
you
can
see
here
and
hope
you
enjoyed
it
and
I
believe
there
are
a
few
minutes
for
questions
left
and
if
anyone
really
scans
a
QR
code
ever
you
can
scan
it
here.
I
can
just
type
moon
run
into
Google
and
you
will
find
it
on
github.
J
Hi
Dan
Bogdanovich,
actually
very
nice
work
and
I'm
pleasantly
surprised
in
package
generation.
The
package
iteration
so
far
has
been
an
issue
and
domain
of
the
expensive
guys
and
seeing
an
implementation
using
VP
DK,
you
know
solves
many
of
the
problems,
especially
up
to
a
10
gig
space.
So
thank
you
for
the
work.
Thank.
A
I
K
K
K
What
would
you
say
to
a
specification
that
calibrated
the
generators,
in
other
words
like
policing,
kind
of
like
policing,
the
police,
would
would
I
mean
I'm
beginning
to
think
because
of
the
sensitivities
we've
we've
seen
and
you've
seen
that
that
might
be
a
valuable
spec
to
pursue.
What's
your
thoughts,
that's.
I
An
interesting
idea,
as
I've
said,
I
have
and
I
believe
I
have
a
few
graphs
here
and
like
this.
Just
for
me
in
packets
per
second
and
a
few
software
package,
a
notice
and
how
they
even
even
wind
and
then
configure
to
use
poor
software,
doesn't
try
to
hit
this
target,
which
is
12,
50,
nanoseconds
and
but
some
significant,
diverse
and
package
on
duplicates
not
not
visible
here,
but
they're,
huge
outliers
and
they're,
because
the
printer
statistics
in
the
same
settings
are
really
bad
idea.
I
I
K
E
E
K
I
A
A
L
You
Alison,
so
it's
actually
pronounced
lowland
fungi
swag
day,
but
I'm
not
going
to
torture
people
and
force
them
to
do
that.
So
my
talk
today
is
going
to
be
about
the
use
of
elliptic
curve
cryptography
in
DNS
SEC,
which
is
what
the
paper
that
was
that
gautier
NRP
was
actually
about
and
I'm
going
to
go
into
a
little
bit
more
detail
about
some
follow
up
work
that
we
did
after
writing.
That
paper
and
also
going
to
go
into
some
detail
about
the
doctrine
of
these
cryptographic.
L
Thank
you.
This
is
me,
surrounded
by
my
committee.
You
may
recognize
some
of
the
people
in
that
committee.
Some
of
them
are
here
in
the
room,
so
no
pressure,
no
pressure
but
I'm
gonna
go
into
the
meat
of
the
presentation
now
and
I'm,
not
going
to
repeat
all
of
the
earlier
research
we
did.
There
are
some
pointers
on
the
slices
slicer
actually
up
on
the
material
site
for
this
this
meeting
and
at
the
end
there
is
a
set
of
references
to
all
the
papers
I'm
referring
to.
L
L
L
Tow
achieves
the
same
goals
as
RSA,
so
it's
a
public
key
cryptography.
You
can
do
signatures
with
it,
but
the
nice
thing
about
ECC
is
that
the
both
the
keys
and
the
signatures
are
much
smaller
than
they
are
for
RSA,
while
they
offer
greater
cryptographic
strength
and
to
give
you
an
example,
a
typical
case
is
used
for
elliptic
curve.
L
So
why
wouldn't
we
switch
to
ECC
immediately
for
the
in
a
sec?
Well
to
quote
our
essays
RFC
605,
which
is
the
RFC
that
actually
standardizes
the
use
of
the
elliptic
curve.
Digital
signature
algorithm
in
DNS
SEC
validating
RSA
signatures
is
significantly
faster
than
validating
ECDSA
signatures
about
five
times
faster.
L
So
the
goal
of
the
study
in
this
paper
was
if
we
switch
DNS
sick
from
using
RSA
to
using
ECC.
How
does
that
impact
validating
DNS
resolvers
right
so
rather
than
recommend
to
everyone?
Well,
these
easy
say:
ECC
signatures
are
much
smaller.
It's
really
nice
to
switch
to
them.
Let's
work
out
if
we're
not
introducing
a
new
problem
by
giving
this
recommendation-
and
that
was
the
purpose
of
this
study.
So
how
do
we
go
about
doing
this?
L
We
decided
to
do
a
measurement
study
and
some
modeling
for
this
and
our
method.
I'm
gonna,
describe
our
methodology
in
the
next
couple
of
slides
and
we
started
out
from
the
premise
that
we
want
that
we
had
this
intuition
that
if
we
knew
the
number
of
outgoing
queries
from
resolver,
so
that's
not
incoming
crash
or
clients.
That's
the
queries.
The
resolver
sends
to
authoritative
name
servers
on
the
internet
that
we
might
be
able
to
predict
the
number
of
signatures
validations
that
it
has
to
perform.
L
Given
that
load
right-
and
that
was
our
premise
and
I'm
gonna
get
I'm
gonna
talk
you
to
four
factors
that
influence
the
number
of
signature
validations
that
a
resolver
will
have
to
perform
now.
The
first
factor
is
that
for
every
query
that
a
dns
resolver
sends
to
an
authoritative
nameserver
on
the
internet,
it
will
not
always
get
a
response
right.
So
the
number
of
responses
that
come
back
are
somehow
a
factor
in
this.
L
The
third
factor
is
the
number
of
signatures
in
the
response
that
contain
signatures
right,
because,
while
you
might
expect
a
response
to
contain
a
single
signature
for
the
record
that
you
requested,
actually
we
observed
that
on
average,
every
response
that
contains
signatures
has
somewhere
in
the
order
of
between
2.4
and
2.5
signatures
per
response.
That
has
signatures.
That's
because
there
are
signatures
in
the
additional
section.
There
might
be
extra
records
in
there
that
require
signatures,
so
this
intuition
doesn't
hold.
There
are
more
signatures
in
a
response
than
just
for
the
record
that
you
requested.
L
Is
because
it
doesn't
have
a
full
chain
of
trust
all
the
way
up
to
the
root,
so
it
might
not
be
able
to
validate
that
particular
signature,
and
it's
not
going
to
bother
to
spend
the
CPU
cycles
on
it
right
and
to
remind
you
again,
we
do
not
measure
the
number
of
queries
from
clients,
because
that
very
strongly
between
resolvers.
We
wanted
to
build
a
model
that
we
can
apply
to
any
resolver,
regardless
of
its
client
population,
and
if
I'm
not
gonna,
go
into
detail
in
the
presentation.
L
But
in
the
paper
you
will
see
that
the
model
is
actually
a
little
bit
less
accurate
for
resolvers
that
have
a
small
client
population.
But
those
are
the
resolver
that
we
really
don't
have
to
worry
about
as
much
because
they
will
be
validating
far
fewer
signatures,
because
they're
processing
far
fewer
queries
right.
L
So
how
did
we
measure
this?
This
picture
shows
you
our
measurement
setup
and,
on
the
left
hand
side.
You
see
clients
which
is
typically
you
with
your
laptop
unless
you're
an
idiot
like
me
to
run
servers
over
on
their
laptop
and
then
what
we
did
was
we
captured
traffic.
That
was
going
to
production,
DNS
resolvers,
and
then
we
forward
this
traffic
to
an
instrumented,
DNS
resolver.
So
we're
sending
a
copy
of
the
exact
query
traffic
that
goes
to
a
production
resolver
to
one
that
we
instrument,
and
then
we
measure
certain
factors
on
that.
L
If
we
then
look
at
all
of
these
four
factors
that
I
described
in
the
methodology
slide-
and
you
plot
those
as
a
scatter
plot-
and
then
you
see
from
top
left
to
bottom
right,
all
of
the
four
factors
so
a
shows
you,
the
number
of
queries
on
the
x-axis
number
of
responses
that
come
back
on
the
y-axis
B
shows
you.
The
number
of
responses
on
X
versus
number
of
responses
containing
signatures
on
Y
C
shows
you
number
of
response.
L
A
number
of
signatures
per
response
and
D
is
a
number
of
signatures
that
are
actually
validated
or
fractional
signatures.
That's
actually
getting
validated.
Now,
if
you
look
at
these
graphs,
then
your
intuition
might
be
that
you
could
model
this
with
a
linear
model,
although
especially
graph
B
has
a
lot
of
noise
in
it,
but
as
it
turns
out
graph,
B
is
not
the
one
that
we
want
to
worry
about,
which
is
the
number
of
responses
that
contain
signatures,
because
we're
actually
going
to
use
that
later
on
in
the
model.
L
So
there
the
accuracy
is
not
an
issue
for
the
other
ones.
We
tried
if
we
can
approximate
this
with
a
linear
model,
and
it
turns
out
that
we
can
so
I'm
not
going
to
talk
you
through
all
of
this,
but
we
came.
The
details
are
in
the
paper,
but
we
created
a
simple
set
of
linear
equations,
that
you
can
then
combine
to
make
a
model
for
a
validating
resolver
and
it
has
four
important
parameters.
L
So
the
first
one
is
the
average
number
of
responses
per
query,
and
this
is
something
that
you
need
to
measure
on
an
operating
resolver
to
actually
populate
the
model.
So
these
are
parameters
that
you
would
need
to
measure
the
fraction
of
responses
with
signatures
and
the
average
number
of
signatures
per
response
and
a
fraction
of
signatures
that
is
validated
Oh.
L
Okay,
I'll
try
to
eat
the
mic,
as
somebody
suggested
yesterday.
Okay,
so
of
course,
if
you
make
such
a
model,
you
need
to
validate
if
it
works.
So
we
validate-
or
we
said,
as
we
set
out
for
criteria
that
we
use
to
validate
this
model,
and
the
first
one
is
that
we
wanted
to
make
sure
that
the
model
works
for
a
different
DNS
resolver
implementation.
L
So
we
tested
it
for
unbound
and
bind
and
actually
I
had
a
student
do
some
tests
with
all
readiness
as
well,
which
at
the
time
they
were
implementing
validation
in
the
resolver,
unfortunately
wasn't
stable
enough,
and
the
same
is
true
for
not
resolver,
which
was
then
still
under
development,
but
in
principle
you
could
apply
to
those
two
and
we
get
some
tests
with
it
now.
The
second
thing
we
wanted
to
validate
is
whether
the
model
has
stable
properties
over
time
and
actually,
like
I,
said
only
alpha.
L
S,
which
is
the
number
of
the
diffraction
of
responding
responses
that
contain
signatures
can
vary
significantly
over
time
because
we
vary
this
parameter
to
do
to
make
predictions
right.
So
we
don't
really
care
if
that's
stable
over
time,
but
the
other
factor
should
be
more
or
less
stable
over
time.
So
we
measured
over
a
five
month
period
and
didn't
see
major
changes
in
in
these
two
in
the
rest
of
the
parameters
of
the
model.
L
And
finally,
we
checked
if
the
model
is
actually
a
good
predictor
of
imparity
observed
data.
So
what
we
did
was
we
populated
the
model
made
predictions
of
what
we
thought.
The
number
of
signatures
that
we
need
to
validate
what's
going
to
be
and
then
compare
that
to
what
we
saw
in
actual
practice
and
again
the
details
forever
in
the
paper,
but
we
did
some
statistical
goodness
of
fit
tests
for
that
now.
The
next
thing
that
we
have
to
do
is
now
that
we
are.
L
We
have
a
model
for
predicting
the
number
of
signature
validations
that
are
required.
We
of
course
need
to
know
how
ECC
performs
right,
and
although
there
are
some
benchmarks
publicly
available
that
we
used
in
in
in
an
earlier
paper,
we
wanted
to
make
sure
that
we
had
up-to-date
benchmarks.
So
we
took
five
implementations
of
elliptic
curve,
cryptography
and
benchmark
those
on
them.
On
a
modern
CPU,
we
took
three
versions
of
OpenSSL,
one
that
we
consider
a
legacy.
L
So
you'll
see
that
in
older
distributions,
one
that
we
considered
long
term
support
because
it's
in
in
all
of
the
long
term,
support
versions
of,
for
instance,
the
major
Linux
distributions
and
one
that
we
considered
at
the
time
to
be
new
and
optimized,
and
it's
actually
moving
into
long
term
support
now
and
that
had
optimized
implementations
of
ECDSA
P
256.
So
that
is
the
algorithm
that
we
expect
will
be
used
the
most
in
DNS
ech
at
this
point
in
time
and
actually
there's
now
OpenSSL,
1.1
or
0,
which
was
not
performed
that
differently
from
102.
L
So
this
is
actually
still
a
good
set
of
benchmarks
to
use.
Today,
then,
we
looked
at
the
newer
elliptic
curve,
algorithms
82,
four
five,
one
nine
and
eighty
four
four
eight,
which
have
only
recently
been
standardized
for
use
in
DNS
SEC.
And
there
again
we
took
optimized
implementation
of
these
two
algorithms,
because
the
the
reference
implementation
of
those
don't
perform
very
well.
L
So
easy.
Do
you
say
P
256
is
an
order
of
magnitude
slower
than
RSA
1024,
and
why
is
that
a
good
comparison,
because
we're
you
could
argue
that
we're
comparing
apples
and
oranges
right
because
ECD
is
AP.
Two
five
six
cryptographically
is
much
stronger
than
RSA
1024,
but
I
would
argue
that
you
need
to
make
this
comparison,
because
most
of
the
signatures
that
you
see
in
the
NSTIC
today
are
signatures
with
zone
signing
keys
that
are
1024
bits.
L
Where
did
that
make
sense
in
terms
of
security
or
not,
you
can
debate,
but
that's
the
case
and
then,
if
you
take
ECDSA
P
384,
which
is
greater
perfectly
even
stronger,
you
compare
that
to
something
like
RSA
2048.
You
see
again
that
there
is
an
order
of
magnitude
performance
difference,
so
this
is
way
more
than
the
five
times
that
is
quoted
in
the
RFC.
L
This
is
not
the
top-end
CPU,
but
it
would
be
a
common
CPU
that
you
would
encounter
in
server
architecture.
So
this
is
typically
something
that
people
have
in
their
data
center
right.
We
have
data
centers
full
of
these
stuff
unless
you're
really
rich
in
your
Google.
You
have
these,
and
why
did
we
pick
these
particular
benchmarks
because
you're
going
to
see
them
in
the
graphs
that
I'll
be
showing
you
in
the
in
the
next
couple
of
slides?
So
we
picked
ECDSA
p3,
therefore,
because
this
was
a
worst
case
scenario
right.
L
This
is
the
the
slowest
of
all
of
the
algorithms
that
we
benchmarked
and
it
is
the
strongest
broadly
supported
cipher,
and
what
do
I
mean
by
that?
You
could
say
that
84
4,
4
8
at
the
bottom
of
the
slide,
is
stronger
in
terms
of
cryptography.
But
it's
not
widely
available
in
implementations,
so
few
people
are
going
to
use
it.
So
that's
why
we
took
P
384
as
sort
of
a
benchmark
to
compare
against
then
P
256
on
openness
l1a1.
L
So
let's
go
back
to
our
original
question,
which
was
what
is
the
impact
on
validating
the
US
resolves
right,
because
that's
why
we
started
this,
so
we
use
our
model
to
evaluate
or
to
estimate
future
performance
right,
and
we
took
a
look
at
two
scenarios.
So
the
first
scenario
is
what,
if
we
take
currently
in
a
sick
deployment-
and
we
switch
all
of
those
domains
over
to
ECC
overnight,
so
everything
that's
now
signed
with
RCA
or
DSA
or
whatever
you
use,
will
switch
that
to
ECC.
L
Is
that
an
issue
well
based
on
the
measurements
that
we
did
on
our
resolvers?
We
argued
that
you
need
about
150
signature,
validations
per
second
for
a
busy
result
where
this
was
a
result
for
processing
around
20,000
queries
from
clients
per
second.
So
this
was
a
busy
resolver
and
that's
not
a
problem,
and
even
if
we
take
the
model-
and
we
put
in
the
worst
case
numbers,
we
still
don't
go
above
the
worst
case
scenario,
which
is
using
p
384.
L
So
that's
not
an
issue,
but
what,
if
everybody
deployed
the
NSTIC
and
if
they
used
ECC
right
so
right
now,
the
NSTIC
deployment
is
roughly
three
three
and
a
half
percent
of
all
domains
on
the
internet.
What
if
a
hundred
percent
of
those
were
to
deploy
it
in
a
sec,
and
they
all
use
ECC
to
sign?
What
does
that
do
to
your
resolve?
L
So
the
second
scenario
that
we
evaluated
is
a
popular
domains.
First,
growth
to
a
hundred
percent
domestic
deployment,
and
everyone
uses
ECC.
Now,
what
do
I
mean
by
popular
by
popular
I
mean
that
the
domains
for
we,
for
which
the
resolver
sense
to
most
queries
to
the
internet,
if
that
switch
is
to
ECC
first
right,
and
so
here,
I
plot.
L
The
query
popularity
for
queries
that
the
resolver
sends
to
authoritative,
nameservers
and-
and
this
shows
you
this
is
a
classic,
so
you
can
see
the
the
axes
are
low
cloak
and
this
is
a
classic
internet
distribution.
It's
commonly
referred
to
as
ship
for
long-tailed
or
Plato
or
80/20
doesn't
really
matter,
but
basically
what
it
means
is
that
the
most
popular
query
and
is
by
far
responsible
for
the
highest
number
of
queries
sent
out
to
the
Internet.
L
So
let's
look
at
some
results.
So
these
are
the
really
nice
graphs
that
my
student
cooked
up
he's
a
MATLAB
wizard
and
what
you
can
see
in
this
graph
on
this
axis
and
we
can
debate
what
you
call
that
axis.
But
I
would
say
it's
the
y
axis.
You
see
the
intersect
deployment
and,
as
you
may
remember,
I
said
that
we
will
be
varying
the
average
number
of
responses
with
signatures
to
simulate
the
intersect
deployment
right.
L
L
The
takeaway
from
this
is
that
there
is
ample
room
for
growth
in
the
NSTIC
deployment
and
outgoing
query
load
right,
so
we
can
go
up
to
100%
DNS
SEC
deployment
using
ECD,
DSA,
P
384,
and
the
number
of
outgoing
queries
from
that
resolver
could
still
double
and
Unbound
would
still
be
able
to
validate
those
signatures
on
a
single
CPU
core
right,
and
so
this
is
a
conservative
estimate.
If
you
run
a
really
busy
resolver
you're
working
at
an
ISP,
you
typically
don't
have
a
single
core
assigned
to
that
resolver.
L
So
this
is
something
that
is
easily
within
the
realm
of
the
possible.
So
that's
a
great
result.
We
can.
We
can
take
the
worst
case,
algorithm
and
unmount,
we'll
still
be
able
to
cope
with
it.
So
what
does
this
picture
look
like
for
bind
I
apologize,
because
the
title
of
the
slide
has
somehow
gone,
but
this
is
bind
and
for
bind.
We
observe
something
a
little
bit
different.
L
There
are
there's
been
suggestions
for
reasons
why
that
might
be,
because
blank
might
be
trying
to
chase
if
it
gets
negative
responses,
it
might
be
trying
to
chase
more
chase
up
other
authoritative
nameservers.
It
really
tries
very
hard
to
get
the
response
and
it
might
be
validating
more
signatures
because
of
that,
but
we
actually
didn't
investigate
in
detail
why
this
was
the
case.
L
L
Now
answer
the
original
paper.
We
did
some
additional
benchmarks
because
you
could
argue
that
we
did
our
benchmark
on
into
x86.
Some
of
the
optimizations
that
have
been
implemented
are
only
available
for
x86
architectures.
So
what
about
other
architectures?
What?
If
I,
have
a
home,
router
and
I
want
to
do?
Dns
accreditation
on
that?
How
is
it
going
to
cope?
L
Now
the
key
I'm
not
going
to
go
through
all
the
details
of
those
benchmarks,
but
the
the
key
takeaways
there
is
that
the
performance
is
low,
but
it
is
more
than
sufficient
for
home
scenarios
and
that,
interestingly,
ECDSA
may
sometimes
be
faster
than
EDSA,
because
there
are
already
some
optimized
versions
of
ECDSA
available
for,
for
instance,
arm
CPUs
that
outperform
the
stock
EDSA
implementations
that
are
available
for
that
we
did
an
N
equals
1
home
router
experiment.
So
this
is
take
with
heap
of
salt
right.
L
This
is
not
representative,
but
it's
an
interesting
experiment
to
run,
and
one
of
my
students
really
wanted
to
do
this,
and
and
I
mean
he
got
extra
bonus
points
for
the
fact
that
he
got
informed
consent
from
his
roommates
before
he
did.
The
experiment
right
so
and
I
didn't
even
have
to
enclose
that,
because
he
it
turned
out.
He
had
an
ethics
course
going
on
at
the
same
time
so
and.
L
There
are
two
takeaways
for
this
shows
you
24
others,
of
course,
to
the
resolver
that
they
run
in
their
student
dorm,
which
he
equipped
with
the
unbound
and
then
instrumented
and
they're
measured
and
the
there
are
two
takeaways
from
this
and
the
first
one
is
a
little
bit
serious
in
the
sense
that
with
them,
concurrent
user.
So
he
did
this
during
a
party.
L
So
there
were
lots
of
people
in
the
house
and
with
them
concurrent
users
to
query
loud
peaked
at
around
60
queries
per
second
from
clients.
Right
now.
He
also
measured
cache
performance
on
on
his
resolver,
and
the
cache
performance
was
atrocious
right
because
there
are
too
few
users
to
make
good
use
of
the
cache.
So
actually
only
about
10,
20
%
of
his
queries
could
be
received.
Responses
from
the
cache,
so
I
said.
Well,
let's
go
for
the
worst
case.
The
couch
doesn't
do
anything
and
the
resolver
has
to
validate
everything.
L
So
there's
maybe
some
work
there,
but
this
is
actually
only
if
we
have
a
hundred
percent
domestic
deployment
which
today
we
don't
have
so
I,
believe
we
can
safely
assume
that
by
the
time,
if
ever
we
reach
one
hundred
percent
the
NSTIC
deployment,
these
devices
will
be
fast
enough
and
there
will
be
optimized
implementations
of
elliptic
curve.
Algorithms
Oh
in
a
second
takeaway
from
this
is
that
stood
apart.
E's
are
not
what
they
used
to
be
because
it
observe
the
observant.
Viewer
will
see
that
the
party
stopped
at
1:00
a.m.
oh.
A
M
L
L
So
I
want
to
end
with
some
insight
into
adoption
right
because
I've
written
a
couple
of
papers
on
on
use
of
ECC
in
in
DNS
SEC,
but
until
2015
there
was
virtually
no
adoption
of
ECDSA
signing
schemes
that
are
standardized
in
RFC,
six
605
and
RFC.
Six
605
dates
back
to
2012
so
and
actually
the
first
implementation
in
environment.
Unbound
is
a
little
bit
older
than
that
right
because
about
the
records.
One
of
the
authors
of
the
RFC
is
also
one
of
the
developers
that
implements
Unbound.
L
So
in
late
2015
CloudFlare
actually
was
the
first
DNS
operator
to
adopt
ECDSA
signing
at
skill
right.
They
rolled
out
their
DNS
ik
as
a
service
thing,
and
they
said
we're
going
to
Oliver.
Guth
Monson
said
we're
going
to
be
signing
with
ECDSA,
so
we
want
to
know
how
is
it
option
developed
since
then?
L
These
graphs
refer
that
continental
org
and
what
they
show.
You
is
the
period
from
the
first
of
March
2015
until
somewhere
last
week
before
I
got
on
a
plane
and
what
you
can
see
against
the
legend
is
little
bit
hard
to
read,
but
I'm
gonna
be
pointing
out
some
things,
such
as
the
fact
that
the
majority
of
signed
domains,
income
net
and
org
still
use
RSA
sha-1
that
should
change.
Sha-1
is
not
considered
secure
anymore
for
signature,
algorithms.
L
This
is
the
point
in
time
where
CloudFlare
announces
its
Universal
DNS,
accusing
ECDSA
P,
2,
O,
5
6,
and
as
you
as
I
hope
you
can
see,
there
is
an
uptake
of
ECDSA.
That
starts
from
that
point
onward
right.
The
the
pink
area
at
the
at
the
top
of
the
graph
starts
growing
slowly,
but
actually
ECDSA.
Adoption
is
now
driven
completely
by
other
operators
that
are
adopting,
is
our
mas
and
and
so
of
I.
Think
the
beginning
of
this
month.
L
Ecdsa
is
the
second
signing
algorithm
after
RSA
sha-1,
please
people
change
that
replacing
our
say
sha-256
as
second
popular
signing
algorithm.
So
that's
actually
a
good
news.
This
is
getting
adopted
pretty
quickly
in
combat
and
org.
If
we
look
at
them
to
the
2t
of
these
that
have
the
largest
number
of
sign
domains,
which
is
Tata
now
under
2
C,
and
the
picture
is
a
little
bit
different
and
as
you
can
see,
that
adoption
of
ECDSA
Peter
5:6
is
still
quite
low.
L
It's
only
a
fraction
of
the
total
number
of
sign
domains,
but
one
takeaway
here
is
that
especially
the
C
is
doing
really
well
right,
no
RSA
sha-1.
It's
all
our
sha-256
so
kudos
that
it
actually
makes
way
more
sense
and
they're
actually
going
to
switch
to
signature
algorithm
for
their
TLD
to
our
sha-256
as
well
and
at
the
end
of
this
month
in
the
Danelle,
also
for
a
lesser
session.
One
then
in
common,
an
org,
but
also
only
a
little
bit
of
ECDSA.
L
L
If
we
look
at
the
Alexa
top
1
million
completely
different
graph.
Also
quite
interesting
here
you
can
see
again
that
there's
quite
a
bit
of
adoption
of
ACDs
AP,
2,
5,
6
22%
of
the
electorate
of
1
million
signed
domains
in
about
1.7
percent
of
them
are
signed,
use,
ECDSA
and
61
percent
of
those
use
cloud
fair.
So
there's
actually
also
quite
a
significant
number
that
are
not
using
cloud
thread
for
lists
are
using
another
operator.
That's
interesting
right.
So
I
get
to
my
conclusions.
L
L
So
my
recommendation
is
going
to
be
that
operator
should
switch
to
ECDSA
for
signing.
If
you
haven't
deployed
the
in
a
sec,
yet
don't
bother
deploying
RSA,
please
go
for
ECC
algorithms
straight
away
because
it
gives
you
all
of
the
benefits
of
ACC,
which
is
smaller
than
a
speck
eights,
which
means
no
fragmentation.
L
Finally,
resolver
operators
may
want
to
look
at
deploying
newer,
optimized
crypto
libraries
to
have
some
CPU
to
spare.
You
can
do
this
even
with
long
term
support
versions
of
the
software,
but
if
you
want
to
save
on
CPU
cycles,
you
might
want
to
deploy
newer
libraries
and
finally,
as
I
showed
you
in
the
last
couple
of
slides,
adoption
is
slowly
taking
off
and
with
that
I
get
to
the
end.
L
I
would
like
to
thank
my
students
who
who
helped
me
with
this,
so
it's
Kasper
Hagerman,
who
just
started
his
PhD
in
at
the
albergue
in
Denmark,
Bruce
and
JJ,
who
helped
with
the
ARMA
mips
benchmarks
and
the
data
for
the
adoption
was
supplied
by
the
open
Intel
project
have
a
look
at
the
URL
if
you're
interested
and
the
references
to
the
papers
as
I
said,
are
included
in
a
PDF
of
the
full
slide
deck.
Thank
you
for
your
time.
N
I'm
freedom
from
NIST,
so
we
we
have
been
working
on
PGP
sec
implementations,
which
also
uses
ECDSA
P
256
and
listed
together
with
a
SBIR
contract.
The
company's
name
is
a
antara
technique,
so
we
have
as
together,
we
have
developed
a
high-performance
implementation
of
PGP
SEC,
and
in
that
we
we
did
I
mean
it
was
mainly
our
SBIR
contractor
anchor
a
technique
and
his
name
is
mammoth
it
earlier
so
excellent
work.
You
should
look
at
that.
N
We
we
presented
that
paper
at
Nanak
69
in
February
this
year
it
will
say
BGP
SEC,
a
high-performance
PGP,
SEC
implementation,
but
it
has
a
lot
of
measurement
details
about
ECDSA
performance
and
we
use
DAC.
We
compared
it
with
the
OpenSSL
1.1
dot,
0
and
significant
I
mean
several.
Several
I
mean
significant
multiplication
factor
improvement
of
this
high-performance
implementation
compared
to
open,
SSL,
1.1
dot.
0,
so
I'll
be
happy
to
give
you
the
pointer
to
that
paper.
Ok,.
L
O
West
heard
Icarus
I
thinks
this
is
a
really
good
measurement
work
and
I
enjoyed
seeing
the
results
quite
a
bit.
You
know
the
this
sad
thing,
so
two
things
first
off.
The
sad
thing
is
that
you
know
you
are
providing
guidance
to
signers,
but
it's,
but
it's
really.
The
resolvers
don't
have
a
choice
right.
O
You
know
based
on
the
fact
that
they're
they're
still
significantly
slower-
and
that
actually
brings
me
to
my
next
point,
which
is
it
would
actually
be
interesting
to
look
at.
You
know
what
DNS
SEC
adoption
rate
might
combined
with.
You
know
the
CPU
increase
in
speed
and
and
have
this
early
warning
system
of
we're
headed
for
danger,
because
all
of
a
sudden,
the
resolvers
are
not
gonna
get
it.
You
know,
if
all
of
a
sudden,
some
major
you
know
GoDaddy
or
something
you
know
started
signing
everything.
L
Stop
judging
people
money
for
for
using
Venus
ik,
so
there's
actually
some
discussion
about
that
in
the
paper
and
in
the
paper
we
argue
that,
even
if
you
go
for
a
worst-case
scenario,
so
we're
we,
we
take
away
all
of
the
measurements
and
we
just
model.
We
assume
that
the
model
is
is
accurate
enough
to
put
in
worst
case
parameters
you
it's
arguable
whether
or
everybody
has
the
CPUs
that
can
deal
with
this
right,
but
that
that's
an
assumption
and
that's
an
assumption
that
we
cannot
not
prove
or
disprove.
L
But
even
if
you
put
in
worst
case
data,
then
with
the
way
the
DNS
currently
looks.
I
am
confident
enough
to
say
that
every
resolvers
would
be
able
to
handle
the
signature
validations.
However,
if
suddenly
the
new
gTLD
has
become
wildly
popular
and
we
see
a
fragmentation
in
the
namespace,
then
this
picture
might
change,
because
that
might
blow
up
the
number
of
cache
misses
which
might
blow
up
the
number
of
signature
validations
and
then
we
are
in
unknown
territory,
but
it
doesn't
seem
like
the
new
g2u.
L
These
are
that
wildly
popular,
so
I'm
not
too
worried
about
that.
Yet
but
there
are-
and
these
are
actually
discussed
in
the
paper,
so
there
are
some
situations
where
our
assertion
that
we
can
deal
with
these
signature
validations
where
they
might
not
hold-
and
this
is
one
of
those
situations,
the
other
one
which
is
also
discussed
in
the
paper-
is
about
what
did
it
do
not?
L
So
that's
also
in
the
paper
and
what
we
did
was
we
forced
resolvers
to
do
lots
of
ECDSA
signature
validations
by
making
them
verify
signatures
for
cloud
layers,
sort
of
black
life
thing
that
gives
you
a
fresh
signature
for
every
NX
domain
that
can
kill,
bind
easily
unbound
survives.
So
there
is
an
issue
there,
but
we
also
sketch
an
idea
of
how
you
could
solve
this
in
resolve
or
implementations
by
doing
some
form
of
rate
limiting
and
and
I
know.
L
P
P
G
P
L
That's
actually
interesting
because,
as
the
paper
states
there's
a
huge
difference
between
bind
and
unbound,
but
there
are
many
factors
that
play
a
role
in
that
right:
a
platonic
reserve
or
resolver.
What
would
you
need
to
specify
requirements?
What
that
does?
Does
that
give
you
does
that
work
the
hardest
to
get
you
an
answer?
Does
that
find
some
middle
ground
between
spending
time,
finding
something
and
then
deciding
it
can
be
found?
L
P
L
P
L
Q
Q
Q
L
So
we
actually,
we
actually
measured
the
legality
you
can
see
in
the
graph
here
we
measured
the
Galle,
more
free
factor
and
I'll
talk
you
through
what
you
see
in
the
in
the
graph
here.
So
what
we
did
was
we
measured
the
callee,
more
free
factor
in
micro,
more
freeze
for
queries
per
second
leading
to
ECC
validation.
L
So
we
you
see
the
initial
ramp
down
right,
which
is
what
you
would
expect
to
see,
typically
in
a
galley,
more
free
distribution
and
then
some
normal
noise.
But
then
there
is
this
weird
peak,
an
unexpected
rise
around
425
queries
per
second,
which
we
can't
explain
right
so
and-
and
that
has
puzzled
us
for
for
for
the
past
year
and
a
half.
And
if
you
know
what
causes
that
I
I
would
I
would
like
to.
L
Q
Q
H
Q
L
Q
A
Concerned
that
the
audience
is
wondering
if
they've
gone
out
of
their
minds
about
this,
so
we
should
explain
that
Willam
has
been
challenged
and
now
he's
taken
rolling
into
a
challenge
to
to
use
the
word
galimov
free
at
three
mic
lines,
and
this
is
a
very
successful
version
of
that
as
well
as
a
you
know,
a
deep
enlightenment
of
an
important
scientific
factor.
It's.
M
L
D
L
Let
me
see
if
the
pointer
on
this
works,
what
you're
referring
to
is
is
here
where
there
is
especially
not
org.
It's
very
steep.
This
is
very
actually
in
look
at
that
in
detail.
What
happened
there-
and
this
is
one
Operator
in
particular,
who
who
was
using
RSA
sha-256
before
and
they
decided
on
their
own
and
to
switch
to
ac/dc
ECDSA
p25
six
for
all
the
right
reasons,
because
they
wanted
to
reduce
their
packet
sizes.
They
wanted
to
increase
the
security
of
their
signature.
L
Algorithms
I
think
I
I'm
trying
to
struggle
onto
him
remember
the
name.
I
was
domain.
Names
show
up
it's
a
Norwegian
company
and
I
can
mention
their
name
because
I
had
some
email
communication
with
them
and
they
they
did
this.
It's
actually
not
been
flat,
it's
kind
of
hard
to
see
in
the
in
the
graphs
here.
L
If
you,
if
you
look
at
the
slice,
you
can
zoom
in
a
little,
so
there
is
still
some
adoption
and-
and
it's
still
increasing
slowly
but
the
the
large
peak
was
when
this
one
organization
decided
to
switch
and
then
later
on,
there's
a
smaller
bump
that
you
see
if
you
zoom
a
little
bit
into
the
in
on
the
graph
there's
another
small
bump,
which
is
another
algorithm
rollover
and
actually
I
brought
these
people
because
I
monitored
their
Okrand
rollover.
They
did
it
completely
correctly
right.
L
So
those
of
you
familiar
with
the
NSX
will
know
that
this
is
difficult
to
give
a
little
bit
of
idea
to
the
people
that
are
less
familiar.
An
algorithm
rollover
requires
you
to
take
those
specific
steps
which
is
to
introduce
new
signatures.
First
before
you
introduce
new
key,
because
the
NSA
actually
has
a
provision
that,
if
something
is
signed
with
a
certain
algorithm,
so
if
key
for
a
certain
algorithm
exists,
signatures
for
that
algorithm
must
also
exist,
because
otherwise
you'd
be
able
to
perform
downgrade
attacks
and
most
resolver
implementations.
Take
that
quite
strictly.
L
This
other
project
called
root
canary
which
we
presented
at
the
Mapuche
meeting
earlier
this
week,
and
this
the
suite
actually
came
to
us
and
said:
can
you
measure
our
algorithm
below
for
because
we're
kind
of
scared
that
something
might
go
wrong,
so
we're
actually
gonna
measure
that
and
see
how
that
works
in
practice.
So
we
get
a
much
more
detailed
measurement
and
we
have
for
this
particular
instance,
where
we
only
have
a
granularity
of
one
day
intervals.
L
D
H
A
A
A
All
up.
Do
we
have
certificates
to
present
to
oh,
we,
oh
sorry,
yes,
so
we
we
were
going
to
actually,
if
you
want
to
stay
and
work
in
here,
you
can
see
the
the
honor,
the
presentation
of
the
prize
certificates
and
the
photographing
of
same,
but
thanks
very
much
for
for
being
with
us.
We're
really
very
good
session.