►
From YouTube: IETF113-SAVNET-20220324-0900
Description
SAVNET meeting session at IETF113
2022/03/24 0900
https://datatracker.ietf.org/meeting/113/proceedings/
A
A
B
D
D
D
So
what
is
safnet
sapnet
this
session
is
a
so-called
exploratory
birds
of
a
feather
session.
This
means
we
are
not
a
working
group.
This
is
a
congregation
where
we
look
for
other
interested
parties
for
feedback
from
the
wider
community
on
the
problem
of
source,
address,
validation
and-
and
we
don't
know
where
exactly
this
work
will
go
after
this
session,
but
this
session
exists
to
help
us
inform
on
what
potential
next
steps
exist
and
who,
who
the
people
are
that
are
interested
to
take
on
this
work.
B
B
B
A
A
A
A
A
So
this
safe
actually
is
an
old
problem
with
a
very
long
history
of
attention.
In
ietf,
as
early
as
the
year
of
1998,
english
filtering
or
acl
based,
the
safe
was
proposed
in
offset
2267,
but
its
problem
is
that
it
requires
manual
configuration
after
that
in
2004
fc3704
proposed
the
strict
erpf
feedable
erpf,
as
well
as
lucy
rpf.
A
The
recent
efforts
on
safe
mechanisms
is
savvy
and
efp
rpf
in
savvy
working
groups,
six
rfcs
were
proposed
from
the
year
of
2012
to
2017,
with
a
focus
on
host
level,
save
in
access
networks
or
enterprise
networks,
and
about
two
years
ago
fc
8704
proposed
the
efp
rpf,
which
is
actually
an
enhancement
version
of
feedable
erpf,
with
the
focus
of
mitigating
the
problem
of
strict
erpf
and
feedable
erpf.
In
some
cases,.
A
A
A
A
So
the
effect
is
that
if
all
the
other
resulters
in
the
network
make
the
same
deployment,
that
is
all
the
other
routers
applies
strictly
rpf.
Only
under
the
subway,
the
port,
that's
okay!
There
will
be
no
problem,
however,
in
practice
we
cannot
require
that
all
the
routers
makes
the
same
deployment
and
let's
assume
that
if
only
router
1
2
4
7
makes
a
deployment
and
the
other
daughters
are
in
in
the
anti-product
area,
there
will
be
problems.
A
A
So
it
means
that
in
this
case,
applying
strictly
rpf
and
all
the
ports
into
the
receive
will
have
improper
block
problem
as
a
whole.
No
matter
whether
we
apply
strict
erpf
and
a
separate
port
or
apply
strictly
rpf
at
all
the
ports,
there
will
be
either
improper
permit
problem
or
improper
block
problem
for
interdependent
network.
A
A
A
Okay,
then,
we
may
ask
that
hardboard
s4
choose
other
urpf
mechanisms.
Besides,
okay
strike
the
rpf
feedable
and
a
fp
erpf
with
algorithm
a
there
are
two
other
erpf
mechanisms.
One
is
loose
erpf,
so
loose
erpf
will
cause
significant
improper
permit
in
the
eft
urpf,
with
algorithm
b,
proposed
some
enhancement
on
that.
A
A
Okay.
Now
we
can
observe
that
there
is
another
problem
that
is
when
the
packets
from
s1
and
s2
spoof,
the
source
addresses
of
each
other
as4
will
improperly
permit
these
packets,
because
s4
has
no
capability
to
distinguish
the
package
from
its
customer
asses
generally,
we
can
conclude
that
loose
urpf,
eft
urpf,
with
algorithm
b
interdimensive,
may
need
to
improper
permit
problem.
A
A
We
think
that
the
root
cause
of
the
improper
block
and
improv
permit
problem
for
erps
for
urpf
is
the
safe
mechanism.
Is
that
urpf
is
a
load
level
technology
that
means
that
they
all
never
reach
the
local
feed
or
rep
table
of
routers
to
decide
the
incoming
interface
of
packets,
which
may
not
match
the
real
data
plane
forwarding
pass
so
to
solve
this
problem
and
achieve
accurate
receive.
A
We
may
need
a
network
level
technology
instead
of
the
node
level
technology.
We
hope
that
electric
level
protocol
can
help
build
an
independent
and
accurate
save
table
in
each
router,
which
follows
the
real
data
plane
forwarding
pass
and
compared
with
strictly
rpf.
This
save
table
is
different
from
the
fifth
table,
so
the
improper
block
problem
under
asymmetrical
routing
can
be
avoided
and
compared
with
feasible,
erpf,
loose
crpf
or
efprpf.
A
A
A
Urpf
based
the
safe
mechanisms
have
either
improper
block
problem
or
improper
permit
problem,
and
we
argue
that
the
root
cause
of
your
pf
is
the
safe
mechanism.
Is
that
it's
a
node
level
technology
and
it
depends
on
router's,
local
feed
or
rib
for
for
checking
the
source
address
and
to
achieve
accurate
receive.
D
F
A
A
A
F
A
F
Here
we
go
okay,
so
in
this
module
either.
One
of
those
is
fine
in
this
model.
In
order
for,
in
order
for
for
sav
to
work,
it
would
need
to
be
the
case
that
the
that
you
trust
the
routers,
the
as1
router,
the
as2
router-
to
enforce
the
behavior
basically
to
enforce
the
address
validation.
Is
that
correct?
F
Yes?
So,
in
other
words,
if
the
the
problem
that
you're
stating
here
is
that,
if
cust,
if
a
device
on
the
customer
network
sends
a
packet
to
the
as1
router,
the
as1
router,
that's
got
a
bogus
source
address.
The
as1
router
is
trustworthy.
You
trust
the
as1
router
to
to
block
that
packet.
Is
that
right.
A
A
F
F
Or,
for
example,
it
might
even
come
from
as2
and
still
as4
is
going
to
have
no
way
to
tell
where
that
packet
came
from,
because
nothing
in
the
ip
header
to
authenticate
it.
So,
therefore,
part
of
the
trust
model
here
is
that
I
think,
if
I
understand
you
correctly,
is
that
you're,
assuming
that
the
routers
are
trustworthy,
that
as1
is
going
to
reject
a
bogus
source
address
from
its
own
internal
network,
and
that
that's
part
of
the
trust
model
is
that
right.
A
Actually
they
can
only
get
the
correct
direction
of
this
pack
of
this
source
address,
but
if
there
is
some
spoofing
between
the
ascs
along
the
same
path,
actually
they
cannot
distinguish
between
them,
but
the
the
key
is
that
if
we
can
do
this
kind
of
port-based
direction
checking,
even
though
there
is
some
source
address,
spoofing
along
the
parts,
actually,
we
can
narrow
skip
and
the
hair
parts
twist
back.
The
source
stress,
moving.
E
F
Okay,
all
right
that
helps
yeah.
The
reason
I'm
asking
about
this
is
because
the
trust
model
here
is
unclear
and
I
think
it's
actually
worth
documenting
the
trust
model
when
you're
talking
about
this,
because
otherwise
you
know
when
I
look
at
this,
I
think
well,
your
solution
sounds
like
it's
complex
and
wonderful,
but
doesn't
actually
solve
the
problem,
because
you
still
have
the
trust
problem,
but
if,
if
so
so
saying
why
that
model
actually
makes
things
better
is
important
and
then
the
other.
F
The
other
question
that
I
had
is
just
that
you
know
and
which
actually
ties
back
to
what
you
just
said
is
that
in
in
this
scenario,
as4
is
the
is
the
isp
as12
and
three
are
customers,
so
the
enforcement
path
here
is
is
different
than
it
would
be
if
these
were
all
independent
right,
and
it's
worth
talking
about
that
as
well,
I
think
so.
That's
all
I
wanted
to
say
I
mean
I
think
this
I
you
know
I
don't
have
any
objection
to
any
of
this
stuff.
I
just
want
to
make
it.
A
D
H
A
So
by
algorithm
b,
it
can
avoid
the
improper
block
problem
in
algorithm
a
but
may
have
improper
permit
problem,
but
because
the
aces
in
the
customer
code
kind
of
spoof
each
other.
So
if
you
have
more
interest,
I
think
you
can
refer
to
the
office
8704.
It
has
a
very
detailed
description
yeah.
Thank
you,
okay.
Okay,
thank
you
very
much.
C
C
A
I
G
I
You
propose
a
network
ladder
protocol
for
discovering
real
data
plane,
the
real
data
playing
fast
right
so
yeah,
instead
of
because
I
you
know,
we
have
to
pay
a
cost
for
for
this
discovery
for
this
network
level
protocol.
So
I'm
wondering
if,
if
we
consider
that,
if
we
can
consider
multiple
feasible
paths
to
apply
said,
rules
can
also
work
or
you
you
did
you
just
think
about
that
or.
A
Oh
okay,
okay!
I
I
get
your
question
I
think
in
our
meaningless.
Maybe
yari
has
okay
asked
a
similar
question.
That
is
okay.
If
we
just
make
this
probing
of
the
real
data
plane
path,
of
course,
we
will
pay
additional
cost
and
the
alternative
way
is
that
hardware
we
just
use
some
feasible
paths
and
all
the
packets
arriving
around
the
feedable
path
will
be
permitted.
Otherwise
they
will
be
blocked.
A
Actually,
this
is
the
same
idea
used
in
feedable
erpf,
but
this
idea
actually
also
has
improper
block
or
improper
permit
problem,
because
when
the
packets
okay
come
from
the
past,
that
is
beyond
the
feasible
parts.
Just
like
the
example
we
use
in
the
interdimensional
okay.
Actually
it
will
cause
improper
block,
because
okay,
maybe
is,
does
not
learn
the
routing
parts
of
the
of
the
actual
okay
data
plane
forwarding
pass
because
of
some
launching
policies.
A
So
you
see
we
are
causing
block
problem
and
this
kind
of
a
fadeable
path
solution.
We
are
also
needed
to
improve
permit
problem,
because
this
is
very
straightforward
right,
because
there
are
multiple
fatal
paths,
but,
okay,
the
real
data
plane
falling
past
is
only
one.
So,
of
course,
there
will
be
some
improper
permit
problem.
Okay,
thank
you.
Thank
you
for
this
question.
I
C
G
A
A
A
Yes,
yes,
yes,
I
I
think
I
get
your
point
but
okay,
you
yfgrpf,
although
there
are
some
communication
between
the
border
routers
in
the
as
but
if
we
just
abstract
the
s
as
a
single
load.
Actually
it's
still
the
information
exchange
within
the
single
load.
So
in
so
we
still
regard
that.
Fgrpf
is
a
load
level
technology,
but
we
want
to
just
propose
a
network
level
protocol,
the
concrete
idea
of
which
will
be
presented
in
the
next
presentation,
but
generally
in
the
introductory
level.
A
The
network
level
protocol
will
be
wrong
between
the
authors
in
the
as
and
an
interdimensional.
This
protocol
will
be
one
between
different
ases,
so
these
are
just
a
network
level
of
protocols
and
we
just
see
that
the
urpf
is
just
a
load
level
technology
right,
so
they
only
achieve
based
on
local
flip
and
reap.
So
we
just
want
to
use
this
network
level
protocol
to
generate
okay,
more
accurate,
save
tables
to
overcome
in
this
problem,
and,
of
course,
for
this
deployment
slower,
we
should
consider
incremental
deployment
yeah.
J
A
K
A
A
A
D
E
I
I've
been
trying
to
think
about
the
root
cause
and
like
what
are
the
actual
fundamental
issues
here
and
I
actually
identified
four
things
root
cause
number
one
is
that
you
have
information
that
that
you
could
base
decisions
on,
but
you
don't
actually
use
it
or
don't
use
all
of
it
and
as
an
example,
you
perhaps
you
have
like
a
full
network
topology
model
in
your
memory,
based
on
what
you
learned
from
the
roping
protocols,
you
could
use
that
to
make
decisions
on
what
addresses
are:
okay
or
not?
Okay.
E
E
Let's
say
your
routing
protocol
doesn't
provide
everything
that
you
would
need,
or
for
some
other
reason
you
don't
have
information
that
would
enable
you
to
make
these
decisions
on
social
validation
and,
and
then
the
answer
obviously
is
provide
more
information
either
in
form
of
a
new
protocol
or
some
extensions
of
existing
ones.
I
think
igor
who's.
E
After
me,
on
the
queue
had
some
proposal
on
the
list
about
that
third
option
is
that
or
the
third
route
course
is
that
you
have
information
about
the
feasible
routes,
but
you
don't
have
information
about
the
actual
ones
that
are
being
used
at
this
time,
and
I
guess
here
you
have
to
decide
what
you
want
like
you
could
be
satisfied
with.
You
know
some
improper
permits
and
and
just
look
at
the
feasible
routes.
E
Then
you
have
a
simpler
solution
or
you
create
a
more
complex
solution
that
costs
more,
but
you
can
catch
more
issues
and
root.
Cause
number
four
is
kind
of
variation
of
of
third
of
the
third
one
about
this
actual
paths
versus
feasible
paths
and
there's
an
issue
that,
if,
if
there's
a
change
somewhere
else
in
the
network,
when
do
you
actually
learn
about
that
and
if
you
think
about
it
from
the
point
of
view,
the
note
that
has
has
to
change
for
some
reason
like
link
is
added
or
removed.
E
This
also
gets
me
somewhat
confused
about
the
network
level
discussion
that
we
had
because
it's
yeah
we
can
talk
about
the
network
level
solution,
but
we
still
have
like
individual
nodes
that
have
to
make
decisions
and
are
not
exactly
synchronized
to
everybody
else.
On
the
same
instant
because
of
you
know,
speed
of
light
and
such
that's
it.
Thank
you.
A
A
Generally,
I
think
for
safe
mechanisms
we
can
just
maybe
we
can
come
up
with
some
a
mechanism
which
is
very
easy
to
deploy.
The
cost
is
very
low,
but
maybe
okay,
there
will
be
some
inaccurate.
Okay,
that
inaccurate
decision,
improper
permit
or
in
public
block
or
okay.
The
other
extreme
is
that.
Okay,
we
just
to
achieve
accurate
decision.
We
will
pay
the
cost
of
the
new
protocol.
The
network,
the
network
level
protocol,
so
my
okay
design
philosophy
is
that
actually
for
ins
for
today's
internet,
actually
we.
B
A
Go
ahead,
let's
just
quickly
answer
yaris
I'll,
just
respond
to
yari's
comments.
Just
my
design
philosophy
is
that
I
want
to
that.
Okay
first,
we
should
satisfy
the
performance
requirement,
that
is,
to
okay,
improve
the
accuracy,
and
under
this
assumption
we
will
just
try
to
reduce
the
overhead
just
limit
the
overhead
as
much
as
possible.
A
So
I
personally
prefer
this
direction
of
solution
and
for
the
the
final
comment
from
you
is
that,
okay,
when
there
is
during
the
convergency
period-
okay
there
we
maybe
we
can,
we
have
to
pay
the
cost
of
okay.
The
packet
drop
just
the
improper
block,
something
like
that.
I
think
yeah,
it's
just
as
similar
as
the
resulting
protocol.
A
So
in
any
kind
of
a
routing
protocol
during
the
converging
period
there
may
be
loop
right
and
if
there
is
nope,
this
is
kind
of
a
temporary
loop
will
also
cause
packet
drop
okay.
So
so
I
I
think
that
this
this
for
source
address
validation
actually
for
this
question,
it's
very
similar
as
resulting
the
resulting
protocol.
So
we
just
want
to
okay
design,
okay,
several
ways
just
to
try
to
mitigate
this
problem
instead
of
okay
still
paying
the
cost
of
general
okay,
improper
block
or
improper
permit.
A
B
E
L
D
L
Can
hear
myself
all
right?
Can
you
okay
good?
Thank
you.
So
I
have
a
comment
and
a
good
question.
So
the
quick
comment
is
that,
in
my
view,
the
reason
we're
having
the
discussion.
The
reason
we're
having
the
problem
is
that
all
the
current
methods
are
using
what
is
effectively
reachability
information
bgp
as
a
substitute
for
allowed
forwarding
paths
for
sort
of
address
validation,
and
it's
just
not
the
most
accurate
signal
and
that's
why
we're
having
problems?
A
L
Have
is
what
do
you
think
I
mean
save,
will
add,
cost
to
the
forwarding
path.
What
do
you
think
is
a
reasonable
cost
that
the
internet,
the
the
industry,
will
be
able
to
bear
like
relative
to
the
cost
of
forwarding
packets?
It
is
like
twice
as
much
hardware
three
times
as
much
hardware
like
in
terms
of
acid
per
packet.
A
Okay,
okay,
okay,
now
I
get
your
point
yeah.
I
think.
Maybe
these
issues
will
be
described
with
more
details
in
our
next
presentation,
but
generally
icelander
for
the
cost
we
can.
We
should
still
just
divide
this
protocol
into
inter
domain
and
the
introduction
so
for
interdependent
stuff.
Maybe
we
can
just
extend
the
capabilities
of
bgp
to
help
carry
okay,
more
information
required
for
this
okay,
the
data
plane
pass
notification
or
discovering,
and
for
introducing
a
part,
because
this
scope
is
the
smaller,
I
think.
A
A
We
just
we
just
want
to
leverage
existing
consulting
protocols
such
as
bbc
or
design
new
introduction
instrument
and
network
protocols,
which
just
shares
the
same
complexity
of
routing
of
the
intradominating
protocol,
but
not
greater
than
that.
That's
my
generally
thinking
about
the
cost
that
we
should
pay
for
this
kind
of
social,
just
checking.
A
M
Yeah,
so
thank
you
ciao.
I
I
think
it's
very
important
to
operators
to
avoid
the
improper
blocker
and
the
permit.
So
I
think
this
is
this
direction
is
valid.
I
have
a
very
quick
comment.
I
don't
think
I
need
some
response,
so
you
know,
operators
network
is
very
large
and
the
number
of
the
nodes,
such
as
in
the
backbone
network,
maybe
reach
a
substance.
So
I
guess
it's
reasonable.
That
put
the
being
suitable
for
the
large-scale
network
deployments
should
be
important
requirements
when
we
design
the
network
live
protocol.
A
J
N
N
N
N
N
N
Here
we
list
some
terminologies,
the
node
is
a
router
in
intra
domain
dcf
or
an
es
inter
domain
dcf.
The
prefix
notification
means
the
process
by
which
a
node
notifies
the
incoming
direction
of
its
source
prefixes
to
all
the
other
nodes
in
the
network
and
during
prefix
notification.
Each
node
conducts
one
of
three
operations
message.
Origination
means
a
node
generates
original
notification
messages.
N
The
d
save
notification
message
contains
two
main
fields:
prefix
field
and
propagation
scope
field
for
source
prefix
field.
It
contains
the
source
prefixes
of
the
node
when
receiving
a
message.
A
node
generates
save
rules
for
the
source,
prefixes,
and
this
field
will
remain
unchanged
during
the
prefix
notification
process
for
propagation
scope
field.
N
N
N
N
N
O
N
N
N
It's
worth
noting
that
p6
may
take
different
next
hopes
because
of
multi-path
routing
so
from
nodes
to
slip.
P6
and
p7
take
node
7
as
the
next
hope,
so
node
2
conducts
message
link
and
generates
a
really
notification
message
to
node
7
carrying
py
in
the
source,
prefix
field
and
carrying
p6
and
p7
in
the
propagation
scope.
N
Next,
when
node
4
receives
the
message
from
node
2
at
port
4.1
node
4
first
generates
the
c
rule
for
source
prefix
p1.
It
then
checks
the
propagation
scope,
p4
and
p6
from
node
4
fib
p6
takes
node
6
as
the
next
hope.
So
node
4
contacts
message
relink
and
generates
a
reading
notification
message
to
node
6,
carrying
p1
in
the
source,
prefix
field
and
carrying
p6
in
the
propagation
scope
field.
N
Similarly,
when
node
7
receives
the
method
from
nu2
at
port
7.1,
it
generates
the
civil
rule
for
source
prefix
p1,
and
then
it
checks
that
p6
takes
node
6
as
the
next
hope.
So
node
7
conducts
messenger
link
and
generates
a
relaying
notification
message
to
node
6
carrying
p1
in
the
source,
prefix
field
and
carrying
p6
in
the
propagation
scope
field.
N
N
N
N
We
have
considered
two
dc
update
models
for
pure
periodic
update.
Each
node
generates
original
notification
messages
periodically
for
triggered
update
when
routing
city
changes,
the
node
generates
original
notification
messages
to
add,
updated,
silverware
or
delete
outdated
silverware
for
the
affected
nodes.
N
N
N
Besides
packets
from
es5,
with
both
the
source
addresses
of
p1
p2
p3
p4
will
be
blocked
at
port.
A
while
loose
urpf
may
have
improper
permit
problem
in
this
case
overall,
compared
with
urpf
in
in
predominantly
interdependencies
as
within
the
deployed
area
cannot
spoof
each
other
and
ess
in
the
undeplored
area
cannot
cannot
spoof
the
source
addresses
of
the
deployed
area.
N
N
N
G
G
G
Okay,
okay,
all
right!
Well,
so,
whatever
so,
okay,
it
seemed
to
me:
okay,
one!
Don't
get
me
wrong.
This
is
very
good
idea,
I
think
and
necessary,
and-
and
I
think
we
happy
to
work
with
you,
but
I
think
there's
a
couple
of
fundamental
flaws
and
I'll
bring
them
up
one
at
a
time.
Let
other
people
talk
first
fundamental
flaw.
I
believe
it
depends
on
hop
by
hop
header
and
being
accurate
and
not
spoof
and
and
that-
and
so
if
the
hop
by
hop
extension
header
is
bad
to
start
with.
G
P
P
Did
you
explore
the
possibility
to
have
a
propagation
field
that
is
built
by
each
op?
For
instance,
you
have
a
message
where
you
have
the
source
field
that
you
that
you
certify
and
then
the
next
node
is
using
the
message
from
the
that
is
going
from
the
from
the
originating
node
populate
this
propagation
field
and
relay
it
to
its
neighbors.
So
you
build
the
propagation
scope
field
up
by
up
and
you
can
then
verify
the
path
completely
rather
than
just
the
source.
P
P
The
propagation
scope
field
yeah:
do
you
think
that
it
could
be
an
idea
rather
than
building
the
propagation
field,
from
the
information
that
are
in
the
field
to
build
it
up
by
up
with
your
originator
message
with
only
the
source
prefix
field?
And
then
the
neighbor
puts
the
prefix
in
the
source.
Prefix
field
message
they
received
in
the
propagation
scope
field
before
relaying
the
message
to
their
own
neighbor,
and
it
goes
on
until
you
propagate
the
message
in
all
the
network.
A
A
So
another
possible
way
is
that
we
just
carry
okay,
just
some
destination
addresses
in
the
in
the
package
in
the
pay
node
and
just
the
probe
those
paths
it
will
bring
much
more
a
protocol
ever
overhead,
so
yeah.
Actually,
we
use
the
fib
for
the
notification
because
we
want
to
discover
the
real
data
forwarding
paths,
because
the
real
data
platform
pass
is
determined
by
the
vape
table.
N
R
N
Sure
we
have,
we
do
have
some
solutions
for
ecl.
Yes,
you
are
right:
ecru
direction
may
check
source
address
destination,
address
or
port
number,
yes,
and
we
we
think
dc,
can
use
the
control,
plane,
routing
information
to
generate
notification,
messages
along
policy-based
forwarding
paths,
including
easier
redirection
path
or
other,
for
example,
a
tunnel
path.
D
S
A
N
N
N
D
C
N
From
node
one
fifth,
it
finds
node
two
and
number
three
are
two
next
hopes
in
its
theme,
therefore,
it
takes
node
two
as
a
nest,
hope
and
sends,
and
it
generates
an
original
notification
message
to
number
two.
The
message
generated
from
node
1
to
node
2
carries
p1
in
the
source
prefix
field
and
carrying
p2
p4,
p6
and
p7
in
the
propagation
scope.
N
N
N
D
D
D
S
S
S
Such
a
weakness
allows
malicious
actors
to
spoof
ip
packets
and
launch
a
wide
variety
of
attacks,
for
example,
the
lgcp
spoofing,
dns
reflection,
deducts
and
the
tcp
syn
flooding
to
name
gaza
field.
However,
at
the
main
defense
mechanism,
the
real
world
deployment
of
source
address
variation
in
the
past
decades
is
far
from
being
said,
satisfactory.
S
S
Let's
start
with
the
general
overview
of
how
easter
works,
the
source
s
and
the
the
destination
as
directly
from
an
end
to
end
package
tag
synchronization,
after
which
the
package
from
the
source
will
carry
the
legal
package
tag
and
be
received
by
the
destination
support.
Packets,
don't
have
the
tag
and
are
marked
as
suspicious
by
the
destination
and
other
process.
The
further
or
dropped
directly.
S
To
implement
this
design
itself
will
require
both
a
data
plane
under
control
plane
within
a
s.
The
control
plane
will
be
implement
through
a
device
called
the
ais,
control,
server
or
acs,
and
the
data
plane
will
be
implemented
through
an
ais
border,
rotor
or
abr,
where
the
api
is
responsible
for
adding
checking,
replacing
and
deleting
tags
for
all
upstream
and
downstream
traffic.
S
And
the
acs
is
responsible
for
providing
the
api
with
the
information
needed
for
the
relevant
tag
operations
such
as
the
legal
prefix
to
tag
mapping
the
controllers
of
different
as
need
to
work
together
to
maintain
a
tesla
lens
and
achieve
consistence
on
the
information
required
for
tech
operations
within
the
lungs.
This
requires
the
support
of
existing
network.
S
In
fact,
infrastructure
such
as
the
mapping
between
as
number
and
ip
prefix
provided
by
rpki
with
the
package
tag
mentioned
above
itself,
can
guarantee
a
career
security
gain
within
the
deployment
and
guarantees
the
authenticity
of
the
source
address
of
the
traffic
that
has
passed
the
tag
check.
It's
the
instead
of
only
checks
is
owen
traffic.
S
So
the
overhead
of
establishing
a
universe,
entertainment,
trust
and
hardware
fiction
mechanism
at
the
internet
scale
is
hardly
acceptable
with
the
simple
end-to-end
tag.
Maintenance
is
not
friendly
to
change
in
the
network
environment
in
each
of
a
hierarchical
structure
called
as
community
is
designed
to
address
the
scalability
changes
faced
by
end-to-end
tag
schemes
when
deployed
at
a
scale
in
each
of
is
confirm
a
community
structure
with
a
hierarchy
that
splits
the
progress
and
to
enter
maintenance
between
s
into
a
the
cross
layer,
tag,
verification
and
the
replacement.
S
The
end
to
end
derived
task
is
replaced
with
a
cross
layer
chain
of
cluster
delivery
in
es
community
end
to
end
tag
is
only
maintained
between,
as
with
the
same
community,
quite
fake,
entering
or
leaving
the
ais
community
is
operated
by
the
border
airs
for
tag
replacement
through
hierarchical
design.
We
can
achieve
the
following
three
benefits:
the
first
one
you
can
reduce
the
size
of
the
tags
maintained
between
s.
S
S
To
simplify
the
tag
replacement
rules
in
data
forwarding
itself
propose
a
logical
concept
called
water
s
to
maintain,
inter
community
tax
will
entering
under
leaving
our
community
awarding
problems
such
as
tag
replacement
difficulties
due
to
multiplace
transmission
between
s
or
traversing.
None
itself
deployment
area
such
as
s,
one
two,
for
example,
as
the
one
one
send
package
to
s,
2
3
and
after
passing,
through
s
1
2,
where
e
7
is
not
deployed.
S
S
Here
there
are
nine
boundary
loaders
lot
of
one
to
load
line
each
ribs,
each
representing
one
different
airs
forming
the
as
community,
as
shown
in
the
figure
lutheran
sent
out
a
package
to
note
9.
in
the
first
step.
Lutheran
learns
that
the
destination
is
not
inside
this
community
by
the
destination
address
of
the
package,
but
it
is
inside
the
cluster
length
and
it
puts
the
tag
between
itself
and
the
water
s
of
this
community.
S
S
So
after
verifying
the
validity
of
the
current
tag,
the
tag
is
replaced
with
the
tag
between
community
one
three
and
community,
one
two
that
is
voter
s,
one
three
and
a
two
vertical
as
one
two
similar
to
the
above
process
after
the
package
across
community.
One
three
and
reached
that
the
board
aso
community,
one
two
that
is
loader
three.
Those
three
will
perform
the
same
check
and
replace
the
tag
with
the
tag
between
the
community
one
two
and
under
community
one
one
and
the
form
the
tag
water
as
one
two
water
s,
one
one.
S
The
next
one
is
rotor
7.
Finally,
it
arrives
at
s.
Community
2,
3
root,
8,
performs
tag
check,
after
which
the
tag
is
replaced
by
the
tag
between
root,
8
and
root.
9
through
the
destination
address
and
the
root
name
receives
it,
and
it
will
verify
the
tag
validity
and
remove
the
tag
and
send
it
to
the
in
the
host.
S
S
G
Yes
hi:
this
is
delaney
atkinson
inside
product.
So
again
I'll
keep
keep
it
to
one
question
which
is
so
so,
okay
so
say:
I'm
mr
bad
as
number
one
and
my
community
is
my
friends
bad
as
number
two
bad
ass
number.
Three,
and
we
all
say:
yeah
yeah,
good
tag,
good
tag,
and
so
what
is
the
I'm?
Not
understanding?
Quite
the
validation
mechanism
are.
These?
Are
you
intending
for
this
stuff
to
be
encrypted?
G
A
G
T
Oh,
can
you
hear
me
by
the
way
nice?
Thank
you
for
the
question.
So,
first
of
all,
this
is
haiyan,
I'm
one
of
the
collaborators
of
this
research.
So
what
are
you
asking
is
if
there
are
bad
iss
out
there,
how
we
actually
validate
those
tax
out
there?
Is
that
what
you're
asking
yeah?
That's
that's
actually
a
very
good
question:
yeah,
that's
actually
a
very
good
question.
T
So
talking
about
the
esav,
I
want
you
guys
to
think
about
the
autonomous
systems
or,
let's
say
a
set
of
toronto
assistance
as
a
at
the
daycare.
Okay,
thinking
about
those
ib,
prefixes
and
ip
addresses
they
like
kids
out
there,
okay,
those
kids,
they
don't
have
driver's
license,
they
don't
have
ids.
So
our
responsibility
is
to
design
a
protocol
that
is
running
in
in
the
daycares
to
validate
the
identity
of
those
kids,
okay.
T
So,
basically,
what
we
do
is
that,
first
of
all,
we
don't
search
actually
the
actual
routing
table
up
there.
We
actually
only
need
to
check
the
destination
ip
prefix
and
to
check
if
this
destination
is
within
the
daycare
or
outside
of
daycare.
If
it's
within
the
daycare,
we
send
it
to
the
our
inter
domain
protocol
if
it's
outside,
then
we
give
this
kid
a
sticker.
We
put
that
sticker
on
his
head
and
then
we
send
this
kid
out.
T
What
you're
asking
is
that
what
will
happen
if
we
have
some
evil
daycares
that
does
not
care
about
those
kids.
The
sin
is
that
we
are
basically
going
to
consider
those
autonomous
systems
as
autonomous
system.
That
does
not
support
yes,
av.
Okay.
So,
first
of
all,
this
is
not
going
to
hurt
the
sender
of
the
packet
or
the
receiver
of
the
packet.
It
is
only
going
to
hurt
those
evo
autonomous
systems
who
refuse
to
check
the
tech.
T
If
that
makes
sense
to
you,
it
seems
that
our
deployment,
we
don't
require
all
the
daycares
to
check
those
stickers.
Okay.
So,
for
example,
a
kit
is
generated
from
a
daycare
with
a
sticker
on
there
and
we
are
going
to
eventually
have
some
not
evil
daycares
that
is
going
to
check
the
validation
of
that
sticker.
T
I
don't
know
if
that
makes
sense
to
you.
For
example,
if
we
have
three
autonomous
systems,
one
two
three
connected
out
there
and
the
atomic
system
two
in
the
middle
is
evil
or
does
not
have
e-s-cb
deployed
out
there.
It
doesn't
matter
because
one
three
can
still
validate
each
other
and
if
you
don't
feel
good
or
if
you
don't
feel
happy
to
join
this
esab
system,
you
can
ignore
it.
I
don't
think
it's
going
to
hurt
our
protocol,
but
still
that's
a
very
good
question.
U
T
Okay,
so
you're
thinking
about
efficiency
of
the
attack,
validation
and
tech
generation.
Is
that
what
you're
asking
yeah
sure
that's
a
very
good
question?
Actually
we
already
test
that
on
the
commercial
we
actually
implemented
the
protocol
and
the
we
actually
test
that
on
real-world
routers
in
a
we
actually
deployed
that
in
a
virtual
router,
you
know
environment
that
is
relatively
a
large
scale
virtual
network.
I
would
say
the
efficiency
talking
about
throughput.
V
T
Yeah,
it's
actually
built
in
in
ipv
version.
Six
option
have
a
header
out
there,
the
the
actual
size.
The
thing
is
that
we're
not
going
to
actually
add
extra
header
or
extra
information
on
top
of
the
a
version,
six
header-
if
that
makes
sense
to
you,
so
our
tag
is
actually
a
part
of
the
ip
version.
Six
header.
T
V
T
V
T
V
T
Good
question,
actually
the
scene
is
that
the
existing
limitation
on
ipv6
is
based
on
the
extension
and
we're
also
thinking
about
the
adding
that
for
ib
version
4.
That
is
probably
also
going
to
be
added
to
the
extension
head.
That's
a
very
good
question.
Yes
thanks!
So
overhead
is
around
like
64
bits
thanks
so.
V
My
my
feeling
about
this
is
that
I
would
really
I'm
really
interested
to
see
something
very
much
along
these
lines
in
terms
of
end-to-end
cryptographic,
authentication
of
every
packet.
I
think
that's
fascinating
and
worth
in
investigating
and
investing
in.
I
I
don't
really.
I
don't.
I
have
disagreements
with
all
like
every
detail
in
this
proposal.
V
In
particular,
I
really
think
that
we
should
consider
static
setup
instead
of
instead
of
trying
to
do
dynamic
arrangements
between
the
asses,
which
creates
kind
of
an
n
squared
problem
where
all
the
asses
have
to
talk
to
each
other.
I
think
we
should
consider
a
static
cryptographic,
handshake
setup.
V
I
think
that
would
allow
us
to
get
rid
of
the
hierarchy
of
communities
which,
which
is
conceptually
confusing,
increases
management,
and
I
think
that
I
think
a
big
lesson
from
from
the
tls
is
that
authentication
is,
is
not
really
authentication
without
encryption
is
only
half
of
the
half
of
the
story.
If
you're
going
to
do
all
the
work
to
set
up
a
shared
secret
between
two
parties,
then
you
might
as
well
encrypt
the
payload
while
you're
at
it.
V
T
D
Are
these
protocols
worthy
worthy
is
not
the
right
word?
Is
there
sufficient
interest
to
form
a
working
group
to
progress?
The
development
of
these
protocols
are
the
protocol
concepts
feasible
in
deployments
on
the
internet,
but
I
I
think
we
are
pressed
for
time
to
to
address
those
in
a
thorough
manner.
K
Another
five
minutes
jared
you
go
first,
yeah
yeah,
real,
quick
jared
macha
is
an
individual,
so
I
think
that
there's
the
opportunity
for
there
to
be
some
interesting
work
in
this
space
describing
this,
but
I
think
it
also
is
going
to
pose
some
real
challenges
when
it
comes
to
actually
deploying
it,
which
is
basically
see
everyone.
Who's
tried
to
either
do
bgp
route,
filtering
or
bgp
path
scale,
because
a
lot
of
these
properties
of
this
are
going
to
scale.
K
W
W
U
U
O
O
O
Q
D
We're
now
five
minutes
over,
I
would
like
to
thank
all
participants
both
locally
and
remotely.
It
is
deeply
appreciated
that
many
people
either
went
to
bed
very
late
or
got
up
super
early
to
be
here.
Virtually
the
next
place,
where
we
can
continue
discussion
is
the
safnet
at
itf.org
mailing
list,
and
this
is
where
we
can
figure
out
whether
to
do
another
buff
to
initiate
a
working
group
or
to
do
something
else.
The
mailing
list
is
the
next
platform
for
discussion.