►
From YouTube: IETF103-LISP-20181105-0900
Description
LISP meeting session at IETF103
2018/11/05 0900
https://datatracker.ietf.org/meeting/103/proceedings/
A
B
C
B
C
C
A
D
D
This
PGP
same
thing:
we
push
forward
chef,
every
table
has
been
done
and
we
have
comments
from
the
is
G
will
be
solved,
then
usually
intro
document
that
has
been
there
like
forever.
Okay,
the
base
documents.
We
had
thoreau
security
review,
which
actually
doubters
very
well
and
they
just
updated
the
documents.
There
has
been
several
updates,
but
yesterday
they
submitted
the
latest
version
and
we
will
have
an
update.
D
D
You
know
the
history
of
STIs,
it
came
back,
we
updated
to
be
standard,
make
sure
to
be
compliant
with
the
final
spec.
The
main
specs
will
most
probably
be
mandatory
to
implement
you
discuss
this
later,
but
we
will
move
it
forward
along
with
the
main
spec
okay
and
we
have
all
the
windows
specific
al-kahf
also
passed.
The
working
group
last
call
okay,
I'm
the
Shepherd
I'm
waiting
to
write
to
prepare
the
right
app
to
see
what
happens
with
main
specs
okay.
D
So
we
will
agenda.
Today
we
will
have
a
short
update
on
the
young
model.
Then
a
good
update
and
everything
that
happened
on
the
main
specs.
Okay,
then
an
update
on
the
Eid
anonymity
document,
the
ACD
essay
authentication
and
authorization
document
and
the
top
subscribe
document.
These
are
the
working
group
documents
on
the
non
working
group
items.
We
have
a
presentation
by
Victor
on
multi-domain
lisp.
Also
P.
Is
he
supposed
to
be
here?
D
B
E
D
F
D
F
You
so
the
changes
we
did
in
0
9
r,
st
changes,
which
we
discussed
last
ITF.
Can
montreal
the
in
the
virtual
network
list:
we've
mapped
them.
We've
changed
the
so
that
the
mapping
of
the
VN
eyes
to
virtual
network
instance
who's.
The
meter
2x
DRS
can
txt
ours
right.
You
know
and
we've
added
the
security
section,
the
security
considerations
section,
which
you
know
according
to
the
requirements
of
sixty
eighty
seven
bits,
so
that
section
in
sixty
seven
base
basically
request
that
you
identify
knowledge
which
could
be
sensitive
from
a
security
point
of
view.
F
F
So
previously,
the
VN
I
also
known
by
Samas
IID,
was
just
a
number
and
will
change
it
to
be
leaf
ref
who
to
the
virtual
network
cables.
So
that
way
you
cannot
just
put
in
number
which
does
not
map
to
any
any
vrf.
Also,
we've
made
the
network
instance
name
mandatory.
So
that's
your
birth
name
before
we,
you
could
just
add
a
VN
I,
which
had
no
network
instance
name
and
finally,
we've
made
the
network
instance
name
unique
so
that
you
cannot
map
multiple
TN
eyes
to
the
same
birth.
F
Okay,
next
step
Alberto.
Actually
this
weekend
pointed
out
that
the
yang
is
a
bit
out
of
sync
with
some
of
the
changes
in
the
best
documents.
For
example,
there
was
an
algo
ID,
which
was
added
I,
think
in
the
biz
Docs,
which
are
not
in
the
yang,
so
we
do
have
to
add
that
to
the
yang
and
after
that
you
know
in
about
two
weeks,
we
would
like
to
ask
the
chairs
to
start
a
working
group
class
called
a.
G
A
You
kept
talking
about
VN
eyes
and
use
VN
eyes
in
the
mapping
indexes.
What's
supposed
to
happen,
if
the
V
ni
is
the
public
Internet,
if
there
isn't
a
private
know,
if
it's
not
a
private
network,
I'm
looking
at
the
mappings
grouping-
and
it
looks
like
that's
a
mandatory
key
and
I,
don't
know
what
value
you'd
put
in
I.
H
F
So
do
you
there
is
it,
do
you
guys
do
you
chairs
or
anybody
in
the
room
having
an
issue
if,
after
we've
made
those
I
mean
there
was
others
Corrections
which
I've
been
mentioned,
and
with
the
algo
ID
that
we
start
a
worker
class
called
relatively
soon
I
mean
I'm,
not
stuck
on
two
weeks
or
three
weeks
or
four
weeks,
but
I
mean
I.
Think
I
mean
that
will
push
some
people
to
read
the
document
too,
because
I
don't
think
it's
got
as
much
love
as
it
should
have
being
yang.
F
A
E
F
E
F
J
Okay,
so
I'm
going
to
present
all
the
changes
on
50/30
p.m.
623
bees
that
we
we
did,
after
all,
the
reviews
and
instead
of
going
through
all
the
changes
and
detailing
every
one,
every
every
single
one
I
will
start
by
discussing
a
little
bit.
The
overall
changes
first,
like
a
short
summary
of
the
important
changes.
Then
I
will
list
all
the
all
the
smaller
changes.
J
The
focus,
change
on
other
use
cases,
and
now
the
common
property
for
such
cases
is
that
it
is
Lisp
is
focused
on
a
large
set
of
cooperating
entities
which
are
seeking
to
communicate
over
the
public
internet
or
an
underlay
IP
infrastructure.
While
keeping-
and
this
is
the
important
part
addressing
topology
separate
from
the
internet-
apology,
routing
and
addressed.
So
this
is
one
of
the
of
the
changes
and
wait
on
the
documents.
So
because
of
this,
we
remove
the
term
global
from
both
steps.
J
For
instance,
these
are
not
defined
as
global
identifiers,
but
within
this
set
of
cooperating
entities
and
so
on
and
so
forth.
So
the
second
change
is
that
now
list
SEC
is
mandatory
to
implement,
and
this
is
based
on
the
following
assumptions.
So
the
control
plane
holes
based
on
that
the
mapping
system
is
secure
and
trusted
that
Ethier's
have
a
pre-configured
translation
ship
with
a
mapping
system
and
that
list
set
must
be
implemented.
J
So
this
is
stated
in
the
control,
plane
and
the
so
as
a
result
of
this,
and
this
is
something
that
it
is
not
posted
yet-
and
this
is
just
my
interpretation
of
what
we
should
do
so
people
can
can
chime
in
and
say
if
they
agreed
or
not,
but
I
understand
that
deployment
that
are
concerned
about
this
kind
of
security
issues
should
sorry
mass
drop.
Contrary
message
that
do
not
contain
leaf
SEC
material,
which
is
the
SVD
av
quantum
key
and
packet
authentication
data.
A
J
I
J
Yeah,
so
we
require
so
we
need
to
add
these
sentence
into
the
pond.
This
is
not
yet
in
the
latest
version.
Ok,
then.
Another
change
is
an
interior
play
mechanism,
an
antibiotic
mechanics
for
my
producer.
So
this
to
prevent
in
attack,
which
is
a
mix
theory
sending
a
map
registered
to
a
map
server.
Then
an
attacker
is
intercepting
this
map.
While
it's
capturing
this
map
register
and
just
replaying
it,
which
means
that
it
will,
it
will
register
the
same
Navy
and
the
same
Arab.
J
So
let's
say
that
the
exodus
appears
then
an
attacker
can
actually
register
for
Samiha
via
network.
So
the
idea
that
we
have
now
and
noticed
the
Avro
timeline
so
time
go
from
the
left
to
the
right.
The
idea
we
have
now
is
that
the
map
server-
and
if
you
are,
they
keep
the
last,
they
keep
state,
which
is
the
last
nonce
used
and
each
map
register
for
each
map.
J
Register
Dixie
are
needs
to
increment
the
nonce
by
one
value,
which
means
that
if
an
attacker
intercepts
captured
one
of
this
map
register,
it
won't
be
able
to
replay,
because
the
map
server
only
accepts
map
register
with
the
nonce,
which
is
greater
than
the
last
scene.
Not
these
are
very
standard
and
replay
metallus
and
the
state
is
kept
on
on
both
at
the
xtr
and
the
map
server
and
the
non
didn't
that
set
by
the
extra
a
be
this
here.
J
So
the
non
without
incremented
image
map
register,
the
nonce
is
returned
in
map
no
different
message
which
this
estándar.
This
is,
as
in
the
old
version
of
the
documents
both
appears
a
map
separate
a
mastered
in
persistent
storage.
The
last
ones
which
is
indexed
by
Dixie
are
ID.
If
the
state
is
lost,
both
entities
need
to
rekey.
They
need
to
have
new,
share
keys
and
well.
If
the
map
register
received
with
a
nonce,
which
is
a
smaller
or
equal
to
one
store,
then
the
map
server
will
drop,
unlock
the
message.
J
J
So
now
I'm
going
to
list
all
the
changes,
but
I
already
explained
the
the
the
most
important
ones.
So
these
four
data
plane
document
so
seems
last
IDF,
and
this
pretty
much
because
of
the
changes
due
to
the
reviews
coming
in,
we
went
from
/
14
2000
to
5,
and
this
is
the
current
status
as
for
yesterday
of
the
documents
document
so
overall
and
introductions
to
remove
the
term
global.
J
The
first
one
is
a
small
is
that
the
TTL
or
cop
count
must
be
before
we
were
stating
that
it
should
be
copied
from
the
outer
head
up
to
the
inner
header.
This
is
when
the
caps
rating,
and
also
it
is
recommended
that
implementers
follow
60/40,
which
is
RFC,
describing
how
explicit
congestion
notification
bits
must
be
treated
when
tunneling,
so
that
it
will
recommend
to
to
follow
these.
These
guidelines,
then,
regarding
security
considerations.
We
added
why
this
is
a
minor
edit
I
think,
but
we
added
that
of
path.
J
So
then,
going
to
the
Contra
print
document,
we
went
Sims
last
idea
from
/
10
to
stash
21,
and
this
is
the
status
asked
for
yesterday
and
overall,
we
again
removed
the
term
global
an
example
of
a
sentence,
because
this
is
throughout
all
the
documents.
Mappings
are
propagated
across
the
mapping
system,
not
globally,
because
of
the
new
scope
of
applicability.
We
added
the
new
scope
of
applicability,
which
is
exactly
the
same
as
the
one
in
the
data
plane
there
are.
J
This
is
where
we
describe
the
interior
play
attacks.
This
is
exactly
same
as
I
was
explaining
before
and
will
also
include
a
sentence
stating
that
the
nonce
mass
before
we
were
saying,
should
be
generated
by
proper
random
sources
so
because
the
nones
is
index
at
by
the
xt
ID
and
the
expiry
ID
was
defined
in
another
document.
We
now
specify
both
experience
at
ID
in
the
list
under
pain
of
FC.
J
So
it's
pretty
much
stating
that
if
the
IPT
set,
then
at
the
end
of
the
memory
system,
we
will
find
our
agency
ID
that
uniquely
identify
the
Aaron
decided
where
the
XJ
is
attached,
then
on
security
considerations.
This
is
where
we
stayed
that
what
I
was
explaining
at
the
beginning,
at
least
set,
is
mandatory
to
implement
and
the
assumptions
that
we
are
we
hold
regarding
the
mapping
system,
which
is
secure
and
trusted,
and
that
there
is
a
pre-configured
relationship
between
the
idea
and
the
mapping
system.
J
We
also
describe
do
as
an
amplification
attack
that
can
be
done
by
exploiting
the
map-request
map-reply
message
exchange,
and
we
explain
also
how
this
set
provides.
A
number
set
of
protections,
original
indication,
integrity,
integrity,
protection,
prevention
of
man-in-the-middle
and
perfect
of
reclaiming
for
map,
request,
map,
reply,
message,
exchange
and
that
it
years
can
obtain
the
Navy
prefix
it
also.
This
is
the
kind
of
a
summary
of
the
attacks
that
let's
say
that
it
related
to
the
controller,
and
then
there
is
a
bunch
of
other
changes.
J
Oh
I
forgot
one
because
there
is
a
new
version
of
the
slides,
but
I
sent
them
five
minutes
ago.
So
we
also
include
ok.
So
no,
no,
that's
fine,
I,
just
wanna
slide.
So
one
of
the
comments
from
the
reviewers
was
that
we
were
ignoring
privacy
comments
regarding
the
control
plane
and
we
had
a
new
privacy
consideration
section
where
we
described
that.
J
The
summary
of
the
the
section
is
that
Hades,
our
long
leaf
identifiers
that
can
somehow
identify
the
note
and
that
they
correlate
with
the
airlock,
which
is
a
topological
location
of
the
note,
and
that
this
information
is
pretty
much
public.
We
seen
the
list
department
and
this
introducing
some
privacy
concerns
that
disk,
and
this
can
be
mitigated
by
either
using
authentication
mechanism
for
mapping
information
within
the
left
side
and
or
using
a
similarly
edit,
for
which
we
are.
We
have
already.
J
Sorry,
no
access
control
list,
that's
one
right,
and
now
it's
not
in
the
dissection
we
said
so.
First
you
can
ECL
who
can
ask
for
mapping
information.
Then
you
can
resultant
equation,
which
is
a
more
advanced
form
of
ECL,
let's
say
to
identify
who
can
have
access
to
the
information
or
use
ephemerally?
Okay,
okay,
so
and
then
the
last.
This
is
the
last
slide,
so
there
are
a
bunch
of
common,
so
we
simplified
the
abstract.
J
There
is
a
small
change
on
the
not
change.
We
are
stating
that
there
is
a
type
seven
control
plan
message
which
is
not
assigned.
We
added
capture
to
some
figures,
then
this
little
bit
more
important
bits,
m
and
I
in
map
request
are
now
reserved
and
define
in
in
other
documents
and
beat
them
is
also
reserved
in
the
memory
system.
So
those
are
bits
that
were
defined
in
the
control
plane
and
now
the
controller
is
just
preserving
it
and
they
are
being
used
in
other
the
forms.
J
There
are
many
instances
of
may
in
capital
letters
that
are
now
made
without
capital
letters.
Little
changes
we
are
also
using
ipv6
addresses
to
for
the
examples
on
some
of
the
paragraphs.
This
is
I
think
it's
recommended
also
by
IDF
and
some
of
the
fields
in
my
precious
time
notify
notify
acknowledgement.
Are
they
are
defining
in
all
this
message
and
they
have
the
same
meaning
so
we're
specifying
that
they
are
dual
use
and
then
there
are
also
a
bunch
of
of
minor
areas.
J
D
D
H
J
H
K
Eric
not
my
question,
so
I
haven't
read
the
spec
on
this,
but
these
announcers
can
they
actually
get
out
of
sync
suppose
that
the
ex
TR
is
sending
nouns
to
that
map
registry
is
never
received
by
the
map
server.
J
H
L
H
Are
you
referring
to
the
map
notify
as
an
acknowledgment
to
the
map
register?
Yes,
okay?
So
that
because
that
takes
out
the
discussion
about
uncensored
map
notifies
so
being
since
it's
an
acknowledgment
to
the
map
register,
the
map
notify
copy
for
nods
from
the
map
register
and
then,
when
the
next
map
registers
sent,
it
could
be
sent
+1
or
+
and.
H
E
A
E
H
M
M
So
what
are
we
trying
to
solve
we're
really
trying
to
make
the
IDS
private
and
non-trackable?
Typically
IDs
are
persistent
and
they're
storing
in
the
mapping
system,
where
you
can
look
them
out,
and
this
whole
graph
is
about
trying
to
make
them
private
and
non
tractable
as
possible
without
enforcing
more
encryption.
This
is
particularly
useful
in
the
mobility
use.
Cases
where
the
locator
part,
which
is
the
visible
part,
is
also
changing,
so
we
actually
have
the
two
changing
at
the
same
time,
which
actually
prevents
trainability
next
night.
So
how
do
we
do
that?
M
It's
actually
a
case
of
where
we
actually
hide
in
a
crowd,
or
rather
in
this
case
we
hide
in
a
pool
of
addresses.
Every
wally
ids
are
just
like
normally
ids
their
IP
addresses.
The
only
thing
is
that
they
come
recycle.
It's
a
random
number
which
is
recycled
within
the
pool
and
the
points
within
a
specified
range.
Now
we
can
use
different
techniques
to
to
generate
them.
One
of
them
is
to
cut
your
hash.
M
M
But
it
might
be
very
interesting,
though,
to
use
a
different
one
for
each
section,
which
appears
so
that
you
really
make
yourself
more
invisible
in
that
sense,
and
from
ladies
should
have
a
limited
life,
or
else
they
just
become
a
permanent,
the
ideas,
the
others,
and
we
can
also
use
them
as
a
one-time,
only
thought
before
recycling
them
a
little
bit
like
having
a
credit
card
that
you
can
use
only
once,
and
then
the
number
changes.
M
So
how
do
we
do
this?
What's
great
is
that
we
do
not
have
really
any
changes
the
base
list
protocol.
It
really
relies
on
the
clicks,
yeah
existing
mechanisms
already
present
with
a
registration
duration.
Do
you
registration
of
in
the
mapping
system.
What
we
are
really
documenting
here
is
also
the
reservation
of
the
range
for
the
pool
of
addresses
and
also
some
recommendations
and
how
to
avoid
collision.
M
The
use
case
is
some
other
I.
Don't
have
it
I,
don't
have
it
elaborate
use
case
in
the
slides
here,
but
one
of
them
would
be.
For
example,
if
I
talk
to
you
once
and
I'll
give
you
my
Eid
and
we
are
having
a
lush
met
conversation,
but
that
doesn't
prevent
you
later
to
misuse
that
yeah
II,
because
now
you
already
know
it,
but
in
the
case
where
I'm
actually
changing
my
Eid
all
the
time,
it
doesn't
guarantee
you
that
the
next
time
you're
really
going
to
try
to
target
me,
can
be
anybody
else.
M
D
Well,
a
stockman
has
been
around
for
a
while
if
it
goes
to
work.
Equip
last
call,
of
course,
will
be
cured
a
pile
of
work
that
is
G
is
doing
for
that.
But
anyway,
we,
since
the
others
I
asking
for
the
worst
working
group
last
call
let's
get
a
sense
of
the
rooms.
So
if
you
guys
think
that
the
top
minutes
okay
and
is
ready
to
be
published,
please
are
now.
D
M
H
H
In
Montreal,
so
post
Montreal,
we
got
some
comments
during
the
working
group
in
Montreal
and
we
updated
a
document
that
0
3
and
then
requested
for
working
group
documents.
So
this
is
the
first
working
group
document,
so
basically
an
overview
of
the
draft.
What's
the
drafts
proposing
is
to
authenticate
and
authorize
XT
hours
using
the
mapping
systems,
so
we
can
sign
map
registers
and
sign
map
requests,
and
only
when
authenticated
you
get
a
lot
you're
allowed
to
register
EW
ID'd
our
look
mappings
and
when
you
get
authenticated
for
map
request,
you
get
answers
back.
H
So
we,
the
draft,
specifies
how
to
store
public
keys
in
the
mapping
systems
and
introduces
a
concept
of
a
crypto,
a
ID,
a
crypto
e
ID
is
an
ipv6
address
with
a
prefix
and
low-order
bits,
and
the
lower
two
bits
are
hash
of
a
public
key.
Not
only
does
that,
allow
you
to
authenticate
yourself
and
look
up
the
public
key
mappings,
but
it
gives
you
the
right
to
use
that
ipv6
address.
In
sending
data
packets,
we
introduced
something
called
signature
IDs.
H
We
called
them
signature
a
IDs
in
the
past,
but
we
got
commentary
last
ITF
that
the
IDS
were
misleading,
because
there's
entities
that
don't
have
the
IDs
that
might
wanted
to
use
signatures.
So
we
just
call
them
signature,
IDs
and
those
signature.
Ids
are
the
same
ipv6
an
ipv6
address
that
has
a
prefix
in
a
hash
of
a
public
key
next.
H
So
what
are
some
of
the
benefits?
Well,
we
get
to
use
DSA
signatures
with
elliptic
curve
cryptography.
We
can
verify
and
invalidate
a
single
XDR
or
previously.
If
you
wanted
an
XT,
are
to
not
register,
you
would
have
to
change
the
shared
key,
which
means
all
other
etrs
that
were
sharing
the
the
same.
Shared
key
would
have
to
be
recued
and
that's
a
big
management
problem.
So
now
you
can
ended
it
invalidate
or
by
just
not
allowing
the
public
key
to
be
registered,
a
mapping
system.
H
You
could
allow
XT
RS
to
not
register
or
request
mappings,
and
then
we
use
this
signature
ID
for
registering
any
kind
of
Eid
type.
That's
what
we
added!
So
not
only
you
can
register
an
ipv6
crypto
Eid,
but
you
can
also
register
an
ipv4
address,
a
distinguished
name
geo-coordinates,
all
the
type
of
a
ID
types
that
are
in
el
caps
and
we're
going
to
show
how
we
can
make
that
secure.
H
H
We
can
now
validate
that
and
I'll
explain
that
in
a
second,
so
you
can
use
the
public
key
for
encrypting
results
as
well,
but
the
spec
does
not
talk
about
encryption,
just
authentication
so
now
that
annex
TR
has
a
public/private
key
pair
that
public
key
could
be
used
to
encrypt
messages
to
it.
So
we
have
some
interesting
things
we
could
do
in
the
future
with
the
mapping
system,
encrypting,
control
messages
and
we
provide
identity,
privacy.
Multiple
key
pairs
could
be
used.
H
So,
like
Padma
was
explaining
with
a
family
IDs,
we
could
constantly,
if
you're,
using
crypto
key
IDs
instead
of
random
numbers,
you
can
constantly
check
or
change
key
pairs,
and
we
find
that
the
cryptocurrency
and
blockchain
algorithms
use
that
they
go
through
key
pairs
very
quickly
and
it's
very
secure.
So
any
public
keys
that
are
in
the
clear
or
in
the
net
network
anywhere
only
one-time
use
keys,
so
it
adds
more
security
to
it.
Thanks.
H
Okay,
so
some
of
the
changes
that
went
into
the
O
3
/
0
0,
the
O
3-
was
the
individual
submission.
The
0
0
was
the
first
working
group.
It
was
one
in
the
same
changes.
We
just
changed
signature
IDs,
so
every
signature
that
appears
in
a
map
request
or
map
register
is
a
company
with
a
signature
ID
and
that
allows
the
map
server
to
look
up
the
signature
Eid
in
the
mapping
system
to
find
the
public
key
to
verify
the
signature.
H
Okay
and
then
we
added
multi
signatures
to
allow
a
particular
ETR
to
register
other
types
of
things
and
I'll
show
you
the
next
slide
an
example
of
that
one.
Other
thing
is,
since
we
allowed
signing
map
registers
and
that
requests,
we
also
consign
map
notify
messages
too.
So,
if
you
sign,
if
you
generate
a
key
pair
in
the
map
server,
then
a
map
server
could
actually
sign
a
map
notify.
H
So
when
you
get
a
notify
telling
you
that
there's
an
our
look
set
change,
you
know
it's
coming
from
an
authenticated
map
server,
and
this
is
the
way
the
the
map
notify
would
look
there
be
on
our
low
credit
record
in
there.
That
would
have
the
signature
and
then
the
signature
ID
would
be
its
crypto
ID.
H
So
here's
an
example
where
this
is
a
public
key
mapping.
It
has
four
records
in
the
mapping
system,
so
basically
the
crypto
e
ID
that
has
the
Lord
or
64
bits
of
that
one
1
two
2
three
3
four
4
is
registered
to
the
mapping
system
with
this
Eid
called
hash
as
an
ASCII
string,
for
instance,
ID
1000.
So
when
it's,
what
this
is
is
a
public
key
mapping.
H
So
when
a
particular
map
server
gets
a
map
register
with
this,
it's
a
map
register
and
it's
saying
that
it's
signer
ID
is
this
one
1
two
2
three
3
four
4
the
map.
Server
can
look
up
this
record
and
get
that
public
key
that
you
see,
there's
the
first,
our
local
record
and
verify
the
signature.
Now
what
we
added,
where
it
was
additional
records
where
other
entities
could
actually
merge
the
our
look
set
into
this
entity,
so
this
guy
here
2001
colon
colon
1
1
1
1.
H
Now
you
could
see
that
you
could
have
multiple
guys
for
1/1
1/32
and
you
can
do
a
two-thirds
rule
where,
if
two
out
of
the
three
signers
have
signed
it,
that
means
they're
allowing
you
to
to
register
that
and
so
the
map.
So
what
happens
is
when
the
map
register
is
being
received
by
the
map
server
for
this
Eid
one
1/32.
It
can
verify
this
and
I
just
show
you
two
more
records
that
could
be
well
the
the
two
there.
H
It
requires
two
signatures
from
:
:
1
1,
1,
:,
:
2,
2
2,
but
maybe
that
guy
wants
to
register
as
geo-coordinates,
and
you
can
see
that
just
one
entity
allows
it.
So
if
the
signature,
if
the
public
he's
not
there
or
the
signature,
is
not
part
of
this
thing,
then
the
you
can't
allow
the
Eid
the
map
server
would
reject
it
and
only
allow
it
to
register
the
things
that
it
has.
Signatures
for.
H
Things
that
we
could
work
on
in
the
future
in
this
spec
is
that
we
put
this
on
the
to-do
list.
Last
IETF
and
I
didn't
I
didn't
spec
it,
but
our
look
probe
requests
that
go
from
ITR
ETR
could
actually
be
signed
as
well.
So
an
e
TR
that
gets
a
probe
could
only
respond
back
to
authenticated
ITRs
and
we
also
finding
out
that
you
know
our
look
probes
contain
a
lot
of
information
rekeying
for
list
crypto.
H
It
also
can
contain
telemetry
data,
and
so
maybe
the
ITR
wants
to
authenticate
the
e
TR
to
make
sure
it's
the
right
place
where
it
can
trust
this
telemetry
data.
Ok,
we
can
consider
encrypting
map
registers
from
ETR
to
map
server
using
public
key
of
the
map
server,
and
we
can
also
do
the
same
for
map
requests
from
ITR
to
map-resolver.
So
now
we
have
now
that
we
have
this
public
key,
these
key
pairs.
We
can
do
interesting
things
now
when
they
submit
to
a
symmetric
keying.
H
H
Then
the
decrypt,
the
entire
message
that
that's
a
pretty
good
idea
that
would
require
protocol
changes,
obviously,
but
will
decide
if
what
the
working
group
should
decide
if
we
want
to
put
these
features
in
the
big
advantages
is
a
lot
of
people
are
saying
that
they
want
all
interaction
with
the
mapping
system
to
become
private.
They
don't
want
to
know
who's,
registering
bloody
IDs
with
what
our
looks
and
they
don't
want
to
know
who's
requesting
what
e
IDs.
H
D
H
H
I
H
Or
I
mean-
or
if
you
have
a
separate
document
that
says
we
just
encrypt
the
Eid
record
and
we
can
keep
it
under
256
bytes.
Then
we
don't
have
to.
We
just
have
to
say
there's
an
understanding
between
the
two,
the
implementation
that
the
I
mean.
You're
gonna
need
a
bit
to
say
it's
encrypted
versus
not
right,
something
like
that.
So
there
is
most
likely
going
to
have
to
be
packet,
format,
changes
to
support
it,
and
but
but
I
I
mean
so.
The
idea
here
is
to
get
more.
H
We've
been
experimenting
with
this
for
about
a
year
now
the
the
just
the
regular
signing,
and
we
want
to
get
more
experience
with
multi
signatures
and
stuff.
So
you
know
we're
not
ready
to
carry
it
forward
anymore
than
just
keeping
it
a
working
group
document
and
maybe
I
may
be
next.
Itf
I
can
show
you
an
implementation
of
the
multi
signatures
and
how
it
can
work
as
a
high-level
use
case,
and
then
we
could
play
around
with
I
mean
I'd
rather
not
implement
and
prototype
the
encryption
part
of
it
until
we
can
spec
it
out.
K
So
so
uncommon
I
think
that
the
notion
of
being
able
to
encrypt
everything
that
they
sort
of
possible
to
do
is
here
is
interesting.
I,
don't
know
if
anybody's
looked
at
what's
the
performance
impact
of
using
public
key
crypto
for
all
of
that
I'm
supposed
to
figure
out
a
way
of
having
some
symmetric
scheme
if
you're
gonna
do
that,
yeah.
H
K
K
H
I'm
doing
some
experiments
now,
where
I'm
just
encrypting
the
map
register
using
ChaCha
only
with
the
shared
key
that
exists
between
the
security
Association
between
the
two
and
I'm
trying
to
do
some
performance
measurements
on
that.
So
I
could
report
that
yeah.
It's
not
AES,
though
it's
cha-cha,
20,
so
much
much
faster,
smaller
Keys.
E
E
So
the
change
is
introduced,
so
the
first
change
was
already
mentioned
by
Albert
when
he
did
this
presentation
and
basically
the
site
ID
and
XDR
ID
definitions
and
the
corresponding
Ayana
consideration.
Let
me
moved
to
68
33
B's,
and
this
is
because,
basically
and
now
we
want
to
have
that
definition
in
in
68
33
only
for
the
Macra
asbestos
yeah
exactly
there
are
a
few
security
consideration
that
have
been
added.
E
E
The
pub/sub
will
not
be
used
as
a
way
to
basically
overload
NXT
are,
and
then
there
is
a
discussion
that
we
have
been
having
in
the
mailing
list
and
partially
in
the
last
couple
of
days
here
and
basically
it's
how
to
handle
the
knowns
in
map
notifies
and
we
can
go
to
the
next
slide.
That
is
providing
the
details,
not
useful.
E
Okay,
so
I
start
from
the
well.
The
the
first
one
is
that
there
is
a
discussion
on
if
we
should
include
up
not
the
updates,
a
taxi,
68,
33
B's
in
here
and
I,
think
you
know
the
right
people
have
discussing
this
and
they
will
come
up
to
the
right
conclusion
and
the
other
discussion
that
is
open
is
how
to
deal
with
the
with
the
known.
E
So
these
I
will
be
reflected
in
a
mini
list
and
I
think
in
the
next
version,
as
it
was
discussed
very
recently,
but
the
idea
is
that
with
PAD
sab,
we
are
using
the
map-request
as
a
way
to
subscribe,
basically
a
next
year.
So
since,
as
described
by
albert,
we
have
changed
the
use
of
knowns
to
become
basically
a
sequence
number
to
prevent
replay
attacks.
The
question
is:
should
we
change
that
also
for
the
map
for
them
for
the
publish/subscribe
protocol,
so
in
publish/subscribe?
E
The
reply
attack
is
relevant,
because
if
I
want
to
subscribe
to
a
mapping,
somebody
could
replying
that
message
and
subscribe
me
again
or
unsubscribe
me
again.
So
the
conclusion
is
that
when
we
use
the
map
request
with
the
semantics
of
subscribe,
we
should
have
an
anti
reply-
protection
mechanism.
That
is
exactly
the
same
that
we
use
in
the
map
register
and
these
will
basically
be
handled
exactly
as
we
described
in
my
register
when
messages
are
sent
from
the
xtr
to
the
map
cell
subscribed
apart.
Our
protocol
is
also
another
message
that
is
another
protocol.
E
It
is
basically
sent
from
the
map
server
down
to
the
xtr
and
again,
the
question
is:
is
that
protocol
subject
to
reply
attacks?
And
the
answer
is
yes,
because
if
you
receive
a
publish
from
the
mapping
system,
somebody
could
reply
that
the
publish
and
basically
reuse,
one
that
you've
sent
in
the
past
so
exactly
for
the
same
reason
we
are
going
to
use
also
their
announced.
That
is
a
basically
avoiding
reply.
Attack
that
are
mounted
against
the
map.
Server
same
thing,
notify
as
publish
messages
in
the
in
departure
protocol.
D
G
So
some
of
these
networks
have
very
high
sensitivity
and
we
basically
have
pockets
of
the
network
that
need
their
own
mapping
system,
their
own
set
of
resources
and
are
able
to
basically
survive
failures,
and
you
know
their
networks.
So
what
we
want
to
do
is
basically
structure
the
network
as
a
series
of
sites
that
are
connected
by
a
transit,
transit
domain
or
a
transit
overlay.
These
are
all
entire
list
networks
with
their
own
mapping
systems
with
their
own
X
TRS
and
they
initiate
and
terminate
their
tunnels
in
the
in
the
site.
G
A
If
I
can
interrupt
you
right
there,
because
looking
at
the
draft
I
was
left
confused.
So
the
first
point
I'd
make
is
that
the
comment
you
made
just
now
about
having
a
mapping
system
or
a
portion
of
the
mapping
system
that
this
site
can
take
responsibility
for
and
therefore,
and
it's
only
an
intra
site
connectivity
works
as
long
as
this
site
is
working.
That's
an
important
point
to
call
out
that
is
not
clearly
called
out
in
the
draft.
A
A
This
doesn't
really
improve
mapping
system
scale
because
the
ability
to
delegate
in
any
of
the
mapping
system
inversions
we've
used,
gives
you
very
good
scaling
already,
and
this
introduces
REM
caps
and
additional
specific
points
of
failure
along
the
intercept
paths
where,
if
you
didn't
do
this,
your
intersect
communication
would
be
more
robust
because
it
wouldn't
be
going
through
a
small
set
of
tunnel
routers.
So
I'm
left
it's
not
that
you
can't
do
it
that
clearly
works,
but
except
for
the
mapping
system
and
I,
think
that
could
be
done
in
simpler
ways.
A
H
See
why
so
this
is,
you
know
so
I
think
we
missed
messaged
the
benefit.
The
idea
wasn't
we
were
stating
we're
trying
to
make
the
mapping
system
scale.
Well,
those
are
three
independent
mapping
systems
that
are
managed
independently.
It's
not
a
subtree
of
one
versus
the
other,
but
why?
Why
are
they
managed
independently
because
these
sites?
So
what
is
a
site
overlay?
It's
a
set
of
X
TRS
and
a
mapping
system
where
they
encapsulate
to
each
other
and
it's
managed
and
wholly
owned
by
one
organization.
Okay,
so
wouldn't
it
be.
A
You're
gonna
have
to
coordinate
for
all
the
inter
site
stuff
anyway,
and
you
don't
have
to
coordinate.
If
you
can't
the
other
organization,
you
just
operate
locally.
It
should
be
possible
to
solve
this
problem
purely
inside
of
the
mapping
system
and
we
entertain
lots
of
mapping
system
alternatives.
That's
one
of
the
nice
properties
of
layers
without
getting
into
the
complexities
of
adding
tunnel
routers
to
provide
interconnection
and
I'm,
just
I.
A
But
it's
the
only
thing
that's
injected
into
the
Oh
Boober
lay
is
the
aggregated
information,
which
is
the
only
way
they're
scales.
Then,
if
I
rehome
from
one
site
to
another,
I
actually
don't
get
connectivity
unless
I
change
my
Eid,
the
whole
point
is
not
to
have
to
change
my
Eid
when
I
move
so
again
I'm
left
with,
but
this
doesn't
seem
to
match
what
we've
said
are
our
objectives.
A
G
A
L
G
G
So
what
the
draft
is
attempting
to
explain
is
basically
how
you
could
actually
get
this
to
work.
Basically
from
a
control
plane
perspective,
the
XT,
ours
or
every
site
will
have
basically
its
own
set
of
XT
ours,
its
map
servers
and
there's.
Basically,
this
roll
of
a
border
XT
are
that
connects
the
sites
to
the
overlay,
and,
if
you
can,
you
can
think
of
the
topology
from
from
a
virtual
network
perspective
as
a
daisy
right
with
the
core
of
that
desi
being
the
overlay
and
all
the
petals
being
to
side
overlays.
G
G
The
borders
in
turn
will
actually
take
those
and
register
in
the
stable
state.
They
would
register
basically
summary
of
those
of
those,
the
ADEs
an
aggregated
route.
In
the
case
of
mobility,
we
will
see
that
we
actually
start
registering
more
specifics,
so
that
we
can
support
dat
mobility
procedures
and
the
other
thing
that
is
interesting
at
that
border
is
that
we're
going
to
register
defaults.
G
So
there
is
a
default
registration
known
as
early
as
0/0,
but
basically
the
notion
of
registering
a
default
that
would
behave
similar
to
what
we
do
to
calculate
covering
prefixes
for
NMR's,
but
this
would
actually
be
used
to
calculate
an
actual
map-reply,
and
the
idea
is
that
for
most
cases
we
would
actually
have
any
communication
that
goes
beyond
the
site.
Follow
that
default,
so
we're
not
creating
remote
State
in
those
in
those
sites.
G
So
that's
all
the
control,
plane,
interaction
and
basically,
what
what
you
end
up
with
are
the
registrations
that
you
see
on
the
right-hand
side
of
the
diagram
right.
So
you've
got
the
local
elements,
as
you
can
see
at
the
top,
you've
got
one
1/16
and
one
2/16,
with
their
corresponding
our
looks
and
you've
got
a
default,
but
for
everything
else,
and
that
points
to
your
border,
x-ers.
K
G
So
once
you've
created
the
state,
what
takes
place
is
pretty
standard.
We've
tried
to
basically
keep
each
domain
doing
X
for
the
most
part,
exactly
what
we
have
in
place
of
what
the
draft
calls
out
are
the
exceptions
that
need
to
be
implemented
at
the
borders
to
to
actually
create
this
concatenation
of
overlays.
So
if
I
go
through
a
flow,
basically
I'm
going
to
issue
a
map
request
and
that
request
being
for
an
eID
that
is
remote,
it's
going
to
come
back
with
a
response
that
is
the
default,
the
default
points
to
the
borders.
G
So
you
can
see
that
second
step,
which
is
basically
I'm
going
to
tunnel
my
traffic
to
those
borders
when
I
get
to
the
border,
I
issued
a
new
look
and
that
new
lookup
I
have
to
decide
which
mapping
system
I'm
going
to
look
at.
One
of
the
things
that's
happening
here
is
that
we
have
had
those
borders
actually
subscribed
to
all
the
local
key
IDs.
G
So
when
I
look
at
the
border
border
has
a
single
cache
that
single
cache
is
going
to
have
a
match
for
anything,
that's
local
and
it's
going
to
have
a
Miss
for
anything
that
is
across
the
overlay.
So
we're
gonna
do
that
lookup
and
we
get
as
a
response
to
X
here
or
the
R
looks
for
the
remote
takes
TRS
and
we
go
ahead
and
step
for
encapsulate
to
that
remote
x,
TR
and
at
that
remote
XE
r,
since
that
is
subscribed
to
the
local
Lea
IDs.
G
G
So
the
functionality
is
basically
anchored
on
the
role
of
that
border
x
TR
if
I
was
to
summarize
basically
I'm
simply
connecting
site
overlays
to
the
overlay
I'm
using
rien
capsulate
internal
routers
for
both
unicast
and
multicast,
and
that
border
is
also
the
point
at
which
I'm
going
to
exchange
information
between
the
mapping
systems
in
the
in
decide.
Overlays
as
well
as
in
the
overlay
and.
G
Part
of
what
I
do
at
that
border,
xcr
is
also
constrained
which
advertisements
go
into
the
site
overlays.
As
we
said,
we're
basically
registering
a
default
and
when
I
register
that
default,
if
I,
don't
absolutely
have
to
register
something
into
that
site,
overlay
I'm
going
to
basically
have
the
border
preclude
that
registration.
G
The
other
thing
that
borders
must
so
so
the
border
is
handled.
Basically,
those
two
are
look
set
and
two
separate
are
disjoint
our
look
spaces,
the
in
the
ad
mobility
case.
There
are
basically
two
away
tables
that
are
formed.
There
are
basically
each
domain
or
each
overlay
is
going
to
have
its
own
mobility
environment.
So
these
environments
require
a
wait
tables
to
keep
track
of
anything
that
may
be
misrouted
to
to
old
cache
locations.
So
you're
going
to
have
one
facing
the
overlay
one
facing
the
the
site
overlay
so.
A
Actually,
the
split
horizons
a
little
bit
tricky
because
you,
you
have
site
prefixes,
which
are
going
to
show
up
from
the
overlay
into
the
local
site
legitimately
if
there's
been
movement
yeah,
but
accidentally.
If
there's
something
else
going
on,
it's
gonna
be
I
know
you
called
it
out
in
the
dress.
You
know
it's
a
little
bit
tricky
I
think
you
can
make
it
work,
but
it.
H
H
A
G
H
G
G
The
other
thing
that
we
do
is
we
relay
events
across
the
domain,
so
here
I
have
called
out
that
we
relay
mobility
events
that
there's
basically
map
notifications
that
that
go
back
to
the
departure
sites.
We
are
going
to
also
relay
mobile
notifications
that
go
towards
the
sources
of
multicast
right,
so
so,
basically
we're
relaying
a
lot
of
the
signaling,
and
that's
that's
one
of
the
principles
of
how
these
borders
work.
So
so
they
in.
G
G
G
Basically
those
map
rate
map
notifications
will
hit
the
borders
and
that
triggers
basically
registration
of
most
has
interest
in
the
next
overlay,
so
it
basically
gets
Stacy
change.
One
interesting
thing
is
that
the
border
x-ers
actually
provide
a
natural
point
of
replication
for
forehead
and
replicated
multicast
right
so
at
each
at
each
boundary.
You
basically
providing
a
point
where
you
are
reducing
the
amount
of
replicas
that
you
that
you
have
to
put
onto
the
network
from
the
very
source.
G
There
are
a
some
VPN
considerations
when
you
do
this,
you
have
the
ability
to
scope
the
instance
IDs
that
you
use
in
the
different
sites
if
they
are
not
going
to
be
used
for
the
purposes
of
cross
site
communications,
so
so
I
could
have
basically
dedicated
instance.
Ids
in
each
in
each
overlay,
site
or
I
could
have
global
instance
IDs,
which
are
actually
going
to
give
me
services
that
cut
across
all
the
different
all
the
different
domains.
H
So
one
other
benefit
that
we
didn't
talk
about
is
how
these
uber
lays
and
site
overlays
can
help
the
underlay
since
the
insight
of
site
overlay.
Since
you
only
encapsulate
to
our
locus
at
our
in
that
region,
those
our
looks
don't
have
to
be
redistributed
into
anywhere
else
in
the
underlay,
so
it
does
help
the
underlying
routing
system
not
require
routes
for
everywhere.
So
there's
these
containment.
K
N
G
Okay,
yeah,
you
you
it's!
It's
all
documented
in
detail
in
the
draft,
but
basically
it's
a
concatenation
of
signal
free
messaging
for
for
interesting
interest
expression.
So
as
you,
if
you
if
I,
was
to
summarize
what
what
you
do
in
signal
free,
multi
casting
you
have
anywhere
where
there's
attached
listeners,
there
will
be
basically
a
registration
into
the
mapping
system
that
registration
triggers
a
map
notify
towards
the
source
or
DRP,
depending
on
whether
it's
a
SM
or
SSM.
G
G
G
E
G
G
A
very
good
point
right
so
so
part
of
what's
driving
this
and
and
fret
sampling
is
not
here,
but
he's
presenting
he's
presented
a
few
times
his
case
for
having.
Basically,
the
civil
aviation
ground
network
be
be
restructured
and
one
of
the
things
is
that
it
it
needs
to
be
modular,
so
different
countries
are
going
to
choose
different
technologies
and
they
they
will
meet
in
this
in
the
center
of
this,
so
so
part
of
what
it's
motivated.
The
development
of
this
has
been
basically
achieving
that
modularity,
so
we
can
have
basically
different
that.
E
A
In
the
real
world,
I
think
we
could
make
some
quit,
so
we
could
have
a
common
mapping
system
that
had
clean
enough
boundaries
that
we
could
make
that
work,
but
if
they
really
want
different
ones,
because
each
one
is
making
its
own
choices
about
what
to
use,
then
it
doesn't
matter
how
I
structured
it
I
need
a
way.
I
need
to
completely
separate
the
mapping
systems,
and
then
going
back
down
to
the
xtr
is,
is
about
the
only
way
to
get
a
clean
separation?