►
From YouTube: IETF108-MASQUE-20200728-1100
Description
MASQUE meeting session at IETF108
2020/07/28 1100
https://datatracker.ietf.org/meeting/108/proceedings/
A
D
E
A
A
This
is
this
should
be
a
new
experience
for
many
of
us
using
the
echo
either
as
a
participant
or
a
chair,
so
bear
with
us
as
we
work
through
any
sort
of
technical
difficulties
and
and
trying
to
make
this.
You
know
successful
or
productive
meeting
as
as
typical,
most
itf
meetings
when
you
enter
the
mic
line
or
queue
line
to
say
something.
A
Please
introduce
yourself
so
that
the
note
taker
can
get
that
down
we'll
you
know
enter
you
into
the
queue,
so
you
can
ask
questions
as
the
presentations
go
on
and
you
can
leave
the
cube
shortly
thereafter,
please
be
concise
at
the
mic.
We
only
have
like
20
minutes
for
each
talk
and
I'm
hoping
we
can
use
that
time
for
a
pretty
useful
conversation
in
the
discussion
next
slide.
Please
and
sean
I'll
see
you
I'll
get
you
in
a
second.
A
A
A
So
here's
some
helpful
links
to
help
you
follow
along.
You
can,
of
course,
join
the
job
room
and
follow
along
with
the
notes
before
we
go
any
further.
We
do
this
is
makeup
on
on
us.
We
do
actually
need
a
notetaker
and
a
jabber
scribe,
so
if
someone
would
be
willing
to
do
that,
that
would
be
super
helpful.
A
Okay.
Eric
also
helpfully
pointed
out
that
I
forgot
to
mention
this
is
being
recorded
like
most
itf
meetings.
So
just
take
that
into
account,
I
guess
all
right.
So
here's
our
agenda
we've
gone
through
slide
selection,
our
scribe
selection
and
the
note
well
and
everything
we
have
four
presentations
on
the
docket
connect,
udp
from
david
skenazi
iproxy
and
requirements
from
dallas
mccall
quickboxing
from
tommy
poly
and
transfer
considerations
for
ipud
proxy
from
magnus
westerland.
A
A
B
B
B
I
figured,
I
would
add,
just
a
little
bit
of
historical
context
here,
because
it's
not
really
written
down,
and
I
saw
I
got
some
questions
from
folks
and
I
realized
that
it
was
kind
of
a
mess
of
drafts.
So
I
figured
I
would
just
walk
through
this.
A
little
bit
for
everyone,
so
mask
is
actually
an
acronym
for
multiplexed
application,
substrate
over
quick
encryption
and
is
not
named
after
what
we
should
all
be
wearing
to
save
lives
during
this
pandemic.
B
I
got
the
draft
kind
of
split
into
multiple
parts
where
all
of
the
like
obfuscation
part
turned
into
its
own
http
header,
so
the
that's
drafts
knowledge,
http,
based
transport
off
and
then
just
the
all
the
concepts
of
oscillation
and
all
like
how
to
accomplish
that
got
kind
of
split
into
its
own
draft,
because
that
was
a
part
that
not
everyone
at
the
atf
was
interested
in
working
on
and
the
part
that
folks
were
more
keen
on
became
drafts.
Gnazi
mass
protocol,
so
that
was
discussed.
B
Then
this
year,
in
march
and
kind
of
as
we
went
through
the
chartering
process
for
the
working
group,
we
kind
of
pivoted
from
mask
being
like
a
full-on
protocol
that
had
kind
of
a
swiss
army
knife
of
vpn
features
to
potentially
building
every
like
what
used
to
be
called
the
mask
application
as
its
own
draft.
So
not
a
mask
protocol
but
individual
drafts
that
work
over
http.
B
B
So
most
of
us
are
probably
very
familiar
with
gp
connect,
but
just
to
be
really
give
you
a
very
quick
recap:
it's
been
around
for
over
two
decades
published
in
rc-2817,
supported
in
pretty
much
every
version
of
http
and
it's
pretty
simple.
The
client
tells
the
proxy
to
open
a
tcp
connection
to
a
host
and
port.
B
So
we
we
thought
of
doing
something
that
was
similar
to
connect.
The
reason
we
didn't
re
reuse
connect
is
that
if
you
send
the
connect
method
to
an
existing
proxy
today,
that
is
not
updated
to
support
like
any
new
extension.
We
want
to
add.
It
might
just
create
a
tcp
connection
where,
if
you're
trying
to
ferry
around
a
udp
protocol
would
be
completely
non-useful,
so
we
kind
of
went
with
the
option
of
creating
a
new
http
method.
B
So
this
new
method
is
http
connect.
Udp
naming
bike
sheds
obviously
welcome.
This
is
just
a
working
title
and
the
idea
is
to
do
the
same,
but
for
udp
so
supported
in
all
versions.
That's
because
on
the
client-to-proxy
leg
there
are
networks
where
udp
is
blocked
so
going
over.
Http
201
helps
avoid
that,
and
there
are
some
networks
that
use
a
sheepy
intermediaries
and
then
only
have
hp11
available
between
the
instrumentary
and
back
end.
B
B
So
if
you
look
in
the
slides,
you
have
an
example
of
what
it
looks
like
http
one
one
start
simple
and
then
similar,
you
add
a
little
bit
of
framing
on
the
connect
stream
to
have
the
limits
of
all
your
packets
and
then
you
forward
those
there
into
and
then
they're
transformed
into
utp
packets
in
the
proxy
to
server
like
and
then,
however,
what
makes
this
compelling
these
days
is
that
first
gp3
we
can
use
quick
datagram
frames
to
avoid
reliability
next
slide.
Please.
B
So
what
does
that
mean
is
so
right
now?
This
is
built
on
another
draft
of
mine,
which
is
quick,
h3
datagram.
To
give
you
a
very
quick
summary
of
that
draft.
The
idea
is
that
quick
has
an
extension
called
datagram
frames,
but
the
content
of
those
datagrams
is
left
to
the
application
and
so
the
when
the
application
is
http
3.
B
That
draft
defines
how
to
use
the
datagrams
and
the
way
it
does.
That
is
by
appending
a
quick
variable
length
integer
at
the
start
of
each
datagram,
to
allow
you
to
do
demultiplexing
and
then
in
order
to
be
able
to
use
those
identifiers
for
anything
useful.
The
idea
is
that
both
endpoints
keep
a
flow
id
allocation
service
that
gives
you
like
a
unique
identifier,
each
time
even
identifiers
for
the
client,
all
the
ones
for
the
server
and
but
that
draft
doesn't
specify
any
sort
of
protocol
to
negotiate
these.
B
And
so
that's
where
connect
udp
comes
in
and
says
okay,
so
you
send
the
connect,
udp
method
and
the
authority,
and
then
you
add
a
new
header
which
is
datagram
flow
id
which
tells
you
okay.
This
is
the
datagram
id
that
we
will
use
for
this
connect
udp
and
the
reason
you
want
that
is
that,
on
an
http
3
connection,
you
could
have
multiple
separate
connect
udp
to
different
servers
within
the
same
http,
3
connection,
and
you
use
the
datagram
flow
identifier
to
demultiplex
them
next
slide.
Please.
B
B
However,
if
we
look
at
big
server
deployments
of
http
today,
it's
not
always
a
single
box
that
does
all
this.
From
the
comments
perspective,
it
feels
like
you're
only
talking
to
one
machine,
because
it's
serving
you
your
tls
certificate
and
terminating
either
your
tls
connection
or
your
quick
connection,
but
in
reality
you
might
be
talking
to
an
intermediary
that
is
then
based
on
the
contents
of
the
http
request.
You
make
sending
them
to
a
different
back
end.
B
So
in
this
example,
and-
and
you
could
also
by
the
way,
have
multiple
activities
before
the
back
end,
and
so
in
this
example.
The
client
actually
has
an
issue
b3
connection
to
the
interpreter,
but
that
one
in
turn
has
it
can
be
an
http
one.
One
connection
between
the
intermediary
and
the
back
end
and
connect
udp
will
be
routed
from
the
client
to
the
back
end.
B
So
that's
why
we
need
http
one
one
for
to
support
connect
udp,
but
it
also
makes
it
a
little
bit
harder
to
ferry
datagrams
because
they
they
no
longer
work
and
to
end
from
the
client
all
the
way
to
the
back
end,
because
that's
a
feature
only
available
in
should
be
three
and
above
next
slide.
Please.
C
B
That
goes
into
a
great
deal
of
detail
on
those,
but
the
I
really
hope
that
we
can
ship
something
very
simple
for
connect,
udp
that
is
very
like
very
closely
min
mix
just
connect
and
but
that
we
make
extensible
enough
that
all
of
these
cool
features
can
be
added
as
extensions
later
so,
for
example,
like
notions
about
icmp
handling.
If
there's
icmp
between
the
proxy
and
server,
what
do
we
do
with
it?
B
So
this
is
kind
of
a
question
for
the
working
group
and
you
know
for
the
community
at
large,
because
this
is
something
we
also
want
to
discuss
with
the
http
working
group
in
the
quick
working
group.
But
we
have
these
two
drafts,
so
one
is
the
one
I
just
presented:
connect
udp
and
one
is
a
like
required
dependency
for
it,
which
is
h3
datagram,
which
tells
you
how
to
use
quick
datagrams
with
http
3.
at
first.
B
B
H
So
now,
how
do
I
we
hear
you,
okay,
all
right,
so
that
happened
by
itself?
Great?
Yes,
I
think
there
is
value
in
keeping
them
separate,
simply
because,
if
quick
had
had
datagrams
when
we
were
writing
the
h3
spec,
there
were
several
of
the
frames
that
we
would
probably
have
sent
as
datagrams
instead
of
on
the
control
stream,
and
that
was
a
conversation
in
the
time
we
might
revise
h3
in
the
future
to
go
in
that
direction.
B
So
another
one
is
I,
from
the
multiple
conversations
I've
had
over
the
past
few
weeks,
I'm
noticing
a
pattern
so
connect
udp,
we
just
talked
about
tommy,
is
going
to
discuss
later
today.
Connect,
quick
and
dallas
is
going
to
present
about
ip
proxying
requirements,
which
could
lead
to
a
future
method
called
connect.
B
B
F
I
don't
think
actually
reflects
kind
of
what
the
the
real
friction
level
will
be.
So
I
think
sticking
with
methods
and
and
going
that
way,
actually
will
make
sense
in
the
long
term,
even
if
it
seems
like
at
the
moment
there
are
two
or
three
of
these
you
you
want
to
handle.
I
I
don't
think
we're
going
to
see
20..
I
don't
think
we're
going
to
have
a
whole
bunch
of
these
suddenly
emerging
so
that
we
need
the
flexibility
of
connectx.
I
B
I
I
So
I
would
like
to
live
in
a
world
in
which
we
could
get
connectx
out,
but
I'm
not
sure
we
live
in
that
world
right
now
and
I
don't
want
to
block
the
progress
on
mask
on
on
getting
to
a
point
where
we
think
that's
actually
implementable,
because
we'll
still
end
up
having
to
have
connect,
udp
and
connect
like
the
current
connect
and
we'll
probably
end
up
having
a
connect.
Quick
that
will
go
before
a
connectx
would
would
be
widely
implemented
as
well.
So
so
I
I
agree
with
ted,
but
for
different
reasons.
J
J
I
I
think
some
of
these
like,
if
we're
doing
them
all
in
mask
together,
there
is
room
to
connect
them
into
a
unified
proposals
like
we,
don't
necessarily
need
a
separate
connect,
udp
and
a
separate
connect,
quick,
potentially
the
connected
udp
we
can
design,
may
have
more
knobs
than
what
your
current
draft
has.
But
I
do
like
ted's
overall
point
that
once
we
have
one
shippable
thing
that
works
for
a
set
of
protocols,
we
can
just
push
that
out
and
not
worry
about
it,
covering
all
the
futures.
B
B
K
So
I
don't
see
a
problem
with
having
multiple
methods,
slash
whatever
the
identifier
is
that
we
use
to
distinguish
between
these.
So
I
would
prefer
to
identify
those
things
that
end
up
being
common
and
make
them
the
same,
but
not
necessarily
make
the
mechanism
generic,
as
in,
I
would
say,
prefer
composition
rather
than
inheritance
and
see
how
far
that
gets.
You.
B
No
yeah
and
that's
a
good
point.
We
can
definitely
have
let's
say,
for
example,
when
we
want
to
do
connect
quick,
have
it
reference,
connect,
udp
and
say
well.
This
is
mostly
the
same
mix
and
here
are
the
differences
which
you
know.
If
you
look
at
other
http
methods,
they
have
a
lot
in
common.
That's
a
that's
a
very
good
point.
B
B
Oh
yeah
there's
definitely
a
lot
of
similar
similarity
with
web
transport
and
we
might
end
up
having
like
one
layer
on
top
of
the
other,
we'll
have
to
see
the
details
there.
I
would
prefer
to
not
tie
this
to
to
not
tie
the
two
at
this
point,
because
right
now,
they're
still
pretty
different
and
we
don't
know
which
one
will
make
more
progress
faster.
B
B
Oh
absolutely
and
to
clarify
I'm,
I
wasn't
asking
the
working
group
to
decide
everything
in
the
room
today.
This
document
it
hasn't
even
been
adopted.
Yet
it
was
just
to
kind
of
get
a
feel
for
the
room
and
thoughts
and
take,
for
example,
like
I'm
appearing
loud
and
clear
that
the
connectsdex
idea
will
look
great
on
my
shelf
and
probably
is
not
the
way
to
go.
So
that
was
really
what
I
was
hoping
for,
which
is
great.
E
B
B
A
B
A
B
Yeah
so
answer
questions
from
previous
slides.
I
think
we'll
definitely
take
those
to
the
list,
but
then
I
mean
I'll
I'll.
Let
the
chairs
comment
on
where
we
want
to
go
next.
If
this
is
ready
for
adoption
or
not
yet,
but
then
next
slide,
I
think
we
can
open
this
for
general
questions
and
thoughts
and
comments
and
oh
perfect
echoes
back.
G
Yeah,
so
I
I
read
this
as
you
may
know,
I
I
think
it's.
I
think
it's
good
enough
for
for
adoption.
I
mean
it's
something:
to
enact
the
thing
that
we
agreed
to
do.
The
part
that
I
have
some
concerns
about
is
the
proxy
handling.
I
I
think
you
know
the
nature
of
the,
as
you
indicated,
the
nature
of
the
proxies
that
people
typically
encounter
at
this
point.
G
Is
that
they're
not
aware
of
them
and
the
the
the
sort
of
apparent
desire
to
push
the
capabilities
of
proxy
all
the
way
back
to
the
to
the
client
via
political
mechanisms
seems
to
either
be
the
wrong
instinct.
I
think
the
right
instinct
is
to
require
the
proxy
that
for
each
proxy
in
in
in
the
front
fox
in
the
system
to
be
aware
of
the
capabilities
behind
it
and
manage
the
management,
manage
this
negotiation
appropriately
and
to
conceal
these
as
the
other
proxies
for
the
client.
B
Thanks
yeah,
I
know,
and
I
definitely
want
to
hash
out
the
multiple
proxies
I'm
realizing
that
somehow
we
completely
skipped
that
slide.
Where
I
was
talking
about
it
cheers.
Could
you
bring
me
back
to
slide
eight
just
for
20
seconds
just
because
that
was
an
important
point
I
wanted
to
make,
and
I
not
sure
how
that
got
slipped.
Apologies
again.
It
is
way
too
early
here.
So
the
previous
slide
was
the
one
where
we
explained
that
you
know
proxy
corp
can
actually
have
intermediaries
and
the
question
is
right
now.
B
I
think
the
mechanism
in
the
draft
just
doesn't
work,
but
we
could
make
it
work
by
making
the
datagram
flow
id
hub
by
hop
header
by
putting
in
the
connection
header,
and
that
was
also
a
question
I
had
for
folks,
because
I
think
that
would
work
and
like
eckerd
since
you're
there.
If
you
have
any
thoughts
on
that
one
or
or
not,
it
was
kind
of
a
especially
question
for
the
folks
that
know.
Http
interpreter
is
better
than
I
do.
I
You
should
have
access
to
them
at
the
end
points
for
how
you're
going
to
change
these
things-
and
I
I
alluded
to
this
a
little
bit
in
my
my
thinking
through
why
I
thought
connect
x-
was
a
good
idea
because
you
could
actually
say
okay.
Well,
I
want
to
build
this
chain
of
proxies
and
if
the
available
chain
of
proxies
matches
the
chain
of
proxies,
you
want
to
build,
then
it
goes
through.
I
B
Cool
no
and
that's
totally
reasonable
at
first.
I
hadn't
thought
about
this
at
all,
and
folks
told
me
that,
like
for
this
to
like
properly
respect
hp,
this
use
case
had
to
be
supported,
but
if
we,
you
know
specifically
decide
as
a
working
group
that
that
is
a
non-goal
that
actually
simplifies
things.
So
that's
solely
an
option.
In
my
mind,
thanks
thank.
F
Relaying
for
eric
nygren,
another
reason
a
connectx
might
make
sense-
would
be
for
cross-protocol
interactions,
in
particular
for
handling
icmp
v6
responses
to
udp
messages
such
as
for
pmtud
ptp.
Although
the
proxy
may
slash
will
need
to
translate
those
regardless.
So
it
may
be
that
that's
a
special
case
and
just
having
a
general
mechanism
for
relaying
those
back
across
the
various
connect
star
methods
would
also
be
fine.
K
So
that's
going
to
make
it
a
little
bit
different
to
do
hop
by
hot
messaging
without
using
frames,
but
I
suspect
you're
gonna
have
to
use
frames
or
some
sort
of
settings
to
negotiate
the
capabilities
hot
by
hop
anyway.
Otherwise,
you're
gonna
end
up
in
a
situation
where
one
or
other
entity
that's
involved
in
the
in
the
chain
is
under
the
impression
that
they
can
send
datagrams,
but
you
don't
have
datagrams
all
the
way
down
down
the
pipe.
B
Cool
thanks,
yeah
that
I
I
I
knew
there
was
a
reason
this
wouldn't
work,
but
I
just
couldn't
find
it
so
perfect,
yeah
I,
this
is
making
more
me
lean
more
towards
what
brian
and
ecker
were
suggesting
of
like
making
that
you
know
explicitly,
maybe
a
non-goal.
In
that
way
we
require
like
a
specific
setting
on
the
h3
or
h2
connection
between
the
client
and
tributary.
That
could
be
good.
G
So
there
seem
to
be.
Actually,
I
think
part
of
the
problem
is
when
we
use
the
word
proxy,
we're
actually
confusing
a
number
of
concepts
which
maybe
don't
go
together
that
well
so
the
proxies
I
think
you're
talking
about
are
are.
This
is
a
little
hard
to
tell
with
you
know
this
diagram,
but
are
you
know
what
used
to
call
reverse
proxies
right
in
the
sense
that
you
have
multiple,
multiple
house
between
you
in
the
back
end?
B
Definitely
agree
and
yeah.
This
is
definitely
confusing
and
I
I
think
we
can
do
a
lot
better
yeah
and
focusing
on
the
forward.
Proxies
makes
a
lot
of
sense
to
me:
cool,
okay
and
go
ahead
david.
Sorry,
I
was
just
going
to
say
if
you
want
to
take
us
to
the
last
slide
and
then,
if
the
chairs
have
closing
comments
on
where
what
I
should
do
with
the
drafts
now.
A
Yeah,
so
there
seems
to
be
a
lot
of
I'm
generally
interested
in
the
draft.
Certainly
there's
issues
that
need
to
be
worked
through,
but
as
decker
is
another,
as
I
pointed
out,
these
are
things
we
can
work
through
during
the
working
group.
So
at
this
time
now
I'm
gonna
be
crazy
and
attempt
to
use
the
hum
mechanism
on
media.
Oh.
A
E
A
A
B
K
C
D
Together
a
draft
of
ip
proxy
requirements
and
use
cases
over
mask:
can
you
go
to
the
next
one?
Please,
okay,
so
to
begin
I'd
like
to
describe
the
use
cases
that
we
considered,
while
laying
out
our
requirements.
First
off
is
that
of
a
point-to-point
connection
here,
we're
talking
about
two
end
points
connected
to
one
another
with
an
ip
tunnel
and
they're
just
proxying
ip
packets
between
one
another.
We
think
that
this
is
a
useful
use
case
for
building
a
more
complex
virtual
overlay
network.
D
D
D
Can
you
move
on
to
the
next
slide?
Please,
okay,
so
now
that
I've
skimmed
over
the
use
cases
that
we
considered
I'd
like
to
kind
of
talk
about
the
requirements
that
we're
thinking
about
kind
of
going
from
the
the
base
security
requirements
up.
So
as
this
is
effectively
a
vpn,
we
believe
that
the
the
transport
of
this
runs
over
should
be
both
mutually
authenticated
confidential
and
have
integrity.
So
we
believe
something
like
quick
or
tls
should
be
able
to
satisfy
this.
D
In
addition
to
this,
the
the
authentication
that
is
performed
for
establishing
an
ip
session,
we
believe,
should
be
separable
from
the
authentication
that
is
done
when
establishing
the
transport.
I
I
saw
on
the
list
that
there
is
a
question
about
this
I'd
like
to
explain
that
in
a
little
bit
more
detail,
what
we're
thinking
is,
for
instance,
if
you
use
tls
to
establish
the
underlying
transport
and
the
the
client
authenticates
the
server,
but
perhaps
the
server
doesn't
authenticate
the
client.
D
Finally,
I
like
to
sort
of
state
the
obvious,
but
whatever
identifiers
that
we
use
for
actually
authenticating
one
another
and
for
providing
the
peers
identities
should
be
cryptographically.
Verifiable
next
slide,
please,
okay,
so
moving
to
the
session
that
will
be
running
on
top
of
the
secure
transport,
and
I
see
somebody
in
the
queue
is
it
a
clarifying
question.
D
G
D
G
D
M
Yeah
hi
again
everyone.
Yes,
we
can
hear
you
hi,
I'm
alex
schneiderski.
I
helped
write
part
of
the
structure.
I
wanted
to
address
a
little
bit
of
ecker's
question
there.
So
when
we
say
cryptographically
verifiable,
we
don't
necessarily
mean
that
the
data
translated
itself
has
some
sort
of
inherent
cryptographic
property,
but
that
is
verifiable
by
the
server
so
like
what
you
could
imagine
is
doing
something
more
like
even
a
traditional
http
web
login,
where
the
cookie
is
somehow
verified
by
the
server
it
could
be
like
hmac
or
something
like
that.
G
D
Okay,
thank
you
alex
all
right,
so
moving
on
to
the
session
requirements
to
establish
a
session,
we
believe
that
it
should
be
necessary
for
a
client
to
send
a
request
for
an
ip
session,
along
with
some
set
of
configuration
options
that
I'll
discuss
a
little
bit
more
later
and
once
the
ip
session
request,
along
with
these
configuration
options,
has
been
sent
to
the
server.
The
server
should
be
allowed
to
either
accept
or
deny
the
client's
request
at
its
own
discretion.
D
Presuming
the
server
has
chosen
to
accept
the
request.
The
primary
purpose
here
is
to
proxy
ip
packets,
so
the
protocol
will
go
on
to
establish
some
form
of
data
transport,
we're
envisioning
using
either
quick
datagrams,
preferably
or
perhaps
stream
frames
to
actually
do
the
the
passing
of
these
ip
packets
in
their
modified
entirety.
D
D
So
now
I'd
like
to
move
up
to
requirements
of
the
session
that
we
believe
are
very
important,
but
should
also
be
configurable
so
to
begin
with
a
reliable
transmission
so
again
we're
forwarding
accu
packets,
so
it
is
generally
desirable
to
transmit
these
ip
packets
unreliably.
However,
there
are
a
narrow
set
of
circumstances
where
it
actually
makes
more
sense
to
transmit
these
reliably.
D
D
D
Looks
like
I
got
cut
off
a
little
bit
so
here
I'd
like
to
discuss
the
configuration
requirements
that
we're
considering
for
the
actual
ip
session
once
it's
been
established.
So
first
up
is
mtu
negotiation.
I
I
saw
on
the
list
earlier
that
maybe
negotiation
is
a
bit
generous
of
a
word.
All
we're
talking
about
is
that
they
share
the
mtu
and
decide
on
a
common
one
between
either
pure
next
up
is
ip
assignment
this
we
considered
specifically
to
address
the
the
point
to
network
use
case
here.
D
Either
peer,
the
client
or
the
server
should
be
able
to
request
to
be
assigned
some
ip
address
range
and
in
response,
the
peer
that
received
the
request
should
return
an
ip
address
range
of
its
choosing,
so
to
be
a
little
bit
more
concrete
here.
This
might
be
your
your
work
laptop
connecting
to
your
corporate
network,
the
work
laptop
requests,
an
ip
address
range
of
the
gateway
that
is
in
your
corporate
network.
K
D
The
next
point
here
is
of
rob
negotiation,
so
we
are
using
this
to
to
address
the
the
point
to
point
and
network
to
network
use
cases,
and
I
I
also
saw
there's
some
confusion
here
on
the
the
list
that
I'd
like
to
explain
a
little
bit
more
detail.
So
here
what
we're
thinking
about
is
either
the
client
or
the
server
at
any
point
in
an
ip
session
may
request
to
advertise
a
set
of
routes
to
its
peer.
D
So
this
is
saying
I
would
like
to
advertise
the
routes
x,
y
and
z.
In
response,
the
peer
can
reply
with
some
subset
of
routes
that
is
willing
to
accept,
or
it
can
deny
the
request
outright.
So
if
the
client
said,
I
would
like
to
announce
routes
x,
y
and
z,
the
server
can
say:
okay,
I
will
only
accept
routes
x
and
z,
there's
discussion
of
maybe
we
can
use
an
existing
protocol
for
for
doing
this.
D
I
think
that's
entirely
reasonable
and
we're
discussing
more
and
finally,
these
configurations
should
be
extensible.
So
as
we're
talking
about
in
the
authentication
section
previously,
it
seems
entirely
reasonable
that,
once
the
actual
transport's
been
established,
we
may
want
to
extend.
Excuse
me
exchange
vendor-specific
credentials
while
actually
establishing
the
ip
session.
So
we
should
have
a
reasonable
extension
point
on
these
configurations
to
allow
users
to
to
set
back
and
forth
additional
useful
configuration
options.
D
D
First
off
is
that
of
an
addressing
architecture,
so
both
endpoints
will
have
some
address
space
that
they're
using
in
the
context
of
the
ip
session
itself.
We
should
not
really
care
these
from
our
perspective,
are
just
opaque
identifiers
that
that
are
saying
whatever
is
semantically
relevant
to
either
endpoint,
but
it's
not
important
for
the
session.
D
The
next
point
is
that
of
network
address
translation.
You
can
think
concretely
in
the
case
of
like
network
to
network
connections.
We
may
be
bridging
two
networks
who
have
private
address
spaces
that
conflict
with
one
another,
that's
an
entirely
likely
scenario,
but
we
believe
that
that
address,
translation
or
or
other
modification
of
the
packets
can
be
done
within
the
endpoint,
perhaps
but
on
either
side
of
the
actual
ip
session
itself.
C
C
D
D
A
A
B
J
Okay,
can
you
hear
me?
Yes,
all
right,
hello,
everyone,
so
I
want
to
bring
up
a
proposal
that
I've
been
talking
about
with
david
and
some
others
about
how
to
further
optimize
connect,
udp
approaches
and
mask
in
general
for
cases
where
we
are
proxying,
quick
through
quick
and
as
you
see
here
on
the
slide,
this
is
you
know
when
we're
talking
about
quick
all
the
way
down,
so
it
could
be
quick
through
quick
through
quick.
Some
people
brought
up
earlier.
You
know
they're
cases
of
multi-hop
forward
proxies
things
like
what
torah
does.
J
This
is
the
kind
of
thing
we're
interested
in
here.
I
do
not
have
a
draft
yet
published
for
this.
We
are
working
on
that,
but
sometimes
our
submission
process
is
slow,
but
thank
you
for
taking
the
time
to
listen
to
this
anyway.
Next
slide,
please
all
right.
So,
as
you
already
heard
about
the
connect
udp
protocol
proposal
allows
tunneling
of
arbitrary
udp
packets
within
h2
or
h3,
particularly
it's
optimized
for
h3,
where
we
can
do
datagram
frames.
J
This
is
good,
but
when
we
are
putting
quick
packets
through
this
quick
proxy,
this
is
adding
extra
encapsulation
and
encryption
for
these
proxied
quick
flows
and
that
extra
encapsulation
encryption
may
be
exactly
what
we
want.
If
we
are
thinking
of
this
as
a
vpn,
and
we
you
know
want
to
make
sure
that
people
looking
at
the
outside
part
of
the
tunnel
cannot
see
what's
going
on
within
at
all
or
at
least
see
any
of
those
packet
signatures,
but
once
we
do
have
a
fully
end
to
end
encrypted
quick
connection.
J
J
J
J
This
kind
of
optimization
would
apply
note
that
it
doesn't
do
anything
for
cases
in
which
the
end
target
is
something
that
is
non-quick
udp
or
it's
tcp.
That
makes
no
difference
here
next
slide,
but
I
think
the
case
that
is
particularly
interesting
for
optimizing
specifically
for
quick
with
and
quick,
is
when
we
have
multiple
proxy
hops,
because
in
this
case,
if
we
are
guaranteed
that
we
are
going
through
two
mask
proxies
that
we
know
about
or
two
or
more
best
proxies.
J
J
So
in
the
proposal
just
calling
connect
quick
here,
we
can
have
the
larger
discussion
about
what
different
methods
are.
There
would
be
two
different
ways
of
sending
quick
packets.
One
is
what
I'd
be
calling
tunneled,
and
this
is
when
the
packets
between
the
client
and
the
target
at
the
end
are
encapsulated
encapsulated
within
datagram
frames
between
the
client
and
the
proxy.
J
This
is
exactly
what
connect
udp
does
today
and
in
this
proposal
I
think
it
makes
sense
to
do
that
for
any
quick,
long,
header,
packets
that
are
end
to
end
now.
The
other
new
mode
here
that
we
can
get
optimizations
for
is
forwarding
instead
of
tunneling,
and
so
in
this
case,
which
is
appropriate
for
short
header
packets.
J
J
J
J
J
So
on
the
these
are
the
different
entities.
So,
on
the
far
left
we
have
the
client,
then
we
have
two
proxies
in
the
middle
and
then
we
have
a
target
at
the
end.
So
if
I
want
to
go
through
two
proxies
every
proxy,
I
talk
to
requires
one
rtt
to
do
its
initial
setup,
so
I
can
do
its
quick
handshake
with
the
first
proxy
and
then
through
that
I
do
a
connect,
quick,
which
is
then
sending
the
long
header
packets
for
the
new
quick
connection
for
a
proxy.
J
K
J
K
Right
and
I
think
that's
a
that's
a
reasonable
requirement,
but
I
I
think
the
management
of
connection
ids
that
you've
described
here,
that
I've
seen
isn't
going
to
work
for
the
for
a
proxy
that
has
to
manage
multiple
connections.
It
looks
like
what
you
said
from
the
previous
slide
was
that
the
client
sets
connection
ids,
that
it
it
expects
the
cert
proxy
to
use.
K
J
J
C
G
So
I
guess
I
I
think
I
understand
the
the
performance
objective,
which
you
stated.
I
don't
think
I
understand
the
security
objective
and
you
should
have
said
tor
like,
but
tourists
have
extremely
specific
properties
which
are
designed
to
rent
proxy
inclusion,
and
I
don't
think
I
understand
how
this
prevents
them.
I
mean
in
order
for
price
inclusion,
you
need
to
conceal.
You
do
not
have
enough
identifiers
right,
that's
the
whole
point,
so
I
guess
I
don't
understand
what
security
properties
your
temperature
sheet
are
here.
J
Right
so
it
is
specifically
yeah:
it's
not
going
to
have
the
same
security
properties,
as
you
know,
a
full
tour
type
thing,
especially
because
if
you
were
able
to
observe
packets
on
two
sides
of
a
proxy,
you
may
see
the
same
content
going
through
now
it
is
fully
you
know
it's
just
a
quick
short
header
packet.
That's
going
through,
so
you
won't
be
able
to.
J
You
know,
get
anything
more
than
if
you
were
on
the
path
already
so
essentially
yeah
the
goal
here
is
we
want
to
get
the
ip
address,
obfuscation
going
through
multiple
hops,
but
we
do
not
necessarily
we're
not
necessarily
concerned
about
being
able
to
reconstruct
that
path.
If
you
were
able
to
observe
all
of
the
clicks.
G
Okay,
I
think
I
guess
I
guess
yeah,
I
think
it'd
be
really
helpful
to
talk
about
the
security
requirements,
because
the
the
part
of
the
reason
why
tor
has
like
multiple
hops
is
to
avoid
various
kinds
of
collusion,
and
it
seems
like
this
reopens
the
number
of
kinds
of
collusion,
and
so
I
think,
as
usual,
my
question
is:
what
was
your
threat
model?
So
you
could
start
with
that?
Yeah.
J
Yeah,
that's
right.
The
what
it's
trying
to
point
out
is
there
are.
There
is
a
possible
mode
of
running
connect,
udp
that
has
this
optimization
and
we
need
to
determine
when
that's
appropriate,
but
if
that
is
appropriate,
I
think
we
should
have
the
ability
to
do
this
type
of
thing.
Rather
than
saying
all
quick
proxies
are
going
to
have
this
extra
tunneling
overhead.
J
So
when
we
want
to
open
up-
let's
say
an
end-to-end
tcp
connection
through
two
hops
of
mass
proxies,
the
first
hop
just
forwards:
the
short
header
packet
through
the
first
proxy.
It
merely
forwards
that
that
one
then
can
include
the
actual
connect
requests
and
then
the
overall
connection
can
just
be
a
two
rtt
thing
and
next
slide,
and
then
this
is
even
more
efficient
when
we're
doing
end-to-end
quick.
J
J
So
the
way
that
I've
been
talking
about
this
here
and
have
worked
on
writing
things
up
is
to
say
that
it's
a
connect,
quick
method.
As
david
mentioned
earlier,
it
may
be
possible
to
merge
these
types
of
things,
so
maybe
not
to
have
a
fully
extensible
connect
x,
but
at
least
have
options
that
we
can
negotiate
in
connect
udp
now.
One
of
the
interesting
things
here
is
this:
is
this
kind
of
capability
of
being
able
to
forward
packets
really
really
relies
on
having
a
proxy
that
is
h3
capable?
That
is
quick.
J
This
will
not
work
if
I
am
falling
back
to
h2.
So
one
of
the
requirements
that
this
puts
back
on
the
connect
protocol
is
that
there
is
some
way
to
negotiate
this
capability
with
the
server
or
at
least
know
that
it's
not
supported
and
be
able
to
fall
back
to
a
simple
datagram,
encapsulation
mode.
Next
slide.
J
I
think
there's
also,
as
echo
is
mentioning
we
need
to
look
at
the
security
properties
and
beyond
kind
of
the
collusion
protection.
You
also
need
to
make
sure
that,
when
you're
forwarding
that
you're
not
vulnerable
to
attacks
of
just
replaying
forwarding,
replay
packets
and
that's
the
end
of
my
slides
so.
A
C
K
J
K
C
Personally,
I
would
lean
toward
basically
emphasizing
that
you
know
there's
work
going
on
right
now
in
int
area
to
specify
a
sock
six,
which
is,
I
know,
you're
well
aware
of
that.
I
think
that
this
might
be
better
suited
for
for
that
line
of
work,
where
it's
clear
that
we're
not
trying
to
maintain
some
sort
of
http
or
https
like
security
guarantee.
J
C
A
E
So
this
is
transport
considerations
for
ibm,
udp
proxy,
it
probably
should
say
or
in
tunneling,
because
but
and
there's
a
draft
associated
this
I've
managed
to
forget
to
put
it
on
these
slides,
but
there's
a
draft
in
the
under
the
mask
working
group,
so
you
can
read
if
you
haven't
read
it
already.
I
have
my
courses
on
there.
E
E
So
I
mean
this
is
a
picture
of,
whereas
look
how
I
look
and
on
http
connect
from
some
sort
of
perspective.
It's
that
it's
an
end
to
end
byte
stream,
semantics
in
this
case
utilized
by,
for
example,
tls
to
reach
from
the
client
to
its
target
and
and
you
have
back-to-back
tcp
sessions
on
top
of
etc,
and
that
has
the
effect
now
that
each
of
these
tcp
sessions
they
really
consume,
ecn,
bits,
etc.
E
They
consume
icmp
and
all
these
things,
all
the
network
to
end
point
signaling
that
could
happen
is
consumed
by
that
connection
so
and
another
relevant
aspect,
but
we
don't
sticky,
but
it's
like
with
tcp
and
other
connection
oriented
protocols.
We
usually
can
only
have
one
single
forwarding,
behavior
cost
level
behavior
on
that
flow.
E
E
You
also
have
the
endpoint
to
network
things
like
these
deep
circle
points.
We
also
need
to
consider
here
a
bit.
So
that's
the
kind
of
state
here,
and
we
also
coming
from
a
point
where,
with
proxima,
we
are
assuming
that
we're
actually
having
the
proxy
generate
the
header
so
that
you,
the
ip
udp
on
the
right
side
picture
here,
would
be
created
by
the
proxy
rather
than
being
tunneled
so,
but
this
consideration
would
also
apply
to
tunneling
if
you
try
to
do
any
type
of
compression
of
those
headers.
E
We
talk
about
the
three
tuples
primarily,
and
you
also
have
this:
okay,
we're
going
to
aggregate
multiple
flows
inside
a
single,
quick
connection
between
the
client
and
the
proxy,
and
you
will
have
some
signaling
flow
tests
that
for
flow
establishment
and
potentially
asynchronous
events,
which
will
show
that
it's
probably
quite
needed
for
supporting
this
functionality.
If
you're
gonna
have
comparable
to
ip
udp
end
to
end.
So
next
slide.
E
E
The
yellow
fields
are
things
that
are
per
packet
and
I
need
to
be
set,
but
I
mean,
for
example,
the
protocol
field
in
ipv4,
if
you're
using
ipudp
proxy,
then
you
know
that
this
is
fixed,
it's
going
to
say
udp
here
and
not
nothing
else,
but
if
you
have
ib
processing,
it's
going
to
be
whatever
apple,
a
protocol
that
you
use
on
top
of
the
type
epoxy
you
need
per
packet.
Indication
of
that
next
and
the
same
here
is
ipv6
headers
very
similar.
E
E
Yeah
the
so,
let's
take
this
type
of
service.
Dcn
field
is
one
of
these
that
we
need
to
consider
if
you're
going
to
support,
ecn,
non-support
could
be
possibility
of,
say,
okay,
specify
that
the
proxy
sets
not
dct,
but
if
you
can
have
ecm
support
which
we
worked
hard
to
get
into
quick,
for
example,
and
it's
it's
slowly
happening,
etc
and
ecm
transparency
in
the
network
is
good,
and
this
would
actually
destroy
that
tsp
in
mask
if
we
don't
provide
functionality
and
but
we
actually
have
two
different
paths
so
for
path.
E
One
ecn
is
handled
by
that
local,
quick
connection
that
we're
tunneling
over,
so
any
ecn
marks
or
usbs
ecn
here
would
be
negotiated
between
the
the
lower
end
tunnel
used,
quick
stack
and
then
we'll
figure
out.
Then
it
would
react
to
the
c
marks
by
reducing
its
congesting
window,
but
to
support
ecn
on
path
2.
E
We
actually
have
to
both
have
signaling
for
setting
what
ecm,
marking
obesity
01
should
go
out
on
from
the
server
towards
the
target
and
read
in
what's
coming
in
from
packets,
from
the
target
towards
the
back
towards
the
client
for
the
proxy
and
propagate
that
information
back
to
it.
So
it
can
provide
it
up
to
that
player.
Protocol
quick
in
this
case,
this
is
kind
of
the
base
functionality
would
require
for
getting
ecn
to
work
and
skip
two
slides
forward.
I
will
skip.
E
E
E
And
you
also
may
have
some
applications,
proxied
orders,
etc.
That
requires
saying
no.
I
need
ip
fragmentation
because
that's
the
only
fragmentation
mechanism-
I
have
it's,
maybe
not
works
great,
but
in
certain
cases
you
can
actually
use
it
even
etc.
So
it's
it's
a
trade-off
here
what
we
need,
but
I
think
we
need
something.
E
You
also
have
the
other
aspect
of
this,
which
is
the
mdu
in
this
system
in
mask,
serve
and
so
the
mask
tunnel
between
the
item
proxy.
If
you're
using
stream,
you
could
actually
send
up
to
64k
large
ip
packets
across
this
indian
stream,
if
you're,
using
datagrams,
you're,
basically
restricted
to
the
path.
Mq
minus
the
overhead
that
the
quick
tunnel
adds
and
you
need
to
be
able
to
indicate
this
toward
a
top
layer
application.
E
So
it
knows
what's
happening
here
about
what
the
mcu
that
can
expect
and
that's
also
in
the
on
the
proxy
external
interface.
You
also
have
an
mtu
which
you
need
to
consider
so
and
then
basically
minimal
between
etc.
So
that's
need
propagation,
and
then
we
have
that,
as
already
mentioned,
the
control
over
the
don
fragment
bit
from
the
proxy
towards
the
target
and
and
it
might
be
per
packet
or
it
might
be
a
default
value
that
should
be
followed.
E
This
is
really
a
question
about
ip
options.
Extension
center.
I
think
it's
so
far.
The
existing
extension
center
seems
to
be
mostly
things
that
the
proxy
would,
if
it
would
use,
be
added
by
this
proxy
on
the
path
to
by
itself.
On
the
os
level,
however,
network
tokens
here
is,
which
is
gonna,
be
presented
more
inside
this
guest
this
week
it
say,
trace
one
of
these
cases
where
it
might
actually
be
the
client
that
needs
to
provide
data
to
a
proxy
that
need,
gets
added
to
2d
and
hop
by
hop
option.
E
That's
added
in
ipv6
datagram
going
out
over
path,
and
then
you
would
need
an
extension,
so
at
least
capability
extending
for
this,
for
the
future
is
might
be
required,
and
it's
just
something
you
should
discuss
if
there's
people
think
of
other
options
or
things
there
please
come
to,
and
I
think
it's
important
to
discuss
this,
but
for
the
moment
I
think
we
can
live
without
the
mechanisms.
As
long
as
we
have
a
path
for
extending
for
this
in
the
future.
E
E
Yeah
we
can
skip
this.
This
is
very
specific
case,
so
go
forward.
The
udp
header
is
fairly
straightforward.
It's
mostly
flow
static
when
you
have
udp
and
the
length
field
is,
and
the
udp
options
is
really
the
only
kind
of
special
cases,
because
normally
you
can
derive
the
udp
length
from
the
ip
length
because
you're
full
you
assume,
fold
the
packets,
but
with
udp
options.
E
You
actually
use
the
difference
in
these
to
signal
that
the
udp
options
is
present,
so
you
need
to
both
be
able
to
track
if
there's
potential,
that
this
udp
options
area
is
present,
and
how
do
you
convey
them
and
just
which
options
do
you
need
to
propagate
from
the
proxy
back
to
the
client
or
have
the
client
provide
data
for
to
be
added
to
the
options
area?
So
that's
the
future
at
least
the
future
extension
capability
that's
needed.
So
next.
E
Icmp
is
another
thing
which
I
think
is
quite
important
and
relevant
here.
It's
it's
and
the
problems
here
I
think
with
icmp
is
that
it
provides
a
network
to
input
signal
that
can
improve
the
performance
of
the
apple,
a
protocol,
the
end-to-end
flow
here,
but
with
package,
a
big
message
or
or
directly
noticing
that
your
destination
is
unreachable
rather
than
timing
out,
but
so,
but
able
to
get
that
function.
E
You're
getting
xmp
message
back
to
the
client
to
the
proxy
based
on
packets
that
go
towards
the
target
and
they
are
coming
from
the
potentially
most
likely
from
the
routers
on
the
path
with
the
source
status.
You
don't
know
so
that
comes
back
to
you
need
have
the
proxy
need
to
look
into
this
match
it
with
outgoing
packet
flows
and
then
propagate
the
information
from
the
smp
message
back
to
the
client
to
enable
this
functionality.
E
A
E
M
Hi
alex
ranhovsky
here
I
have
a
question
about
a
bunch
of
these
features
so
in
in
the
connect
udp
world,
I'm
sort
of
assuming
that
the
direct
datagram
would
be
written
directly
into
the
mouse
connection.
It
wouldn't
be
going
through
an
os
network
stack
is
the
expectation
that
user
space
will
be
doing
things
like
implementing
ecn
and
dscp,
and
all
these
other
things
entirely
itself,
which
are
you
talking
about
the
mask
server
now
or
what's
what.
M
E
E
B
E
So
I
at
the
mean
I
mean
I
I
I
think,
there's
there's
certain
things
which
clearly
is
difficult
to
implement,
but
I
think
the
protocol
needs
to
have
potential
support
and
extensible,
and
even
if
you're
saying
in
certain
cases,
you're
gonna
have
to
know
what
default
values
etc.
What
you're
putting
in
so
but-
and
we
need
to
consider
what
that
means,
and
I
think
we
need
to
discuss
in
such
cases.
E
How
important
is
these
particular
features?
I
have
a
certain
view
of
which
is
more
relevant
and
I
think,
for
example,
ucn
is
one
of
these.
That's
we
started
to
see
great
deployment
of
I've
been
seeing
that
great
functionality,
for
we
have
quick,
which
is
quick
over
quick,
I
think,
is
one
or
quick
over
mask
is
going
to
be
fairly
common
and
and
throwing
away
this
functionality.
But
there
are
certain
aspects
here
which
is
basically
has
to
do
with
what
needs,
for
example,
around
fragmentation
cetera.
E
It's
really
is
basic
datagram
and
be
able
to
indicate
it
to
get
the
right
functionality
working
at
also,
so
I
think,
there's
a
base
set
which
is
needed
for
having
a
reasonable
datagram
service
that
you
would
expect
from
an
ip
udp.
If
you
were
doing
it
end
to
end
and
then
there's
things
that
would
be
extensible.
B
Next,
that
makes
sense,
I
think,
where
I
stand
is
that
today,
ecn
doesn't
always
get
through
the
internet
and
neither
does
icmp
and
so
like
mtu
discovery
and
condition
control
have
to
survive
without
them.
So
I
think
we
can
have
connect
udp
survive
without
them,
but
happy
to
take
that
to
the
list,
because
I
think.
E
Yeah,
that's
I
mean
that's
a
good
example,
but
I
think,
for
example,
setting
the
don
fragment
bit
is
actually
one
of
the
critical
things,
because
otherwise
you
don't
know
that
your
upper
lid
path,
m2
discovery,
works
or
not,
because
you
might
get
hyper
fragmentation
on
this
path
and
you
think
you're
not
getting
hyper
fragmentation.
So.
N
E
Yeah-
and
I
mean
the
alternative
would
be
to
tunnel
the
whole
ipudp
protocols
and
let
the
client
deal
with
the
whole
protocol
stack.
It
would
increase
the
overhead,
so
I
think
that's
the
another
way
of
actually
leaving
it
to
the
client,
how
much
it
implements
of
it,
but
that
would
increase
the
overhead
so.