►
From YouTube: IETF102-IRTFOPEN-20180717-0930
Description
IRTFOPEN meeting session at IETF102
2018/07/17 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
A
I'm
the
IRT
F
chair,
Alison,
mankin
I.
Think
many
of
you
have
been
here
before
I'm
hoping
a
bunch
of
you
are
new
because
of
our
and
our
W
experiment
of
having
our
research
workshop
during
the
ITTF
week
and
I'm
going
to
talk
a
little
bit
about
that,
but
very
warm
welcome
to
those
who
are
here
for
the
first
time
we
hope
you'll
stay
around
okay.
A
This
actually
worked
properly,
okay,
so,
first
of
all
the
traditional
showing
of
the
note
well,
how
many
are
seeing
a
note?
Well
for
the
first
time,
I'm
hoping
a
few
of
you
know:
okay,
a
few
okay,
all
right.
So
this
is
the
reminder
of
the
policies.
Irt
F
uses
the
same
policies
as
the
IETF
and
in
particular
we
have
some
specifics
about
disclosing
your
patent
or
patent
applications
or
those
that
you
know
about.
There's
lots
of
information
in
the
note
well,
and
we
also
have
policies
about
being
kind
to
each
other,
not
harassing
each
other.
A
We
have
a
code
of
conduct.
We
have
a
privacy
policy,
so
all
that
information
is
there
and
because
of
the
fact
that
we
have
a
prize
that
we
give
out
here.
There
is
a
lot
of
photography
during
this
session
and
our
photographer
will
pay
attention
to
your
red
lanyard
if
you're
wearing
one,
but
we
have
a
statement
on
that
consent
as
well.
I
want
to
mention
to
my
research
group,
chairs
and
I
said
see
email,
but
I
haven't
sent
the
email
yet
I'd
like
you
to
update
your
note
wells
with
the
note.
A
Well,
that's
in
here
so
I'll
make
sure
that
I've
sent
that
to
you,
so
that
you
aren't
using
note
wells
from
years
ago.
All
right
so
a
reminder
of
what
we
do
here.
I
RTF
has
actually
been
around
as
long
as
the
IETF
in
some
form,
because
originally
the
internet
was
a
research
project,
but
its
current
incarnation
is
a
group
that
is
supervised
by
the
internet
architecture
board.
The
appointment
of
the
chair
is
by
that
and
we
look
at
longer
term
research
issues.
A
We
have
research
groups
that
are
parallel
to
working
groups.
We
have
a
steering
group,
that's
parallel
to
the
iesg,
although
it
has
fewer
duties
and
we
have
a
small
number
of
at-large
members
on
that.
An
important
thing
is
that
in
the
groups
that
you're
going
to
go
to
the
are
G's
that
you're
going
to
go
to
later
or
the
later
in
the
week
there
weren't
in
a
yesterday
because
of
the
research
workshop,
we
don't
do
any
standards
so
documents
that
come
out
from
us,
our
experimental
or
informational,
and
if
you've
got
questions
about
that.
A
A
So
today,
I'm
just
going
to
talk
a
little
bit
and
then
we're
going
to
have
the
applied
network
research
prize
talks
Mariya
up
mr.
Lackey
and
Panos
puppeteer
Matos
and
I'll
introduce
them
when
we
get
there.
But
I
have
a
few
comments
about
a
few
more
things
about
IRT
F.
So
this
is
the
list
of
all
of
our
groups.
A
A
The
quantum
internet
group
is
a
proposed
RG.
We
have
a
an
approach
where,
once
you
have
a
new
idea,
it's
pretty
easy
to
get
a
proposed
Sergi,
you
get
three
meetings
and
then,
after
the
three
meetings
we
decide
if
you're
going
to
be
chartered
as
a
full-fledged,
RG
or
not,
and
quantum
internet
hasn't
actually
had
a
meeting.
Yet
we
also
have
a
research
group.
That's
in
planning
it's
not
yet
having
a
real
meeting,
it's
having
a
side
meeting.
So
we
have
a
lot
of
things.
A
A
We've
been
looking
in
open
searches
to
replace
some
co-chairs
who
stepped
down
in
HR
PC
the
human
rights
group
and
protocol
considerations
and
network
management
research
group
HR
PC.
We
will
be
appointing
the
second
chair
this
week,
NMR
G
we're
looking
at
a
reach
harder
and
so
we're
going
to
rethink
a
little
bit
and
take
a
little
bit
longer
to
think
about
the
people.
But
we
thank
them
before,
but
will
thank
again.
A
People
who've
been
chairs
there
and
we
will
be
looking
for
a
third
co-chair
for
the
crypto
forum
research
group,
also
known
as
cypher
G.
So
just
there's
some
news
on
that.
This
is
a
little
bit
about
perigee,
I
hope
for
it
to
work
in
a
parallel
fashion
to
cypher
G.
There's
many
there's
there's
much
much
much
great
research
on
cryptographic,
privacy
technology.
That
is
not
much
incorporated
into
our
thinking
here
at
the
IETF.
A
This
is
a
time
when
it's
it's
a
an
opportunity
for
you.
They
didn't
are
G
or
D,
&,
RG
or
didn't
squared
distributed.
The
Internet
infrastructure
proposed
research
group
is
having
its
third
meeting.
This
time,
they've
been
having
a
lively
charter
revision
with
lots
of
discussion
on
their
mailing
list.
They
have
a
meeting
Friday
again
since
we
couldn't
meet
Monday
we've
got
our
our
G's
kind
of
stacked
up
in
doubles
and
on
Fridays,
but
this
is
going
to
be
very
good
one.
A
There
they're
making
progress
on
an
experimental
consensus
protocol
and
also
talking
about
a
number
of
the
aspects
of
centralization
and
decentralization
and
that
that
are
still
really
not
well
understood
in
our
community.
We've
made
a
bunch
of
tries
at
it,
but
so
Melinda
and
Dirk
are
the
chairs
of
that
and
I
want
to
encourage
you
and
also
we'll
get
your
opinions
about
the
transition
from
proposed
to
full-fledged.
A
You
want
to
raise
your
hand
if
people
know
of
someone
who'd
like
to
sponsor
Matt
is
our
everything
about
a
nrw,
and
he
can
help
you
with
figuring
out
how
to
get
the
sponsorship
to
us
because
hey
we
already
have
the
logo.
We're
ready
to
go
for
next
year.
So
expect
another
expect
some
some
even
more
ambitious
plans
for
it
for
the
coming
year
and
as
far
as
joining
again,
some
of
you
who
were
there
yesterday,
will
recognize
that
Mark
Coleman
presented
and
listed
himself
as
a
reformed
ITF
native.
A
We
really
want
people
who
are
reformed,
ITF
errs
or
not
yet
IT
efforts
to
join
in
all
the
different
ways
in
the
IRT
F
and
there's
a
bunch
of
different
ways
to
contact
us
and
just
FYI.
We
also
have
not
FYI
that
most
of
the
rest
of
the
agenda
is
going
to
be
about
the
A&R
P
Awards
so
and
our
W
is
the
workshop
and
our
P
is
the
best
papers
and
those
we
give
out
to
per
ITF.
A
A
So
I
want
to
mention
that
Roya
and
Safie,
who
came
and
Safi
who
came
to
the
Argentina
IETF,
is
back
for
a
return
visit
and
will
also
be
speaking
in
the
HR
PC
and
Paul
Emmerich,
who
was
I
believe
last
time
is
back
and
he
is
on
the
agenda
in
the
benchmarking
working
group
and
we're
happy
to
have
the
returnees
and
people
who
are
here
might
return
so
get
to
know
them.
Okay,
all
right!
So
we
have
these
two
talks.
A
The
first
one
is
going
to
be
Maria's
talk,
she's
from
ETH
Zurich
in
Switzerland,
its
hijacking,
Bitcoin
and
routing
attacks
on
cryptocurrency.
You
want
to
come
up
and
set
up
your
machine
Maria
and
the
second
awardee
is
pon.
Oses
talk
that'll,
be
about
scalable
security
topics
in
vehicular
communication.
So,
let's
get
on
with
this.
A
B
C
Okay,
so
hello,
everyone,
my
name,
is
Mario
Solanki
and
I'm.
A
PhD
student
at
ep8
I
would
like
to
thank
you
all
for
this
opportunity
that
you
give
me
to
present
my
work
on
Saturday,
verse
and
knowledgeable
audience
so
today,
I
will
present
our
work
on
routing
attacks
in
Bitcoin.
This
is
joint
work
with
my
professor
Johann
van
beaver
and
Aviv's
Ahura,
who
is
also
professor.
C
The
Hebrew
University
routing
attacks
quite
often
make
the
news
you
will
have
probably
heard
about
this:
Russian
ISP,
the
high
jerk
large
chunks
of
Internet
traffic
destined
to
MasterCard,
Visa
and
other
financial
services,
or
about
this
other
Canadian
ISP
that
managed
to
steal
eighty
three
thousand
dollars
by
hijacking
the
prefixes
of
a
mining
pool
and
the
price
just
gets
higher.
Recently
like
a
month
ago,
there
was
an
additional
attack
against
my
ether
wallet
that
also
cost
multiple
thousands
of
dollars.
C
However,
this
is
only
the
tip
of
the
iceberg
in
routing
manipulations,
by
analyzing
six
months
of
b2b
advertisement,
we
actually
found
that
BGP
hijacks
are
much
more
prevalent
in
the
internet
that
we
might
have
thought
so
to
give
you
an
intuition
of
our
findings.
In
this
slide,
you
can
see
the
number
of
monthly
hijacks
that
we
detected
in
each
of
the
month
that
you
see
in
the
x-axis,
so
you
can
see
that
there
are
thousands
of
hijacks
ever
every
month.
Of
course
not
all
of
them
are
malicious.
In
fact,
most
of
them
are
misconfigurations.
C
However,
they
are
practical
and
they
do
affect
Internet.
Today,
the
the
the
purpose
of
our
work
is
to
set
light
on
the
impact
of
routing
attacks
in
Bitcoin.
Bitcoin
should
be
robust
against
routing
attacks
right.
After
all,
it's
a
highly
decentralized
protocol
of
nodes
that
are
scattered
around
the
globe.
They
establish
random
connections
and
they
often
use
multihoming
and
additional
really
networks
to
interconnect.
I
like
intuition,
though
Bitcoin
is
highly
centralized
from
both
the
routing
and
the
mining
viewpoint.
C
To
give
you
an
intuition
of
our
findings
in
this
graph,
you
can
see
the
cumulative
percentage
of
mining
power
as
a
function
of
networks
hosting
it.
You
can
imagine
why,
in
power
as
computational
power
and
networks
as
simple
ISPs,
like
i8
NT
you'll,
see
that
mining
power
is
very
centralized
to
only
few
networks.
For
example,
then
I
space
hosts
68%
of
mining
power,
and
it's
not
only
about
mining
power,
even
regular
Bitcoin
clients.
They
are
centralized.
C
C
We
found
that
in
this
graph
you
can
see
the
cumulative
percentage
of
a
connection
as
a
function
of
the
transit
networks
intercepting
it,
and
you
will
see
that
3
only
3
ISPs
intercept
63%
of
of
the
Bitcoin
traffic
because
of
all
the
centralization
two
attacks
are
in
fact,
practical
and
effective.
Today
the
partition
attack
in
which
the
attack
tries
to
partition
the
network
into
half
and
the
daily
attack
in
which
the
attacker
try
to
delay
the
block
propagation.
C
The
partition
attack
is
very
visible
and
that's
because
the
attacker
needs
to
first
hijack
traffic,
but
it's
also
very
effective,
even
against
a
Bitcoin
network
as
a
whole.
The
daily
attack
is
extremely
invisible,
as
the
attacker
only
acts
on
traffic
see
naturally
intercepts,
but
it's
also
effective
against
a
couple
of
nodes
targeted
nodes,
so
my
talk
today
would
be
composed
of
four
parts.
I'll
first
give
you
some
background
information.
Then
I
will
talk
about
each
of
the
two
attacks
that
we
consider
in
our
work
and
they'll
finish.
The
talk
with
countermeasures,
including
our
follow-up
work.
C
So,
let's
jump
to
the
background.
Bitcoin
is
a
distributed
network
of
nodes
that
establish
random
connections
to
each
other.
Each
of
the
nodes
keep
a
ledger
of
all
transactions
ever
done
in
Bitcoin.
This
ledger.
We
call
the
blockchain.
The
blockchain
is
just
a
chain
of
blocks
and
locks
are
composed
by
basically
contained
transactions.
C
The
blockchain
is
obtained
by
miners
and
miners
have
to
lose
to
have
to
use
a
lot
of
computational
power
to
extend
this
doctrine
and
they're
compensated
for
this
effort
with
block
rewards.
Bitcoins
miner
mining
is
a
very
risky
process.
You
can
mine
for
years
and
years
and
still
not
get
anything.
So
what
miners
do
is
that
they
collaborate
forming
mining,
pools
and
mining
pools
need
to
also
use
regular
Bitcoin
clients
in
order
to
interconnect
with
the
rest
of
the
network.
C
C
C
C
C
If
I
had
to
describe
why
this
is
warring
with
one
sentence,
I
would
tell
you
well,
bitcoin
is
a
consensus
protocol.
It
cannot
work
if
nodes
cannot
talk
to
each
other,
but
now
I
have
more
time.
I'll
be
more
concise
and
I
will
tell
you
that
it's
an
effective
denial
of
service
attack
as
transactions
cannot
be
moved
from
one,
but
one
component
to
the
other.
Second,
it
can
cause
revenue
loss
and
that's
because
all
blocks
that
are
mined
within
one
of
the
two
components.
C
The
one
with
the
least
mining
power
will
be
discarded
and
by
discarded
I
mean
that
all
the
miners
that
use
their
mining
power
to
mine
these
new
blocks,
they
they
will
lose
their
revenue
and
finally,
it
allows
double
spending
attacks.
So,
basically,
I
can
use
my
same
bitcoins
to
buy
twice
as
much
as
I
as
I
would
regularly
buy,
just
because
I
spent
them
in
the
different
components.
So
now
that
I
hope
I
persuade
you,
this
is
bad.
I'll
tell
you
how
it
works.
C
So,
let's
assume
we
have
this
Bitcoin
network,
and
this
is
in
the
middle,
is
malicious
and
wants
to
partition
it
to
two
different
components.
Intuitively.
What
the
attacker
will
do
is
attract
all
traffic
destined
to
notes
in
the
right
and
drop
all
connections
that
cross
the
partition
to
understand
how
this
is
done,
we'll
focus
on
one
node,
no
death,
which
is
the
green
node
in
the
right
end
of
the
slide,
and
we'll
explain
how
the
attacker
will
use
b2b
hijacking
to
isolate
this
node
I.
C
Do
understand
that
many
of
the
folks
here
would
be
bored
with
the
next
seconds,
but
I
think
it's
important
to
engage
everyone
in
the
room.
So
basically
this
node
node
F
has
an
IP
and
this
IP
belongs
to
its
provider.
So
a
is
6a.
S6
is
responsible
for
creating
this
BGP
advertisement
that
will
be
propagated
a
s
by
a
yes
until
all
of
them
knows
how
to
reach
a
s6.
For
example,
a
s1
will
reach
a
s6
via
s7.
C
The
problem
with
BGP
that
you
will
hurt
many
times
in
this
meeting
is
that
it
doesn't
check
the
validity
of
advertisements
and
that
actually
means
that
MEA,
yes,
can
advertise
any
prefix.
So
let's
assume
that
the
attacker
actually
advertises
a
prefix
that
covers
the
IP
of
the
green
node
and
it's
in
fact
a
longer
prefix
than
the
benign
advertisement,
because
routers
in
the
internet
would
route
traffic
based
on
the
longest
prefix
match.
C
Everyone
would
choose
to
route
their
traffic
via
the
attacker
and
that's
what
we
call
the
BGP
hijack
and
that's
exactly
what
the
attacker
will
use
to
partition
the
Bitcoin
network.
She
will
hijack
all
traffic
pertaining
to
nodes
in
the
write
all
prefixes
pertaining
to
nodes
in
the
right.
She
would
drop
the
connections
crossing
the
partition
and
boom
the
partition
is
created.
C
C
Connections
within
an
alias
and
and
this
an
attacker
cannot
intercept
because
within
an
alias,
we
don't
use
BGP
and
also
connections
within
a
mining
pool
and
private
connections
between
mining
pools.
The
reason
why
the
attacker
cannot
intercept
those
connections
is
that
she
might
be
not
aware
of
the
exact
topology
within
a
mining
pool,
or
you
might
not
be
aware
of
the
exact
protocol
that
the
two
different
pools
are
talking.
So
it's
harder
for
her
to
know
what
to
hijack,
and
it's
also
harder
for
her
to
distinguish
this
traffic.
C
But
even
in
these
cases
the
attacker
can
detect
that
the
partition
she
tries
to
create
is
infeasible
and
instead
create
a
smaller
but
feasible
one
in
the
pipe
for
it.
I'll
give
you
an
intuition
of
how
this
works,
so,
let's
assume
that
the
same
attacker
wants
to
create
a
different
partition,
so
the
one
that
is
denoted
by
this
red
line.
We
also
assume
the
presence
of
a
mining
pool
in
the
topology,
and
the
attacker
will
again
hijack
all
notes
in
the
right.
C
So
all
the
orange
nodes
she
will
cut
the
connection
crossing
the
partition
and
the
partition
is
created.
But
it's
not
effective
and
it's
not
effective
because
the
attacker
failed
to
cut
one
connection,
one
steals
connection,
but
that
was
a
connections
within
a
mining
pool,
but
what
the
attacker.
In
fact,
this
partition
was
infeasible
to
be
created,
because
the
attacker
could
not
know
that
this
is
a
connection
there.
C
So,
for
example,
the
attacker
might
notice
that
there
was
a
block
that
was
mined
by
black
nodes
and
was
advertised
by
the
orange
ones
and
in
fact
the
attacker
can
even
identify
this
one
node.
That
started
the
advertisement,
which
is
the
one
node
that
actually
had
the
stealth
connection
to
the
other
component,
and
once
you
find
that
in
this
case
it's
the
note
e.
She
can
remove
it
from
the
partition
and
create
a
similar
one.
That
is,
though,
feasible
in
the
paper.
C
We
evaluate
it.
Our
attack
in
terms
of
practicality
and
time
effectiveness,
to
evaluate
the
practicality
of
our
attack.
We
had
to
infer
the
Bitcoin
topology,
which
we
augmented
with
routing
information.
Using
this,
we
found
that
it's
possible
to
partition
the
network
into
two
disjoint
components
by
hijacking
100,
prefixes
and
and
splitting
the
network
to
half
is
the
worst
case
scenario
for
Bitcoin.
Of
course,
hijacking
100
prefixes
is
negligible
compared
to
the
hijacks
that
happen,
often
in
the
intern
and
as
an
illustration.
C
This
graph
shows
you
the
maximum
number
of
prefixes
that
were
hijacked
at
once
in
each
of
the
months
that
using
the
x-axis.
So
you
can
see
that
hijacks
of
one
thousand
prefixes
happen,
often
in
the
Internet
in
one
thousand,
is
one
order
of
magnitude
more
prefixes
that
the
attacker
would
need
to
split
the
network
to
half.
C
We
also
evaluated
our
attack
in
terms
of
time
efficiency
and
to
do
that,
we
had
no
other
option
that
do
it
in
practice,
but
we
attacked
our
own
notes
or
no
words.
So
we
are
talking
once
of
Bitcoin
clients
at
ETH.
These
clients
were
connected
to
the
live
Bitcoin
network
and
we
advertise
their
prefix
by
Amsterdam.
C
This
time
is
the
same
as
the
time
that
the
attacker
would
be
to
create
the
partition
in
this
graph.
You
can
see
the
summary
of
our
results,
so
you
see
the
cumulative
percentage
of
connections
that
were
intercepted
by
the
attacker
as
a
function
of
the
time
we're
stuck
so
it
will
take
less
than
10
seconds
for
the
attacker
to
intercept
all
the
connections.
That
means
that
it
will
take
less
than
100
seconds
for
the
partition
to
be
created.
C
On
the
other
hand,
though,
a
partition
like
a
hijack
will
take
a
couple
of
hours
to
be
mitigated
and
that's
because
it's
a
human
driven
process
and
I'm
sure
many
of
you
would
have
deal
with
such
a
situation
and
understand
how
weird
and
difficult
that
is.
It
took
even
Google
couple
of
hours
to
resolve
the
famous
BGP
hijack
the
Pakistan
Heydrich.
C
On
the
other
hand,
though,
after
the
the
attack
has
been
after
the
Heydrich
has
been
mitigated,
the
Bitcoin
network
is
able
to
reconnect
extremely
quickly
in
seconds
and
that's
because
the
network
has
a
natural
turn,
so
there
will
be
new
clients
that
will
connect
to
the
other
component
and,
and
that
will
quickly
bridge
the
partition
they
will
remain
loosely
connected.
But
that
will
not
affect
the
consensus
that
much
and
with
this
I
I
told
you
everything
that
I
want
to
say.
C
I
wanted
to
say
about
about
the
partition,
attack
and
I
wanted
to
have
a
joke,
but
I
failed.
So
yeah
I'll
just
talk
to
you
about
the
delay,
so
the
dealy
attack.
The
goal
of
the
delay
attack
is
to
keep
the
victim
uninformed
of
the
latest
mind
block,
and
this
is
worrying
for
multiple
reasons.
An
uninformed
merchan
is
acceptable
to
double
spending
attacks
because
they
don't
know
that
certain
bitcoins
have
been
spent
already.
C
An
uninformed
mining
pool
is
testing
to
wait
to
waste
its
mining
power
mining
mining
on
something
that
is
destined
to
be
discarded
and
a
nun
in
for
regular
note
cannot
simply
help
in
the
peer-to-peer
network.
So,
let's
see
how
it
works.
In
this
light,
you
will
see
three
Bitcoin
clients,
nodes,
a
and
B
or
connected
to
the
victim,
and
we
also
assume
the
presence
of
an
attacker
that
intercepts
the
connection
between
node,
a
and
the
victim.
C
Now,
let's
assume
that
a
block
is
mined
in
the
Bitcoin
network
nodes,
a
and
B
learn
about
it
and
they
advertise
it
to
the
victim.
The
victim
will
request
the
block
from
the
first
node
that
advertised
it
to
it.
So
it
will.
It
will
request
it
using
a
get
data
message
from
node
a
now.
If
the
attacker
wants
to
prevent
node
a
from
from
getting
this
block,
she
can
drop
the
get
beta
message
or
when
the
block
is
delivered,
she
can
drop
the
block
both
of
this
attack.
C
What
you
can
do
is
the
reverse
operation.
So
we
see
will
again
change
a
get
data
message
such
that
it
requests
for
the
initial
block.
If
the
block
is
delivered
within
the
20
minutes,
timeout,
the
victim
will
not
consider
this
whole
process
as
malicious
will,
keep
the
connection
and
will
be
happy.
So
the
attack
is
completely
under
the
rather.
The
reason
why
we
actually
use
a
gated
alpha
transaction
is
that
those
are
many
more.
C
So
it's
more
likely
that
the
attacker
you'll
find
one
such
message
and
we
evaluated
our
attack
in
terms
of
effectiveness
and
practicality,
to
evaluate
the
effectiveness
of
our
attack.
We
had
to
perform
it
in
the
wild,
so
we
again
used
the
Bitcoin
olds
that
we
hosted
a
deviates
were
connected
to
the
live
Bitcoin
network
and
we
assume
the
presence
of
an
attacker
that
container
cept
a
particular
percentage
of
the
victims
connections.
C
If
the
attacker
intercepts
50%
of
the
victims
connections,
she
can
keep
the
victim
uninformed
for
63%
of
its
uptime,
and
if
you
think
that
is
not,
this
doesn't
happen.
Often
that
tell
let
me
tell
you
that
for
almost
70
percent
of
the
Bitcoin
clients
in
the
internet,
there
is
such
an
ISP
that
intercepts
50%
of
the
connections
that
the
Bitcoin
client
can
create,
and
with
this
I'll
talk
you
about
countermeasures
likely.
Countermeasures
for
both
attack
are
possible.
C
For
example,
we
can
easily
deal
with
delay
attacks
if
we
adopt
an
encryption
in
the
Bitcoin
protocol
or
if
at
least
we
include
some
kind
of
mark
in
its
packet
such
that
we
are
sure
of
the
integrity
of
our
packets.
This
way,
the
attacker
will
no
longer
be
able
to
modify
the
packets
and
at
least
without
the
receiver,
noticing
it.
C
An
easier
countermeasure
would
be
to
let
the
Bitcoin
trends
be
more
smart
in
the
way
that
they
select
their
peers,
so
just
like
their
peers,
no
more
routing
a
rare
manner
such
that
there
is
not
a
single
ayah
speed
that
intercepts
most
of
its
connections.
However,
dealing
with
partition
attack
is
more
challenging.
The
easiest
way
to
do
it
is
to
actually
host
all
their
Bitcoin
client
since
last
24.
C
This
would
be
an
effective
countermeasure
because
it
would
force
the
attacker
to
actually
advertise
the
same
prefix
as
the
origin
as
the
benign
origin
and
and
using
this
the
attacker
will
all
only
be
able
to
attract
half
of
the
connections
she
would
normally
attract.
She
would
attract
if
she
was
using
a
longer
prefix
advertisement.
A
better
way
to
deal
with
this
problem
is
to
actually
deploy
secure,
outing
protocols.
C
Of
course,
yes,
because
this
would
would
help
us
in
not
actually
having
hijacks
at
all
and
I,
see
some
smiley
faces,
but
most
of
you
are
concerned
and
I
understand
that.
So
what
you're
thinking
is?
That's
not
practical
and
I
actually
totally
agree.
Okay,
we
cannot
host
all
our
a
Bitcoin
client
since
last
24,
because
that
will
increase
our
routing
tables
and
yes,
deploying
secure
auditing
protocol
would
be
awesome,
but
yeah
we're
not
there
yet,
and
we
will
not
be
there
just
because
of
Bitcoin.
C
So
what
we
envision
and
what
we're
actually
working
on
is
to
create
an
additional
security
Channel
that
we'll
be
able
to
let
our
clients
let
Bitcoin
clients
exchange
blocks,
even
if
their
their
network
is
partition.
So
even
if
there
is
a
BGP
hijack
that
is
going
on
and
we
build
a
system
that
we
call
Sabre
and
sable
Sabre
is
basically
a
real
network.
So
that
means
that
there
are
a
few
special
Bitcoin
clients
that
connect
to
each
other
and
also
connect
to
all
other
Bitcoin
nodes.
C
So
as
an
illustration,
if
we
have
this
Bitcoin
topology
Sabre
will
look
like
this.
It
will
be
some
additional
Bitcoin
clients
that
connect
to
each
other
and
also
connect
to
the
rest
of
the
Bitcoin
clients
in
a
way
such
that
the
Bitcoin
clients
don't
need
to
talk
directly
to
each
other,
but
they
can
talk
via
the
secure
channel
so
via
Sabre.
C
Now,
let
me
tell
you
what
is
special
about
our
relay
nodes
or
Sabre
nodes,
so
first
they're
strategically
located
in
the
internet,
such
that
the
chances
that
the
attacker
will
be
able
to
hijack
the
connections
between
the
relay
nodes
or
between
the
relay
nodes
and
the
actual
bitcoin
clients
is
minimal
and
second
they
are
built.
They
are
implemented
in
a
way
such
that
they
are
bused
against
denial
of
service
attacks.
So
let
me
tell
you
first
how
we
position
our
relay
networks
such
that
we
secure
them
against
hijacks.
C
So
that's
an
alias
topology
and
the
arrows
that
you
see
would
sell
the
money
flow
so,
for
example,
the
topmost
a
yeses
are
the
provider
of
the
mid
layers
and
the
mid
layers
is
peer
with
each
other
and
then
the
bottom,
a
SS
will
be
the
customers
of
the
middle
ages.
So
now,
let's
assume
that
the
middle,
a
s
is
an
attacker
and
C
hijacks,
the
prefix
of
the
blue,
a
yes
that
is
labeled
as
origin
and
she
actually
use
the
same
prefix
advertisement.
C
So
all
the
AES
is
in
the
slide,
we'll
learn
about
these
two
advertisements
and
they
will
have
to
choose
between
them.
These
decision
is
is
taken
based
on
two
factors:
first,
what
is
their
business
relationship
to
the
attacker
and
to
the
origin
and
second,
how
close
they
are
to
the
attacker
into
the
origin?
So
basically,
this
is
what
will
happen.
The
radius
is
that
you
see
would
be
those
that
will
be
lured
by
the
attackers
advertisement,
so
they
will
be
vulnerable
to
this
attack.
C
However,
we
also
see
this
grim
a
yes,
and
these
are
the
areas
that
are
not
vulnerable
to
this
attack.
For
example,
the
customers
of
the
attacker
will
not
be
willing
to
pay
for
her
advertisement,
so
they
will
not
be
vulnerable
to
her
attack.
All
this
to
say
that
as
a
relay
nodes
are
already
hosted
in
slash
24,
the
one
crucial
thing
is:
what
is
their
relations
to?
The
other
AES?
Is
that
host
relay
nodes,
as
well
as
to
the
AES,
is
that
host
Bitcoin
clients?
C
What
this
would
buy
us
is
that
we
will
be
sure
that
it's
not
possible
for
the
attacker
to
advertise,
something
that
looks
better
to
the
AES
is
that
is
more
preferred,
so
it
will
look
roughly
like
this.
We
have
these
two
relay
nodes
they
are
Emmaus.
Is
that
pier
directly
to
each
other
and
there
in
a
sec
at
have
no
customers?
C
However,
we
do
know
that
peering
connections
might
be
revoked,
the
peering
agreement
might
break
or
the
link
might
fail
to
deal.
If
this
happens,
then
our
relay
node
would
be
disconnected
and
that's
bad
for
Sabre,
because
then
we
cannot
guarantee
anything.
The
way
we
deal
with
this
problem
is
that
we
require,
while
we
choose
the
location
of
our
relay
nodes,
that
the
graph
that
the
relay
nodes
would
compose
is
K
connected.
That
means
that
the
attacker
would
need
to
cut
at
least
K
peering
links
to
be
able
to
disconnect
our
relay
Network.
C
Okay.
So,
going
back
to
the
example,
we
would
need
to
add
one
relay
Network,
one
relay
no.
That
will
be
hosted
in
a
yes
that
pier
directly
to
the
AES
is
that
already
have
relay
nodes
as
such.
If
we
lose
one
of
the
links,
we
will
still
be
fine
because
the
relay
network
would
still
be
connected
and
the
last
thing
we
take
into
consideration
while
we
place
a
relay
note,
is
that
we
eliminate
the
chance
that
an
attacker
would
be
able
to
hijack
traffic
from
the
Bitcoin
clients
to
the
relay
nodes.
C
So
we'll
explain
that
with
an
example
it
is
you
may
have.
This
is
topology
and
we
have
two
bitcoin
clients
that
we
want
to
somehow
protect
and
the
way
we
do
and
we're
trying
to
find
the
names
to
host
a
relay
to
protect
those
clients
such
that
there
is
no
attacker
that
can
basically
hijack
traffic
from
the
AES
with
confiance
to
the
relay.
So
let's
assume
we
place
the
relay
there
and
what
happened?
C
What
will
happen
in
this
case
is
that
we'll
have
two
possible
attackers,
so
these
attackers,
for
example,
the
the
middle
the
attacker
that
is
in
the
middle,
would
be
able
to
hijack
the
prefix
of
the
relay
by
advertising
it
to
the
a
SS
with
Bitcoin
clients,
and
those
are
yeses
would
actually
follow
the
attackers
advertisement
because
it's
their
customer.
So
it's
more
preferred
path.
However,
if
we
face
the
same
problem
and
we
place
the
relay
in
V
say
yes,
then
we
would
have
no
attackers.
C
So
this
is
what
we
try
to
leverage
while
we're
placing
our
relay
nodes.
Okay,
I'll,
not
tell
you
how
Sabre
will
help
us
in
the
partition
attack
that
I
described
before.
So,
let's
assume
we
have
this
pinko
in
topology
and
as
we
described.
If
we
have
an
attacker
that
hijacks
traffic-
and
we
not
have
any
countermeasures,
then
the
attacker
will
be
able
to
create
this
partition.
However,
if
we
deploy
Sabre,
then
we
would
actually
have
this
additional
Bitcoin
clients.
C
They
will
be
hosted
emails
that
appear
directly
to
each
other
and
they
will
be
connected
to
the
other
Bitcoin
client
and
if
there
is
an
attack
that
happens
and
if
we
assume
that
the
attacker
even
hijacks
more
so
he
hijacks
even
the
prefixes
of
the
relay
network.
So
you
will
manage
to
cut
some
connections,
but
the
actual
Bitcoin
network
would
still
be
would
still
be
secure
and
connected
because
of
all
the
properties
that
I
described
before
and
now.
C
Let
me
talk
to
you
about
the
second
guarantee
that
we
offer
and
that's
that
Sabre
offers
and
that's
the
special
way
that
we
implement
a
Sabre
nodes
such
that
there
they're
better
with
respect
to
denial
of
service
attacks.
So
they
can.
They
can
remain
open
to
new
connections,
even
if
they
are
under
high
demand
or
even
if
they're,
under
a
DDoS
attack.
So
we
use
a
software
and
hardware
code
design.
C
So
we
have
a
hardware
component
and
software
component
and
the
software
component
is
on
be
responsible
for
validating
the
block
and
for
updating
the
hardware
component.
With
the
new
mind
block,
the
hardware
component
is
actually
programmable
switch,
and
you
might
have
heard
of
this
so
female,
and
these
p4
language
that
we
can
program
program
are
switches
with
and
we're.
Basically,
the
the
Suites
is
now
responsible
for
answering
to
all
the
requests
of
the
Bitcoin
client.
So
in
a
way
you
can
imagine
that
the
Suites
actually
talks
Bitcoin.
C
The
reason
why
we
believe
this
design
is
suitable
for
our
problem
is
twofold,
so
first
it
can
keep
up
with
a
high
demand.
That's
because
the
programmable
hardware
is
supposed
to
be
able
to
keep
up
with
Thera
bits
of
traffic
per
second
and
process
them
at
line
rate,
so
it
can
sustain
large
denial
of
service
attack
and
also
high
demand,
and
the
second
reason
why
I
believe
that
this
design
is
suitable
is
that
it
allows
us.
C
So
the
programmable
hardware
allows
us
to
have
dynamic
network
defenses
in
the
suite,
so,
for
example,
Sabre
nodes
would
have
whitelists
and
blacklists
and
some
spoofing
detection
and
also
some
detection
to
be
able
to
avoid
being
using
as
an
amplifier
as
an
amplifier.
And
now
let
me
tell
you
why
this
code
design
is
is
is
possible
because
that's
not
that
trivial,
as
sweeties
are
not
like
for
everything
they
have
few
computation
that
they
can
do,
and
that's
because
bitcoin
is
a
very
communication
heavy
protocol,
as
opposed
to
computational
heavy
prodigal.
C
C
Okay
and
now
that
I
have
described
the
Sabre
notes,
I
will
go
through
the
life
cycle
of
of
a
block.
So
in
this
slide
you
basically
see
two
Sabre
nodes,
they're
connected
to
each
other,
and
they
are
also
connected
to
the
Bitcoin
client,
some
Bitcoin
clients.
And
now,
let's
assume
that
there
is
this
block
that
is
mined
by
a
Bitcoin
client.
This
Bitcoin
client
would
notify
the
switz
about
this
new
block.
The
switch
will
realize
that
this
is
a
new
block
in
the
blockchain.
It
doesn't
know
about
it
and
will
notify
the
controller.
C
The
controller
will
be
now
responsible
to
validate
the
block
so
to
check
whether
this
block
is
correct.
If
the
block
is
valid,
the
controller
will
update
the
cast
in
the
switch
such
that
the
suite
is
now
able
to
answer
to
all
the
clients
that
will
request
for
the
block.
So
the
suite
is
now
responsible
for
basically
propagating
this
to
the
other
Bitcoin
clients
and
to
the
other
Sabre
nodes,
and
with
this
I
finished
my
talk,
if
you
were
to
remember
one
thing
from
it,
it
would
be.
C
It
should
be
that
Bitcoin
is
vulnerable
against
routing
attacks
from
both
the
network
and
the
node
level.
The
potential
impact
of
of
of
these
attacks
in
the
currency
are
warring
because
they
can
they're
an
effective
mal
of
service
attack.
They
can
they
allow
double
spending
and
also
they
can
cause
lost
revenue
and,
finally,
countermeasures
exist
with
secure
routing
protocols
being
the
best
and
saver
being
a
good
alternative.
Thank
you
and
happy
to
take
questions.
D
So
so
say
your
name
when
you
give
your
question:
hi,
I'm,
Cathy,
Aronson
I
think
it's
pretty
somewhat
unlikely
that
an
a
s
would
have
no
customers,
but
you
could
also
use
an
a
s
that
perhaps
does
what
the
BCP
says
and
filters
what
its
clients
announce
to
it.
Then
you
would
have
the
same.
You
know
because
I
guess
not
necessarily
having
customers
as
anyway,
but
if
they
filter
what
their
customers
advertise
to
them,
then
their
customers
can't
advertise
something
that
is
that
doesn't
belong
to
them
like
one.
C
Answer
to
this
is
basically
that,
by
having
direct
peer
connections,
we
also
avoid
the
passive
attackers
that
are
in
the
middle,
and
what
we
also
need
to
think
about
is
that,
yes,
we
might
find
it's
that's
very
good
and
actually
that's
very
good
to
like
create
an
incentive
for
for
a
piece
to
actually
filter.
But
you
have
to
take
into
consideration
that
we
need
to
find
those
locations
such
that
they
are
also
close
to
the
Bitcoin
clients.
C
E
E
C
E
According
to
the
regular
peering
connections,
if
you
have
traffic
go
that
goes
not
through
IP
address
offer
early
three,
but
goes
directly
from
related
to
an
earlier
one.
They
will
send
it.
They
will
send
traffic
through
upstream
providers,
because
if
we
were
speaking
about
peering
connections,
peering
connections,
exchanging
routes
that
belong
to
themselves,
and
so
their
customer
call
here,
you
don't
have
customer
call
so
early.
One
in
n2
will
not
exchange
prefixes
that
belong
to
early
three.
Otherwise,
it's
a
root
leak.
G
C
C
There's
no
directly
connected,
so
if
the
link
is
broken,
then
I'm
not
using
this
link
at
all,
so
I
will
not
try
to
transfer
information
from
Leon
to
relay
2,
and
this
is
why
I
need
the
relay
Network
to
be
always
connected,
because
I
have
an
alternative
route
that
is
composed
of
direct
peering
links
between
among
the
relay
nodes.
So.
E
C
E
E
H
Bitcoin
is
an
attack
on
our
planet.
It's
an
attack
on
I,
financial
infrastructure
and
I.
Don't
want
to
see
people
improving,
Bitcoin
I
want
to
see
better
attacks,
absolutely
serious,
better
attacks
on
Bitcoin,
the
sooner
we
sink
it,
the
better
think
of
the
planet,
I'm
absolutely
serious.
Here
we
have
an
abomination
that
is
using
a
vast
amount
of
electricity
to
transfer
an
infinitesimal
amount
of
money.
It
is
convincing
people
that
they're
making
money
in
their
basement
and
it
isn't.
Of
course
it's
got
trillions
of
dollars.
H
C
I
want
to
add
two
things
in
there,
so
first
the
work
is
about
attacks
in
Bitcoin,
so
you
would
be
happy,
but
this
ain't,
like
I,
will
only
talk
about
environmental
part
and
I
want
to
let
you
know
that
there
are
actually
data
centers
in
San
Jose
that
are
using
more
they're
using
actual
water
for
cooling.
The
data
center
and
they're
using
more
water
than
people
can
use
in
San
Jose.
C
C
I
C
First
I
want
to
let
you
know
that
there
already
are
already
relay
nodes
that
everyone
can,
like.
Everyone
can
connect
to,
and
they're
mostly
they're,
mostly
maintained
by
academics
or
they're
supported
by
academics.
But
our
intuition
is
that
it
would
be
very
nice
if
an
ISP
would
deploy
it,
because
it
would
prove
that
it
is
in
such
connection
in
the
such
position
in
the
internet
that
it
can
actually
help
Bitcoin,
so
I
believe
that
would
be
kind
of
an
advertisement
class.
C
If
we
implement
it
using
these
program,
all
sweetsies
most
likely,
they
will
already
have
this
there,
so
they
will
already
have
the
suite
they
can
have
the
Suites
and
use
it
for
other
purposes
and
then
adding
just
a
relay.
Node
is
not
too
much,
but
I
get
your
concern
that
this
is
problematical
in
video
and.
I
C
I
C
I
I
wasn't
clear:
no,
that's!
Actually
not
what
I
was
asking
about
so
I
think
the
Bitcoin
network,
the
model
of
how
it's
working
to
work
in
the
future
is
changing
so,
but
there's
scaling
problems
with
the
current
network
and
approach
the
taking
to
work
on
this
is
that
when
you
do
a
transaction,
it's
not
necessarily
going
to
be
broadcast
across
the
whole
network
right
away,
you'll
be
working
within
limited
domains,
one
small
number
of
lightning
nodes
and
then
at
some
point
those
will
go
across
all
Network
it.
I
C
Want
to
focus
on
one
thing
of
what
you
said,
so
you
said
that
at
some
point
beat
every
10
minutes
or
beat
every
whatever
time
they
will
need
to
exchange
what
they
have
done.
Otherwise
there
it's
not
possible
to
have
consensus
among
the
Bitcoin
clients
right.
So
when
this
happened,
if
network
is
partitioned,
it
would
not
be
possible.
So
this
applies
I'm.
I
I
J
C
C
J
C
But
every
time
you're
in
an
a
s-
and
you
want
to
know
you're
a-
is
path
to
another.
You
can
always
use
a
trace
road,
and
it's
just
that.
It
would
require
like
more
time
if
we
were
to
start
trace
routes
from
everywhere,
instead
of
actually
using
the
kinda
topology.
But
to
answer
to
your
question:
if
the
system
was
in
place,
there
should
be
also
trace
route
to
check
whether,
for
example,
there
changes
in
the
paths
or
but
sets
that
we
keep
track
with
whatever
happens
in
the
in
the
path
between
the
relays.
F
High
Steward
card
clinical
technology's
first
time
face
to
face
IETF,
participant
and
involved
in
the
activities
online
for
many
years.
First,
a
quick
comment:
I
I,
have
been
absolutely
astonished
in
the
past
few
days
at
the
paucity
of
discussion
here
at
IETF
about
the
potential
interactions
between
not
just
Bitcoin
but
the
broader
blockchain
and
broader
cryptocurrency,
which
should
not
be
equated
with
each
other
research
communities
and
and
and
so
on.
F
With
with
IETF
activities,
I've
been
wandering
from
working
group
meeting
to
working
group
meeting
looking
at
important
problems
that
have
been
studied
for
many
years
to
some
of
which
there
are
obvious
approaches
involving
the
use
of
either
blockchain
and/or
cryptocurrency
technology
to
address
them.
So
I
guess
I
would
like
to
ask
you
a
kind
of
a
broad
question,
considering
especially
that
that
things
like
the
the
Bitcoin
energy
cost
are
are
well
known
within
that
community
and
are
attempting
to
be
addressed
with
proof
of
stake
and
other
approaches.
F
Do
you
have
any
ideas
for
broad
areas
of
research
in
the
intersection
between
cryptocurrency
and
blockchain
technologies
and
IHF
technologies,
where
we
might
invert
the
relationship
rather
than
regarding
Bitcoin,
is
merely
an
application
of
our
network
regarding
cryptocurrency
and
blockchain
technologies
as
potential
enablers
of
our
network.
So.
A
Maybe
that
I
might
have
a
better
ability
to
answer
that
so,
sir,
we
we
actually
have
this
dinner
G,
which
is
the
home
for
this
kind
of
research
Friday
afternoon.
So
it's
just
that
even
wandering
Friday
morning,
you've
been
wandering
too
early,
but
I
think
we're
aware
and
that's
one
of
the
reasons
this
paper
was
so
interesting
to
us
is
because
there
there
are
tremendous
interactions
and
we
just
we.
You
know,
there's
communities
that
need
to
intersect
for
so
sort
of
the
place
where
we're
hoping
that
intersection
will
flower,
especially.
C
L
Hi
I'm
Jill
Malhotra
from
Boston
University
I
have
a
question
on
the
countermeasure
that
you
said
for
delay
attacks.
Are
you
mentioned
encryption
and
Mac
as
the
potential
solutions
I
was
wondering
how
does
that
help
against
a
man-in-the-middle
the
delay
attacks?
How
does
encryption
or
Mac
or
defend
against
a
man
in
the
middle
who
can
drop
the
packets.
C
So
if
the
packet
is
dropped,
the
difference
is
that
in
this
case
we
will
then
the
Bitcoin
client
will
notice
and
will
request
the
block
from
another
peer.
The
problem
is
that
the
node
actually
thinks
that
everything
is
working
properly
because
it
doesn't
have
it.
The
connection
is
not
lost
so
like
when
I
was
describing.
The
attack.
I
said
that
the
attacker
can
drop
the
key
data
message
or
drop
the
block
itself,
but
this
will
will
make
TCP.
C
Basically
disconnect
will
abort,
so
the
the
Bitcoin
client
will
actually
notice
that
I'll
find
it
so
here,
if,
instead
of
modifying
the
message
the
attacker
drops
to
get
data
or
the
block
itself,
then
in
TCP
will
keep
the
sequence
numbers
and
will
not
be
able
to
continue.
So
it
would
reset
the
connection
or
it
will
disconnect.
Does
that
make
sense
or
was
that
what
you
are.
L
C
Maybe
but
sure
dropping
dropping
is
a
problem
and
it's
what
will
be
used
for
a
partition
attack,
but
but
the
key
in
this
particular
in
the
delay
attack
is
that
it's
very
invisible.
So
it's
not
possible
for
the
node
to
actually
understand
that
it's
under
attack,
but
you're
perfectly
right
that,
even
if
the
traffic
is
encrypted,
it
can
be
dropped,
and
so
the
network
can
be
partitioned.
This
is
why
we
consider
encryption
as
a
solution
to
the
delay,
but
not
to
the
partition
attack.
M
Hello
being
from
Hawaii,
my
question
is
that
are
the
attacks
and
the
countermeasures
specific
to
critical
currents,
networks
or
it
is
they
are
general
to
any
peer-to-peer
networks.
I
mean
you
know.
The
delay
attack
is
specific
to
Bitcoin.
I.
Think
I
think
he
theorem
is
not
vulnerable
to
the
delay
attacker,
but
for
the
petitioning
attack
I
think
it
is
general
to
any
peer-to-peer
network.
So
how
about
the
collimator
is
the
columellar
general
to
all
the
peer-to-peer
network
so.
C
I
do
believe
that
at
least
the
cryptocurrencies
would
be
success
would
be
vulnerable
to
a
partition
attack.
What
I
know
about
Bitcoin
that
might
be
different
to
other
cryptocurrencies.
That
is
more
centralized,
so
it
would
be
easier
for
an
attacker
to
hijack
this
traffic,
but
you're
perfectly
right
on
any
peer-to-peer
network
would
not
be
able
to
function.
If
you
basically
split
the
network
to
have.
M
I
mean
there's
a
lot.
There
are
a
lot
of
peer-to-peer
networks,
including
poor,
and
the
current
cursory
cover
currency
networks,
so
I
mean
is
your
countermeasure
to
the
to
the
crypto
kurtal
currency
network
still
applicable
to
the
general
peer-to-peer
network?
Can
your
connemara
protected
all
the
dirty
networks.
C
So
if
we
assume
that
we
study
all
the
partition
attacks
in
all
the
net
works
that
you
describe,
then,
yes,
we
can
imagine
that
we
can
have
a
really
network
for
all,
but,
like
I,
cannot
comment
on
so
I
do
believe
that
it's
a
general
approach
that
you
want
to
build
a
really
network
to
help
a
peer-to-peer
network.
But
I
cannot
comment
on
whether
first
of
all,
that's
an
attack
would
be
feasible
in
something
else.
Whether
somebody
would
be
interesting
for
interested,
for
example,
to
split
the
Tor
relays
using
high
tech.
C
M
N
I'm
Jim
Fenton,
one
of
the
characteristics
of
Bitcoin
network
that
I
think
the
bitcoiners
take
a
lot
of
pride
in
and
sort
of
consider
as
a
as
a
kind
of
fundamental
thing
is
the
egalitarian
peer-to-peer
nature
of
their
nodes
and
I'm
wondering
if
you've
gotten
any
feedback
from
that
community
about
Sabre,
because
it
that's
a
situation
where
now
you're
starting
to
create
the
beginnings
of
a
hierarchy.
Not
all
nodes
are
safer
nodes
and
they
don't
have
all
all
have
the
same.
You
know
are
the
Sabre
nodes
considered,
perhaps
a
point
of
control?
C
First,
no,
this
is
not
work
that
it
has
been
published
yet
I
want
to
say
two
things,
though:
first
they're
already
relaying
networks
out
there
and
they're,
like
basically
used
for
a
different
reason
to
improve
the
performance
of
the
Bitcoin
network.
So
you
can't
you
can
assume
that
you
have
the
same
property
there,
that
there
are
some
nodes
that
are
connected
to
them,
and
maybe
we
were
kind
of
better
to
them.
C
However,
what
I
want
to
point
out
is
that
we
envision
a
network
that
would
be
open
to
everyone
and
will
not
be
controlled
in
a
way
that
can
do
something
about
it,
a
Bitcoin,
because
even
if
it
was
controlled,
it
doesn't
the
Bitcoin
clients
would
still
have
their
connections
to
each
other,
so
it
acts
on
top
of
that
and,
as
such,
it
doesn't
have
the
power
to
do
something
against
them.
I
believe,
thank
you.
Okay.
Well,
thank
the
speaker.
A
A
A
P
P
I'll
be
telling
you
about
some
of
the
work
we
have
been
doing
on
week.
Euler
communication
systems
and
their
security
ie
I
have
quite
a
lot
of
material
in
these
slides.
The
major
part
is
about
the
paper,
but
then
I
also
have
some,
let's
say,
extensions
or
closely
related
areas
of
research,
so
that
we
can
expand
a
little
bit
asphere
of
the
discussion.
So
I
think.
Maybe
you
need
some
sort
of
it's.
B
P
So
yeah
I'll
stay
within
the
circles.
A
bit
say
article,
it
was
a
drawn
with
a
piece
of
chalk
would
be
even
more
spectacular.
So
the
idea
is
we.
We
are
concerned
with
this
emerging
type
of
systems,
vqr
communication
systems.
The
idea
is
that
you
add
additional
processing,
power
and
communication
capabilities
on
those
vehicles
which
already
have
tons
of
computers
on
boards,
so
that
essentially
by
providing
this
vehicle
to
vehicle
or
vehicle
to
in
roadside
infrastructure
communication.
P
Essentially,
you
enhance
transportation,
safety
and
transportation
efficiency,
so
these
yellow
arcs,
you
see
this
is
vehicle
to
vehicle
communication
and
then
there's
a
an
arc
with
element
node
on
a
lamp
posts.
Centrally
you
extend
the
horizon
of
the
driver
and
either
you
use
this
to
advise
or
warn
the
driver
so
that
she
takes
the
action,
say:
brake
hit
the
brake
or
you
can
envision
this
system
supporting
autonomous
driving
down
the
road.
Now
we
are
concerned
with
security
and
privacy.
So
let
me
take
a
simple.
P
Let
me
take
a
simple
example
here:
let's
say
that
exactly
this,
this
notion
of
extending
the
horizon,
where
the
driver
is
applied
to
warning
about
an
approaching
ambulance.
You
could
have
an
application
that
your
car
connects
these
collects
these
these
messages
and
lets.
You
know
exactly
where
the
ambulance
is
coming
from,
rather
than
you
trying
to
figure
out
where
the
siren
is
sounding
from
and
so
on
so
forth.
P
So
what
you
do
is
it
you
yield,
and
then
you
let
the
ambulance
go
through,
but
you
could
imagine
in
the
near
future,
someone
buying
basically
a
hacked
version
of
this
application
that
essentially
transformed
his
car
into
an
ambulance,
and
then
everyone
else
yields
and
he
goes
to
to
work
or
to
wherever
faster
than
everyone
else.
So
that's
a
motivating
example,
but
essentially
there
could
be
even
more
dire
consequences.
P
So
you
need
some
sort
of
anonymity
and
the
consensus
is
to
go
with
conditional
and
unlimited
meaning
that
you
are
naanum
eyes.
Nonetheless,
you
keep
somewhere
the
long-term
Murial
identity
of
the
entities
involved,
so
that,
should
there
be
some
sort
of
accident
or
some
emergency,
you
can
pull
it
out
and
then
you
need
some
sort
of
funneling
capability,
meaning
if
you're
communicating
frequently
you
don't
want
these
communications
to
be
trivially
linked
to
each
other,
because
that
could
lead
to
some
sort
of
DN
Animas
ation.
P
In
the
end
now
there
has
been
some
effort
in
this
in
this
direction
and
there's
even
developing
standards.
Now,
what
are
the
the
underlying
ideas-
and
we
have
been
involved
in
this
since
the
very
birth
of
of
the
area?
So
what's
the
simple
idea
here
and
I'm
taking
one
type
of
application,
what
is
called
the
co-operative
awareness
messages
for
safety,
because
those
that
basically
let
your
car
tell
other
cars,
how
it's
moving
so
that
basically
can
adjust
and
and
warn
the
drivers
and,
let's
take
the
very
simple
way
of
providing
security.
P
Essentially,
you
have
a
digital
signature
and
your
thoughts
a
certificate,
and
then
everyone
can
validate
your
message,
no
matter
what
has
been
any
prior
association
or
knowledge,
which
clearly
is
not
something
you
expect
in
a
in
a
highway
or
in
any
in
any
road
setting.
Nonetheless,
every
time
that
you
digitally
sign
a
message
and
these
messages
they
come
very
frequently.
Typically
transportation
engineering
says
that
you
need
to
transmit
up
to
then
or
even
in
some
occasions,
even
more
than
than
10
per
second.
P
Why?
Because
it's
also
easier
for
transportation
safety
applications,
for
example,
of
collision
avoidance
notifications
to
basically
function
in
this
way.
There
is,
of
course,
the
we
are,
the
next
step
to
blend
anonymous,
authentication
and
public
public
key
cryptography
so
that
you
can
generate
on-the-fly,
say
credentials,
but
I
won't
have
time
to
go
into
that.
It's
also
not
part
of
the
what
is
being
standardized
now.
How
do
these
boxes
look
like
I
mean
on
the
on
the
Left
hands
on
there?
P
Just
the
device
is
out
on
a
table
there.
That
I
show
you
now
who
provides
these
credentials
that
I
have
been
talking
about.
The
short
leaves
anonymize
credentials
that
we
call
pseudonyms.
Well,
there
is
a
public
key
infrastructure
behind,
and
in
this
case
there
is
a
set
of
entities,
and
here
I
show
you
domains.
Essentially,
that
could
be
a
state,
a
city
or
even
a
car
manufacturer
that
provides
credentials
for
all
vehicles
registers
in
that
domain,
and
there
is
a
split.
P
There
is
one
entity,
the
long
term
certification
authority
which
basically
keeps
track
of
the
long
term
identities
of
the
vehicles
and
provides
the
corresponding
certificates
or
certificates.
There's
one,
and
there
is
one
registration
of
per
vehicle
with
one
long
term
certification,
Authority,
and
there
could
be
one
or
more
pseudonym
or
certification
authorities,
those
that
provide
the
short
term
anonymize
credentials,
and
the
idea
is
exactly
that.
The
vehicle
runs
and
authenticates
all
communications
with
a
short-term,
the
ephemeral
credentials,
the
pseudonyms.
Why?
P
Because,
if
it
used
a
long
term
one,
then
it
will
be
trivially
linked
and
privacy
would
be
lost,
and
this
slide
basically
says
with
texts
what
I
just
mentioned
before.
It
also
says
that
that
you
can
establish
trust
between
different
domains
in
different
ways,
with
cross
certification
with
some
higher
level
certification
authorities.
And
should
you
really
need
to
revoke
the
anonymity
of
the
involved
vehicles,
then
you
need
to
have
another
authority
that
has
the
necessary.
Let's
say
circumstance.
Is
this
necessary
authority
to
basically
request
for
for
that
information?
P
Otherwise,
this
information
is
essentially
split
into
the
two
entities:
their
long-term
certification
authority
on
the
pseudonym
certification
authority.
Now
talking
about
security
and
privacy,
of
course
the
problem
is
more
general.
Now
I
will
gradually
say
focus
on
exactly
what
we
looked
at
in
this
paper.
P
There
could
be
malicious,
behavior,
they're
on
board
units.
The
boxes
I
showed
you
earlier.
They
could
basically
hacked
by
anyone
either
remotely,
as
we
have
seen
in
the
news.
Let's
say
the
the
current
counterparts
of
those
of
those
systems
or
one
could
basically
out
there.
The
functionality
of
this
or
one
could
even
modify
sensors
from
board.
Let's
say
other
controllers
on
the
cars
to
feed
wrong
information
to
those
to
those
machines.
P
One
could
also
envision
the
possibility
that
you
have
a
compromised
vehicle,
but
then
you
try
to
make
it
look
like,
as
if
you
had
ten
vehicles
or
twenty
or
a
hundred
or
a
thousand
right.
Why?
Because
there
could
be
all
sorts
of
applications
where,
if
you
could
pose
as
multiple
vehicles
providing
data
responses
to
those
applications,
then
you
could
dominate
the
outcome
of
the
protocol.
Whatever
is
the
protocol
or
the
application
you
are
running.
For
example,
you
could
fake
that
there's
a
traffic
jam.
P
To
put
it
very
simply,
and
of
course
you
could
have
collusion
between
these
these
adversaries,
and
now
we
are
moving.
Let's
say
we're
pushing
the
envelope
one
step
further.
We
are
thinking
of
the
security
infrastructure,
the
certification
authorities
right
what
if
they
are
not
fully
trustworthy,
what,
if
they're
honest
but
curious?
P
How
would
it
look
like
if
we
were
to
to
zoom
a
little
bin
a
little
a
little
more
in
zoom
remain
in
the
system?
Well,
let's
look
at
two
domains
here
on
pick
one,
let's
say
the
home
domain,
where
you
have
the
home
LTC
a
and
then
the
car
essentially
now
submits
the
requests
to
obtain
a
tickets
that
will
allow
it
to
address
that
we
provided
to
any
PCA
and
obtain
credentials.
P
What's
the
the
trains
in
a
system
that
probably
reminds
a
little
bit
of
Kerberos
is
that
we
won't
actually
to
disconnect
or
hide
information
from
the
LTC
a
regarding
which
PCA
the
vehicle
is
going
to
obtain
the
credentials
from.
We
also
want
to
hide
the
period
for
which
it
requests
credentials,
because
these
is
these
are
sensitive
pieces
of
information
and
they
could
allow
an
honest
but
curious,
LTC
a
to
track
the
vehicle
in
its
activities.
P
If,
of
course,
the
LTC,
a
the
curiosity
CA,
the
curious
PCA
also
had
transcripts,
meaning
logs
of
messages
that
the
vehicle
transmitted
while
it
it
moved
around
with
that
with
that
latter
be
difficult.
No,
because
all
you
need
is
some
sort
of
variant
of
a
dot
11
for
this
vehicle
to
vehicle
communication,
and
you
can
record
all
such
traffic
easy
or
you
can
rely
on
other
vehicles
that
interacts
with
whoever
you
want
to
track
to
obtain
this
information,
and
you
can
extend
this
design
in
multiple
domain.
P
So
essentially,
when
you
move
in
a
region
where
another
domain
is
predominantly
present,
then
you
don't
want
to
stand
out.
You
don't
want
to
be
the
only
one
that
has
credentials
from
your
home
domain,
so
you
request
I,
take
it
that
will
allow
you
to
address
one
of
the
local
pcs
and
obtain
credentials
like
the
ones
that
everyone
else
in
the
other
main
house.
P
So
you
don't
want
to
be
like
a
fly
that
fell
in
a
glass
of
milk
right
these
credentials
as
you
as
you
obtain
them
essentially
could
be
seen
as
some
sort
of
fuel
right
so
you're
all
you
need
to
be
authenticating
all
traffic.
You
need
to
be
using
all
these
ephemeral
credentials
and
the
question
is:
how
do
you
get
them?
Can
you
get
them
for
the
eight
years
of
the
lifetime
of
your
vehicle?
P
That
would
be
extremely
expensive
and
we
already
had
some
I'd
say
good
argument
about
spending
too
much
energy
about
all
sorts
of
computations.
And,
of
course
this
is.
This
is
less
less
severe.
So
we
advocate
some
sort
of
on
demand,
that's
acquisition
of
of
credentials,
and
there
are
different
policies.
You
can
basically
know
how
long
you're
going
to
drive,
or
you
can
do
your
best
guess
and
get
for
a
period
and
then
before
you
run
out
of
credentials,
you
get
a
few
more
and
so
on
so
forth.
P
There
is
one
problem
with
this:
the
times
of
requesting
these
credentials
and
the
lifetime
so
actually
could
be
some
sort
of
fingerprint
someone
is
observing
or
even
the
PCA
is
themselves.
This
curious
authorities
could
basically
be
using
just
timing
information
to
basically
track
a
given
vehicle
right.
P
So
the
proposal
here
is
to
essentially
get
everyone
talking
to
a
PCA
to
be
aligned
according
to
the
clock
of
that
PCA
and
essentially
get
I,
don't
know,
yeah,
it's
contentious
with
lifetimes
that
are
identically
aligned
the
same
way
as
they
are
for
everyone
else,
and
then
this
makes
the
unanimity
set
equal
to
the
number
of
vehicles
registered
with
that
that
PCA.
Now?
P
What
is
this
paper
doing?
Essentially,
it's
basically
defining
the
all
the
protocols
of
the
vehicle
to
the
VPI
or
intra
VIP
I
interactions
it
implements
and
basically
evaluates
and
analyzes
how
well
they
perform
what's
the
end
goal.
The
end
goal
is
to
basically
figure
out
whether
this
is
doable,
whether
this
is
practical
given
what
we
have
in
our
hands
and
whether
this
could
be
an
impediment
for
four
deployments.
So
I
will
quickly
go
through
these
protocols.
I
already
gave
the
gist
of
how
it
works,
but
let's
let's
try
and
I
would
just
pink.
P
You
know
pinpoint
a
couple
of
interesting
technical
points
in
each
of
them,
so
here
you
see
basically
the
interaction
of
the
vehicle
v
with
a
long-term
certification
Authority,
it
requests
a
ticket.
It's
a
service
granting
tickets
in
Kerberos
parlance,
and
you
see
there
that
the
identity
of
the
PCA
is
going
to
I.
P
N
P
Of
okay
up
here,
the
identity
of
the
PCA
is
going
to
to
obtain
the
credentials
from
is
hidden
now
from
the
LTC
a
now
the
less
than
then
it
obtains
the
this
anonymize.
The
ticket
digitally
signed
by
the
LTC,
a
which
it
presents
to
the
PCA
at
the
bottom
part
of
this
figure,
along
with
a
number
of
certificate,
signing
request,
switch,
are
centrally
the
requests
to
get
certified.
Those
anonymized
public
keys,
pseudonyms
the
LTC,
a
grants,
the
service.
P
If
the
ticket
is
valid,
and
then
you
see
that
in
the
original
requests
for
the
ticket,
the
the
period
for
which
the
credentials
are
requested
is
given
with
twist
to
values,
T
sub
e
or
T
sub
s,
while
when
the
vehicle
requests
the
actual
credentials
on
the
PCA,
these
values
are
actually
different.
They
are
within
the
broader
requested
interval.
So
this
is
basically
hiding
the
the
the
information
of
when
these
credentials
are
to
be
used
exactly
right.
P
Now
this
is
a
pseudo
code,
but
we
want
we
don't
even
bother.
What
one
point
to
make
here
is
that
there
is
a
binding
during
this
process
between
the
ticket
and
the
issue,
the
credentials.
Why?
Because
this
will
be
later
necessary
for
the
resolution
of
the
certificates
that
were
the
off
of
the
pseudonyms?
P
Well,
the
same
okay:
this
is
the
second
part
of
that.
This
is
the
other
protocol.
So
essentially
here
you
have
a
binding
off
the
long-term
certificate
for
the
vehicle
to
the
ticket
and
the
same
there's
different
binding
between
the
ticket
and
the
and
the
pseudonyms
to
come
afterwards
for
the
resolution
purposes,
one
could
look
exactly
the
same
type
of
functionality
once
you
move
to
a
new
for
to
a
new
domain,
a
foreign
domain.
First,
you
have
to
figure
out.
P
What's
the
how
to
say
this
is
their
authority,
the
certification
authority,
to
address
within
that
new
domain,
this
foreign
LTC
a
and
then
or-
and
this
is
true
also
for
your
home
LTC-
let's
say
you're
a
vehicle
that
is
is
moving
around
or
for
the
PCAs.
You
need
to
know
where
of
these
certification
authorities
and
then
the
idea
is
that
you
first
request
a
ticket
from
your
home,
LT
CA.
That
will
allow
you
to
address
a
foreign,
LT,
CA
and
then
again
repeat
the
process.
P
Once
you
get
a
ticket
now
you
can
address
one
of
the
PCAs
which
have
a
trust
association
with
that
foreign
LT
CA
and
get
your
pseudonyms
like
everyone
else
in
that
domain.
I'll
skip
the
slide
about
the
revocation
and
the
resolution
I
already
mentioned
it.
So
this
is
a
summary
of
why
things
work
the
way
I
I
promise,
so
when,
rather
than
going
through,
this
you're
welcome
to
look
at
the
paper,
and
let
me
know
your
thoughts
about
this
now.
P
Let
me
say
a
few
things
about
the
experimental
evaluation,
and
so
we
have
a
testbed
which
pretty
modest,
if
you
think
about
how
each
of
those
PCA
or
a
DCA-
and
it
is-
and
we
want
to
basically
see
how
they
would
behave,
should
they
face
a
realistic
workloads.
Now,
how
do
you
get
such
a
realistic
workload?
Unfortunately,
we
don't
have
a
vehicle
to
vehicle
or
vehicle
to
infrastructure
system
deployed
out
there.
So
what
we
do
is
that
we
take
mobility.
Traces
from
two
data
sets.
One
is
the
whole
country
of
luxembourg.
P
That's
not
such
a
big
country,
but
that's
where
we
have
available
traces
from
and
then
the
other
one
is
from
a
city
in
germany
and
we
have
different
policies
and
essentially
we
emulate
how
these
vehicles
basically
would
interact
with
the
vb
ki.
And
then
we
run
the
the
vehicle
functionality
on
a
virtual
machine
and
the
PCA,
the
the
VP
ki
infrastructure
and
a
set
of
virtual
machines,
and
we
basically
measure
how
this
performs.
P
Essentially,
we
stress
the
VP
ki
in
order
to
see
whether,
even
with
these
modest
resources,
it
can
again
do
the
the
word-
and
here
you
see,
four
different
policies.
What
are
on
the
y-axis,
the
average
delays
to
obtain
credentials
for
the
two
data
sets,
and
you
see
different,
of
course,
behavior,
because
there
is
dependence
on
on
the
actual
system,
the
actual
mobility,
the
number
of
vehicles.
You
have,
the
duration
of
the
trip,
the
parameters
of
the
policies
and
so
on
so
forth.
P
But
the
bottom
line
here
is
that
if
you
see
these
three
last
bullets
down
here,
you
see
that
the
likelihood
that
the
delay
to
obtain
your
credentials
is
larger.
Run
that
given
value,
which
is
let's
say,
hundred
sixty
seven
milliseconds
or
80
milliseconds
or
74
milliseconds,
or
no
the
probability
that
the
delay
is
below
that
that
value
is,
is
99
percent.
P
So
this
means
that
in
all
likelihood
you
will
get
your
credentials
within
a
very
short
delay
and
if
you
were
to
make
the
the
setup
a
little
less
stressful
for
for
the
VP
ki,
if
you
were
to,
for
example,
requests
pseudonyms
with
a
longer
lifetime,
and
let
me
remind
you
the
the
short
of
the
lifetime,
the
shorter
the
period
for
which
you
are
temporarily
linkable,
thus
the
higher
the
privacy
protection.
Then
you
see
that
in
the
end,
this
is
delay
flattens
out
really
fast.
So
and
then
the
difference
is
not
is
not
huge.
P
If
you
were
to
look
now
how
you
how
well
you
utilize
these
credentials,
well
different
policies.
These
are
all
on
demand
and
they
all
perform
well.
So
we
can
basically
confirm
this
from
from
this
figure
and
if
you
wanted
to
see
which
of
the
two
part
of
the
functionality
is
more
expensive.
Clearly,
the
ticket
revision
is
extremely
fast.
P
In
order
to
resolve
a
pseudonym,
meaning
figure
out
what
was
the
long-term
identity
behind
one
or
more
of
a
temporary
identities,
temporary
certificates
and
public
keys
and
the
corresponding
private
keys
with
which
designs
and
essentially
revoke
evicts
the
entity
from
the
system
which
can
be
removal
of
the
the
the
short-term
credentials.
But
it
could
also
be
a
revocation
at
the
level
of
the
LTC
a
so
when
you
request
next
time
tickets
to
obtain
credentials
and
the
LTC,
a
can
also
say
say
no,
some
comparison
here
with
respect
to
say
various
implementations
are
out
there.
P
P
The
point
is
that
essentially,
even
though
in
the
community,
it
has
been
considered
the
major
impediments,
a
very
difficult
problem
to
address,
there
were
many
questions
about
whether
it
would
be
you
know,
practical
deployable
or
not
or
too
expensive.
We
figured
out
that
even
more
distort
stations
running
the
the
PCA
in
the
LTC.
A
servers
can
handle
tens
of
thousands
of
vehicles
through
typical
workloads,
even
if
you
have
a
relatively
high
level
degrees
of
privacy,
meaning
you
are
partially
linkable
for
30
seconds
at
the
time.
P
P
You
can
use
such
a
system
in
a
different
context
if
you
want
to
protect
privacy
in
a
location-based
service
context
and,
of
course,
secure
this
functionality,
and
there
are
common
ideas,
but
with
more
freedom.
If
you
wish
to
apply
them
exactly
because
there
is
no
standardization
effort
ongoing
in
other
large
scale,
mobile
systems,
for
example,
a
participatory
sensing
systems.
How
much
more
time
do
I
have
well.
O
E
A
K
P
P
The
network
delays
here
exactly
because
they
could
vote
it
depending
on
where
the
vehicle
is
and
how
the
vehicle
is
connecting
to
the
VP.
Ki
are
basically
dwarfed
in
these
measurements,
and
this
was
on
purpose
because
you
could
be
connecting
to
the
the
VP
ki
through
a
roadside
unit,
and
then
you
are
subject
to
all
congestion
that
this
is
facing.
You
might
have
a
special
deal
with
your
telecom
provider
and
you
have
a
4G
network
and
so
on
so
forth,
or
you
might
be
in
your
garage
in
your
home
network
running.
P
P
Actually,
ok,
it's
interesting
that
you
you
mention
this
because
for
for
many
years
and
actually
the
the
project
I
mentioned
there
here,
the
need
for
an
HSM
or
hardware
security
module
has
been,
let's
say,
strong
on
the
vehicle
side
actually
and
in
in
the
the
project
I
mentioned
earlier.
This
preserve,
essentially,
actually
we
had
the
an
ASIC.
P
It
wasn't.
You
know
the
best
AC
you
could
possibly
think,
but
at
least
for
the
vehicle
exactly
because
there
you
have
stringent
clip
the
processing
requirements,
your
you
have
to
validate,
let's
say
hundreds
or
thousands
of
signatures
per
second,
unlike
the
loads
that
you
are
dealing
with
here,
which
are
several
interactions
per
several
minutes,
let's
say
and
so
on
so
forth
right
and
we
have
a
an
ASIC
that
can
do
up
to
approaching
from
below
thousand
signature
verifications
per
per
second
right.
K
This
is
not
I
would
suggest
to
look
into
two
things.
The
first
one
is
Asics,
are
usually
almost
impossible
to
certify.
According
to
you
know,
standards
because
the
protection
of
private
keys,
but
for
the
vehicle,
probably
you
know
you,
can
you
can
go
around
that
on
the
server
side,
I
would
suggest
to
look
into
bursts
of
requests.
You
know
because
that's
where
problems
arise,
if
you
don't
have
capacity,
the
delay
becomes
unacceptable
and
you
might
go
into
problems
there.
Well,
yeah,
excellent
thanks.
Very
much
for
the
suggestion
is.
Q
P
So,
for
for
for
the
hardware
security
module,
for
example,
you
have
a
real
time
clock
which
you
have
to
basically
synchronize
with
an
external
source
right
one
easy
way
to
go
about.
It
is
to
rely
on
GPS
or
Galileo
right
for
obtaining
time.
Of
course,
there
is
a
set
of
constraints
there.
Whether
someone
could
try
to
spoof
your
your
GPS
signal.
P
So
for
so
we
have
a
different
part
of
our
work
for
for
several
years,
actually
dealing
with
securing
the
the
positioning
and
the
time
synchronization
for
for
GNSS
in
general,
for
for
the
servers,
I
suppose
was,
we
can
think
of
is
let's
say
NTP
with
the
security
say
add-ons
that
one
can
think
of
right,
secure
protocol
right,
but,
for
example,
its
take.
So,
let's
think
of
what
would
happen
here.
Should
you
let's
say
suit?
P
Your
clock
is
slightly
not
in
sync
with
the
clock
of
the
PC
a
right,
so
you
appear
and
you
request
a
bunch
of
certificates.
Who's
now
lifetime
will
be
according
to
the
clock
of
the
PC,
a
right
depending
on
where
your
clock
is
I
mean
the
PCA
will
decide
which
batch
of
certificates
to
to
provide
you.
Now,
when
you
start
using
these
certificates,
if
the
clock
of
another
car
is
has
drifted
away
from
your
clock,
for
example,
was
in
urban
Canyon,
it
didn't
manage
to
get
the
latest
connections
the
GPS
and
so
on
so
forth.
P
There
are
two
things
that
can
happen.
One
is
that
okay,
well,
the
drift
is
not
severe
enough
or
if
it
is
let's
say
such
that
it,
for
example,
it
rejects
a
given
message
because
it
looks
at
the
certificates
on
under
which
it
is
signed,
and
then
that
is
already
expired,
then
that's
the
the
worst
thing
that
can
happen.
Essentially
you
you
reject
some
of
the
traffic,
because
you're
saying
it
is
outdated.
It
comes
from
a
non
valid.
Q
P
Course,
of
course,
there
is
there's
a
whole
area
of
how
to
say
work
that
is
trying
to
look
and
I
have
a
just
one
slide
towards
the
end
of
the
add-on
work.
We're
trying
to
look
at
the
validity
of
the
data
itself
beat
position,
beat
any
sort
of
measurement
now.
The
reality
is
that
in
these
systems,
actually
you
have
much
higher
cut
safe,
unreliable,
much,
more
severe
unreliability
factors
in
the
sense
that
the
communication
itself
exactly
because
it's
very
simplistic
in
its
nature,
it
relies
on
redundancy.
P
So
you
have
lots
of
messages
being
lost,
so
essentially,
what
you're
saying
has
to
be
dealt
with
at
the
level
of
designing
the
application?
What
is
your
application
for
collision
avoidance?
This
is
where
you
should
put
enough
redundancy
and
enough
controls
in
your
protocol
to
avoid,
let's
say
or
to
basically
be
able
to
filter
out
man.
P
You
know
money,
you
know,
manipulated
forged
the
forged
messages
or
messages
which
are
not
forged,
but
it
is
what
I
call
an
input
controlling
adversary
centrally
you
induce
a
given
value
time,
location,
etc
on
a
given
vehicle,
then
everything
else
starts
breaking
down
exactly
because
there
is
no
cross
validation
for
for
those
messages.
So
this
is.
Q
Q
P
Of
course,
I
mean
these
we're
talking
about
the
same
thing.
What
I
was
trying
to
make
a
distinction
from
is
one
is
the
provision
of
the
credentials
and
then
it's
a
whole
ballgame
being
an
internal,
it's
a
adversary,
how
you
deal
or
being
in
another
series
that
is
actually
manipulated
by
an
input
controlling
understudy.
How
you
deal
with
should
say
faulty
information
in
whatever
is
a
distributed
protocol.
You
are
running
yes,
no
just.
A
So
I
want
to
inject
my
question
now
and
then
we'll
get
to
the
other
three,
which
is
this
would
be
a
really
really
big
and
very
dynamic
certificate
system.
There's
nothing
like
it
using
the
real
world
now.
Are
we
going
to
have
something
like
this
and
is
it
gonna
make?
Is
it
gonna
actually
operate
the
way
it
does
in
your
test
bed?
That's.
P
P
So
so
the
hope
is
it:
unless
you,
we
have
such
a
system
in
place.
The
rest
of
the
gentleman
who
just
sat
down
that
with
is
actually
you
know
rightfully
concerned
about
the
security
of
every
single
protocol
right
that
deals
with
all
aspects
when
won't
be
won't,
be
deployed.
So
what
we
are
trying
to
do
with
all
this
work,
all
these
years
is
exactly
to
to
show
that
it
is
complicated,
but
you
know
keep
moving
forward
and
demonstrating.
That
is
not
too
hard
in
the
end
and
it's
not
too
expensive
in
the
end.
P
So
we
should
start.
You
know
moving
forward
with
the
deployment
of
such
systems
and
it's
absolutely
correct
what
you
say
this.
This
kind
of
PKI,
essentially
we'll
be
dealing
with
five
or
I,
don't
know
even
more
orders
of
magnitude,
more
numerous
credentials
than
any
other
PK
I
have
seen
so
far.
So
this
this.
This
is
something
that
we
have
to
address
as
early
as
possible,
because
the
flip
side
would
be
to
have
a
toy
system
out
there.
That
says
well.
P
M
R
P
P
This
is
taken
in
to
move
into
consideration
now
we're
talking
about
the
interactions
with
the
VP
ki
is
a
different
line
of
work
where
you
deal
with
the
reliability
of
the
communication
with
this
unreliable
broadcast,
which
is
the
de
facto
primitive
in
these
networks
or
other
multi-hop
multi-hop
communication,
what
I
cannot
tell
you
is
whether
this
would
would
work
not
not
this.
The
provision
of
certificates
would
definitely
work
right.
What
would
not
work
but
I
cannot
tell
you
whether
it
would
work
or
not.
P
Is
these
protocols
for,
for
example,
unmanned
aerial
vehicles
or
helicopters,
or
soldiers
or
or
airplanes,
and
so
on
so
forth?
But
there
is
a
there's,
a
great
commonality
there
I
mean
I,
guess
one
has
to
do
the
homework
deal
with
the
exact
parameters
of
the
system,
but
when
it
comes
to
interaction
with
an
infrastructure,
it
depends
what
your
communication
link
to
that,
because.
P
So
this
this
actually
gives
you
an
opportunity
to
mention
another
kind
of
work.
Another
part
of
the
work
we're
doing
where
we
take
the
standardized,
let's
say
ways
of
communication,
and
we
say:
okay,
we
need
to
have
the
security
I
discussed
before
we
need
to
have
privacy.
You
need
to
have
this.
This
whole
deal
right
still,
even
though
you
add
crypto
accelerators.
At
some
point,
all
this
is
tedious.
S
Yeah,
thank
you
so
he's
grilling
for
more
power
international,
so
I
have
two
questions.
The
first
one
is
the
from
your
presentation.
I
feel
that
the
key
idea
for
your
systems
do
use
the
long
term
key
a
long
term
certificate
and
a
short
term
certificate.
But
basically
this
idea,
I
think,
should
be
the
same
as
the
DSRC
or
formally
it's
called
the
I,
probably
a
2-0
to
11
P.
You
mustn't
know
this
one.
So
my
first
question
is
that
what's
the
difference
between
your
proposal
by
your
team
and
the
TSSAA,
all
right.
P
So
the
question
is,
how
does
all
this
could
say?
Can
you
get
be
positioned
with
respect
to
standardization
effort?
So
first
thing
I
should
clarify.
Is
that
a
2.11
p
is
a
modified
medium
access
control
protocol
with
a
different
physical
layer
and
a
multi-channel
operation
targeted
for
and
some
all
sorts
of
adaptations?
Let's
say
for
the
V
cooler
communication
environment
security
per
se
is
not
addressed
in
8.11
or
DSRC,
which
is
the
predecessor
of
8.11.
There's
a
there's,
a
totally
different
version
of
DSRC,
which
is
you
know,
was
used
for
how
to
say
toll
collection.
P
But
that's
that's!
That's
ancient
history.
Now,
security
from
the
standardization
point
of
view
from
the
i3p
point
of
view
is
addressed
in
a
working
group
and
a
document
called
the
ITP
1609
.,
okay,
so
there
they
use
the
same
ideas.
Actually
the
the
effort
of
69.2
started
later
after,
let's
say
our
our
efforts
and
I
provided
the
to
them.
Let's
say
feedback
in
the
olden
days
and
we
were
still
in
touch.
P
But
then
you
have
credentials
for
twenty
more
twenty
two
more
hours,
which
you're
doing
nothing
with
right.
That's
the
thing
and
then
there
are
a
number
of
other
technical
differences
and
there
are,
for
example,
other
issues
such
as
the
distribution
of
revocation
lists,
which
they
don't
address
and
so
on
so
forth.
So
it's
a
parallel
effort
to
which
we
contributed.
They
chose
a
different
approach.
This,
not
this
on-demand
provision,
I
mean
I,
don't
want
to
comment
too
much
and
say
well,
we
are
much
better
or
anything
like
this,
but
there
are
pros
and
cons.
P
Let's
say
that
one
could
could
argue
about
the
paper
discusses
in
detail.
How
this
work
say
relates
not
only
to
the
1609,
the
two
but
other
research
proposals,
so
I
would
suggest.
Take
a
look.
The
key.
The
key
differences
is
what
I
described
here
and
let
me
know
if
you
have
a
different
question,
so
I'll
be
happy
to
enlighten
you
more
ok,.
S
P
S
S
P
There
exactly
because
we
were
also
in
touch
with
in
organization
which
is
not
a
standardization
body,
but
what
you
call
a
harmonization
or
that's
what
you
called
a
car
to
car
communication
consortium
centrally.
There
was
a
consensus
that
the
key
lengths
should
be
I,
don't
know
the
order
of
256
bits
right
now.
The
second
point
where
there
was
consensus
in
the
community
was
that
these
keys,
even
though
they're
ephemeral,
they
shouldn't
be
very
short.
So
basically,
you
shouldn't
be
able,
you
know
a
year
later
to
basically
rewrite
what
happened.
P
Should
you
have
a
transcript
of
messages
right,
because
if
you
could
now
break
the
key
and
then
recalculate
signatures
and
so
forth,
that
would
be
dangerous.
There's
an
issue
of
liability
and
I
towards
a
liability
attribution
in
the
physical
world
that
is
lurking
behind
us.
So
that
was
the
motivation
for
the
for
the
key
length.
The
second
dimension
was
that
communication
is
at
the
premium
so
essentially
being
over
a
channel
whose
bandwidth
you
cannot
control
and
and
grow.
P
You
have
to
keep
the
cryptographic
overhead
as
low
as
possible
and
among
available
well
understood
the
cryptographic
primitives
elliptic
curve.
Dsa
was
the
one
that
provides
compared
to
RSA,
for
example,
even
though
RSA
would
be
much
more
Hutt's
a
favorable
in
terms
of
very
low
verification
times.
Nonetheless,
so
here
it's
ECDSA
256-
and
this
is
let's
say
also
in
in
accordance
to
the
idealistic
9.2
standard
HS.
G
Otherwise,
and
the
reason
I'm
asking
is
because
I
understand,
from
a
consumer
perspective,
the
challenge
of
kind
of
vehicle
to
vehicle
or
vehicle,
to
other
things,
situation
to
be
that
there's
a
big
competition
for
driver
data,
how
to
lock
them
into
specific
insurance
schemes,
and
perhaps
also
safety
from
public
authorities
and
so
forth.
It
seems
to
me,
as
long
as
you
have
this
central
location,
where
all
that
data
is
somehow
generated
or
stored,
you're,
not
basically
solving
tricky
problems
for
consumers
or
addressing
previously
fairly
well.
All.
P
Right
so
so
let
me
let
me
try
to
rephrase
the
question
so
for
everyone
to
understand,
and
then
you,
let
me
know
if
I,
if
I
got
you
right.
So
the
question
is
in
such
a
thing
of
that
of
the
car
is
a
huge
sensor
which
allows
you
to
basically
learn
too
much,
even
even
better
than
what
your
mobile
phone
nowadays
does
right.
So
what
about
this
data?
P
This
is
a
problem
that
you
have
to
address
exactly
there
now,
the
question
to
ask
would
be
if
you
live
in
a
world
where
all
these
data
anyways
for
one
reason
or
another,
are
at
the
disposal
of
very
curious
entities.
Why
would
you
bother
building
a
strong
privacy,
preserving
and
security
providing
system
like
this?
Well,
the
answer
to
that
would
be
leverage
legislation
make
sure
you,
your
users
are
well
aware,
where
they're
signing
from
and
keep
them
away
from
signing
up
for
such
deals
and
protocols
that
basically
give
their
data
away.
P
Yeah,
it
could
be
actually
could
be,
you
I
mean
might
might
be.
I
know
an
excellent
business
opportunity
you're
the
CA,
who
sells
basically
but
no
I,
mean
to
be.
Let
me
be
serious
here.
The
CA
could
be
the
task,
but
the
Department
of
Motor
Vehicles
right,
the
the
Ministry
of
Transportation,
depending
which
country
you
are
a
municipality
or
it
could
be
any
CA
that
now
perhaps
there
is
a
differentiation
between
long-term
and
PCA.
Spca
could
be
any
any
certification
Authority
in
the
world.
P
Now
that
sees
a
new
opportunity
to
sell
certificates
for
whatever
price,
but
I
mean
I'm.
A
researcher
I
mean.
If
you
want
me
to
put
my
my
enterpreneur
HUD
I
mean
we
can
have
a
different
discussion,
but
we
can
have
it
offline,
but
the
question
who
is
essentially
will
step
forward
and
instantiate
the
CAS
is
open.
It
is
likely
that
the
car
manufacturers
themselves
might
be
the
ones,
but
it's
also
possible
because.
G
P
Yes,
but
this
is,
this
is
a
hypothesis,
let's
say
which
we
don't
know
yet
the
essentially
the
the
whole
underlying
principle
of
designing
such
a
system.
You
will
sit
in
the
other
systems.
I'll
show
you,
so
you
have
a
separation
of
duty
and
then,
of
course,
if
all
these
entities
are
run
by
the
same
entity,
and
it
has
the
same
gluttonous
appetite
for
data,
then
eventually
you
cannot
do
anything,
but
as
long
as
these
these
entities,
they
they
operate
according
to
specific
legislation
and
they
run
by
different
entities.
P
Then,
even
if
they
colluded,
then
what
we
do.
The
only
thing
we
can
have
is
that
the
design
is
there
to
to
reduce
as
much
the
exposure
as
possible.
Then
again,
look
at
the
system.
The
only
thing
you
you
know
is
that
if
you're
the
FDCA
that
I'm
asking
you
for
a
ticket,
nothing
else,
what
you
need
to
do
next
is
to
go
out
there
and
collect
tons
of
data
from
the
wireless
domain
and
then
try
to
make
sense
of
what's
going
on.
P
K
K
O
K
One
of
the
things
that
seems
we're
going
that
direction.
There's
a
lot
of
research
going
on
about
you
know
quantum
resistant
cryptography
and
what
we
have
today
is
definite
goals
in
a
completely
different
direction:
signatures
in
the
order
of
many
many
kilobytes
key
generation.
It
takes
a
long
time,
stateful
or
stateless,
stateless,
even
as
more
in
the
size
of
signatures
etc,
which
definitely
are
not
compatible
with
the
system.
Have
you
considered
how
the
future
of
cryptography
since
these
are
long-lived
systems,
because
P
256,
for
example?
K
So,
if
you
consider
how,
in
the
future,
you
will
try
to
address
this
problem
or
how
your
system
can
be
parametrized
so
that
you
can
also
accommodate,
especially
from
probably
from
the
vehicle
or
very
foreign
PC,
a
very
short
live
credentials
might
not
be
such
a
big
problem
unless,
for
auditing
purposes,
as
you
were
saying
Vader,
you
know
in
a
year,
you
can
still
do
some
damages,
but
for
CAS
and
PCs.
That
might
be
a
big
problem
today,
especially
if
you
invest
a
lot
of
money.
P
P
I
think
that
we
we
already
have
this
common
point.
It
depends
actually
what
you
expect.
What's
the
the
lifetime
of
the
data
which
are
digitally
signed,
let's
say
so,
if
you
want
to
use
them
for
a
posteriori,
say:
liability
attribution,
it's
also
forced
10-15
years
after
a
collection
of
a
transcript.
Let's
say,
assuming
you
run
some
sort
of
black
box
or
on
board
also
consider
the
as.
P
One
thing
you
can
do
is
that,
for
example,
you
can
you
can
increase
the
key
length
for
the
long
term
certificates.
While
you
keep
the
the
ephemeral
certificates
with
this
256
bit
security
or
you
can
keep
increasing,
write
I
mean,
but
then
you
have
to
choose
a
crypto
system
that
doesn't
blow
up
the
the
communication
or
the
communication.
Origin
regarding,
like
the
quantum,
helps
a
proof
future
of
of
cryptography
I'm,
not
the
right
person
to
comment
I
mean.
Will
you
have
to
find
people
in
the
room
who
are
cryptographers
until
you?
K
P
Point
so
let
me,
let
me
add
to
this
essentially
one
one
should
be
very,
very,
very,
very
much
concerned
about
how
to
update,
for
example,
the
crypto
primitives
that
run
on
onboard
the
vehicle
and
how
you
disappoint
them
right,
and
then
this
has.
This
goes
in
the
direction
of
how
do
you
handle
software
updates
and
how
do
you
do
them
in
a
secure
manner?
Let's
say
maybe
this
involves
recall
of
the
vehicle
to
to
the
manufacturer
and
so
on
so
for
I
don't
know
yeah.
P
K
P
A
And
see
I
have
just
one
last
thing
for
you
guys,
which
is
this
is
us
so
we'll?
You
know
we'll
see
you
again
next
time
where
we're
we're
skittering
on
top
of
a
screen,
but
thank
you
for
coming
to
to
the
IRT
F
open,
I'm
happy
to
have
any
last
questions
or
you
can
come
up
and
talk
to
me.
While
the
photography
is
happening
for
the
the
award
winners
and
we'll
see
you
in
the
RG
the
rest
of
the
week
as
well,
so
see
you
later,
our
three
other
look.