►
From YouTube: IETF112-IRTFOPEN-20211109-1600
Description
IRTFOPEN meeting session at IETF112
2021/11/09 1600
https://datatracker.ietf.org/meeting/112/proceedings/
A
All
right,
so
I
make
it
a
couple
of
minutes
after
four
o'clock
and
I
see
that
all
of
award
winners
have
joined
and
the
number
of
people
still
joining
seems
to
be
slowing
down.
So
in
that
case
I
guess
we
should
get
started.
A
A
So
I
want
to
start
with
the
the
usual
note
well
and
reminder
of
the
intellectual
property
rules
for
the
irtf.
The
irtf
follows
the
the
same
sorts
of
intellectual
property
disclosure
rules
as
the
ietf.
A
You
know
if,
if
you're
aware
of
contributions,
if
you're
aware
of
patents
or
patent
applications
that
cover
the
contributions
that
you
make
that
are
controlled
by
you
or
your
sponsor,
you
do
need
to
disclose
that
or
not
participate
in
the
discussion.
A
Perhaps
a
difference
from
the
ietf
disclosure
rules
is
that
the
irtf
expects
you
to
to
file
these
disclosures
in
in
a
timely
manner
in
a
period
of
days
or
weeks
rather
than
months,
and
we
expect
the
the
most
liberal
licensing
terms
possible
are
made
available
for
irtf
stream
documents
and
if
you
need
more
details
about
this
process,
the
that
the
rfc
is
listed
on
the
slide.
Rfc
is
5743.
A
5378
8179
give
details
of
this
and
the
url
iot
irtf.org,
slash
policies,
slash.
Ipr
also
has
links
to
these
and
more
details
on
on
the
process.
A
Also,
as
should
perhaps
not
be
a
surprise,
the
irtf
makes
recordings
of
online
and
in-person
meetings,
and
this
includes
audio
video
and
photographs,
and
so
on.
This
session
is
being
streamed
live.
I
believe
we're
going
out
on
on
youtube,
as
well
as
being
the
the
meet
echo
session
and
as
well
as
being
recorded
and
the
recording
will
be
on
youtube
after
the
session
as
well.
A
If
you
participate
online,
if
you
turn
on
your
camera
and
microphone
and
make
sense
of
the
microphone,
then
you
are
consider
in
the
recordings,
and
I'd
also
remind
you
that
the
chat
logs
in
all
of
these
meet
echo
sessions
are
recorded
and
they're
available
on
the
ietf
site.
So
what
you
put
into
the
chat
is
also
recorded.
A
I'd
also
like
to
remind
you
that
we
we
have
a
code
of
conduct
in
the
irtf
and
in
the
ietf,
and
you
know
as
a
participant
as
an
attendee
at
the
the
irtf
sessions.
You
agree
to
work
respectfully
with
the
other
participants
in
the
session.
You
agree
to
to
behave
in
a
professional,
respectful
and
polite
manner,
and
you
know
we.
We
have
the
code
of
conduct.
A
If
you
have
any
concerns
about
behavior
of
the
various
participants,
the
the
ombuds
team,
again
linked
from
the
slide,
is
available
to
to
investigate
those
and
and
to
act
as
a
point
of
contact.
If
you
have
any
any
issues
with
the
the
participants
in
the
session,
if
you
provide
any
personal
data
and
in
order
to
register,
you
would
have
had
to
provide
at
least
a
little
bit
of
personal
data,
that's
handled
in
accordance
with
the
its
privacy
policy
and
again
that's
linked
from
the
slide.
A
Well,
the
irtf
is:
is
there
to
provide
a
forum
for
longer
term
research
issues,
while
the
the
the
parallel
organization
that
the
ietf
focuses
on
shorter
term
issues
relating
to
engineering
and
making
standards?
A
The
goal
of
the
iitf
is
very
much
to
conduct
research,
we're
not
a
standards,
development
organization
and
while
the
irtf
research
groups
can
publish
informational
or
experimental
documents
in
the
rfc
series,
the
primary
goal
of
the
research
groups
is
not
publishing.
Rfcs.
It's
not
publishing
documents.
A
A
The
irtf
is
arranged
as
a
set
of
research
groups.
We
have
five
research
groups
which
are
highlighted
in
dark
blue
on
this
slide,
which
are
still
to
meet
later.
This
week.
The
crypto
forum
research
group
develops
cryptographic
algorithms
and
looks
for
an
understanding
of
various
cryptographic,
algorithms
and
techniques.
Many
of
those
are
used
in
itf
standards.
A
A
The
pathway
networking
group
is
looking
at
the
the
interplay
between
the
endpoints
and
path
elements
and
how
that
communication
should
happen.
The
privacy
enhancements
and
assessments
group,
which
my
apologies
to
the
chairs.
I
noticed
this
was
listed
as
a
still
a
proposed
group,
rather
than
a
full
group
in
the
plenary.
A
Slides
is
looking
at
privacy,
enhancing
technologies
and
the
human
rights
protocol
considerations
group
is
is
looking
at
the
impact
of
standards
on
human
rights
and
the
way
we
can
reflect
various
principles
from
human
rights
in
into
the
the
types
of
protocols
we
we
develop
in
the
community.
A
We
also
have
a
number
of
groups
which
have
either
met
or
or
even
met,
already
or
not
meeting
at
this
session,
including
the
the
map
rg,
which
had
a
bunch
of
interesting
measurement
papers.
Looking
at
the
network
architecture
in
in
the
previous
session
and
the
network
management,
global
access
and
congestion
control
groups
which
met
yesterday.
A
The
research
groups
in
in
the
irtf
require
some
understanding
of
of
the
various
research
questions
and
problems
that
that
are
interesting
in
a
particular
area
and
are
looking
into
understanding
that
the
relevance
of
those
problems
and
questions
to
the
internet
they're
built
around
a
particular
community
which
is
trying
to
conduct
relevant
research,
and
that
has
been
interested
in
bringing
that
research
to
the
irtf
and
they're
built
on
an
understanding
that
there
is
a
benefit
for
conducting
that
work
in
the
irtf
both
for
that
community
that
brought
the
work
in
and
for
the
irtf
and
the
broader
internet
community.
A
A
We
have
had
one
rfc
published
on
the
irtf
stream
since
the
last
meeting,
which
is
rfc
9106
on
on
the
argon
2
memory,
hard
function
for
password
password
hashing,
which
came
out
of
the
crypto
forum
group.
But,
as
I
said
a
minute
ago,
that
the
main
focus
is
on
developing
understanding
and
in
you
know
the
vast
majority
of
the
research
groups.
I
think
research
papers
and
discussion
and
understanding
is
a
much
more
common
out
output
than
the
the
rfcs.
A
So
that's
what
I
wanted
to
say
about
the
irtf
there's.
A
couple
of
other
activities
been
happening,
which
I
I
want
to
to
mention
in
in
this
introductory
talk.
A
The
the
first
is
that
the
internet
architecture
board
has
a
program
running
to
develop
a
new
model
for
the
rfc
editor
function,
and
this
program
was
created
after
the
departure
of
the
previous
rfc
series.
Editor,
I
guess
a
year,
18
months
or
so
ago.
I
forget
the
exact
timing
in
it
back
in
the
times
when
we
all
used
to
meet
in
person
in
wonderland
hotel
rooms.
A
So
I
guess
it
was
a
while
ago
and
that
that
program
has
been
developing
a
new
model
for
how
the
rfc
editor
function
is,
is
organized
and
arranged
and
arranged.
A
The
model
they're
proposing
has
some
fairly
significant
changes
to
the
rfc
editor
function.
It's
proposing
to
to
change
the
rfc
editor
role
to
that
of
a
consulting
editor,
which
will
be
known
as
the
rs
series.
A
Consulting
editor
he'll
be
an
expert
that
will
provide
guidance
to
the
community,
to
the
rfc
publishing
streams
and
to
the
rfc
publication
center,
and
it's
proposing
to
shift
the
the
the
the
responsibility
for
oversight
of
of
the
evolution
of
the
rfc
series
from
the
internet
architecture
board
to
a
new
working
group,
which
will
be
known
as
as
the
rfc
fc
series
working
group,
which
will
be
a
a
working
group
which
is
independent
of
the
the
I
I
etf
and
the
irtf,
and
the
independent
stream
and
we'll
just
act
as
an
oversight
for
the
the
series.
A
And
once
that
group
reaches
consensus
on
proposed
changes
to
the
operation
of
the
rfc
series.
There'll
be
the
the.
The
proposals
will
then
be
reviewed
by
an
rfc
series.
Approval
board,
which
will
comprise
the
the
rfc
series,
consulting
editor
and
representatives
of
the
various
streams
which
are
likely
to
be
the
irtf
chair,
the
ietf
chair
and
the
iab
chair.
Although
they
can
delegate
that
if
they
need
to.
A
Now
this
may
seem
like
a
fairly
you
know,
a
bit
of
a
process
arcana,
but
it's
actually
a
fairly
significant
change
to
the
administration
of
the
rfc
series
going
forward
and
potentially
has
the
ability
to
impact
the
way
the
irtf
can
publish
documents,
since
if
the
way
the
the
rfc
series
changes
the
way
the
irtf
music
changes,
the
new
model,
the
the
description
of
this
process
is
described
in
an
internet
draft
that
the
iab
have
published,
that
this
program
have
published
draft
iab,
rfc,
ed,
future
rfc
ed
model.
A
If
I
got
the
the
draft
name
right,
that's
just
completed
last
call
in
the
iab
program
and
is
about
to
enter
it.
A
community
wide
last
call
for
comments,
so
I
I
would
encourage
you
as
participants
in
the
irtf
to
review
this
document
and
provide
feedback
to
the
rfc
editor
future
development
program.
A
They
have
a
meeting
tomorrow
in
the
1430
utc
slot.
They
also
have
a
mailing
list
by
which
you
can
provide
comments
and,
as
I
said,
please
do
review
this
document.
Please
do
send
feedback
on
whether
you
think
what's
being
proposed.
It
is
or
is
not
appropriate.
So,
as
you
see
fit,.
A
All
right
onto
perhaps
happier
happier
notes
than
the
arcana
of
the
itf
and
irtf
process.
The
next
thing
on
my
list.
Today's
is
to
congratulate
one
of
our
research
group
chairs.
B
A
C
So
somebody
has
echo
I
this
morning.
Actually
it's
a
it's
a
new
thing
this
morning
at
11
a.m.
Paris
time
weinstein
received
his
award
is
another
chevalier
of
the
audre
du
merit
of
scientific
signed
for
scientific
work
of
the
french
government,
and
while
the
award
was
given
to
him
for
this
contact
tracing
system
or
or
protocol
that
they
put
together
for
the
french
government,
it
was
actually
highly
mentioned
in
the
presentation
from
the
french
government
official.
C
That
veins
was
a
major
contributor
to
the
ietf
with
14
rfcs,
which
I
think
is
about.
I
think
there's
two
french
people
have
tons
of
rfcs
the
other
one
being
crystal
utema
of
the
iab,
and
so
that
was
actually
mentioned
as
a
major
contribution.
Also,
his
work
in
the
irtf,
which
I
am
very
much
aware
of,
but
what
was
mentioned
was
also,
I
think,
what
we
all
came
to
appreciate
of
him.
C
The
hard
work,
the
the
community
spirit,
the
fact
that
he's
always
open
to
new
ideas,
every
team
leader
very
committed
to
the
people
he
works
with
to
also
to
his
family
and
to
the
environment.
C
Like
it
was
highly
deserved,
and
I
think
we
always
forget
that
there
are
people
like
weinstein
who
are
not
like
the
most
vocal
and
who
are
a
little
bit
quiet,
but
in
the
end,
do
all
the
major
work-
and
I
felt
this
was
such
a
great
recognition
of
all
his
achievements
and
and
I'm
absolutely
proud
of,
having
been
his
co-chair.
Thank
you.
A
Yeah
think,
thank
you,
murray.
Congratulations
to
to
vancouver.
As
you
say,
this
is
an
incredibly
well
deserved
award.
Panson
has
been
involved
in
in
the
ietf
and
the
irtf
for
very
many
years
and
has
made
some
some
really
tremendous
and
really
important
contributions.
So
I
think
that
this
is
astoundingly
good
news.
A
All
right
continuing
the
good
news,
one
of
the
more
pleasurable
parts
of
being
the
irtf
chair
is,
is
that
we
get
toward
the
applied
networking
research
prizes
which
we
organize
in
in
conjunction
with
the
internet
society
and
with
support
by
by
comcast
and
nbc
university.
A
These
places
these
prizes
are
awarded
for
some
of
the
best
recent
results
in
applied
networking
for
some
interesting
new
research
ideas
which
may
potentially
be
relevant
to
the
internet
standards
community
to
the
internet
research
community
and
to
recognize
upcoming
people
that
are
likely
to
have
an
impact
on
internet
standards
and
technologies
in
the
future,
and
in
normal
times
we
would
bring
these
people
to
to
an
ietf
an
irtf
meeting,
and
I
would
be
introducing
them
into
you
in
person
and
we
we
could
chat
with
them
in
the
breaks
and
bring
them
to
the
to
the
related
sessions.
A
A
But
it's
my
pleasure
to
to
announce
that
the
the
winners
of
of
the
applied
networking
research
prizes
which
are
being
presented
at
this
ietf
meeting,
there's
this
irtf
open
meeting,
thomas
vertigon
for
his
work
on
extensibility
of
bgp,
implementations
and
other
routing
protocols.
A
A
So
congratulations
very
much
to
the
these
three
speakers.
We
will
see
the
the
talks
in
in
a
few
minutes
if
you
do
see,
see
these
people
around,
and
I
see
they're
they're
in
the
chat
here.
But
if
you
see
them
around
at
the
rest
of
the
itf
irtf
sessions
or
during
the
breaks,
please
do
talk
to
them.
Please
do
congratulate
them.
I
think
this
is
some
really
nice
work.
We've
got
here.
A
And
in
addition
to
that,
the
nominations
for
the
2022
applied
networking
research
prize
are
now
open.
The
the
deadline
for
these
nominations
is
the
19th
of
november,
so
you
have
10
days.
So
if
you
know
any
any
interesting
applied
networking
research,
if
you
know
any
good
papers
in
this
area,
if
you
know
any
any
people
who
you
think
will
make
interesting
contributions
to
the
community,
any
work
which
you
think
is
is
especially
valuable
and
isn't
getting
the
recognition
it
deserves.
A
Then
please
go
go
to
the
website
there
please
make
the
nominations
and
we
very
much
encourage
both
third-party
nominations.
Where,
with
someone's
permission,
you
nominate
someone
for
the
price,
but
also
self-nominations.
A
If,
if
we
you
know,
if
so,
if
you
think
your
work
is
deserving
of
the
price
and
isn't
getting
the
recognition
as
it
deserves,
then
please
do
nominate
yourself
and
if
you're
shy
about
that
reach
out
to
me-
and
I
will
happily
discuss
this-
and
you
know
highlight
whether
I
I
I
think
you
should
be
dominating
the
work
and
and
be
as
encouraging
as
I
can
to
to
get
as
much
work
in
as
we
can
and
for
the
community.
A
A
With
that
we'll
move
on
to
the
the
talks,
we
have
three
talks,
we're
running
a
little
late,
but
I
think
not
all
of
the
talks
use
their
their
full
time.
So
the
first
talk
is
by
toma
talking
about
xbgp
and
in
a
certain
amount
of
irony
that
the
talk
entitled
when
you
can't
wait
for
the
ietf
is
presented
in
the
last
of
the
three
award
talks
of
the
year.
So
I
guess,
there's
something
to
be
said.
A
The
last
of
the
three
irtf
meetings
where
the
award
talks
are
presented
in
the
year
access
talk
on
third
party
service
dependencies,
we'll
follow
that
in
about
30
minutes.
A
So
with
that
I'm
done,
we
will
move
on
to
the
first
of
the
pre-recorded
videos,
which
is
by
thomas
vertigon,
my
apologies,
if
I'm
mispronouncing,
my
name
thomas
received
his
master's
degree
in
computer
science
from
van
in
belgium
and
started
a
phd
looking
at
the
extensibility
of
routing
protocols
under
the
supervision
of
olivier
bonaventure,
he's
currently
working
on
techniques
to
improve
the
program
programmability
of
bgp,
which
led
to
the
prototype
xbgp
system
that
he'll
be
talking
about
in
this
talk
and
his
research
interests
include
distributed
routing
protocols,
programmable
networks
and
system.
A
Architectures
now
he'll
be
talking
about
the
paper
xbgp
when
you
can't
wait
for
the
itf
and
the
vendors
which
is
originally
presented
in
the
acm
hotnet
symposium
in
2020,
and
I
think
thomas
is
in
the
chat.
So
if
there
are
any
questions
for
clarification,
any
quick
questions
during
the
talk
we
can
ask
them
in
the
chat
and
then
he'll
be
available
to
answer.
Questions
live
after
the
talk,
so
thank
you
and
meet
echo.
If
we
can
play
the
first
of
the
videos.
D
You
can
see
the
standardization
delay
of
all
bdp
features,
so
we
measure
the
time
since
it
is
released
as
a
draft
to
the
moment
it
is
released
as
an
lfc.
This
is
not
an
isolated
case.
What
are
routing
protocols
suffer
from
the
same
delay,
but
the
least
I
have
shown
that
this
is
also
the
case
for
other
lfcs.
D
Next,
you
need
to
implement
your
feature
through
the
operating
system,
vendors
and
finally,
the
routers
must
be
updated.
But
if
you
are
a
small
network
such
as
bullet,
you
cannot
easily
influence
step
one
and
step
two,
because
you
are
you
don't
have
enough,
in
fact,
to
actually
convince
routers
vendors
and
the
itf
from
your
new
feature.
D
D
We
start
from
bgp,
which
is
considered
as
the
black
box.
You
can
configure
bgp
with
multiple
interface,
for
example,
cli,
netconf
or
snmp-
to
make
some
monitoring.
So
those
are
the
main
interfaces
to
configure,
but
you'll
not
have
any
way
to
modify
the
protocol.
You
as
being
a
network
operator
xbgp,
will
open,
delete
and
will
expose
the
protocol
in
the
protocol
memory
inside
the
protocol.
You
can
add
a
new
state,
you
can
modify
existing
states
and
also
you
can
modify
the
transition
between
two
states
concerning
the
protocol
memory.
You
can
access
through
the
routing
table.
D
D
Now,
actually
is
mgp.
Let's
add
it
on
the
top
of
operating
system
vendors.
Now
the
routers
can
be
seen
as
a
kernel
where
you
can
actually
run
some
extension,
which
is
the
modification
to
your
pdp
protocol.
Now
I
will
explain
you
how
enzyme
work
inside
bgp,
but
before
I
will
take
an
example
of
a
new
feature
which
is
not
standardized
by
the
itf
and
not
implemented
inside
any
operating
system.
So
what
we
would
like
is
to
add
the
geographical
localization
of
the
router.
D
If
you
would
like
to
add
this
new
feature
inside
the
mdb
protocol,
then
you
need
to
think
about
how
bgp
implementation
works.
Normally,
all
wdp
implementation
follows
the
rfc
4271
and
inside
the
rfc
4271.
It
explains
the
bdp
workflow.
First,
you
have
bgp
message
that
comes
from
your
heels.
It
will
pass
to
the
ajar
bin
then
inside
the
import
filter
when
it
was
the
import
filter.
D
It
goes
to
the
locality
all
the
acceptable
route
inside
the
long
calling
will
be
taken
to
the
bgp
process
to
take
only
one
baseboard
that
will
be
pushed
to
the
forwarding
table
of
the
routers
and
then
putting
inside
the
export
meter
to
take
whether
or
not
the
route
can
be
exported
to
other
networks,
and
if
it
is
the
case,
it
will
be
stored
in
the
rj
board.
And
finally,
the
message
will
be
generated.
D
If
I
take
back
my
geographical
localization
extension,
you
need
to
modify
multiple
steps
of
the
bdp
protocol
and
those
are
represented
by
the
blue
arrows
with
the
bdp.
It
is
possible
to
modify
the
protocol
thanks
to
the
introduction
of
insertion
point
insertion
points
are
a
way
to
execute
arbitrary
code,
and
so,
if
I
take
back
my
geographical
localization,
it
is
composed
of
multiple
subpart
and
also
part
will
be
added
to
the
right
insertion
point.
D
D
This
is
some
way
to
communicate
with
the
vdp
implementation
and
all
the
extension
code
or
plugin
must
use
this
api
to
retrieve
or
set
some
protocol
memory.
Why?
First
because
it
ensures
a
designation
of
the
plugin
and
the
gp
implementation,
and
second,
it
is
a
unified
way
to
access
to
the
memory.
Remember
that
xbgp
must
support
multiple
pdp
implementation
name.
Xvdp
api
contains
multiple
functions
such
as
function
to
send
and
read.
Bgp
messages,
also
the
function
to
get
or
set
some
memory
inside
the
protocol
memory,
for
example,
for
the
geographical
localization.
D
D
So
now
we
have
the
big
mixture
of
xbgp
and
I
will
show
you
some
new
skills
that
you
can
do
with
ldgp,
but
before
you
need
to
adapt
some
bdp
implementation
to
make
them
xbgp
compliant.
You
have
a
favoriting
and
board
in
our
case.
In
the
slide,
I
put
an
array
with
all
the
lines
of
code
that
you
need
to
modify
your
ad
to
make
the
bgp
implementation
xbgp
compatible.
D
The
first
use
case
is
a
simple
one.
This
is
the
monitoring,
and
what
we
would
like
to
do
is
to
monitor
the
length
of
the
ice
path.
Actually,
it
is
difficult
to
achieve
it
with
traditional
interface,
but
within
gpa
you
have
an
interface.
That
is
easier.
Why
would
you
like
to
monitor
the
is
pass?
For
example,
you
would
like
to
monitor
it
to
filter
out
large
aspars
or
make
analysis
afterwards.
D
So
now
I
will
explain
you
a
complete
example
of
c
code
that
represents
the
xbgp
expansion.
First,
you
need
to
retrieve
the
data
from
the
host
implementation.
This
is
known,
true
get
arc
function,
so
this
is
a
function
of
the
api.
Then
you
will
do
your
computation,
so
here
you
will
pass
the
response
attribute
and
count
the
number
of
autonomous
system
contained
inside
the
path,
and
then
you
will
use
another
function
to
actually
log
the
number
of
as
you
computed,
this
extension
code
will
be
added
to
the
import
filters.
D
The
second
use
case
is
related
to
the
use
of
bgp
inside
data
center
in
data
center.
You
use
bdp
to
make
your
internal
routing
all
the
best
practice
concerning
the
use
of
bgp
in
a
data
center
is
stated
in
lrc7938
inside
this
document.
There
is
a
constraint:
you
don't
have
any
exact
path
so,
for
example,
to
go
from
level
two
to
level
zero.
D
You
must
go
to
level
one
and
level
zero,
but
you
cannot
make
something
exactly
between
level
two
and
level
and
one
for
example,
and
to
avoid
this
zigzag
path,
you
must
have
the
same
autonomous
system
number
for
all
routers
of
the
same
level
over
here
level.
0
all
routers
have
the
as1
number,
but
these
constraints
make
a
debugging
difficult.
D
This
extension
will
also
be
put
on
the
insertion
point
related
to
the
import
filters.
The
third
use
case
is
related
to
the
road
selection.
So
in
this
slide
we
consider
a
stop
network
for
the
source
network
connected
to
several
transit
transit
1n102
and
to
reach
the
network
destination.
Bgp
must
advertise
a
route
to
the
source.
The
source
will
directly
receive
the
green
road
via
transit,
one
and
another
one
on
transit
2..
According
to
the
local
22
policy,
it
will
either
announce
the
blue
or
the
yellow
path.
D
Maybe
transit
2
choose
the
path
for
its
security
properties.
Nurses
prepare
the
path
with
a
longer
latencies,
and
so
the
ranking
of
the
source
and
the
transit
does
not
match.
Xbtp
can
solve
the
problem
to
execute
a
plugin
that
will
choose
the
route
on
the
edge
router
of
202
according
to
the
source,
ranking
network
and
so
transit
to
choose
the
root.
The
source
preference,
this
mass
election
service
will
be
added
to
the
decision
process
insertion
point.
D
D
Speed
is
no
longer
reachable,
so
the
rotors
will
send
a
result
to
the
neighbor,
but
for
whatever
reason,
due
to
a
software
bug
or
misconfiguration,
the
router
cannot
process
the
result,
and
so
it
fails
to
send
a
missile
to
the
other
label.
The
upstream
router
will
still
have
the
key
prefix
in
their
forwarding
table.
This
is
something
we
don't
want
because
it
may
lead
to
some
black
owning
or
traffic,
and
this
is
a
big
misogyny.
D
D
There
are
some
mechanisms,
such
as
transforming
staff
that
can
actually
reload
all
the
entire
routine
table
of
the
neighbor.
But
since
mgm
is
concerning
a
small
fraction
of
prefix
according
some
measurement
inside
the
internet,
it
is
not
really
necessary
to
renew
all
the
entire
routing
table.
So
we
designed
a
prototype
that
only
asked
for
those
means
that
we
detected.
D
Well,
we
need
to
have
an
automatic
way
to
verify
some
properties
before
injecting
it
to
the
routers.
With
with
vdp
we
make
the
following
approach.
First,
you
start
from
the
extension
source
code
that
will
annotate.
Then
it
will
be
passed
to
the
software
verification
tools
and
if
the
verification
tool
says
ok,
the
code
can
be
trusted.
It
will
be
compiled
to
the
bytecode
and
then
injected
to
the
protocol.
Now
I
will
explain
you
some
properties
that
we
define
that
all
the
plugin
most
satisfied
before
being
injected
to
the
routers.
D
The
first
one
is
the
termination
properties
we
do
not
want
that.
An
infinite
loop,
for
example,
breaks
the
protocol.
Another
properties
is
related
to
the
memory.
Isolation
of
the
plugin.
All
plugins
must
not
modify
memory
that
are
not
authorized
to
modify.
We
also
restrict
some
api
function
to
some
extension
code,
for
example
for
double
detailing.
They
do
not
have
the
right
to
modify
the
protocol.
Finally,
we
use
cr
a
lot
of
verification
tools
to
verify
properties
related
to
the
bdp
syntax.
D
D
We
write
all
the
properties
and
we
annotate
the
plugin,
and
then
this
annotated
plugin
will
be
passed
through
the
application
to
server.
That
will
say
yes
or
no,
and
if
it
say
yes,
then
we
are
the
guarantee
that
all
execution
of
the
plugin
will
satisfy
the
constraint
to
conclude
within
pdp,
you
can
make
hptp
implementation
totally
expensive.
D
D
A
Okay,
thank
you
really
interesting
talk,
thomas.
If
you're
there,
you
can
open
up
your
video
some
questions.
A
Hi,
okay,
can.
Can
you
all
hear
us
yeah?
Yes,
I
can
hear
okay
well
yeah,
as
I
say,
really
interesting
talk.
Do
we
have
any
questions
for
thomas
I
see
elliot
had
something
in
the
chat
elliot
jones.
Maybe
go
ahead.
E
Yeah
thanks
very
much
for
your
talk.
It
was
very
interesting
two
points.
The
first
is
a
question
in
terms
of
that
last
slide.
It
was.
It
was
your
desire
for
this
mechanism
to
always
have
the
transitive
bit
set
to
zero,
which
I
think
does
allow
for
a
certain
amount
of
prototyping,
for
instance,
right.
D
Yeah
yeah,
yes,
this
is
actually
xbtp
is
designed
for
quick
prototype
prototyping.
We
just
added
an
interface
to
allow
some
network
operators
to
implement
quickly
this
functionality
and
then
you
will
actually
test
in
another
network
and
finally,
it
will
be.
Maybe
if
it
is,
it
works
well
in
maybe
a
release
on
the
prediction
routing
network.
But
actually,
if
you
would
like
to
have
performance,
you
have
to
to
write
it
directly
inside
the
implementation
level
code.
D
So
yeah.
Maybe
when
you
introduce
new
code,
you
will
actually
break
some
some
rules
on
the
bgp
protocol,
but
we
designed
some
mechanism
to
guarantee
the
execution
of
the
plugin
locally,
but
the
execution
in
the
global
network
is
not
something
we've
done,
and
this
is
something
that
you
can
you
you
you
test
on
yourself.
D
So
you
you
make
some
tests
and
if
you
are
confident
about
that,
you
will
push
on
the
network,
so
there
is
no
really
way
to
test
the
global
safeties
of
the
the
implementation
you
you
put
on
the
on
the
router,
so
I
mean
this
is
something
we
can
actually
do
afterwards,
but
something
I
think
it
is
something
quite
complicated
to
to
verify
and
satisfy
the
security
property
of
the
global
network.
E
Yeah,
thank
you.
The
reason
I
ask
the
question,
obviously,
is
you
know
one
of
the
reasons
it
takes
three
and
a
half
years
to
go
through
the
standardization
process
is
because
I
think
people
are
cons.
E
Routing
is
a
is,
is
a
difficult
business
to
begin
with,
and
we
we
do
see
cases
where
routes
disappear
for
sometimes
inexplicable
reasons,
even
with
the
current
mature
mechanisms,
and
so
the
there's
a
certain
amount
of
proof
time,
and
so
one
question,
I
think
I
think
one
research
question
to
ask
is
just
how
flexible
should
a
routing
paradigm
be
and
what
what
are
the
guard
rails
that
make
it
safe
to
experiment.
D
Hi,
this
is
an
interesting
question,
because
when
xmgp,
you
can
do
what
you
pretty
much
we
can
do
well.
The
first
thing
is
that
you
have
to
choose
the
while
right
tool
to
actually
guarantee
the
security
property
of
the
underwater,
maybe
well
now
we
we
write
all
the
plugin
in
c
code.
This
is
not
something
which
is
really
secure,
but
you
know
in
another.
D
We
can
also
use
on
other
tools
some
some,
maybe
some
language
that
are
safer
like
rust
and
those
two
will
will
be
actually
provide
a
better
security
but
yeah.
You
know
we
don't
have
any
yes,
maybe
obviously
there
is
a
balance
between
us,
flexibility
and
and
security,
and,
if
you
add
flexibility
inside
the
routing
protocol,
then
the
security
part
will
be
less
less
mean
in
the
part
of
the
the
the
reasoning
of
the
thing
yeah.
A
Yeah,
thank
you.
Thank
you.
So
a
sort
of
I
had
a
follow-on
to
that.
To
some
extent
I
mean,
if
I
understand,
write
this.
This
adds
a
bunch
of
hooks
throughout
the
the
bgp
implementation,
where
you
can
insert
different
sets
of
functionality.
A
D
Oh
yeah,
actually,
what
you
have
to
do
to
put
xbgp
inside
an
implementation
is
to
first
follow
the
original
llc's
of
4271,
and
we
also
need
all
the
extension
above
multiprotocol.
D
For
example,
in
the
in
the
paper,
we
reproduce
the
root
reflector
functionalities,
and
this
is
one
of
some
some
some
new
skills
that
prove
that
we
can
actually
implement
a
lot
of
complexity,
but
the
strong
basis
of
hbgp
relies
on
the
the
original
draft
and
multi-protocol
extension.
The
other
thing
you
can
you
can
do
you
can
actually
put
your
code
inside
the
extension
code
and
then
put
it
in
the
the
implementation
which
is
six
php
compatible.
D
But
if,
for
example,
if
you
want
to
to
modify
some
data
structure
that
you
just
argued
inside
the
implementation,
you
cannot,
for
example,
if
you
take
the
the
functionality
that
enlarge
the
the
buffer
of
of
bgp
message
or
4k
to
a
74
kilobytes
of
memory
to
one
message:
that's.
This
is
one
example
of
a
feature
that
you
cannot
do
within
ubdp,
so
everything
related
to
to
the
memory
or
internet.
That's
data
structure,
which
is
when
you
put
it
inside
the
the
implementation.
A
Oh
okay,
that
makes
sense
that
makes
sense.
Does
anyone
else
have
questions
if
you
put
yourself
in
in
the
queue,
if
you
have
elliot,
are
you
still
in
the
queue
or
just
left
over
from
before.
A
Okay,
so
I
just
had
what
one
last
thing
I
mean
you
know.
A
Obviously
the
focus
of
the
the
thing
of
the
mechanism
is
extensibility
of
the
protocols,
and
you
know
you
you
make
the
point
of
when
you
can't
wait
for
the
ietf,
and
I
think
it's
well
known
that
that
the
itf
process
takes
time-
and
you
know
obviously
elliott
mentioned
some
of
the
the
reasons
for
that
a
minute
ago,
and
assuming
we
can't
make
the
itf
go
any
faster,
other
things
we
you
think
we
should
be
doing
differently
in
the
way
we
structure
the
protocols
that
will
help
this
sort
of
experimentation
once
the
rfc
has
been
published.
A
D
When
when
we
look
at
xbgb,
the
the
protocol
was
pretty
well
established,
so
if
the,
what
we
we
try
to
do
with
single
gp
is
to
understand
what
are
the
properties
of
the
the
protocol,
and
then
we
establish
a
set
of
properties
to
actually
actually
model
a
general
actually
architecture
of
of
the
routing
protocol.
And
then,
when
you
have
the
general
model
of
this
routing
protocol,
then
you
will
look
inside
your
implementation.
D
If
it
actually
implements
this
kind
of
general
model,
and
if
you
implement
this
general
model,
then
you
will
be
able
to
actually
put
xbgp
inside
the
protocol,
but
yeah.
If
the
the
implementation
is
only
exotic,
I
would
say
then
you
know
gp
will
be
more.
It
might
be
difficult
to
integrate
inside
the
implementation.
A
Yeah
that
that
that
that
makes
sense,
so
I
guess
the
the
general
conclusion
is
the
modularity
in
the
in
the
the
way
the
specifications
are
written,
might
make
this
process
easier
for
developing
modular
apis
and
extensions
yeah.
Okay.
So
that's
maybe
some
something
for
the
the
standard
groups
to
think
about
all
right-
and
this
is
where
over
time-
and
I
I
don't
see
anyone
else
in
in
the
queue
so
thank
you
very
much.
I
think
that's
really
interesting.
Some
really
nice
answers
to
the
questions.
A
If
there
are
any
any
more
questions
to
tomorrow,
please
please
put
them
in
the
chat
and
maybe
he'll
be
able
to
to
be
around
in
the
break
afterwards.
If
people
want
to
catch
up
with
him
in
in
the
cover
space,
perhaps
or
of
course,
drop
him
an
email
all
right.
So
thank
you,
thomas.
A
We'll
move
on
to
the
the
next
talk
of
the
the
session,
which
is
by
axa
kashaf
axa
is
a
phd
student
at
carnegie,
mellon
university,
she's
co-advised
by
eva
sekker,
and
you
you've
reached
a
gowell
and
I
apologize.
I
must
have
mangled
those
names.
A
Access
focuses
on
network
security,
particularly
distributed
denial
of
service
attacks
and
currently
she's
working
on
building
reconnaissance
techniques
to
to
profile
the
capabilities
of
ddos
defense
systems,
looking
at
understanding
and
improving
the
resilience
of
the
internet
against
ddos
attacks.
A
The
award
paper
today
is
analyzing
third
party
service
dependencies
in
modern
web
services.
What
have
we
learned
from
the
the
mirai
din
incident
and
it
was
originally
presented
at
the
acm
internet
measurement
conference
in
2020?
So
if
we
can
play
the
next
video,
please.
F
F
F
F
F
F
F
F
F
To
do
this,
we
look
at
the
lifecycle
of
a
web
request
when
a
user
makes
a
request
to
a
website.
It
first
goes
to
the
authoritative
dns
server,
which
provides
the
ip
resolution
of
the
website
after
the
ip
resolution
of
the
website.
User
starts
a
tcp
handshake,
followed
by
an
ssl
handshake.
If
the
website
supports
https,
if,
yes,
then
the
website
provides
a
certificate
which
is
verified
for
revocation
by
the
user
by
contacting
the
ocsp
server
or
crl
distribution
points
set
up
by
the
certifying
authority.
F
Finally,
if
the
certificate
is
valid,
the
user
requests
the
content
of
the
of
the
website
page.
If
the
website
is
using
a
cdn,
then
cdn
will
serve
this
content.
Based
on
this,
we
identify
three
services.
The
first
one
is
dns.
Second,
one
is
certificate
validation
by
certified
authority,
and
the
third
one
is
cdn
note
that
these
by
no
means
are
the
only
services
that
a
web
request
encounters,
but
we
just
identify
these
three
services
and
define
the
scope
of
our
work.
F
F
We
are
also
interested
in
critical
dependencies
which
exist
if
a
service
provider
is
integral
for
a
given
service,
for
example.
Here,
if
cloudflare
is
down,
ocsp
servers
of
let's
encrypt
will
not
be
accessible.
Hence,
let's
encrypt
has
a
critical
dependency
on
cloudflare
in
case
of
dns
in
cdn
we
compute
critical
dependency
by
measuring.
If
the
website
is
redundantly
provisioned,
which
means
that
the
website
is
using
multiple
dns
or
cdn
providers
and
in
case
of
certificate
authorities,
we
compute
it
by
measuring.
If
the
website
has
enabled
ocsp
stapling.
F
F
I
would
go
into
details
for
this
in
the
next
slide,
that
how
do
we
actually
identify
if
it's
a
private
or
a
third
party
and
finally,
for
a
website
and
its
name
server?
We
want
to
identify
which
of
these
name.
Servers
belong
to
the
same
entity,
for
instance,
here
azure,
dns
and
o365
filtering
both
belong
to
microsoft.
F
F
To
identify
third
party
name
servers
prior
work
looks
at
second
level
and
top
level
domains
of
the
name
server
and
the
website.
If
they
match,
then
the
name
server
is
private,
otherwise.
Third
party,
for
example,
here
in
case
of
google,
its
name
server,
also
has
the
same
second
and
top
level
domain
google.com.
F
F
F
F
To
cope
with
these
issues,
we
add
a
few
more
heuristics
so
for
all
website
and
name
server
pairs.
We
classify
the
name
server
as
private
if
the
second
level
domain
and
top
level
domain
match
for
the
website
and
the
name
server
or
if
the
name
server
is
present
in
the
subject.
Alternate
name
list
of
that
website.
F
F
In
general,
we
identify
approximately
10
000
third-party
dns
providers
in
our
data
for
measuring
cdns.
We
fetch
the
web
page
of
the
website
that
we
want
to
measure
the
cdn
of,
and
then
we
extract
all
the
resources
in
the
web
page
and
identify
the
resources
which
are
internal,
for
example,
for
reddit.com.
F
F
F
F
F
In
general,
we
identify
total
86
third
party
syrians.
In
our
data
for
certificate
authority
dependency,
we
just
fetch
the
certificate
of
a
website
and
from
that
extract,
the
links
for
the
ocsp
servers
and
the
crl
distribution
points,
and
we
use
the
same
techniques
which
are
tld,
mentioning
startup
authority,
non-matching
and
sandless
to
identify.
F
F
F
F
F
F
F
F
F
F
These
critical
dependencies
between
service
providers
give
rise
to
indirect
dependency,
but
why
should
we
care
about
indirect
dependencies?
I
mean
okay,
sure
they
exist,
but
what's
the
harm
turns
out
that,
as
a
result
of
indirect
dependencies,
we
see
huge
amplification
in
the
impact
of
a
given
provider,
for
example,
in
case
of
ca
to
dns
dependency,
cloudflare
now
critically
serves
37
of
the
top
100
000
websites
as
compared
to
24
before.
F
Hence,
because
of
these
in
indirect
dependencies,
we
see
amplification
of
provider.
Concentration
to
summarize
critical
dependencies
are
also
widespread
among
service
providers,
and
these
dependencies
can
amplify
the
concentration
of
service
providers,
which
means
that
the
effect
of
single
points
of
failures
in
the
internet
is
amplified
and
a
single
provider
can
now
impact
37
percent
of
the
top
100
000
websites.
F
This
is
what
we
observed
for
data
in
2020.
Now
we
see
how
the
world
changed
after
the
dying
incident
by
comparing
2016
dependency
data
with
2020
data,
which
brings
us
to
our
third
question,
which
is
how
did
the
world
change
after
the
time
incident
did
websites
try
to
reduce
their
third-party
dependency
on
service
providers?
Did
the
concentration
among
providers
decrease.
F
F
F
F
F
F
F
A
Okay,
thank
you
axa.
For
that
really
really
interesting
talk.
Please
do
come
on
up
all
right.
Can
you
all
hear
us.
A
Yes,
we
can.
Yes,
we
can
all
right
so
yeah,
as
I
say,
thank
you
for
the
really
interesting
talk.
We
had
a
bunch
of
really
good
questions
in
in
the
chat
already,
and
I
see
a
couple
of
people
in
in
the
queue
where's.
I
guess
your
first.
F
I'm
not
able
to
understand,
I
think
my
internet,
maybe
is
very
bad.
F
G
Okay,
great,
so
thanks
a
lot
for
the
work.
So
it's
you
know,
any
studies
we
get
on
centralization
and
dependencies
is
fantastic
because
it's
definitely
a
trend,
as
you
have
proved
in
your
numbers.
You
made
one
statement
that
said
so
in
your
recommendations,
you
said
that
you
recommend
the
companies
be
more
transparent.
G
Can
is
there
any
data
to
back
that
up
or
or
why
companies
should
be
more
transparent?
That
has
been
something
that
people
want,
but
it's
hard
to
prove
that
that's
actually
a
good
thing
for
them
to
do.
F
So,
actually,
I
have
a
multiple
sort
of
data
points
for
this,
for
instance,
currently,
let's
say
I'm
doing
research
in
the
redos
area
and
when
I
say
that
companies
should
be
more
transparent.
What
I
mean
is
that
they
should
be
transparent
about
what
attacks
they're
observing
so
that
we
can
sort
of
determine
the
skill
level
of
the
attackers
to
some
extent,
for
instance,
here
in
this,
in
this
attack
that
happened.
We
don't
really
know
for
for
the
dyna
tag.
F
We
don't
really
know
if
the
if
the
target
of
this
attack
was
particularly
dine
or
if
the
target
of
this
attack
was
some
other
website
and
all
other
websites
were
just
collateral
damage,
and
these
kind
of
questions
can
actually
help
in
making
informed
decisions,
because
if
many
websites
just
became
collateral
damage,
then
people
might
might
want
to
think
about.
F
Okay,
also
having
a
private
provider
rather
than
just
having
third
party
providers,
and
if
a
particular
provider
was
specifically
being
attached,
then
we
can
make
an
argument
that
okay,
maybe
we
should
be
redundantly
provisioned
and
not
in
just
this
attack,
but
there
are
many
other
attacks.
For
example,
currently
I'm
working
on
building
attackers
who
can
do
reconnaissance
on
on
different
service
providers
and
these
type
of
attacks
have
existed
for
so
long.
I
look
at
all
these
companies
aka
my
verizon
and
their
ddos
reports,
and
I
see
that
they
talk
about.
A
Okay,
thank
you
elliot.
I
guess
you're
next.
E
Thank
you
again,
colin
axo.
This
is
a
great
paper.
I
echo
what
what
wes
said.
It's
a
really
helpful
and
an
area
that
is,
I
think,
really
challenging.
You
know,
given
our
dependency
on
the
internet
today,
two
points.
First,
the
numbers
you
presented
in
terms
of
concentration
very
much
are
consistent
with
the
numbers
that
anna
maria
mandalari
at
the
imperial
college
showed
when
she
was
looking
at
iot
cloud
dependencies.
E
So
you
can
look
up
her
work
if
you'd
like,
I
think
she
presented
at
the
at
imc
as
well
at
some
point
about
this.
The
second
point
was
was
just
that
there's
an
activity
going
on
inside
the
ietf,
which
may
benefit
from
hearing
more
about
your
work,
which
is
benoit
clays,
presented
something
called
sane.
Please
don't
ask
me
to
expand
the
acronym
I
couldn't
possibly,
but
it
essentially
is
a
dependency.
E
It's
a
service
architecture.
It
looks
a
it
and
it's
based
on
a
dependency
graph
and
there's
a
lot
of
work
actually
going
on
in
the
ops
and
m
area
that
is
focusing
on
this
very
important
area
of
resiliency.
E
So
again,
congratulations
on
a
great
paper
and
I
look
forward
to
seeing
a
lot
more
interesting
stuff
from
you
and
your
colleagues.
Thank
you.
E
A
A
All
right,
other
than
that,
I
noticed
we're
running
shots
on
time.
We've
had
a
a
bunch
of
really
really
interesting
questions
there.
A
Please
do
read
reach
out
to
exo
if
you
have
more
more
questions,
and
so
as
as
everyone
said,
this
has
been
a
really
nice
piece
of
work
all
right
and
with
that
we
should
move
on
to
the
the
final
talk
today,
which
is
by
kevin
bock
kevin
is
a
phd
candidate
in
the
department
of
computer
science
at
the
university
of
maryland,
advised
by
dave
levin
and
his
work
focuses
on
enabling
open
communication,
improving
network
security
and
evading
censorship,
and
if
we
can
have
the
final
video,
please.
H
One:
hey
everyone:
my
name
is
kevin
bach
from
the
university
of
maryland.
Before
I
get
started,
I
wanted
to
give
a
huge
shout
out
to
all
the
ietf
organizers
for
making
this
event
possible
doing
all
this
remote
organization,
and
I
wanted
to
give
a
big
thank
you
to
all
the
collaborators
on
this
project.
It's
really
taken
a
village
to
get
this
going
now,
I'm
going
to
be
talking
about
censorship
today
and
specifically,
a
new
form
of
censorship
evasion.
We've
been
working
on
server
side
of
asia.
H
Before
I
get
into
that,
though,
I
wanted
to
give
you
all
a
brief
background
of
what
nation
state
censorship
looks
like
nowadays
to
motivate
some
of
the
approaches
we've
taken
now.
There
are
many
types
of
censorship
that
operate
around
the
world
today
and
today
I'm
going
to
be
talking
specifically
about
the
automated
in-network
censorship
that
operates
in
the
network
by
nation-states.
H
Now
some
nation-states
operate
censorship,
as
in-path
sensors
like
this
one,
with
the
sensor
physically
sitting
inside
the
network
path.
Other
sensors
operate
censorship
like
this,
instead
of
being
in
the
path
they're
on
the
path.
So
if
the
client
makes
a
forbidden
request,
you'd
see
this
request
moving
to
the
network.
Now
the
server
will
get
the
packet
and
the
sensor
will
too.
H
H
Specifically,
it
will
inject
spoofed,
tcp,
reset
or
tear
down
packets.
These
are
normal.
Packets.
Are
computers
sent
all
the
time
these
just
exist.
To
tell
the
other
side
stop
talking
to
me
immediately,
it's
going
to
send
one
of
these
packets
to
the
client,
pretending
to
be
the
server
and
one
of
these
packets
to
the
server
pretending
to
be
the
client.
H
Now
when
these
packets
arrive,
the
client
thinks
the
server
terminated
the
connection
and
the
server
thinks
the
client
terminated.
The
connection
immediately.
Both
of
these
sides
stop
talking
to
each
other
and
just
like
that
censorship
has
been
achieved
now
in
order
to
pull
off
this
attack
of
injecting
tear
down
packets.
The
sensor
needs
to
have
some
information
about
the
connection.
It
needs
to
know
the
port
numbers,
the
sequence
and
acknowledgment
numbers.
H
Now,
once
again,
our
client
is
about
to
generate
a
forbidden
request
to
this
resource,
but
this
time
we're
going
to
inject
a
tcp
reset
packet
of
our
own,
we're
going
to
set
it
in
such
a
way
that
the
ttl
or
time
to
live.
This
is
a
field
in
these
packets
that
tell
the
network
how
long
it
should
survive
in
the
network
and
it
decrements
once
per
hop.
H
We're
going
to
set
the
ttl
high
enough
such
that
we
reach
the
sensor,
but
not
so
high
that
we
reach
the
server
so
watch.
What
happens
when
we
send
this
packet
now,
just
like
before
the
sensor
will
get
a
copy
of
the
packet,
but
the
packet's
not
going
to
reach
the
server
it's
going
to
get
dropped
along
the
way.
H
Now
the
server
never
saw
this
packet,
but
the
sensor
has,
and
the
sensor
says
well,
it
looks
like
the
client
just
terminated
this
connection,
so
I
can
stop
tracking
the
connection
now
and
it
throws
away
the
state
it's
been
maintaining
about
the
connection
now
for
the
rest
of
this
flow,
the
client
and
server
are
free
to
communicate.
The
sensor
has
no
state
with
which
to
censor
us,
and
the
server
is
no
idea.
We
pulled
off
this
trick
now.
H
Now,
ideally,
servers
would
be
able
to
help
instead
of
deploying
software
at
the
client.
Instead,
we
would
deploy
it
at
the
server
and
if
such
a
thing
were
possible,
then
the
server
could
subvert
censorship
on
the
user's
behalf
without
clients
needing
to
deploy
anything
at
all
and
just
think
about
the
benefits
of
this.
This
would
immediately
broaden
reachability
and
accessibility
for
these
resources
without
clients
needing
to
do
anything.
Many
clients
connect
to
one
server.
Clients
no
longer
need
any
technical
expertise
or
to
download
anything.
H
Every
client
immediately
gets
plausible
deniability
and
it
helps
all
those
users
who
don't
have
technical
expertise
or
don't
know
they're
being
censored
in
the
first
place.
So
this
sounds
amazing.
The
problem
is
it
shouldn't
work
and
it
shouldn't
be
possible
and
to
see
where
this
is.
Let's
consider
the
waterfall
diagram
of
packets
that
are
exchanged
leading
up
to
some
censored
query
clients
going
to
send
a
sin
to
which
the
server
responds
with
the
synack.
H
The
client
completes
it
through
a
handshake
and
then
the
sensor
keyword
is
sent
from
the
server's
perspective,
though
there's
very
little
it
can
do
before
the
sensor
keyword
is
sent.
In
fact,
the
server
can't
influence
this
connection
past
the
synack
at
all,
underscoring
the
difficulty
in
this
space
there's
been
no
prior
work
on
evading
a
sensor,
evading
censorship
from
the
server.
H
H
Geneva
runs
strictly
one
side
of
the
connection
we
originally
designed
it
for
the
client
side
and
the
way
it
works
is
it
manipulates
packets
as
they
enter
and
leave
the
system
now
geneva
is
a
genetic
algorithm,
so
in
fact
it
learns
how
it
should
manipulate
packets,
specifically
the
way
it
can
manipulate
packets
is
it
can
do
that
with
just
four
actions.
That's
duplicate!
You
take
one
packet
of
two
packets
tamper,
you
take
a
pack
and
you
change
it
in
some
way,
fragment,
take
a
packet
and
break
it
in
half
or
drop
take
a
packet.
H
H
What
this
means
is
that
it
can
access
the
tcp
flags
fields,
it
can
change
the
flags
fields,
but
it
has
no
knowledge
that
if
I
set
the
flags
field
to
sim,
that
means
the
start
of
a
connection
so
syntax,
no
semantics
I'll,
also
call
that
fragment
here.
It
does
a
bit
of
double
duty:
the
ip
layer
does
fragmentation,
but
but
it
can
also
do
segmentation
of
the
tcp
layer.
H
Now
let
me
show
you
what
it
looks
like
when
geneva
puts
these
actions
together,
because
genita
actually
composes
these
things
into
trees
and
these
trees
look
something
like
this.
At
the
top.
We
have
some
sort
of
match
or
trigger
okay
and
then
associated
with
that
match.
We
have
an
actions,
these
are
match
action,
pairs
and
a
strategy
is
comprised
of
some
combination
of
these
match
action
pairs.
H
H
H
We're
going
to
generate
our
act
packet
which
matches
the
trigger
geneva,
pulls
it
into
the
tree,
duplicates
the
packet.
The
left
child
is
done,
the
right
child,
the
flags
are
changed
to
reset.
The
ttl
is
changed
to
two
and
then
in
order
to
traverse
the
leaves
and
we
send
the
packets
and,
if
you'll
notice,
this
tree
exactly
implements
the
censorship
evasion
strategy
that
I
opened.
H
H
H
H
So
this
is
one
successful
server-side
evasion
strategy
that
works
in
china.
Now
there's
a
lot
going
on
here.
So
let
me
break
this
down.
The
client
starts
off
just
like
normal
by
sending
a
sin
packet.
Okay,
now,
instead
of
the
server
responding
with
the
synack,
doesn't
respond
with
the
cynic
anymore.
Instead,
it
responds
with
two
syn
packets.
H
The
first
is
a
normal
synth
packet.
The
second
is
a
sim
packet
containing
a
payload.
Now
this
amazingly
is
legal.
The
first
syn
packet
serves
to
trigger
a
tcp
simultaneous
open.
This
is
an
archaic
feature
of
tcp,
that's
still
supported
by
every
major
platform,
and
this
was
originally
written
to
handle
the
case
of
what
happens
if
two
computers
send
a
syn
packet
to
each
other
at
the
exact
same
time
now,
when
the
client
receives
the
send
packet,
the
client
now
sends
a
synack,
and
it's
actually.
H
This
combination
of
the
client
sending
a
sin
back
the
client
sending
a
synac
immediately
preceded
by
a
syn
packet
containing
a
payload
that
causes
the
great
firewall
of
china
to
desynchronize
from
the
connection
and
for
the
rest
of
this
flow.
The
client
and
server
can
now
communicate
censorship
free
now
this
seems
crazy,
but
this
actually
works
with
varying
degrees
of
success
across
all
the
protocols
we
tested
and
for
context.
H
The
baseline
success
rate,
if
you
do
nothing
at
all,
for
evading
censorship
is
about
two
percent
now
this
is
one
successful
strategy,
but
it's
actually
just
one
of
many
altogether.
We
found
11
different
strategies
at
the
time.
We
did
this
work.
We
discovered
eight
in
china,
one
in
iran
and
india
and
another
three
in
kazakhstan.
H
H
H
Now
one
of
the
big
takeaways
from
this
is
that
it
really
has
helped
motivate
why
we
should
be
using
automated
techniques
to
discover
this.
This
is
likely
a
bug
in
this
sensor
that
it
may
have
been
difficult
for
a
human
to
discover
now.
Here's
another
example
that
I
wanted
to
show
you
also
in
kazakhstan.
H
Now
in
this
one
during
the
during
the
three-way
handshake.
Instead
of
the
server
sending
one
synack,
it
actually
sends
two
synax
and
it
includes
payloads
on
those
synax
specifically
the
payloads
it
includes.
Are
two
uncensored
get
requests,
get
requests
for
something
like
example.com
or
something
innocuous
and,
of
course
the
client
is
just
going
to
ignore
these
payloads.
H
H
Now,
at
this
point,
we've
seen
a
lot
of
different
types
of
bugs
and
sensors
not
handling
esoteric
features
in
tcp,
correctly
correctly
error
cases
or
just
confusing
the
logic
altogether
for
more
details.
For
any
of
these
I'll
refer
you
to
the
paper,
but
it
will
note
that
all
of
these
do
not
require
any
client
behavior
whatsoever.
H
They
may
induce
some
behavior
from
the
client,
but
no
software
changes
as
needed,
and
we
tested
this
across
a
wide
range
of
diverse
clients
and
in
fact
we
found
only
one
case
of
a
strategy
that
relied
on
platform
independent
behavior.
We
were
able
to
very
quickly
write
that
strategy
to
make
it
platform
agnostic,
and
all
of
these
really
teach
us
more
about
how
sensors
work.
H
H
So,
specifically,
the
way
this
works
is
let's
say
the
sensor
misses
a
packet.
The
idea
is
simple:
it
can
just
re-synchronize
its
state
on
a
later
packet.
In
the
connection
now
the
exact
dynamics
of
the
resynchronization
state
are
constantly
evolving
over
time
and
understanding
how
the
resynchronization
state
operates,
allows
us
to
build
better
censorship
evasion
tools,
so
looking
at
the
resynchronization
state
gives
us
some
more
insight
as
to
why
that
first
strategy,
I
showed
you
actually
works
so
once
again,
here's
that
strategy.
H
H
H
The
next
packet
that
it
resynchronizes
on
is
the
synack
packet
from
the
client,
but
because
we
force
the
tcp
simultaneous
open
when
you
do
a
tcp,
simultaneous
open.
The
mechanism
by
which
sequence
numbers
are
incremented
during
the
three-way
handshake
changes
and
the
grade
firewall
is
not
properly
incrementing,
its
initial
sequence
number,
while
it's
resynchronizing.
H
H
What
this
has
led
us
to
what
it
led
us
to
think
about
is
a
new
model
of
how
the
great
firewall
of
china
works,
because
in
the
past,
we've
kind
of
tacitly
assumed
that
the
great
firewall
works
with
this
kind
of
very
same
network
model
where
it
seemly
separates
application
layer
from
transport
layer
protocols.
H
It
looks
something
like
this,
but
what's
going
on
here,
is
that
we're
finding
different
tcp
layer
bugs
for
each
protocol,
which
means
that
each
protocol
censorship
must
have
its
own
tcp
stack,
and
this
strongly
suggests
that
the
great
firewall
is
actually
running
multiple
sensory
middle
boxes.
In
parallel,
it's
not
just
one
set
of
machines.
H
H
Now
you
may
look
at
this
be
like
well,
it's
obvious.
It's
just
got
to
be
using
the
port
number,
but
it's
actually
not
relying
on
port
number.
The
great
firewall
for
all
these
protocols
can
sensor
effectively
on
any
port.
If
you
try
and
make
an
http
request
for
some
forbidden
content
on
80
or
8000
or
a
random
port,
it
will
still
censor
you
the
same.
So
it's
not
using
port
number
we
think
is
going
on.
Is
that
how
does
it
know
which
middle
box
to
apply?
We
think
it
doesn't?
H
We
think
that
every
single
little
box
gets
a
copy
of
every
packet
independently
and
then
every
middle
box
applies
protocol,
fingerprinting,
every
middle
box
checks:
hey,
is
this
something
I
can
censor?
Is
this
belong
to
me?
Does
this
belong
to
me
and
then,
if
it
discovers
hey,
this
is
something
I
should
be
taking
action
against,
then
that
specific
middle
box
will
take
action.
H
This
raises
the
question:
where
are
these
guys
located?
Are
they
nearby?
Are
they
far
away?
So
we
did?
Was
we
used
ttl
limited
probes?
We
sent
forbidden
queries
with
different
for
different
protocols
with
different
ttl
limits,
and
we
tried
to
see:
are
these
located
in
the
same
spot
in
the
network
or
they
located
far
away?
H
What
we
find
is
that
largely
they're
co-located
at
the
network
level,
they
don't
seem
to
be
located
at
different
locations
now.
Next,
I
want
to
shift
gears
a
little
bit,
and
I
want
to
talk
about
where
we've
taken
these
ideas,
since
we
wrote
this
paper
now.
The
first
thing
I
want
to
talk
about
is
how
this
idea
of
service
activation,
and
this
idea
of
an
automated
approach
to
service
side
evasion
has
allowed
us
to
be
highly
responsive
to
new
forms
of
censorship.
H
The
way
this
works
was
that
it
monitored
all
protocols
entering
and
exiting
the
country
on
certain
ports,
and
it
only
allowed
certain
of
those
protocols
to
happen
it
performed
protocol
fingerprinting
across
all
of
these
and
protocols
that
didn't
match
were
then
subject
to
censorship,
which
means,
if
you
tried
to
use
a
protocol
they
didn't
approve
of
regardless.
If
what
you
were
doing
is
innocuous,
they
would
take
that
connection
down.
H
So,
within
a
small
amount
of
time
of
this
censorship
system
being
deployed,
we
threw
geneva
at
this
problem
and
we
were
able
to
discover
four
strategies
to
evade
this
filter
four
from
the
server
side.
So
this
means
that
as
soon
as
iran
rolled
this
out,
we
were
able
to
defeat
this
thing
and
help
roll
out
those
evasion.
Tactics
to
those
in
iran,
another
example
of
new
censorship
events
that
occurred
is
last
summer.
China
began
censoring
the
use
of
encrypted
sni.
H
Now
the
sni
field
is
revealed
in
tls
1.2,
where,
when
a
client
connects
to
a
server,
the
client
announces
in
plain
text
the
domain
it's
trying
to
get
to
sni
is
clearly
a
privacy
leak
and
the
tls
developers
are
working
on
fixing
that,
but
sni
is
how
sensors
have
been
censoring
https
for
quite
some
time
es,
and
I
people
have
been
looking
forward
to
as
a
mechanism
by
which
they
can
protect
themselves
from
smi
based
censorship.
And
unfortunately,
last
summer
china
decided
to
ban
the
use
of
esi
completely.
H
Now,
within
24
hours
of
china
rolling
out
this
system,
geneva
had
discovered
six
strategies
to
evade
it,
six
from
the
client
and
four
from
the
server.
This
is
very
exciting
and
it
really
allows
us
to
be
highly
responsive
and
dynamic
as
new
censorship
events
occur
now
the
other
exciting
direction
we've
been
able
to
explore.
Since
this
work
has
been
a
real
world
deployment
of
this
system.
H
We've
been
working
with
a
number
of
anti-censorship
groups
to
integrate
our
software
and
our
findings
into
their
systems
and
we're
starting
to
see
success
with
this
we've
been
using
geneva
to
help
really
in
two
regards
the
first
is
in
bootstrapping
initial
connections,
so,
let's
say
you're
something
like
a
vpn
and
you
really
want
to
help
users
get
connected
initially
and
the
weak.
The
weak
spot
in
a
lot
of
these
protocols
is
that
initial
connection
is
those
api
calls
that
initial
reaching
out
now
we
can
use?
H
H
It's
good
because
this
has
opened
up
the
ability
to
do
censorship,
evasion
to
more
people,
even
those
who
don't
know
they're
being
censored
now.
This
is
made
possible,
though,
by
the
ugly
fact
that
middle
boxes
have
bugs
and
bad
assumptions
that
can
be
exploited,
and
unfortunately,
this
can
also
lead
to
some
very
bad
directions.
H
Ultimately,
this
leads
us
to
conclude
that
to
really
make
sense
about
what
these
new
additions
to
the
internet
are
doing.
We
really
need
to
keep
investing
and
automated
tools
like
geneva
to
understand
what
new
things
these
middle
boxes
enable
and
how
they
change
the
landscape
of
the
network
and
networking
research.
H
A
All
right,
so,
thank
you,
kevin
really,
nice
talk.
Are
you
there.
A
Yes
hi,
so
I
see
tremendous
amounts
of
discussion
in
the
chats
already.
Are
there
any
questions
which
people
haven't
asked
already
in
the
chat
see
spencer,
maybe.
G
Well,
since
you
needed
questions
and
then
two
more
people
popped
up,
so
it
was
unclear
to
me-
and
maybe
I
missed
it,
how
did
you
determine
ground
truth
for
if
you
were
doing
server-side,
you
know
studies?
How
do
you
decide
whether
something
is
successful
or
not
and
actually
got
transferred
to
and
from
the
client
properly.
H
Can
you
hear
me,
let
me
know
if
my
audio
is
not
great.
So
in
our
case
we
have
the.
We
have
the
good
fortune
of
being
able
to
control
both
the
client
and
the
server.
So
we
did
our
experiments.
We
actually
had
vantage
points
located
in
all
of
these
censored
countries,
and
so
we
could
ground
truth
was
very
easy
to
determine.
We
could
try
and
obtain
some
forbidden
resource,
see
the
sensor,
take
action
and
then
try
and
do
that
again
with
the
server
side
strategy
running
and
see
it
succeed.
H
Now,
when
you're
talking
about
scaling
this
up
to
cases
in
which
you
don't
control
the
client
or
some
of
our
more
real-world
deployments
that
we've
been
working
on
recently,
it
starts
getting
a
little
trickier
when
you
start
needing
to
really
look
at
telemetry
and
look
very
carefully
at
what
the
if
the
packets
are
getting
exchanged.
If
the
connection
is
staying
alive,
that
sort
of
thing,
I
will
say
most
sensors
when
they
take
action
against
the
connection,
it's
fairly
obvious,
like
it
they're,
usually
not
quite
about
it.
H
So
generally,
the
server
can
determine
pretty
accurately
whether
a
sensor's
taken
action
against
something
or
not.
A
Okay,
thank
you.
Shiva.
B
Hey
kevin
thanks
for
the
talk.
Can
you
hear
me?
Okay,
I
just
so
I
I
think
he
might
have
touched
upon
this,
but
when
it
comes
to
deploying
this
at
scale,
were
you
I
think
you
mentioned
like
tunnelbear
someone?
You
were
working
with
british
wondering?
Were
you
thinking
about
the
coming
up
the
strategies
in
a
centralized
way
and
then
distributing
those
strategies
to
every
deploy
to
every
server
running
geneva,
or
were
you
thinking
that
every
individual
deployment
server
deployment
would
come
up
with
its
own
strategies?
B
H
For
initial
rollout,
the
the
methodology
has
been
will
be
kind
of
a
strategy
oracle
and
provide
strategies.
I
didn't
get
to
talk
about
it
too
much
of
the
talk
but
geneva's
broadly
broken
into
two
halves.
There's
the
component
that
runs
a
strategy
on
the
network
and
a
genetic
algorithm
that
discovers
the
strategies
and
those
are
fairly
self-contained.
H
So
for
now,
we've
been
we've
had
success
with
having
third
parties
deploy
the
strategy
engine,
the
thing
that
takes
the
strategy
and
runs
it
on
the
network
and
we've
been
more
strategy,
oracle,
providing
strategies.
That
being
said,
there
are
more
and
more
groups
who
are
working
to
find
strategies
themselves,
and
so,
as
that
becomes
more
decentralized,
that'll
things
will
just
continue
to
improve.
I
Yeah
and
thanks
a
lot
for
this
talk,
it
was
very
interesting
to
learn
what
the
senders
are
doing
there
and
I
probably
have
to
read
the
rest
of
the
paper
as
well
to
understand.
What's
happening
there.
We
talked
a
little
bit
in
the
chat
about
this.
Is
a
cat
and
mouse
game
right.
Can
you
just
tell
a
little
bit
about
like
how
long,
because
I
think
somebody
said
in
the
chat
that
some
of
these
bugs
have
been
fixed
so
like?
What's
the
timeline,
how
long
did
it
take?
H
Yes,
that's
a
really
good
question
and
that's
something
we're
still
studying
of
what
does
it
look
like
when
a
nation
state
rolls
out
a
bug
fix
like
how
long
does
that
take?
Where
does
that
go,
but
still
something
we're
studying,
and
I
I
don't
think
I
have
a
great
answer
for
you,
the
yeah.
I
think
I'll
put
a
tbd
stay
tuned
on
that.
It's
something!
That's
super
interesting
we're
going
to
keep
monitoring
and
we
do
test
these
things
fairly.
H
For
example,
a
country
like
china
may
have
may
have
many
instances
of
middle
boxes,
and
I
mean
perhaps
the
fix
get
rolled
out
somewhere
and
it
takes
time
to
traverse
or
there's
different
sets
of
middle
boxes,
doing
things
so
it.
It
really
takes
quite
a
concerted
effort
to
measure
these
things
at
scale
and
get
a
good
understanding
of
how
the
fixes
move
through
the
network.
If
you
will
so
a
big
tbd
on
that,
but
it
is
a
super
interesting
question.
I
A
All
right,
andrew,
I
think,
is
next
siobhan.
Are
you
supposed
to
still
be
in
the
queue.
J
Yeah
should
I
go
ahead:
yep
yeah,
hi
kevin
thanks,
very
interesting
presentation,
just
just
amplify
a
comment
I
made
in
the
chat
which
you
answered,
but
I
think
clearly
I
can
see
nation
states
have
the
resources
to
you
know,
respond
over
time
with
countermeasures
etc.
J
So
it's
an
arms
race
and
no
side
will
win.
I
think
by
definition,
possibly
china
might
because
they
got
more
resources
than
anybody
else.
But
notwithstanding
that,
my
concern
is
for
the
non-nation
states
affected
by
this.
So
if
you
like,
for
the
typical
end
user
versus
the
malicious
content
developer,
clearly
server-side
evasions
in
the
hands
of
malware
has
seriously
bad
implications
for
for
most
end
users.
J
So
if
you
like,
any
tool
can
be
used
for
good
and
bad.
I
think
this
tool
has
tremendously
negative
connotations
for
the
vast
majority
of
internet
users,
which
doesn't
negate
the
work,
but
I
think
that
needs
very,
very
careful
consideration.
H
Really
true,
I
mean
the
the
true
it's
a
true
statement
generally
that
anything
like
this
can
be
used
for
good
and
bad
and
malicious.
I
think
dave
said
it
best.
Malicious
is
in
the
eye
of
the
beholder,
so
we've
intentionally
not
taken
this
work
and
applied
it
towards
the
firewalls,
like
you're,
describing
like
this
really
has
been
a
very
concertedly,
focused
effort
on
nation
states
to
try
and
at
least
angle
things
towards
the
good
side,
as
as
we
can
help
direct
it.
I
think
it's
difficult
to
quantify
if
the
who's
affected,
the
majority.
H
Here
I
mean
there
are
billions
of
people
living
under
the
centered
regimes,
there's
also
billions
of
people
who
would
like
to
be
protected
by
firewalls.
So
it's
kind
of
a
tough
question
to
answer,
but
it
is
something
we've
been
thinking
about
and
it
was
a
serious
consideration
we
were
talking
about.
Should
we
release
this
tool?
Should
we
make
it
open
source
at
the
end
of
the
day,
we
we
thought
it
best
to
put
it
out
there
and.
J
I
guess
I
I
just.
I
would
observe
that
some
of
the
earliest
adopters
of,
for
example,
encrypted
dns,
were
malware
developers,
so
malicious
content
in
the
way
that,
in
a
definition,
that
most
of
us
would
recognize
as
malicious
but
yeah
anyway.
Food
for
thought
certainly
thank
you.
A
Yeah,
it's
it's
a
difficult
problem,
I
I'm
tempted
to
say
the
the
only
winning
move
is
not
to
play
just
following
on
a
little
bit
from
that.
Can
you
say
I
think
you've
touched
on
this
to
some
extent
already.
Can
you
say
something
about
how
you
did
the
tests
and
how
you
protected
the
the
users
who
are
running
the
tests
in
these
countries.
H
Are
we
good
okay,
we're
good?
In
these
cases
we
did
all
these
tests
ourselves,
so
there
were
no
end
users
directly
involved
and
the
no
end
users
were
harmed
in
the
making
of
this
paper.
If
you
will
and
no
end
users
were
we
tried
very
hard
to
not
put
any
end
users
at
risk.
H
I
was
from
machines
directly
at
our
control
and
that
we
monitored
all
that
very
carefully
going
forward,
as
these
things
are
deployed,
that's
a
whole
separate
question
and
that's
that's
something
that,
as
people
deploy
these
things
they'll
have
to
wrestle
with
those,
but
at
least
in
in
all
the
work
we
did
and
in
those
circumstances
there
were
no
users,
no
users
involved.
A
All
right
great,
thank
you
very
much.
We
are
basically
out
of
time
here.
I
think
we've
had
three
really
interesting
talks.
We've
had
a
bunch
of
really
interesting
discussion.
If
you
anyone
here
would
like
to
follow
up
with
the
the
rest
of
the
office,
you
know
please
do
reach
out
to
them.
I'm
sure
everyone
involved
will
be
happy
to
chat
more
the
you
know.
People
may
be
around
for
the
rest
of
the
meeting.
A
We
have
the
gather
space
if
people
want
to
chat
afterwards
as
well,
which
is
all
linked
from
the
agenda.
Yeah.
Really
nice
talks,
as
I
say,
please,
reach
reach
out
to
the
office
and
please
submit
your
nominations
for
the
price
for
2022.
The
deadline
is,
I
believe,
the
end
of
next
week.
A
So,
thank
you,
everybody
thank
you
again
and,
and
that's
all
we
have
so
thanks.
Everyone.