►
From YouTube: IETF110-PEARG-20210312-1430
Description
PEARG meeting session at IETF110
2021/03/12 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
You
might
have
already
seen
this
slide
at
this
point
in
the
week,
but
just
a
friendly
reminder
that
please
do
read
this
note
well
before
participating
today
and
oh
yeah,
and
also
reminder
about
if
anyone
wants
to
participate
in
the
queue,
please
press
the
raise
hand,
icon
and
yeah,
and
then
you
can
send
audio
separately
and
also
please
remember
that
perigee
is
a
part
of
irtf,
which
is
a
research
organization
and
not
a
standard
setting
organization.
A
A
They
passed
the
research
group
last
fall
last
year
and
the
rest
of
our
drafts
a
couple
of
them.
I
know
the
authors
are
working
on
updates
and
draft
censorship
is
actually
not
on
here.
A
Stan
adams
from
cdt
will
be
giving
enough
doing
a
quick
update
to
at
the
end
of
this
meeting,
and
we
did
have
an
interim
on
ip
address
privacy
in
january
that
chris
will
be
giving
an
overview
of,
but
we
do
have
brad
lassie
and
paul
jensen
talking
about
knackcatcher,
which
was
a
talk
that
was
presented
at
iphone's
privacy
in
term,
but
we
didn't
have
enough
time
for
that.
A
So
this
is
the
full
talk
and
we'll
have
some
discussion
time
to
talk
about
that
interim
and
what
teams
emerge
and
what
the
potential
work
is
around
that,
and
we
will
also
have
a
talk
by
zach
newman,
who
will
be
talking
about
their
work
on
using
overlay
routing
for
improving
performance
for
anonymous
communication
systems,
specifically
tar,
which
would
be
interesting
and
then
yeah
like.
Like
I
mentioned,
stan
adams
will
be
getting
an
update
on
the
censorship
techniques
draft
all
right,
and
we
can
also
try
out
this
countdown
timer
thing.
A
A
A
B
Cool,
so
my
name
is
paul
jensen.
I
work
on
chrome
on
the
privacy,
sandbox
team
and
I'm
here
to
talk
to
you
today
about
the
nat
catcher
proposal.
So
nat
catcher
is
a
bird
here's,
a
picture
of
an
app
catcher,
but
it's
also
the
name
of
this
proposal.
It
stands
for
global
network
address
translation
combined
with
audited
and
trusted
cdn
or
http
proxy
eliminating
re-identification.
B
So
in
terms
of
where
this
proposal
comes
from
comes
from
the
privacy
sandbox
team,
which
is
a
team
that
aims
to
eliminate
cross-site
identity,
linking
we're
working
towards
a
big
first
step
of
deprecating
third-party
cookies,
and
as
we
work
towards
that,
we
need
to
make
sure
that
we're
not
allowing
other
mechanisms
for
identity
linking
and
ip
address
is
a
pretty
big
one.
B
So
how
can
we
improve
ib
address
privacy
to
prevent
this
linking
so
we
can
give
each
person
many
addresses.
You
know
one
per
tab,
one
for
each
site.
You
go
to
kind
of
thing.
B
So,
let's
look
through
those
solutions,
so
the
first
solution
give
each
person
many
addresses
these
days
with
a
number
of
internet
users,
it's
only
possible
with
ipv6
right
now.
A
lot
of
people
are
using
slack
for
ipv6
to
get
their
address,
and
the
problem
is
that
a
lot
of
the
time
they
still
have
a
big
prefix,
that's
unique
to
them,
and
so,
even
if
they
have
multiple
addresses,
they'll
all
have
the
same
prefix
and
it's
not
really
providing
any
privacy.
B
We
could
start
giving
people
lots
of
random
addresses
with
different
prefixes,
but
the
hierarchical
hierarchical
nature
of
the
internet
kind
of
breaks
down
and
it
becomes
very
challenging
to
route
packets
at
scale
the
router
caches
kind
of
explode.
B
So
moving
on
to
the
two
remaining
solutions,
we
paired
them
up
into
a
hybrid
of
the
two.
So
in
the
give
many
people
one
address
front,
we
have
a
proposal
called
near
and
in
the
make
servers
not
use
ib
addresses
for
identity.
We
have
the
willful,
ib
blindness,
spec
and
so
nat
catcher
is
the
hybrid
of
these
two
puts
them
both
together.
B
So
I'll
walk
through
we'll
flag.
You
blindness
first.
B
So
wolf
ib
blindness.
The
idea
is
that
servers
on
the
internet
attest
to
not
using
ip
addresses
to
track
users,
and
then
they
volunteer
to
be
audited
to
verify
that
they're
telling
the
truth
and
to
verify
the
degree
to
which
they
use
ip
addresses
as
identifiers
and
once
they
complete
this
audit
they're,
then,
given
a
certificate
that
they
can
in
turn
take
and
show
to
a
browser,
and
then
the
browser
can
use
that
to
adjust
things
like
the
privacy
budget
to
control
how
much
access
to
other
identifying
information
they
have.
B
B
B
Things
like
that,
and
the
idea
is,
but
that
by
dividing
the
serving
stack
into
these
two
kind
of
pieces,
we
can
make
it
easier
to
audit
one
and
the
other,
because
if
we
know
the
ip
address
isn't
getting
to
the
back
end,
then
we
don't
really
need
to
audit
that
because
they
can't
use
it
for
joining
if
they
don't
have
it,
and
the
other
advantage
is
dividing
it
into
these.
Two
sort
of
halves
is
if
this
first
half
is
stuff,
that's
generally
done
by
a
cdn.
B
This
could
become
something
a
cdn
could
offer
to
the
application
back
ends
they're
hosting,
so
they
could
say.
Okay,
I've
been
audited.
I
know
I'm
conforming
205b
blindness
and
I'm
not
using
ib
addresses
for
re-identification
purposes.
So
we
now
know
that
the
services
they're
hosting
are
also
conforming.
B
Ib
addresses
are
also
used
for
server
selection,
so
a
lot
of
the
times
you'll
have
multiple
servers
and
they'll
be
hosting
different
content,
and
so
a
site
might
need
to
pick
the
server
that's
closest
to
the
user
for
the
best
latency
and
the
one
that
has
the
content
that
they're
looking
for.
B
B
So
in
the
interim
idf
perg
meeting
we
had
talking
about
ip
address
privacy.
There
were
a
number
of
presentations
about
anti-abuse
applications
of
ip,
and
so
it's
clear
there's
a
lot
of
a
lot
of
uses
there
that
are
really
important
to
the
success
of
the
web.
And
so
we
need
to
make
sure
that
the
willful
ib
blindness
policy
can
account
for
that
and
keep
those
those
important
functions
working.
B
So
there
are
cases
when
ip
addresses
are
used
for
anti-abuse
purposes,
a
little
deeper
into
application
back-ends.
But
the
idea
is,
you
could
kind
of,
hopefully
compartmentalize
and
separate,
separate
those
from
the
rest
of
the
application
back
in,
so
that
we
can
still
audit
that
and
say:
okay,
the
ib
address
is
not
leaking
back
in,
but
it
is
used
in
these
little
parts,
but
those
parts
are
only
outputting
like
abuse
signals
and
at
the
same
time,
as
this
all
can
be
audited.
B
The
hope
is
that
there's
other
privacy
preserving
alternatives
that
are
going
to
be
coming
online.
That
can
decrease
this
reliance
on
the
ip
address,
and
so
it
can
make
the
audits
easier,
if
say,
someone's
using,
like
a
trust
token,
to
convey
the
trust
rather
than
sort
of
associating
the
trust
with
an
ip
address,
and
so
over
time
the
audit
can
become
easier
as
these
technologies
evolve.
B
A
site
might
need
to
know
roughly
where
a
user
is
to
apply
region-specific
treatments,
so
things
like
gdpr
or
ccpa,
and
so
will
flybe
blindness
needs
to
allow
for
that
and
needs
to
audit
to
make
sure
that
only
course
geographic
location
is
used
and
is
only
used
for
applying
these
region.
Specific
treatments
that
are
necessary.
B
There
are
also
rare
cases
when
you
might
need
to
use
an
ip
address,
so,
for
example,
if
somebody
comes
to
you
and
says
you
know,
I'm
getting
really
bad
performance.
Here's
my
ip
address
and
you
sort
of
have
their
permission
to
look
in
the
logs
for
it.
So
you
might,
you
might
need
to
debug
like
one
particular
address
here.
Also,
if
there's
some
really
dangerous
abuse
going
on,
you
might
need
to
investigate
further.
B
So
in
these
cases
you
need
to
audit
to
make
sure
that,
when
this
is
done,
when
ip
addresses
are
used
for
these
specific
rare
events
that
there's
sort
of
a
break
class
access
is
required,
and
when
that
happens,
we
need
to
make
sure
it's
logged.
We
make
sure
that
log
is
audible
and
people
are
providing
motivation
and
the
most
important
thing
is.
We
need
to
make
sure
that
these
are
in
fact
rare
events
and
that
they're,
a
small
fraction
of
all
the
traffic
and
all
the
ip
addresses
that
are
coming
to
a
site.
B
So,
as
we
were
kind
of
thinking
about,
will
flappy
blindness,
you
know
we're
keeping
in
the
back
of
our
minds.
This
is
sort
of
feeding
back
into
the
privacy
budget
like
I
was
saying,
and
so
looking
at
the
sort
of
it's
identi
identification
based
on
ip
address.
If
there's
7
billion
people-
and
this
means
we
need
roughly
on
the
order
of
33
bits
to
uniquely
identify
everyone
and
a
quick
look
says-
the
ib
addresses
are
somewhere
in
the
neighborhood
of
27
bits
of
entropy.
There's
a
little
bit
of
instability.
B
There
depends
on
your
audience,
etc.
But
the
fact
is
that
27
bits
of
entropy
is
almost
all
of
this
33
bits
of
entropy.
So
it's
a
really
big
problem
and
you
know
willful
I'd
be
blindness
makes
sense
in
some
cases,
but
for
sites
that
aren't
woefully
I'd,
be
blind.
B
They're
still
gonna
have
almost
no
privacy
budget,
so
we
really
need
another
another
piece
to
this
puzzle
to
solve
it,
and
so
this
is
where
nat
catcher
comes
in,
so
that
catcher,
as
I
said,
is
the
hybrid
of
willful,
ib
blindness
and
the
near
path
nap
and
so
by
by
bringing
in
the
near
pathnat
proposal.
Nat
cancer
becomes
more
of
a
complete
solution
and
by
having
willful
ib
blindness,
we
still
allow
for
sites
that
need
to
do
perhaps
cross-site
anti-abuse
measures,
so
they
can
keep
working.
B
So
the
near
path,
nat,
so
the
near
path,
gnat.
The
idea
is
that
you
basically
run
an
at
at
the
edge
of
the
internet,
perhaps
at
the
cdn
level,
and
we
sort
of
call
each
of
these
nap
machines
or
each
machine
running
than
that.
B
An
ip
privatizing
server,
so
an
ipps,
and
so
these
ipps's
their
function
is
to
make
sure
so
they're,
basically
netting
the
traffic
coming
from
clients
and
they're
sharing
their
ip
address
amongst
thousands
of
browsers,
so
sites
can't
really
tell
which
of
the
browsers
it
is,
and
they
can
also
kind
of
change
the
ip
address
and
port
as
you
go
between
different
sites.
B
So
the
kind
of
rough
diagram
of
how
near
path
networks,
your
browser,
establishes
an
http
3
session
to
the
nat
and
inside
the
session.
You've
got
streams
for
your
tcp
and
your
udp
connections
and
then,
when
those
come
out,
the
other
side
of
the
nat
like
a
typical
nat
they're,
given
the
the
address
of
the
nat
rather
than
your
address,
and
you
can
see
in
this
example
when
you're
talking
to
two
different
servers.
The
address
that
you
present
to
them
is
different
and
then
of
course,
you're.
B
Not
the
only
person
talking
to
that
there's
thousands
of
others.
So
you
know
these
same
addresses
can't
be
associated
with
just
you,
because
other
people
are
using
them
as
well.
B
So
the
important
thing
for
the
near
path
now
is
performance,
and
so
it's
not
slowing
down
people's
browsing
experience
and
by
being
near
path.
You
know
on
the
edge
they're
they're,
not
really
adding
to
your
length
of
your
route
between.
You
know
your
browser
and
your
server,
but
basically
not
sending
data
all
the
way
off
to
a
data
center
somewhere
and
then
all
the
way
back
to
wherever
your
server
is.
B
So,
as
we
talked
about
with
will
fly
be
blindness.
There
are
cases
when
rough
geographic
location
is
important
for
region-specific
treatments
and
so
with
the
near
path
nat,
because
we're
at
the
edge
we're
pretty
near
to
those
clients,
and
so
the
idea
is
that
the
ip
addresses
from
the
those
ipps's
can
still
give
rough
geographic
information
to
apply
the
region
specific
treatments.
B
So
if
we,
if
we
take
this
mapping
from
you,
know
one
person
going
to
one
top
level
origin
and
and
then
we're
mapping
that
to
the
ip
address
or
port
tuple
that
we're
sending
to
that
server.
If
we
keep
that
mapping
constant
over
time,
then
it
allows
servers
to
do
some
of
the
same
anti-abuse
mechanisms
that
they
have
been
doing
in
the
past.
B
B
So
when
we
thought
about
how
we
can
implement
the
near
path,
nat,
we
looked
around
at
a
few
different
ways
of
technologies,
of
doing
that.
The
explainer
sort
of
compares
and
contrasts
a
few
of
them.
The
thing
that
really
seemed
like
pretty
much
a
perfect
match
to
the
needs
of
it
was
the
the
mask
protocol
that
the
itf
mask
working
group
is
working
on.
B
It's
basically
extending
http
3
with
proxying
capabilities
and
like
that
diagram
diagram
showed
before,
like
you,
have
an
hdb3
connection
into
ipps
and
in
there
there's
tcp
and
udp
streams,
and
so
it's
a
pretty
good
match.
It
also
leverages
a
lot
of
http
3's
strengths.
You
know
very
modern
protocol,
so
the
performance
is
good.
It's
got
pretty
good
encryption
and
you
know
a
big
thing
too.
Is
that
browsers
know
how
to
speak.
Http
3
and
a
lot
of
servers
do
as
well,
so
it's
already
deployed
to
some
degree.
B
So
I
think
that's
the
end
of
my
presentation.
A
C
Yeah,
I
I
had
a
question
of
clarification.
You
said
in
a
couple
of
the
slides
at
the
edge
and
I
may
have
missed
it,
but
that
means
many
different
things
to
many
different
people.
Could
could
you
talk
about
where
you
envisioned
this
being
implemented
and-
and
you
know
what
you
mean
by
the
edge
and
especially
who
runs
that
service.
B
So
this
is
kind
of
a
proposal,
so
I'm
not
sure
we
have
any
specific
answers
to
that.
You
know
at
the
cdn
level
is
one
kind
of
answer
and
in
terms
of
who
runs
it
I
don't
know.
If
there's
a
great
answer,
it
doesn't
have
to
be
one
person
necessarily
it
could
be
a
sort
of
a
service
that
multiple
people
are
offering.
D
In
general,
it's
the
realization
that
there
are
plenty
of
folks
who
have
you
know,
edge,
caches
or
cdns
or
whatnot
that
are
close
to
users,
and
those
folks
would
be
well
positioned
to
run
something
like
this
in
general.
C
Cool,
I
I
guess
from
a
cdn
perspective
that
would
be
you
know,
it
looks
pretty
straightforward
to
implement
and
it
looks
interesting
as
a
service
to
provide
customers,
but
it
seems
like
you'd,
need
a
mechanism
to
communicate
and
to
make
the
assertion
from
where
you're
performing
the
service
back
to
the
browser.
So
the
browser
can
change
its
behavior
and
that
creates
an
incentive
for
people
to
adopt
it.
And
then
you
get
a
virtuous
cycle.
So
that's,
I
guess
the
piece
that
I'm
I
don't
see
here
yet
that'd
be
really
interesting
to
talk
about.
A
Thanks
paul
thanks
fred
chris,
do
you
want
to
give
your
summary
of
the
interim.
E
E
Right
so
the
the
interim
that
we
had,
I
forget
what
it
was.
Actually
the
the
entire
focus
was
on
ip
privacy.
I'm
trying
to
look
at
it
from
the
perspective
of
clients
and
servers.
E
We
made
sure
we
had
discussion
in
terms
of
like
how
ip
addresses
are
currently
used
for
on
on
the
server
side,
for
various
anti-fraud
and
abuse
cases,
and
for
denial,
service
prevention
and
mitigation
mechanisms
and
there's
a
lot
of
lively
conversation
that
that
came
out
of
that
they're
also
were
two
great
presentations
on
sort
of
the
overview
of
the
privacy
aspects
of
ip
addresses,
both
from
the
perspective
of
the
client,
as
well
as
from
the
server
and
then
various
sort
of
forward-looking
proposals
about
how
to
potentially
deal
with
this.
E
E
So
during
the
the
course
of
the
presentation,
a
number
of
key
questions
came
about,
perhaps
the
most
important
one.
In
my
view,
perhaps
the
most
important
one
was
that,
if
you
imagine
a
world
in
which
ip
addresses
were
removed
from
servers,
be
it
by
a
mac,
catcher
or
something
else.
What
are
the?
E
What
are
the
requirements
for
a
signal
that
could
be
suitable
as
a
replacement
that
would
work
for
these
anti-abuse
cases,
anti-fraud
cases
in
general
service
protection
cases,
and
there
was
some
discussion
during
the
meeting
and
then
some
follow-up
chatter
on
the
mailing
list,
or
there
was
a
message
on
the
mailing
list
that
matthew
finkel
kicked
off
and
it
seems
like
there's
still
some
more
work
to
be
done
and
figuring
out.
E
What
exactly
are
the
requirements
here
both
from
sort
of
the
client
perspective,
in
terms
of
what
are
the
privacy
properties
that
they
want
of
the
signal,
as
well
as
from
the
server's
perspective,
in
terms
of
what
are
the
you
know,
the
authenticity
properties
of
this
particular
signal?
Can
it
be
spoofed
easily?
E
What's
the
granularity
of
the
signal
and
so
on?
Something
also
interesting
came
up,
was
sort
of
the
need
for
analyzing
the
the
cost
benefit
of
using
ip
addresses
in
the
way
that
they're
used
right
now
so
clearly,
folks
have
concerns
in
terms
of
how
people
use
or
misuse
ip
addresses
for
from
a
privacy
perspective,
and
but
using
them
in
this
particular
way,
may
make
it
cheaper,
easier,
etc.
To
do
certain
things
on
the
server
side.
E
So,
looking
at
exactly
how
much
how
how
the
costs
shift
for
various
parties
involved
as
you
either,
you
know
take
away
ip
addresses
or
replace
them
with
something.
It
certainly
would
be
quite
useful.
E
Another
interesting
point
that
came
up
was
sort
of
the
differences
between
v4
and
v6
addresses
and
how
they
affect
the
signal.
Entropy
fernando
had
some
good
comments
on
that,
and
then
thinking
specifically
about
this
signal,
the
question
was
raised
whether
or
not
sort
of
an
unspoofful
like
signal
remote
attestation
that
the
device
is
trusted
like
that
the
client
devices
trusted
from
which
the
connection
is
coming
would
be
sufficient.
E
There
were
also
mentions
and
references
to
sort
of
anonymous
credentials.
There's
a
more
general
mechanism
here
and
folks
perhaps
are
aware
that
there's
work
are
going
in
the
privacy
pass
space,
which
is
a
particular
type
of
anonymous
credential.
Maybe
there
are
applications
there.
I
think
what
would
be
quite
useful
is
to,
I
think,
have
more
discussion
around
the
first
point
here.
E
We
really
need
to
sort
of
get
clarity
in
terms
of
what
the
requirements
are
from
all
parties
involved
and
that
would
allow
us
to
kind
of
set
embark
upon
finding
a
suitable
replacement.
So
that's
effectively
the
high
level
summary
and
how
many?
How
much
time
do
we
have
for
sort
of
discussion?
Shabbat.
E
Okay,
so
as
next
steps,
I
think
it'd
be
good
to,
like
I
said
document
the
these
requirements.
You
know
pull
people
into
the
conversation
that
represent
both
the
clients
and
the
servers,
because
sometimes
these
you
know
these
use.
E
These
requirements
are
at
odds,
but
I'm
sure
we
can
come
to
consensus
here
and
once
we
have
sort
of
an
understanding
in
terms
of
what
what
is
actually
necessary
for
this
particular
signal,
then
maybe
look
at
how
existing
technologies
that
are
being
standardized
either
help
or
don't
help
like
what
is
the
gap
between
what
we
have
available
to
us
and
what
needs
to
be
done
in
order
to
build
it
in
doing
so,
it
might
be
worth
also
considering
sort
of
the
larger
impact
on
this
sort
of
shift
on
the
the
just
the
ecosystem
in
general,
like
if
you're
going
to
do
something
similar
to
that
catcher.
E
How
do
how
do
clients
actually
pick
proxies?
How
are
they
audited?
How
are
they
trusted
and
what
are
other?
You
know,
aspects
of
centralization
that
we'd
be
concerned
about,
and
perhaps
also
logistically
speaking,
we
should
decide.
You
know
where
this
work
should
take
place,
be
it
in
perigee
or
elsewhere.
I
have
no
strong
opinions
there.
I
think
it's
useful
work,
so
it
could
probably
happen
anywhere
so
with
that
I'd
like
to
just
open
the
floor
to
discussion.
E
D
Yeah,
I
just
wanted
to
jump
in
and
say
you
know
we
have
a
pretty
strong
interest
in
pursuing
various
some
form
of
ip
privacy.
One
of
the
big
challenges
is
doing
that
and
still
preserving
anti-abuse
and
anti-fraud
protection,
so
that
websites
can
reasonably
defend
themselves
against
attack
so
having
a
a
forum
where
we
can
discuss
the
the
needs
there
and
how
various
applications
could
affect
those
those
needs
would
be
great.
So
I'm
very
supportive
of
this.
E
Cool
stephen.
F
Yeah
just
asked
to
kind
of
venue
and
kind
of
scope.
I
I
think
prg
is
probably
a
good
venue
and
because
it
would
allow
or
easily
more
easily
allow
in
including
within
scope,
for
example,
the
fact
that
you
know
some
particular
brands
of
mobile
operating
system
might
be
returning
an
emcee
to
an
operator
or
a
service
provider,
as
well
as
an
ip
address.
F
E
What
do
you
mean
by
ip
address?
Only
mechanisms
just
that
it
would.
It
would
hyper
focus
on
that
as
the
specific
vector
or.
E
Gotcha
yeah,
I
think
that
that
makes
sense.
Certainly
we
don't
want
to
overly
constrain
ourselves
so
that
we
don't
actually
solve
the
problem
of
privacy
from
a
client's
perspective,
so
yeah.
I
totally
agree
with
that.
Matthew.
G
Yeah,
I
just
want
to
say
that
I
think
any
work
in
this
area
probably
probably
won't
result
in
a
single
drop-in
replacement
for
ip
addresses,
and
we
might
need
to
look
at
different
solutions
for
different
signals
and
basically
providing
client-side
information
to
servers.
If
it's
not
directly
available.
E
Yeah
that
that's
compelling,
I
mean
the
there's
a
lot
of
different
signals
that
we
extract
from
ib
addresses,
or
I
that
I
gather
from
the
interim
geolocation
identity,
and
it
might
be
the
case
that
addressing
each
of
these
signals,
each
of
these
use
cases
requires
like
a
different
mechanism
yeah.
So.
G
H
Yeah,
I
just
wanted
to
drop
in
the
thought
that
I
think
it'd
be
useful
to
include
network
operators
in
the
discussion,
be
they
so
enterprise
networks,
or
indeed
public
networks,
just
to
make
sure
that
stuff
isn't
broken
inadvertently
it
or
makes
it
hard
for
the
operators
to
discharge
their
responsibilities
about
efficient
network
management,
including
spotting
things
like
you
know,
network
abuse,
applications
and
so
on.
So
I
just
wanted
to
make
the
point.
Hopefully
that
isn't
overlooked.
E
In
some
cases,
these
two
are
always
at
odds,
and
that's
specifically
why
we
want
to
have
the
people
who
are
using
ip
addresses
for
in
the
ways
that
they're
using
them
right
now
in
the
conversation,
so
that
we
can,
you
know,
as
a
group
come
together
and
figure
out,
what's
a
good
or
suitable
set
of
replacements
if
needed,
yeah.
I.
E
There's
going
to
be
a
conflict,
that's
unavoidable.
I
guess.
H
E
F
Yeah
sorry,
I
I
forgot
to
ask
for
something.
So
one
issue
with
ip
addresses
is
how
they're
used
in
trace
headers
in
mail
and
again
there
are
similar
anti-abuse
mechanisms
that
make
use
of
those.
Is
that
an
area
I
mean
that
you
know
is
that
something
that
should
be
in
scope
or
are
there
people
interested
in
this,
or
are
we
really
just
thinking
about
the
web?.
E
That
is
a
a
good
question.
I
don't
know
I'd
be
curious
to
hear
what
other
people
think
right.
Certainly,
the
web
is
a
motivating
use
case
in
this
particular
context,
but
it
may
be
wrong
to.
I
guess-
constrain
ourselves
to
that
particular
case
to
start
so,
if
others
have
opinions
in
terms
of
like
what
the
scope
should
be
love
to
hear
it.
F
Yeah,
so
I
think
they're,
some
of
the
anti-abuse
mechanisms
may
be
a
little
bit
different
in
male,
but
I'd
have
to
think
about
it
more
and
talk
to
other
people
really.
So,
for
example,
I
think
in
in
male
that
you
know
some
people
may
treat
messages
more
likely
to
be
spam
if,
depending
on
the
set
of
ip
addresses
in
in
trace
headers
and
that's
a
little
bit
different
from
the
web
anti-abuse
patterns,
maybe
so
there
might
be
something
to
learn
by
cons
by
broadening
the
scope
to
include
mail
as
well.
E
That's
a
good
point:
do
you
know
if
the
people
in
that
space
are
like
in
in
perigee
or
they're
aware
of
this
work
and
if
not
like,
would
you
be
able
to
sort
of
help
us
bridge
the
gap.
F
Yeah
yeah,
so
there's
an
organization
called
mog
which
is
kind
of
deals
with
that
kind
of
stuff,
and
I'm
there's
overlap
between
itf
and
mog,
which
is
sufficient.
I
think,
but
I
can
help.
Certainly
if,
if
need
be,
the
one
thing
I
would
say
is
that
I,
I
think
the
male
anti-abuse
people
are
even
more
allergic
to
changing
things
in
in
terms
of
ip
address
handling
than
the
web
anti-views
people.
E
That's
surprising
but
yeah
good
to
know.
I
Chris,
I
was
just
gonna
mention
one
thing
proposal
that
I
think
I
remember
from
the
interim,
which
is
that
I
think
christian
hoytmar
said
how
what
we
could
start
with
is
an
analysis
of
all
the
use
cases
with
some
assessment
and
categorization
in
terms
of
who's
being
who's,
the
primary
protectee
of
the
action,
the
anti-abuse
action
that's
being
made
and
then
categorize
them
and
then
in
that
way,
what
might
fall
out
is
groupings
for
different
signals
with
different
nature.
I
E
That
that's
what
I
mean
by
the
requirements,
I'm
sort
of
assuming
that
sort
of
that
work.
Folds
into
this.
We
need
to
understand
all
these
cases
in
order
to
understand
like
the
requirements
for
what
those
solutions
would
be.
Definitely,
I
think
it's
premature
at
this
point
to
try
to
start
speculating
what
would
be
a
suitable
replacement
without
fully
understanding
the
problem.
E
J
Yeah
wondering
if
just
just
to
see
if
I
can
get
your
opinion
yesterday,
madina's
was
meeting
and
they
are
very
interested
in
the
use
cases
that
are
broken
with
the
mac
address
randomization.
J
So
I
was
just
wondering
what
you
guys
think
might
be
like
the
type
of
response
for
these
ip
use.
Cases
that
you
guys
have
in
mind
right
now.
Did
that
make
sense
julian.
A
Yeah,
which.
J
They
met
at
the
last
ietf
saying
that
it
was
a
non-war
group,
conforming
buff,
but
right
now,
they're
already
working
on
drafts
and
everything
basically
to
circumvent
they
are.
They
are
first
gathering
different
use
cases
that
need
macadrice,
randomization,
circumvention
right
and
they're,
also
like
gathering
different
solutions
that
are
available
for
that.
Currently.
D
This
goes
to
steven's
first
point
of
whether
the
scope
is
is
just
ip
address,
or
it
covers
mac
pulses
and
imei
numbers
and
and
whatnot
other
network
identifiers
are
associated
with
the.
A
Yeah,
I
think,
that's
I
think,
that's
in
scope
generally,
I
think
yeah
we
are
trashing
out
what
the
scope
is
formally
for
the
requirements
document.
A
K
All
right
so
yeah
thanks
for
having
me
everyone.
My
name
is
zach
newman.
I
am
here
to
talk
today
about
routing
for
anonymous
communication,
and
this
is
early
stage.
Research
work.
It's
joined
with
a
couple
of
colleagues
kyle
hogan
who's
here
today,
sasha
serving
schreiber
we're
all
at
mit
and
then
ben
weintraub
and
cristina
anita
rotaru
at
northeastern
and
ben
is
also
in
the
audience
today
and
kyle's
here
too.
K
But
but
the
main
question
is
there's
a
technique
used
on
the
internet
called
overlay,
routing
primarily
by
cdns,
and
we
would
like
to
get
some
of
those
benefits
of
that
technique
outside
of
the
cdn
context,
and
so
we're
doing
a
case
study
on
anonymous
communication
and
when
one
wants
to
do
a
case
study
on
real
deployed
anonymous
communication,
you
basically
have
one
choice:
it's
tor
anonymous
in
the
sense
of
metadata
hiding
not
not,
and
then
encryption
a
lot
signal,
and
so,
when
we're
doing
this
case
study,
we
need
to
consider
application
goals.
K
It
doesn't
do
anyone
any
good
to
make
tor
a
little
bit
faster
if
it's
at
the
expense
of
privacy,
for
instance,
and
so
today
we're
going
to
explain
the
high
level
idea
of
this
proposal
and
present
a
little
bit
of
preliminary
evidence
in
favor
and
in
in
the
future.
We'll,
hopefully
have
more
evidence
we'll
build
out
a
proof
of
concept.
Do
more
analysis,
do
some
simulations
and
so
I'll
detail
all
all
of
our
plans
at
the
end
of
the
talk
yeah,
so
so
again
just
to
caution.
K
This
is
early
stage
in
progress
research.
We
are
not,
for
instance,
ready
to
propose
any
kind
of
drafts
today
so
for
background
content.
Distribution
networks
use
overlay
routing
to
for
for
a
variety
of
benefits.
So
this
is
a
diagram
from
cloudflare
detailing
argo,
which
is
a
product
they
offer.
K
Argo
is
their
name
for
overlay
routing,
and
so
what
this
does
is,
rather
than
having
a
user
connect
directly
to
the
origin
destination
over
the
default
route
that
the
internet
gives
them
and
their
isps
and
the
autonomous
systems
along
the
way
give
them
they.
K
One
is
perhaps
better
latencies
one
is
you
can
avoid
temporary
congestion,
you
can
avoid
permanently
slower
paths,
you
can
avoid
outages
and
in
some
circumstances,
you
wind
up
being
able
to
multiplex
traffic
for
a
better
overall
throughput
and
so
cloudflare.
Does
this
akamai
also
does
this?
They
call
their
product
sure
route,
and
so
what
lets
them
do
this
and
why
do
they
get
a
benefit
from
it?
K
Well,
cloudflare
akamai
cdns
need
to
route
a
lot
of
long
paths,
and
so
these
are
long
in
two
senses
geographically
and
in
a
network
sense
and
further,
you
need
to
be
able
to
use
your
machines
of
proxies
and
these
machines
need
to
be
widely
distributed
across
the
network
and
again
akamai
cloudflare
at
all
have
an
enormous
distribution
of
many
many
many
thousands
of
machines
all
over
the
internet.
They're.
K
All
very
powerful
and
they
have
a,
and
so
they
they
have
many
potential
proxies
to
use,
but
they
also
have
a
global
view
of
the
internet.
They
can
sort
of
in
real
time
and
in
they
can
assess
network
conditions
and
use
those
to
choose
better
routes,
and-
and
so
our
observation
is
that
tor
meets
several
of
those
conditions.
So
tor
is
an
anonymity
network.
It's
got
2
million
daily
users
and
importantly,
for
our
purposes,
it
has
about
six
thousand.
K
What
they
call
relays,
which
are
nodes
in
the
tor
network
and
further
traffic
in
the
tor
network
needs
to
travel
between
most
pairs
of
those
relays.
That
is,
you
know,
pick
any
two,
no
matter
how
far
away
in
the
world
they
probably
are,
or
many
of
them
are
going
to
need
to
talk
to
each
other
at
some
point
and
they're,
not
choosing
which
ones
talk
to
each
other
based
on
who's
near
each
other
in
the
network,
and
so
our
proposal
is
to
introduce
this
overlay
routing
technique
into
tor.
K
So
so
this
diagram
is
an
is
a
high
level
overview
of
what's
happening
in
tor,
a
user
is
going
to
connect
to
a
tor
relay
or
node,
which
is
going
to
connect
to
another
tor,
relayer,
node
and
another,
and
then
finally
it'll
spit
out
that
traffic
and
send
it
to
the
destination.
And
all
this
traffic
in
between
is
encrypted.
K
We're
proposing
to
not
alter
the
way
that
tor
pass
selection
works,
but
rather
use
the
same
path,
but
introduce
an
additional
hop
only
for
the
purposes
of
routing
so
traffic
between
the
first
and
the
second
relay
will
remain
encrypted
and
but
it'll
be
forwarded
and
not
decrypted
through
a
third.
K
What
we
call
via
node
and
again
this
this
will
give
possibly
many
of
the
same
performance
benefits
as
in
cdn,
so
latency,
perhaps
throughput,
perhaps
better
use
of
bandwidth,
perhaps
more
reliability,
and
our
early
analysis
suggests
that
there
will
be
minimal
security
impact,
yeah
and
so
again,
importantly,
we're
not
proposing.
There
are
many
other
orthogonal
proposals
to
alter
tor
pass
selection
for
reasons
of
either
security
or
performance,
and
we
are
not
proposing
any
changes
to
that.
We're
also
not
adding
additional
encryption
hops,
we're
just
adding
additional
hops
for
routing.
K
So
when
is
this
going
to
provide
latency
improvements?
Well,
it's
going
to
do
that
when
the
path
direct
when
the
direct
path
is
slower
than
the
path
from
a
to
x,
then
from
x,
to
b
so,
namely,
like
this
wouldn't
happen,
geometrically,
it's
never
going
to
be
faster
or
geographically.
It's
never
going
to
be
faster
to
me
for
me
to
like
walk
to
my
destination
via
some
other
point
than
it
would
be
to
walk
directly,
but
on
the
internet.
K
K
Their
data
is
public
and
we
we
have
some
analysis
of
it,
so
they
collected
latency
data
between
all
pairs
of
a
small
subset
50
nodes
in
the
tor
network
and
of
those
we
find
sort
of
these
latency
speed
up
conditions
in
many
of
them
and
kind
of
as
you'd
expect.
In
most
cases,
these
speed
ups
are
very,
very
small,
but
you
do
find
some
paths
there.
K
There
will
be
a
pair
of
ra
of
tor
relays
where
the
default
traffic
path
is
over
a
hundred
milliseconds
slower
than
you
could
get
by
routing
via
some
other
node,
and
so
we
just
from
that
data
set,
we
we
mapped
out
a
couple
examples
of
large
speedups.
So
the
default
route
from
this
node
and
looks
like
the
us
east
coast
into
scandinavia
takes
200
milliseconds,
but
it
turns
out.
If
you
go
via
mainland
europe,
you
can.
K
You
can
basically
have
that,
and
so
what
this
suggests
is
is
that
the
default
route
being
used
is
slow
and
and
could
be
improved,
and
you
see
that
again
over
on
the
right
side
of
the
screen,
yeah
and
so
this
we.
We
also
observed
that
many
of
these
pairs
of
nodes,
their
default
routes,
are
really
bad.
So
in
this
example,
34
out
of
the
50
relays,
when
used
as
intermediate
nodes,
would
provide
a
speed
up.
K
So
the
default
route
is
worse
than
choosing
another
node
in
the
tor
network
at
random
to
route
traffic
through
and
again
this.
This
this
just
indicates
that
whatever
default
route
is
is
coming
out
of
this
relay
to
the
other
relay
is
particularly
bad
yeah,
so
so
this
data
is
all
all
from
2015,
it's
a
little
out
of
date
and
it's
pretty
small
scale.
So
we
really
want
to
scale
up
measurements
of
pairwise
latencies
in
the
tor
network.
So
we've
been
in
communication
with
the
tor
research
safety
board.
K
We
have
their
permission
to
to
do
this
experiment
and-
and
the
next
step
also
is-
we
want
to
make
sure
it's
actually
secure
so
most
existing
tor
security
metrics
that
are
that
are
used
in
academia
to
try
to
quantify
the
impact
of
various
changes
to
the
tor
network
aren't
affected.
We
think
that,
like
like,
they
are
not
affected
in
any
way.
We
think
that's
not
quite
right.
K
We
think
that
there
must
be
some
impact
to
doing
this,
so
we're
trying
to
adapt
some
existing
security
frameworks
and
make
sure
we
can
quantify
exactly
how
bad
the
risk
of
de-anonymization
gets.
K
You
know.
Perhaps
this
will
be
very
promising
and
we
would
actually
want
to
build
this
out
in
the
tor
network.
In
any
case,
I
think
this
is
of
independent
interest
for
a
couple
of
reasons.
These
torah
network
latency
measurements
feel
like
a
useful
data
set
for
worrying
about
tour
de
anonymization
and
finally,
we
we
hope
that
this
generates
some
interest
in
using
overlaid
routing
techniques
and
other
decentralized
systems
yeah.
So
that's
what
I
have
happy
to
answer
any.
L
Yeah
thanks,
you
know
that's
a
really
interesting
concept
and
idea.
I
need
to
you
know:
wrap
my
head
around
it
a
little
bit
more
to
figure
out
how
you
would
actually
execute
it.
Cdns
have
a
lot
of
ability
to
sort
of
control,
those
overlay
networks,
and
so
in
your
diagram.
You
know
you
kind
of
indicate
that
there's
these
hops,
where
middle
tour
nodes,
are
actually
making
a
decision
about
what
direction
to
send
something
and.
L
K
Yeah,
I
guess
I
suppose
I'd
I'd
argue
that
that's
already
the
case
that
if,
if
any
of
these
relays,
I
guess
you're
just
increasing
the
number
of
relays
that
could
do
this,
but
any
of
the
relays
in
your
tour
path
have
this
capability
to
artificially
slow
down
traffic
already.
K
So
I'm
I'm
not
certain
what
the
what
the
impact
is
beyond
increasing
the
number
of
relays
that
might
do.
This
is
maybe
I'm
misunderstanding.
L
I
think
that
you
you're
getting
the
point,
I'm
not
sure
so
I
haven't
looked
into
how
much
can
an
existing
relay?
You
know
slow
down
epic.
In
the
first
place
I
mean
that
they
can
certainly
hold
on
to
things
longer
in
the
first
place,
but
okay
thanks.
K
Yeah
yeah,
I
believe
that
that's
roughly
equivalent
from
at
least
a
theoretical
point
of
view,
whether
it's
equivalent
equivalent
practically,
maybe
not
the.
K
Case
all
right,
any
any
other
questions,
I'm
not
I'm
not
looking
at
the
chat.
Sorry,
if
there's.
M
Yeah,
there's
a
sorry:
I've
got
a
difference,
there's
a
bunch
of
conversation
to
chat
where
kylie's
kyle's
been
answering
a
bunch
of
questions
about
so,
for
instance,
can
you
deploy
this
just
by
modifying
the
client
to
change
path,
selection
and
then
dave
asked
the
question
about?
How
do
you
usually?
How
do
you
compute
the
route
so
that
not
everybody
goes
over
the
faster
route
and
then
makes
it
slow
again
by
overloading
that
four
and
in
the
middle.
K
Yep
yep.
Yes,
that's
a
that's
a
great
question
both
of
those
I'll
start
with
the
latter,
which
was
how
do
you?
How
do
you
make
sure
that
you
don't
do
this
in
an
overwhelming
way?
K
And
so
that's
what
our
our
simulations
are
going
to
hope
to
answer
our
vision
is
that
this
will
be
a
very
like
edge
case,
we're
hoping
to
help
with
tail
latencies
in
the
kind
of
you
know,
90th
per
95th,
percentile
or
so,
and
we're
not
expecting
that
most
hops
are
going
to
be
affected
by
this,
and
if
that
is
the
case,
then
hopefully
the
overall
impact
both
on
bandwidth
and
and
kind
of
on
those
individual
nodes
would
be
relatively
low.
K
Also,
these,
oh,
I
guess
that's
a
segue
into
the
next
question
also,
so
these
decisions
would
be
made
roughly
in
in
real
time,
so
these
nodes
might
have
a
list
of
candidate
intermediate
nodes
in
the
path,
but
they
would
actually
make
those
decisions
based
on
sort
of
data
races.
This
is
how
it
happens
in
the
in
the
cdn
context
and
so
they're
informing
the
final
routing
decision
based
on
real
world
network
conditions
and
then
sorry
the
first
question
was:
could
you
do
this
client
side?
K
K
K
Well,
you
could
do
that
with
essentially
no
modification
to
the
to
the
tour
servers
by
making
only
client-side
software
modifications,
but
that
would
involve
extra
in
extra
encryption
hop
at
these
vias,
which
would
increase
the
latency
probably
over.
It
would
probably
wash
out
most
of
the
benefit
from
doing
this,
that
extra
encryption
step.
A
Any
other
questions
for
kyle
and
zach.
We
are
at
time.
So
that's
perfect
thanks
a
lot
zach
and
kyle,
and
also
for
like
the
great
tag
teaming
with
the
answering
questions
in
the
in
the
chat.
I
think
there's
a
lot
of
discussion
that
happened
in
the
chat
and
there
seems
to
be
a
lot
of
interest
so
yeah.
We
hope
to
see
further
iterations
on
this
work.
K
Yeah
yeah,
we'll
we'll
keep
hopefully
keep
you
updated
as
it
progresses.
A
Is
sam
here,
sam
hello,
hey!
I
believe
you
don't
have
skype,
but.
N
Yeah,
okay,
awesome,
those
slides,
hi,
everyone,
I'm
I'm
stan.
I
am
a
policy
attorney
from
the
center
for
democracy
and
technology.
I
am
not
a
technologist,
so
I'm
a
little
a
little
out
of
my
depth
here.
I
want
to
present
sort
of
the
latest
status
and
updates
on
the
survey
of
censorship
drafts.
N
N
Part
of
the
issue,
the
larger
issue
with
this
draft
is
that,
in
order
to
keep
it
as
an
up-to-date
resource
because
of
the
constantly
evolving
and
emerging
nature
of
censorship
techniques,
it
requires
someone
to
either
be
on
hand
to
sort
of
provide
regular
updates
to
this
or
for
it
to
otherwise
be
a
living
document.
In
some
fashion,
we
have
found
that
to
be
basically
unsustainable
for
for
at
least
the
the
original
authors,
and
so
I
believe
we
have
reached
consensus
based
on
the
list
to
sort
of
bring
this
to
a
close
date.
N
It,
as
you
know,
last
last,
updated
as
of
a
certain
date
and
then
let
it
be
what
it
is
after
that,
where
it
is
now
is
almost
there.
I
believe
there
are
about
12
issues
open
a
lot
of
them
are
sort
of
minor
debates
about
terminology
updating
some
references.
There
are
a
few
larger
issues
to
resolve
about
terminology
and
relationship
between
things,
but
I
don't
think
any
of
them
are
are
too
major
of
an
issue.
N
So,
as
I
said,
I'm
a
lawyer,
I
am
able
to
resolve
some
of
these.
My
role
in
this
so
far
has
been
mostly
as
an
editor,
not
not
a
substantive
contributor,
so
I
I
can
probably
fix
a
lot
of
these
that
deal
with
sort
of
updating
citations,
substituting
in
a
few
extra
words
or
swapping
out
some
terms,
I'm
less
able
to
deal
with
resolving
technical
issues,
but
I
believe
we
have
some
volunteers
here
in
this
group
to
vol
to
sort
of
help
me
out
figuring
those
things
out
and
then
bringing
these
to
a
close.
N
N
I
hope
that
I
can
get
some
time
spent
on
this
in
the
next
three
or
four
weeks,
but
I'm
especially
crunched
at
work
these
days,
and
so
this
is,
this
continually
falls
lower
on
my
priority
list
than
I
would
like
happy
to
answer
any
questions
about
that
or
say
more.
If
that
would
be
useful.
A
Thanks
a
lot
stan
for
both
your
and
other
authors
work.
I
think
we
are
at
time.
We
don't
have
any
time
for
questions
or
comments,
but
I
guess
that
was
very
victory,
like
we
had
literally
a
time.
J
To
mark
the
the
remaining
issues
by
priority
like
the
ones
that
you
won't
be
able
to
get
to
until
later
on,
and
then
maybe
we
can
try
to
tackle
those
on
first,
that's
all.
I
wanted
to
say.
A
You
can
just
kind
of
push
this
out
after
so
much
work
that
folks
have
put
in,
and
the
idea
is
to
publish
a
snapshot.
Yes
for
them
to
be
like
this
is
up
to
date.
As
of
this
date
and
yeah,
we
can
do
a
last
call
for
that
soon,
right
after
the
authors
of
other
channels
should
look
at
the
existing
issues
and
with
that
thanks
all
for
coming
to
edgy
at
ietf110
and
hope
you
have
a
great
last
day
of
it
here.