►
From YouTube: IETF110-IPPM-20210308-1430
Description
IPPM meeting session at IETF110
2021/03/08 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
All
right
welcome
to
ippm
everyone.
Can
people
see
the
slides.
B
So
am
I
not
presenting
the
during
the
loop
loopback
decks
period?
You
are.
I
do
have
your
slides
in
there.
Okay,
all
right
thanks.
A
A
This
is
the
note.
Well,
if
you
have
not
seen
it
before,
please
do
take
a
look.
This
is
the
kind
of
the
terms
under
which
you
participate
in
the
ietf.
A
A
A
A
A
Today
we
want
to
go
through
just
the
iom
topics
that
we
have
we're
going
to
start
out
with
some
very
brief
updates
for
some
of
the
existing
working
group
documents
that
are
further
along
as
well
as
frank,
will
tell
us
about
some
deployment
work,
and
then
we
have
two
long
sections
that
we've
allocated
to
talk
about
kind
of
particular
issues
that
we
want
to
get
to
one
being
integrity
of
iom
data
that
came
up
during
iesg
review,
as
well
as
discussing
some
of
the
attacks
and
concerns
around
loopback
and
direct
export.
A
We
will,
as
we
discuss,
have
some
thoughts
from
martin
there
about
some
of
the
concerns
he
has
and
we're
going
to
actually
start
out
with
those
before
we
get
to
the
rest
of
the
presentation
on
loopback
and
direct
export.
A
C
Okay,
excellent
because
the
tool
tells
me
are
you
speaking:
it
seems
we're
not
detecting
your
audio
okay,
excellent.
So
this
is
an
update
on
the
the
o5
version
of
the
v6
options.
Draft
next
slide.
C
So
the
key
changes
are
really
apart
from
editorial
updates.
I
try
to
go
and
align
the
nomenclature
between
the
data
draft
and
the
v6
options
draft.
There
is
one
node
and
that
came
from
the
implementation
effort
that
justin
yerman
is
driving
right
now
for
the
linux
kernel.
C
So
I
think
that
is
a
node
that
is
in
there
now,
and
the
other
thing
is
that
so
far
the
the
draft
didn't
really
cover
direct
export.
Given
that
direct
export
is
progressing
nicely,
we
also
asked,
or
we
we
included
the
the
need
for
an
option
type
allocation
for
direct
export.
C
C
So
that's
really
like
an
oversight.
Sorry
for
that,
maybe
I
didn't
want
to
go
and
stick
touch
this
thing
with
a
mentally
10
foot
stick,
but
well
I'm
going
to
go.
Do
it.
C
C
C
So
with
this
like
well,
the
others
are
minor
and
we're
carrying
along.
I'm
not
sure
whether
at
some
point
we
want
to
go
and
do
a
last
call
on
the
document
or
whether
we
want
to
go
and
keep
it
hangar
for
a
while,
because
I
think
we
for
sure
need
to
go
and
get
six
man
to
also
go
look
at
it
right.
So,
like
we've
done
in
the
past
right.
A
A
So
some
of
the
changes
that
would
account
for
things
in
direct
export.
I
don't
imagine
that
there
would
be
any
kind
of
dependency
there
right
as
far
as
like.
C
Other
thing
that
I
think
you
were
helping
with
and
that
this
again,
what
justin
put
out
on
the
mailing
list
is
that
we
are
going
to
go
and
hopefully
extend
the
early
allocation
so
that
the
the
ongoing
implementations
are
not
really
impacted.
A
Thank
you.
We
have
for
you
in.
E
The
queue
hi
frank:
this
is
how
you
from
future
week
this
this
note
in
this
slide,
but
I
remember
in
the
draft
you
mentioned
to
use
ip9p
encapsulation
to
support,
including
outside
om,
but
my
concern
is
that
if
you
use
this
approach,
it's
actually
changed
the
original
purpose
of
the
iom,
which
is
used
to
monitor
the
original
user
flows,
because
you
now,
you
basically
put
it
into
a
tunnel
and
the
voting
behavior
will
be
changed.
C
Well
so,
and
we
had
that
discussion
before
right,
the
approach
is
that,
as
an
operator,
if
you
do
use
iom
with
the
need
of
double
end
cap
here,
you
have
to
go
and
make
sure
that
you
engineer
your
network
in
accordance
right,
so
that
you,
your
flows,
don't
really
start
to
go
and
follow
a
different
path,
or
it
will
only
apply
to
those
situations
where
the
flows
will
continue
to
be
forwarded
along
the
same
path.
Otherwise,
yeah
to
your
point,
there
is
no
no
benefit
from
from
from
using
iom.
C
In
that
context,
if
you
feel
like
we
want
to
go
and
have
that
as
a
particular
kind
of
node
or
additional
statement
in
the
draft,
I
think
we
can
go
on
at
that.
C
I
think
it's
one
of
the
downsides
of
the
safe
method,
ie
double
encapsulation,
so
everything
comes
with
the
trade-off
right.
Everything
comes
for
the
cost.
A
All
right,
thank
you,
I
think
we're
out
of
time
for
this
update,
and
then
we
want
to
hear
a
five
minute
update
on
the
yang.
D
D
Thanks
to
richard
miki
for
the
valuable
comments
during
the
adoption
call,
and
in
this
version
there
are
several
major
changes
based
on
the
comments
in
the
list.
Firstly,
as
requested,
we
add
operational
container
ioi
ion
info
for
assistant
data
like
units
and
timestamp.
This
is
right
now
empty.
For
for
the
argument,
there
was
a
proposed
example
on
timestamp
description,
but
I
read
the
iron
data
draft
and
I
think
there
is
no
need
for
additional
information
on
timestamp.
D
There
was
a
finding
that's
the
ordered
list,
only
extend
within
each
sale,
so
if
two
asa
is
matched
the
implementation
does
not
know
which
sae
in
which
sale
to
use
to
solve
this.
I
associated
ac
instead
of
acl
with
each
profile
in
this
version
and
as
suggested
I've
added
text
in
the
document
say
I
want
actions
be
driven
by
the
accepted
packet
when
the
matched
sae
forwarding
action
is
accepted.
D
There's
another
way,
but
I
did
not
think
I
did
not
argument
augment
ace
actions
because
there
might
be
different
kind
of
filters.
Acl
is
just
the
one
as
the
roof
proposed
flows
back
could
be
another
one.
I
believe
existing
structure
is
more
flexible
and
third,
I
removed
the
action
transit
as
I
suggested,
because,
right
now
there
is
no
use
case
for
the
transit
node
configuration.
D
D
A
So
just
one
quick
commentary,
I
think.
D
To
the
end,
yeah
and
next
step,
we
need
the
input
for
the
iomu4
and
we
will
add
examples
on
the
young
model.
Usage
and
more
comments
are
welcome.
Thanks.
C
C
So
the
scope
of
that
document
is
is
to
really
tie
all
the
various
iom,
related
documents
that
are
out
there
together
into
something
that
could
become
say
a
bcp
or
the
likes.
So
everything
around
data
fields,
yang
operations,
export
the
various
encapsulations
so
that
we
have
one
document
that
frames
what
iom
is
really
to
an
outside
reader.
C
That
might
be
a
little
lost
in
all
these
various
documents,
and
we
started
that
if
we
flip
to
the
next
slide
a
while
ago
in
ops,
awg
and
created
a
document
that
basically
explains
iom
deployments,
what
are
domains,
what
are
nodes?
C
What
are
the
different
types
of
iom
with
the
associated
references
to
the
documents
it
has
a
section
on
manageability.
There
is
a
section
on
security
considerations
that
were
continued
to
grow.
It
talks
about
why
data
export
is
useful.
It
has
a
little
bit
of
a
framing.
I
don't
want
to
go
and
call
it
architecture,
but
how
the
various
things
fit
together
like
end
cap,
decap,
transit
nodes
and
maybe
a
controller
to
go
and
make
sure
that
information
is
gathered,
and
then
we
have
stuff
like
on
how
namespaces
are
used.
C
How
layering
is
used
and
how
the
different
modes
are
used
and
references
to
the
various
encapsulations
so
that
we
have
this
as
a
bit
of
a
document
that
ties
it
all
together
for
people
that
want
to
use
iom
instead
of
implement
iom?
C
Slide
so
we
started
this
in
in
in
ops,
a
wg,
but
given
that
everything
is
now
really
centered
around
ippm
with
regards
to
ium,
and
I
think
thanks
for
having
a
a
dedicated
iom
session
even
now,
I
love
that
I
think
it's
it's
a
natural
place
to
go
and
progress
that
work
in
in
ippm
rather
than
up,
say
wg,
because
all
the
people
that
care
are
here.
There
is
another
piece
that
and
this
this
document
is
about
to
expire.
C
I
need
to
go
and
put
in
some
additional
work
for
the
security
section
that
sean
actually
was
recommending
and
along
with
his
review.
C
He
also-
and
this
is
why
it's
also
here
recommended
to
put
in
a
reference
and
it's
there
in
the
dash
12
revision
of
the
data
draft
to
this
particular
deployment
document,
because
some
of
the
contacts
that
we
have
in
in
the
data
draft
about
say
the
security
section
is
like
yeah,
you
list
a
couple
of
threads,
but
why
does
anybody
care?
And
I
think
the
reason
why
you
care
is
in
the
deployment
draft,
so
we
have
an
informational
reference
there.
A
Document
has
this
been:
when
was
the
last
time
we,
it
was
discussed
in
offside,
wg
and.
C
A
Sure,
and
do
you
know
if
you
have
a
sense
of
kind
of
the
sentiment
there
of
if
they
think
the
work
should
be
done
there
or
here.
C
I
think
what
we've
gotten
from
those
discussions
is
that
most
people
that
commented
anyway
were
people
that
had
well
the
stake
in
iom
and
came
from
ippm,
so
yeah.
We
can
have
that
conversation
formally
with
the
chairs,
but
you
know
originally.
We
did
it
there
because
it
was
deployment
focused
here.
I
think
we
were
focused
more
on
the
spec,
but
maybe
we
can
go
and
groom
everything.
D
C
I
don't
mind
where
it
lives
to
be
honest,
but
given
that
we
have
a
direct
relationship
with
the
data
draft
might
be
useful
to
have
it
here.
I
think
we
have
rob.
F
Yes,
so
with
an
ops
awg
ad
hat
on,
it
makes
sense
for
the
document
to
be
here.
I
think
that
this
is
a
to
like
a
better
home.
If
this
is
where
all
the
iom
stuff's
been
discussed,
then
I
would
prefer
being
here,
but
that's
just
my
opinion.
C
I'm
gonna
go
rev
it
anyway.
I'm
gonna
go.
B
C
C
Historically,
ium
has
been
built
around
the
assumption
that
this
is
for
a
dedicated
trusted
domain
and,
as
such,
there
has
been
very
little
focus
on
ensuring
that
nobody's
going
to
go
and
mess
around
with
the
data
that
iom,
capable
nodes
would
go
and
put
in
and
well
the
discussions
that
we
had
recently
revealed
that
people
might
have
an
appetite
for
using
iom.
C
Otherwise,
the
the
discussion
would
have
wouldn't
have
been
there
in
areas
where
there
might
be
concerns
that
nodes
indeed
go
and
fitted
around
with
the
ium
data
as
it's
progressing
through
the
network.
So
we
might
need
a
an
integrity
solution.
C
That
is
not
really
a
simple
discussion,
because
whatever
you
do
to
achieve
that,
it's
going
to
go
incur
cost
right.
So
whenever
we
go
and
create
whatever
type
of
hashes
over
the
fields
and
put
these
hashes
in,
it's
not
only
going
to
consume
space,
but
it's
also
going
to
go
and
incur
significant
operational,
I.e,
compute
costs
on
a
per
hot
basis.
So
I
think
that's
something
to
keep
in
mind.
But
people
want
it.
So,
let's
see
what
we
have
as
options
next
slide.
C
So
what
do
we
go
and
consider,
as
in
scope
for
the
threats
that
we
want
to
go
and
look
at
for
integrity
protection?
It's
like
the
modification
of
the
data
fields,
it's
the
modification
of
option
type
headers.
C
It's
injection
of
data
fields,
injection
of
option
types
headers
and
even
potentially,
like
replay
problems
that
can
go
and
occur.
If
somebody
uses
an
old
header
with
a
new
data
packet
and
the
likes,
I
think
all
of
that,
whether
we
have
all
the
options.
You
know
all
everything
covered
with
all
the
options
or
methods,
so
we're
going
to
go
and
talk.
C
I
think
we
can
go
and
look
at
that
in
a
later
phase,
but
I
think
that's
really
what
we
wanted
to
go
and
have,
as
the
original
scope
of
the
document
we're
not
really
trying
to
go
and
tackle
this
any
type
of
things
that
are
related
to
the
management
side
of
things,
the
exporting
side
or
people
well
treating
delay
as
against
something
that
would
change
the
integrity
of
the
operation.
It's
not
really
changing
the
integrity
of
the
packet,
but
it's
changing
the
integrity
of
the
delay.
C
C
So
we
have
basically
created
a
set
of
ideas
that
we
came
up
with,
based
on
the
request
from
the
working
group
of
what
could
be
done
and
this
what
could
be
done
as
a
set
of
five
methods
and
these
five
methods
take
a
couple
of
assumptions
and
we're
not
really
spelling
it
out
for
every
single
option
type
for
now,
because
we
just
thought
like:
let's
go
and
create
a
set
of
ideas
first
and
then
we
can
go
discuss
so
we
use
the
trace
option
type
as
the
one
that
I
think
has
well
the
biggest
impact
across
and
it
could
easily
be
applied
to
e2e
or
direct
export.
C
If
it
works
for
trace,
it
will
work
for
the
other
ones
if
it
doesn't
really
work
for
for
trice,
it
might
still
work
for
e2e
as
we
have
it
with
now.
One
of
the
methods
method,
five
later
on
the
basic
idea
is
always
like,
and
I
already
said
that
in
the
very
beginning
about
the
additional
load
that
we
add.
C
C
Will
will
use
some
of
that
base
method,
one
way
or
the
other,
so
the
setup
that
we
assume
is
classic
end
cap,
dcap
and
transit
notes.
In
addition
to
that,
we'll
have
a
validator
node,
which
we
assume
is
typically
the
dcap
node.
But
it's
a
dedicated
function
which
verifies
that
the
integrity
of
the
iom,
data
fees
is
indeed
met
and
that
validator
would
go
and
then
probably
post
the
results
to
some
network
management
station
plus
you
need
to
have
a
magnificent
station
or
a
controller
in
place
that
handles
key
distribution.
C
So
all
of
these
things
need
to
be
figured
out
as
we
would
design
a
solution
in
detail.
But
I
think
that's
the
base
setup
that
we
assume,
if
you
go
to
the
next
slide,.
C
C
The
third
one
is
space
optimized
with
symmetric
keys.
The
fourth
one
is
using
post
quantum
methods
to
go
and
make
symmetric
keyh
management
a
little
better
and
easier,
and
the
fifth
one
is
not
applicable
to
everything,
especially
not
applicable,
to
trace,
but
it
could
be
low
hanging
fruit
for
just
protecting
iom
for
those
option.
C
Types
that
carry
immutable
fields
where
we're
not
really
having
any
intermediate
node
like
a
transit
node
fiddle
around
with
the
traffic
at
all
ie,
e2e
or
direct
export,
would
be
examples
of
that
where
we
can
leverage
the
ip
authentication
header.
So
let's
go
and
go
through
the
the
methods
really
quick,
so
method.
One
is
that
each
node
creates
a
key
here
shares
the
public
key
for
the
validator
and
the
network
management
controller.
C
And
then
what
we're
going
to
go
do
is
we're
going
to
go
and
create,
where
we're,
adding
a
node
sign
field
to
every
single
hop
that
we're
adding
node
data
for
and
that
node
sign
then
includes
a
signature
using
the
private
key
as
well
over
a
hash
of
the
the
node
data
of
that
particular
element
and
the
earlier
signature,
so
that
we're
linking
signatures
to
each
other,
the
starting
node,
would
start
with
some
seed
and
the
hash
of
the
node
data
of
the
first
node.
C
So
that
we're
having
some
anchor
point
and
the
validator
would
need
to
go
through
the
the
procedure
and
kind
of
itself
in
order
to
validate
that
things
are
in
order.
What
this
does
is,
depending
on
what
we're,
using
as
as
a
method,
we're
adding
something
like
32
bytes
per
hop.
C
For
that
particular
signature
right,
we
can
go
and
do
the
very
same
thing
method.
Two
we
flip
to
the
next
slide.
C
We
could
use
a
very
similar
method
with
symmetric
keys,
just
a
different
algorithm,
but
the
logic
would
be
still
the
same
involves
that
that
somebody
would
go
and
distributes
the
the
search,
the
the
the
secrets,
the
symmetric
keys
to
the
individual
nodes
and
the
validators
up
front.
If
you
do
that
on
a
per
packet
basis,
you
need
a
key
per
per
packet,
obviously
and
again
similar
here,
depending
on
the
method
that
we're
using-
and
we
have
a
couple
of
examples-
mentioned
it's
somewhere
between
16
or
32
bytes
per
hop
that
we're
adding.
C
All
of
this
is
quite
heavy.
So
if
we
go
to
method
three
rather
than
having
a
signature
on
a
per
hop
basis
at
it,
we
can
have
the
trace
signature
in
the
header
of
the
iom.
Option
type
and
the
example
here
is
for
the
trace
option
type.
We
would
have
a
try
signature
there
like
32
bytes,
would
be
added
once
and
all
we
would
do.
Then.
C
If
we
go
to
the
next
slide
on
a
hot
by
hot
basis,
is
we
are
updating
that
particular
trace
signature
with
the
hash
of
no
data
list,
so
that
we're
always
adding
on
top
of
our
piggybacking
on
top
of
the
symmetric
key
and
the
validator
would
need
to
go
and
do
the
exact
same
operation
on
validation
and
see
whether
he
would
arrive
at
the
very
same
signature
key
in
there,
as
it
was,
was
received
so
quite
of
of
an
operational
coordination
effort
between
the
individual
nodes,
and
it
would
be
still
required
that
we're
sharing
upfront
on
a
per
packet
basis,
all
the
symmetric
keys.
C
If
we
want
to
go
and
use
a
keeper
packet,
I
think,
which
is
something
that
we
would
recommend
right.
If
you
want
to
make
that
a
little
simpler,
we
could
use
methods
that
the
the
guys
there's
other
efforts
in
the
itf.
As
we
all
know,
if
we
go
to
the
next
slide
with
method,
four,
we
could
use
a
method
of
loan
from
the
the
post,
quantum
pre-shared
key
distribution,
post,
quantum
user
symmetric
keys
and
their
idea
is
to
go,
and
rather
than
share
all
the
keys
up
front.
C
C
So
that's,
I
think
the
way
to
go
and
at
least
make
it
operationally
a
little
easier.
The
fifth
method
and
thanks
tommy
for
already
slipping
flipping
forward
is,
is
something
that
could
be
entirely
attributed
as
an
idea
to
greg
mursky
and
the
design
team.
When
we
when
we
are
when
we
discussed
the
integrity
draft
the
the
zero
zero
version,
he
said
why?
C
We
have
the
the
the
ip
authentication
header
and
the
authentication
header
we
can
go
and
basically
tell
like
what
method,
what
types
of
or
what
range
of
the
packet
do.
You
actually
want
to
go
and
see
covered,
so
that
could
obviously
cover
the
the
the
the
dv6
options.
So
we
can
go
and
include
it
and
use
it,
but
we
can
obviously
only
use
it
if
no
notes
in
between
want
to
go
and
change
it
between
the
well
end
points
of
the
security,
authentic
association.
C
C
It
obviously
doesn't
really
apply
because
unless
we
want
to
go
and
create
tunnels
with
every
single
one
on
the
planet,
which
I
don't
think
is
really
feasible,
so
it's
like
only
applicable
to
to
those
option
types
that
are
immutable,
but
it
might
be
at
least
the
starting
point,
and
maybe
we
arrive
at
at
the
conclusion
that
we
we
are
good
with
just
protecting
that
particular
thing.
I
think
it
all
depends
on
the
use
cases
that
people
have
in
mind
from
a
priority
perspective.
C
So
if
we
go
to
the
the
last
slide,
I
think
that's
the
final
one.
It's
really
like,
along
the
lines
of
what
I
just
said.
I
think
we
need
to
go
and
understand
what
what
concerns
people
have.
What
do
we
want
to
go
and
protect
to
what
level
do
we
want
to
go
and
protect
it?
What
burden
do
we
want
to
go
and
take
on,
and
does
it
really
need
to
go
and
cover
all
option
types?
C
Is
it
okay
to
go
and
maybe
just
carry
a
subsection
of
a
subset
of
the
option
types
and
I'm
also
interested
in
seeing
whether
we
can
go
and
get
more
help
on
this?
This
overall
thing,
because
it's
this
is
by
no
means
trivial.
Thank
you.
B
I
find
thanks
for
for
writing
this
draft
on
short
notice.
It's
very
thoroughly
thought
through.
I
was
wondering
why
you
didn't
have
a
variant
of
option.
Three
that
used
asymmetric
keys.
I
mean
it's
obviously
part
of
the
truth
table.
Although
it's
one
of
the
permutations
of
all
the
sort
of
variables
you
have
was
there
some
reason
you
ruled
that
out
or
or
what.
B
C
You
so
you
wanted
a
variant
of
which
option
sorry.
B
So
option
so
you
have
you,
have
the
you
know
one
signature
per
hop
version
and
there's
an
asymmetric
version
of
symmetric
version,
but
when
you
have
a
single
signature
for
the
entire
path,
you
know
cumulative
signature,
you
only
have
a
a
symmetric
keying
option
and-
and
I
wondered
if
that
was
just
an
oversight
or
there
was
some
consciousness
behind
that.
C
B
I
honestly
haven't:
I
don't
have
a
real,
strong
opinion
about
which
way
we
should
go
well.
B
Let
me
rephrase
that
so
I
I
do
not
see
any
advantages
to
having
all
the
additional
overhead
of
one
signature
per
hop,
which
is
I
mean,
maybe
there's
some
that
that
I
don't
see
and
and
my
following
question
is
gonna
be,
can
you
articulate
like
actually
should
the
draft
discuss
more
pros
and
cons
or
they're
just
a
matter
of
overhead
and
but
like
if,
if
my
instincts
are
correct
and
there's
no
point
in
having
a
one
signature
per
hop
thing,
then
I
would
like
to
have
the
asymmetric
symmetric
discussion,
I'd
like
to
eliminate
those
options
and
and
have
the
symmetric
asymmetric
discussion.
B
Second,
in
the
context
of
the
single
signature.
C
Yeah,
so
I
think
definitely
we
can
all
add
that
option,
and
I
would
also
agree
that
more
of
a
discussion
of
the
various
approaches
and
also
how
well
they
apply
to
the
the
set
of
requirements
that
we
we
laid
out
at
the
very
beginning.
I
think
all
of
this
could
be
done,
but
to
your
earlier
point,
it's
been
put
together
relatively
quickly,
based
on
your
request
and
tommy's
request,
so
that
we
at
least
have
something
to
go
and
start
a
discussion
with.
E
Yeah,
so
the
concern
I
have
that
this
proposal
will
introduce
more
overhead
to
the
iom
message
already
very
large,
and
also
we
all
know
that
this
kind
of
security
protection
is
a
computer
intensive.
Then
it
will
add
a
lot
more
processing
requirement
to
the
fastpass.
So
so,
in
my
opinion,
why?
E
Not
just
you
know
if,
if
there's
no
such
requirement,
you
use
this
iom
trees
option,
but
on
the
other
hand,
in
case
we
do
need
some
protections
we'll
find
the
direct
export
mode
or
the
hybrid
to
to
to
pass
method.
Both
are
immune
to
this,
this
kind
of
attack
because
they
will
send
the
data
independently
and
which
can
afford
the
slow
pass
processing.
B
Sorry
I'll
just
jump,
there's
no
cues
I'll
just
save
time.
So
I'm
sorry
in
my
in
my
giant
cloud
of
comments
and
questions,
there's
actually
something.
I
would
like
to
get
your
opinion
on.
So.
B
In
the
per
hop
signature
like
the
options,
one
and
two,
and
with
the
additional
I
mean,
obviously
the
overhead
cost
is
a
drawback.
Is
there
some
reason
that
you
would
advocate
that
we
keep
those
in
play.
C
Not
from
me,
no,
I
think
we
put
this
together
in
an
iterative
way,
as
you
see
right
where
we
try
to
go
and
say
well,
first,
one
really
rough,
then
a
little
bit
more
optimized
further
optimized.
C
A
Makes
sense
so
just
jumping
in
cue
myself,
looking
through
these
yeah,
it
seems
that
one
and
two
they're
not
practical,
given
the
overhead.
A
I
I
have
some
concerns
about
four
given
just
kind
of
the
it
has
a
higher
level
of
cryptographic.
Complexity
going
on
you,
just
kind
of
it
seems
like
it
raises
the
bar
for.
A
A
Essentially,
try
to
riff
off
of
option
three
and
kind
of
learn
things
from
consider
a
variant
that
is
asymmetric
key.
It
seems
like
the
main
issue
with
option.
Three
was
just
that
you
wanted
to
have
a
unique,
a
new
key
per
packet
going
through.
What's
the
primary
reason
there.
C
Yeah,
so
I
we
can
relax
that,
as
I
said
right.
So
if
we
are,
if
this
is
less
of
a
concern,
we
can
say
what
we're
using
the
same
key
for
a
period
of
time
instead
of
or
a
set
of
packets
instead
of
on
a
per
packet
basis,
so
that
we
are
removing
a
little
bit
of
the
nightmare
to
go
and
distribute
well
millions
of.
C
C
I
think
this
is
goodness,
but
because
I
think
what
we
try
to
go
and
do
is
we're
trying
to
go
and
get
some
sense
of
direction
here
and
then
that's
exactly.
I
think
the
discussion
that
we
were
hoping
for
that
people
say
well
yeah,
well,
look
more
into
this
one
and
we're
happy
to
go
and
relax
some
of
our
thinking
and
saying.
C
Well,
we
don't
need
to
be
that
stringent
that
we
want
to
go
and
verify
that
every
single
packet
is
treated
by
itself,
but
we're
grouping
things
up
and
to
maybe
do
it
for
a
thousand
packets
or
a
hundred
thousand
packets
or
re-key
every
ten
minutes
or
whatever,
and
then
right.
A
A
Right
so
I
guess
my
suggestion
would
be:
let's
go
off
of
option
three.
You
know
thinking
of
the
fact
that
we're
bringing
into
this
when
you're
doing
ipsec,
esp
or
essays,
you
have
a
symmetric
key
that
you've
negotiated,
that
you
use
for
a
set
of
packets,
and
then
you
re-key
after
a
period
of
time.
B
A
If
we're
not
technically
using,
if
that
wasn't
good
enough
for
that
solution,
why
not
kind
of
use
that
cadence
of
keying
all
right
greg
is
in
the
queue
as
well.
G
Speak
up
actually,
it's
very
good
point
about
their
computational
impact,
and
that
reminds
me
of
what
we
have
found
in
dfd,
which
support
authentication
mode,
but
in
a
location
mode.
Then
each
and
every
packet
is
authenticated.
G
So
what
we
discovered
is
that
it's
very
challenging,
especially
in
a
high
rate
monitoring
like
sub
100,
milliseconds
interval
and
what's
more
efficient,
is
to
have
an
optional
authentication
which
can
be
requested.
G
So
the
rate
of
the
authentication
would
be
operator
choice
but
being
able
to
indicate
that
in
this
particular
transaction
in
this
particular
packet
that
iem
data
has
to
be
authenticated
or
encrypted.
I
think
that
might
be
a
good
direction.
A
A
C
C
C
Play
around
with
how
how
often
we
would
re-key
and
then
at
also
a
method
like
what
what
greg
was
saying,
one
out
of
n
yeah
and
whatever
so
that
we,
I
think,
that's
all
kind
of
dovetails
with
what
what
martin
was
saying
as
well.
Yes,
that
we
want
to
have
more
discussion
on
the
trade-offs
of
the
various
things.
C
A
A
A
So
next
we
want
to
talk
about
loopback
and
direct
export
and
actually
I'd
like
first
martin
to
quickly
run
through
some
of
the
concerns
he
had.
He
had
made
some
slides
for
this
and
then
we'll
have
a
discussion
that
tall
can
lead
about.
So.
H
We'll
probably
need
to
present
the
the
draft
slides
on
the
next
session
right
yeah.
We
we
can
let
the
conversation
bleed
over
as
necessary,
yeah,
okay,
sure.
B
Yeah
I
mean
I
would,
I
would
hope,
to
have
a
little
discussion
about
what
I'm
presenting
here
and
so
we'll
see
how
that
goes.
All
right,
so
just
to
remind
people
so
the
and,
by
the
way,
obviously.
B
On
these,
so
please
like
raise
your
hand
if
I'm
telling
you
lies
here
about
what
happens
here,
but
but
loopback.
Essentially,
you
know,
as
with
another
iom
flow,
the
traffic
user
traffic
goes
from
encapsulated
decapsulating,
node
and
loopback.
Each
one
of
those
transit
nodes
sends
its
telemetry
back
to
the
encapsulating
node
in
the
pa
in
the
reverse
path,
and
then
dax
is
the
same
idea,
but
instead
of
going
in
capturing
mode,
it
goes
some.
You
know
some
some
other
storage
facility,
that's
arbitrarily
located
somewhere
else,
next
slide.
B
So
ever
since
I
started
showing
up
to
to
ippm,
like
there's
been
some
grumbling
about
this,
I
know
that
brian
back
with
his
chair
miranda
back
when
she
was
80,
and
I
think
they're
both
at
map
rg
right
now.
Unfortunately,
but
there's
been
a
general
concern
that
when
you
have
one
traffic
bracket,
that
you
get
n
control
packets
as
a
result-
and
you
know
elsewhere
in
itf,
we
spend
a
lot
of
time
worrying
about
amplification.
B
Where
you
know
one
packet
leads
to
gobs
of
packets
and
there's
been
some
and
there
have
been
some
things
that
we've
added
to
security.
Conservative
kind
of
the
drill
we
do
here
at
itf
is
like
somebody
raises
concern.
We
add
some
text
to
security
considerations
and
we
check
it.
We
move
on
next
slide.
B
B
The
worst
one
is
deck,
so
I'm
going
to
cut
straight
the
punch
line
here,
so
I
am
running
a
domain
that
has
that's
and
hops
across,
and
I
use
dex
to
export
that
data
to
my
cloud
provider
next
slide
and
that
happens
to
be
through
tommy's
domain
to
get
to
that
cloud
provider
and
unbeknownst
to
me,
tommy's
also
running
dex
next
slide
and
he's
exporting
to
a
different
cloud
provider
that
happens
to
be
reachable
from
my
domain.
This
is
a
completely
arbitrary.
B
You
know,
as
a
customer,
I'm
picking
whatever
cloud
provider
I
want,
and
so
there
are
end
met,
so
each
user
packet
in
my
domain,
generating
in
control
packets,
which
in
turn
generates
end
times
and
control
packets
from
tommy's
domain
and
next
slide,
and
this
keeps
keep
clicking
until
you
see
more
and
it's
not
a
factor,
it's
just
an
exclamation
point,
but
it
keeps
like
this
keeps
going.
So
a
single
packet
creates
an
infinite
ping
pong
of
exponentially
increasing
flights
or
control
packets.
B
This
is
obviously
completely
unsatisfactory.
Next
slide,
okay
and
then
for
loopback.
It's
it's
not
as
bad,
because
there's
some
limitations
on
on,
because
essentially
so
so.
B
The
problem
here,
which
is
not
as
severe,
is
that
if
as
if
there
is
a
loopback
going
on
so
you're
tunneled
over
some
other
network
and
the
underlay
network
also
was
running
loopback,
then
there
is
some
like
there's
some
that
that
you
not
only
have
n
n
packets
being
each
of
the
n
packets
up
to
n
of
the
packets
that
I
am
generating
in
my
domain
generates
m
times
n
control
packets
in
the
in
the
underlay-
and
you
know
you
could
do
turtles
all
the
way
down
after
some
sort
of
limit.
B
If
you
have
two
tunnels
on
top
of
the
tunnel
tunnels,
this
could
be
some
sort
of
like
a
high
degree
polynomial,
but
but
in
prac,
but
you
know
in
practice
you're
talking
about
probably
an
order
of
n
squared
sort
of
thing
in
a
in
a
typical,
very
bad
case,
so
again,
not
as
severe
because
of
some
of
the
restrictions
on
where
these
packets
control
packets
go.
These
telemetry
packets
next
slide.
B
So
this,
I
think,
if
you
understand
the
grumbles,
that
we
originally
had
from
the
one
to
end
relationship,
I
think
you
should
be
more
grumbling
now
next
slide,
so
you
know
like
again.
The
the
standard
thing
to
do
here
is
just
add
more
text.
Consider
security
considerations.
B
I
will
note
this
is
not
like
a
detectable
situation
until
your
traffic
blows
up
because
you're
just
these
completely
orthogonal
network
architectures
that
are
causing
these
problems
rate.
Limiting
is
not
great
limited,
I
think,
is
what
is
in
the
text
right
now.
It's
not
sufficient
when
a
single
user
packet
creates
an
infinite
stream
of
rate
limited
traffic-
that's
not
satisfactory.
B
I
guess
one
thing
we
can
do
is
change
the
probability
bounds
if
you're
using
dex
or
something
if,
if
there
are
n
hops
and
the
probability
of
sending
a
dex
factor
is
less
than
one
over
n,
then
at
least
this
dot.
That's
this
goes
to
zero
over
time.
A
B
Than
expanding
infinitely,
we
could
we
could
make
do
something.
This
restrict
the
student
remain
more
strongly.
You
could
run
this
over,
not
overlays
in
the
case
of
loopback
or
you
could
restrict
the
location
of
the
storage
a
little
more
tightly
than
we
have
or
like.
The
other
thing
is
to
really
you
know,
go
rethink
what
we're
doing
here.
You
know
these.
These
concerns
have
already
existed,
certainly
in
the
cert.
In
the
current
case.
I
wouldn't
approve
this
as
an
ad.
B
Maybe
we
could
massage
this,
but
like
really
like
what
are
we
doing
here?
Is
this
a
good
mechanism
to
use,
or
do
we
really
need
to
really
go
back
to
the
drawing
board
on
on
this
whole
idea?
I
mean
I
would
hate
for
the
group
to
spend
a
lot
of
time
working
on
this.
Just
never
really
come
up
with
something
that's
acceptable,
and
at
this
point
I'm
not
convinced
maybe,
but
I
just
I
would
like
to
have.
B
G
Martin,
thank
you
for
analysis
and
presenting
it
in
so
clear.
Visual
things
you
know
again
picture
is
worth
a
thousand
words
if
you
have
a
concern
about
direct
expert
traversing
through
another
domain,
my
understanding
and
that
that's
again,
that's
my
understanding.
I'm
not
an
offer
of
this
proposal
that
indirect
expert
it
uses
some
transport
which
is
not
marked
as
iem
data,
so
it
should
not
have
iem
marking
and
in
my
understanding
of
the
proposal,
a
direct
export
should
not
trigger
their
cascading
effect.
G
So
it's
just
like
udp,
it
could
be.
Some
transport
might
be
even
use,
well-known,
port
or
used
on
other
encapsulation,
but
definitely
not
to
be
iem
marked
and
not
collect
im
data
on
the
way
to
their
data
lake.
B
So
I
think
in
my
model
here
my
traffic
going
through
tommy's
domain
is
just
use
traffic
as
far
as
time
is
concerned,
so
it
would
be
marked
and
encapsulated.
It
would
modify
the
encapsulating
node
to
be
iom
data
but
I'll.
Let
someone
more
knowledgeable
answer
that
question.
G
H
Thanks
martin
for
raising
this
issue,
so
first
of
all,
I
agree
with
the
the
importance
of
these
scenarios
and
we
actually
in
the
drafts.
We
are
already
describing
these
scenarios
very
briefly,
but
at
this
point
like
you're
saying,
we
still
need
to
think
about
suggestions
for
how
to
solve
them,
and
actually,
I
think
the
situation
is
a
bit
worse
than
what
you're
describing
it,
because
actually
it's
not
limited
just
to
direct
exporting.
H
Psamp
is
a
working
group
that
10
years
ago
defined
how
packet
sampling
can
work,
and
they
already
described
some
of
these
threats
and
they
didn't
resolve
them
and
ipfix
actually
also
defines
a
flow
selection,
but
doesn't
necessarily
solve
these
problems.
So
I
think,
if
we're
trying
to
solve
these
problems,
we
may
need
to
think
of
a
bit
of
a
bigger
scope,
not
necessarily
limited
to
ippm,
because
the
same
problem
actually
exists
for
other
contexts
in
which
you're
doing
exporting
to
an
external
entity.
B
B
In
ietf
for
sure,
so
whatever
we
could
do
to
figure
out,
this
problem
would
be
good.
A
One
question
I
guess:
for
martin
and
also
for
tall:
do
we
think
it
would
be
possible
to
solve
this?
A
Just
by
saying
we
we
can
batch
kind
of
the
exporting
to
say
you
know
I
I
don't
know
to
what
degree
the
use
cases
for
direct
exporting
require
that
export
to
happen
in
you
know
near
real
time
on
a
per
packet
basis,
but
a
lot
of
the
amplification
goes
away.
If
you
essentially
have
a
digest
of
here's
here's
the
stuff,
I
need
to
export,
but
I
only
send
it
once.
I
have
a
hundred
things
to
export
or
you
know
at
some
cadence
and
then
you
essentially
never
blow
up.
It's
always
just.
A
H
E
I'd
like
to
comment
that
you
usually,
we
will
never
allow
all
the
traffic
to
be.
You
know
to
to
to
trigger
the
this
dx
data
collection.
We
usually
need
to
have
some
kind
of
acl
to
filter
the
only
subset
of
traffic.
So
if
you
are
careful
and
we
can
avoid
to
resample
the
the
the
the
actually
export
data
packet,
so
then
we
can
avoid
such
kind
of
problem,
but
this
is
one
possible
way
to
handle
that.
A
Yeah,
I
think,
although
to
martin's
point
it
needs
to
be
very
explicit,
and
coordination
within
one
domain
may
not
be
sufficient.
I
think
you
need
some
deterministic
bounds
on
how
often
you're
sending
something
that
are
not
that's
not
going
to
be
correctly
related
to
the
packets
coming
in
all
right.
We
are
pretty
much
out
of
time.
We
will
spill
over
the
conversation,
frank,
you
were
in
queue.
Did
you
want
to
just
have
one
last
word,
and
then
we
will
talk
again
on
friday.
C
Yeah
that
sounds
good.
I
just
wanted
to
go
see
whether
there's
a
recommendation,
because
martin
said:
should
we
fundamentally
rethink,
or
should
we
go
and
try
to
go
and
massage
the
security
considerations,
which
is,
I
think,
what
we're
leaning
towards
right,
that
we're
saying:
okay,
do
it
in
a
single
domain
only
do
it
at
a
regular
cadence.
Do
it
in
an
aggregated
way.
I
think
we
can
go
and
put
all
these
things
in
that
have
been
put
in
in
other
places
like
psamp
or
ipfix,
and
just
refer
to
these
earlier
methods.
C
Do
we
want
to
go
and
go
down
that
way?
I
have
a
load
of
sympathy
because
people
use
it
that
way.
Right
now,
right,
rather
than
saying
out
of
all
these
iom
options,
I
think
it's
the
easiest
one
to
implement
in
hardware,
and
so,
if
we
just
go
and
remove
it
off
the
table
for
now,
just
because
of
that
particular
concern,
I
think
we're
doing
ourselves
a
disservice.
A
E
A
Does
seem
that
the
technical
wire
encoding
of
the
option
that
part
probably
seems
fine,
it's
what
we
need
to
think
really
hard
about
is
what
we're
actually
doing
in
response
to
receiving
the
option
and
putting
guardrails
there
all
right,
I
think,
we're
out
of
time
craig.
Can
you
send
your
thoughts
to
the
chat
or
the
list,
and
then
you
will
group
back
again
on
friday,
it's
yeah.
The
list
is
a
good
idea.
Thank
you.
Okay,
thank
you.
All
right
thanks!
Everyone
for
your
time
have
a
good
rest
of
your
itf
week.