►
From YouTube: IETF102-SIDROPS-20180716-1330
Description
SIDROPS meeting session at IETF102
2018/07/16 1330
https://datatracker.ietf.org/meeting/102/proceedings/
A
B
C
E
C
C
F
C
The
current
status
wow-
that's
nice,
I
know
what
the
obj
means,
but
the
currents
have
a
drafts
in
the
in
the
tree.
For
us,
are
these
they're
all
currently
relatively
active
and
being
worked
on?
If
there's
the
one
missing
from
here
and
it's
yours,
you
should
speak
up.
Oh
okay,
Thank,
You,
Warren,
and
now
we
get
to
the
presentation
part
so
Sharon,
oh
and
you
can
feel
free
to
hold
the
mic
or
put
it
back
in
the
stand,
and
also
the
little
clicker
thing
works
for
you.
G
Okay,
great
thank
you,
so
I
wanted
to
update
on
this
best
common
practice.
Draft
best
current
practice
draft
that
we've
been
working
on
with
several
folks
who
are
here
it's
a
very
short
draft.
It's
just
some
thoughts
on
how
to
use
max
length
in
the
rpki.
So
let
me
tell
you
what
the
draft
is
about
so
I'm
just
going
to
tell
you
what
the
draft
is
about
and
I'm
going
to
tell
you
the
recommendations
we
make
in
the
draft.
G
So,
let's
start
off
with
something
that
was
defined
in
RFC
six
907,
a
minimal
rower,
so
Aroha
is
minimal.
If
we
have
this
a
yes
and
we
know
that
it
announces
this
set
of
prefixes
okay,
then
the
ROE
is
minimal
if
it
contains
only
that
set
of
prefixes.
So
you
can
see
here
that
there's
exactly
the
same
of
I
same
set
of
IP
prefixes
and
boats,
the
rower
and
the
AAS.
Okay,
that's
what
it
means
for
a
rower
to
be
minimal.
Pretty
simple,
minimal
Roiz
are
awesome.
G
We
always
want
to
have
them,
as
was
said
in
RFC
six
907.
So
why
are
they?
Awesome
is
because
they
stop
sub
prefix
hijacks.
So,
in
this
case,
we
have
our
attacker
over
here
and
what
he
wants
to
do
is
hijack
a
prefix,
that's
unannounced,
by
this
a
s.
So
you
can
see.
These
are
the
two
prefixes
he
announces.
The
attacker
is
announcing
this
one.
Twenty
2.0
right,
you
can
see,
there's
no
to
120
2.0,
slash
twenty
four.
G
This
prefix
is
unannounced
it's
a
sub
prefix
of
the
slash
16
and
therefore
all
guesses
that
see
this
all
routers
that
see
this
announcement
will
prefer
it
because
it's
the
sub
prefix
right.
If
we
have
the
rpki
in
place,
we
would
know
that
this
announcement
is
invalid,
because
there
is
no
prefix
that
matches
this
one
in
this
row
right.
So
we
have
the
dot
one.
Two
two
5.0
slash
twenty
four,
but
not
dot,
0
dot,
0,
slash,
24,
okay,
so
very
simple.
This
is
why
we
designed
the
rpki
everybody
here
knows
this.
G
Okay,
so
enter
max
length,
so
here's
a
loose
Rolla,
so
this
rua
is
not
minimal.
Let's
look
at
what's
in
this
row
up
this
row
has
a
slash
16,
and
this
is
up
to
max
length
24.
So
sometimes
you'll
see
this
as
like.
The
prefix
slash,
16
24,
if
you've
seen
that
before.
So
that's
the
max
length
attribute.
So
what
that
means
is
that
you
can
announce
any
sub
prefix
of
the
slash
16
up
to
the
slash
24.
G
Okay,
now
for
the
AAS
that
we
have
here,
it
is
the
case
that
this
row
authorizes
all
the
prefixes
announced
by
the
say
us
right.
So
this
prefix
that
the
slash
24
here
is
contained
in
this
row,
ax
right,
because
this
row
all
authorized
I
know
every
subtree
fix
up
to
length.
24
of
this.
They
say
us,
so
that's
fine,
so
we
won't
have
any
routes
going
invalid.
That
shouldn't,
which
is
great
the
downside,
is
this
row
is
loose.
It
contains
many
prefixes
that
are
never
going
to
be
announced
by
Ras
okay.
G
G
This
is
the
prefixes
that
are
properly
announced.
The
bug
here
is
that
this
should
say:
dot
2
to
5.
I'm,
really,
sorry,
this
should
say:
Dokdo,
5,
ok,
so
sorry
about
that
bug,
I'll
fix
it.
I'll
update
the
slides,
but
here's
the
attack.
Our
attacker
is
announcing
a
sub
prefix
right
that
is
covered
by
this
row.
Ax
right.
Actually,
no
there's
no
bug
I'm,
really,
sorry,
everything's
fine.
So
what
this
is
fine.
This
prefix
is
a
sub
prefix
of
this
row
right,
but
it's
not
announced
by
Ras
over
here.
G
It's
not
in
the
set
of
it
prefixes
that
it's
are
announced.
So
the
only
time
we're
gonna
see
this
slash
24
announced
is
by
the
attacker.
Okay,
this
is
the
only
place
that
this
announcement
ever
happens
in
the
Internet.
Our
attacker
is
smart,
though,
because
he
knows
that
there's
a
row,
so
he
knows
that
the
origin
is
has
to
be
the
legitimate
a
s,
and
so
what
he
does
is
he
puts
a
legitimate,
a
s
number
here,
the
subtree
that
nobody's
announcing,
and
then
he
puts
his
own
number
okay.
G
So
we
call
this
a
forged
origin,
sub
prefix
hijack.
If
you
were
Alberto,
you
would
call
this
a
type
1
sub
prefix
hijack
according
to
the
text
on
amia,
presented
a
tear
and
RW
it
this
morning.
So
with
a
forge
origin,
sub,
prefix
hijacked,
the
impact
is
the
same
as
the
exact
separate,
fixed
hijack
that
I
showed
you
before.
Okay,
the
number
of
aces
that
would
fall
for
this
would
be
the
same.
The
reason
is
because
this
is
the
only
path
to
the
sub
prefix
in
the
internet.
G
Okay,
so
the
fact
that
you've
made
the
path
longer
doesn't
matter,
it
doesn't
slow
anyone
down,
it
doesn't
make
it
less
attractive
for
anyone.
It's
still
the
only
way
to
get
to
the
sub
prefix.
This
path
will
win.
This
attack
is
really
bad.
We
don't
want
this
attack,
okay.
So
that's
what
this
draft
is
about.
So
in
the
draft
we
explained
this
attack,
which
has
appeared
in
other
places,
but
we
just
wanted
to
like
make
it
very
clear
what
this
attack
is,
and
then
we
make
the
following
recommendations.
G
Our
recommendations
are
coming
from
the
fact
that
there
was
a
measurement
study
that
we
did
a
couple
but
year
and
a
half
ago,
I
think
it's
finding
that
a
lot
of
people
use
Mac's
links
in
a
way
that
leads
to
this
type
of
attack,
so
they
use
the
max
length
and
this
type
of
attack
is
possible
against
their
rowers.
So
what
we
want
to
recommend
in
this
draft
is
that
operators
should
use
minimal
rows
whenever
they
could
and
we
want
to
discourage
the
use
of
max
lengths.
G
Okay,
the
reason
is
because
max
length
is
very
confusing
for
people,
it's
easy
for
people
who
are
not
super
experts,
like
the
people
in
this
room
to
get
this
wrong,
and
so
we
don't
want
to
give
people
a
chance
to
configure
Lucilla's
without
knowing
that
they're
doing
it.
Okay,
and
so
what
that
recommendation
comes
down
to
is
operators
should
avoid
doing
this.
G
I
think
we
found
that,
like
more
than
I,
don't
remember
with
an
like
more
than
80%
of
max
length,
using
Roiz
we're
vulnerable
to
this
attack.
Just
a
note
max
length
does
not
reduce
the
number
of
rows
in
the
rpki.
It
just
reduces
the
number
of
prefixes
in
each
individual
row
up,
so
this
practice
does
not
actually
cause
there
to
be
more
row
as
in
the
RPK.
It
just
means
that
there
would
be
lists
of
prefixes,
as
opposed
to
you
know,
just
the
prefix
with
the
max
length.
G
The
rower
should
not
include
any
IP
prefixes.
There
will
not
be
originated
in
BGP
and
again
avoid
the
use
of
max
length
whenever
you
can
okay.
So
it's
a
pretty
simple
draft.
We
just
outlined
the
attack
outline
the
recommendations
and
we
hope
that
this
will
limit
Mis
configurations
in
the
ARP
ki
and
that's
it
thanks.
E
Alexander
Alexander,
okay,
Alexander's,
email,
computer
labs,
I,
hope,
you'll,
see
me
so
now
it's
better.
My
question
is
what
about
black
holing?
Normally
a
black
hole
roots
are
for.
Ipv4
is
slash
32,
and
are
you
suggesting
that
nobody
needs
to
the
calling
or
I
suggesting
to
update
Rose
in
case
of
emergency?
Do.
H
This
industry
faces
a
challenge
related
to
black
holing.
We
don't
want
people
to
set
next
length
up
to
32
for
IP,
4
or
128
for
ipv6.
What
I
will
be
working
on
with
some
others
is
we
need
to
expose
the
underlying
reason
why
it
prefix
is
invalid.
Is
it
invalid
because
of
next
length,
because
of
the
origin
or
both
in
the
case
of
black
hole
routes?
I
want
to
accept
these
more
specifics
that
are
invalid
if
they
contain
a
certain
community,
if
they
match
a
certain
prefix
list
and
there
are
P
I
region.
H
E
I
need
to
admit
that,
from
my
personal
view,
I
disagree
here
that
I
agree
that
we
need
to
duplicate
much
length,
but
it
should
be
like
every
year.
What
is
covering
this?
This
row
is
OK,
including
slash
the
deterrent,
because,
if
we're
speaking
about
malicious
activity,
it
will
anyway
bypass
rows
using
ice
bath
poisoning
and
there
we
should
focus
about
ice
baths,
purification
process
and
it
is
and
furrows
bigger.
We
should
make
it
simpler,
duplicate
max
length,
but
without
any
additional
restrictions
make
it
since,
in
that.
A
You
go
actually
I'm
looking
at
this,
and
I
am
thinking.
Some
people
may
take
this
a
little
bit
misleading,
because
the
first
and
major
message
that
man
that
has
to
be
placed
is
to
tell
people
you
should
not
publish
row
us
for
which
you
do
not
intend
to
actually
originate
Roo
that
are
meant
for
global
distribution.
A
Everything
everything
that
you
publish
as
a
rower
that
does
not
match
these
criteria
could
be
viewed
as
an
invitation
to
an
attacker
to
use
the
draw,
and
the
next
length
is
just
a
way
of
very
conveniently
register.
A
set
of
things
that
you
may
not
actually
intend
to
use,
and
a
kind
of
the
comment
about
the
intention
for
global
distribution
seems
to
be
something
where
I
think.
Actually
that
also
addresses
the
black
holding
things
because
kind
of
I
doubt
I
doubt
that
black
holing
and
similar
function
roots
actually
actually
have
an
intended
distribution
reach.
A
That
goes
that
goes
very
far,
and
a
kind
of
actually
talking
about
that
authorizing
roots
that
are
that
are
meant
for
very
limited
distribution
is
something
that
actually
that
actually
should
be
put
out,
because
if
we
do
not
provide
that
advice,
people
will
say:
oh
I
want
to
send
this
privately
to
Alexander,
and
nobody
else
should
say
should
use
it,
but
well,
okay,
because
I
don't
think
about
it.
I
allow
hope
to
hijack
that
route
globally.
C
I
Warren
Kumari,
without
any
hats,
I'm
assuming
I'm
missing
something
obvious.
Let's
say
that
I
have
a
prefix
and
I
announce
that
as
a
slash,
20
and
I
never
have
plans
to
add
nobs
anything
more
specific
out
of
that
and,
let's
say
use
it
for
like
YouTube
or
something,
and
then
somebody
else
like
Pakistan
South's
site,
start
announcing
a
slash
24
seeing
is
we
don't
have
full
rpki
distribution.
They
then
win
and
I
immediately
need
panic
and
stop
distributing
a
slash,
24
or
something
really
I.
Think.
G
Agree
but
I
think
that,
in
order
to
get
to
a
world
where
everybody
is
verifying
rpki
rose,
we
should
have
them
configured
as
accurately
as
possible
and
actually
Randy
just
presented.
His
co-author
presented
a
paper
this
morning
that
people
are
actually
turning
it
on.
So
I
take
the
point,
but
I
don't
think
that
it
prevents
us
from
thinking
about
this
problem.
Randy.
F
Bush
ijr
Castillo,
whatever
I,
don't
wear
hats
at
all:
it's
just
an
enumeration
macro:
it
can
stay
there,
it
can
go.
You
were
correct.
There
are
no
more
roles
created
if
the
software
is
going,
but
the
list
of
prefixes
in
the
Laura
fully
enumerates,
which
is
why
it's
a
macro
and
it
is
enumerated
in
the
rpki
to
router.
Protocol
and
ter,
has
all
the
little
pieces
and
it
eats
his
memory
and
it
eats
his
processing.
F
G
Just
a
comment
on
that,
so
I,
don't
we're
not
proposing
removing
max
lengths
from
the
spec
and
in
fact
we
have
a
research
paper
that
we
wrote
that
I'm
happy
to
send
to
the
mailing
list.
After
this,
where
we
wrote
a
little
tool
that
would
take
a
minimal
row
that
does
not
use
max
length
and
compress
it
down
using
the
macro,
and
so
the
proposal
here
is
not
to
stop
having
max
length
or
even
building
macros.
That
can
just
compress
it
with
that.
G
The
idea
is
just
to
not
give
paraders
this
degree
of
freedom,
because
we
worried
that
they're
gonna
make
mistakes,
that's
what
this
is
about.
Okay,
so
we
just
want
to
limit
misconfigurations.
If
you
do
the
measurement
studies,
you
do
see
that
this
does
cause
a
lot
of
Mis
figurations.
So
that's
the
thinking,
okay,
so
I'm
going
to
wrap
up.
So
from
the
perspective
of
the
authors,
we'd
love
to
have
your
comments
on
the
list.
We
feel
like
from
a
technical
content
perspective.
We've
got
most
of
what
needs
to
be
covered.
G
If
there's
something
we
missed,
please
let
us
know
we're
gonna
do
like
a
bunch
of
editorial
passes
and
we're
gonna
kind
of
try
to
wrap
it
up
with
working
group
last
call's.
So
if
there's
anything,
we
missed,
please
let
us
know
on
the
list
as
soon
as
possible,
also
as
you
can
see,
I'm
on
a
short
timeline.
So
now
is
the
time
if
you
want
me
to
do
any
edits,
get
them
in
now.
Thank
you.
F
J
F
Okay,
you
were
supposed
to
have
read
the
draft
okay,
so
within
a
rolling
trust
boundary
like
a
pop,
okay
and
think
hard
about
the
term
routing
trust
boundary,
it
may
not
be
desirable
and
it
is
not
necessary
for
all
devices
to
individually
perform
origin
validation
because
you're
within
a
trust
boundary
your
neighbor
can
do
it
for
you,
I
am
NOT,
saying
trusted
from
another
is
okay,
a
nice
use
is
route
reflectors
and
so.
F
Yes,
I
can
learn
to
use
this
device,
so
here's
the
cash
it
is
feeding
the
two
route
reflectors,
they
are
doing.
Origin
validation
and
the
art
reflector
clients
could
learn
this
information
from
them.
Now.
What
do
I
mean
learn
this
information
I
am
suggesting
that
these
be
the
only
evaluations
of
bgp
announcements
and
that
they
signal
back
invalids
to
the
aggregation.
Routers
I
want
to
be
careful
about
terminology,
because
this
is
especially
designed
to
be
confusing.
F
An
evaluator
is
the
device
that
receives
routing
announcements
from
senders
and
applies
our
PKI
based
origin,
validation
and
now
comes
the
fun
part
and
signals
the
invalidity
back
to
the
sender
who,
all
of
a
sudden
is
receiving
the
validity.
Checking
information
so
watch
out
for
the
word
sender
here:
okay,
so
the
hack
is
an
evaluator,
can
signal
receipt
of
an
invalid
route
and
only
invalid
routes.
By
announcing
that
route
back
to
the
sender
with
the
prefix
origin,
validation
state
extended
community
involvement
a
little
bit
as
defined
in
1897.
F
If
you'll
remember,
1897
was
the
RFC
for
vendor
do-gooders,
who
wanted
to
automatically
do
this
and
just
tag
prefixes
validity
states,
I'm,
just
reusing
that
extended
community
gotta
support
you
up.
In
some
ways,
community
gets
a
nickel
for
every
time.
A
community's
used
the
sender
receiving
the
return
prefix
with
the
invalid
marking
must
treat
it
the
way
it
would
treat
an
invalid
origin
that
it
itself
detected,
and
that
means
withdraw
any
announcements
of
that
prefix
with
valet
s
and
watch
out
for
ad
path.
F
You're
a
simple
and
stupid:
what
did
you
expect
from
me?
Look?
Okay!
You
want
to
cut
in!
Oh
no
you're!
Welcome
to
okay.
Now,
of
course,
since
the
sending
the
invalid
announcement
is
the
sender's
not
expecting
to
receive
it
back,
they
need
to
signal
the
capability.
So
we
have
a
wonderful
new
BGP
capability
that
says:
I
can
rescind
and
receive
this
GARP.
F
Isn't
this
outsourcing
security?
No,
it
is
not
it's
remote
decision-making,
as
my
friend
Steve
pehlivan
says,
not
letting
a
third
party
make
the
decision.
It's
simply
doing
it
in
a
different
computer
in
the
same
party,
its
symbol,
similar
to
a
pop
having
a
single
rpki
cache,
with
all
trust
vested
in
your
within
the
trust
boundary.
H
Job
Snider's,
NTT
communications,
I,
think
you're.
Looking
in
the
right
direction,
there
are
use
cases
for
this
type
of
technology.
My
suggestion
would
be
to
do
it
perhaps
a
little
bit
different.
Instead
of
using
communities
in
the
ipv4
unicast
and
ipv6
unicast
API
have
a
route
reflector
set
up
within
a
new
API
or
subsequent
API
issues.
Yeah
subsequent
API
communicate
the
in
violets
or
communicate
what
it
needs
to
say,
rather
than
recirculates
the
invalids
with
a
community
that
differentiates
them
from
other
things.
H
H
K
F
K
J
B
J
Will
illustrate
with
an
example:
is
the
peering
router
gets.
You
know,
prefix
a
from
you
know:
here's
1
and
2.
He
prefers
Pier
1
sends
it
on
to
the
route
reflector
the
route
reflector
sends
back.
No,
you
won't
either
so
the
peering
router
says:
ok,
great
I'll
choose
my
backup
route
number
2,
so
he
withdraws
route
number
one
towards
the
route
reflector.
What
is
the
route
reflector
do
now?
J
L
I'm,
just
clarifying
the
that
out,
reflector
simply
does
the
validation,
the
receiving
guy
when
it
receives
an
invalid
route
for
all
practical
reasons,
thinks
it
as
a
dampened
or
an
invalid
route
in
this
case,
takes
the
route
out
of
the
best
path
decision
for
path
out
of
the
best
part
decision
and
just
follows
with
n
1.
Even
if
he
runs
out,
he
has
got
no
pants.
Let.
F
D
J
D
J
F
F
M
F
M
M
L
L
M
N
As
out-of-band
good
you've
heard
one
example,
somebody
actually
doing
it
as
the
draft
describes
it
not
good.
We
need
this
to
be
in
a
different
place
of
the
pipeline.
We
want
this
before
hits
ribbon,
not
a
trip
ouch,
which
is
sort
of
where
you're
doing
your
you
that's.
The
main
thing
second
thing
consider
two.
N
Are
correct,
I
did
this
for
some
of
the
reasons
that
Jon
will
get
to.
That
would
be
the
place
to
do
it.
You
would
need
a
little
additional
binding
to
be
able
to
figure
out
what
the
full
loop
looks
like
it'll
smell
like
a
death.
It
won't
be
at
that
he'll
smell,
like
the
second
comment,
is
you're
thinking.
Origin
validation
right
now
think
this
also
later
on
for
outsourcing
HP
sec.
H
N
H
E
Good
afternoon,
one
more
time,
my
name
is
Alexander
Zima
I'm
from
Q
at
ellipse,
and
today,
I
am
going
to
discuss
with
you
possible
methods
of
future
security,
bgp
deployment
and,
let's
start
with
the
current
state,
one
may
find
the
current
state
of
bgp
security,
terrifying.
There
are
regional
events
that
are
happening
on
a
regular
basis.
There
are
numerous
local
events
that
goes
fully
undetected.
E
There
is
malicious
activity
that
may
took
days
or
even
weeks,
with
full
support
of
the
community
to
shut
down
the
entrada,
because
there
is
no
support
from
the
BGP
protocol
itself
and
ok,
there
are
problems,
roof,
leaks
and
hijacks,
but
the
problem
is
not
limited
to
the
anomaly
itself.
The
problem
is
that
these
anomalies
are
propagated
and
what
do
we
have
to
detect
these
anomalies
in
in
the
world?
E
Here
is
GP
security
quadrant,
and
we
have
several
tools
that
are
capable
to
detect
mistakes.
Mistakes,
hijacks
mistake,
root,
leaks,
there
are
old,
well-known
IRA
futures
with
old,
well-known
problems
such
as
problem
with
authorization
problem
with
naming
problem.
Without
it
outdated
data
there
is
rose
which
is
finally
on
fly.
It's
a
great
news
that
recently
several
huge
axes
have
started
to
drop
invalids.
It's
the
level
offer
router.
E
There
are
also
several
drafts
that
are
targeting
detection
of
mistake,
root
leaks
using
additional
attributes,
and
it
is
believed
that
to
detect
malicious
activity,
we
all
need
BGP.
Second,
and
this
BGP
extension
has
several
well,
although
they
can
entrance
problems.
The
most
highlight
here
is
a
computational
cost.
It's
has
great
computational
overhead,
but
there
is
another
one
which
I
was
not
able
to
find
in
the
available
literature,
and
it
is
web
compatibility.
E
There
are
C
states
that
if
we
receive,
if
our
neighbor
can't
speak,
BGP
say
we're
switching
back
to
the
plain
old
BGP
and
my
Croatian
is
what
will
make
an
attacker
to
support
BGP
SEC?
Does
it
mean
that
to
secure
which
should
be
safe
to
secure
BGP?
We
need
to
make
a
take
us
to
support
BGP
SEC
from
its
sounds
at
least
we'd.
E
The
results
is
here,
but
don't
be
too
upset
because,
as
far
as
I
know
from
numerous
discussions,
nobody
was
going
to
deploy
BGP
sick
during
their
lifetime.
So
it's
a
room
of
opportunity
and
let
us
learn
from
the
mistakes
and
clearly
specify
the
goals
or
what
we
need
from
the
any
kind
of
protocol
extension
to
detect
malicious
hijacks
and
reduce.
E
So
what
we
need.
We
have
already
a
region
validation
with
rows.
We
need
opportunity
to
detect
invalid
eyes
paths
and
it
should,
of
course,
support
incremental
deployment
and
it
should
be
lightweight
which
should
be
no
signatures
in
BGP.
That
must
be
checked.
There
should
be
no
shipping
messages,
no
address
families
and
so
on
so
on.
So
it
must
be
simple
to
be
to
have
a
chance
to
be
deployed
in
near
future,
because
we
have
already
in
the
world
of
disaster
and
let's
go
back
and
speak
about
the
anomaly
propagation.
E
It
doesn't
matter,
it
is
hijack
or
root
leak.
It's
is
propagated,
like
with
any
other
prefix
announce
it
goes
from
a
region
or
the
attack.
It
doesn't
really
matter
to
providers
to
the
upper
providers
to
be
use,
and
after
this,
of
course,
to
the
down
streams
to
the
customer
cone
so
and
so
on,
and
if
we
will
be
able.
E
If
I
will
learn
a
route
from
provided
appear
in
its
I
spot,
they
may
exist
only
customer
to
provide
a
pass
and
the
soul
so
to
be
able
to
not
really
did
but
verify
I
spot.
We
need
a
validated
database
of
customer
to
provider
relations
in
the
soul.
So
to
achieve
this
goal,
we
propose
a
new
ArchiCAD
project.
It's
called
out
own
system
provider
authorization.
It
has
three
fields.
First,
one
is
the
customer
here
he's
a
record
holder
host
he's
signing
the
object.
E
Second
is
their
provider
and
the
last
one
is
address
family,
because
connectivity
in
different
address
famous
families,
especially
IP
456,
of
course
I
can
hungry
table
right.
So,
of
course,
there
are
some
boundary
cases
for
transit,
free
networks
such
as
access
and
dear
ones.
It
can
be
easily
solved.
So
we
need
to
signal
that
routes
from
this
ice
piece
should
not
be
received
from
any
customer
or
peer,
and
it's
like
was
row
zero.
E
E
So
let's
go
to
the
verification
process.
I
think
I
don't
want
to
describe
that.
We
can
split
ice
bath
into
players
of
different
I
sense,
we're
all
prepared
values,
I
ignored,
and
after
that
we
have
a
brief
occasion
process.
This
is
very
similar
to
raw
validation.
We
are
gathering
all
candidates
as
pass
we're
checking
if
there
is
overlaps,
if
there
is
overlap,
so
then
it's
it's
returns
with
it.
It's
is.
E
There
is
no
elapsed
into
its
returns
invalid
and
if
there
are
invalid
pairs
in
the
ice
bath,
the
ice
bath
was
leaked
or
malformed
and
we
doesn't
really
care.
So
here
is
an
example
how
it
works
here.
Our
own
system,
before
is
an
attacker.
It
will
be
trying
to
hijack
address
space.
This
belongs
to
our
own
system,
one,
but
a
consistent
one
was
prepared.
So
each
has
signed
its
address
base
with
rows
each
his
ice
bar
records.
This
has
seen
that
it
has
single
provider
ice
to
and
also
a
consistent
to.
E
E
E
The
last
thing
that
eyes
for
may
try
to
do
is
to
remove
itself
from
the
I
spot.
But
again
it
will
raise
conflict
because
I
three
eyes
free,
must
check
that
their
neighbor
Ison
is
present
in
the
ice
bath.
So
there
is
no
way
attacker
may
hijack,
create
an
ice
bath
which
is
valid
according
to
Rose
and
I.
Spa.
E
And
small
benefit
this
process
may
be
fully
automated.
So
a
few
I
think,
two
years
ago,
I
was
presenting
the
GP
roles.
It's
a
configuration
option
that
can
be
negotiated
between
which
be
neighbors
and
to
avoid
mistakes.
It's
quite
super
suitable
here.
So
we
have
a
conversion
configuration
option
that
says
that
these
link
belongs
to
custom
of
these
links
belongs
to
provide.
That
is
the
link
belongs
to
peer,
and
with
these
options
we
can
automate
on
which
links
we
should
apply
ice,
positive
verification
on
which
we
should
not,
because.
E
E
E
E
The
question
is:
how
should
we
should
we
be
aggressive?
Maybe
it's
time
to
drop
it?
Maybe
it's
not.
I
will
be
glad
to
hear
your
PIN
here
and
there
are
several
other
questions.
Some
of
them
were
already
discussed
in
the
mailing
list,
so
please
feel
free
to
get
back
to
me
or
other
authors
and
share
your
view
or
go
to
the
manatees.
Maybe
it's
the
pictures
here
and
summary.
E
This
applique
record
is
really
simple:
it
scales,
we
are
not
bringing
any
new
messages:
new
sign
e
inside
bgp
protocol
itself,
it
has
a
low
computational
cost
and
with
a
rose
and
a
spa
together
can
provide
a
full
solution
for
malicious
activity
in
BGP
and
maybe
one
day
we
will
wake
up
in
a
next
beautiful
world.
So
thank
you
for
listening
questions.
Please.
J
J
I,
don't
know
if
your,
if
you
remember
sob
GP,
but
this
is
basically
the
same
thing,
which
is
fine,
I.
Think
the
all
the
protocol
bits
that
you
have
are
nicer
than
all
the
protocol
bits
that
were
in
SOP
GP.
So
it's
an
improvement,
and
so
that's
that's
comment.
One
and,
and
it's
interesting,
I
haven't
read
your
draft.
Yet
I,
you
know,
based
on
this
talk,
I
will
go
and
read
it.
J
The
second
thing
is
just
that
in
in
your
motivation,
you,
you
know
we're
talking
about
how
BGP
SEC
got
it
completely
wrong,
because
it's
asking
the
attacker
to
participate
in
BGP,
SEC
and
I
think
you
are
mistaken
about
that
and
it
doesn't
really
affect
the
rest
of
your
toe.
So
if
I
were
you
I
would
just
you
know,
drop
that
claim.
The
reason
I
think
you're
mistaken
is
the
the
underlying
assumption
in
the
GP
sac.
J
E
J
O
Sridham
nist
have
you
thought
about
the
situation
where
Naas
has
a
lateral
peering
relationships
a
in
north
america
with
another
AAS
and
the
same
a
is
and
that
a
s
in
europe
has
a
customer
provider
relationship?
That
is
that
that
has
happened
in
practice.
Have
you
thought
about
how
to
create
the
ASPA
in
in
such
a
situation?
O
E
F
Both
Randy
Bush
IJ
both
continue
John's
thought
and
also
to
disagree
with
little.
This
has
the
two
major
problems
to
me
of
sov
GP,
which
is
over
revealing
relationships,
and
it's
per
a
s,
not
per
prefix,
but
that's
why
you
like
the
protocol
a
little
better
than
this
OB
GP
is
SOP
GP
and
unfair
number
of
its
later
iterations
transported
the
database
within
region,
which
this
is
not
true,
which
is
why
it
appears
the
little
cleaner
but
I'm
not
complaining
about
that
right.
It's
reusing
the
rpki,
which
is
cool.
I
P
P
All
resources
must
be
correct
in
the
entire
chain
of
trust
between
you
and
the
trust
anchor
all
the
time
for
all
assertions
to
hold
and
if
anything
is
not
currently
correct,
because
somebody
has
over
claimed,
then
all
your
products
are
dead,
all
of
them
and
the
higher
up
a
tree
towards
the
root.
You
go,
the
more
the
risk
of
unexpected
damage
to
on
a
real
unrelated
party
Rises,
and
we
feel
that
this
is
an
operational
burden
which
the
community
should
not
have
to
bear.
P
When
we
first
presented
this
idea,
we
didn't
expect
to
come
out
the
door
with
a
discreetly
different
OID.
The
thing
here
is
that
certificates
can
only
have
one
OID,
that's
the
nature
of
an
x.509
certificate
as
I
understand
it,
and
since
the
oh
I
D
defines
the
validation
model,
and
since
there
was
no
consensus
in
the
room
to
agree
to
repurpose
the
validation
model
of
the
existing
OID,
it
is
necessary
to
accept
that
there
will
be
a
new
I
D
and
that
immediately
puts
on
the
table
the
transition
question.
P
So
if
we
think
that
we
have
to
move
to
a
new
model,
there
is
this
fundamental
requirement
that
requires
some
degree
of
coordination
and
I.
Absolutely
stress.
I
do
not
mean
to
imply
hierarchy
of
ordering
of
the
things
that
have
to
be
considered
here.
I'm
just
saying
there
appear
to
be
a
minimum
of
three
things
that
have
to
be
thought
about.
P
You
need
to
have
code
and
that's
on
two
sides
to
both
make
things
and
validate
things,
and
you
need
to
have
an
agreement
in
the
community
at
large,
which
principally,
is
about
both
the
signers
and
the
relying
parties
that
they
want
to
move,
but
you
also
have
to
know
how
you're
going
to
move
so
the
document
about
deploying
validation,
reconsidered,
effectively
kind
of
implicitly
said.
Well,
we
use
the
same
mechanism
that
we
do
for
rolling,
mean
algorithm.
P
P
Some
of
us
have
a
feeling
that
it
might
be
better
to
think
about
operating
permanently
in
a
mode
where
both
oh
IDs
can
exist,
because
it
effectively
offers
an
extra
bit
of
information.
It's
the
bit
that
says
I'm
saying
that
my
children's
minted
with
this
OID
have
behavior
a
or
I'm
saying
with
the
OID
minted
like
this.
They
have
behavior
B,
which
would
a
plow
allow
flexibility.
People
could
say:
I
asked
my
parent
to
make
me
a
strict
tree.
P
I,
don't
ever
want
you
to
validate
things
if
I
over
claimed,
or
they
could
say
no
I
think
there
are
operational
risks
here.
I
want
to
be
signed
into
a
world
that
if
over
claims
happen
prune,
don't
throw.
So,
let's
think
about
these
things,
one
by
one,
so
code
change
if
I
by
the
way.
This
is
an
unmodified
pack
from
a
presentation
given
in
IE
PG
and
if
I
could
try
to
short-circuit
and
represent
the
views
of
a
speaker
in
the
room
at
the
time.
P
My
first
bullet
may
be
wrong
because
in
fact
changes
are
not
minimal
to
signer
I.
Don't
remove
his
right
to
stand
up
and
say
it
for
himself,
but
in
principle
I
believe
they
were
a
simpler
class
of
change
than
for
relying
parties.
But
the
fact
is,
there
is
quite
a
high
change
burden,
even
on
signing
side,
because
the
depth
of
the
barrier
of
this
behavior,
interdependent
libraries
and
related
systems
is
quite
AI,
but
nonetheless
the
changes
in
some
sense
felt
to
me
minimal.
P
You
just
have
to
say:
I
want
to
use
an
OID
and
you
put
it
in
a
certificate
if
you
choose
to
go
with
mixed
mode,
they're
slightly
bigger,
because
you
now
have
to
think
about
user
interface
and
systems
and
flags
to
say
type,
A
or
type
B,
but
these
are
reasonably
contained,
but
for
validators
for
verifiers
there
is
this
other
burden.
You
now
have
to
live
in
the
world.
P
Where,
previously
you
were
carrying
with
you,
the
data
structure
down
from
the
root
or
up
from
the
bottom
of
what
assets
you
care
about
and
at
any
point,
if
you
find
they
don't
exactly,
are
match
or
are
fully
covered
by
their
parent
you're
out
of
the
game,
and
things
have
terminated.
But
now
we're
saying
no,
no,
no!
No!
You
have
to
go
and
get
some
malloc
memory
or
some
other
space.
P
You
have
to
construct
a
tree
of
the
things
that
are
valid,
hang
on
to
the
things
that
are
invalid
for
error,
reporting
and
carry
on
inside
your
recursing
structure
or
whatever
you're
doing
you
actually
have
to
mint
new
data
structures.
So
the
burden
of
code
construction
to
make
a
validator
for
the
new
model
got
to
accept
that
it's
actually
a
bit
higher.
P
The
principle
point
here
is
that
we
don't
actually
have
anything
deployed
now
at
some
level
we
think
signers
could
probably
deploy
more
rapidly,
but
the
fact
remains
there
aren't
any
it's
my
belief
that
the
right
validator
community
actually
did
talk
about
this,
and
the
developers
have
discussed
this
and
have
thought
about
coding
this
model,
but
it's
not
currently
in
deployment
and
the
two
other
principle
packages
that
are
used
are
pista
and
dragon
research.
They
don't
have
code
that
does
this
so
in
the
community
of
code
packages
that
make
certs
or
validate
certs.
P
This
code
just
doesn't
exist
and
for
a
pinochle
issue
here,
because
our
relationship
is
not
that
all
things
we
sign
exist
directly
with
holders
and
use
of
as
acids.
We
have
intermediaries,
the
national
internet
registries,
and
we
know
that
of
the
NIR
community's
two
of
them
are
in
deployment
using
dragon
research,
software
and
two
more
actively
testing
the
deployment,
so
we're
walking
into
a
regime
where
we
know
that
there
are
people
using
systems
that
don't
have
the
ability
to
use
the
new,
our
ID
okay.
P
P
Insider
ops
acts
as
if
the
closing
moment
is
definitionally
in
this
room,
and
we
feel
a
little
more
like
there's
a
conversation
to
be
had
with
operations
communities
at
the
nog
circuit
to
understand
from
people
who
are
in
deployment
mode.
What
their
feelings
are
here,
okay,
so
the
third
question
I
put
on
the
table
about
what
kind
the
flag
day:
that's
really
lovely,
because
it
is
compellingly
simple.
You
just
perform
a
bounded
transition
across
the
interval.
P
If
we
create
a
towel,
a
root
object,
a
trust
object
that
bears
the
new,
oh
I,
D
and
all
the
relying
party
software
does
not
accept
this.
Our
ID.
We
have
immediately
invalidated
the
state
of
the
entire
validation
tree
for
those
relying
parties.
So
that's
a
very
difficult
move
to
make
it's
kind
of
one
where
we
have
to
see
acceptance
and
consent
to
move.
Otherwise
we
are
simply
preemptively
destroying
the
tree,
so
we
really
have
to
achieve
some
sense
of
understanding
here.
Oh
sorry,
whoever's
got
the
microwave
on
your
coffee's
hot.
P
That
means
I'm
entitled
to
take
a
field
gold
in
Australian
rules.
Football
well
done
okay,
so
this
is
kind
of
a
three-way
deadlock.
You
know
both
wrestlers
are
on
the
ground
and
the
and
the
ref
is
knocked
out
too.
We
can't
move
without
code.
We
haven't
got
any
code.
We
can't
move
without
consent
from
the
people
involved.
We
haven't
sought
consent
and
we
can't
deploy
a
new
towel
without
either
of
the
above.
So
basically
nothing's
happening
here.
A
parallel
question
is
who's
actually
in
the
game,
and
I
did
some
basic
work.
P
P
Ok,
so
I
did
some
rough
rough
measurements
and
I
see
somewhere
around
300
IPs
from
178
ASNs
doing
arcing,
which
really
has
to
cover
the
65
IPS
and
39
AAS
ends
I,
see
doing
our
RDP
an
interesting
moment
in
IE
PG
is
that
Randy
said
he
has
radically
different
numbers
here
and
I
think
we
may
have
a
little
moment
where
we
find
a
student
to
do
some
measurements
on
who
is
in
system
and
where
they're.
Looking
because
that's
kind
of
weird
remember
this
is
an
all-encompassing
framework.
P
If
you
look
at
us,
you
should
be
looking
everywhere.
Everyone
should
be
seen
everywhere
all
the
time
and
that
doesn't
seem
to
be
the
case,
which
is
kind
of
weird.
So
I
was
able
to
gather
from
user
agent
strings
in
our
RDP.
What
the
rough
count
is
of
the
distribution
between
app
Easter
dragon
software
and
ripe,
and
my
rough
feeling
is
that
it's
approximately
two
to
one
a
using
our
P
store
and
Dragon
it's
possible.
P
Those
numbers
are
wrong,
but
in
no
sense
is
the
majority
of
the
community
using
our
RDP
and
in
that
sense,
in
no
sense
is
the
majority
of
the
community
using
code.
That
I
know
has
potential
to
do
modified
validation
because
ripe
indicated
they
would
think
about
it.
So,
in
a
world
where
there
are
three
platforms
in
the
space,
and
only
one
of
them
is
thinking
about
implementing
and
they're,
not
even
the
dominant
player,
we're
not
heading
to
a
trajectory
where
community
is
going
to
be
using
new.
P
Oh
I,
D
aware
software,
so
that's
kind
of
a
strong
message.
It
is
already
a
distributed
problem.
This
is
the
breakdown
of
the
economies
of
the
prefixes
that
came
to
me
doing
validation.
So
my
sense
is
in
no
sense
is
this:
an
activity
where
I
only
have
to
talk
to
one
or
two
people
we,
the
community,
interested
in
making
the
move.
We
actually
have
to
talk
to
a
lot
of
people
spread
across
a
lot
of
places.
P
So,
if
we're
going
to
do
this,
it's
actually
quite
a
big
burden,
but
I,
don't
think
waiting,
not
talking
about
this
I.
Don't
think
anything
gets
easier
here,
because
we're
talking
about
a
change
that
I
believe
is
a
conversation
with
under
five
hundred
parties.
The
number
of
downstream
affected
people,
the
IP
coverage.
P
C
Seems
like
roughly
you're
proposing,
there's
three
things
you
prefer.
You
seem
to
prefer
one
which
is
a
flag
day.
You
point
out
that
there's
potentially
five
hundred
some
users
who
would
be
network
operators
who
would
be
affected,
yeah
I,
think
none
of
the
answers
really
look
great,
but
I
think
picking
one
is
opposed
to
vacillating
would
be
good,
so
picking
one
and
picking
a
date,
that's
achievable
and
then
trying
to
figure
out
how
to
message
to
people
who
are
certainly
going
to
be
affected.
Yeah.
P
P
P
So
now
long
ago,
I
would
have
said
that's
inconceivable,
but
having
looked
in
logs
I
know,
that's
true
because
at
least
three
of
the
user
agent
strings
appear
to
be
web
browsers
that
have
walked
into
the
our
RDP
URLs
in
someone's
documentation
and
they're
refreshing
for
no
purpose.
So
yes
that
definitely
exists.
It's
a
superset.
It's
not
just
people
doing
work
so.
C
I
think
there
are
folks
in
there
folks
in
the
right
area,
Joe
who
are
looking
at
rpki
stuff
and
potentially
know
who's
they're,
either
pushing
people
to
do
this.
They
know
which
deployments
are
happening
same
thing
in
LAC,
nick
Carlos's,
folks
or
my
brain
is
skipping.
My
old
ad
who's,
probably
in
the
room,
not
Joe,
Benny
Joe
I'll
figure
it
out
later.
But
the
point
is
I
think
there's
folks
in
region
that
probably
have
some
idea.
C
C
C
P
P
P
Yes,
it's
always
a
moment
when
your
co-author
gets
up
to
the
microphone
queue
because
he's
probably
gonna
say
something
that
says
what
George
said.
It
was
completely
not
what
I
intended.
No
no
he's
walked
away
from
the
mic.
He's
walking
back
he's
walking
back
he's
walking
back
Rob
Rob
hit
me
Rob
hit
me
with
your
rhythm
stick.
D
Q
Q
Exists,
secondly,
there
are
actually
two
separate
conversations
here,
one
of
which
you
are
making
it
difficult
to
have
by
not
having
a
draft.
Yes,
I
know,
there's
upstairs
politics
about
that,
but
this
is
the
ITF
we
discussed
drafts
here
with
like
actual
schedules
and
timelines
and
considerations
rather
than
our
point
so
next
time
you
do
this.
Please
have
a
draft
or
you
know,
stop
wasting
our
time.
Yeah.
P
Q
R
Yeah,
my
girls
no
longer
with
ripeness
to
see
actual
evils
and
all
that
laughs,
so
I
can't
speak
for
ripens
to
say,
but
I
can
speak
from
memory
a
bit
as
to
the
implementation
in
the
archive
validator
by
the
writers
version.
Two
of
that
was
implementing
the
reconsidered
protocol
at
some
point,
but
as
a
global
setting
right
and
changing
that
to
respect
a
birth
certificate,
choice
based
on
the
oid
should
not
be
that
hard,
but
I
understand.
There's
more
players
in
in.
P
R
I
think
it
can
be
done
for
the
version
three
I
wasn't
involved
in
that
project.
There
was
a
decision
not
to
do
this
until
you
know
it
would
become
clear
what
far
forward
is,
but
regardless
there's
a
new
idea.
So,
no
matter
what
current
software
doesn't
support
it,
so
there
would
have
to
be
an
update
to
support
this
particular
way.
P
R
R
I
think
there
are
three
choices
here.
Indeed,
so
one
is
don't
deploy.
Another
is
look
at
the
the
algorithm
all
over
document.
Depth.
Steps
in
existence
is
about
best
practice,
but
that
still
includes
flag
days.
It
just
prescribes
that
the
whole
tree
should
have
the
same
ideas
and
you
can
look
at
the
mix
model
which
also
has
flag
days,
but
I
think
less
of
them.
R
Finally,
I
don't
know
if
you
can
agree
to
disagree
on
this
with
other
people,
but
the
way
I
see
it.
This
is
not
an
excuse
to
cause
over
claims,
but
this
is
a
way
to
just
limit
those
things
and
I've
always
felt
that
the
change
was
fairly
minimal
in
the
sense
that
what
it's
trying
to
do
is
it
just
limits
the
impact
to
resources
our
on
the
dispute?
This
is
something
that
any
CA
that
has
a
over
claiming
certificate
could
take.
They
were
aware
of
the
fact
that
their
certificate
has
been
shrunk.
R
This
doesn't
always
happen,
though.
Yes,
it's
good.
If
you
can
avoid
this
and
transfers,
but
the
reality
is
you
may
not
be
able
to
so
you
know.
Is
that
a
big
enough
problem
that
this
should
be
deploys?
I,
don't
know
I
I
can't
speak
for
the
RER
anymore
abuse
me,
but
I
I
know
that
the
problem
is
felt
big.
Their
operators
I
think
it's
good
to
reach
out
to
the
operator
community
because
they
should
think
about
this.
If
we
want
to
be
impacted
by
this
or
not.
F
Randy
Bush
ijr
Kasbah
operator
should
think
about
what
where's
the
document.
This
isn't
just
disrespectful
of
the
process.
This
is
disrespectful
of
the
people
here
and
the
people
you
will
go
around
showing
this
slide
deck
to
who
cannot
see
exactly
what
I'm
being
asked
to
buy
into
and
I
agree
with
Chris.
If
we're
gonna,
do
this
better
start
soon?
F
Let's
start
what
soon,
if
you
don't
give
us
the
document
where
some
expletive
expletive
exploited,
the
you
know,
documents
take
a
while
here
and
there's
a
document
by
Tim
and
oleg
documenting
the
right,
validator
algorithm
that
has
been
in
this
working
group
for
almost
six
years
and
all
messages
to
the
chairs
fall
on
the
floor.
That's
what
I'm
really
talking
about,
because
oleg
asked
me
to
twice
in
the
last
week
got
the
message.
Thank
you.
F
A
Video
folk,
yes,
also
coming
back
to
the
question
of
were
well
okay.
How
well
is
the
required
communication
working
in
my
view.
In
my
view,
this
group
is
the
identified
forum
where
this
technology
is
being
discussed.
It
would
be
potentially
good
thing
for
having
an
actually
existing
forum
of
the
people
who
are
actually
operating
stuff.
A
I'm,
not
aware
that
that
is
the
that
that
is
available
and
being
developed
and
kind
of
the
first
thing
that
has
to
happen
to
actually
having
documents
to
be
scrutinized
here
and
quite
certainly
I
would
not
go
away
where
you
essentially
bypass
this
group
and
start
discussing
details
with
operational
groups
which,
in
the
end,
certainly
have
to
contribute
so
that
the
operational
aspects
actually
get
fitted
in,
but
kind
of
the
thing
has
to
actually
be
done.
First
here
or
well,
okay,
you
are
free.
F
R
R
Think
realistically,
you
can
only
set
a
day
when
you
have
a
good
understanding
that
relying
party
tooling
will
be
updated
in
a
way.
That's
well
defined
and
understood,
so
I
do
think
it's
good
to
talk
to
two
operators
that
maybe
not
be
in
this
room,
but
I
think
that
a
good
understanding
of
we
now
understand
if
it's
a
mixed
model
or
whatever.
We
now
understand
this
thing
to
work
in
a
particular
way.
I
think
that
has
to
be
a
shared
understanding
between
relying
party.
F
George
and
I
did
this
dance
at
the
IPG
meeting.
When
Nietzsche
I
said
this,
he
was
not
talking
about
religion.
He
was
saying
that
we
are
responsible
for
our.
This
is
the
birth
of
existentialism,
we're
responsible
for
our
own
acts.
God
is
not
don't
blame
her
we're
responsible
for
our
own,
that's
where's,
the
clicker.
This
is
no
fun
without
a
clicker.
F
Okay,
George
and
I
are
actually
friends.
We
write
papers
together,
we
work
together.
We
had
lunch
together,
but
maybe
it's
more
like
brothers,
we
fight
a
little,
but
we
not
our
masters,
are
responsible
for
our
actions.
So
you
have
my
sympathy
George,
but
the
facts
are
the
facts.
The
real
problems
with
the
rpki.
What
actual
problems
do
we
have
and
I'm
an
engineer?
I
worry
about
problems,
we're
researcher.
We
only
care
about
problems,
bla
bla,
bla,
okay,
the
rpki
is
doing
fairly
well
and
warning.
F
F
F
Okay,
here's
one
thing
installed:
this
is
a
problem.
A
penis
is
very
aware
of
it.
They
hate
it.
George
is
suffering
he's
caught
between
his
masters
and
reality.
My
sympathy
George
I,
bought
you
lunch.
Okay,
the
same
thing
shows
on
dragon.
Research
RP
except
the
eye.
Candy
has
less
sugar
and
there
is
no
trust
anchor
role
protocol.
This
is
our
mistake.
F
Tell
roll
correct
okay
certification
problems,
they've
gone
on
for
years.
Everything
below
this,
our
irca
went
missing,
because
the
e
certificate
had
a
different
mount
expiration
for
the
manifest
than
the
CA
they
went
away.
They
don't
have
a
knock.
It
goes
on
and
on.
Okay,
I
won't
drill
it
down
this.
These
are
some
old
data
right.
F
You
see
that's
an
inability
to
fetch
for
days.
They
didn't
monitor,
they
have
no
knock,
they
don't
work
weekends,
that's
right!
A
friend!
This
is
old
Veda.
They
still
do
not
have
a
knot.
They
still
do
not
work,
weekends.
Okay,
that's
fine,
except
they're,
asking
us
to
rely
on
it
operation.
That's
not
fine!
If
you
can't
do
it
yourself,
how
sorsa
to
a
real
obstacle?
F
F
Okay,
weird
data,
RFC,
71
15,
says
our
state
must
be
hierarchic
directory
structure,
so
it
can
just
fetch
it
with
one
TCP
setup.
Instead
of
five
thousand
here's,
the
five
thousand
ripen
AP
NIC
make
you
fetch
all
of
them
and
it
takes
forever
ripe
fixes
it
look
how
wonderful
that
is,
and
look
at
a
nice
clean,
key
role
by
the
way
they
doubled.
Their
objects
went
back
to
normal,
so
ap
NIC
still
has
not
fixed
that
they're
still
out
of
RFC
on
that
and
everybody
running,
our
sync
pays
the
TCP
setup
price.
Okay.
F
Luckily,
the
RP
software
is
willing
to
use
stale
data,
but
how
long
is
stale
our
IR
s
have
had
three
and
five-day
outages
of
various
services.
Now,
of
course,
I
never
make
mistakes
you're
supposed
to
laugh,
but
you
know
you
can't
reach
me
on
weekends,
but
we've
had
no
major
rpki
disasters
recently,
okay,
so
let's
make
some
lane
delegation.
F
Ap
NIC
has
the
problem
of
having
a
child
repository
that
CN
make
that's
behind
the
firewall
ap
nichkhun
CN
nick
have
been
working
on
this,
for
you
could
have
had
a
child,
but
it's
the
same
as
a
DNS
flame
delegation
right.
How
do
we
support
that?
F
F
F
Let's
have
a
flag
day.
This
is
an
actual
count
and
you'll
notice.
It's
quite
different
than
George's
of
the
number
of
our
RDP
fetchers
unique
IDs,
fetching
our
RDP
and
unique
IDs
fetching
our
synced
that
those
are
significantly
different
from
George's
is
fun
and
we're
already
agreed
to
scrape
up
a
grad
student
fetch
all
the
CAS
and
find
out
why
this
is
different.
As
I
said,
George
and
I
are
friends
and
do
research
together,
but
there's
a
lot
of
folk
out
there
to
have
the
flag
day.
As
chris
says
it
ain't
going
to
get
less.
F
F
Okay,
if
the
I
Anna
was
the
single
point
of
trust
as
we
expected,
they
are
conservative
about
this.
They
document
things
they're
the
other
extreme
and
they're,
successfully
rolling
things.
Okay,
but
rir
is
politically
refused
to
let
the
Ayane
do
anything
except
accept
their
cash.
Of
course,
the
our
IRS
aren't
operators
they're,
like
PT,
t
s,
so
the
protocols
don't
have
the
resilience,
our
bad
and
that's
what
we
should
be
working
on.
Our
IR
s
have
operational
and
publication
problems
repeatedly.
F
They
need
to
fix
this
or
outsource
it
or
whatever
validation,
reconsidered,
solves
a
problem
that
they
are
not
having,
and
it
will
make
things
less
predictable
and
understood,
and
it
looks
like
it's
going
to
be
a
flag
day,
so
how
that
flag
day
works.
What's
going
to
happen
when
people
fall
out
and
don't
make
it,
how
that's
detected,
how
it
will
be
fixed,
etc,
needs
to
be
documented.
H
That
one,
yes,
that's
the
eighth
slide.
Unfortunately,
this
is
not
how
things
look
when
you
install
the
software
as
shipped,
for
instance,
the
air
Intel
will
never
be
there
and
I've
deployed
rpki
in
a
number
of
commercial
ice
peace
in
the
Netherlands.
Now
and
invariably,
every
time
we
install
this
beast.
F
That's
another
problem
and
I
should
check.
Oh,
my
god,
the
aren't
there
I
do
not
I
just
built
a
VM,
threw
it
up
and
did
it
and
clearly
there
clearly
I
have
indeed
manipulated
the
towels,
because
also
the
alt
see
a
towel.
Is
there
yep,
but
the
fact
that
the
Arum
tell
wouldn't
be
there
is
a
serious
problem.
It.
H
Is
very
very
concerning
yep
good
point:
I
have
spoken
with
some
of
the
re
ARS
to
create
a
feedback
loop
between
their
own
rpki
services
and
how
that
looks
from
an
operational
perspective.
So,
for
instance,
this
weekend,
I
proposed
to
pave
that
K
routes
should
do
origin,
validation
and
that
way
it'll
suffer
in
the
same
way.
The.
F
H
F
S
Could
that's
why
you
should
trust
I
can't
cover
dyes,
but
right?
This
is
just
informational
point,
yeah,
guess
four
carat
or
we
have
rose
for
the
prefixes
we
announced
and
we
got
a
proposal
to
actually
start
religion.
Valuation
which
we
are
looking
into
so
case
were
out
for
our
multi
humped
home
site
you're,
going
to
do.
S
S
S
Ncc
in
general,
has
that
and-
and
there
is
a
procedure-
is
a
general
number
that
at
the
back,
they
have
procedure
that,
if
it's
about
this,
then
send
it
to
that
support
engineer.
So
we
already
have
that
we
don't
have
it
for
our
PGI,
it's
specifically
for
any
part
of
our
cacao
subsystem,
but
that's
another
thing.
We
have
to
consider
to
set
up
support
for
that
cool.
Thank
you.
R
R
R
So
Randy
did
you
read
written
that
you
ate
his
document?
Yes,
okay,
thanks
great
good,
Anna
and
I
know.
I
did
get
some
comments
from
some
people,
but
I
figured.
Maybe
let
me
ask
the
room
if
people
looked
at
this,
because
this
disk
goes
in
into
the
issue
that
there's
no
way
currently
to
roll
a
trust
anchor
key
in
the
aapki,
I
and
I
think
it's
an
issue
we
should
be
thinking
about
so
I
know
some
of
you
have
read
it.
Nobody
wants
to
show
their
hands
like
yeah.
Look
at
it,
I'll!
R
R
Have
something
but
yeah
there
are
lessons
to
be
learned.
So
what
can
we
learn?
Well,
first
of
all,
I
did
talk
about
this
at
the
last
ITF
and
then
I
made
a
quadrant
about
you
know.
Is
this
important
urgent?
Where
are
we
and
I
figured
that?
Maybe
this
is
really
important
to
me
at
least,
but
maybe
it's
not
super
urgent,
but
I
cannot
reconsider
that
position
to
myself.
I
think
this
is
also
earned.
R
I
think
this
is
something
that
needs
to
be
addressed
before
you
have
a
bigger
number
of
relying
party
tools
out
there
that
don't
support
whatever
algorithm
there
is,
then
there
are
lots
of
things
in
RFC
fifty
eleven
that
are
very
DNS
specific
and
while
they
make
up
for
an
interesting,
read,
I'm,
not
so
sure
that
they
really
apply
here,
because
the
model
of
getting
things
is
differently.
There
is
no
time
to
live
with
regards
to.
If
you
get
this
certificate,
that's
mentioned
in
the
tell
you
can
keep
it
for
so
long.
R
Essentially
you
get
it
every
time
you
may
keep
it
all
back
up,
but
it's
pretty
undefined.
Actually,
so
maybe
that's
something
that
should
be
valid.
It
fine,
but
you
know,
backup,
keys,
yeah,
so
that's
possible
in
in
the
NSX
I'm,
not
sure
that
we
should
go
there
to
be
honest
because
you
can
easily
end
up
in
a
situation
where
you
have
two
problems.
Now
you
have
two
keys
protect
and
if
you
lose
one
of
them,
Braun's
bootstrapping
is
a
big
thing,
so
you
have
outdated
software.
R
Q
I'm
just
going
to
put
comments
on
two
things:
one
I
agree
about
the
lots
of
DNS
specific
timing,
the
TTL
stuff
that
was
self
inflicted
DNS
damage
on
DNS
SEC,
don't
worry
about
it.
The
back
of
keys
I
would
recommend
you
at
least
think
about
a
bit
more,
the
main
reason
being
that
there's
no
way
to
do
an
emergency
key
role.
Basically,
you
can
do
staged
key
roles.
You
can
do
Plan
B
key
roles.
Q
R
Yeah
I
have
some
more
slides
later.
Maybe
it
makes
more
sense
to
talk
about
it
after
I
come
through
that.
So
what
are
the
objectives?
Well,
my
main
objective,
this
plan
roles
I
want
a
process
that
is
automated.
That
can
work
unattended
and
I
want
to
leave
a
trail
for
outdated
software.
I
mean
people
install
things
on
docker
images
and
they
don't
update
it.
You
know,
might
be
the
wrong
way
to
do
it,
but
it
happens
so
wanted
to
be
able
to
get
the
latest
somehow.
R
So
this
is
going
and
if
you
read
the
Drakh,
you
may
notice
that
yeah,
maybe
I
changed
things
a
bit,
but
that
was
also
after
discussing
and
I'd,
rather
focus
here
on
how
I
think
things
should
work
and
then
have
a
discussion
about
that
and
move
forward.
But
I
think
this
is
still
in
alignment
is
rough.
This
is
basically
there's
no
role
happening
at
the
moment
at
all.
R
What
a
draft
then
says
is
that
you
can
have
a
new
object,
a
dot
L
object
and
it
basically
refers
back
to
where
a
difficut
file
has
been
found.
If
a
relying
party
sees
this,
they
can
go
like
okay,
that's
great,
that's
is
an
agreement,
but
I
have
nothing
to
do
so.
I
can
just
continue
a
small
then
during-
and
this
is
where
I'd
rather
focus
on
this
mice,
and
what's
the
exact
text
of
the
document.
R
R
I
R
I
B
R
I
welcome
that
discussion.
So
one
thing
you
could
protect
against,
if
you're
afraid
of
key
loss,
you
can
use
hardware
security
model
theft.
You
can
use
hardware
security
modules
with
card
sets
and
all
that
that
make
it
very
hard
to
steal
a
key,
not
say,
but
then
you
still
have
an
issue
of
key
loss
that
you
may
want
to
think
about.
But
what
are
the
properties
of
that
when
you
now
have
two
keys
to
protect
because
yeah?
R
Maybe
it's
slightly
better,
because
if
you
lose
the
new
key,
you
still
have
the
old
one
and
vice
versa,
but
yeah
in
any
case
are
used,
but
it's
missing
the
yes
yeah.
Oh,
it's
just
not
fullscreen,
no
right!
Okay,
yes
back
so
ta
roll,
so
we
were
here.
Everything
is
fine.
That's
just
this
new
object
says
to
the
relying
party
yeah.
This
I
think
this
is
still
my
current
certificate,
a
my
current
key
now
during
a
key
role.
R
What
you
could
do
and
what
the
document
kind
of
says,
but
they
don't
miss
a
important
detail,
is
you
can
set
up
a
parallel
structure?
Actually,
you
can
set
up
a
new
ta
certificates,
new
key.
You
can
publish
all
the
objects
there.
You
can
have
a
truss
anchor
there.
So
Sangha
tell
final
that
points
back
and.
R
Information
access,
your
eyes
that
is
basically
I,
think
intended
as
an
informational
thing.
We
had
a
talk
about
it.
You
know
a
long
time
ago,
though
there's
a
back
reference
for
every
certificate.
That
says
this
is
the
arcing
URI,
where
my
parents
certificate
lives,
if
you've
really
really
strict
about
that,
you
would
find
that
there's
differences.
If
you
find
something
through
a
different
path,
you
might
reject
things,
and
that
would
really
complicate
this.
So
I
would
suggest
that
we
talk
about
deprecating,
the
this
field
or
at
least
make
it
a
informational
thing.
Q
We
already
have
to
ignore
AIAS
during
internal
key
roles,
further
down
the
tree,
I'm,
pretty
sure
we
got
that
right
somewhere
buried
in
the
depths
of
the
original
documents
that
their
advisory.
You
should
not
reject
anything
just
because
the
AAA
is
wrong,
so
I,
don't
think
there's
any
documentation
needed
I,
don't.
R
Think
it's
a
key
for
the
ripens
received
on
the
data
either,
but
it's
it's
good
to
know
because
yeah
another
place
where
this
may
cause
an
issue
is
that
you
know
in
case
you
want
to
change
your
publication
points.
You
have
issues,
maybe
you
want
to
outsource
it.
You
know,
and
you
can't
otherwise.
So
but
anyway,
you
can
have
two
parallel
structures,
and
but
the
draft
actually
currently
says
is
that
you
would
go
to
the
after
stage
very
quickly,
but
I'm
quite
willing
to
discuss
that
and
say
you
know,
maybe
not
go
there
very
soon.
R
You
could
leave
both
in
place
for
awhile.
This
also
gives
people
see
the
the
opportunity
to
you
know
update
their
relying
party
software
manually.
You
can
communicate
this
no-tell
out
of
bounds,
as
you'll
probably
have
to
do
at
least
if
you're
beginning
to
deploy
this
stuff,
because
not
everybody
will
support
it
straight
away,
I'm
sure-
and
maybe
it's
something
you
want
to
build
up
operational
experience
with
before
you
go
further,
let's
say,
but
eventually
you'll
get
what
to
get
rid
of
the
old
key.
R
So
afterwards,
what
you
can
do
is
you
can
throw
away
your
key
you
old
key.
You
can
throw
away
all
the
objects
and
just
leave
a
pointer
in
place.
These
things
need
to
be
signed
with
a
long
pole
it
at
the
time
we
can
argue
about
how
long
makes
sense
there's
currently
something
in
the
document
that
says
one
year,
but
that's
completely
arbitrary.
Maybe
it
should
be
much
longer
but
yeah.
That's
it
essentially
that's
being
proposed,
and
you
couldn't
Deary
also
talked
about
using
this-
to
have
backup
keys
rather
like
indicate
this.
R
R
No
sorry
so
again,
maybe
click
through
this.
If
you
read
the
document,
it
basically
goes
from
this
to
this
very
quickly,
but
after
discussions,
feedback
I
think
it
does
make
sense
to
have
this
stage
there
for
a
longer
time,
at
least
until
operational
experience
shows
that
people
can
do
the
role
automatically.
R
What
I
do
think
makes
sense
if
we
want
to
peek
provision
keys.
That
can
be
a
separate
discussion,
but
as
written
the
and
that's
what
I
wanted
to
say,
the
TA
dot
star
in
the
blue
column
here
immediately
points
to
the
new
choice
anchor
here
and
when
that
happens,
I
believe
that
relying
parties
should
be
should
be
able
to
trust
that
their
TA
that
I
work
I
mean
it
ca,
can
mess
up
their
system
in
many
other
ways.
If
they've
done,
the
validation
I
think
it
shouldn't
be
necessary.
R
For
you
know,
an
arbitrary
number
of
relying
parties
double
check
whether
they
did
our
work
correctly,
at
least
that's
my
view,
but
yeah.
If
you
really
want
to
go
there,
and
we
say
we
want
a
pre
provisioning
key
or
you
want
to
say,
we
intend
to
role
on
this
today
and
you
are
welcome
to
verify
then
I
think
we
can
do
it,
but
we
need
to
risk
everything
to
structure
a
bit.