►
From YouTube: IETF-CORE-20220202-1500
Description
CORE meeting session at IETF
2022/02/02 1500
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
We
have
a
relatively
small
agenda
for
today.
I
believe
will
end
up
the
meeting
earlier
than
usual.
It's
some
status
update
as
usual
recently
on
the
two
cork
of
documents
under
sg
review
on
href,
especially
and
coral,
and
then
we
have
a
presentation
from
john
on
the
recently
submitted
co-op
attacks
document.
B
B
Misleading
title
something
about
the
yang
catalogue
or
something,
but
that's
not
the
subject
of
those
messages.
Yeah,
I'm
also
often
making
the
mistake
of
not
adjusting
a
subject
line
when
forwarding
things
anyway.
So
we
do
have
the
remaining
discussion
open
on
what
the
relation
is
between
yang
sids
and
yang
names.
B
There
is
a
somewhat
complex
relation
set
up
in
the
currency
document
and
rob
has
been
proposing
to
to
simplify
this
losing
a
little
bit
of
functionality,
but
we
aren't
even
clear
how
much
functionality
we
would
be
losing
there,
but
it
might
in
particular
make
the
job
of
intermediates
that
need
to
translate
between
the
the
sid
and
the
name
form
much
easier.
So
it's
well.
If,
if
this
was
entirely
my
draft,
then
I
would
say
of
course
rob
is
right.
B
Let's
do
that,
but
of
course
we
have
several
people
who
have
contributed
to
this
draft
and
I
think
we
need
to
do
this
as
a
working
group,
and
so
please
look
at
those
messages.
Look
at
the
the
way
corset
is
currently
setting
this
up
and
state
your
opinion.
B
Yeah
it's
one
of
those
questions
where
there
is
not
a
single
right
answer.
I
mean
it's
not
the
question
whether
two
plus
two
is
four
or
five,
but
it's
really
a
question:
how
how
do
we
design
something?
So
it
actually
can
survive
for
a
couple
of
decades
and
that's
always
a
difficult
question
to
to
discuss.
But
I
think
we
are
very
very
close
to
finishing
this
now
with
this
last
one
discuss
outstanding
and
yeah.
B
If,
if
there
is
no
stronger
position
in
the
next
couple
of
days,
then
then
probably
I
will
jump
the
gun
and
and
simply
accept
those
changes
or
write
text
for
those
changes
and,
of
course
the
working
group
should
be
involved
in
in
that.
So
it
would
be
interesting
to
hear
from
people
and
interesting
to
hear
from
the
chairs
whether
they
want
to
to
introduce
some
some
further
delay
by
by
having
the
working
group
properly
participate.
B
Yeah
francesca's
asking:
how
big
do
I
envision
these
changes
to
be
with
respect
to
the
the
amount
of
text?
Actually,
I
think
the
the
they
will
remove
some
of
the
text
that
is
trying
to
weasel
around
what
we
actually
mandate
here.
So
we
will
have
a
very,
very
simple
rule
with
respect
to
the
way
this
protocol
is,
is
run
in
the
long
run.
B
Well,
it's
it
does
change
things
only
after
the
yang
modules
being
being
communicated
about
here
actually
change
themselves.
So
it's
really
the
matter.
How
of
how
we
do
we
reflect
evolution
in
the
yang
modules,
so
it's
really
hard
to
to
even
predict
whether
the
the
change
is
material
or
just
a
simpler
way
of
describing
what
we
would
be
doing
anyway,
but
right
now
there
are
avenues
open
that
that
we
would
be
closing
and
and
making
things
much
more
mechanical.
B
So
nothing
changes
on
the
wire,
but
the
the
way
we
expect
the
designated
experts
to
to
operate,
and
we
expect
the
the
software
that
generates
these
sets
to
operate
or
to
actually
to
be
used
less
how
it
operates
that
that
does
change
a
little
bit.
C
I
can't
talk.
I
I
probably
would
have
to
look
at
the
diff
to.
D
C
What
if,
if
a
full
last
call
rerun,
is
necessary?
The
thing
that
worries
me
is
that
that
would
take
two
more
weeks
and
then
we
would
have
to
also
give
the
isg
either
like
an
unofficial
chance
to
to
review
the
changes
and
and
possibly
like
change
their
ballot,
or
I
think
that
would
be
enough.
C
The
other
option
is
to
actually
like
bring
it
back
to
the
telechat
so
that
they,
the
rest
of
the
asg,
has
a
chance
to
look
at
it,
but
I
don't
think
it's
necessary
in
this
case,
but
even
then,
like
at
least
one
more
week
for
the
asg
to
to
take
a
look
at
it
and
unofficially
confirm
that
everything
is
fine
and
then
we're
dangerously
close
to
march,
and
we
don't
wanna,
we
don't
wanna
like
we
want
to
have
this
done
before
the
isg
changes,
which
should
not.
C
B
B
Yeah
I
I
can't
really
help
you
answer
this
question,
but
I
will
generate
a
pr
unless
we
have
a
significant
input
on
this
question
and
then
see
how
how
that
is
accepted,
and
then
you
can
look
at
it
and
see
what
the
text
changes.
Look
like.
C
Yes,
and
and
again,
this
is
just
in
the
case
that
we
need
to
rerun
the
full
last
call,
because
this
is
still
answering
rob's
comments,
so
it
could
be
seen,
as
you
know,
we're
fixing
things
and
that's
it.
We
don't
need
to
do
much
more
yeah.
A
B
There
are
a
few
last
minute
runs
that
need
to
be
done
through
the
documents
aligning
dates
on
on
yang
modules,
and
things
like
that,
and
I
would
like
to
combine
with
that
with
answering
the
the
comments,
there's
a
little
bit
of
editorial
stuff,
that
that
still
needs
to
be
done.
But
I
wanted
to
have
the
the
big
issues
the
discuss
level
issues
out
of
the
way
before
we
do
the
editorial
work,
because
yeah,
the
editorial
stuff
is
going
to
change
with,
with
the
big
issues.
A
Okay,
I
think
we
know
how
to
proceed
with
this.
Any
more
comment
on
karkov.
A
B
B
On
the
implementation
side,
we
are
trying
to
trying
to
clean
up
our
test
vectors
and
are
finding
little
nits
that
need
to
be
resolved,
and
I
hope,
at
the
time
of
the
next
interim,
we
will
have
all
all
these
nits
out
of
the
way
and
can
actually
decide
how
many
of
these
test
vectors
we
actually
incorporate
in
the
document,
because
there
should
be
some
examples
there,
but
not
the
whole
test
vector
stack,
because
that
gets
very
boring
very
quickly.
A
A
E
Yes
good,
so
this
picture
is
meant
to
illustrate
a
distributed.
Amplification
attack
using
co-op,
for
example,
multicast-
and
this
is
the
document
co-ops
attack
and
also
talk
about
the
status
of
the
echo
request.
Draft
corp
attacks
is
authored
by
me,
christian
amsas,
joram
francesca
and
another
john
john
funera
here.
E
So,
firstly,
the
background,
if
you
don't
remember,
the
co-op
attacks
is
a
informational
companion
document
to
the
echo
request,
tag
token
processing
document.
That
document
is
a
standard
tracks.
It
will
hopefully
very
soon
be
published
as
an
rfc
content
of
co-op
attacks
is
some
introduction
which
discusses
security
properties
important
for
co-op,
especially
actuators.
E
Then
it
describes
some
known
attacks
on
co-op,
mostly
in
a
theoretical
way,
and
some
of
these
attacks
are
later
mitigated
by
the
or
can
be
made
created
by
the
echo
request
draft
document.
Then
it
describes
attacks
using
co-op,
namely
denial
of
service
and
amplification
attacks.
E
Echo
request
tag
provides
mitigations
to
some
of
these.
It
echo
can
be
used
against
delays,
attacks
and
denial
of
service
attacks
should
be
clearly
some
denial
of
service
that
it's
not
the
solution
for
everything.
A
request
tag
can
be
used
against
the
request,
fragment,
rearrangement
attacks
and
the
updated
token
person.
This
thing
mitigates
the
response,
delay
and
mismatch
attack,
hopefully
to
100
percent.
If
we
got
the
text
correct.
E
There
is
a
new
paragraph
explaining
the
concept
of
freshness
and
how
it
relates
to
replay
protection
and
sequence
numbers.
There
are
more
references
and
updated
reference
text
to
the
soon
to
be
published.
Rfc
9105,
echo
request.
Like
token
processing
kersten
made
a
comment
about
the
rfc
2119
terminology
and
wanted
an
explanation
of
what
the
meaning
was
in
the
informational
draft.
I
think
it's
perfectly
fine
to
use
in
the
information
drop.
I
don't
think
these
drugs
need
it.
E
So
I
have
we
have
deleted
all
normative
text
in
this
document,
I
think
that's
an
improvement
probably
also
makes
it
easy
to
agree
on
the
descriptions
in
the
draft
it's
easy
to
describe
attacks.
These
are
like
facts.
What
to
do
about
and
show
the
master
note
facts
and
its
opinions
then
correct
the
text
on
oscar
over
tcp.
E
It's
not
tcp
that
offers
protection.
It
is
if
you
use
the
special
replay
protection
tls
like
replay
protection
in
oscor,
then
the
other
sentence.
Why
miss
binding
attacks
do
not
work
in
https
and
then
after
a
comment
from
kirsten
the
example
with
a
homeless
man,
a
hitman
and
somebody
getting
killed
was
replaced
with
a
girl,
stealing
apples
and
evil.
Queen
poisoning
apples,
then
there's
quite
a
lot
of
small
editorial
changes.
E
Current
status
and
next
steps,
so
this
is
a
companion
document
to
a
request
tag.
Accurate
quest
tag
is
in
what
48
and
the
information
here
is
also
outdated.
This
has
now
been
this.
The
fix
to
issue
77
have
been
merged
and
the
the
current
document
is
approved
by
two
of
the
authors
and
the
80,
so
we're
waiting
for
joran,
which
will
hopefully
approve
the
document
soon.
Then
this
can
move
forward
in
there.
It
will
never
happen.
E
E
This
co-op
attacks
document
was
presented
at
itf
1111
and
then
the
conclusion
was
that
one
one
good
option
was
to
make
a
bcp
and
there's
recently
been
discussion
both
in
tinted
thing
already
and
on
the
core
list
about
such
a
bcp.
I
think
my
I
understood
these
pcbs
to
be
published
quite
soon.
I
think
now.
I
understand
that
kirsten
wants
this
to
be
published
later
after
research.
I
think
that
might
be
a
good
idea,
but
we
definitely
need
to
do
something
soon
as
well.
E
I
don't
think
the
thing
already
would
be
soon
enough.
Attacks
using
co-op
is
happening
now.
So
third
point
here:
I
think
we
should
publish
co-ops
attacks
as
a
information
documents
relatively
soon,
as
yesterday
by
security
aide
benjamin
k,
keduck.
He
took
an
example
what
the
uta
working
group
did
when
they
published
the
mitigations
and
a
commanding
document
illustrating
talking
about
the
attacks
and
the
first
step
to
that
would,
of
course,
be
working
group
adoption.
B
So
I
think
this
is
really
important
and
we
kind
of
have
been
sidetracked
by
by
publishing
the
echo
request
document,
which
is
well
yeah,
providing
some
protocol
elements
that
help
a
lot
here,
but
that
means
that
we
have
essentially
forgotten
to
provide
the
bigger
picture,
and-
and
I
think
it's
good-
that
we-
we
have
an
initiative
to
work
on
this.
B
One
problem
we
had
in
in
this
space
is
that
we
don't
necessarily
agree
on
on
the
the
the
the
severity
of
certain
kinds
of
attacks
and
the
value
of
of
certain
mitigation
strategies,
and
so
on.
So
it's
relatively
hard
to
do
a
consensus
document.
In
this
space
I
mean
the
consensus.
Is
that
something
somebody
should
do
something
about
this?
But
beyond
that,
we
we
are
a
little
bit
stuck
sometimes,
and
my
oh
marco
dropped
out.
B
My
view
of
this
is
that
we
really
should
be
serious
in
understanding
this
space
before
we
do
the
next
set
of
recommendations.
So
there
are
recommendations
in
7252.
There
are
recommendations
in
in
9175,
including
an
update
to
to
the
way
some
processing
rules
work
in
seven,
two
five
two
and
we
I
think,
if
we
want
to
do
this
right,
then
we
should
have
the
the
whole
picture,
and
maybe
we
also
should
separate
the
attacks
on
coab
and
the
attacks
using
co-op
from
each
other.
B
So
this
this
last
slide
is
talking
about
denial
of
service
and
application.
Attacks,
which
I
think
is
is
different
from
the
question.
What
can
you
do
to
the
communication
between
two
co-op
implementations
by
blocking
a
request
or
exchanging
requests
or
manipulating
something
somewhere?
So
there
are
different
targets
here
and
and
different
kinds
of
attacks.
So
it's
maybe
useful
to
separate
this.
B
So,
in
the
end,
I
would
think
that
it
would
be
useful
to
have
a
document
that
that
really
provides
information,
and
if
we
can
get
these
also
data
on,
what's
going
on
in
the
dos
and
amplification
environment
and
yeah
and
in
some
places
we
can
just
shrug
and
say:
oh,
they
should
have
read
the
document,
but
still
we
want
to
work
on
on
making
it
less
likely
that
more
serious
implementations
of
co-op
provide
the
same
attack
angle.
B
B
In
many
cases,
that's
unfortunately
inevitable.
So
it
doesn't
really
matter
whether
it's
a
problem,
but
I
think
we
also
should
look
at
the
the
cost
equation
of
of
the
various
mitigations.
B
And
finally,
we
also
should
look
at
the
mitigations
with
respect
to
the
actual
effect,
because
sometimes
mitigations
just
mean
that
the
the
attackers
will
use
a
slightly
different
angle
and
we
we
should
need
to
under.
We
should
we
need
to
understand
whether
the
mitigations
we
propose
have
this
property,
because
then
we
shouldn't
be
seriously
recommending
them
or
recommending
mitigations
that
that
don't
have
that
property.
B
So
I
think
that
this
requires
a
lot
of
discussion
and
and
actual
research
input,
and
that's
why
why,
with
the
new
sec
core
activity
in
the
research
group,
I
was
thinking
whether
that
might
be
the
right
place
to
do
this
and
then
based
on
that
information,
we
can
even
go
ahead
and
define
bcp,
because
we
have
all
the
data
and
can
make
somewhat
authoritative
statements
about
what
should
and
should
not
be
done.
E
E
I
think
we
at
least
need
to
make
sure
this
is
not
getting
worse.
I
think
what
you
talk
about
the
things
the
thing
rg
things
you're
talking
about
and
doing
that
before
doing
an
r
bcp
sounds
like
a
good
plan,
but
I
think
you
also
need
to
do
something
now.
I
think
a
minimum
requirement
is
to
publish
a
description
of
attacks.
E
A
Yeah,
I
also
think
we
should
have
something
informational
now
and
then,
of
course,
more
work
is
required
to
build
something
nicer
and
final
and
sure
they'll
require
more
research
work.
I
think
you're
also
aligned
in
terms
of
well
not
timeline
in
detail,
but
as
a
sequence
of
steps
right
you're.
You
look
like
on
the
same
page
thinking
of
john's
mail
sent
earlier
today.
B
Yeah,
I
think
we
have
differences
in
the
details,
yeah
so
yeah.
I.
I
still
think
that
the
the
we
could
write
this
this
document
describing
the
the
state
of
the
union
in
two
steps
we
could
start
by
publishing.
This
is
happening
now
and
then
extend
expand.
This
document
to
here's
more
data
about
that.
Here's,
the
the
exact
reason
why
these
attacks
were
possible,
even
though
co-op
actually
has
some
some
mechanisms
in
place
that
should
have
been
preventing
them
and
so
on.
So
I
think
we
can
do
this
in
two
steps.
B
We
don't
have
to
to
breed
this
document
for
five
years
or
something,
but
on
the
other
hand,
putting
an
rfc
number
on
the
document
doesn't
make
it
significantly
more
valuable.
So
I
think
that
that
the
more
important
part
is
to
actually
gather
the
the
information
in
an
authoritative
way,
but
looking
at
looking
like
we
are
reacting
is
certainly
a
good
thing,
even
if
it's
five
years
late.
A
E
I
would
like
to
publish
both
of
these,
but
these
are
nice
companions
to
the
request
tag.
If
it's
one
document
or
several,
I
doesn't
really
matter,
but
I
think
idf
should
publish
this
kind
of
information
quite
soon.
I
don't
think
it's
okay
to
wait
several
years
for
thing
to
think
rg
working
group.
Then
I
think
I
think
we
we
need
to
publish
attack.
E
I
think
we
need
to
be
strict
there
in
in
future
rfcs,
even
if
we
don't
have
all
the
understanding,
if
we
even
we
don't
have
a
bcp
in
place,
the
understanding
we
we
do
have
some
knowledge,
and
that
is
that
the
current
documents
are
quite
soft
and
core.
What
is
used
for
dynamic
service
attacks
and
it's
hard
to
even
say
that
they
are
violating
idf
requirements,
because
the
requirements.
B
B
Yeah-
and
that
has
happened
already,
sorry
what
we
are
excusing,
what
what
we
are
actually
describing
is
how
people
have
not
implemented
the
protocol
correctly
and
what
the
consequences
of
that
were.
E
B
Fine,
we
definitely
should
be
speaking
about
what
has
been
happening
in
places
where
people
didn't
heed.
What
the
the
documents
say.
B
Okay,
but
it's
not
not
something:
oh
we
messed
this
up,
but
it's
there
are
certain
consequences
for
the
actions
of
implementers,
and
here
they
are.
B
So
again,
the
first
thing
we
should
agree
on
is
splitting
that
thing
between
attacks
on
co-op
and
and
attacks
using
co-op,
because
I
think
it's
this
there's
absolutely
no
reason
the
two
things
need
to
be
in
the
same
document,
except
that
they
both
were
triggered
by
some
some,
but
by
the
the
echo
request
document
and
and
some
common
mitigations
that
are
in
that
document,
but
I
think
for
the
current
purpose
documenting
what
you
should
not
do.
B
E
B
No,
I'm
I'm
actually
fine
with
an
adoption
call
on
both
parts.
I'm
just
wondering
where
that
adoption
call
should
occur.
Yeah,
that's
a
minor
point.
So,
in
the
end,
it's
it's
just
going
to
make
our
life
harder
to
make
the
wrong
decision
here.
While
doing
this
in
the
first
place
is
really
the
important
part.
A
B
A
How
does
it
sound
to
you
to
have
the
split
down
in
the
near
future
and
then
then
we
can
go
for
adoption
of
the
first
document.
Then.
E
E
E
A
So,
by
the
way,
there
there's
already
some
text
about
this
topic
in
group
combis
that
that
we
added
following
your
input
on
this
topic,
john.
So.
E
D
Hi,
I
I
think
it
would
be
interesting
to
publish
if
you
want
to
do
it
at
a
bcp,
though
you
can't
do
it
in
a
research
group
right.
It
has
to
be
in
the
working
group.
So
if
whether
it's
informational
or
whatever,
if
it's
anything
above
informational,
you
pretty
much-
are
stuck
doing
it
through
the
rsd
track.
E
F
Yeah
this
interesting
experience.
If
you
raise
your
hand,
you
suddenly
disappear
from
the
meeting.
That's
something
try
out
in
the
real
meetings
as
well
yeah.
I
just
wanted
to
add
that
I
mean
on
the
timeline
here.
Karsten
you
you,
you
request
a
research
activity
around
around
the
tax
which
I
think
is
great.
F
F
B
F
A
Okay,
if
there's
no
other
technical
topic
or
document
to
discuss,
we
are
to
the
aob
yeah,
just
a
few
words
in
the
next
entry
meetings.
We
have
two
left
before
atf-113
and
I
will
not
be
able
to
attend
the
next
one
on
february
16th
since
I'll
be
away
basically
the
whole
week
for
a
project
final
review-
and
this
was
already
known
when
we
scheduled
this
interim
series.
A
But
it
was
a
one-off
absence
for
me,
and
this
was
still
the
best
compromise
to
avoid
a
worse
guidance
for
seaborne
and
some
of
its
key
participants.
Now,
unfortunately,
I've
learned
this
week
that
jaime
would
not
be
available
either
due
to
personal
issues.
So
I
I'm
afraid
we
have
to
cancel
the
meeting
of
february
16..
A
I
was
hoping
if,
rather
than
just
keeping
it,
we
can
reschedule
it
for
the
week
after,
of
course
not
wednesday,
because
they
would
collide
with
cyborg
but
keeping
the
same
time.
15
utc.
A
I
see
two
options:
tuesday
22,
if
lp1
at
the
same
time,
is
not
a
problem
or
thursday
24,
which
should
be
in
the
week
without
an
isg
telechat.
So
it.
F
A
C
A
And
here
no
check
shown
around
so
okay,
I
will
cancel
the
one
for
the
16
and
reschedule
for
thursday
24
same
time,
15,
utc
and,
of
course
after
it
will
have
one
more
the
week
after
on
march
2nd
and
that's
going
to
be
the
last
one
before
itf-113.
A
Okay,
thanks
for
the
feedback
more
you
want
to
discuss
today,.
A
C
Yeah,
I
I
have
to
say
that
this
time
there
is
a
lot
of
working
groups
that
have
indicated,
at
least
in
art,
that
they
won't
be
meeting
because
they
they've
been
doing
interims
instead.
C
But,
yes,
the
isg
is
always
very
careful
with
allowing
more
than
one
session
more
than
one
two
hour
session.
Now
that
we're
we're
still
on
a
restricted
schedule
with
hybrid
meetings,
so.