►
From YouTube: IETF112-IPSECME-20211108-1200
Description
IPSECME meeting session at IETF112
2021/11/08 1200
https://datatracker.ietf.org/meeting/112/proceedings/
B
C
B
Need
some
note
takers,
preferably
too,
I
have
already
you
know,
filled
in
the
basic
notes
in
the
headstock
or
etherpad
used
to
be
eater,
but
so
you
could
go
there
and
start
just
editing
and
adding
what
happens
really
in
the
discussion.
No
need
to
take
any
of
the
presentations,
so
anybody
willing
to
be
taking
notes.
A
B
Yeah,
I
was
just
looking
for
him
if
he's
there,
he
knew
that
all
right,
so
thanks
paul
and
if
somebody
can
help,
because
I
guess
paul
is
probably
going
to
be
talking
at
some
point.
He
usually
is
so
helpful
he's
talking.
Also
it
would
be
good.
I
think
the
meter
call
link
and
the
chopper
link
and
notes
links
are
still
actually
no.
The
probably
the
notes
links
are
probably
wrong
because
it
should
be
now
in
the
notes.
Df.Org.
B
B
We
now
have
enough
time
this
time
compared
to
last
time,
so
we
we
are
going
to
be
staying
on
that
topic
until
we
are
done
with
it.
So
we
can
get
the
documents
out
and
then
we
have
five
or
ten
minutes
about
the
quantum
breast.
I
question
two
and
big
keys
and
then
we
have
two
presentations
from
valerie
which
are
actually
most
repeats
from
the
previous
ones.
B
The
group
key
management
using
I
question
two
and
the
announcing
support
for
all
indigenous
in
like
version
two
and
those
both
are
r
and
charter,
and
they
are
items
that
we
haven't
been
discussing
for
some
time
and
we
should
be
getting
working
on
those
two
any
comments
on
that
end
up.
B
If
not
we
go
forward
so
the
first
one
is
the
document
status.
So
we
have
one
document:
ip
version,
2
immediate-
that
is
intermediate-
that
is
now
in
the
publication,
requested
state
waiting
for
the
80s
to
pick
it
up,
and
then
we
have
the
iptfs
group
which
hopefully
go.
Actually,
I
think
the
first
two
name
of
the
crafts
are
wrong
because
I
think
they
are
now
ietf
ipsec
me.
B
Those
three
first
documents
are
should
be
ready
to
go
to
the
publication
requested
almost
immediately
after
this
itf
finishes,
or
actually
I
think
the
young
and
big
one
still
needs
us
several
flight
write-ups,
but
for
the
iptfs
main
document
should
be
ready
immediately
when
we
get
this
final
issues
resolved
that
we
have
a
multiple
key
exchanges,
which
I
think
should
be
ready,
also
and
algorithms
acquisition
one
algorithms
to
historic
is
should
be
also
getting
ready
and
labeled
ipsec
paul
was
saying
that
he
doesn't
have
any
update
for
those.
B
C
I
just
want
to
say
that
rfc
22,
sorry
82-29
b's,
seems
to
be
ready
for
last
call.
The
last
revision
is
didn't
change,
anything
and
tommy,
and
I
think
that
the
dropped
is
ready
for
last
goal,
so
it's
quite
stable
in
nature.
B
Yeah
my
understanding
is
both
of
these
are
actually
should
be
ready,
for
you
know
to
go
to
the
out
from
the
working
group
after
the
itf
quite
soon.
Oh,
actually,
the
idea
version
2
probably
needs
more
reviews
still,
but
anyway,
okay,
then
we
have
oh,
actually
I
have
the
more
more
text
about
the
group.
Key
management
need
more
reviews:
the
announcement
supporter
authentication
animators
in
ikever's
two.
We
have
a
presentation
about
that
and
I
think
it
should
be
ready
for
the
working
group.
B
B
All
right
so
anything
else
about
the
current
documents
we
have
we
have
couple
of.
Where
is
it
here?
We
have
a
couple
of
documents
that
are
not
the
working
group
documents
that
are
still
in
the
list
if
they
have
compression
and
that
kind
of
things,
but
we
haven't
heard
anything
about
those.
So
so,
if
there's
people
interested
to
get
those
one
already,
they
should
be
start
discussing
the
working
group
list
and
and
start
processing
progressing.
Those.
A
B
Yeah,
probably
we
should
be
doing
that.
I
think
that's
also
ready,
so
we
should
actually
probably
start
that
add
that
to
the
list
and
and
add
that
and
the
announcing
our
supported
altercation
methods
in
ikers
2
to
the
working
group
adoptions.
B
D
Hi
yeah,
that
sounds
good.
Okay,
the
bars
are
moving,
so
I
think
you
guys
can
hear
me
all
right
so
yeah.
This
is
a
presentation
on
the
status
of
iptfs
next
slide.
Please
2021
recap:
in
february
we
did
a
we
completed.
The
working
group
last
call
we
received
some
post
working
class
call
comments.
We
updated
the
document
to
o8.
D
This
was
from
valerie
wanting
to
change
the
language
kind
of
like
everywhere,
get
to
get
away
from
iptfs
and
talk
more
to
the
to
you
know
to
talk
about
the
encapsulation
as
ag
frag,
because
it
you
know
he
felt
it
could
be
reused
elsewhere.
In
april
we
submitted
the
draft
write-up
july.
We
I
did
a
update
clarifying.
D
We
had
had
one
change
earlier
to
talk
about
how
the
replay
and
reorder
windows
could
be
made
the
same,
because
if
your
reorder
window
dropped
packets,
who
cares
or
or
like
vice
versa,
but
we
needed
to
update
that
same
text
again,
because
people
might
want
larger
replay
attack
windows
because
they're
very
cheap
right.
You
can
have
2k
entries
in
there
and
it's
not
a
lot
of
memory
to
keep
track
of
that.
But
your
reorder
window
generally,
you
want
to
be
small.
D
I
think
we've
kind
of
reinforced
that
through
multiple
updates,
that
the
reorder
window
needs
to
be
small
but
yeah
to
the
next
bullet
item
in
september
we
added-
and
I
I
think
this
was
probably
the
most
important
change.
In
my
opinion.
We
weren't-
you
know
we
before
we
talked
about
you.
Could
you
could
use
a
drop
timer
if
you
wanted
and
based
on
tarot's
sort
of
analysis?
D
You
really
don't
want.
You
know
if
you
have
a
slow,
sending
link
even
a
medium,
sending
a
medium
speed,
link
or
whatever.
If
you
have,
if
you're
just
using
the
reorder
window
to
drop
packets,
then
the
sizer
reorder
window
determines
the
amount
of
time
that
it
takes
to
detect
a
lost
packet.
So
you
know,
a
lost
packet
could
then
incur
a
large
delay
in
downstream
packets,
inner
packet
delivery.
D
D
So
yeah
so
the
drop
time
we
ended.
We
instead
of
saying
talking
about
the
drop
timer
hand
waving
at
it.
We
actually
brought
a
mentioned
it
up
front
and
furthermore,
recommended
its
use.
You
know
this
is
it's
important,
it's
important
to
put
a
drop
timer
in
because
it's
it
will
then
directly
affect
how
long
of
a
delay
you're
willing
to
take
from
a
dropped
packet,
yeah,
and
so
that
you
know
the
the
end
result
of
this.
Is
that
you
just
don't
use
reorder
window
as
a
way
to
detect
packet
loss?
D
You
use
a
drop
timer,
I
you
know
I've
implemented
this
and
you
don't
actually
have
to
use
a
timer
right
if
you're
using
the
you
know
the
way
the
document
talks
about
constant
sun
rate.
You
can
you
could
just
have
your
drop
timer,
be
one
packet
gap
right,
so
you
literally
just
you-
can
have
your
window
sitting
there
and
if
you
get
one
out
of
order,
you
consider
any
previous
drop
and
that
implements
a
drop
timer
of
one
gap
interval.
So
that's
how
we
chose
to
implement
it,
but
you
can
do
it.
D
You
can
use
a
timer
as
well
to
do
even
shorter,
shorter
delays.
I
I
felt
like
this
was
what
we
needed
to
do.
I
thought
this
handled
everything
tarot
didn't
agree,
and
so
we
asked
for
an
update.
Eventually,
I
just
took
a
guess
at
what
would
sort
of
satisfy
tarot.
I
think
I
got
close,
but
I'm
not
no
cigar,
so
11
had
a
small
well
and
I'll.
D
We'll
highlight
why,
in
the
next
few
slides
I
put
in
some
text
which
we'll
go
over
and
taro
made
a
suggestion,
changing
a
should
in
may,
and
I
think
that's
what
this
discussion
is
really
going
to
be
about
next
slide.
Please.
D
Right
so
the
last
issue
to
resolve
would
be
the
difference
between
what's
in
11,
I
mean
we're
happy
to
I'm
happy
to
accept
the
the
text
as
terrell
put
it
with,
but
I'd
prefer
to
see
it.
The
should
and
maze
change
primarily
to
go
back
to
what
11
says
you
know,
but
using
tarot's
text
it's
a
little
bit
more
verbose
and
descriptive.
D
So
let's
go
to
the
next
slide,
so
in
11
this
is
the
text
we
added,
we
say
as
an
optimal
optimization.
The
receiver
may
transmit
any
fully
formed
inner
packets
prior
to
reordering
the
outer
packets.
This
just
means
that
if
I
have
a
full
packet,
no
matter
what
order
it
comes
in
full
inner
packet,
I
send
it
along.
D
We
had
this
as
a
may,
so
the
next
slide
shows
tarot's
suggestion.
This
is
the
proposed
text
from
tarot.
It
starts
off
with
that
concept
and
it.
Furthermore,
it's
recommends
it.
It
says
the
receiver
should
process
the
payloads
and
send
and
as
many
incoming
packets
from
it
as
possible.
D
That's
one
thing
worth
pointing
out:
if
we
don't
have
reordering,
then
both
of
these
no
matter
what
we
pick
it
looks
the
same,
but
if
we
do
have
reordering,
then
tarots
will
send
some
packets
out
of
order
to
get
them
downstream,
faster
and
then
taro.
I
don't
know
what
the
next
slide
is.
Do
you
want
the
yeah?
So
let
yeah?
Let's
do
your
slides.
Let's
talk
to
your
stuff,
all
right.
B
Yes,
here,
here's
my
so
I
made
this
kind
of
slide
set
to
try
to
explain
it
a
bit
a
bit
better
what
this
is,
and
so
so
this
is
the
original
text
or
this
the
text.
B
Actually,
this
is
the
original
text
and
one
of
the
things
their
problem
there
is
that
there's
a
lot
of
places
very
attached
way,
talking
implying
that
you
do
like
the
last
paragraph,
for
example,
there
was
not
clearly
saying
that
it
is
true
or
may
or
what
something,
and
it
was
like,
not
really
going
with
the
one
where
we
say
that
of
the
optimal
of
optimization
when
you
still
say
that
we
process
the
in
order
and
in
the
inside.
B
That's
why
I
wanted
to
rewrite
most
of
these
texts
to
be
so
that
we
actually
have
two
different
options
so
so,
like
it
says
it
implies,
it
doesn't
explicitly
say
it,
but
it
implies
it
in
several
places,
which
was
the
original
problem
in
the
in
the
may
or
in
the
spring
time
was
that
I
didn't
really
understand
that,
but
actually
requiring
that
until
when
I
finally
understand
that
from
the
discussion
with
other
people
that
actually
does
require
that
all
the
time-
and
it
takes
this
written
in
such
way
and
and
so
so,
if
you
check
out
to
check
out
the
normal
view
normal
flow
when
we
have
a
pocket
coming
in
so
the
o1,
the
blue
one,
there
is
the
this
is
like
from
the
responder
point
of
view.
B
So
this
all
the
whole
text
is
in
the
responder.
You
know
processing
time,
so
we
have
one
with
this
outer
pocket,
which
has
two
and
half
buckets
in.
So
when
we
get
that
one,
we
can
immediately
send
out
the
two
inner
packets
that
are
complete.
B
We
can't
send,
of
course,
the
third
one
because
that's
not
complete,
then
we
get
the
next
frame
and
then
we
can
send
the
third
and
fourth
pocket
out
and
and
then
we
get
the
you
know.
Fourth,
third
outer
pocket.
We
can
again
say
that
this
is.
This
is
like
what
it
happens
so
so
it
sends
immediately
completely
fully
packets
out,
and
this
is
fine
everything
works.
Then
we
come
to
the
if
we
have
any
kind
of
reordering
happening
there
and
now
as
it's
in
in
order.
B
This
is
actually
not
the
reorder,
isn't
actually
not
that
big
issue.
So
we
have
an
og
and
oh
two
are
changing
places,
so
we
have
an
o3
first
and
the
o2
in
order.
We
have
to
wait
until
we
get
to
o2
and
then
we
can
process
the
inner
three
four
and
five
we
sent
them
all
back
to
back
when
we
finally
get
this
o2.
B
If
we
do
this
in
in
immediate
way
immediately,
when
we
get
this
o3,
we
can
send
the
i5
out,
because
it's
it's
already,
we
have
it
completely
and
then,
when
we
get
to
o2,
we
send
out
the
i3
and
i4
the
difference.
There
is
mostly
comes
when,
when
we
have
a
lost
pockets
or
if
we
have
non-constant
bit
rate
sending
because
as
valerie
was
saying,
we
actually
want
to
be
able
to
do
this
kind
of
things.
You
know
with
non-constant
bit
rate
and
and
the
drop
timer
only
starts
when
we
get
the
o2.
B
B
We
continue
waiting
for
it
in
o4
we.
Finally,
we
realized
that.
Okay,
if
we
have
a
reorder
winter
of
two
or
we
have
a
drop
timer
of
that
long
in
o4,
we
actually
realized
that
okay,
that
was
actually
missing.
So
we
sent
an
o5
inner,
five
and
six
and
so
on
out
all
the
back
to
back.
The
problem
is
that
if
the
old
tree
doesn't,
if
that
comes
much
later
like
we
are
not
sending
contrast,
constant
rate,
we
are
not
really.
You
know.
B
Oh
sorry,
actually,
oh
four
comes
out,
so
so
it
actually
or
if
you
have
a
longer
like
like
we
have
here
here-
is
a
longer.
If
you
have
a
replay
window
of
reorder
window
of
three,
we
have
to
keep
all
of
those
o3
and
o4
and
o5
in
memory
until
we
get
the
enough
or
enough
time
from
from
last
time,
and
so
we
actually
use
much
more
memory
and
we
cause
delay
and
we
have
you
know,
already
lost
frame.
So
so
it
doesn't
really
yeah
go
ahead.
Yeah.
D
D
E
D
B
B
B
D
B
D
B
D
If
I
have
100
gig
tunnel,
then
one
packet
gap
is
tiny
and
that's
still
appropriate.
If
I
have
a
one
megabyte
tunnel,
then
you
know,
then
a
a
hundred
nanosecond
gap
you
know,
is
not
appropriate
for
one
megabyte
one
mega
tunnel
right.
The
delay
should
be
much
bigger.
In
our
case,
it's
exactly
scales
to
one
packet
gap,
but
you
know
people
it
determines.
You
know,
that's
a
that's
a
knob
and
it's
an
obvious.
D
B
My
my
understanding
is
that
if
you
have
an
reordering
happening,
real
reordering,
that
usually
means
that
you
have
two
parts
that
the
network,
packets,
didn't
take
the
same
path.
If
they
take
the
same
path,
there
should
be
no
reordering
happening.
The
only
way
you
can
actually
have
a
you
know
reordering
is
when
you
have
one
pocket,
goes
through
different
transit
network
than
the
other
one,
and
in
that
case
the
delay
caused
by
that
might
be
orders
of
magnitude.
Bigger
than
what
is
you
know,
your
your
you
know,
100
frames
per
second
interval.
A
D
B
D
Milliseconds,
yes,
and-
and
we
speak
to
that
in
the
later
slides
in
the
deck
right,
but
the
re,
but
that's
why?
Yes,
that's
why
you
don't
want
reordering.
You
don't
put
a
single.
You
know:
we've
designed
the
internet
routers,
I
I'm
a
router
guy
right.
We've
spent
a
huge
amount
of
money,
research
and
whatnot,
I'm
not
reordering
flows
right
because
because
tcp
will
not
accept
its
packets,
where
you
have
two
three
four
five
one:
six,
seven,
eight
nine
two.
D
D
B
That's
that's.
Why
that's
why
we
have
that's
why
we
are.
We
are
working
very,
very
fine
with
trying
to
get
you
know
things
like
selective
acts
and
so
on
working
so
in
case
that
we
actually
for
for
the
for
the
you
know
the
responder
point
of
view.
It's
actually
no
difference
whether
actually
one
was
re-transmitted
or
if
one
was
actually
you
know
just
delayed
because
of
the
reordering.
B
D
B
No
half
a
second
delay
for
pockets
randomly
appearing
actually
one
second
delay
for
one
link
I
invite
in
my
in
my
house.
I
see
this
very
commonly
that
every
every
you
know
10
seconds
or
something
I
haven't
suddenly.
I
have
a
one
second
longer
delay
on
one
bucket
than
than
in
in
other
packets
and.
B
If
I
have
two
different
links
going
out,
they
are
going
to
be
using
there's
going
to
be
one
second
or
half
a
second
of
delay
when
will
actually
arrives,
if
I
would
have
multi
holdings
so.
D
B
D
E
B
But
but
the
difference
is
that,
if
we
actually,
you
know,
don't
use
a
drop
driver,
but
instead
of
when
we
actually
have
it,
you
know
when
we
received
the
all
three
packets
and
we
we
noticed
that.
Okay,
we
have
a
fully
full
pocket
of
i5
there.
We
can
set
it
out
immediately.
We
only
still
need
we
need
still
need
to.
You
know
buffer
at
the
end
of
or
beginning
of
the
i3
from
the
o1,
because
that's
we
haven't
seen
still
seen
that
you
know
the
end
of
the
i3.
B
B
We
have
very
limited
limited
buffers
in
the
memory
because
we
only
have
to
buffer
those
fragments
that
are
part
of
the
missing
frame.
We
don't
have
to
buffer
everything.
We
only
have
to
buffer
that
one
piece
that
was
actually
missing
or
or
that
the
pieces
of
that
pocket.
That
is
missing,
so
we
had
you
know
for
each
frame
that
we
are
actually
missing.
B
We
actually
only
need
to
buffer
a
very
small
amount
of
time
and
we
are
not
tied
to
the
fact
that
oh,
we
are
sending
constant
fact,
of
course,
that
you
know
these,
because
in
some
cases
it
actually
yeah
yeah,
we
might
still
have
to
have
a
drop
time,
timer
and
so
on.
The
other
thing
is
that
there
is,
you
know
the
ipsec
does
not
provide
in
order
delivery.
B
That's
not
guaranteed
if
we
turn
off
ipsec
in
in,
for
example,
in
this
reordering
case,
we
are
going
to
get
these
packets
in
in
wrong
order.
If
we
have
a
reordering
happening,
I
don't
think
it's
ipsec
point
of
or
oh
sorry,
iptfs
person
of
the
ipsec
should
be
fixing
that
reordering
in
general
case.
If
we
have
an
ipsec
without
iptfs,
we
can't
fix
the
reordering,
because
we
don't
know
it
happened.
We
have
no
idea
of
knowing
it
whether
it
happened
or
not.
Sequels
numbers
doesn't
allow
us
to
do
that.
You
know.
B
B
So
that's
why
I
think
it's
important.
We
don't
actually
try
to
fix
something
that
wasn't
problem
before.
E
D
Ip
ipsec
also
doesn't
let
you
aggregate
20,
40
byte
packets,
in
a
frame
either
right
I
mean
we're.
D
D
Right,
yeah
and
part
of
that
is,
is
you
know,
part
it's
just
all
part
of
a
package
the
ordering
drops
out
of
that
and,
as
you
said,
on
slide
14
you
I
want
to
just
point
out
when
you
were
at
slide
14,
you
said:
if
we
don't
have
a
drop
timer,
we
are
recommending
a
drop
timer.
We
are
recommending
it.
So
it's
it's!
So
just
keep
that
in
mind.
You
know
as
well
about
this.
D
B
So
you're
effecting
getting
rid
of
the
reordering
window
in
in
in
number
of
pockets.
You
are
only
using
it
as
an
you
know,
number
of
timer,
but
I
saying
that
define
your.
D
That's
either
this
quote
I'll,
tell
you
why
we
use
it
for
exactly
the
case.
You
talked
about
right
when
we,
when
people
want
to
use
this
for
either
you
know
well
one
line
rate
stuff
right
where
there
there
is
no
packet
gap
or
were
they
not
doing
constant
sunbreak
like
people
that
want
to
use
it
just
for
mtu
solutions
right
where
packets
come
whenever
they
come
right.
D
That's
why
the
reorder
window
is
useful
there,
because
you're
willing
to
wait
a
little
time
to
get
out
of
order,
delivery
right,
because
I
got
pack,
it
pack
a
packet
and
then
a
big
pause.
Those
three
packets
might
arrive
out
of
order.
We
a
reorder
window
makes
sense
then,
which
that
reorder
window
will
get
it
will.
D
It
will
put
things
in
order
before
the
drop
timer
hits,
because
those
packets
are
coming
back
to
back
they're,
just
slightly
reordered
because
they
went
out
of
you
know
whatever
cues
slightly
behind
each
other,
so
the
the
reorder
window
still
makes
sense,
but
only
in
these
cases,
where
you
know
where
the
drop
timer
doesn't
fire.
So
when
you're
pointing
out
that
oh
well
now
you're
just
making
the
reorder
window
one
slot
right,
that's
only
a
constant
send
rate
right.
D
B
Okay,
so
there's
other
people
in
the
queue
let's
allow
them.
B
F
So,
let's
see
christian,
of
course,
was
talking
mostly
about
the
environment,
where
you
are
doing
the
constant
send
rate
and
so
that
your
drop
timer
has
a
fairly
natural
setting
in
terms
of
one
inter-packet
window,
and
I
know
that
turo
is
at
least
partially
considering
the
case
where
you're
not
at
the
constant
bit
rate,
and
so
you
might
not
have
this
natural
setting
with
the
drop
timer.
F
Your
first
could
still
use
one
and
the
the
right
setting
value
for
the
drop
timer
is
an
operational
parameter
that
you.
We
may
not
have
the
right
guidance
for
right
now,
but
we
could
still
say
that
you
would
want
to
use
one.
So
I
guess
one
thing.
F
To
jump
in
and
sort
of
focus,
the
discussion
was
to
make
sure
that
we
were
sort
of
considering
both
of
those
cases.
I
think
in
the
the
stuff
that
happened
after
I
joined
the
queue.
I
think
that
was
starting
to
happen
that
we're
making
sure
we
consider
both
the
constant
flow,
constant
rate
case
and
the
the
sort
of
more
generic
egg
frag
uscapes
and,
let's
see,
I
think,
also
christian
you're,
doing
a
great
job.
F
Picking
this
up
right
before
I
jumped
in
to
point
out
that
you
can
have
a
little
bit
of
a
reordering
window
that
performs
sort
of
a
separate
function
than
the
drop
timer
itself
does,
and
so
I
think
I
was
just
doing
some
notes.
As
you
finished
up
like
we
might
have
a
very
fairly
small
reorder
window
or
rear
time
interval
and
then
like
the
drop
timer
would
be
significantly
bigger
than
that.
F
I
guess,
and
so
you
would
still
have
the
ability
to
do
a
little
bit
of
reordering
fix
up
before
the
the
drop
timer
would
kick
in,
and
that's
that's
what
I
heard
you
saying
sing.
D
When
you,
in
fact
you
when
you
have
the
your
reorder
window,
can
be
big,
then
because
you're
gonna
you're
not
gonna,
wait
because
you
drop
right.
D
E
B
It
it
it
it,
no,
it
doesn't
actually
and
one
of
the
things
that's
actually
is
what
my
when
I
proposed
in
one
of
the
earlier
emails,
was
the
hybrid
mode
where,
where
we
actually
so,
we
have
a
certain
value
where
we
assume
that
we
have
a
very
short
you
know:
timer,
it's
not
a
drop
timer,
because
drop
timer
is
actually
wrong
term
because
we
are
not
dropping
the
frame.
At
that
point,
we
assume
that
the
frame
might
have
been
dropped.
B
Would
actually
imply
that
we
had
dropped
all
of
the
frames
that
were
actually
you
know
assuming
to
be
dropped
and
forget
everything
from
that.
We
don't
want
to
do
that.
We
want
to
just
say:
okay
after
this
time
we
assume
it's.
The
bracket
first
lost
the
lost
time.
Rejection
could
happen,
so
we
have
a
lost
timer.
B
We
can
keep
that,
for
you
know
much
longer
time
because
that's
very
short
amount
of
small
memory
and
then
when
we.
Finally,
if
we
ever
happen
to
get
the
o2,
then
we
can
actually
set
it
out
out
of
order
now,
because,
because
it's
outside
the
drop,
you
know
this
lost
timer,
but
inside
the
re
ordering
window.
D
Hey
taro,
can
we
move
to
back
to
my
slides
because
you
know
it.
I
think
where
benjamin
was
going.
You
know
we
have
a
solution
here
right
which
is
oh
backwards:
yeah
back!
Okay!
Back
back!
It's
right
here.
D
F
Right-
and
one
of
the
things
I
wanted
to
say
was
that
we
have
some
good
thoughts
about
this,
but
it's
also
possible
that
people
in
the
broader
itf
are
going
to
have
some
thoughts
on
this,
and
so
maybe
one
option
to
keep
in
mind
is
like
put
a
note
in
the
document.
F
We
had
a
long
discussion
about
this.
We
could
go
either
way.
You
know,
let's
get
some
feedback
as
part
of
the
last
call.
We
could.
You
know,
for
example,
specifically
call
it
out
to
the
tsv
area
directorate
review
and
say,
like
we
can,
as
a
working
group
reach,
you
know
a
tentative
conclusion
or
a
set
of
just
two
things
that
we
we
could
perhaps
be
happy
with
either
of
them
and
get
more
feedback
later
in
the
review
process.
F
D
So
the
bottom
point
says
like
make
them
both
maze
in
a
configuration
that
we're
not
locked
into
either
behavior
I
mean
if
we're
gonna,
I
I
don't
think
we
should
hold
it
up
for
a
big
long.
You
know
if
we
we're
not
locking
anybody's
behavior
out,
then
I
mean,
rather
than
just
keep
going
through
reviews
and
reviews.
Let's
just
allow
both
behaviors
and
let
the
configuration
stand
and
then
you
can
have
operational
experience
down
the
line
right
because
people
learn.
D
D
You
know
before
we
publish
a
working,
you
know
we
have
working
solutions
here,
let's
get
them
out.
I
mean
that's
how
we
do
it
in
the
routing
area
generally,
when
we
have
two
working
solutions
and
we
can't
come
to
an
agreement
on
which
one
is
better,
we
generally
throw
a
configuration
knob
at
it
and
say
you
know
let
let
operational
experience
dictate
the
correct
solution.
D
So
I
think
that's
what
the
second
option
there
does.
It
really
doesn't
lock
us
into
anything
right.
It
allows
both
behaviors
and
it
allows
people
to
you
know
pick
which
one
works
seems
to
work
best
for
them
and
eventually
we
might,
you
know,
learn
that
hey
this
one
is
always
the
better
one
or
90
of
the
time,
this
one's
the
better
one
but
yeah.
I.
C
F
Yeah,
I
always
feel
a
little
bit
uncomfortable
when
I
see
drafts
coming
through.
You
know
you
mentioned
the
routing
area,
which
does
this
a
fair
amount,
and
you
might
personally
prefer
if
we
could
pick
a
single
solution
that
we
know
we're
happy
with,
but
I
recognize
that
sometimes
we
can't-
and
I
think
I
can't
remember
actually
any
times
where
something
came
in
through
the
isg
review,
that
had
multiple
options
and
we
were
able
to
say
no,
you
don't
actually
need
all
these
options.
We
should
cut
it
down
right.
It's
a
little
bit
impressive.
D
A
H
All
right:
well,
thanks
for
letting
me
go
out
of
cue,
I
would
have
been
fine
sticking
behind
valerie,
but
thanks
I,
I
was
actually
going
to
go
back
to
a
point
that
tarot
made,
I
think,
is
really
the
critical
one.
Is
that
when
these
weird
delays
happen,
as
he
talks
about
you
know
your
experience
at
the
edge
your
protocols
are
built
today
to
recover
from
them.
What
they
are
not
always
built
to
do
is
handle
massively
out
of
order.
H
Packets
and
I've
seen
certain
transport
protocols
that
will
basically
do
a
connection
reset
when
they
get
something.
That's
too
far
out
of
window
out
too
far
delay.
Sometimes
they
think
it's
actually
some
form
of
delay
attack,
and
so
I
think
you
know
going
to
a
mechanism
where
we
experience
it
today
is
safe.
You
know,
adding
some
delay
is
something
that
the
internet
is
built
on
today.
So
that's
a
safe
approach,
adding
amplifying
reordering,
I
think,
is
a
risky
approach
for
many
transport
protocols
and
at
least
it
requires
some
good
research
exploration
experimentation.
H
We
found
one
paper
which
talked
about
tcp
having
a
really
hard
time.
We
get
two
out
of
order
and
the
because
we
have
an
amplifying
effect
with
the
reordering
because
we're
carrying
multiple
packets.
You
know
we
might
end
up
with
lots
of
acts
out
of
order.
H
You
know
a
big
chunk
of
acts
or
a
big
chunk
of
small
data
out
of
order,
and
we
just
don't
know,
what's
going
to
happen
so
from
my
perspective,
it
seems
really
risky
to
recommend
that
as
it
should,
and
I
think
we
have
to
allow
for
the
operational
experience
the
market
experience
before
going
to
a
should
for
that,
which
is
why
I
said
I
was
comfortable
with
I
could
live
with
the
maymay.
I'm
not
saying
I
actually
think
there
should
be
should
be
the
other
way,
but
I
can
live
with
a
name.
B
B
There
are,
there
are
different
flows
that
have,
because
I
mean,
if
you
have
multiple
pockets
they're
in
the
same
flow.
That
actually
means
that
your
send
rate
is
spits
too
small
or
somehow
you
are
sending,
because
I
mean
in
cases
where
you
actually
have
a
transfer
like
in
tcp.
It's
actually
since
full
frame.
It
says
big
buckets
when
you
are
sending
lots
of
data
and
then
you
have
a
sending
back-to-back.
You
know
packets
and
they
are
going
to
be
in
separate.
You
know
aggregated
frames,
so
in
that
case
actually.
H
B
H
I
mean
it
depends
whether
you're
you
know
if
you're
doing
it,
if
you're
thinking
about
a
in
the
middle
of
the
network,
you're,
probably.
H
B
B
H
Looking
at
use
cases
from
anything
up
to
you
know,
tens
of
gig
down
to
down
to
you
know
basically
office
remote
access.
Now
those
are
those
are
sort
of
the
cases
that
we've
been
considering
so.
B
The
question
is,
why
would
the
download
or
uplink
or
whatever
protocol
would
use
less
than
full
frame
packets
when
you're.
B
Rate
thing
that
we're
documenting
right:
no,
no,
we
are
talking
about
now
data
inside
the
constant
data,
constant
aggregated
frames,.
D
B
B
That's
that
but
yeah
okay.
H
So
the
the
basic
point
I
wanted
to
make
and
I'll
again
get
out
of
queue.
Is
that
the
should
the
way
you
have
it
is.
It
makes
a
very
strong
assumption
on
what
applications
can
handle,
and
I
I'm
worried
that
you
know
you're
going
to
start
breaking
things
if
you
say
should
so,
I'm
really
uncomfortable
with
going
down
an
approach
that
may
yield
a
non-functional
solution,
and
we
just
don't
know
because
we
don't
understand
the
full
scope
of
applications
out
there.
H
So
I
think
it
is
too
risky
to
use
the
should
the
way
you
have
it
phrase
it.
You
know
I
would
love
this
to
be
done
with
this
I
mean
we've
been
sitting
a
long
time
trying
to
get
this
document
out.
I
would
love
just
to
accept
it,
but
I
think
it
is
too
risky
to
take
the
approach
that
you
have
you're
recommending.
A
Okay
and
now,
despite
the
reordering,
we're
going
to
process
valerie's
input,
valerie.
A
C
Okay,
I
just
want
to
bring
attention
to
one
potential
issue,
probably
it's
obvious,
but
I
think
that
it
escaped
from
the
discussion
antero.
Can
you
please
move
to
your
slides.
C
And
okay.
G
C
Next,
oh
this
one,
okay
previews,
so
you
can
see
that
if
we
keep
an
order
of
packets,
then
packets,
i3,
i4,
i5
and
6i7
not
only
delayed,
they
are
all
sent
as
a
bunch,
and
so
this
may
cause
a
congestion,
because
if
in
in
usual
operation,
when
there's
no
delay,
there
is
no
packet
lost
out
of
packet
lost
or
loading
packets
are
sent,
internal
packets
are
sent
with
pretty
pretty
concentrate,
but
here
we
not
only
have
a
delay,
but
we
also
have
a
bunch
of
packets
sent
at
once
when
they
are
assembling
there
or
scented
ones.
C
And
this
can
this
can
cause
and
congestion.
It's
probably
a
theoretical
issue,
but
I
think
it's
not.
It
must
be
counted
well
just
want
to
bring
attention
to
this.
D
I
think
that's
a
valid
comment.
Valerie,
I
I
you
know,
I
don't
think
there's
like
you
said
it's
a
theoretical
thing.
I
think
we
have
to
look
at
and
we'll
get
an
operational
experience
as
we
get
it
out
there
right,
like
what
kind
of
burstiness
does
tfs
cause
right,
because
there's
a
certain
amount
of
burs.
If
you
do
a
constant
sun
rate
and
you're
aggregating,
a
bunch
of
packets
right,
you're
you're
only
getting
the
outer
packet
on
this
at
this
constant
rate,
but
then
you
get
maybe
five
or
ten
packets
in
a
outer
packet.
D
You
send
them
all
at
once
right
so
we'll
I
think
we
just
have.
We
haven't
seen
any
problems
with
that,
but
you
know
we're
not
the
internet
right.
So
once
we
get
this
out
there
we're
going
to
find
out.
Oh
this
doesn't
work
in
these
scenarios
or
you've
got
to
limit
things.
You
know
you
can't
you
know
aggregate
too
much.
We
don't.
We
don't
know
those
things
but
yeah.
It's
a.
I
think.
It's
an
interesting
and
important
observation.
C
I
just
I
think
that,
as
ben
suggested
to
to
attract
transport
area
expat
gsp
review
is
a
good
idea,
but
I
just
want
all
this
consideration,
even
if
you
choose
may,
for
both
just
an
operational
condition
operational
handle.
I
think
that
all
these
transport
consideration
should
be
documented
in
the
draft.
So
what
we'll
have
if
we
use
this
option
and
what
are
adventures
disadvantages
and
what
can
happen?
At
least
it
should
be
documented.
That's
my
opinion.
D
D
B
B
B
D
I
don't
think
we
need,
I
think,
that's
a
good.
I
also
don't
think
this
is
a
lot
of
verbiage.
We
need
to
add
right.
We
don't
need
a
major
redesign
here.
We
just
could
we
just
need
to
note
in
like
the
paragraphs
you
suggested
tara.
We
can.
We
can
even
say
this
can
result
in
this.
You
know
it.
Could
you
know
like
we'll
get
to
that
site.
Show
that
show
mine
because
that'll
be
something
I
want
to
put
in
yeah
and
I
think
that's
that's
a
good
point.
You
had.
F
We've
heard
a
lot
of
things
in
the
live
discussion
here
that
you
would
be
nice
to
write
down
somewhere,
but
I
think
when
we
go
and
figure
out,
you
know
what
actually
needs
to
go
in
this
document
versus
what
could
maybe
be
a
separate
draft.
That's
just
sort
of
a
almost
a
living
document
to
to
incorporate
the
additional
stuff
that
we
do.
We
learn
over
time
like
I
think
we
should
try
to
not
put
everything
that
we
talked
about
today
into
this
document.
F
D
Yeah,
if
you
throw
up
the
the
picture
it
talks
to
this
lou
mentioned
the
amplification,
and-
and
I
want
to
show
that,
because
that
that's
what
I
would
probably
put
in
the
line,
it's
a
little
bit
further
down,
I
think
slide
nine,
maybe
yeah.
So
this
shows
a
picture
of
you
know
a
lot
of
misorder,
I'm
showing
a
picture
of
here,
a
common
scenario
right
where
you
get
a
mis-ordered
packet,
but
you
know
they're
not
since
we're
not
talking
about
constant
sun
rate.
D
I
wanted
to
highlight
that
the
miss
ordering
is
often
going
to
happen.
You
get
one
just
before
the
other
right,
because
it
it
just
took
a
slightly
it
paused
in
a
queue
or
or
whatever
I
mean
mostly,
we
don't,
like
you
said
tarot.
This
is
a
if
this
is
a
site
to
cite
any
udp,
we
don't
expect
a
lot
of
misordering
right,
but
if
we
do
see
it,
I
expect
it's
going
to
be
like
this
and
what
can
happen
when
you
get
this?
Is
you
know
if
you
look
at
the
out?
D
The
top
of
the
diagram
is
just
normal
delivery
and
it
even
shows
somewhat
of
a
valerie's
point
of
the
burstiness
right
of
when
you're
aggregating,
that
your
sense
son,
the
inners
right
one,
two
three,
four,
five,
six,
seven,
eight,
nine
ten.
When
you
get
them
miss
ordered
you
know
we're
getting
the
second
one
a
little
bit
before
the
first
one,
and
what
happens
is
that
then
we
send
the
first.
D
We
have
six
seven,
eight
nine
ten
to
send
so
we
send
them,
and
then
we
have
one
two,
three
four
five
and
we
send
those
right-
and
this
is
what
lou
is
talking
about-
where
we're
amplifying
the
out
of
order
delivery
right.
We've
only
got
a
one
packet
out
of
order
on
the
tunnel,
but
we've
made
the
user
and
what
the
user
sees
at
the
end.
It's
got
five
packets.
This
can
start.
You
know
we're
worried
that
this
could
start
really
triggering
you
know,
tcp,
you
know,
gets
outside
of
the
windows.
D
B
D
Make
ours
look
nice
because
you
know
in
this
particular
case,
ours
looks
nice
because
you
know
the
delivery
only
adds
a
small
delay
and
you
get
all
the
packets
in
order.
That's
not
going
to
be
every
case,
I'm
not
trying
to
say
you
know.
Ours
is
the
best
look
at
how
great
this
diagram
is,
but
there
are
definitely
cases
this
is.
D
This
is
going
to
be
a
common
case
where
the
small
delay
is
not
a
big
deal
and
tcp
and
whatnot
can
deal
with
it,
but
you
know
transport
protocols
might
not
be
able,
in
this
case,
to
deal
with
the
large
amplification
of
out-of-order
delivery.
This
is
just
one
case
that
I
wanted
to
cover
and
why
we.
F
Thought
that
gets
into
the
sort
of
there's
many
different
potential
use
cases
for
this
technology.
Some
of
them
will
involve
only
a
handful
of
inner
transport
flows
being
aggregated
into
the
single
outer
flow.
F
Was
there
anyone
else
in
the
queue?
I
had?
One
final
thought,
so
I
guess
one
of
the
things
I
got
up
in
the
queue
to
sort
of
mention
very
early
on
was
that
like,
if
we
think
about
a
traditional
router
and
ip
network,
it's
not
looking
at
the
flow.
It's
not
trying
to
do
any
reordering
here
and
in
some
sense,
if
we
think
of
the
ipsec
building
block
as
being
vaguely
analogous.
F
To
that,
my
intuition
would
be
that
this
router-like
thing
should
just
take
what
is
given
and
send
it
on
without
trying
to
store
too
much
state.
But
then
I
think
the
discussion
that
we've
had
just
right
now
during
this
meeting
has
sort
of
community.
That's
that's
not
exactly
the
case
here
precisely
because
I
think
maybe
lou
was
the
first
one
to
bring
this
up.
F
F
I
think
that
was
all
I
had
queued
up
in
my
notes,
so
I
guess
the
training.
D
D
To
show
at
this
point
yeah
I,
this
was
just
me
making
the
case
I
kind
of
just
made,
which
is
I,
I
think,
there's
going
to
be
a
lot
of
cases
where
things
just
work
right,
but
we
don't
have
to
dwell
on
this.
I
think
we're
getting
to
a
this.
This
is
the
discussion
I
think
we
needed
to
get
to
right
or
we
need
to
resolve
so
right.
F
Sort
of
summary
is
that
we
should
say
we
should
say
for
both
of
them,
and
we
can
put
a
little
bit
of
text
in
to
to
try
and
cover
some
cases
in
which
one
should
might
make,
like
others,
in
which
no
that's
not
doing.
B
The
one
right
now
right,
yeah
right,
I
I
I
I
think
I
think
having
may
may
actually
is
okay
and
I
think
what
we
should
be
doing.
We
should
rename
the
drop
timer
to
lost
timer
because
and
then
we
actually
want
to
define
it
in,
because
I
don't,
I
think,
we're
actually
missing
the
text
saying
that
after
the
lost
timer,
you
are
still
not
throwing
the
packets
away.
You
just
assume
that
the
previous
bucket
was
lost.
There
was
not
a
small
reorder.
B
This
is
like
the
hybrid
mode
I
have
in
my
when
I
proposed
three
different.
You
know
one
was
the
in
order.
One
was
mine
and
one
was
the
hybrid
wherever
actually
you
know
wait
for
the
short
time
to
see.
If
there's
a
you
know
just
two
packets
in
out
of
order,
and
then
you
know
process
them
in
order
and
after
a
very
short
time
out,
you
realize
that
okay,
it
was
not
just
out
of
or
very
short
out
of
order.
B
D
So
that
it
does
say
in
the
drop
timer
recommend,
it
says
only
consider
an
outer
packet
loss
when
the
reorder
window.
You
know
I
mean
it
does
talk
about
it.
Just
considering
that
packet
lost,
I
think
we
might
be
covered
there,
but
you
know
I
I'm
willing
to
call
it
a
lost
timer.
If
you
want
yeah.
B
B
Actually,
actually,
they
actually
come
to
the
one
format.
If
the
you
know
lost
timer
is
you
know
short
enough.
D
Yeah,
no
okay,
so
I'll
change,
I'll
change
drop
to
lost
packet
in
the
text
and
we'll
change
the
two
reds
to
may
that
last
final
crossout,
I
think
I
made
by
mistake
in
blue.
We
could
say,
drop
drop,
lost
packet,
timer
or
or
we
can
leave
over
your
window.
We
can
cross
it
out.
I
don't
know
yeah.
D
So
I
think
we
we
add
a
sentence
to
each
one
of
these
paragraphs
describing
the
oh.
You
know
for
the
first
paragraph
we
can
say
this
method
can
can
amplify
out
of
order,
inner
packet
delivery
and
for
the
second
paragraph
we
say
this
method
can
add,
you
know,
can
add
extra
delay
to
in
to
the
inner
packet
delivery.
D
So
those
are,
those
are
like
two
three
minor,
pretty
minor
changes
I
think,
and
we
make
those
and
let's
go
to
the
next
slide
line.
Rumor
is
commenting
that
the
extra
burst
perfectly
already
there.
D
So
I
I
think
we're
at
a
resolution
and
I
don't
think
we
have
any
other
issues.
Does
anybody
disagree.
B
Now
I
think,
that's
I
I
agree
and,
and
you
I
assume
you
can
get
the
new
draft
out
very
soon-
yeah
actually
send
center
note
centered.
You
know
modified
2.5
to
the
list
first,
hopefully
like
as
soon
as
possible,
and
then,
if
there's
no
comments
on
that,
then
we
can
actually
get
in
the
draft.
So
we
don't
and
then
I
want
to.
E
B
A
Just
one
thing
that
I
think
if
we
do
write
about
a
drop,
timer
or
delay
time
packet.
A
D
D
B
B
D
I
I
just
we
don't
know
what
effect
you
know
that
setting
we're
we're
just
taking
a
swag
at
it
right,
we're
writing
it.
B
A
D
D
H
B
No,
we
just
have
just
you
know,
a
comment
or
note,
or
something
like
that:
yeah
all
right.
So
if
that's
and
you
will
publish
the
new
version
of
the
craft-
and
we
will
tell
you
that
okay
send
okay,
I
don't
know
if
it's
going
to
be
stefano,
it's
going
to
be
the
who
is
going
to
be
okay.
Stephanie
is
going
to
be
presenting
this
okay.
I
We
do
not
claim
at
any
point
that
we
shouldn't
go
for
like
intermediate
or
the
multiplication
exchanges,
so
this
does
work.
We've
also
tested
that
with
a
strong
one
in
cyclone,
as
well
as
with
valerie
and
his
implementation,
and
of
course
it
does
work,
but
it
is
a
somewhat
complex
solution
and
you
there
are
a
few
pitfalls.
You
have
to
take
care
of
when
implementing
it
and
using
it,
and
what
we
do
claim
in
our
main
thread
is
that
we
should
have
like
a
first
barrier
that
is
quantum
resistant
in
the
iksa
in
it.
I
I
So
the
current
solution,
like
intermediate
and
the
multiple
key
exchanges,
is
to
have
it
like
in
a
hybrid
way,
to
use
several
schemes
in
a
hybrid
method,
and
this
does
work.
You
shouldn't
go
for
too
many
schemes
at
the
same
time
in
practice,
but
it
does
work
still.
We
need
some
kind
of
fallback
solution,
because
will
there
be
one
single
like
lettuce-based
scheme
in
the
future?
Maybe
maybe
in
five
to
ten
years,
we
will
have
the
confidence
that
a
single
scheme
is
good
enough
for
the
next
few
years
for
some
parameter
sets.
I
But
right
now
we
still
don't
know
and
iq
ii
is
used
in
a
lot
of
settings,
and
we
do
know
about
quite
a
few
settings
that
are
in
the
governmental
or
military
context
and
there
they
want
to
have
a
very
secure
solution,
and
sometimes
they
have
quite
good
throughputs.
It's
not
always
that
bad
having
they
don't,
have
two
lossy
networks
in
some
cases,
and
they
basically
want
to
have
mega
lease
because
mega
lease
is
really
big.
I
If
you
want
to
have
like
a
quantum
resistance
scheme
for
authentication
as
well
and
there,
you
get
quite
a
lot
of
complex
state
machines
and
it
gets
quite
messy
and
there
are
really
many
denial
of
service
options
you
could
have
as
an
attacker
and
one
easy
way
to
go
about
it
without
doing
a
lot
of
multiple
key
exchanges
beforehand
is
have
like
this
very
first
barrier,
so
taking
just
one
efficient
quantum
resistance
scheme
included
in,
I
guess
in
it.
I
We
still
don't
know
if
this
single
scheme
is
like
really
secure
for
the
next
five
years.
We
just
can't
say
it,
but
it
is
an
additional
effort
that
an
attacker
would
have
to
do
like
in
the
very
first
exchange
of
any
data.
I
So
this
might
be
quite
a
cost,
efficient
solution
and
it
would
help
for
quite
a
few
cases
of
denial
of
service
attacks
as
well,
and
you
might
be
able
to
implement
it
and
also
like
implement
like
intermediate
and
everything
above
it
as
well.
So
we've
implemented
it
and
we've
also
done
some
measurements,
and
I
think
it
has
a
few
graphics
to
show.
K
So,
okay,
yes,
exactly.
K
We're
just
gonna
switch
places
all
right,
then
we
do
it
that
way.
We
implemented
all
the
drafts
actually
and
let's
do
that.
We
implemented
all
the
drafts,
so
our
intermediate
exchange
the
follow-up
exchanges
and
the
beyond
64k
limit
draft
and
but
not
the
current
version,
but
the
version
before
the
current
version
uses
mixed
mode,
so
tcp
for
the
handshake
and
udp
for
for
the
actual
payload
data.
K
K
There
we
have
on
the
exact
x-axis,
the
error
rate,
so
like
the
packet
failure
rate
and
percent
and
on
the
y-axis
we
see
the
ever
the
handshake
duration
for
each
network
configuration
so
like
f,
each
error
rate
there
were
100
100
measurements
taken
and
the
the
underlying
conditions
were
at
this
point,
100
milliseconds
of
a
pretty
constant
latency
and
100
megabyte
off
of
throughput.
K
So
it's
like
in
german,
you
would
say,
like
an
average
usual
household
connection
and
there
we
see
that
as
long
as
the
package
drop
rate
is
not
too
high,
it's
like
around
I'd,
say
10
10
seconds
until
the
essays
are
created,
which
we
deem
actually
pretty
acceptable
for
a
solution
that
is
for
like
sellers
with
with
especially
high
security
requirements
where
agencies
say
okay
these
day,
this
data
has
to
be
secure
for
decades,
not
just
for
like
five
years
or
something
like
that,
and
for
this
I
guess
we
think
it's
actually
a
solution.
K
That
is
not
too
bad.
Obviously,
if
you
want
to
connect
a
large
amount
of
mobile
clients
working
over
like
cell
phone
connections,
you
you
come
you
get
into
trouble.
That
is
that's
clear.
You
also
see
it.
We
tested
the
the
same,
the
same
setup,
but
instead
of
100
megabit,
it
was
one
megabit
of
throughput.
K
So
if
you
can
show
the
next
slide,
please
and
there
we
have
a
pretty
clear
distinction,
so
we're
pretty
fast
at
around
50
seconds
of
handshake
duration
or
even
more
than
when
the
package
loss
goes
up,
and
I
don't
think
this.
So
this
shows
like
less
reliable
wireless
networks,
and
I
don't
think
this
is
a
or
just
smaller
red
networks
with
less
throughput,
and
we
don't
think
for
this
use
case.
K
Yes
still,
we
thought
I
should
talk
about
where
to
use
it
because
a
gateway
having
to
accept
like
several
megabytes
or
1.4
in
the
largest
configuration
megabytes
of
data
from
an
unauthenticated
peer
just
opens
up
the
attack,
vector
of
just
many
peers,
sending
sending
these
these
large
public
keys
and
thereby
exhausting
the
memory
of
the
gateway
and
so
by
this
denying
the
service
and
therefore
has
to
be
some
protection
against
this
attack.
K
So
we
think
putting
it
behind
authentication,
so
each
initiator
has
to
authenticate
itself
first
and
it's
then
able
to
to
send
the
the
mcaleese
key
exchange
in
our
way.
We
did
this
by
immediately
re-keying
and
only
allowing
the
mcleans
to
be
sent
during
follow-up
exchanges,
but,
as
we
talked
discussed
already
last
time,
this
has
some
implications
so
yeah
it
has
to
is
it's
a
decision
to
be
made?
K
K
C
So,
first,
I
think
that
using
udp
they
trusted
me
very
largely
as
as
it
was
in
blue's
version
of
the
n64
car.
It's
not
a
very
good
idea.
That's
why
we
introduced
a
mixed
transport
mod.
I
think
that
it
will
solve
a
reliability
problem,
because
I
will
well
your
figures
are
very
impressive,
but
I
think
if
this
is
used
for
ike
in
this
case,
so
this
this
will
be
solved.
C
And
what
about
the
solution?
You
propose
to
make
some
combined
combined
key
exchange
that
combines
difficult
one
with
some
quest
quantum.
C
With
some
post-quantum
alteration
with
small
public
key,
I
think
it's,
it's
not
a
bad
idea,
but
first
of
all
to
the
multiple
key
drops,
because
you
can
use
it
with
or
without
it's
just
just
well.
Multiple
key
drop
makes
one
change
to
the
ip2
protocol.
C
It
remains
difficult
on
group
through
generic
key
exchange
method,
and
with
this
change
you
can
define
a
key
exchange
method
as
as
you
want,
as
combination
of
two
key
exchanges,
so
it's
okay
and
you
can
use
it
to
with
without
multiple
key
exchanges
and
it's
just
a
secondary
work.
What
what
makes
me
what
I
don't
like
about
it
is
that,
well
you
pick
you
have
picked
up
a
single
classic
exchange
to
55
19
and
the
single
post
quantum
key
exchange.
C
Well,
I
think
that
it's
okay,
but
not
not
in
all
environments.
There
are
lots
of
environments
that
will
insist
on
using
this
particular
quantum
key
exchange
in
this
particular
classic
exchange
and
and
they
they
won't
be
those
that
you
have
selected.
So
that's
why
multiple
pe
will
solve
this
problem
but
combinations,
so
you
can
achieve
the
same
result.
C
If
you
perform,
like,
I
say,
need
with
any
classic
exchange,
you
want
and
then
follow
with
the
what
quantity
is
change
with
small
public,
key
and
academic,
and
it
will
add
you
one
extra
round
cheap,
comparing
to
your
solution,
but
much
more
flexibility.
That
is
very
important
for
for
some
environments,.
K
I
totally
agree
if
I
just
can
like
directly
answer
to
that.
I
totally
agree
and
I
think,
for
long
term,
the
greater
flexibility
of
follow-up
exchange,
like
the
the
multiple
key
exchanges
and
the
intermedia
intermediate
exchanges,
is
definitely
the
superior
solution
still
for
migration
purposes,
because
the
the
intermediate
exchange
does
definitely
add
complexity
due
to
its
interconnectedness
with
authentication
and
the
way
the
signature
has
to
be
calculated.
K
And
so
currently
we
have
to
expect
that
agencies
already
record
data
to
be
able
to
decrypt
it
when
they
have
a
large
quantum
computer
available
later
on
in
whenever
that
may
be,
and
so
we
should
like
start
use
using
post
quantum
cryptography
better
now
than
than
in
a
few
years
or
a
few
months.
So
the
the
easy
solution
of
just
adding,
I
don't
know
one
to
three
given
fixed
combinations
that
are
like
there's
no
big
protocol
changes.
K
There's,
as
you
said,
it's
it's
really
low
effort,
and
the
adoption
of
this,
for
many
implementations
should
be,
should
be
pretty
quick
and
then
in
in
the
to
like
overcome
the
transition
period
until
the
intermediate
exchange
and
the
multiple
key
exchanges
draft
is,
has
a
wide
wide
adopting
like
wide
acceptance,
yeah
it's
widely
adopted
by
different
implementations,
and
so
because
otherwise
we
still
have
a
gap
where
we
just
use
as
it
is,
as
it
is
now.
Just
use
classical
key
exchanges
like
tiffy
helmand.
C
I
just
want
to
point
out
that
we
will
already
have
an
rfc
8764
for
using
a
mixing
per
shared
key
to
achieve
both
quantum
security,
and
it
was
deliberately
chosen
as
a
short-term
solution
before
post
quantum
key
exchange
became
mature,
so
you
can
always
use
this
rfc
and
it
has
yes,
it
has
some
scalability
problem
there,
but
it
gives
you
the
the
whole
protection
from
quantum
computers
so
and
well,
so
I
don't
I
don't
mind
if
you
defined
a
combined
key
exchange
as
as
for
me,
but
I
think
that
this
is
a
stronghold
work.
C
So
you
can,
you
can
write
draft
defining
how
how
keys
are
combined
and
for
me
just
for
me
for
some
reasons
of
a
great
magicity.
I
I
think
that
I'd
avoid
using
some
hashes
and
just
make
a
concatenation
of
public
keys,
because
if
you
stick
with
a
hash
function,
you
will
use
it
forever.
It's
it's
no
agility,
so
you
will
change
the
whole
combined
method.
C
Well,
if,
but
it's
in
my
opinion,
so
it's
it's
security,
expense
should
analyze
it.
Oh.
C
But
so
so
the
bottom
line.
What
I
want
to
say.
I
think
that
it's
not
a
bad
idea,
but
it
is
not
concerned
with
the
current
efforts
to
make
multiple
key
and
beyond
64.,
because
I
think
they
they
should
be
continued
and
to
make
workable.
And
yes.
K
Yes,
I
think
they
might
be
like
if
he
is
the
beyond
64k
draft
and
he
put
the
the
the
large
key
exchanges
behind
authentication
like
we
proposed.
Then
you
might
run
into
the
the
situation
where
you
don't
use
a
quantum
secure,
key
exchange
before
authentication,
because
an
administrator
thinks
well.
I
use
make
a
list
there's
a
secure
enough
there.
I
don't
need
another
post
quantum
key
exchange
and
then
they
have
iksa
in
it
with
the
classical
key
exchange
they
have
authentication
and
then
they
re-key
or
whatever.
K
However,
it's
structured
and
run
the
the
mecalis
key
exchange,
a
attacker
who
lively
like
in
in
real
time,
decrypts
or
breaks
the
first
key
exchange
would
obtain
the
the
shared
secret
and
this
would
allow
him
to
or
them
to
to
manipu
manipulate
the
message
authentication
code
of
the
mcaleeski
exchanges
so
establishing
a
full
man
in
the
middle
position
before
the
mcat
key
exchange
is
conducted.
K
So
there
would
be
another
easy
option
to
to
just
deny
it
deny
that
auction
or
to
deny
this
attack
without
even
requiring
the
multiple
key
exchange
or
the
intermediate
exchanges,
which
doesn't
mean
you
should
not.
You
like.
K
You
should
not
use
it,
so
you
could
still
say
you
use,
I
can
say
in
it
with,
I
don't
know
classical
tiffy
hermann
and
then
use
the
first
intermediate
exchange
with
some
lattice-based
scheme,
and
then
you
have
authentication
and
then
you
have,
then
you
have
your
mcliskey
exchange
or
you
just
have
you
configure
your
combined
mechanism
in
iso
in
it
with
ecdh
and
with
some
some
small
letters
based
scheme,
which
at
least
prevents
an
attacker
from
breaking
the
code
life
in
real
time?
K
Then
you
have
authentication,
and
then
you
have
your
meca
lease
scheme.
So
in
that
situation
it
could
be
like
also
come
in
handy,
but
it's
definitely
not
a
must.
So
it's
just
a
another
another
thing
to
make
it
more
easy
and
more
the
transition
more
and
more
smoothly.
C
All
right,
you
can
also
achieve
this
by
doing
classical
exchange
that
I
can
say
need,
then
I
can
intermediate
with
some
small
public
key.
K
So
it's
as
I
said,
it's
not
a
it's,
not
a
definite
must,
but
it's
I
think
it
would
make
all
of
these
transition
transition
periods
more
easy
and,
as
I
mean
as
we,
we
already
agreed
upon
them.
It's
it's
a
nice
addition
and
which,
which
should
make
the
transition
periods
smoother
and
on
the
long
term,
the
the
the
the
solution.
F
K
With
more
cryptographic
agility,
which
allows
more
cryptocurrency
like
the
follow
key
exchange
md,
the
multiple
key
exchanges
should
be
preferred.
K
K
K
K
But
already
now
for
for
some
network
environments,
it
is
a
acceptable
solution,
but
we
think
the
mca
lease
mca
lease
key
exchanges
or
like
all
key
exchanges,
that
are
that
large,
that
they
require
the
beyond
64k
draft
should
at
least
be
put
after
authentication
to
prevent
the
this
attack
vector
for
dos
attacks
or
especially
memory
exhaustion,
attacks.
K
J
I'm
actually
going
to
ask
a
question
not
about
the
protocol,
but
about
your
assertion
that
20
seconds
of
delay
is
actually
acceptable.
I
assume
you
are
running
this
on
a
net
on
a
conf
on
a
a
single
connection
between
one
gateway
to
another
gateway
or
one
client
to
another
client.
J
Yes,
unfortunately,
we
that
quite
commonly
we
have
a
single
gateway
talking
to
dozens
hundreds,
possibly
even
thousands
of
clients,
and
sometimes
they
all
try
to
to
basically
come
in
at
this
about
the
same
time.
J
How
would
this
scenario?
How
would
your
protocol
work
in
that
scenario.
K
That
is
a
good
question.
Actually,
so
the
test
environment
is
just
two
gateways:
communicating
over
yeah,
more
or
less,
depending
on
configuration,
reliable
channel.
Obviously,
if
you-
but
it's
it's
also
confined
to
100
megabits.
So
I
guess,
if
you
have
a
central
central
route
like
central
gateway,
it
will
hopefully
have
more
than
100
megabit
of
throughput
and
just
be
more
capable
than
that.
Otherwise
I
don't
think
it
will
be
fit
for
for
such
a
scenario
and
yeah
other.
K
Obviously,
also
if
you
connect
a
lot
of
a
lot
of
a
lot
of
client
initiatives
initiators
at
the
same
time
and
all
of
them
are
sending
or
send
such
large
public
keys,
you
will
run
into
problems
and
the
10
seconds
we
we
have
here
in
our
measurements,
for
for
rather
rather
good
network
conditions
will
be
surpassed.
K
I
About
like
really
a
lot
of
clients
talking
to
a
single
gateway,
because
what
we're
talking
about
is
like
there's
agencies,
there's
military
stuff,
where
you
won't
have
this
three
four,
maybe
five
connections
to
other
places
and
those
have
to
be
really
secure
and
they
expect
us
to
use
megalith
something
that
they
really
can
rely
on.
But
on
the
other
side
there
might
be
hundreds
of
other
clients,
but
I
don't
think
that
any
mobile
client
will
be
able
to
use
megaliths
anyway.
I
So
we
have
to
use
something
else
there
anyway,
but
when
you
only
talk
about
those
very
specific
lines,
only
thinking
about
like
one
con
location
connected
to
the
other
location,
it
should
still
be
okay
with
this
delay,.
K
Of
course,
real-time
measurements
with
real-world
conditions
would
be
even
more.
It
would
give
even
more
insight,
but
for
these
network
confined
confined
yeah
variants
of
networking
conditions,
this
might
be
a
good
solution.
It's
definitely
not
a
one.
One
size
fits
all
draft
and
it
was
never
intended
to
be,
and
we.
I
Still
don't
have
really
like
too
many
test,
setups
like
what
we
can
do
right
now
is
like
test
within
germany,
so
over
the
internet
is
quite
okay,
because
we
have
some
locations
where
we
can
test
it,
but
so
far
we
weren't
really
able
to
like
test
it
worldwide.
That
would
be
something
we
want
to
do
so
if
anyone
can
help
us
out,
that
would
be
great
anyway.
C
And
with
my
result,
well,
I
didn't
maintain.
I
didn't
have
a
network
that
emulates
packet
loss.
It
was
just
a
100
megabit
test
bed
network
and
pretty
dated
stopped
and
it
took
about
few
seconds
to
perform
marcolis
with
this
setup.
Well,
I
didn't,
I
don't
have
exact
measure,
but
it's
about
two
three
seconds
to
make
a
list
to
complete
just
my
experience
with
it.
K
Just
one
little
note,
the
graphic
you
see
there,
which
is
rather
rather
high
connection
times
or
handshake
completion
times,
is
with
a
net
throughput
of
one
megabit.
So
this
is
a
really
really
confined
throughput
and
so
like
not
what
we
would
expect
a
scenario
to
have,
but
it
shows
that
it's
really
not
the
best
scenario
for
for
this.
This
draft
sorry.
B
Can
you
hear
me
now
actually
with
my
microphone?
Okay,
okay,
you
can
hear
me,
but
I
can't
see
my
text
there,
but
anyway,
so
we
should
be
going
forward
to
next
presentation,
which
should
be
valerie,
which
should
try
to
speak
up
this
time,
because
there
have
been
people
complaining
that
you
are
too.
You
are
not
loud
enough
all
right,
let's
just
say
when
you
want
to
go
to
next
slides
and
zone.
C
So
it's
grocery
management
using
iq2.
So
next,
please,
the
draft
is
about
securing
ip
multicast,
and
this
is
a
brief
reminder
of
what
multicast
is-
and
I
think
you
all
this
know
about
it,
so
it
contains
at
least
one
center
and
and
receivers
and
the
packet
it
takes
advantage
advantage
of
multicast
routing
that
delivers
packet
to
all
and
receivers
and
for
to
secure
this
setup.
This
requires
sender
and
receiver
to
chase
it
up
like
say
using
the
same
keys.
C
So
there
are
two
kind
of
costs
in
this
setup.
It's
group
key
group,
controller,
k7,
gc
cars
and
group
members,
so
group
control
k7
is
responsible
for
generating
the
shared
key
and
for
delivering
them
to
the
group
members
at
the
time.
At
the
time
the
group
members
joined
the
group,
so
this
a
unicast
registration
protocol
that
is
very
similar
to
iq2
and
except
that
it
is
not
created
a
child
assay.
Instead,
it
ends
up
with
shared
keys
that
are
delivered
from
controller
to
group
members.
C
So
there
is
also
a
rekey
protocol
that
can
be
done
either
we
are
multicast
or
via
unicast,
depending
on
the
controller
choice.
So
the
next
please
so
and
gi
quit2
is
intended
to
be
used
in
ieee
802
15
9
as
a
key
management
protocol
for
multicast.
So
I
think
terra
may
correct
me
this.
This
is
data
from
from
the
previous
presentation.
Probably
something
has
been
changed,
but
draft
zero.
Five
version
of
std80259
standard
specifies
that
gip2
is
used
for
group
key
distribution,
so
the
next
please.
C
C
It
has
been
adopted
by
a
pesekomi
two
years
ago
and
in
2020
it
was
a
major
rewrite
and
since
then
on
the
mind,
update
were
made
and
the
draft.
Well,
it's
it's.
I
think
it's
mature
enough,
but
I
think
it
definitely
badly
needs
the
reviews
so
for
by
much
enough,
I
I
mean
that
authors,
don't
don't
see
anything
that
can
be.
That
should
be
added
to
the
to
this
and
anything
that
should
be
removed
from
this,
but
definitely
it's
only
owl's
opinion
and
we
badly
need
reviews.
C
Immigration,
things
like
transforms,
and
and
so
on,
so
that's
why
formats
of
gsa
and
cadepo
has
changed
and
group
key
representation
has
been
changed
before
the
group
key
were
transferred
clean,
clear
inside
key
distribution.
Payload,
so
like
implementation
can
look,
can
can
see
them,
and
I
think
it's
not
good
and
it
was
changed
so
the
old
key
encrypted,
even
inside
deep
load,
either
using
a
skt
derived
key
or
using
some
keys.
C
C
So
we
will
write
it.
I
am
consideration
so
now
it's
it's
more,
an
extension
to
iq2
and
not
a
separate
protocol.
So
we
use
like
two
registries
for
new
ways.
We
extend
them
and
a
lot
of
clarification
has
been
added
and
I
won't
list
all
of
them,
but
there
are
a
lot
of
them
and
that's
please.
C
C
Reload
format
is
now
common
for
all
situation
of
keck
check
and
gap
and
the
gap.
The
difference
of
the
gap
is
that
it
distinguished
by
the
value
of
protocol
that
is
zero.
It's
next,
please
kdp
load
contain
scheme
material
necessary
for
the
policy
in
the
gsa
load,
so
it
contains
one
or
more
keys
in
encrypted
form.
There
is
a
structure
called
the
wrapped
key
and
that
contain
contains
a
group
key
that
is
encrypted
with
another
key
and
either
it
is
skd
derived
key
or
rather
group
key.
C
C
And
idg
plot
contains
identifying
the
group
that
gm
want
to
join.
There
is
no
change
next,
please.
C
So
a
few
equity
pilot
are
used.
It's
sag
that
it
has
the
same
format
as
a
sap
load,
but
slightly
different
semantics
and
delete
below
again
it's.
It
has
the
same
format
and
the
same
reload
number,
but
the
semantic
is
slightly
different
because
it
is
allowed
to
delete
all
essays,
not
only
a
particular
say
so
next,
please,
there
are
new
notifications
compared
to
equity.
C
C
That
indicate
that
gm
want
to
be
a
center
in
the
group
and
newly
added
with
the
zero
one
version.
The
keys
needed
notification
that
this
notification
is
used
with
ppk
with
when
ppk
is
used,
because
using
ppk
with
gi,
quick
2
brings
a
lot
of
problems
because
we
need,
I
can
say,
to
be
secure
from
the
very
beginning,
because
we
we
want
to
transfer
sensitive
foundational
weed.
C
So
the
approach
that
is
rc,
87
64
is
taken
when
we
create
a
childless
psycho
sales
and
immediate,
clear
key
is
not
going
for
jq
2.
That's
why
there
is
a
very
complex
mechanism
and
I
also
have
a
draft,
an
alternative
weight
for
eq,
probably
for
what's
quantum
key
security,
mixing
the
shape
key
for
quantum
key
security,
and
I
think
if,
if
we
want
to
make
this
rfc
work
for
jquery
ii,
we
should
consider
the
adoption
of
this
draft
because
it
it
it
signifi
it
uses.
C
I
can't
immediately
in
insignificant,
significantly
simplifies
jqe2
for
use
with
ppk,
so
the
next
please
and
use
transparent
mod
is
reused
with
slightly
different
semantics.
C
B
So
I
have
one
question:
do
you
do?
Does
the
you
know,
system
or
or
the
draft
already
support
this
like
intermediate
and
or
do
you
have
a
text
for
that.
C
I
don't
remember
whether
the
text
for
for
that
is
in
the
draft,
but
I
think
that
I
can
intermediate
can
be
used
with
this
draft.
There's
no.
B
Yeah,
my
understanding
is
that
it
will,
I
think,
actually
it
would
be
a
good
idea
to
add
that
in
in
in
there,
that's
so
that
we
actually,
you
know,
have
a
clear
text
that
you
can
actually
use
this
without
intermediate,
but
I
think
we
can
actually,
even
I
think,
that's
a
very
small
change
that
we
can
actually
because
I
think
it
works
without
any
changes.
It
just
needs
to
be
said
that
oh
yeah,
you
do
that.
B
B
C
Okay,
this
is
also
repeated
presentation.
It's
not
new.
I
just
want
to
bring
your
attention
to
the
draft
because
it
is
in
the
ipc
commit
chatter
and
I
think
it
is
ready
for
adoption.
So
the
next
please.
C
So,
unlike
equity,
one
authentication
method
is
on,
q2
is
not
negotiated,
so
each
pa
is
free
to
use,
whichever
method
is
think
is
appropriate
and
generally
it
works
very
well.
C
So
it
is
also
possible
for
responding
but
less
likely
because
once
initiate
indicates
which
authenticated
authentication
method
it
uses
a
responder
has
more
information
to
to
choose
a
proper
one.
So
the
next
piece.
C
So
the
problem-
the
problem
was
first
encountered
when
rsi
pss
signature,
formatted
piece
in
like
two
so
new
initiator
tried
to
use
rsi
pss,
while
old
responder
didn't
support
it,
send
it
authentication
failed
and
for
initiators
there
is
no
clue
why
authentication
is
failed.
It's
probably
something
wrong
with
credentials
or
something
else.
C
C
There
may
be
some
some
indirect
ways
can
be
used
like
a
set
request
preload,
but
in
general
it
is
unreliable
and
I
think
that
with
new
signature
formats
and
authentication
method,
especially
if
we,
if
you
think
of
what
quantum
authentication
method
and
hybrid
ones
that
only
appear
the
station
of
me
selected
may
happen
more
often
so
the
next
please
and
propose
solution.
C
We
can
add
a
new
optional
status
notification
supported
our
method
to
indicate
so
that
each
peer
can
indicate
a
supported,
authentication
method.
There
is
not
a
negotiation,
unlike
iq1,
it's
only
announcement,
so
each
peer
just
announced
which
method
are
supported
so
that
the
other
peer
can
select
one
of
supported,
authentication
method.
They
can
different
in
different
directions
as
it
is,
as
as
it
can
be
now.
So
in
this
case,
it
is
not
a
negotiation
in
negotiation.
It's
only
an
announcement
and
for
certificate
bridge
authentication.
C
We
can
add
an
ability
for
peace
to
indicate
which
sign
algorithm
can
be
used
which,
which
each
certificate
authority
certificate
in
the
third
track
indicated.
If
the
search
request
will
load-
and
we
don't
want
creating
new
ionic
registries
for
this-
so
the
next
please.
C
So
the
format
of
this
new
notification
is
as
follows:
identification
data
consists
of
list
of
supported
methods
which
has
three
possible
formats
to
octets
format
that
only
indicate
for
the
methods
that
are
not
linked
to
subtract
such
requests
below
it
like
pressured
key
or
null
authentication,
three
octet
format
that
allows
the
optional
linking
to
search
requests
below
and
multiple
formats.
C
So
it's
it's
an
example.
Somehow
it
can
look
like
so
we
can
as
you
we
can.
We
have
a
search
request
below
with
several
cs
each
with
different
algorithm,
and
we
have
supported
our
method
notifications
that
link.
That
indicates
an
aggression,
identifier
and
link
with
algorithmic
and
identifier
with
a
particular
c.
So
the
next
please.
C
So
this
notification
can
be
used
either
in
I
can
say,
need
and
for
correspondent
and
I
cause
initiator
or
next
please.
C
Or
in
I
can
intermediate
exchange
just
to
avoid
fragmentation
in
this
case.
Respond
sends
an
empty
supported
house
method
in
aksa
need
just
indicating
that
the
real,
the
the
real
supported
house,
myself,
notification
containing
a
real
information
will
be
will
be
sent
in
in
ike
intermediate,
and
this
can
avoid
a
potential
fragmentation
problem,
because,
with
this
format,
supported
house
method
can
grow
well,
pretty
pretty
well
two
to
tens
or
even
100
bytes
and
loans
in
length.
G
Okay,
so
so
my
question
is
that
there's
a
bit
of
confusion,
I
think
between
what
is
a
configured
authentication
method
and
what
is
a
supported,
authentication
method,
because
if
a
responder
supports
rsa
pss,
but
it
only
has
a
connection
configured
for
pre-shared
key,
then
that
information
is
kind
of
useless
to
the
initiator
right,
and
so
I'm
really
confused.
G
What
so
I
can
understand
the
initiator
can
send
what
what
is
expecting
to
do,
because
it
knows
the
authentication
it
is
going
to
do
because
it
knows
which
connection
it's
trying
to
reach,
but
the
responder
might
have
multiple
connections
configured
with
different
authentication
mechanisms,
and
so
I'm
just
trying
to
clarify
like.
Are
you
only
looking
to
announce
the
supported
authentication
methods
as
in
the
implemented
ones
and
not
like
the
allowed
ones?
Because
there's
some
confusion
for
me
there?
I.
C
Think
I
think
it
is
allowed
once,
but
if
you
can,
of
course,
if
you
can
tell
what
is
allowed
for
this
particular
connection,
if
this,
of
course
it
is
allowed
once
not
implemented.
G
Okay,
but
so
then
the
problem
becomes
on
the
allowed
side.
The
responder
has
no
way
to
answer
anything
until
it
has
received
the
auth
payload
from
the
initiator,
because
only
then
does
it
have
the
id
payload,
and
only
then
does
it
know
what's
configured
for
that
specific
peer.
Yes,.
C
C
It's
a
little
mix
of
this
because
well
actually,
if
responder
can
guess,
for
example,
from
ap
address,
then
it
is
allowed.
But
if,
if
it
cannot
guess,
then
it
is
supported.
G
B
Any
comments
about
note
whether
this
document
is
ready
for
working
group
adoption.
If
I
I
think
it
should
be,
because
I
mean
it's,
it's
a
starting
point
for
this
draft
document
that
I
think
is
in
the
charter.
So
we
should
be
making
us
a
working
group
document
and
then
start
processing
it
for
one.
B
B
All
right,
so
so,
if
there's
no
other
comments
on
this
on
this
topic,
I
think
we
will
then
you
know
start
a
working
group.
Adoption
call
for
that
or
the
christian.
Do
you
have
some
comments
on
this
or
something
else?
No,
okay.
So
so
I
think
that's
for
it.
Then
then
we
have
any
other
topics
or
valerie.
Do
you
have
another
other
topics.
C
First,
first
is
a
voice,
cookie
processing.
Well,
we
discussed
it.
A
few
atf's
ago
was
a.
I
want
to
know
whether
there
is
any
interest
in
adopting
this
draft
and
then
another
drug
that
is
waiting
for
adoption
call
is
alternative
mechanism
for
mixing
pressured
key
that
I
mentioned
when
I
talked
about
jqe2.
C
So
if
we
use
ppk
in
jq2,
I
think
that
we
should
seriously
consider
adopting
the
draft,
because
it
solves
a
lot
of
problems
that
that
well
doing
ppk
in
gik-2
is
very
difficult.
It
requires
a
lot
of
additional
round
trips
and
unnecessary
delay
of,
say
setup,
because
you
need,
I
can
say,
to
be
secured
from
the
very
beginning.
C
So
if
you
want
to
bpk
to
be
coupled
with
gip2s-
and
we
should
consider
this
alternative
way-
it
is
very
simple:
you
can
it's
only
seven
pages
long,
and
I
also
think
that
draft
beyond
64
kilobytes
is
also
is
worse
to
adopted
by
this
group.
Well,
we've
talked
a
lot
about
using
michaelis
and
all
these
mechanisms,
long
public
keys
and
not
only
for
exchange
method
but
for
signature
method.
Two,
and
so
I
think
that
well
probably
not
immediately,
but
I
think
that
we
should
consider
adopting
this
drought.
B
Yeah,
I
would
propose
you,
send
an
email
to
the
list
on
on
each
of
these
specific
crafts
and
ask
for
their
author
people
who,
if
their
people
are
interested
to
comment
on
that
and
and
and
and
so
forth
or
all
people
can.
Actually,
we
have
still
five
minutes
actually
probably
do
that
in
email
all
right.
So
the
next
one
is
paul.
I
guess
in
the
queue.
G
I'm
not
sure
how
a
raised
christian
but
there's
another
draft,
the
multiple
essay
ones
where
we
clarified
some
things.
We
add.
We
asked
some
input
from
the
working
group
on
a
mailing
list
and
we
did
not
hear
any
objections
to
a
proposal.
So
we
went
ahead
and
published
a
new
version
of
the
draft
that
did
not
have
qos
in
it
and
that
really
simplifies
the
draft.
And
so
I'm
hoping
that
people
can
read
it
and
give
comments
on
it
because
we
have.
G
It
and
we
really
are
looking
for
getting
our
more
than
you
know
more
than
three
gigs
per
cpu
implementations
out
there.
So
we
have
implementations,
but
we
really
want
this
document
to
move
forward.
So
wasn't.
B
There
just
before
the
society
have
some
comments
about
somebody
saying
that
they
should
be
combined
with
other
draft
or
something
like
or
have
this.
I
think
there
was
some
discussion
at
least
before
the
itf
or
I
don't
know
I
might.
I
might
be
streamer
okay
but
anyway.
So
let's
bring
that.
Let's
keep
that
on
the
list
and
and
continue
there
and
see
if
people
are
interested
christian.
D
I
I
will
say
paul:
we
are
interested
in
looking
at
tfs
stuff
on
in
linux.
I
don't
know
if
we're
gonna
get
to
it,
but
if
we.
B
D
I
suspect
we're
gonna
be
looking
at
your
stuff
as
well
to
get
the
higher
rates.
In
any
case,
I
was
just
going
to
say,
the
new
iptfs
draft
is
published
and
posted.
We
only
have
four
minutes.
If
we
had
like
20
minutes,
I
was
going
to
say
I'll
share
my
screen.
We
can
go
over
the
diff,
but
I
think
we're
out
of
time
for
that.
I
think
I
got
all
the
points
in
there,
though
so
people
could
take
a
quick
look.
That
would
be
great
all
right,
good.
B
Okay,
my
list
of
things
that
we
should
be
doing
is
to
have
an
working
group
last
call
for
gi
question
2
to
get
more
reviews
on
start
the
publication
of
the
iptfs
trust.
When
we
get
this
when
we
have,
you
know
time
to
read
the
draft
and
verify
that
it's
all
there
and
then
probably
start
the
working
group
adoption
course
for
draft,
be
tv
ad
ipsec
ike
for
the
additional.
B
You
know
this
this
dns
stuff,
and
then
we
have
the
I
question
to
out
announce
anything
else
that
I'm
missing
on
my
to-do
list.