►
From YouTube: IETF109-SIDROPS-20201116-0900
Description
SIDROPS meeting session at IETF109
2020/11/16 0900
https://datatracker.ietf.org/meeting/109/proceedings/
A
B
B
B
A
A
A
A
A
D
A
A
A
B
B
B
It
doesn't,
we
will
still
be
able
to
avoid
raw
like
synchronization
issues,
plus
there
will
be
no
security
flaws
at
the
state
of
object
transfer,
so
we
are
going
back
to
a
raw
like
verification,
pair
verification
process,
so
we're
retrieving
cryptographically
valid
a
space,
selecting
its
values,
create
a
set
of
candidate
providers,
and
after
that,
with
this
set,
we
are
checking
if
the
second
atom
system
is
present
in
this
set.
If
it
is
present,
it's
valid,
if
it's
not
present
it's
in
invalid
and
of
course,
is
the
set
is
empty.
B
B
B
B
Here
is
the
example.
At
this
slide,
we
see
an
example
of
processing
prefixes
that
are
received
from
upstream
path,
as
we
discussed
upstream
path
is
a
prefix
that
is
received
from
customer
peer
or
a
risk
client
in
this
example,
it's
spear,
so
the
wonderful
thing
about
this
kind
of
prefixes
is
that
asp
ace
path
can
consist
only
of
customer
to
provider
players
customer
to
provider
customer
to
provider.
If
we
see
there
something
else,
it's
a
leak,
and
so
we
can
detect
it
how
it
works.
B
We
apply
the
verification
procedure
for
a
pair
one
two
valid
two
three
valid
three
four
valid,
so
the
the
outcome
of
the
check
will
be
valid.
It's
clear
on
the
right
side:
we
have
a
an
example
of
detectable
leak.
The
procedure
starts
just
the
same
way.
We
have
one
two
threaded
two
three
is
invalid,
because
the
second
atom
system
haven't
authorized
the
atom
system
number
three
to
advertise
its
prefixes
to
its
upper
providers.
B
B
It's
just
a
quote
from
the
drafting
so
because
this
working
group
is
working
with
this
draft,
I
believe
we
should
read
it
and
agree
on
it
anyway
and,
of
course,
it's
way
more
complicated
than
the
previous
drawings,
but
because
it
it
needs
to
cover
connect
edges.
So
the
first
point
stands
for
empty
ice
path.
If
the
is
path
is
empty,
the
outcome
is
invalid.
B
The
second
point
checks
whether
the
last
autonomous
system
in
the
path
equals
to
the
neighbor
autonomous
system.
If
it
is
not,
it's
again
invaded
number
three,
it's
a
most
important
and
hard
to
read,
but
still
easy
to
understand
point.
It
just
looks
for
a
pair
in
of
unequal
high
sequence
segments
that
have
invalid
a
pair
verification
outcome.
B
I
set
segments
and
the
fifth
point
is
nearly
the
same
as
the
third
one
and
its
processes
unknown
outcomes
and
if
we
reach
0.6,
this
means
that
the
path
is
about
it.
Okay-
and
this
was
an
easy
part,
because
we
are
now
going
to
a
very
verification
procedure
that
should
be
applied
on
the
prefixes
that
are
received
from
providers
and.
B
Route
servers-
the
key
difference
here
is
that
the
first
pair,
that
is
invalid
in
terms
of
asp,
doesn't
signal
that
it
is
a
leak.
It
signals
only
the
end
of
upstream
part
and
there
in
a
proper
route.
The
upstream
part
may
be
followed
by
by
the
downstream
bar.
If
it
goes
up
again,
it's
a
leak,
I
hope
it's
clear
and
but
we
need
to
verify
downstream
path.
We
need
to
change
the
order
of
in
our
check.
B
So
let's
jump
to
the
example
on
the
the
left
side
is
the
valid
route
we
are
starting,
as
as
we
are,
we
were
doing
for
in
the
previous
one,
so
we're
checking
one
two
valid
two
three
with
it:
three
four,
it
four
five
invaded
it,
but
it's
a
downstream,
but
we
are
discussing
here
a
downstream
path.
So
it's
a
a
route
that
was
received
from
provider
and
route
server
or
route
server,
so
the
invalid
4
5
doesn't
mean
that
it
is
a
leak.
B
But
it's
the
end
of
upstream
part
and
after
that
we
are
checking
not
five
six,
but
six,
five,
seven,
six
to
check
that
there
are
also
customers
to
provide
a
pair
hope.
It's
clear
now
on
the
right
side
is
a
and,
as
a
is
a
an
example
of
a
leak,
it
starts
just
the
same
one,
two
valid
two
three
weather
three,
four
valid
four
five
end
of
upstream
part:
six:
five
valid:
seven,
eight,
not
it's
not
real!
It's
not
valid
it's
invalid.
B
This
is
also
invalid
if
we
found
and
find
these
kind
of
pair,
the
outcome
of
the
procedure
is
invalid,
as
we
discussed
in
the
example
0.6,
it's
again
processing
wonderful,
I
set
segments
or
in
seven,
so
we
also
need
to
distinguish
unknown
output
of
the
verification
procedure
from
valid.
So
in
this
case
we
have
two
points
responsible
for
this
process.
We
have
point
seven
for
the
downstream
sub
path
and
0.8
for
upstream
cycles
of
path
and
0.9.
B
Finally,
if
we
are
there,
the
path
is
valid.
So
this
time
for
questions,
my
question
to
this
working
group
will
be
about
the
readiness
of
the
the
documents
at
yandex.
We
have
evaluated
for
a
half
year,
the
asp
techniques
we
use
it
in
our
monitoring
tools
and
we
plan
to
start
filtering
using
sp
techniques
prefixes
in
the
mid
of
the
next
year.
B
A
A
This
is
chris
from
google,
not
as
a
chairperson,
but
as
a
user.
How
do
you
verify
or
how
do
you
keep
the
irr
objects?
The
same
like
early
in
the
presentation,
I
think,
on
the
second
or
third
slide,
you
said
the
asp
would
point
to
a
object
or
set
of
objects
which
are
supposed
to
be
the
same
or
could
be
the
same.
B
So
so
let
me
try
to
answer
this
question.
So
if
you
have
multiple
asp
records
in
different
registries,
you
just
need
to
keep
them
the
same.
It's
not
a
registry
obligation,
it's
user
or
signer
obligation,
because
asp
objects
are
not
related
to
so
you
so
in
rows.
You
are
you
have
an
object
where,
with
prefix,
you
are
assigning
a
single
autonomous
system
in
spa.
B
E
E
B
G
G
B
G
E
A
H
H
H
H
I
think
that
that
we
are
gonna
see
some
instance
where
either
because
of
a
bug
or
because
of
user
error,
we
need
to
deal
with.
We
need
to
deal
as
gracefully
as
possible
with
a
scenario
where
multiple
disagreeing
aspa
objects
are
presented
to
an
rp,
and
I
think
the
best
we
can
do
in
that
scenario
is
just
trying
to
avoid
an
outage
as
best
we
can.
H
A
C
C
B
I
believe
it
was
a
comment
to
ben's
suggestion,
but
anyway,
so
I
think
we
have.
We
are
on
the
same
side
here
and
we're
with
the
clear
voting
in
the
draft
to
suggests
that
in
the
selected
trusted
anchor,
there
should
be
only
single
sp
record
and
if
you
have
multiple
space
for
some
reason,
they
should
carry
just
same
value.
We
should
be
fine.
A
F
F
A
new
object
called
attack,
a
trust
anchor
key,
and
that
is
a
declaration
of
the
state
of
keys
to
be
seen
and
whether
they're
in
or
out
of
use
and
there's
also
the
definition
of
the
validation
requirements
to
understand
how
attack
is
well
formed
and
valid.
There's
the
request
for
the
oid
assignment
and
there's
the
use
of
the
dot
tac
file
extension
in
the
manifest,
and
the
draft
also
has
examples
of
what
key
rollover
would
actually
look
like
in
a
different
range
of
scenarios.
F
F
So
this
draft
has
not
undergone
a
great
deal
of
change.
Since
the
last
time
it
was
discussed,
we
added
a
paragraph
to
reflect
on
the
feedback
from
rob
kisteleki
about
the
risks
inherent
in
use
of
inbound
signaling
and
the
ability
to
steal
a
ta
using
this
kind
of
mechanism,
and
we
think
that
may
actually
represent
the
end
state
that
we
can
get
to
in
this
document.
So
I
just
want
to
reprise
why
we're
here?
What
do
we
think
we're
doing
here
and
our
main
purpose
for
presenting
this
work
is
about
planned
key
role.
F
We
understand
from
what
rob
said
about
the
mechanism
that
is
often
used,
which
is
to
preference,
vendor-backed
updates
vendors
ship
new
towels
when
they
are
ready
to
be
deployed,
and
that
then
rolls
out
into
the
community
at
the
frequency
of
update
against
the
code.
Our
primary
concern
is
that
there
are
mechanisms
that
can
come
into
play
inside
the
ca
framework,
such
as
use
of
hsms
that
are
unavoidably
unable
to
export
their
key
state.
F
If
you
move
between
vendors
or
if
you're
performing
a
transition
to
something
like
the
m
of
n
mechanism
that
ripe
have
had
under
discussion,
these
moments
are
unlikely
to
be
ones
that
are
particularly
friendly
to
the
time
scale
of
asking
people
to
update
code
through
a
vendor.
We
think
a
signal
mechanistically
would
be
a
hell
of
a
lot
easier
and
there's
also
this
idea
that
there
is
a
huge
amount
of
deployed
state
inherent
in
the
system,
so
people
might
be
using
docker
or
other
pre-built
binaries.
F
This
actually
is
analogous
to
something
that
came
up
in
dns
with
5011,
and
there
was
quite
a
lot
of
conversation
about
the
need
for
appliances
to
be
able
to
be
taken
off
the
shelf
and
understand
signaling
in
system
to
inform
them.
They
were
behind
state
against
trust,
anchors
and
needed
to
update.
So
on
the
pro
side,
we
think
it
adds
functionality
to
improve
the
likelihood
of
convergence
to
the
correct
keys,
but
on
the
con
side,
there's
absolutely
this
problem
that
it
would
add
complexity
to
the
system.
F
So
we
think
that
there
is
this
problem
that
is
latent
in
what
rob
said
about
malicious
access
to
keys
and
the
corruption
of
change
through
a
sign
tell
and
we're
thinking.
Well,
if
that
really
happened,
the
fallback
mechanism
here
is
to
use
the
vendors
to
perform
the
community
upgrade.
We
don't
actually
think
the
attack
surface
is
largely
increased
because
of
an
inbound
mechanism,
and
we
think
we
have
a
potential
mitigation
use.
The
vendors
click.
F
So,
in
our
view,
there
is
not
overall
a
massive
increase
in
security
risk
and
we
like
to
remind
people
that
all
of
the
trust
anchors
are
using
hsms.
So
theft
of
key
is
not
just
mechanistically
about
coming
into
this
framework
and
being
able
to
make
someone
believe
attack
exists.
It's
about
theft,
of
the
rights
of
access
to
a
protected
piece
of
hardware
that
is
fundamentally
protecting
those
keys.
F
F
That
says
only
the
first
key
is
active
and
two
tas
with
tax
for
both
of
them,
but
with
a
revocation
event
and
a
single
ta
for
attack
and
the
key
has
been
revoked,
and
we
think
this
set
of
four
states
should
allow
rp's
that
are
developing
against
this
to
see
all
the
potential
varying
states
of
being.
They
could
expect
to
ever
see
against
the
ta
they
had
and
attack,
and
we
have
as
well
as
publishing
a
testbed.
We've
got
some
example
code
that
we've
put
into
the
public
domain.
That
shows
how
to
use
this
click.
F
F
So
there
may
also
be
other
examples
of
test
states
that
it
would
be
worth
looking
into,
and
we
think
we
should
leave
open
the
possibility
that
people
want
us
to
put
into
a
test
bed
state
different
states
that
we
could
reflect
on
as
well.
So
at
this
stage,
we'd
like
to
continue
discussion
on
the
mailing
lists,
and
we
think
we'd
like
to
aim
towards
working
group
last
call
in
a
future.
Ietf
click.
I
E
So
I
had
a
comment
more
than
a
question
regarding
the
number
of
keys.
So
currently
the
document
allows
well
x
keys
to
coexist,
and
I
think
that
generates
quite
a
lot
of
complexity,
and
you
know
it
being
complex
to
implement
to
begin
with,
it
might
might
be
a
impediment
to
to
you
know
taking
on
this
work.
E
F
Well,
since
we're
not
looking
for
closure,
I
think
the
best
thing
to
do
at
this
point
is
to
carry
this
one
forward
into
the
mailing
list
and
talk
out
the
issues
and
then
bring
up
working
group
last
call
at
a
later
ietf
there's
potential
here
that
we
could
actually
see
if
fender-backed
key
distribution
is
able
to
demonstrate
closure
in
a
small
enough
period
of
time
that
it
covers
99
of
the
cases
and
constructing
complexity
and
a
signing
mechanism.
If
we
can
demonstrate
that
vendor-backed
role
is
adequate
would
be
silly.
F
So
another
approach
here
is
that
we
open
up
some
channels
with
rp
vendors
and
actually
start
discussing
how
they
want
to
be
told
about
necessary
code
updates
against
towel
changes,
and
if
that
cycle
is
closing
nicely,
that
would
also
be
useful
against
this
work
and
we
would
bring
that
back
to
the
room.
I
do
think
it's
useful
to
document
this
kind
of
idea.
C
F
F
F
If
you
look
at
byo
ip,
the
current
mechanism
is
using
rowers
to
try
and
signal
proof
of
possession,
but
there
actually
is
a
problem
potentially
for
some
suppliers
of
service
that
they
have
to
declare
an
asn
in
order
to
let
the
user
make
a
rower
against
their
prefixes
going
in
to
the
state.
But
the
asn
may
not
be
the
right
one.
That's
actually
going
to
be
used.
F
F
There's
the
potential
need
to
have
more
than
one
key,
even
though
it's
only
one
entity
who
is
using
this
mechanism,
but
we
do
think
that
there's
potential
interest
in
multiple
entities
who
share
resources,
signing
business
to
business
declarations,
an
example-
might
be
someone
who's,
performing
the
function
of
aggregating
lots
of
small
fragments
of
address
and
is
trying
to
demonstrate
proof
that
they
have
a
collective
state.
That
would
be
a
covering
less
specific
in
order
to
create
more
value
in
the
system.
They'd
need
signatures
from
lots
and
lots
of
different
individuals.
F
F
So
there
have
been
no
substantial
changes
in
the
draft
against
the
last
version,
but
we've
added
some
authors
because
we
now
have
functioning
implementations.
We
have
two
fully
independent
implementations.
There
is
the
ap
nic
code
that
was
released
some
time
ago
and
we
have
funded
work
in
nl
net
labs
to
implement
rta
in
krill
and
routinator.
F
This
is
a
compile
time
option,
so
it
is
not
normally
visible,
but
the
great
thing
about
this
implementation
is
it's
completely
viable
in
a
self-hosted
environment,
and
if
you
read
down
you'll
see
that
there
is
also
now
a
situation
that
four
of
the
five
rirs
supports:
self-hosted
rpki,
so
you
can
already
use
the
rta
mechanism.
If
you
have
internet
address
resource
under
ap,
negaran
lack,
nick
and
right
and
there's
absolutely
no
modification
required
in
any
rir
system
to
perform
this
function.
So
nobody
has
to
revise
their
rpa
agreement.
F
Nobody
has
to
consider
the
legal
implications
of
allowing
users
to
make
declarations
of
any
kind
they
like
about
their
addresses,
because
this
works
self-hosted,
and
this
is
entirely
private
between
you
and
whoever.
You
wish
to
share
things
with
with
a
footnote
that
the
keys
you
use
almost
certainly
will
be
visible
in
the
global
rpki,
but
the
exact
semantics
of
what
you
are
signing
in
this
detached
signature,
that's
private
to
you.
What
do
you
want
to
sign?
That's
your
business
click.
F
So
the
only
substantive
question,
apart
from
asking
people
to
try
out
the
krill
code
and
see
what
they
think
of
this
technology
is
to
understand
if
this
work
is
interesting
to
cider
ops
and
we
should
seek
adoption
in
this
forum
or
if
we
should
look
in
the
community
at
large,
about
provisioning
of
resources
for
future
use
in
global
routing
or
in
business
applications
and
find
a
different
working
group
to
pursue
this
work.
Thank
you.
F
C
Randy
I
j
and
arcus.
I
think
you're
naive
that
some
tas
may
still
consider
that
they
incur
liability,
but
that's
their
problem
and
the
disease
is
bad.
We
specific
to
be
clear.
We
specifically
asked
for
this,
for
the
geo
feeds
signing
to
be
able
to
sign
a
geo
feed
to
have
stronger
attestation
than
how
you
found
it.
So
thanks
for
pulling
this
back
in,
there
are
things
I
would
quibble
with,
but
we
can
take
it
offline.
F
Thank
you,
randy,
that's
very
useful
feedback
and
I
think
you're
right
that
it
would
be
naive
to
imagine
there
aren't
potential
future
risks.
I
think
that's
something
that
we
will
have
ap
nick
will
have
to
discuss
with
the
other
rir
and
understand
how
the
community
at
large
and
the
rir
feel
about
their
risk
exposure.
We
still
see
merit
in
this
technology.
We
think
it's
useful,
but
I
would
be
foolish
to
pretend
there
are
not
potential.
E
Let
me
state
my
affiliation
for
a
change,
keep
forgetting
sorry,
just
a
clarification,
a
small
clarification,
so
this
can
actually
work
outside
of
the
rpi
repositories
in
the
sense
that
the
cms
would
be
signed
under
existing
rpki
ca
certificates.
But
you
wouldn't
necessarily
see
these
objects
in
the
rpi
itself.
F
So
I
think
business
to
business
pre-provisioning
lies
in
that
space
where
people
actually
want
privacy.
If
I'm
in
a
business
negotiation
with
a
range
of
cdn
and
cloud
hosting
companies,
I
don't
necessarily
want
people
to
infer
my
future
business
intent.
I've
got
a
need
for
it
to
be
private.
I
think
where
tim
and
I
are
trying
to
feel
our
way
is
that
we
think
the
system
has
to
be
capable
of
working
without
visibility
in
the
repository
space,
but
we
didn't
say
it
was
necessary
that
it
never
existed
in
the
repository
space.
F
H
Ben
chris
then
work
online.
So,
first
of
all,
thanks
for
this,
I
think
this
is
actually
really
really
useful.
I
I
was
having
an
internal
call
here,
the
other
day
where
we
were
talking
about
a
problem
with
that
this
would
solve
straight
off
the
bat
and
that
we're
having
to
currently
work
around
using
rooting
registry
hacks.
Currently
on
the
question
of
whether
it
should
be
visible
in
repos
or
not.
I
think
there
are,
I
think
there
are
use
cases
either
way.
H
F
C
F
F
A
J
But
I
do
believe
that
the
certificate
that
is
used
to
actually
verify
those
signatures
should
be
in
the
repository.
We
have
mechanisms,
we
have
all
the
oids.
We
have
all
the
mechanisms,
we
need
to
actually
put
it
in
there
and
verify
that
it's
correct
and
so
on.
So
personally,
I
could
see
a
way
forward
where
the
certificate,
the
end
user
certificate,
if
you
will
is
in
the
repository
in
the
manifest
and
everywhere,
but
the
object.
F
Isn't?
Okay,
I
think
that's
that's
a
valid
model.
We
thought
quite
hard
about
deliberately
designing,
not
to
need
repositories,
but
the
asn1,
if
I
remember
it
correctly,
is
capable
of
not
having
the
full
chain.
It
would
be
possible
to
only
specify
the
immediate
ee
cert
of
use
and
depend
on
chain
validation
in
the
normal
validated
repo
state.
So
I
don't
think
that
the
asn.1
is
going
to
preclude
that
model
of
use.
It
wasn't
one
we
foresaw,
but
that
doesn't
mean
it
can't
be
encompassed.
J
F
Collection,
so
the
actual
detached
signatures
themselves
are
reasonably
small
if
they
contain
a
full
chain
of
pair
inserts
they're,
not
zero,
because
they're,
not
just
the
sig
and
the
necessary
cert
pointers,
but
they
include
cert
state
but
they're,
not
inherently
extremely
large
objects.
So
they're.
The
part
of
this,
that
is
things,
do
get
into
published
repo
state
and
have
to
be
dealt
with.
F
I
think
it's
at
the
low
to
tolerable
end
and
mostly
invalidation
of
the
search
chain
above
the
e,
so
it
would
take
care
of
it,
unlike
previous
models
of
arbitrary
object,
where
there
was
that
problem
of
a
denial
of
service
risk
that
people
might
sign,
star
wars,
vol
6
and
then
upload
it
into
the
repo
and
do
a
massive
attack
on
all
the
relying
parties.
This
does
not
expect
to
ship
the
refereeing
data.
It's
only
the
sig
component
that
is
necessarily
going
to
appear
if
it
were
to
appear
at
all.
F
A
D
A
A
E
A
I
I
had
planned
to,
but
I
think
it
kind
of
closed
itself
out.
I
think
the
I
think
the
long
and
the
shorter.
The
conversation
was
at
least
from
my
perspective,
that
that
you
know
we
designed
something
we
built
it.
Then
we
went
to
go
use
it
in
operations
and
realized.
Oh
gosh.
Maybe
it
works
differently
than
we
expected
and
we
need
to
adjust
our
our
plan
process
procedure
and
operations
a
little
bit,
which
I
think
is
a
perfectly
fine
thing
for
cider
apps.
A
E
Right,
okay,
yeah,
because
I
think
there
are
two
discussions
that
kind
of
got
conflated.
One
is
around
what
rfc's
currently
says
that
must
be
done.
Another
discussion,
that's
perhaps
much
more
useful,
is
about
what
the
best
thing
to
do
would
be,
and
on
that
we
already
said
that
we
are
willing
to
to
do
the
fallback
and
continue
the
discussion
on
the
asking
deprecation
as
a
as
a
separate
effort.
E
A
F
They
close
off
enough
paths
of
attack
that
I
think
they
have
significant
merit
and
there's
the
additional
thing
that
I
honestly
believe
the
cdn
benefits
the
localization,
the
speed
of
closure
to
a
bounded
state
against
the
deltas
visible
in
the
publication
space.
I
think
that
it's
a
better
protocol,
I
think
rrdp
on
a
tls
carrier,
is
just
the
better
protocol.
Now
I
know
we're
talking
about
signed
data.
F
I
know
that
in
principle,
channel
security
should
not
affect
the
integrity
of
the
data
space
we're
talking
about
because
all
the
elements
assigned
you
can
know
you're
under
attack.
But
the
problem
is
the
necessary
consequence
in
validation
for
people
who
are
trying
to
perform
decision
logic
in
bgp
you're
under
attack.
What
the
hell
are
you
meant
to
do
at
some
point.
If
the
attack
persists,
your
validation
state
is
no
longer
valid.
Certificates
have
lifetimes
you're
in
a
bad
place,
so
I
think
protecting
the
integrity
of
this
system
getting
faster
reconciliation
and
closure.
F
I
A
A
A
E
Yeah
no
yeah.
I
don't
really
have
anything
more
to
add
to
this.
I
believe
chris
attempted
to
ripen
to
see
right
and
c
formally
ripens
to
see
another
laughs
muscle
memory,
I
guess
tongue
muscle
now
I
would
say:
let's
move
forward
on
on
deprecate
rsync,
we
can
have
lengthy
discussions
about
how
we
quote
various
parts
from
rfcs,
but
it's
probably
not
all
that
constructive
to
do
so.
So
I
would
say:
let's
move
forward.