►
From YouTube: IETF99-OPSEC-20170719-1330
Description
OPSEC meeting session at IETF99
2017/07/19 1330
https://datatracker.ietf.org/meeting/99/proceedings/
B
Hello
welcome.
You
have
ended
up
in
OPSEC
in
a
not
so
small
room,
but
we
don't
have
such
a
big
audience.
So
it's
a
perfect
fit
so
first
some
administrivia
here
so
before
we
can
start.
You
know
it
would
be
nice
to
actually
have
a
job
or
describe
anybody
willing
to
look
into
the
jumper
things
and
actually
relate
questions.
If
there
would
be
any
I
know.
D
B
E
A
F
G
B
So
the
next
thing
is,
as
you
have
seen,
probably
just
like
a
new
note
well
out
here.
If
you
haven't
seen
this
thing,
you
probably
haven't
been
going
to
the
session
and
just
being
enjoying
the
social,
which
is
maybe
not
the
intention
so
taking
into
account
be
aware
of
any
IP
on.
If
you
have
any
IP
on
and
things
you
know,
and
you
don't
want
to
disclose,
don't
participate.
B
So
in
that
case
you
probably
wouldn't
have
seen
this
note
on
anyway,
so
the
book
sheets
are
going
around
filled
in
so
that
next
time
we
get
like.
You
know
the
appropriate
size
room
and
we
know
who
actually
has
been
here.
So
that's
really
good
and
in
addition,
if
you
don't
feel,
then
we
actually
get
like
grumpy
face
from
our
area
director,
and
we
want
to
avoid
that.
We
want
him
to
be
a
happy
face.
B
Yep
I
can
do
that
sorry,
so
yeah
Jenna
today
we
have
covered
up
in
two
different
sections,
so
we
first
are
going
to
be
discussing
some
of
the
working
group
documents
which
had
some
activities
upon
them
and
see
how
we
can
progress
them.
You
know
towards
further
completion
now
in
compliment
to
that.
We
also
started
like
a
couple
of
my
eight
years
ago
to
discuss
operation
security.
B
You
know
aspects
which
do
not
really
have
working
group
documents
at
all,
but
you
know
are,
in
the
general
interest
from
you
know,
from
a
security
perspective
for
like
a
wider
audience,
so
we're
trying
to
group
those
things
here
in
this
particular
working
group
here.
So
we
have
found
four
different
topics
here,
which
had
some
activity
during
you
know
before
the
last
ID
event
is
IDF
here.
B
B
Okay,
then,
a
very
quick
workgroup
status
here,
so
we
actually
haven't
published
any
other
stations.
The
last
IETF
meeting
we
actually
have
back
to
active
working
group
documents
which
we're
going
to
be
discussing
here
and
we
actually
have
like
two
individual
documents
which
had
like
some
further
activity
here.
For
the
rest,
you
know
little
activity
on
the
email
list,
as
you
have
seen
also-
and
that
is
that
the
current
working
group
stages
at
this
point
in
time
now
before
we
actually
get.
You
know
started
with
a
number
with
this
with
this
draft
here.
B
So
one
observation
I
had
is
that
I
went
and
actually
had
to
look
into
the
working
group
alias
and
also
into
the
document
itself,
and
while
the
document
you
know
it
is
looking,
you
know
reasonably
good
in
my
eyes,
I
have
noticed
that
it
is
like
not
a
lot
of
discussion
on
the
working
group
list
on
this
document
and
also
did
like
a
search
I
found.
Like
five
emails.
You
know
on
the
list
on
this
particular.
You
know
this
particular
draft.
B
Four
of
them
were,
like
you
know,
I've
updated
the
draft
and
it's
like
a
new
version.
So
only
one
active,
you
know
feedback
comment
or
something
like
that.
Now
that
is
surprising
to
me.
So
it
makes
me
wonder
you
know.
Is
this
document
doing
the
right
thing?
Is
it
actually
tickling
the
interest
of
the
working
group?
No,
unlike
I
said
you
know,
and
when
you
look
through
the
document
itself,
it
is
actually
you
know
quite
well
written,
and
it
seems
you
know
in
my
eyes
is
touching
upon
the
right.
H
You
should
I
will
do
a
we'll
be
doing
a
quick
overview
of
these
document.
Recommendations
on
the
filtering
of
ipv6
packets,
containing
extension
headers,
essentially
as
a
summary
about
the
document
of
what
this
document
it's
about
is
essentially
an
ipv6
version
of
71
26.
We
was
talking
about
ipv6
before
options
and
essentially
for
each
extension,
header
and
each
ipv6
option.
It
tries
to
summarize
the
security
and
the
operational
implications
like
security.
What
can
you
know
what
can
go
wrong
if
you
actually
allow
packets
with
those
extension,
headers
or
options
and
operational
implications?
H
Is
what
happens
if
you
happen
to
drop
those
packets?
Okay?
The
idea
is
that
the
this
document
provides
operational
advice
on
how
to
filter
packets
containing
these
extension
headers
at
transit
routers.
At
some
point
in
time,
the
discussion
was
about.
You
know
how
to
filter
these
packets.
You
know
everywhere,
but
there
was
quite
a
lot
of
discussion
about
that,
and
essentially
the
agreement
that
we
got
to
in
the
working
group
was
to
make
this
document
focus
on.
You
know:
transit
routers.
H
The
idea
is
that
there,
the
approach
would
be
more
of
a
blacklist
approach
as
opposed
to
what
you
do,
probably
at
the
edges,
where
it
would
be
more
of
a
whitelist
of
em.
Why
this
approach?
Okay,
the
hopes
you'd
say,
depending
on
your
point
of
view,
is
that
these
might
help
improve
the
situation
in
those
cases
in
which
you
have
transit
systems
that
are
dropping
packets,
containing
extension,
headers
or
at
least
wise
awareness.
H
What
are
the
changes
that
we
apply
to
version
number
three,
essentially
just
edit
your
comments,
and
there
were
a
few
sections
that
you
know
had
missing
contents.
So
we
have
sections
for
some
specific
options.
Some
of
them
might
have
been
like
experimental,
or
you
know
for
particles
that
at
least
we
were
not
that,
let's
say
familiar
with,
so
it
was
a
matter
of
you
know,
digging
into
the
you
know
corresponding
specifications,
and
you
know
try
to
figure
out.
H
You
know
what
the
security
implications
were,
and
you
know
what
might
break
if
you
were
actually
to
drop
the
packets
containing
these
extension
headers
for
options
that
it's
essentially
so
a
discussion
that
we
have
among
us
co-authors
was
that
you
might
have
seen
that
recently
the
revision
of
2460
was
published.
Okay,
so
the
end
there
was
the
question,
I
mean,
and
there
were
some
things,
particularly
when
it
comes
to,
for
example,
hope,
I
hope,
options.
Extension
header
they
were,
there
were
some,
let's
say,
modifications
or
some
changes
in
24
16
that
respect.
H
H
We
should
probably
do
both
because
well
most
of
the
you
know,
you
will
have
lots
of
what
you
might
call
legacy
implementations,
which
are
most
implementations
that
are
still
behaving
us
in
twenty
four
sixty
or
you
know
in
theory,
according
to
20
40
60-
and
you
know
you
know,
in
the
near
or
long
term,
you
might
have
I.
You
know,
implementations
behaving
according
to
what
in
8200
I
don't
know
if
there's
any
input
or
you
have
any
thoughts
about
that
I
mean
by
default.
If
you
don't
complain,
we
would
be
doing
both
right.
B
I
H
So
the
idea,
as
far
as
I
remember,
was
that
in
theory
I
mean
that
means
according
to
what
2460
says,
if
you
receive
a
packet
that
has
hope,
I
hope
options,
extension
header,
it
has
to
be,
like
you
know,
sent
to
the
slow
processing
part
of
the
router
to
actually
check.
What's
inside,
that,
you
know
hope,
I
hope,
I
hope,
I
hope,
options.
Extension
header,
obviously
that's
bad
for
a
lot
of
reasons,
performance
and
obviously,
as
a
result
of
that
you
can
get
denial
of
service
attacks
and
as
far
as
I
remember
were
you
know.
H
Six
when
I
agreed
to
was
that
that
behavior
would
only
happen
if
you
actually
have
a
reason
or
if
you're
expecting
something
to
be
in
you
know
the
hope
is
extension,
header,
I,
guess
if
you,
if
you
have
repaired,
apply
RSVP
or
something
like
that.
That's
the
only
case
in
which
you
look
at
the
packet,
but
by
default
you
don't
look
at
hope
by
hub
options,
run.
H
The
thing
here
is
that
so
you
have
what
2460
says
what
8200
says
and
what
implementations
were
actually
doing
in
some
case,
which
was
like
ignoring
that
anyway.
So
in
the
current
version
of
the
IDE,
we
already
discuss
what
implementations
do
and
go.
2460
says
and
I
guess
that
a
t20
serious,
essentially
reflecting
what
was
already
happening
in
practice.
In
many
cases.
E
J
H
Did
I
think
hunter
did
at
some
point
and
there
was
I
mean
let's
put
things
this
way,
so
there
was
some
folk
complaining
that
we
were
essentially
encouraging
people
to
drop
anything
that
had
extension
headers.
That's
not
what
this
document
does
actually
is
to
put
it
in
in
some
way,
it's
more
way
more
permissive
than
what
I
personally
do
so
to
speak.
B
B
B
Here
is
that
the
working
group
last
call
actually
all
triggers
people
to
actually
go
and
read
it
mm-hmm,
because
otherwise
you
know
nothing
will
happen
on
this.
No,
like
I,
said
the
text,
and
this
document
is
already.
You
know
that
quite
well
written
so
I
think
it
is
it's
ready
for
the
working
group
Moscow.
So
I
will
do
this
after.
E
You
have
no
slides,
I
have.
L
Five
years
later
right,
it's
turning
into
one
of
these
projects,
where
we
know
that
we'll
never
absolutely
be
done,
because
there's
always
going
to
be
continuing
work
like
what
Fernanda
was
just
presenting,
and
we
want
to
add
all
that.
We
had
a
last
call
this
past
May
and
there
are
a
lot
of
really
great
recommendations.
I
also
what
the
authors
we
know,
a
bunch
of
v6
operators
who
don't
necessarily
IETF,
and
we
requested
four
five
or
six
of
them
to
do
a
thorough,
read
which
they
did,
and
they
also
commented
some
very
good
comments.
L
So
in
the
last
two
months
I
mean
you
know,
it'll
be
at
least
you
know,
12
to
18
hours
worth
of
work
literally
to
really
incorporate
all
of
them.
Look
at
them,
parse
them.
So
as
authors
we've
decided
that
you
know
we
really
want
to
do
the
diligent
job
to
make
sure
that
the
current
state,
as
its
represented
now
and
from
all
the
comments
that
we
got
there
were
actually
seriously
going
to
look
at.
What
shall
we
embed
and
then
also
bring
to
the
working
group?
L
Anything
that's
controversial,
so
we
can
make
a
decision
and
then
hopefully,
by
the
next
IETF.
We
can
have
a
last
call
where
we
can
declare
the
document
done
in
its
current
state.
There
was
one
conversation
about
you,
LA's
and
you
know
not
six
six
and
a
recommendation
that
there'd
be
very
strong
language
in
terms
of
do
not
recommend,
and
while
the
answer
that
I
got
when
I
asked
because
last
year,
I
had
a
hiatus
for
a
year
for
personal
reasons,
but
I
said
yeah.
There
was
a
lot
of
discussion
and
there
was
text.
L
Then,
when
I
said
can
I
have
a
pointer,
there
was
silence,
so
I
actually
read
through
all
of
the
comments
there
were
from
last
June
and
July
I
found
the
text
that
was
embedded
in
two
different
comments.
So
now
I
have
that
reference
and
we're
going
to
be
discussing
how
we'll
incorporate
that
and
so
I.
You
know
that's
basically
the
status
and
then
hopefully,
we'll
have
a
next
Rev
out
in
the
next
couple
of
weeks,
just
so
that
we
can
get
to
finalizing
it.
So
any
questions
how
many
of
you
have
read
it.
G
A
L
Just
remember
that
there
were
some
competing
comments
from
different
people
as
to
what
the
text
should
say
and
so
I
didn't.
Those
are
the
things
I
didn't
have
time
to
put
on
the
slides,
because,
quite
frankly,
we
had
really
good
comments
from
about
ten
people,
and
there
were
six
of
them
that
they
sent
it
to
my
personal
email
because
they
don't
contribute
to
the
IETF.
And
so,
but
you
know
they're
operators
and
we
did
want
their
input,
because
this
is
for
operators
and
considerations
and
operational
environments,
but
but
I'm.
L
M
Nataly
gentleman
right
Vince,
you
see
I
would
like
to
first
thank
the
authors
for
this
document.
We,
as
writing
C,
are
currently
almost
finishing
up
our
the
build
of
a
new
IP
six
security
training
course.
This
document
has
that's
greatly
in
making
things
understandable
for
operators
and
on
how
to
move
on
with
IP
security.
So
thank
you
great
nice
to
hear.
C
F
It
seems
like
I'm
a
bit
smaller,
but
now
it's
fitting.
Thank
you
for
welcoming
quite
warm.
So
the
intention
of
the
document
that
I'm
presenting
it's
a
paper
that
was
published
at
the
scientific
workshop
was
more
or
less
similar
to
the
document
that
was
presented
before
when
I
started
to
work
and
I
was
told
to
collect
all
things
that
are
related
to
ipv6
security
and
attacks
and
countermeasures
and
back
then,
when
I
started
it
I
just
looked
it
up.
F
It
was
at
the
same
time
when
you
started
with
this
draft,
so
say
my
dear
at
multiple
places,
I
started
to
collect
it
and
at
the
first
it
was
where
a
lot
of
personal
paintings
by
hand
and
afterwards
I
started
the
systematization
of
them
and
at
the
time
or
the
time
it
takes
to
go
through
a
lot
of
attacks.
I
will
give
you
an
it
an
idea
of
what
I
did
and
why
it
could
be
beneficial
for
you
and
beneficial.
Also
beyond
document.
F
We
discussed
just
a
few
minutes
before
so
what
I
did
after
collecting
all
the
thing
I
was
classifying
according
to
some
general
language
that
describes
attacks
by
the
here
mentioned
that
classification
attributes.
The
intention
is
that
you
get
an
overview
of
what,
in
a
specific,
attacked
us
on
a
quite
high
level.
What
is
done
and
what
are
the
results?
F
What
may
also
be
for
interest
for
for
you
here,
it's
distinguished
between
security
and
privacy
issue
that
arise
from
configuration,
so
that
is
more
touts
the
operators
from
design
that
is
more
for
standardization
and
implementation,
so
for
the
people
writing
code.
So
just
an
you
see
or
get
an
idea
of
what
I
did.
So
these
are
the
reaction
that
can
be
done
in
an
attack.
I
don't
want
to
go
in
it
in
detail
right
now,
but
the
results
that
I
got
are
a
whole
bunch
of
tables
and
they
are
on
purpose
now,
quite
small.
F
So
don't
try
to
read
the
head
where
these
attacks
got
a
number
and
the
name
and
and
classified
according
to
this,
and
there
are
even
more
attacks,
and
there
is
a
four
table
where
the
countermeasures
that
help
to
a
certain
extent
got
a
tick
with
the
respective
attack.
What
also
sometimes
happens
that
countermeasure
occurs
again
at
the
attacks
of
the
left
side,
because
sometimes
countermeasures
introduce
a
new
attack
vector
like,
for
example,
the
privacy
extensions,
saves
your
privacy,
you
know
one
hand
but
Union.
F
On
the
other
hand,
it
can
be
used
as
a
cover
channel,
for
example,
whether
this
is
harmful
or
not
depends
on
the
use
case,
but
there's
potential
to
use
it
that
way.
So
what
were
the
benefits
for
you?
One
thing
is,
it
can
be
a
good
introduction
to
a
PC
security.
You
might
be
the
expert,
but
there
are
maybe
some
non
experts
outside
this
room
and
I.
F
Think
these
tales
are
still
are
a
good
overview
to
get
an
idea
what's
going
on
and
it's
11
pages
of
reading,
including
references,
so
you
can
do
it
in
one,
maybe
two
hours.
The
second
thing
is
it's
a
good
overview
in
the
common
ground
for
discussion,
because
sometimes
I
read
something
and
I
don't
and
there
are
multiple
attacks
in
this
area
and
you
don't
know,
really
knew
what
the
other
one
refers
to.
F
So
it
might
also
be
helpful
for
that
and
a
checklist
for
whatever
you
need,
for
example,
penetration
tests
or
whenever
you
implement
it
and
use
new
stack
or
whatever.
You
can
add.
This
check
against
the
list.
Whether
you
consider
this
or
not,
the
document
is,
as
I
taught
before,
also
add
a
little
bit
older
and
back
then
I
saw
three
challenges
which
was
securing
the
local
network,
which
is
more
or
less
than
protocol,
which
is
specified
but
not
used.
F
According
to
the
data
protection
rules,
so
you're
not
allowed
to
collect
the
more
than
necessary
stored
in
more
than
necessarily
and
so
on.
The
only
way
to
kind
of
get
beyond
this
is
some
some
level
of
salinization
and,
for
example,
you
might
consider
privacy
that
addresses
such
a
kind
of
sad
immunization.
F
G
N
N
N
Lose
you
RPF
is
is
is
good
to
use
when,
when
isp
is
filtering
on
the
on
all
the
like,
the
entire
PGP
table
that
it
is
receiving
from
an
upstream,
primarily
what
is
being
filtered
on
is
people
grants
and
such
so
it
is.
It
is
useful
to
filter
those
out,
but
otherwise
it's
not
very
effective
for
ipv4
at
spoofing.
N
So
that's
why
BCP
84,
which
talked
about
you
RPF,
all
these
different
flavors
of
you
RPF.
It
puts
some
emphasis
on
feasible
paths.
You
RPF,
which
is
a
refinement
over
the
strict
or
the
lose,
and
so
basically
ISPs
are
apprehensive
that
they
may
be
denying
legitimate
traffic
from
their
customers.
So
if
they,
if
they
did
strict
that,
that
could
certainly
happen.
N
If
you
are
multihomed,
however,
you
should
announce
all
your
prefixes
to
each
of
your
transit
providers
by
doing
that,
although
the
ISPs
a
s,
may
not
choose
your
all
your
prefixes
as
best
path,
all
the
prefixes
that
you
announced
as
as
their
best
path.
At
least
they
have
heard
from
you
that
these
are
the
prefixes
that
you
have
and
you
have
sent
updates
to
them.
N
They
will
incorporate
that
in
the
RPF,
the
reverse
path
filtering
table
and
there
is,
as
a
result,
they
will
be
more
flexible
in
terms
of
the
source
address,
validation
that
they
do.
So
that's
the
idea
of
feasible
path
is
now,
even
though
a
feasible
path
supposed
to
work.
That
way,
the
many
times
the
customer
races
don't
announce
all
their
prefixes
they'll
make
some
of
the
prefixes
for
traffic
engineering,
but
personally
they
are
announcing
different
prefixes
to
different
ISPs.
N
So
there
are
scenarios
we
look
at
where
feasible
path
fails
doesn't
perform,
as
you
would
expect
it
because
of
the
behavior
in
terms
of
the
announcement
of
the
prefixes
in
BGP.
So
we
will
look
at
some
examples
and
we
are
looking
in
this
work.
We
are
looking
to
propose
an
improvement
on
feasible
path.
You
RPF
and
we
are
calling
that
for
now,
enhanced,
feasible
path
and
the
purpose
of
all
this
or
the
goal
is
to
encourage
a
wider
deployment
of
you
appear
for
DCP
84.
N
The
key
principles
of
this
algorithm
can
be
summarized
in
these
steps.
First
of
all,
the
ISP
router
it's
receiving
BGP
updates
from
the
customers
from
peers
from
poor
providers,
so
it
can
look
at
the
collection
of
all
the
BGP
updates
it
has
received,
and
it
creates
a
union
of
announced
prefixes
that
have
a
common
origin,
a
s.
So
that
is
the
key
here,
so
create
a
union
of
prefixes
that
all
have
a
common
origin.
N
A
s
so
once
you
have
done
that
and
as
I
said,
those
announcements
could
have
come
from
a
customer
here
or
a
provider.
So
once
you
have
done
that
you
take
that
Union
of
prefixes
and
look
at
the
interface,
for
example,
towards
a
customer,
and
the
customer
has
announced
at
least
one
of
those
prefixes.
Now
you
give
the
benefit
of
the
doubt
to
the
customer
to
that
interface
that,
since
this
prefix
with
that
originates,
came
in
a
BGP
announcement
towards
me,
I'm
going
to
allow
in
the
source
addresses
this
prefix.
N
So
any
address
in
this
prefix
is
good
I'm
going
to
accept,
and
then
you
give
the
benefit
of
doubt
by
saying
that
I
notice
that
these
other
prefixes
that
I
heard
may
be
from
other
interfaces.
They
share
the
same
origin,
a
s
as
this
prefix,
so
they
are
all
originating
the
same
areas.
So
potentially
they
all
have
a
BGP
update
path
towards
me
if
they
are
going
to
send
eventually
later,
if
they
are
going
to
send
data
with
source
addresses
in
those
other
prefixes,
potentially
they
could
have
also
announced
BGP
their
BGP
announcement.
N
So
that's
the
key
idea,
and
by
doing
this,
the
they
can
choose
to
apply
this
not
across
peer
and
provider
and
so
on.
They
can
choose
to
limit
this
algorithm
to
customer
interfaces,
so
some
scenarios
through
which
we
can
walk
through
how
these
functions
or
how
some
of
the
RPF
techniques
fail
and
how
some
of
them
do
better.
The
first
scenario
is
pretty
straightforward:
a
s1
has
to
be
freak
prefixes,
it
originates.
It
sends
P
1
to
s,
to
announce
s,
only
P
1
to
s
2
and
only
P
2
to
s
3
and
s.
N
N
S2
has
not
heard
P
2
from
s
1
so
as
to
stick
to
RPF,
we'll
say
no,
this
not
allowed
and
the
packet
will
be
dropped,
so
strictly
RPF
would
fail
feasible
pathway,
RPF
would
also
fail.
Since
P
2
was
not
announced
to
a
s.
2
P
1
was
not
announced
to
a
s
3.
Basically
it
s
went
in.
Follow
the
recommendation
operational
recommendation
in
PC
P
84.
N
It
is
supposed
to
announce
all
its
prefixes
with
prepending,
if,
if
preferable
and
so
on,
for
trafficking
at
uni
but
I,
didn't
it
only
announced
prefixes
selectively,
so
feasible
path,
you
got
EPF
also
fails
lose,
would
work,
but
that's
not
what
we
desire
to
have
enhanced,
feasible
path
works
best,
because
what
as2,
for
example,
is
saying
that
I
heard
p1
directly
from
a
s1
I
heard
p2
by
RAF
3
I
see
that
they
have
the
same
origin.
S1.
N
Therefore,
I
am
going
to
allow
source
addresses
in
p1,
as
well
as
in
p2
from
s1
and
s3
does
the
same
thing
and
there
is
no
denial
of
traffic
for
the
customer,
so
one
scenario
where
it
works,
but
even
if
you
have
prepending
so
now,
a
s1
is
trying
to
follow
BCPs
for
operational
recommendation.
It
announces
all
its
prefixes
to
s2,
as
well
as
a
s3,
both
its
transit
providers
and
it
does
prepending
in
order
to
achieve
whatever
traffic
engineering
it
wants
to
achieve.
Now.
N
A
s2
and
s3
are
in
the
happy
position
that
they
know
all
their
prefixes
that
the
customer
has,
and
it
has
announced
them
in
BGP.
So
they
stick
to
RPF
works
would
work
fine.
As
far
as
now,
we
are
looking
at
comparison
between
feasible
and
enhanced
feasible.
As
as
we
go
through
the
examples,
we
try
to
highlight
the
fact
that
the
feasible
may
fail
sometimes,
but
the
enhanced
feasible
still
works.
That
is
the
improvement
we
are
trying
to
show
so
feasible
path
works.
N
If
the
customer
drought
is
preferred
at
a
s3
over
the
shorter
path,
so
that
is,
if
that
happens,
if
the
customer
route
is
preferred,
then
it
works.
If
the
customer
route
is
not
preferred.
Instead,
the
shorter
path
through
appear
is
preferred,
then
even
feasible.
Your
pH
P
F
will
have
a
problem
not
on.
N
If
a
data
packet
goes
from
s1
to
s3
and
shows
up
a
s,
@a
s
2
and
s
2
happen
to
shoe,
choose
best
path,
not
it
right.
If,
if
it
didn't
choose
the
customer
route
as
the
as
the
best
part,
then
there
could
be
a
problem
with
the
feasible
path.
Otherwise,
not
regardless
of
of
that
of
the
type
of
path.
Selection
that
as2
or
as3
do
in
enhance,
feasible
path
works
in
both
cases,
whether
the
customer
prefix
is
preferred
or
the
shorter
path
length
is
preferred
in
both
cases
enhanced
feasible
path.
N
N
So,
unlike
in
the
previous
scenario,
in
this
scenario,
we
are
back
to
the
case
where
the
customer
is
not
being
not
observing
the
atp-cp
84
recommendation
properly,
announcing
different
prefixes
to
different
upstream
providers
and
not
doing
not
announcing
all
its
prefixes
so
selectively,
announcing
so
only
p1
propagates
from
s1
to
s2
to
s4,
only
p2
propagates
from
s1
to
s3
to
s4
and
p2,
also
propagates
by
RA
s5
to
s4.
Now
we're
looking
at
a
s4
and
what
we
want
really.
N
Is
that
the
flexibility
that,
if
s4,
is
seeing
data
packets
with
source
addresses
in
p1
or
p2
on
any
of
those
interfaces,
whether
it
is
from
the
to
customers
below
s1
or
s2,
whether
it
is
from
the
peer,
a
s5
in
all
cases?
Yes,
4
should
be
willing
and
ready
to
accept
data
packets
coming
from
originating
from
s1
with
source
address
in
either
p1
or
p2,
and
that
happens
that
happens
with
enhanced
a
feasible
path
alone.
N
We
end
up
putting
aside
lose
your
TF
that
have
in
this
scenario
that
doesn't
happen
with
feasible
path,
but
it
happens
with
enhanced
feasible
path
once
again
because
of
the
flexibility
of
giving
the
benefit
of
doubt
based
on
the
same
origin
areas.
So
the
basic
basic
idea
is
that
from
v1
that
that
is
good,
because
I
saw
the
BGP
update
from
p1,
so
data
packet
with
source
address
p1
is
good,
p2
same
origin,
a
s.
So
potentially
there
is
a
data
packet,
a
data
path
for
p2
as
well,
so
I'm
going
to
accept
it.
N
They
both
have
the
same
origin
so
now
on
in
the
no
discussion
it
got,
I
mean
pretty
interesting,
so
people,
multiple
people,
job
and
couple
of
others.
They
came
up
with
the
same
example
to
show
one
case
where
very
to
it
wouldn't
work,
and
that
is
shown
here,
but
what
they
example
they
shared
on
the
grow
list,
and
essentially
what
it
says
is
that
a
s1
puts
a
no
export,
so
p1
p2.
It
announces
both
prefixes
to
its
upstreams
to
the
to
upstream
transit
providers.
N
N
K
N
So
the
operational
recommendation,
if
we
look
back
at
84
I,
have
been
saying
this
all
along
the
recommendation.
The
way
it
is
worded
in
the
PCP
84
is
that
the
mechanism
relies
on
consistent
route
advertisements.
That
is
the
same
prefixes
through
all
of
the
paths
propagating
to
all
the
routers
performing
feasible,
RPF
checking
and
we
relaxed
that.
So
that's
a
bit
stringent,
all
the
prefixes
must
be
announced
and
they
must
be
propagating
up
to
all
the
routers
that
are
doing
feasible
path.
As
we
move
up
from
the
customer
to
the
course.
N
We
want
to
relax
that
as
much
as
possible
and
if
more
words
here,
but
it
is,
it's
actually
a
more
relaxed
or
less
stringent
operational
requirement.
That
is
because
all
we
are
saying
here
is
that
if
you
are
a
multi
homestay
base,
you
must
announce
at
least
one
of
your
origination
prefixes,
without
without
no
export
or
or
they
are
X,
they
should
be
exportable,
unlike
that
example
through
each
of
your
transit
providers.
N
So
it
is
a
one
prefix
exportable
to
each
of
your
transit
providers,
and
if
you
are
a
non
stub,
a
s
you
have,
some
customers
below
the
above
recommendation
should
still
be
applied.
Regarding
your
origination,
prefixes
and
additionally
for
the
transit
routes
that
you
are
going
that
you
have
selected
as
best
path,
you
must
announce
at
least
one
route
for
each
unique
prefix
origin
pair
to
each
transit
provider.
So
a
lot
of
words
here,
but
hopefully
these
operational
recommendation
mean
that
this
kind
of
anyway
happens
it.
N
So
the
the
main
idea
is
that
is
that
you're,
you
do
RPF
checks
in
the
line
card
and
in
the
line
card
you
push
the
rib
into
the
Rhine
card
or
some
of
the
contents
of
the
rib
into
the
line
cards
and
in
the
line
card.
You
have
to
look
up
the
destination
address
once
and
when
you
are
doing
your
PF,
you
also
do
a
second
look
up
for
the
source
address.
So
what
are
the
source
addresses
that
that
you
are
going
to
look,
for?
N
That
is
what
we
were
talking
about
right,
so
that
those
are
the
addresses
that
that
you
need
to
say:
okay,
if
those,
if
the
source
address
belongs
to
one
of
those
prefixes.
It's
good.
The
data
packet
is
good
to
go.
If
it
doesn't,
then
the
data
packet
is
dropped.
That
is
the
idea
of
reverse
pass
filtering.
N
So
as
long
as
the
demand
on
the
RHIB
in
the
line
card
is
not
excessive,
this
has
this
has
a
when
we
could
conceive
of
implementing
it
by
enhancing
the
RPF
in
the
RIP
card.
So
if
you
do
strict,
if
you
do
strict
you
RPF,
you
have
to
have
some
additions
right
in
the
in
the
line
card.
That
says
that
the
rip
tells
me
what
are
the
destination
addresses
that
are
routable.
N
In
addition,
if,
if
I
do,
for
example,
feasible
path
it
those
additional
prefixes
that
are
allowed
in
the
source
address,
they
are
not
coming
strictly
from
the
rail.
Some
of
them
come
from
I'm
sorry,
they
are
not
coming
strictly
from
the
flip
because
they
are
not
your
best
paths
they
so
so
now
what
what
we
have
sort
of,
augmented
that
list,
by
allowing
some
flexibility
and-
and
so
those
additional
prefixes
which
are
not
necessarily
tied
to
the
RHIB,
should
also
be
included
in
the
RPF
filter
list
in
the
line
card.
N
N
J
So
Warren
Kumari
my
questions,
I
guess
somewhat
about
the
loss,
but
the
implementation,
but
how
much
extra
work
is.
This
is
this
basically
just
like
another
vrf,
with
sort
of
normal,
IP,
lookup
and
many
possible
like
it
feels
as
though
this
might
be
wildly
expensive?
But
if
not,
it
looks
like
it's
a
nice
idea.
Okay,.
O
Eric
muller,
so
conceptually
this
sounds
kind
of
interesting
and
I
can
see
some
potential
good
applications
for
it.
As
far
as
operational
deployment
goes,
one
really
big
concern
I
have
with
doing
something
like
this.
Is
that
well
now,
I'm
outsourcing
my
customer
filtering
to
that
customers,
other
transit
providers,
because
any
route
they
can
leak
through
another
transit
I'm
now
accepting
from
them.
Okay,.
N
So
you
are
doing
filtering
on
different
interface,
the
prefix
filtering.
You
follow
the
RFC
74/54
or
whatever,
and
now
there
is
also
rpki
and
draw
a
horizontal
addition
coming
along.
So
you
have
a
you're
accepting
these
prefixes,
the
ones
you
rejected.
They
are
out,
they
are
out.
They
are
not
in
your
rip.
These
are
the
ones
that
you
have
accepted.
You
have
included
them
in
your
best
path
selection.
So
at
that
point
you
have
done
your
prefix
filtering
you
made
in
the
down
the
road.
N
P
N
You
when
you
say,
let
me
ask
you
when
you
said
no
export
on
all
your.
Would
you
set
all
no
export
on
all
your
prefixes
or
maybe
some
towards
one
towards
all,
but
two
is
fees,
yes,
no
export
on
all
transit
towards
all
ISPs,
except
for
two,
yes,
and
no
export
on
every
one
of
the
prefixes
you
announced
to
them,
or
some
some
some
is
bent,
but
somewhat
most
is
still
okay,
as
long
as
it
is
at
least
one.
This
is.
This:
has
a
charge.
P
N
P
A
P
N
K
P
N
P
P
N
P
P
N
Q
Jeff,
and
so
you
are
caught
about,
two-thirds
of
the
stuff
I
was
gonna,
say
about
where
the
routes
get
advertised
long,
a
short
of
it,
sometimes
the
more
specifics
that
basically
a
before
it
want
you
to
send,
are
not
propagated
for
business
reasons.
So,
just
simply,
I
don't
want
this
network
to
be
at
the
pad
transit
for
know
this
traffic.
So,
unfortunately,
that
piece
of
ESP
84
may
not
be
deployable
in
some
circumstances:
yeah
others,
it
might
have
circumstances.
We
can
still
concede
it.
Q
Q
If
you're
on
a
box
that
actually
has
no
specific
lookups
for
a
multicast,
you
prf,
that
is
another
piece
of
machinery
that
can
be
taken
advantage
of,
but
that's
usually
much
smaller
table.
The
problem
we
have
here
with
no
going
with
the
you
know
the
instance
you're
talking
about
is
we're
looking
to
either
extend
one
of
these
tables
so
that
it
gets
so
basically
a
digital
noise
from
the
perspective
of
its
main
use.
Q
So,
if
we're
using
this
or
destination
based
forwarding-
and
we
were
doing
this
for
loose
and
therefore
we're-
including
all
the
routes
that
are
feasible
on
the
system-
and
we
want
to
group
together
additional
things
that
one
may
work
but
to
Warren's
point-
it
has
to
go
into
sort
of
precious,
no
forwarding
no
table
entries
so,
if
you're
to
take
other
presentations
some
grow,
but
where
people
are
freaking
out
about
the
FIB
size
expanding
well,
this
is
intentionally
increasing
the
size
of
the
FIB
to
allow
the
stuff
to
happen.
So
from
a
technical
perspective.
Q
This
is
a
way
this
could
be
done,
but
in
terms
of
the
impact
on
a
implementation,
what
would
take
to
actually
do
this?
It's
fairly
costly
and
the
problem
is
when
you
look
at
the
next
generation.
Mind
card
features,
no
usually
looking
a
couple
years
out
in
terms
of
the
forwarding
and
the
firewall
type
features
as
well.
They
look
a
couple
generations
out.
This
would
be
the
kind
of
thing
that,
if
this
was
to
be
a
feature,
would
have
to
get
in
people's
roadmaps.
Q
It
would
be
many
years
before
it
popped
out
and
you'd
have
to
plan
for
additional
resources
specifically
for
this
purpose.
So
it's
technically
correct
could
be
done.
Has
impact
may
be
deployable
in
some
circumstances?
An
existing
hardware,
but
pervasiveness,
especially
at
large
transit
providers,
is
probably
unlikely
based
on
the
capacity.
Yes.
N
N
The
closer
you
are
to
the
edge
as
opposed
to
the
core,
the
better
these
things
work.
So
considering
that,
wouldn't
you
wouldn't
it
be
the
case
that
you're
lying
the
load?
Are
they
additional
load
on
the
line
card?
Because
then
we
are
dealing
with
much
fewer
prefixes
that
any
particular
s
might
originate.
So
so
the
fractional
increase
in
the
load
on
the
teak
a
more
the
FIB
memory
is
smaller
right,
close
as
you
move
towards
the
edge,
and
that
is
where
it
is
also
most
effective.
So.
Q
You
have
the
correct
observation,
but
you
know
there's
part
of
the
lifecycle
of
routers
that
you're
not
really
accounting.
For
that
make
sure
the
box
is
at
the
edge,
also
tend
to
be
lower
capacity,
because
in
many
cases
no
today's
edge
routers
know
where
at
one
point,
no
yesterday's,
no
core
routers
so
sure
they
have
more
capacity,
they're
able
to
deal
with
the
edges,
but
they
may
have
just
enough
capacity
or
in
some
cases
you
may
be
buying
much
smaller
boxes.
Q
R
What
I
like
in
in
this
approach
is
this
is
one
of
the
first
approaches
where
I
see
that
somebody
is
trying
to
accommodate
what
happens
in
practice.
You
know
benefit
of
the
doubt.
Thank
you,
I
think
is
a
key
factor
in
designing
security
mechanisms,
because
the
whole
it's
either
black
or
as
whites
approach,
clearly
does
not
work
in
this
problem.
Space
so
I
like
that
as
a
philosophy
and
I
would
encourage
you
to
keep
looking
in
such
directions.
Thank
you
as
to
the
specifics
of
this
proposal.
R
Not
only
no
expert
can
be
a
challenge,
but
there
is
also
many
traffic
engineering
strategies
where
you,
for
instance,
lower
the
local
preference
outside
a
geographical
region
which
results
in
the
prefix
not
being
exported
within
that
region.
So
it's
don't
focus
just
on
no
expert
is
everything
related
to
traffic
engineering
can
jeopardize
this
mechanism
so.
N
R
Show
you
a
flying,
okay
and
and
there's
a
challenge
of
over
claiming
because
you
you
compiled
a
list
of
all
the
prefixes
that
are
originated
by
an
ASM,
but
in
the
cases
of
CD
ends,
somebody
might
a
CDN
might
put
a
small
cash
in
some
ISPs
network
that
only
has
2/24,
but
because
the
originate
is
an
instead
of
the
CDM
that
is
used
globally
and
CDM.
A
globally
have
up
to
a
slash
nine
worth
of
space,
then
that
small
ISP
that
has
that
small
cash.
R
Because
of
that
single
slash,
24
traffic
can
be
spoofed
for
the
slash
nine
that
is
owned
by
the
CDN.
And
if
you
look
at
traffic
spoof
a
text
and
the
IP
addresses
are
of
them.
Randomized
out
of
legitimately
used
IP
space.
But
you
are
good
as
long
as
the
slash
9
is
not
announced
in
BGP.
Well,
the
totality
of
the
slash
9
is
announced
from
from
perhaps
up
to
three
thousands
vantage
points
and
that
enables
the
one
ISP
to
to
spoof
quite
some
traffic.
R
N
R
Yeah,
if
you
can
really
narrow
down
that,
if
you
use
this
in
this
scenario
there
there
will
never
be
any
trouble,
then
you
know,
then
we
can
recommend
for
that
particular
style
of
deployments.
This
is
a
useful
document,
but
we
have
to
be
I.
We
between
the
four
of
us.
We
identified
a
number
of
cases
where
it
actually
breaks
things,
so
we
need
to
make
sure
that
that
never
happens
right.
N
J
You
so
Warren
Kumari
kind
of
related
to
the
last
comment.
Igor
I.
Think
for
your
sort
of
example,
where
you're
doing
all
your
prefixes
with
no
export
I,
think
that
you
can
fix
this
by
simply
announcing
a
sacrificial
proper
prefix,
which
then
sort
of
closes.
The
graph
doesn't
need
to
be
the
prefix
you're
actually
using.
But
you
know
you
can
signal
this
works
by
announcing
a
sacrificial
prefix
I,
see.
S
S
P
Quite
smart,
so
so
yes
I
can,
however,
that
might
expose
my
relationship
with
that
ASN
publicly,
which
is
absolutely
not
what
I
want
to
do
some
experiment:
I'll
prefix
as
well.
So
when
job
engineer
and
stuff
that
is
done
for
business
reasons,
some
of
it
might
be
confidentiality.
Is
it
literally
that
I
asked
goes,
will
have
a
connection
between
you
and
I?
Nobody
can
know
about
it.
That
happens
a
lot
in
practice.
L
Just
a
real
quick
comment
because
well
yob
said
I
really
resonated
with
me:
it's
really
important
also
to
articulate
where
it
will
work,
but
what
it
breaks,
medicare,
ko
so
anyway
from
fireside
security
but
yeah
but
articulating
what
it
breaks
right
is,
is
ask
critical
so
that
people
actually
know
that
you
know
cuz.
Some
people
just
say
works
here.
Well,
maybe
I'll
work
in
my
environment,
but
if
you
do
articulate
what
breaks
and
why
that
is
those
also
very
important
love.
This
draft.
N
P
H
So
this
is
fern
and
again
before
we
actually
before
actually
go
through
the
actual
contents
of
the
ad.
Let
me
try
to
introduce.
You
know
how
we
came
up
with
this
document
couple
I.
Think
years
ago,
I
was
working
with
some
ICMP
based
attacks
that
essentially
we're
about
spoofing,
ICMP
version,
six
packet,
two
big
messages
which
trigger
the
use
of
they
say
a
weird
feature
in
ipv6,
which
was
atomic
fragments.
Okay,
essentially,
you
had
two
systems.
H
You
know
that
were
transferring
information
with
each
other
and
you
could
spoof
one
ICMP
error
message
that
would
trigger
the
use
of
fragmentation,
but
as
a
result
of
the
weight
spread,
dropping
of
fragments
on
the
internet
that
would
cause
those
packets
to
get
dropped,
essentially
you'd
fire,
one
single
ICMP
error,
and
that
would
cause
you
know.
Packets,
between
the
two
endpoints
to
be
dropped.
I
mean
there
were
many
aspects
to
that.
Attack
like
one
of
them.
I
was
like
well.
H
Why
do
we
have
these
weird
atomic
fragments
in
the
first
place,
which
we
took
care
about
it,
but
the
other
one
was
a
more
generic
one
like
well.
We
have
ICMP
errors
which
don't
really
require,
don't
even
require
the
attacker
to
spoof
the
source
service
of
the
pockets,
because
you
know
they
could
be
coming
from
any
router,
so
the
idea
was
well
were,
could
some
device
that
was
at
the
very
edge
of
the
network
do
to
try
to
prevent?
Let's
say
users
for
lunch
in
this
kind
of
attacks
against
other
systems?
H
Okay,
so
we
came
up
with
this
very
simple
filtering
rule
that
needs
to
be
applied
at
the
edge,
obviously
not
in
cases
in
which
you
have
multihoming.
Okay,
because
that's
when
things
get
more
difficult.
So
now,
let's
move
to
the
UPS
contents.
So
essentially
the
idea
of
you
know
what
we
are
describing
here
is
what
you
could
do
to
filter
or
to
prevent.
You
know
attackers
at
the
age
of
a
network
from
performing
attacks
that
required
the
spoofing
of
ICMP
error.
H
Okay,
there
are
many
different
possible
attacks,
the
one
that
actually
triggered
this
word
was
the
use
of
packet,
big
error
messages
that
again
were
treating
a
specific
case,
the
generation
of
atomic
fragments
in
ipv6.
But
then
there
are
other
cases
like
you
could,
for
example,
spoof
ICMP
errors
that
in
some
cases
might,
for
example,
cost
connections
to
be
reset
or
other
ones.
Oh,
this
one
I
mentioned
has
to
be
applied
on
the
edge
and
obviously
not
in
cases
where
you
have
multihoming.
H
So
as
a
brief
refresher
of
you
know
how
I
see
a
ICMP
errors
are
generated,
we
have
like
you
know
two
end
points
on
the
extremes.
Let's
say
node
a
sends.
A
packet
known
tries
to
send
a
packet
through
this
router
B,
and
you
know,
let's
say
that
that
message
elicits
an
ICMP
error.
Essentially
the
ICMP
error
will
have
a
source
address
of
the
system
that
is
sending
the
error.
H
In
this
case,
the
destination
obviously
will
be
the
destination
of
the
error
message,
which
in
this
case
is
a
and
then
the
part
that
at
times
is
tricky
for
you
know,
for
people
that
are
not
into
protocol
say
internals
is
that
inside
the
ICMP
error
you
put
a
you
know
a
piece
of
the
packet
that
trigger
the
error
message.
So
that
means
the
original
packet
that
was
being
sent
from
A
to
B
or
to
the
in
this
case.
H
So
this
would
be
an
you
know,
attack
scenario
in
which
let's
say
that
we
have
these
two
systems.
You
know
there
are
transferring
data,
it
could
be
a
TCP
connection
or
something
this
could
be
the
internet,
or
you
know
some
kind
of
like
neck
were
over
there,
and
in
this
case
we
have
the
attacker
okay.
Now
what
the
article
wants
to
do
is
to
spoof
or
ICMP
error,
maybe
in
this
case
to
these
node
over
here,
you
know
pretending
that
it
came
from
you
know
somewhere
here.
H
You
know
from
the
path
that
the
original
packets
were
following.
Now
when
it
comes
to
the
source
address
this
one
over
here,
the
auditor
doesn't
actually
need
to
spoof
any
other.
Is
why?
Because,
though,
the
error
message
could
be
coming
from
any
router
on
the
internet,
destination
address
would
or
will
obviously
be
there.
You
know
the
target
of
the
other
okay,
the
source
address
will
correspond.
You
know
to
the
system
that
you
know
originally
send
the
original
packet
now.
H
The
interesting
part
here
is
the
destination
address
in
the
embedded
packet,
so
you
are
sending
an
error
message
from
here
and
that
essentially-
and
you
look
at
the
embedded
payload
essentially,
this
is
implying
that
you
got
here
a
packet
that
was
destined
to
this
address.
Okay,
so
if
you're,
not,
if
you
don't
have
a
multihoming
scenario
well,
obviously
you
could
have
never
actually
receive
this
packet
here.
So
essentially,
what
you
do
is
something
kind
of
like
bc,
p38,
but
based
on
the
destination
address
of
the
embedded
payload
meaning.
H
If
these
surgeries
here
doesn't
belong
to
your
network
here,
then
then
that
means
that
you
shouldn't
let
the
packet
go
through.
Okay,
you
could
have
never
received
this
original
packet
over
here.
The
rule
is
essentially
this
okay
destination
address
of
the
embedded
payload.
If
it's
within
my
network
I
will
let
the
packet
go
through.
Otherwise
I'll
drop
it
and
obviously
again.
This
implies
that
you're
looking
inside
a
you,
know,
ICMP
payload,
meaning
that
in
many
cases,
but
in
cases
where
you
are
looking
inside
or
you
can
look
inside,
you
might
filter
this.
H
What
are
the
changes
that
we
apply?
On
version?
3
well,
first
one
was
the
original
examples
where
I
say
I
pee
before
examples
somebody
said:
okay,
you
should
you
know
change
that
to
v6.
That's
what
we
did,
then
the
second
one
is
explained
possible.
Limitations
of
you
know
expect
an
ICMP
payloads
and
the
third
one-
and
this
was
I,
said
by
Carlos
Minotauro
in
part
of
the
ID.
We
have
like
the
generic
format
for
ICMP
errors,
but
based
on
the
extensions
of
you
know
specified
in
4884.
We
had.
This
is
the
ICMP
extension
options.
K
K
J
C
E
C
D
D
H
C
E
T
And
we're
trying
to
answer
a
question
that
well
some
people
have
that
as
top
of
mind.
Others
don't
have
that
that
much
we've
been
steering
traffic
for
decades
with
traffic
engineering,
service,
training
policy
based
routing
and
whatever
have
we
ever
ask
ourselves?
Is
the
traffic
really
following
that
path?
I
had
that
conversation
and
actually
the
the
work
was
inspired
by
a
gentleman
called
Stevie.
Oh
now,
working
at
JP
MC
those
days
working
at
another
bank,
and
he
said
well.
T
I
can't
really
do
anything
NFV,
because
as
soon
as
I
virtualize
I
lose
the
method
that
I'm
using
today
to
prove
the
path
which
is
probes
and
cable
checking
and
proving
means
showing
to
his
management
that
all
the
traffic
makes
it
through
a
particular
set
of
firewalls
and
well
sure.
If
you
do
it
nfe
there
are
no
cables
and
the
single
miss
configuration
of
the
V
switch
can
go
and
mess
the
overall
thing
up.
T
So
how
do
we
prove
in
a
cryptographically
secure
way
that
traffic
actually
makes
it
through
a
set
off,
say
firewalls
or
whatever
you
consider
so
problem
domain
is
very
easy,
we're
saying:
well,
we
want
to
make
sure
that
the
trophy
goes
through
ABC
and
not
a
X
C,
and
we
want
to
be
able
to
verify
that
it
made
it
through
that
particular
set
of
hops.
I.
Think
that's
the
problem
Nanako
solve
the
approach
that
we
took
to.
That
is,
let's
imagine,
we'd
be
able
to
have
this.
T
You
were
saying
as
a
controller
and
that
controller
would
be
able
to
have
a
secret
and
that
controller
might
be
able
to
split
that
secret
and
to
as
many
hops
as
you
want
to
see
verified
that
could
be
hops
as
a
service
chain.
It
could
just
be
general
routing
hops
that
you
want
to
make
sure
that
the
traffic
is
actually
going
through,
so
we're
taking
the
secret,
like
I,
hear
we're
splitting
that
into
as
many
hops
as
we
have
and
then
at
every
single
hop.
T
Two
points,
parabola
three
points,
cubic
function,
four
points
and
so
forth.
We'll
remember
that
right
and
it's
uniquely
identified
by
these
by
these
points.
Now,
let's
assume
that
we
have
a
polynomial
as
the
secret
and
if
we
say
one
a
verify
three
hops.
We
need
three
points.
So
we
need
a
polynomial
of
degree
2,
and
these
three
points
will
wander
one
identify
my
polynomial.
T
We
give
every
single
node
while
splitting
that
secret
means
we're
giving
every
single
node
a
point
on
the
curve,
and
then
the
verifier
would
just
need
to
go
and
re
retrieve
the
polynomial
from
these
three
points.
Okay,
all
of
that
is
well
based
on
the
mechanism
that
Sameer
Adi
Shamir
invented,
and
it's
well
kind
of
feasible.
But
if
you
look
at
that
mechanism,
it
would
mean
we
need
to
go
and
create
a
secret
polynomial
per
packet.
T
T
Now
you
need
to
go
and
read
through
the
draft
or
I
have
a
link
to
a
presentation
on
SlideShare
that
goes
and
takes
you
through
the
math,
but
the
overall
thing
can
be
done
in
a
very
computationally
simple
way,
and
we've
proven
that
with
a
reference,
implementation
in
open
source
and
VPP
and
open
an
open
daylight.
So
it
all
comes
down
to
every
single
node,
including
the
verifier,
we'll
need
to
do
to
auditions
one
multiplication
and
one
division
modulo
a
prime
number.
T
So
there
isn't
a
hallow'd
of
things
that
you
need
to
go
do
because
you're
computing,
the
Lagrange
polynomials
in
a
stepwise
fashion
and
the
secret
to
be
dead,
honest
is
not
the
entire
polynomial.
It's
only
the
constant
part
of
the
polynomial.
So
it's
just
the
constant
number
that
we
re
retrieving
and
again
as
an
identifier
of
the
second,
the
public
one
we're
just
using
the
constant
number.
T
So
the
constant
coefficient
I
have
to
say
in
in
order
to
be
well
operationally
easy
here
what
type
of
numbers
what
we
need
to
go
deal
with
and
I've
just
did
a
little
bit
of
math.
So
if
you
are
running
or
if
we're
assuming
that
we're
running
at
a
hundred
gig,
a
64-bit
number,
which
is
well
the
number
of
polynomials
that
we
can
have
for
the
second
polynomial,
going
back
to
the
constant
coefficient
we
roughly
can
live
with
that
for.
K
T
3,100
years,
more
or
less
without
reprovision,
the
entire
thing,
if
you
say
in
64
bits
of
metadata
that
I
need
to
go
and
carry
actually
two
times
of
64
bits
metadata
that
I
need
to
go
carry
is
too
much.
I
only
can
carry
32
well,
this
obviously
goes
down
exponentially.
Then
you
might
need
to
go
at
100,
Gig
reprovision
every
22
seconds.
So
there
is
a
trade-off,
but
64
bits
two
times
64
bits
sounds
like
a
reasonable
number.
T
That's
one
approach,
the
downside
of
Shamir
secret
sharing
is:
you
are
verifying
that
you've
been
through
a
set
of
hops,
you're,
not
verifying
the
sequence,
that's
actually
something
that
should
mere
secret
share
and
can't
really
do
for
us,
given
that
the
points
on
the
curve
are
points
on
the
curve.
If
we
want
to
go
and
do
something
that
is
more
like
order
preserving,
there
is
a
second
approach
documented
in
the
draft
that
is
more
like
composing,
an
onion
which
means
you're,
taking
a
number
and
hop-by-hop
you're
encrypting
that
number.
T
So
it's
like
you,
take
the
inner
piece
of
the
shell
and
then
you're
putting
another
shell
in
another
shell
and
the
verifier.
Would
need
to
do
the
exact
operation
that
you're
doing
through
the
network
all
itself
so
you're
your
step
by
step,
composing,
the
onion
as
the
packet
traverses
through
the
network
and
the
verifier
would
do
the
exact
same
thing
it
would
it
wouldn't
decrypt
it
will
just
recompose
the
exact
same
thing.
T
T
That
means
you
have
crypto
chips
at
Tripler
ships
out
there
that
might
be
a
feasel,
a
feasible
alternative
to
the
other
approach,
so
both
of
them
are
there,
we've
implemented
from
your
secret
sharing
an
open-source.
Well,
that's
just
how
you
carry
the
data
I
think
that's
not
too
interesting.
We
implemented
the
whole
schema
in
open
source
and
an
application
that
is
in
the
open,
daylight
carbon
release,
so
the
controller
who
picks
a
secret
and
then
splits
the
secret
into
as
many
nodes
and
hops.
T
You
have,
and
we've
implemented
that
as
part
of
the
service
function,
training
application
in
in
open
daylight
communicates
that,
along
with
the
other
parameters
that
you
need,
like
the
prime
number,
everything
is
done
over
a
finite
field,
so
everything
is
done,
modular,
prime,
so
that's
part
of
the
the
implementation
piece
there
and
the
data
plan.
Implementation
is
Don,
SS,
open
source
and
Fido
VP
piece
on
the
vector
packet,
processor,
I've,
included
the
links
to
the
documentation
and
also
the
code,
so
that
you
can
have
a
peek.
T
T
If
you
are
looking
for
a
nicer
format,
there
is
a
presentation
on
SlideShare
that
takes
you
throughout
Shamir
secret
sharing
works,
so
we
appreciate
Commons
and
especially
more
of
a
thorough
review
from
a
security
perspective,
because
what
this
does
is
obviously
it's
taken
the
packet
through
this
thing
and
then
kind
of
putting
updating
the
cryptographic
information.
It's
not
really
protecting
the
content.
What
we
can
do
is
the
the
second
random
number
as
a
packet
identifier.
We
can
use
that
as
a
hash
across
the
entire
package,
so
it
doesn't
necessarily
need
to
be
entirely
random.
T
We
can
go
and
choose
what
we
put
in,
but
well
there's.
Obviously
other
concerns
and
well
I'd
be
interested
to
hear
about
those,
and
that
leads
me
to
the
second
question:
is
that
something
like
the
problem
itself?
Maybe
not
the
solution
that
we
have
we
have
to,
but
the
problem
is
that
is
that
something
that
ops
AG
is
interested
in
looking
into
because,
as
I
said,
the
gentleman
from
the
financial
industry,
Steve
you'll,
say
well,
like
I
have
to
stay
with
physical
devices
unless
you
solve
that
problem.
For
me,
at
least
for
firewalls
thoughts,
comments.
U
J
T
V
T
T
Well,
we
do
believe
that
we
have
well
control
on
the
exit
door
like
a
potential
V
switch
or
whatever,
but
well
yeah
I
think
it
comes
with
certain
deployment
constraints
and
and
also
I,
think
I've
not
seen
a
single
chip
set
today.
That
is
able
to
do
a
modular
prime
operation
efficiently
in
hardware
software
data
plane
like
VPP,
modern.