►
From YouTube: IETF109-IPSECME-20201117-0900
Description
IPSECME meeting session at IETF109
2020/11/17 0900
https://datatracker.ietf.org/meeting/109/proceedings/
C
Yeah
then
I
find
the
proper
window
to
go
forward.
The
meat
echo
window
doesn't
work
for
moving
next
slide.
So
this
is
the
note
well-
and
everybody
has
probably
seen
this
couple
of
times
already
and
we'll
see
it
a
couple
of
more
times
so
the
first
things
we
don't
need
blue
sheets
because
they
are
taken
automatically,
but
we
brought
with
some
note
takers
and
chopper
scribe.
C
So
anybody
you
know
volunteering
to
taking
notes
in
the
for
the
meeting.
There
is
already
pre-filled
stuff
in
the
coding
id,
so
it
should
be
very
easy
and
just
write
in
the
stuff
that
actually
discards
not
or
or
questions,
ask
answers
and
so
on.
A
Right
and
I'll
be
monitoring
the
java
room,
so
I
don't
think
we
need
an
extra
scribe
for
that.
Okay,.
C
C
D
E
So
I'm
really
bad
at
taking
notes,
but
I
I
can
give
a
try
all
right.
People
can
go
there
and
help.
C
That's
all:
okay,
good,
okay,
so
this
is
our
agenda,
so
we
are
right
on
schedule.
So
we
have
five
minutes
for
the
document
status.
Then
we
have
a
couple
of
work
items.
Actually
the
young
model
for
ip
traffic
flows,
securities
problem
it's
in
the
middle
of
the
work
either
or
the
new
item.
I
don't
know,
and
then
we
have
a
couple
of
new
items,
any
comments
on
the
agenda.
C
If
not,
we
go
forward
so
our
status
report.
So
we
have
one
document
that
is
in
itf
last
call
now
ipv6
ipv4
codes
and
I
think
it's
it
will
be
finishing
in
couple
of
weeks
or
something
like
that.
It's
starts
started,
then
we
have
a
couple
of
documents
that
are
still
in
ongoing.
The
gi
version,
2
is
got
got
to,
I
think,
quite
a
big
right,
but
he
still
hasn't
been
getting
that
much
review.
C
I
think
ice
version.
2
intermediate
should
be
ready
quite
soon.
I
think,
and
I
think
the
multiple
key
extensions
and
those
things
are
and
the
liabilities
those
we
actually
have
a
couple
of
other
systems
presentations
later
for
the
last
two
ones
or
any
comments
on
the
current
working
group
status.
C
F
H
G
Okay,
I
just
wanted
to
make
a
quick
note,
since
we're
not
talking
about
intermediate
that
we
have
done
interrupt
with
a
number
of
parties,
so
I
think
we're
pretty
good
there
for
moving
the
document
forward.
F
I
really
want
also
to
talk
about
intermediate,
it's
quite
ready
for,
and
we
have
at
least
three
interoperable
implementations,
so
I
think
it
it's
absolutely
ready
for
group
class.
C
I
I
know
that
I
have
you
actually
get
getting
your
emails,
but
I
have
been
to
too
busy
with
other
things,
to
be
able
to
actually
go
through
it
and
and
put
it
forward
so,
but
I
will
try
to
get
it
after
this
meeting.
A
G
Okay,
so
an
update
on
labeled
ipsec,
there
are
just
a
few
minor
fix.
Ups
in
the
text,
there's
a
little
bit
of
added
text
in
the
security
section
and
we
added
an
implementation
section,
but
currently
only
librisfon
on
linux
has
implemented
this,
so
we
have
implemented
in
librisfon.
It
is
working
with
sc
linux
as
the
the
underlying
security
system
that
transfers
that
uses
the
labels
that
are
transmitted
and
so
for
for
rel
for
red
hat.
G
We
now
have
a
a
path
forward
from
ike
v1
to
ikv2,
which
is
why
why
we
wanted
to
have
this,
so
there's
no
interrupt
testing
done.
If
anyone
else
has
implemented
this.
I
would
like
to
to
interrupt
test
it
that
we
are
using
private
number
241
and
I
think
it's
ready
for
broken
group
last
call.
We
only
had
minor
changes
at
this
point,
maybe
to
an
early
code
point
but
yeah.
That's
it.
C
Yes,
so
it's
called
what
it
is.
This
is
actually
the
241
is
in.
I
just
tried
remember
what
was
the
core
point,
which
registry
this.
C
Which
register
this
code,
private
number
you
are
using,
is
taken
from
it.
It
is
it's
not
a
notification.
This
is
something
I
try
to
remember.
Oh,
it
was
a.
C
Yeah,
okay
yeah,
so
those
are
expert
review
stuff.
So
yeah.
If
you
tickle
the
stable
and
we
can
start
the
last
call,
then
I
think
we
are
going
to
actually
keep
that
because,
as
I
said,
therefore,
there
is
no
official
early
code
point.
We
start
you
starting
to
email
and
or
request
a
code
point
to
be
allocated
and
then
because
it
goes
to
the
expert
review
and
and
so
on
it
actually
goes
directly
to,
and
so
so
you
can
just
start
that
yourself.
H
C
B
I
clicked
the
wrong
button:
okay,
hi
yeah,
so
this
is
the
update
to
the
iptfs
draft
next
slide.
Please.
B
So
we
published
two
drafts
one
during
the
meeting
after
the
cut
off
the
gate
opened.
The
changes
were
largely
based
on
list
discussions.
One
of
the
additions
was
a
clarification
that
the
fragments
need
to
follow
in
subsequent
sequence
numbers
we
added
a
zero
comp
on
receive
sort
of
feature,
but
this
generate
a
lot
of
discussion.
B
I
got
a
slide
on
that
and
then
we
published
a
new
version
where
we
removed
the
zero
conf
we
removed
the
ip
protocol
number,
we
did
retain
the
payload
type
and
we
made
some
congestion
control
changes.
I've
got
another
side
and
that's
the
next
slide.
B
So
the
ip
protocol
number
originally
at
108
benjamin
and
said,
do
the
request.
Tarot
said
this
is
too
much
trouble
to
justify
this,
so
we
do
need
to
to
have.
We
don't
always
have
state-based
negotiation
like
ike,
so
we're
going
to
keep
the
payload
type,
but
we're
just
going
to
have
it
be
an
esp
payload
type
and
pick
the
number
five.
This
does
happen
to
correspond
with
ipv5,
which
is
not
actually
deployed
and
used.
So
the
number
wouldn't
actually
conflict
with
anything.
B
It
seems
that
was
our
backup
plan
and
it's
pretty
straightforward.
It's
not
gonna.
We
don't
have
to
ask
anybody.
B
Zero
comp
received
support,
so
this
this
was
just.
This
is
really
just
about
it's
very
simple
to
implement.
You
can
receive
ipt
fest
frames
and
it's
useful
in
non-like
scenarios.
It's
just
goes
to
one
of
these
things
where
the
more
configuration
you
have
to
get
right,
the
more
chances
of
getting
it
wrong.
B
So
you
know
we
saw
this
as
a
nice
addition.
It
doesn't
you
know
it's
not
it's
not
like
critical
to
have
it.
It
just
makes
it
easier
to
deploy,
but
so
this
was
controversial
and
so
we
removed
it
next
slide.
Please.
B
So
the
congestion
control
I
made
these
changes
to
match
rfc
5348,
which
is
the
the
reference
implementation,
that's
tcp,
friendly
that
we're
referencing
in
the
document,
and
we
we
identified
these
changes
as
good
to
make
in
a
pre-transport
review
and
during
the
implementation
of
it.
B
The
primary
changes
are
before
we
had
this
last
sequence
number
and
because
we
were
sending
at
a
fixed
rate,
we
thought
okay,
if,
if
the
sender
you
know
if
the
receiver
sends
back
the
last
sequence
number
that
it
received,
you
could
sort
of
in
inter
interpolate
interpolate
the
time
that
you
sent
it
based
on
the
sequence
number.
This
is
just
this
ended
up
just
being
overly
clever
it
also.
B
You
know
if
people
down
the
road
want
to
do
different
types
of
things
with
the
non-fixed
time,
not
you
know
non-constant
rate
sending
it
doesn't
work
for
that,
so
it
just
seemed
better
to
go
with
what
you
know
the
standard
way
to
do
it
right,
which
is
what
tcp
does
and
dccp
does,
and
everything
else
seems
to
do,
which
is
that
you
send
a
timestamp.
B
The
sender
sends
a
timestamp
which
is
opaque
to
the
receiver.
So
there's
no
synchronization
issues,
it's
just
a
number,
but
you
know
it'll
be
its
clock
when
it
sends
it
and
the
receiver
then
marks
the
time
locally
when
it
receives
it
and
when
it
echoes
that
and
then
it
puts
that
value
in
in
the
echo
field
and
returns
it
along
with
that.
It
sends
the
echo
delay.
So
you
know
it
didn't
time
stamp
when
it
received
and
when
it
sends
it
back.
B
It
looks
at
the
new
the
latest
clock
and
gives
a
delta,
so
it
sends
a
delta
back
along
with
the
echoed
value,
and
then
the
the
sender
on
receiving
that
echoed
value
can
just
take
the
current
clock:
minus
the
echoed
value
minus
the
delay
and
that's
the
actual
round
trip
time
without
needing
any
synchronization.
B
Additionally,
to
that,
we
added
the
transmit,
delay
and
needed
this,
because
you
can
get
in
situations
where
you're
you
know.
If
you're
you
know,
if
you're
going
from
dc
to
san
francisco
or
new
york
to
london
right
you've
got
a
long
round
trip,
but
if
you're
going
across
a
data
center,
your
round
trip
time
can
be
really
tiny.
B
But
the
actual
logical
round
trip
time
is
based
on
your
send
rates
right
because
you
have
a
transmission
delay
you're
only
sending
packets
every
so
often
to
match
a
certain
bandwidth,
so
the
transmit
delay
is
the
the
sender
of
this
value.
This
is
saying
what
that
value.
You
know
what
that
transmission
delay
is,
and
it
knows
what
that
is,
because
that's
exactly
how
often
it
sends
a
packet,
so
it
just
puts
that
value
in
there.
B
This
can
change
in
congestion
control
because
you
might
be
slowing
down,
so
you
need
to
keep
reporting
it.
So
basically
you
take
you.
Take
these
two
round
trip
times
the
one,
the
actual
one
on
the
wire
and
the
transmit
delay,
which
is
your
train,
your
transmit
delay,
plus
their
transmit
delay,
and
you
pick
the
bigger
one
and
that's
your
actual
round-trip
time
estimate.
B
So
the
open
issues
from
the
last
meeting
was
were
that
job
had
suggested
that
we
should
do
a
transport
review.
I
think
that's
a
good
idea.
I
think
that
the
idea
here
is
that
you
know
everybody
in
this
room
is
an
expert
on
ipsec
and
they
can
understand
the
basic
protocol
here
and
it
all
looks
good,
but
you
know
people
you
know
are
thinking
well,
we
don't
really
know
too
much
about
congestion
control,
so
we
need
to
get
a
transport
review,
so
our
latest
version
is
based
on
implementation
experience.
B
B
We
also
had
a
meeting
with
david
black
from
transport
area
and
you
know,
got
some
good
feedback
and
he
said
yeah.
You
know
just
put
the
put
the
review
in
and
we're
ready
to
go
on
this.
I
think.
A
Next
slide,
please,
if
I
can
interrupt,
we
have
asked
for
a
transport
area
review
and
it's
still
pending
it's
assigned
to
joe
touch
not
to
david
black
and
they
still
haven't
completed
the
review.
So.
B
Oh
okay!
Well
I
I
didn't
even
know
we
should
probably
well
if
they
haven't
have
they
started,
but
we
should
let
them
know
that
we
did
this
update
to
add
that
the
ts
val
t
echo
change
they'll.
A
C
Most
of
most
of
the
people
when
they
start
to
do
the
review,
they
do
the
latest
version
anyway
for
the
for
the
draft
right,
they
don't
do
that.
We
didn't
request
for
specific
version.
We
asked
for
the
latest
version
so
when
they
start
doing
the
review,
they
usually
take
the
latest
one
but
email
to
the
reviewer,
saying
that
there's
new
version
might
be
a
good
thing
if
they
have
already
started,
but
I
don't
think
people
do
it
very
quickly
when
they
start.
C
B
Oh
okay,
thanks
so
the
so
the
other
notes.
We
again
we
do
have
an
implementation,
as
we
did
in
vpp
and
the
ike
changes
we
did
in
strong
swan.
As
part
of
that,
I
did
the
vpp
to
strong
swan
or
I
made
it
work
together.
B
There
was
some
stuff
out
there,
but
it
wasn't
fully
functional
and
we
do
have
congestion
control
support
in
this,
like
b2
support
and
we're
in
a
publication
process
now,
so
we
have
to
go
through
some
bureaucracy
to
actually
get
it
published,
but
we're
hoping
to
release
this
next
month
and,
as
always,
we're
open
to
collaborating
and
interoperability
testing
next
slide.
B
So
we
think
that
moving
forward,
we
think
that
all
the
issues
on
the
you
know
the
base
document
outside
of
the
congestion
control
have
been
addressed.
In
this
current
version,
it
was
really
the
ip
protocol
number
allocation
and
and
that
zero
comp
thing
now
that
I
know
that
the
transport
review
is
happening,
that
that
action
is
going.
So
we
were
going
to
say
is
this?
Can
we
do
this
part
of
the
working
group
last
call,
which
is
pretty
pretty
normal
yeah?
So
that's
the
question.
C
So
for
doing
this,
so
so
for
working
group
last
call,
I
have
to
read
it
myself
before
I
can
actually
see
if
it
actually,
I
would
usually
read
them
before
I
I
could
actually
see
if
it's
ready,
I
mean
when
I
was
actually
reading
it
quickly.
I
realized
that
then
I
wrote
this
this
congress
congestion
control
stuff,
and
then
I
realized
that
I
have
to
ask
for
the
transport
area
for
the
protocol
ip
protocol
number.
As
I
said,
I
don't
think
we.
C
The
reason
I
was
objecting
is.
I
was
saying
that
I
don't
think
we
need
an
early
version
because
we
can
do
our
internal
testing
with
you
know,
just
by
version
two
and
saying.
Okay,
if
you
have
this,
you
know
thing
there.
Then
you
can
do
it,
but
the
I
think
we
can
still
allocate
the
ip
protocol
operating.
That
might
be
better
better
if
you
actually
need
to
have
an
ip
protocol.
Of
course,
I
was
what
I
was
saying.
C
We
could
just
use
zero
or
something
like
that
said
that
ignore
the
ip
protocol
number,
because
we
know
what
is
in
there
I
mean
for
esp
it's
a
transport
mode
or
tunnel
mode,
and
the
protocol
number
is
for
tunnel
mode,
it's
actually
completely
useless.
It
actually
is
never
ever
anything
else
than
the
one
of
this
you
know,
but
for
a
transfer
mortgage
needed.
So
I
was
thinking
about
a
little
bit
similar
kind
of
thing.
B
So
I
I
think
that
that
I
think
that
we
could
do
the
you
know.
Why
don't
we
stick
with
the
value
five?
You
know
as
a
esp
transport
payload
type,
and
you
know
it's
not
really
squatting,
but
no
one's
gonna
use
that
because
it's
allocated
but
unused.
That
was
our
thinking.
Actually
I
think
lou
is
in
the
room
and
he's
co-author
on
ipv5
work.
So
he
was
like
we'll
just
use
that
so.
B
If
that's
okay,
I
mean
we,
we
can
try
to
do
the
ib
protocol
number,
but
I
I
I
don't
want
to
hold
the
work
up
on
on
that
because
it
doesn't
seem
critical
and,
like
you
were
saying,
if
people
do
want
to
use
it
outside,
we
could
always
do
that
work
either
way.
I
think
we
just
we're
just
interested
in
moving
it
forward.
C
Yeah,
but
I
think
the
ip
allocates,
I
don't
remember
what
the
allocation
policy
theory
is
for
for
normal
is
it?
Is
it
actually
standardization
required
or
what?
But
I
don't
think
it's
expected.
I
think
it's
higher
bar,
so
so
to
get
it
before
they
actually
go
into
the
publication
requested
and
addressed
the
allocation
is
going
to
be
required
earlier
location.
But
of
course
the
question
is:
if
it's,
if
it's
almost
ready,
then
it's
not
that
far
away
but
yeah
and,
of
course,
with
the
early
allocation
stuff.
I
I
Thing
yeah
yeah,
it's
a
fairly
heavy
bar,
but
we
can
still
request
an
early
allocation
and
with
the
early
allocation.
If
it
is
granted,
then
you
know
after
a
year
we
can
renew
it.
Just
with
the
working
group
chairs,
saying
yeah
we're
still
working
on
this
and
after
you
know
the
second
year,
then
the
isg
has
to
approve
it,
but
we
tend
to
be
happy
to
renew
them.
If
the
draft
is
still
something
that
we
think
is
going
to
happen.
I
C
Yeah,
so
I
I
I
think
there
are
most
of
the
things
I
did
because
I
think,
as
long
as
you're
only
using
it
in
that,
I
still
don't
think
we
actually
need
that,
because
we
can
always
negotiate
like
version
two.
If
we
actually
have
some
other
uses
for
it
outside
like
an
ipsec,
then
I
think
we
need
that
one
definitely
and
then,
but
then
I
actually
would
not
want
to
get.
You
know
more
feedback
from
people
who
are
actually
using
it
somewhere
else
than
in
ipsec,
because
of
course,
there's
nobody
here.
B
Yeah,
that's
so
this
is
our
motivation
for
just
saying:
forget
it
right,
we
just
we.
We
have
people
that
want
to
see
this.
You
know
get
standardized.
So
it's
you
know
it's
just
easier
to
go
the
with
the
flow
here,
and
so
that's
why?
Let's
just
do
the
esp
protocol
payload
type
right
and,
like
you
said,
tarot
it
doesn't,
it
doesn't
actually
have
to
be
an
ip
protocol
number
even
right.
We
because
we
own
the
esp
payload
type
space.
B
So
you
know
we'll
just
pick
five
and
that
way
we're
picking
we're
picking
a
number
no
one's
ever
going
to
allocate
because
it's
already
allocated.
So
if
down
the
road
somebody
wants
to
do
this,
they
can
write
their
draft
that
uses
it
and
then
they
can
do
the
ip
allocation
number.
You
know
they
can
do
the
allocation
request
as
a
part
of
what
they're
doing,
and
I
think
that
matches
what
you're
saying
yeah.
A
Topic
the
question
for
ben
is
whether
we're
going
to
get
sat
down
if
we
do
follow
this
advice
and
just
stick
a
five
in
there.
I
It's
possible
that
we
will
get
pushed
back.
I
don't
have
a
super
great
sense
right
off
the
top
of
my
head.
C
I
I
think,
if
somebody's
going
to
comment,
then
we
are
then
it
happens
at
the
late
of
the
ist
process
and
then
we
can
say:
okay,
we
allocate
a
new
one.
We
are
looking
at
the
proper
ip
number.
Then
that's
our
solution.
C
Five,
then
we
say:
okay,
let's
allocate
a
new
one,
how
about
five,
because
we
can
actually
try
that
so
what
we
can
actually
do
at
that
point,
if
we
say
that
the
five
is
actually
never
going
to
be
used,
we
can
actually
then
later
make
an
you
know,
proposal
to
ist
and
say
that,
okay,
how
about
we
actually
repurpose?
This
number
five
to
is
used.
C
C
B
Okay
yeah,
so
this
is
an
update
on
the
yang
model
for
ippfs
yeah.
As
you
mentioned,
this
is
go
ahead,
we'll
I'll
get
to
that.
B
So
the
changes
since
108
just
some
reminders,
the
you
know.
The
objective
here
is
just
to
get
a
yang
model
to
support
iptfs
the
approaches
that
we're
going
to
augment
the
only
ip
second
model
that
we
can
find,
which
looks
you
know
done,
which
is
this
sdn
ipsec
flow
protection.
It
actually
works
pretty
well,
there
was.
There
was
an
open
issue
with
it.
It
didn't
actually
work
originally
because
they'd
split
the
essay
database
and
the
policy
database
and
they
put
it
into
iklis.
B
B
They
have
these
notifications
for
the
iklas
mode
to
implement
the
eclipse
mode,
and
so
we
asked
them
to
mark
them
as
features,
and
what
that
means
in
yang
is
that
you
don't
have
to
do
them.
B
So
that
means
somebody,
you
know,
can
use
the
iklas
and
ike
model
together,
even
in
the
ike
case
right
there,
and
they
can
put
that
you
know
they
can
use
the
assay
database
from
the
I-class
model,
so
that
got
us
to
where
we
needed
to
be,
and
so
we
we
updated
the
latest
version
to
refer
to
the
the
to
the
latest
versions
of
of
those.
The
sdn
ipsec
flow
protection
that
one
that
the
version
the
base
document
there
seems
like
it's
moving
forward.
B
It's
get,
you
know
getting
basic.
I
think
benjamin
probably
he's
been
working
with
tom
patch
to
get
that
sort
of
nailed
down,
but
seems
fine
next
slide.
B
I
think
I
might
have
yeah,
so
this
is
what
I
just
talked
to
so
it's
they
intentionally
left
the
essay
database
out
and
they're
missing
some
information,
yes
say,
oh,
so
I
should
mention.
Also,
we
put
some
basic
ipsec
counters
into
the
into
the
ike
model
and
the
sa
and
it's
just
rx
packets
and
bytes,
received
our
octets
received
and
transmit,
received
and
drops
next
slide.
B
So
these
are
the
things
that
we
we
have
inside
there
to
configure,
which
is
whether
you
want
congestion
control,
the
fixed
size
of
the
packet
or,
if
you
want
to
use
path
mtu
or
if
you
want
to
use
that
path
mtv
to
lower
it,
the
bit
rate
either
specified
as
l3
or
lt
bitrate,
and
whether
to
allow
fragmentation,
you
know
you
can
add
to
these
vendors
can
add
to
these
if
they
want
later,
but
that
that's
the
standard
settings
next
slide,
please.
B
These
are
the
statistics
that
I
mentioned.
The
the
top
ones
of
the
ipsec
counter
is
very
basic.
Both
of
these
are
also
implemented
as
features,
so
somebody
input
you
know
wanting
to
do
a
minimal
implementation
doesn't
actually
have
to
input
either
of
these.
They
just
have
to
do
the
configuration
next
slide,
please
so
we
we'd
like
to,
and
we
this
is
pretty
straightforward
stuff.
So
we'd
like
to
ask
for
working
group
adoption
on
this,
but
that's
our
last
site.
I.
C
Think,
okay,
I
have,
I
don't
remember
if
this
is
actually
this
probably
isn't
our
charter,
because
I
think
young
models
for
this,
and
so
I
don't
think
we
actually
need
to
do
anything
for
that,
and
but
this
is
quite
new
stuff.
I
don't
think
there
has
been
that
many
people
who
actually
read
this
so
that
I
would
like
to
you
know
we're
gonna
have,
of
course
we
can
actually
start
a
working
group
out
of
sinkhole
and
then
people
will
probably
hopefully
read
it
and
comment
on
it.
B
Yeah
that
that
probably
would
be
good
it's
because
nobody
likes
to
read
yang.
So
if
we
we
might
be
waiting
forever,
if
we
do
the
call
it
might
cause
the
people
to
read
it,
it's
really
straightforward.
It's
you
know,
it
is
only
a
few
pages.
I
think
yeah.
It's
just
configuration
and
stats.
C
One
of
the
question
I
had
actually
is
because
this
actually,
I
have
no
idea
about
the
angle,
but
you
were
having
this
things
here,
saying
that
I
assume
these
ones.
These
configuration
parameters
are
something
that
can
be
changed
on
the
fly,
so
so
somebody
gonna
go
and
say
that
okay,
I
want
to
change
the
bitrate
to
be
something
different,
which
is.
This
has
actually
always
been
problem
with
you
know.
If
people
have
been
trying
to
use
the
traffic
flow
confidence,
they
have
been
okay.
B
C
Yeah,
so
so
the
question
is
that
actually
one
of
the
things
I
actually
had
realized
that
actually
having
you
know,
algorithms,
that
kind
of
things
in
young
also
that
would
also
probably
allow
them
to
be
changed.
Is
there
actually
any
way
to
in
young
say
that
you
can't
modify
this
after
it
has
been
insta
installed.
B
You
can't
do
that
in
syntax,
but
you
would
do
it
in
the
description
you
could
say
in
the
description
this
could.
If
you
modify
this,
it
will
read,
you
know
we'll
do
a
renegotiation
in
the
usa
or
something
you
can
put
that
in
the
description.
C
Yeah,
because
one
of
the
things
I
realized
that
there's,
I
didn't
see,
that
kind
of
things
into
sdn
stuff
and
I
was
thinking,
but
I
should
probably
actually
comment
and
mark
ask
them.
Actually
somebody
should
go
through
the
model
through
and
check
out
which
of
those
are
something
that
needs
to
be
changed,
but
anyways
that's
actually
a
little
bit
different.
So
anybody
has
any
comments
on
this
document.
C
C
C
C
Probably
we
to
start
a
working
group
last
call
for
that
also,
but
we
have
to
check
out
it
first.
A
One
thing
that
came
up
on
the
jab
room
that
four
years
ago
there
was
a
draft
by
muhammad
about
deprecating
ipe
version
5
as
another
over
again
isg
statement.
So
it's
back
to
available
so
using
it
now
is
squatting.
B
I
C
F
Currently,
hello.
F
Okay,
so
let's
preload
inaccurate
tool
next,
please
so
there
is
just
about
motivation
and
we
have
a
working
draft.
F
Key
e
that
addresses
issues
of
using
large
keys
and
multiple
latch
keys
that
are
common
in
post
quantum
key
exchange
method
methods
in
like
two,
but
this
draft
still
limits
the
size
of
any
single
key
to
64
kilobytes
and
it's
the
maximum
size
of
okay
to
preload.
F
And
if
we
look
at
the
neast
current
state
or
the
third
round,
so
most
candidates
fit
into
in
this
restriction.
F
F
So
another
consideration
that
we
have
in
mind
is
that
probably
with
post
quantum
signatures
will
always
have
either
signature
size
or
public
key
size
that
will
exceed
that
would
probably
exceed
64
kilobytes
limit,
so
they
in
this
case.
Yes,
they
wouldn't.
E
F
F
So
the
these
data
blocks
are
public
keys
for
key
exchange
signatures
and
certificates,
and
we
want
to
do
to
make
it
the
backward
backward
compatible,
and
we
also
want
to
address
reliability
and
transference
at
large
data
in
iq2
and
we
want
to
introduce,
as
as
as
minimum
changes
to
the
current
protocol
as
possible.
F
G
F
F
Is
as
a
follower,
so
if,
if
the
data
doesn't
fit
into
signal,
payload
then
split
data
into
chunks,
each
smaller
than
64
kilobytes
and
put
these
chunks
into
successive
reloads
at
the
same
time
so
receiving.
F
That
it
will
extract
from
this
and
it
works
well
if,
if,
if
a
message
contains
only
can
contain
only
one
preload
well
in
ixtake
machine,
the
message
contain
only
one
one
payload
of
this
time
in
the
message.
So
it's
true
for
key
exchanging
hours.
It's
a
single
payload,
there's,
no
ambiguity
of
extracting
data
from
them,
and
it's
not
true
for
safety
loads,
because
there
are
multiple,
there
can
be
multiple
set
loads
and
each
with
certificates.
F
If,
if
he
put
a
single
certificate
into
multiple
state
but
set
the
load,
it
would
be
possible
to
to
properly
distinguish
between
several
certificates,
but
it
can
be
workaround,
it's
a
problem,
but
it's
not
not
not
showstopper,
and
so
there
is
a
pro.
Another
problem.
Is
that
all
these
loads,
if
they
appear
in
encrypted
reload,
is
an
encrypted
load
size
won't
fit
into
64
kilobytes.
It's
it's
clear
that
it
will
be
greater.
F
So
it's
it
can
be
also
work
around,
because
the
size
of
encryptable
load
can
be
always
deducted
from
the
size
of
like
message,
because
it's
always
the
last
ballot
and
the
message.
So
it's
the
length
if
you
encrypted
for
load,
it's
useless
is
useless.
It
can
be
set
to
say
zero
or
something
like
that.
It
doesn't
mean
it's
it's
not
needed,
so
it's
not
a
big
deal.
So
next,
please.
F
So
this
is
an
example,
just
high-level
example
how
it
can
be
looked
so
you
can
see
that
there
are
several
key
exchange
reloads
that
all
contain
a
single
in
inside
intermediate
exchange
that
all
contain
a
single
public
key
and
note.
E
F
In
the
initiator
request
message
in
the
responder's
response,
the
number
of
these
loads
can
be
different,
so
the
size
is
the
the
size
of
the
key
exchange
in
request
and
response
can
be
different.
That's
very
well
suited
for
encapsulation
exchange
methods
that
is
common
for
what
quantum
cryptography
and
also
in
like
also,
you
can
see
that
we
can
put
several
hours
below
it
and
see
if
signature
doesn't
fit
into
one.
So
next,
please.
F
F
F
F
And
I
think
that
we.
F
Issue
that
not
the
issue,
but
I
think
we
will
will
introduce
a
new
mod
when
ike
will
switch
from
udp
to
tcp
and
esp
will
remain
in
plane
or
edp
encapsulation,
if
it,
if
it
possible,
so
it
will,
it
will
avoid
a
necessity
to
encapsulate
the
ipc
in
gcp
because
for
performance
reasons
it's
not
very
good
idea,
so
either
we
do
all
in
tcp
or
we
do.
I
can
tcp
and
ip
second
udp
on
play,
so
I
think
it
will
address
the
reliability
and
transfer
in
the
religion
that
I
like.
F
So
the
purpose
of
this
presentation
is
to
guard
and
working
group
interest
in
this
topic.
So
is
it?
Is
this
problem
worth
to
address
and
is
the
suggestion
suggested
approach,
a
real
number?
So
these
are
questions
to
the
group.
C
Yeah,
so
if
anybody
has
any
comments
come
to
you
know,
I
might
from
my
personal
view.
I
think
this
is
hard
to
answer
the
questions.
I
think
this
is
worth
of
addressing
and
I
think
I
think
actually
it
would
be
better
to
do
some
other
approach
to
that.
C
I
was
thinking
about
having
one
bit
in
the
reserve
fields
of
the
header
to
say
that
this
is
not
the
last
one,
meaning
the
not
the
last
fragment,
and
that
would
indicate
whether
you
need
to
combine
it
with
the
next
one
or
or
or
whether
it's
a
standalone,
and
that
would
actually
solve
the
problem
that
it
actually
would
work
with
any
payload
type,
regardless
what
it
is,
and
of
course
it
will
still
mean
that
if
there's
implementations
who
check
the
reserve,
then
like
barf,
if
there's
non-zero
values
there,
that
they
will
barf
but
that's
happening
anyway,
because
I
mean,
if
you
have
any
payload,
that
kind
of
payloads,
they
will
not
talk
with
the
old
versions
that
don't
support
this
anyway.
C
So,
but
that's
that's
my
comment,
so
I
think
you're
up
next.
A
Yeah
hi,
so
I
think
it's
worth
as
an
individual.
I
think
it's
worth
doing.
I
think
we
had
previously
needs
for
larger
payloads
like
where,
with
config
payload,
when
we
wanted
to
send
a
large
amount
of
routes.
Well,
they're,
not
routes,
they're
traffic
selectors
in
the
config
payload,
but
yeah
the
same
thing
and
we
were
limited
by
the
64k
which
was
okay
but
nothing.
A
F
Well,
the
motivation:
what.
F
So
this
approach
is
very
simple
and
it
doesn't
require
any
change
to
belong,
parsing
or
well
a
little
very
little
change.
So
that's
why
it
was
taken.
But
if
you,
if
you
want
to
change
a
generic
preload
format,
well,
it's
possible.
I
agree
it
probably.
A
To
the
protocol
to
me
having
getting
several
payloads
of
the
same
type
and
then
knowing
that
when
you
get
these
pills,
you
have
to
merge
them
into
a
large
payload
at
the
receiver
and
that's
more
complex
than
just
having
an
alternate
failure.
But
that's
probably
implementation
dependent.
I
think.
F
Large
balloons,
the
other
case,
is
to
make
like
messages
as
small
as
possible.
Well,
not
not
for
this
particular
large
key
exchange
method,
but
using
ike
for
iot
on
on
on
the
like,
and
we
are
trying
to
make
as
small
as
possible
and
for
this
reason
to
enlarge
a
generic
reload
for
mods
so
that
it
will
take
not
not
not
for
children
not
to
take
provide
but,
for
example,
eight
bytes.
It's
not
very
good
idea.
It
must
at
least
support
both
formats
as
compact
and
large,
and
something
like
that.
F
So
call
for.
C
F
C
I
would
really
like
to
see
a
couple
of
comments
on
people,
and
actually
I
was
really
thinking
about.
We
should
probably
have
a
little
bit
more
discussion
about
what
would
be
the
best
way
of
you
know
having
pros
and
cons
on
different
things
on
on
on,
for
the
actual
you
know,
implementation,
you
know
either
having
you
know,
I
think
three
octaves
is
too
low.
C
That
means
that
we
have
more
than
255
fragments
or
these
kind
of
payloads
that
need
to
combine
together,
which
actually
start
to
get
really
a
little
bit
annoying
already
and
and
that's
actually
it's
one
of
those.
You
know
question
is,
if
you
actually
have
that
big
payload,
then
I
think
you
know,
chasing
the
payload
format
to
be
would
be
either
better,
because
I
mean,
if
you
have
have
to
combine
you
know
hundreds
of
these,
then
it
gets
a
little
bit
annoying.
C
Yeah,
but
we
are
using
yeah
yeah,
of
course,
but
even
in
tcp
you
know
the
yeah.
The
payload
format
is
still.
I
mean
if
you
use
this
method
that
we
have.
You
know
multiple
of
same
payloads
with
maximum
length
of
64
case,
and
we
want
to
send
one
megabyte.
We
still
have
what
we
have.
Let
me
see:
32
sorry,
16
16,
you
know
payloads.
We
have
to
come
by
to
send
one
megabyte.
C
So
but
anyway,
so
I
so,
I
think
we
don't
want
to
get
people
to
read
this
document.
This
is
so
so,
do
you
have
the
craft
that
is
already
in
the
that?
Has
all
the
discussion
about
this.
F
C
All
right,
yeah
yeah,
but
if
you
actually
would
take
this
document,
this
different
approaches
to
the
list
and
we
could
have
started
discussing
on
the
list
about
what
would
be
the
best
of
the
different
approaches
and
what
would
be
the
good
things
and
bad
things
about
those,
because
people
have
different
views
and
different
and,
as
I
said,
they
were
actually
yeah.
One
of
the
things
that
people
also
wanted
to
see
was
actually
transport
and
configuration
payload.
C
They
wanted
to
transport
like
whole
configuration
files
where
you
have
a
text
file
which
has
you
know
the
whole
configuration,
and
that
can
be
actually
quite
big
and
that's
what's
one
of
the
things
that
they
were
saying.
Oh,
we
won't
use
gfk
set
to
set
the
configuration
to
all
of
our
remote
devices
and
then
we'll.
A
F
So
this
this
draft
was
presented
in
itf
108
and
since
we
received
some
comments
and
one
comment-
was
a
complexity
induced
by
mixing
attributes
in
one
in
a
single
attribute
format.
F
F
Origin
blade,
so
we
issued
next
new
version
which
incorporated
this.
Yes
next
place
all
these
changes.
So
there
is
a
new
single
attribute.
New
attach
sorry
attribute.
F
But
we
introduced
six
different
attribute
types
with
the
same
format
for
so
that
each
each
type
of
intercontinental
and
ip
family
is
carried
in
into
this
into
dedicated.
F
Type,
so
we
included
port
number
in
this
format
and
we
remove
scope
beat
because
it
was
controversial
and
actually
the
most
common
that
it
is
not
okay
to
use
encrypted
dns
servers
outside
tonight.
So
next,
please.
F
So
separate
attribute
types:
it's
it's.
There
is
a
trade-off
between
complexity
and
the
size
of
the
message,
so
we
decided
to
simplify
processing
so.
E
E
F
Has
its
dedicated
attribute
type,
so
it's
it's
like
negotiation
client
includes
all
the
attribute
encrypted
and
it
encrypted
dns
type
it
supports,
and
the
server
returns
back,
one
or
probably
a
few
of
them,
which
it's
also
supported.
It
is
configured
then
as
but
each
attribute
type
each
attribute
can
contain
several
addresses.
F
Well,
the
the
reason
for
this
simplification,
the
justification
for
it
is
that
in
additive
working
group,
encrypted
dns
is
mostly
considered
as
equivalent
to
unencrypted
encrypted
resolvers
are
equivalent
to
53
resolvers,
so
it
it
must.
F
F
You,
for
example,
would
choose
one
of
the
supported
encrypted
dns
types
and
we
have
the
same
results
in
create.
So
it's
it's
like
like
negotiation.
That's
why
we
decided
to
separate
attribute
title
for
each
indiana
style,
and
next,
please
so
portable
is
included
for
as
a
comment
from
dog
authors
and
it's.
F
F
A
F
Dog
servers
may
support
more
than
one
template
and
the
client
uses
well-known.
We
recent
four
to
discover
these
templates.
This,
like.
F
And
it
is
covered
by
the
in
the
draft
by
tv
home
and
it's
just
an
example
and
we
we
will
use
whatever
mechanism
the
devoking
group
will
choose.
F
So
comment
questions.
It
seems
that
hd
working
group
is
not
interested
in
this
draft,
because
they're
more
focused
on
basic
negative
functionality,
so
if
ipsec
can
be
working
group
is
interested.
So
it's
probably
the
right
time.
J
Hello,
can
you
hear
me
yep
great?
Yes,
thank
you
for
presenting
this
moving.
Definitely,
the
document
seems
in
better
shape
than
it
had
before.
I
like
some
of
the
changes
regarding
the
relationship
with
adb,
specifically,
I
actually
would
like
to
urge
us
to
not
necessarily
adopt
or
move
this
work
forward
and
what
more
has
been
done
in
addi,
specifically,
some
of
the
mechanisms
we're
looking
at
there.
J
Details
like
the
alternative
protocols
or
the
ports
could
be
handled
in
a
more
generic
mechanism,
and
that
may
not
be
the
case,
but
it
may
be
the
case,
and
I
don't
think
we
should
jump
the
gun
here
and
end
up
having
a
conflicting
approach.
I
think
in
general
what
we
could
do
in
ike
should
align
with
whatever
we
end
up
putting
into
dhcp
and
ra
for
bootstrapping
trust
in
the
same
way
of
the
encrypted
resolver.
J
A
Yeah
but
as
mentioned
in
the
discussion.
A
A
So,
as
mentioned
in
the
job
room,
the
existing
trust
is
different
from
or
trusted
posture.
It's
different
for
dhcp,
as
opposed
to
ike
in,
like
we
already
know
who
the
the
gateway
is.
The
other
batteries,
the
pier,
whereas
in
dcp
we're
just
sending
him
out
of
broadcast
and
waiting
for
some
information
there.
So
the
challenges
are
different.
A
G
If
it's
a
public
one,
then
sure
there
might
be
public
discovery
mechanisms
you
can
use,
but
if
it's
like
a
an
internal
one
and
there's
a
split
vpn
and
so
there's
a
split
dns
as
well
with
an
internal
only
zone
and
the
name
is
internal
only
zone
and
how
you
reach
that
name
without
actually
getting
to
the
name
server.
So
I
think
there's
there's
definitely
an
additional
bootstrap
problem
that
might
need
to
be
resolved
and
that
might
require
actually
sending
some
kind
of
cert
payload
for
the
for
the
tls
connection
or
the
https
connection.
K
Hello,
can
you
hear
me
yeah
hello,
yeah,
hey
yeah,
I
would.
I
would
like
to
respond
to
some
of
the
comments
from
tommy
and
walter.
The
first
one
is
that
this
graph
does
not
define
the
some
of
the
mechanisms
for
discovering,
for
example,
the
doh
templates.
K
It's
pretty
much
relying
on
the
work
that's
happening
in
add,
and
we
are
not
defining
any
iq2
extension
for
conveying
that
uhuri
templates.
The
only
reason
why
you
see,
in
addition
to
the
resolver
name,
that
the
ip
addresses
and
port
numbers
are
being
converted
is
to
avoid
any
dns
or
53
lookup,
that
is
to
basically
avoid
a
clear
texting
slot.
K
That
was
the
reason
for
adding
the
portables
and
ip
address,
but
we
can
definitely
wait
for
the
outcome
of
the
discussions
that
I
think
many
of
us,
including
tommy,
and
we're
actively
participating
in.
I
had
working
group.
The
other
one
that
I
wanted
to
bring
up
was
the
comment
that
was
brought
up
with
regard
to
using
private
certificates.
K
K
It
can
still
have
a
public
certificate
but
use
private
ip
addresses
and
the
vpn
provider
can
still
get
use,
acme
and
other
protocols
to
have
an
public
domain
name
and
get
a
public
certificate,
but
make
sure
that
that
internal
dns
server
is
only
reachable
by
the
vpn
connected
clients
and
not
by
anybody
outside
the
network.
So
we
did
not
see
a
reason
for
sending
the
certificate
fingerprint
back
to
the
client
for
authentication
purposes.
C
Okay,
so
I
think
that
was
lost
from
the
queue
our
ad
was
saying
that
we
have
to
resharper
anyway
for
this
work,
so
we
can't
actually
just
adopt
it
yet
so
we
have
to,
but,
but
actually
that
doesn't
mean
that
that
actually
gives
us
some
time.
C
The
question
is
that
to
actually
want
to
add
recharger
to
do
this
kind
of
work
also-
and
I
think
there's
we
probably
want
to
go
up
or
go
to
list
and
ask
the
list
whether
people
are
saying
that
this
is
item,
that
we
should
be
adding
and
we
probably
want
to
get
some
other
things
also,
perhaps
that
we
have
to
check
out
what
other.
C
C
F
So
I
watched
cookie
processor
next,
please.
F
E
F
F
So
this
is
the
first
problem
scenario:
consider
the
network
that
is
very
bad
and
introduces
long
delays
and
high
packet
loss
so
initiated.
First.
Signs,
like
I
say,
need
request,
responder
response
with
cookie.
It
feels
it
only
feels
that
it's
under
attack
and
it
responds
with
a
cookie,
but
this
message
contains
cookie
requests
is
delayed
for
quite
a
long
time,
so
that
initiated
times
out
and
recents
its
initial
request
without
any
cooking.
F
E
This
response
is
also
delayed.
F
F
A
rack
2,
including
this
cookie
into
the
request,
but
this
request
get
lost
in
the
network.
After
some
time,
the
network
initiator
receives
resp
to
response,
and
also
consider
that,
I
can
say,
need
completed
so
at
this
point,
both
initiate
and
responder
things
that
I
can
say
in
it
has
completed,
but
they
have
different
view
on
what
was
the
most
recent
request
message
from
initiator
so
initiator
since
thinks
that
it's
wreck
2
well
responded
since
that,
it's
sorry
respond.
F
Regular
and
the
chat,
it
seems
like
it's
right
too,
so
as
a
result,
since
these
messages.
E
F
F
I
can
say
it
is
completed
again
initiate
the
response
has
have
different
views
on
what
was
the
most
recent
request
message
from
the
from
the
initiator,
because
initiate
a
sense
is
that
it
will.
It
contains
cookie
c1,
while
responder
thinks
that
it
contains
cookie,
c2
and
again,
authentication
will
frame.
So
next.
E
F
What
is
the
source
of
the
program,
the
source?
Is
it
like?
A
sir,
like
I
say,
immediate
request
can
be
sent
several
times
with
different
content
and,
depending
on
the
responder
state
and.
F
Since
it
is
later
played
into
into
the
house
below
calculation,
if,
like
I
say,
meet,
is
completed
when
initiator
and
responder
have
different
view
on
what
was
the
most
recent,
I
can
say
need
request,
so
in
this
case,
authentication
will
fail,
despite
that,
all
the
credentials
of
the
initiator
and
responder
are
correct,
and
they,
if
the.
E
F
So
what
is
similarity
of
this
problem?
Well
from
the
first
on
the
first
glance,
there
are
a
lot
of
preconditions,
so
network
must
be
really.
E
E
F
E
F
F
And
so
what's
the
proposed
solution,
I
think
that
we
can
work
around
this
situation
by
excluding
cookie
into
from
there.
I
can
say
I
can
say
you
need
request
message
if
it
is
present,
so
every
every
functionality
that
is
tied
to
cookie,
like
in
technology
token,
will
be
retained,
but
it
is
not
fed
into
the
house
followed
compilation,
and
next,
please.
F
So
how
this
can
how
this
can
look
like
the
shelter
sends,
like
I
said
in
each
request
message
a
responder
that
supports
this
revised
cookie
processor
includes
cookie
notification
containing
cookie
and
an
empty,
revised
cookie
notification
just
to
indicate
that
it
supports
this
extension.
If
initiator
doesn't
support
this
extension,
it
will
respond
as
usual.
F
It
will
ignore
a
revised
cookie
and
everything
will
work
or
doesn't
work
as
as
it
currently
happens,
but
if
initiator
also
supports
this
extension,
it
will
place
a
cookie
into
the
revised
cookie
into
the
new
revised
cookie
notification
in
recent
request
message.
So
this
will
indicate
this
one
indication
for
the
responders
that
respond
to
that
initiator
also
support
this
extension.
F
F
E
F
E
F
High
crito
and
requested
nothing,
probably
in
most
cases
it
requires
another
cookie.
What
what
is
change?
What
is
the
change?
The
change
is
into
in
the
output
calculation,
so
it
is
calculated.
F
F
F
F
That
wasn't
really
received
a
real
message.
One
so
revised
cookie
notification
is
removed
and
two
fields
are
updated
next
below
the
niketa
and
message
lane.
A
very
simple
update,
obviously,
for
this
field,
so
is
this
updated
message
is
spread
into
the
house
below
calculation.
G
I
had
a
question
so
if
you
initiate,
if
the
client
initiates,
I
can
say
in
it
and
then
it
it,
it
doesn't
get
a
response.
It
tries
again
and
then
eventually
it
will
abort
the
exchange
and
try
a
new
exchange.
It
will
likely
create
a
new
ke
payload
for
that
new
ike
essay
in
it.
F
F
So
that
it
completely
well
right.
G
G
F
C
D
F
F
G
Right,
okay,
yeah,
so
I
I
think
I'm
a
little
bit
in
agreement
with
with
joaf
on
on
the
chat
where
he's
like
is
this
case
worth
fixing,
because
you're
already,
assuming
that
there's
so
many
packet
loss
in
such
slow
network.
Even
if
you
get
a
tunnel
up
what
what's
left
to
do
with
it,
it's
going
to
be
unusable.
F
Well,
I
don't
know
again
if
it
depends,
we
encourage,
we
didn't
encounter
this
problem
in
stress
test.
Of
course,
it's
stress
test.
It
was
about
several
thousand
or
ten
thousand
of
eye
connections
that
simultaneously
I
clients,
not
data
type
clients
but
emulated
like
clients
that
simultaneously,
at
the
same
time,
going
to
the
respondent
and.
F
F
Of
initiators
and
attack
single,
responding
with
a
great
network
but
well
my
my
reason
for
this
to
this
draft
is
that,
from
my
point
of
view,
it's
it
it's
definitely
a
protocol
flow.
So
if
you
protocol
ended
up
with
timed.
E
F
F
So
if
timed
out
is,
is
is
okay,
it's
it's
a
metal
condition,
temperate
message
so
by
the
acme,
but
actually
check
is
also
a
key
samsung
problem
with
network,
but
authentication
free.
It's
something
function,
problem
with
my
certificate,
and
that
is
for
customer.
It
is
very
annoying
and
it's
very
I
don't
know
it's
not
a
good
thing.
C
H
A
Okay,
I
was
in
the
queue
to
channel
scott's
message
from
the
driver
room
wouldn't
having
the
implementation,
select
the
fresh
ike
spi
when
it
changes
cookies
solve
this
problem
without
the
need
for
protocol
change.
F
Well,
actually,
it
is
responder
who
changes
who
who
generates
a
new
cookie,
so
responder
just
responds
to
the
request
and
it
cannot
change.
I
conspire
and
for
initiator.
E
F
It's
it's
quite
possible
to
receive
several
different
cookies,
because
it's
in
the
draft-
sorry
it's
in
the
rfc,
I
critique
it's
quite
possible
situation
when
initiator
receives
a
first
cookie
request
with
cookie
one
and
then
cookie
request
with
cookie
two
and
it
just
resends
it,
because
it's
a
big
block
for
the
initiative.
It's
just
sent
us
back.
C
Actually,
I
think
in
this
case,
where
we
actually
have
a
cookie
and
you
change
the
secret.
I
think
most
of
the
case
is
actually
the
responder
cookie,
because
if
this
is
the
stateless
thing,
the
responder
spi
are
going
to
be
different,
because
this
is
sending
is
spi,
responded,
spiv,
zero
and
he's
responding
with
some
spi.
E
C
F
C
Here,
when
we
get
this
in
actually
actually
yeah,
so
we
actually
create
the
state
here
when
we
actually
get
this
one
and
yeah
actually
yeah,
it's
still,
it's
still
a
problem
yeah.
I
don't
think
it
actually
solves
the
problem.
C
C
So
this
is,
this
is
not
in
our
charter,
but
this
actually,
I
think
this
is
a
small
change
in
in
in
the
sunset,
some
sense.
E
C
C
I
Right,
I
think
that
this
would
fit
into
the
general
maintenance
small
topic
sorts
of
things
I
don't
feel
like.
We
need
to
recharter
to
do
this
all
right,
good.
C
Then
we
have
to
discuss
about
so
I
will
probably
take
it
to
the
list
and
and
then,
if
the
list
is
agreeing
that
we
should
actually
work
on
this,
then
we
should.
You
know,
start
probably
you
know
working
on
this,
but
I
think
we
want
to
verify
that
on
the
list.
Also,
all
right,
so
the
next
one
is
not
valerie.
F
G
Okay,
so
this
is
a
work,
I'm
mostly
done
by
by
stephen
glasser
and
anthony
anthony,
so
next
slide.
G
So
that
the
current,
the
current
problem
that
we
are
trying
to
fix
is
that
an
ipsec
assay
is
typically
bound
to
only
one
cpu,
and
so
when
you
have
a
big
pipe
and
you
do
like
you
know,
10
gigs
or
more
over
that
pipe
and
you
enable
ipsec
and
suddenly
your
performance
drops
dramatically
to
you,
know
three
four
gig
or
something,
and
so,
if
you
got
a
nick
that
can
even
do
more
than
10
gig,
then
you
know
you
see
a
significant
drop
in
performance.
G
So
what
we
really
want
to
do
is
see
if
you
can
use
multiple
cpus
in
a
way
that
makes
sense
performance
wise.
Additionally,
if
you
do
qos
services,
then
you
would
need
different
ipsec
assays
to
to
to
to
get
the
right
traffic
on
the
right
sa
and
also,
if
you
do
more
than
one
ipsec
essay.
G
So
if
you
do
one
ipsec
say
per
cpu,
then
you
run
into
issues
that,
if
you,
if
you
have
multiple
ip
seconds
with
the
exact
same
traffic
selectors,
that
some
implementations
might
delete
the
old
ones
because
they
they
think
the
duplicate.
That
means
that
you
should
delete
the
old
one.
G
So,
and-
and
also
we
wanted
to
do
some
negotiation
where
we
basically
say
how
many
of
these
parallel
ipsec
essays,
we
want
to
use
so
that
we,
so
both
parties
know
beforehand
and
don't
try
to
set
up
too
many
of
them.
G
So
so
one
thing
that
needed
some
more
clarification
in
in
in
how
to
handle
ipsec
essays
that
have
identical
traffic
selectors
and
to
make
sure
that
people
just
don't
delete
the
old
ones
and
assuming
that
they
have
been
replaced-
and
we
are
suggesting
notify
payloads-
to
convey
some
information
about
these
duplicate
ipsec
essays
that
we're
going
to
install.
G
G
How
many
duplicate
ipsec
assays
you
want,
and
then
you
can
put
you
know
one
on
each
cpu
and
keep
them
sticky
on
that
cpu
and
we
have
a
q
info
notify
for
the
qos
case,
where
we
think
that
you
know
some
information
needs
to
be
conveyed
like
this.
Is
the
ipsec
safe
for
this
specific
quality
of
service?
G
So
there's
an
implementation
in
linux.
The
draft
has
links
to
it.
This
was
done
by
steven
classer,
and
this
includes
like
where
you
can
do
an
on-demand
acquiring
message
per
cpu.
So
you
can.
If
you
have
16
cpus
you
can,
you
can
say
you
can
do
up
to
16,
but
if
there's
only
two
cpus
sending
traffic
over
the
tunnel,
you
could
just
set
up
two
cpu
to
ipsec
essays.
G
Then
there's
a
libris
one
on
the
strong
side,
implementation
anthony
is
on
most
of
that
work,
so
they're,
definitely
not
independent
implementations.
At
this
point
I
would
say,
but
they
they
do-
prove
give
the
proof
of
concept
that
that
this
is
working.
G
So
this
is
a
benchmark
you
can
see
black
is
the
unencrypted
traffic
like,
depending
on
how
many
cpus
you
use
red,
is
basically
the
universe
where
we
live
now,
if
you,
you
know,
you
set
up
one
episode,
saying
you're
limited
to
you
know
about
four
gigs
of
traffic,
regardless
of
how
many
cpus
you
have,
and
if
you
set
up
multiple
tunnels,
multiple
ipsec
assays
per
cpu,
then
it
basically,
you
know
climbs
up
linearly.
G
G
Some
issues
that
you
know
we
could
use
input
of
the
working
group
for
one
is.
There
was
some
talk
about
how
to
negotiate
the
exact
number
that
you
want
to
do,
because
a
cpu
is
not
a
really
specific
measure
of
computational
power.
So
just
saying
like
I
have
four
cpus
doesn't
really
also
tell
you
how
powerful
they
are.
Maybe
the
other
end
will
only
do
two
and
you
know
versus
the
forum
on
the
smaller
device-
that's
good.
G
So
so
initially
we
put
in
the
preferred
and
maximum,
and
then
you
know
they
can
pick
the
the
highest
one
that
fits
within
the
max.
That's
the
highest
preferred
one
that
fixed
within
the
max
value.
G
We're
also
thinking
of
whether
there's
use
in
signaling
on
on
sort
of
a
cpu
id
so
that
both
ends
can
sort
of
keep
sync
about
which
which
cpus
to
to
keep
something
on,
but
that
is
also
conveying
some
internal
state
of
these
machines,
so
so
we're
also
a
little
uncomfortable
doing
that.
So
we're
not
sure
if
there's
value
in
doing
this
or
not
now
for
the
queue
info.
If
it's
only
qos,
then
maybe
we
don't
need
a
subregistry.
G
There's
also
some
corner
cases
where,
like
vincent,
if,
if
you,
if
you
agreed
to
eight
ipsec
assays
and
you
you've,
installed
seven
and
both
of
them,
both
sides
initiate
for
the
final
slot,
then
you
end
up
with
nine
ipsec
assay.
G
So
should
the
draft
say
something
about
that
or
do
we
leave
this
as
a
local
implementation,
where
maybe
one
end
will
delete
one
or
maybe
they'll,
just
leave
9
running
a
bigger
issue
is
ipsec
re-keying,
because
that
changes
the
spine
numbers
and
with
some
of
the
the
hardware
support,
that's
being
used
here
that
might
actually
change,
for
instance,
the
cpu
that
it's
bound
to
so
it
might
switch
to
different
cpu
because
its
spine
number
changes.
G
And
so
then
you
you,
you
run
into
issues
where
one
cpu
is
like
underutilized
and
one
is
over
utilized
and
then
there's
also
issues
with
net
mapping
and
that
mapping
is
it's
the
same
thing
with
rss
you
that
those
gets
those
values
are
hashed.
So
if
the
the
net
route
in
between
changes,
the
mapping
and
changes
the
hash,
then
it
might
also
change
the
affinity
or
the
queue
where
the,
where
this
work
will
end
up
on.
G
So
some
hardware
related
things
that
maybe
we
should
or
should
not
dive
into
in
the
draft.
So
the
assumption
is
that
you
know
the
sender
has
no
issues
to
pick
which
cpu
it
will
use.
It's
only
the
receiver
that
needs
to
distribute
the
load
properly
and
that's
where
that's
where
the
real
hardware
support
is
needed.
So
most
network
cards
these
days
support
rss,
usually
the
only
supporters
for
udp
and
tcp.
G
They
don't
support
it
for
esp,
even
though
you
can
sort
of
sneak
in
the
same
offset,
because
the
they're
using
it
for
basically
creating
a
random
hash
and
since
for
esp
the
spine
number
overlaps
with
the
udp
port
number,
you
can
use
that
too,
because
it's
also
random,
but
some
some
hardware
implementations
now
support
rss
natively
for
the
esp
protocol
and
then
there's
also
the
n-tuple
support,
which
is
also
usually
not
available
for
for
the
spy
selector
to
usually
also
only
look
at
the
the
port
numbers
and
the
the
source
and
destination
ip
addresses,
but
not
go
not
go
deeper
into
the
packet
to
look
at
the
spy
to
select
this
on.
G
So
that
would
be
nice
if
it's
available,
but
that's
usually
not
the
case,
and
we
see
that,
like,
like
virtual
nicks,
are
also
starting
to
play
in
this
space
and
trying
to
aggregate
things
and
bind
multiple
virtual
nicks
together
and
so
they're
they're.
Also
playing
in
this
space,
where
we
have
sort
of
you
know
a
virtual
hardware
solutions
and
next
slide.
G
So
so
I
mean
for
us
this
fixes
a
practical
problems
like
we
need
to
bring
up
the
performance
of
you
know
of
a
tunnel
between
two
endpoints.
Where
you
have
like
you
know,
you
don't
have
thousands
of
essays,
but
you
only
have
one
of
them,
so
this
is
one
way
of
of
solving
it,
and
so
the
question
is:
does
the
working
group
think
this
is
a
good
way
of
doing
it?
G
It
sort
of
requires
hardly
any
protocol
changes,
just
like
some
fine
tuning
and
telling
people
how
to
deal
with
duplicate,
ipsec
essays,
so
so
we're
interested
in
in
both
the
hearing
from
the
working
group
and
hearing
from
hardware
vendors
to
see
if
they're,
if
they're,
looking
into
this
problem,
too
and
and
and
getting
us
the
right,
the
right
access
to
the
hardware
to
to
start
using
their
their
hardware.
G
F
It's
not
a
question,
it's
a
comment.
I
think
that
it's
a
very
interesting
work
and
we
discussed
with
paul
and
with
anthony
and
his
technique.
F
Requested
to
be
adopted,
and
so
I'm
ready
to
review
it,
and
I
think
we
discussed
with
paul
about
the
generic
general
approach
of
negotiation
of
these
things
in
agriculture
and
I'm
glad
that
so
the
drum
didn't
go
into
too
much
detail
on
the
hardware
and
internals
specifically,
is.
I
think
it's
quite
right,
my
margin
of
not
to
go
into
so
so
that's
why
I'm
against
cpuid?
G
Yeah,
we
would
definitely
like,
like
more
input
from
people
about
the
discussion
of,
like
you
know,
things
like
a
cpu
id
like
like.
Is
there
much
to
be
gained,
or
is
that,
like
local
implementation,
details
that
should
not
be
exposed,
or
that
has
like
little
value
that
I
think
that's
a
good
discussion
to
have
on
the.
C
B
Hi,
so
this
reminds
me
of
the
new
esp
work.
I
wonder
if
this
is,
you
know,
came
out
of
that.
G
So
no,
this
was
actually
that
it
predates
that
actually
a
number
of
itfs,
so
so
yeah.
Some
of
it
can
solve
similar
problems,
but
we
found
at
least
that
the
the
the
new
esp
work
is
trying
to
do
a
lot
more.
A
lot
of
different
things
is
trying
to
do
multicast
and
a
whole
lot
of
other
issues
that
are
that
we
fear
takes
like
will
take
a
lot
more
time
to
get
into
a
further
stage
than
just
getting
this
out,
and
this
is
like
a
concrete
problem.
G
B
Yeah,
it
definitely
seems
easier
to
get
through.
I
just
as
an
implementation
point,
even
without
like
an
rss
support.
You
know
just
having
been
in
like
vpp
or
whatever
you
know.
If
I'm
rece,
if
I'm
receiving
it,
I
can
fan
out
based
on
the
spi,
even
on
one
cpu
right,
I
can
do
40.
I
can
do
40
gig
on
a
single
core.
If
all
I'm
doing
is
looking
at.
You
know
the
spi
and
then
immediately
handing
it
off
to
another
core
to
do
decrypt
and
all
that
right.
B
B
C
G
Ipsec,
because
you
you,
you
could
have
multiple
tunnels
where
you
want
16
spread
like
let's
say:
you've
got
your
data
center
tunnel
and
a
management
tunnel.
You
don't
want
your
management
panel
to
have
16
either.
If
your
production
one
has
one.
Okay.
C
Yeah,
the
one
of
the
questions
that
I
have
there
are
that
I
would
actually
assume
that
you're
actually
going
to
have.
You
know
to
prefer
to
be
like
three
times
what
you
have
a
cpus,
especially
because
I
mean
that
will
actually
solve
lots
of
the
other
cases.
It
solves
the
corner
cases,
it
doesn't
matter.
If
you
have,
you
know
eight
or
nine,
if,
if
your
limit
is
24
and
25
and
it
solves
the
problem
of
hashing,
because
if
you
have
lots
of
those
randomly
has,
they
will
spread
out
with
all
the
tpus.
C
Otherwise
you
have
to
have
a
certain
problem
that
you
have
to
allocate
cspi
so
that
they
actually
hash
into
the
certain
you
know
cpu,
which
might
make
it
very
difficult.
If
you
don't
know
how
the
hashing
is
done
in
the
hardware,
so
I
I
think
it
would
be
much
more
interesting
to
just
say
that
okay
use
the
big
enough
number.
C
The
question
is
the
queue
info
qr
info-
I
I
don't
under
I
mean
if
it
if
it
needs
a
super
registered,
then
it
probably
needs
to
have
a
standardization
way
of
putting
something
in
there.
If
it's
just
opaque,
they
stop
for
the
implementation
for
two
implementers
that
know
each
other,
then
I
don't
think
we
actually
need
a
super
extra,
but
if
you
need
to
have
a
super
extend,
we
probably
also
want
to
specify,
what's
in
there
like,
what's
really
in
there.
G
So
so
so
right
now
the
only
the
only
use
we
have
for
it
is
qos.
So
we
could,
we
could
tailor
it
to
qrs
only
and
have
it
specifically
for
that,
but
we're
wondering
maybe
other
people
have
other
bits
of
information
that
is
useful
for
them
to
to
to
inform
the
peers
of
for
for
this.
So
if
nobody
comes
up
with
anything
new,
maybe
we
will
just
reduce
it
and
say
like
we'll:
just
do
a
specific
qrs
one
and
no
no,
so
then
it
would
be
like
you
know,
qos
info
specifically.
G
F
Well,
it's
just
a
comment
not
about
this
job,
but
probably
more
about
it's
just
some
association.
F
So
this
draft
is
concerned
with
high
performance
issues
for
pck
and
actually,
if
you
send
very
small
packets,
like
yp
packets
with
high
rate,
then
I
our
head-
that
esp
implies
is
very
high.
And
even
if
network
is
fast,
you
will
lose
a
quite
noticeable
percentage
of
its
performance
and
so
that
I
think
that
iptfs.
F
Can
be
seen
as
more
generic
mechanism
of
not
only
for
traffic
flow
confidentiality,
but
also
for
paycheck
and
taking
a
few
smaller
packets
into
one
esp
package
that
will
improve
performance
if
packets
are
very
small.
F
So
it's
probably
just
consideration
for
christian
is
that
it
is
not
only
for
traffic
for
confidentiality.
It
has
other
applications,
it
probably,
which
was
mentioned
in
the
job.
Just
a
comment.
G
Yeah,
that's
true,
and
we
had
a
two
on
our
list
of
of
you
know
similar
workouts
being
done
right
now,
so
so
yeah.
If,
if,
if
the
new
esp
could
do
something
as
well,
where
it
can
like
sort
of
group
a
number
of
small
packets
together
into
one
and
do
that
based
on
like
you
know,
similarly
to
how
how
modern,
kernels
or
nic
cards
do
this
gso
or
other
other
features
that
would
be
great
to
have.
But
that
would
be
a
much
more
substantial,
substantive
change
than
than
doing
this.
A
All
right
so
freddie
haven't
read
the
draft,
so
this
could
be
a
stupid
question.
But
what
does
it
do
that
rfc
6311
doesn't
do.
A
G
7296
also
allows
that,
but
this
is
you're
giving
a
little
more
information
as
to
why
they're
being
used
so
that
so
both
sides
know
that
they're
going
to
you
know
that
you
want
them
and
also
the
point
was
to
negotiate
how
many
you
want
like
what
we
wanted
to
avoid
was
a
situation
where
one
end
goes
and
installs
more
and
more
and
more
until
they
get
t
as
unavailable,
because
the
other
end
is
tired
of
installing
more
of
them,
and
so
we
were
hoping
that
this
would
like
make
it
clearer
from
both
sides
that
they
can
sort
of
expect
how
many
they
will
have.
G
A
So
how
do
you
handle
the
asymmetric
case
where
one
side
has
like
eight
cpus?
The
other
side
has
a
six.
G
Current
and
stefan
can
correct
me
if
I'm
wrong,
but
currently
we
install
all
the
inbound
essays
because
you
have
to,
but
we
only
install
one
outbound
sa
per
cpu.
So
if
you
get
multiple
ones,
then
you
just
don't
use
half
of
them.
A
Yeah,
so
on
the
eighth
on
the
eight-way
machine.
You'd
have
two
cores
that
never
decrypt.
G
B
Is
the
is
the
q
info
sort
of
an
idea
of
like
you?
You
want
to
maybe
pick
certain
cpus
based
on
the
you
know.
You're
saying
like
this
is
a
high
priority.
G
Sorry,
I
was
probably
muted.
We
don't
want
to.
We
don't
want
to
go
into
the
the
implementation
itself,
like
it's
just
to
negotiate
and
say
like
this
is
the
the
quality
of
service.
You
know
voip
super
important
and
how
you
deal
with
that.
On
the
other
hand,
it's
up
to
the
other
end,
but
like
like
at
least
you
have
two
different
ipsec
essays
to
encrypt.
Like
you
know
your
bulk
unimportant
stuff
and
your
super
important
stuff.
B
Yeah,
okay,
so
this
reminds
me
of
the
in
routing
we
have
admin
tags
right,
so
it's
like
coloring,
where
you
don't
assign
you
know
you
don't
standardize
the
the
semantics
of
the
value,
it's
just
opaque,
so
yeah.
This
makes
sense
to
me
for
sure
yeah.
So.
G
C
All
right,
so
I
think
that's
it
for
that
one,
and
then
we
move
to
the
I
question
one
graveyard,
which
is
not
our
working
group
item,
because
it's
not
it's
I'm
talking
about.
I
question
one,
even
if
I
original
first
version
of
the
agenda,
I
was
talking
like
version
2
graveyard
by
mistake,
but
that
was
fixed,
so
fall.
G
Yeah
so
funny
enough,
even
though
so
next
slide
yeah
for
enough,
even
though
it
has
not
been
adopted.
Yet
if
you
look
at
the
ietf
108
action
items
for
the
chairs,
that
says
perhaps
go
to
working
group
last
call.
So
apparently
the
chairs
were
jumping
to
make
this
happen
anyway.
So
only
a
very
few
small
changes
made
us,
mostly
the
text
from
sean
turner,
to
make
sure
that
we
were
not
seeing
anything
that
either
ayanna
or
isg
couldn't
couldn't
be
instructed
to
do
so.
G
All
the
work
has
really
been
done,
and
I
think
it
we
should
just
get
it
done
or
we
should
just
drop
it,
but
but,
like
it,
clarifies
the
anna
registries,
it
adds
a
deprecated
column.
It
I
think
it.
You
know
it
will
make
sure
that
people
who
are
implementing
gang
won't
start
implementing
all
this
old
stuff
anymore,
because
it's
clearly
deprecated
and
and
think
it's
very
useful
to
do.
It's
also
just
really
nice
to
have
an
rfc
number,
where
you
can
point
to
people
and
say,
like
don't
use
ikv
one.
C
I
C
Left,
I
don't
see
anybody
jumping
onto
the
queue
or
going
to
the
jobber
or
anything
like
that.
So
I
think
that's
it.
So
thank
you
for
the
presentations
I
I
will
try
to.
As
I
wasn't
able
to
collect
all
the
you
know,
the
action
items
that
I
was
supposed
to
do.
So,
if
anybody
has
any
action
items
I
should
be
doing
send
me
an
email
after
this
meeting
remind
me
that
this
was
something
that
we
agreed
on,
because
I
I
most
likely
forgot
most
of
the
things
that
we
agreed
on
here.