►
From YouTube: IETF113-IOTOPS-20220324-0900
Description
IOTOPS meeting session at IETF113
2022/03/24 0900
https://datatracker.ietf.org/meeting/113/proceedings/
D
Fine,
so
we
are
already
at
the
top
of
the
hour.
We
have
two
hour
schedules
for
this
meeting.
The
slide
deck
should
be
visible.
It
is
not
visible
to
me
right
now.
It
is
showing
up
to
you.
Yes,.
C
D
So,
first
of
all
welcome
everybody.
This
is
the
fourth
day
of
the
iit
113
in
vienna,
hybrid
meeting
very
astonishing
that
we
are
doing
this
in
hybrid.
Actually,
let
me-
and
I
speak
also
now
put
on
my
mask
because
that's
the
thing
we
do
here,
so
your
lovely
co-host
co-chairs
are
alexey
next
to
me
and
me
I'm
hank
and
first
of
all
please
mind.
This
is
a
recorded
session,
because
this
is
an
itf
event.
D
Okay,
yeah,
I
hope
everybody
is
now
well,
as
last
said
it
with
the
unreadable.
Note
well,
there's
a
lot
of
things
in
here.
I
think
most
apparently,
please
read
the
bcp
54
and
78
and
79.
it's
a
code
of
conduct
and
whatever
you
say
here
basically
can
go
into
the
iit
society's
ipr
pool.
So
there's
a
notebook
here
about
information.
Also,
I
think
important
to
highlight
is
bcp25.
D
D
So
yeah
this
is
a
hybrid
meeting
in
person.
Participants
should
raise
their
hand
with
the
tool.
So
if
you
have
a
device
with
you
and
you
can
join
the
meet
echo,
you
can
get
in
line
because
there
are
now
virtually
two
lines.
You
are
the
physical
inline
and
the
actual
line.
It
makes
more
sense
for
us.
If
you
raise
your
hand
so
can
we
can
see
the
sequence
between
virtual
people
going
into
the
mic
and
the
physical
attendees
going
to
the
mic?
D
So
that
really
helps
us,
but
we
will
also
try
to
take
track
of
people
who
can't
raise
their
hand
in
the
room
here.
So
anyone
who
is
not
actually
participating
in
discussion
is
advised
to
mute
their
mic.
D
D
So,
in
general,
the
logistics-
I
think
the
agenda
is
pretty
obvious.
I
think
the
most
important
thing
is:
if
you
have
a
problem
with
all
of
this
and
find
out,
it
might
not
be
me,
it
might
be
the
system,
there's
an
issue
link
down
at
the
bottom
of
this
slide.
Please
report
to
increase
the
quality
of
the
experience
for
everyone.
I
think
that's
very
appreciated,
especially
if
yeah
it's
a
recurring
problem
for
you.
D
So,
as
I
already
said,
alexey
hi,
hi,
I'm
hank
and
now
comes
the
very
important
part.
We
need
minute
takers
so
because
we
will
talk
about
things
and
there's
a
link
here
on
the
slide.
There's
a
link
in
the
agenda.
It
has
a
little
notebook
page
and
a
pen
on
it.
If
you
click
on
it,
you
get
redirected
to
a
kodi
md,
that's
where
the
minutes
are
taken.
So
what
we
need
here
right
now
is
a
minute
taker.
At
least
one
preferably
two-
and
this
is
a
hard
blocker
on
the
session
and
michael
thank
you.
D
D
D
Alex
is
mumbling
to
me
that
he
might
be
compensating
for
the
lack
of
attendee
volunteerism,
but
I
still
want
this.
Given
the
next
30
minutes,
maybe
seconds
anybody
up
and
awake
yeah,
some
people
might
not
be
as
awake
than
others.
D
Okay,
if
you
want
to
follow
the
discussions,
you
will
click
at
the
note
anyway,
because
typically
people
follow
the
notes.
If
you
think
something
has
been
written
down
incorrectly,
just
correct
that
that
makes
you
a
support,
notetaker,
so
alexia.
Unfortunately,
now
has
a
second
note-taking
duty,
yeah
again
the
meet
echo
link.
Apparently
you
found,
if
you're
in
this
meeting,
it's
on
the
bottom
of
the
slide,
and
then
we
can
go
to
the
content
next
slide.
D
Please
so
we're
going
to
have
a
full
agenda,
but
it
is
not
as
full
as
we
have
field,
because
we
have
a
two
hour
slot,
so
there
will
be
time
for
discussion
and
that
will
be
of
benefit
to
the
whole
endeavor.
So
yeah,
I'm
not
going
through
all
the
items
here.
You
can
see
michael's
first
kieran
you
had
she
has
presented
last
time.
Pierre
is
new
and
I
think
I
think
would
be
very
interesting
to
see
about
the
future
proof
next
slide.
D
This
iot
ops
working
group
is
intended
to
be
a
landing
site
for
people
coming
from
the
outside
of
the
ietf,
with
a
problem
with
the
navigation
within
the
navigator
missing
and
now
we
want
to
take
over
some
navigator
duty
here,
I
think,
and
then
last
but
not
least,
the
hunters
will
tell
us
about
the
dts
1.3
profile
for
iot.
D
I
think
that
would
be
very
interesting
for
most
of
us
and
then
we
want
to
go
into
the
rest
of
the
time
and
we
don't
have
to
notice
all
the
time,
but
hopefully
most
of
it
to
talk
about
a
working
group
deliverable.
We
started
that
discussion
last
time,
but
I
think
we've
came
closer
to
that
and
we
will
actually
have
some
slides
on
that
so
well.
First,
in
line
first
and
presentation
line
is
michael
and
so
you're
now
free
of
minute
duty
and
the
microphone
is
yours.
A
So
this
yeah,
that's
the
one.
How
do
I
actually
pause
control.
A
C
All
right,
that's
good.
A
Up,
okay,
all
right,
so
I'm
here
to
this
is
a
follow-up
for
to
talk
that
nick
gave
the
last
ietf.
So
I'm
involved
in
a
uk
group
called
the
iot
security
foundation.
It's
an
interesting
group,
a
little
bit
in
the
scale
of
you,
know,
ietf
to
complete
marketing-
it's
probably
about
here.
A
Okay,
so
you
know
not
not
some
real
technical
issues,
but
not
as
technical
as
itf,
and
it's
created
a
working
group
called
many
secured
and
within
that
there's
an
effort
called
the
secure
usable
internet
browser
or
browsing.
Maybe-
and
so
we
came
to
you
last
time
with
the
problem
statement
next
slide,
please
I'll
just
mention
that
not
only
christians
in
the
room,
but
christian
is
an
ietfer
that
got
dragged
into
this,
and
some
of
these
other
people
are
coming
from
other
directions.
A
So
what
is
the
problem?
We'd
like
to
be
able
to
browse
securely
to
the
devices
in
your
home,
be
they
printers
refrigerators
or
thermostats,
whatever
things
in
your
home,
so
https
everywhere?
That's
the
goal,
or
maybe
some
other
other
security.
A
If
someone
has
it
and
the
problem
is
that
well
devices,
they
don't
have
names
and
they
don't
have
certificates
and
if
they
did
have
certificates
the
certificates
content
don't
match
the
ip
address
that
you
probably
have
to
use
to
reach
them,
and
that's
the
problem,
and
so
today
I'm
going
to
talk
a
little
bit
about
some
of
the
solutions
that
we
have
thought
about.
One
of
the
interesting
things
that's
kind
of
un
surprising
is
that
when
we
talked
about
this
last
time
the
jabber
room
erupted
in
basically
comments
of
well.
A
This
is
an
easy
problem.
Okay,
you
just
need
to
color
it
with
a
brown,
pencil
and
there'll.
Be
no
issues
right
and
the
answer
is
well
that's
great,
but
unfortunately,
brown
pencils
are
not
available.
You
know
in
this
contact
store,
there's
a
lot
of
interesting
things,
so
I
actually
would
encourage
you.
I
had
to
dig
around
for
the
jabra
logs.
I
would
encourage
you
to
go
back
and
read
what
you
know.
A
30
intelligent
people
came
up
with
in
20
seconds
to
figure
out
what
to
do
and
what
what
some
of
the
issues
are
behind
them.
We
this
group
is
open
to
outside
participants.
You
don't
need
to
be
a
member,
but
it's
a
little
bit
more
closed
in
the
itf.
Unfortunately,
so
we
do
need
to
invite
you,
but
you'll
be
very
welcome.
A
If
you
want
to
do
that
and
I'll
just
say
that
a
tuesday
was
it
tuesday
was
six
man,
you
know,
there's
the
question
as
to
whether
or
not
you
can
even
talk
put
an
ipv6
link
local
address
in
your
browser
bar
and
the
answer:
is
you
can't
right
now,
but
as
soon
as
you
can
do
that,
of
course,
the
next
statement
is
I'd
like
it
to
be
secure,
and
so
this
is
a
bit
above
that
as
well
next
slide,
please.
A
So
I
have
a
bunch
of
slides
that
start
with
hack,
because
I'm
going
to
say
that
none
of
those
solutions
are
particularly
perfect.
Okay,
so
the
first
version
is,
you
know
what
there
isn't
really
a
problem.
A
The
problem
is
that
the
warning
that
the
browser
puts
up
is
so
scary
that
most
people
won't
click
through
it.
So
the
question
is:
if
we
could
make
that
that
warning
look
a
little
less
scary,
such
that
people
when
it's
a
link
local
address,
so
an
rfc
1918,
that's
directly
connected
or
ula,
that's
directly
connected.
So
you
know
if
you're
on
192
168,
you
know
1.1
and
it's
on
172
16.
Well,
that's
not
directly
connected
it's
somewhere
else
on
some
other
network
right,
so
the
one
that's
physically
plugged
into
your
computer.
A
If
you
go
there,
the
idea
is
that
the
browser
won't
give
you
quite
so
such
a
heart
attack,
okay
and
will
allow
you
to
essentially
accept
the
certificate
for
this
device.
Put
it
somewhere
safe.
It's
essentially
a
trust
trust
on
first
use
and
that's
about
it,
and
this
is
the
simplest
one,
but
it's
also
the
simplest
conceptually,
but
it's
probably
also
the
most
difficult
politically
to
get
to
make
happen.
A
We
basically
would
have
to
convince
the
ca
browser
forum
to
to
create
such
a
an
exception
and
the
browser
makers
to
actually
you
know,
be
willing
to
deploy
this
and,
of
course,
there's
a
lot
of
ui
and
other
issues
there.
That
we'd
have
to
talk
about
next
slide.
A
Please
so
this
is
in
some
ways,
the
most
brilliant
of
them
all
and
christian
and
moose
has
actually
emphasis
has
actually
implemented
some
of
this
and
came
up
with
some
of
these
this
stuff
a
little
bit
independently,
and
then
we
discovered
that
there
were
three
or
four
iot
vendors
that
are
actually
doing
this
right
now,
because
you
don't
actually
need
any
permission.
And
of
course
this
is
the
best
part
of
of
permissionless.
Innovation
is
the
lack
of
permission.
A
So
an
example:
here
you
have
star
dot,
you
know
fo
crypto
1d
and
it's
rooted
somewhere
in
the
manufacturer's
dns
zone
and
there's
an
http
server
that
you
connect
to
http,
not
s
at
the
moment,
and
it
redirects
you
to
this
link
right
and
when
you
look
up
that
name,
you
discover
it
returns,
192.168.0.1,
which
was
the
ip
address
of
the
device,
and
you
might
notice
that
the
hex
part
in
there
maps
directly
to
that
address,
and
so
in
fact
the
dns
server
isn't
keeping
any
state
or
any
wonderful
stuff,
whatever.
A
Whatever
query
it
sees,
it
turns
around,
you
know,
removes
the
hex
and
says:
well,
it
must
be
at
that
address
and
returns
it.
It's
actually
out
there.
You
may
know
if
you
run
open
wrt
this
isn't
going
to
work.
A
It
will
in
fact
filter
out
any
replies
that
have
rfc
19
addresses
in
them.
In
it
it
will
not
filter,
filter
out
ula,
so
yay,
ipv6,
or
maybe
the
other
side
of
it
is
unfortunately
openwrt
doesn't
know
how
to
do
security
for
ipv6.
A
The
vendor
is
not
involved
at
all.
There's
no
call
home
it's
cashable
and
conceivably.
A
You
know
someone
could
even
put
up
us
if
the
vendor
died,
someone
else
could
put
up
a
service
or
you
could
stuff
that
number
into
your
local,
open,
wrt
hosts
file
or
something
like
that
if
the
vendor
is
truly
dead
next
slide.
Please,
oh,
please
ask
questions
and
please
interrupt
me
if
something
is
unclear
there.
A
A
You
know
10.1.1.1.
Could
you
put
that
in
my
dns
please
and
the
vendor?
Does
that
and
now
it's
really
just
bog
standard
dns.
We
can
do
this
with
rc
3000,
sorry
3007,
which
is
the
dns
update
protocol
and
or
you
could
use
a
wide
variety
of.
You
know
proprietary,
hp,
http
based
ones
which,
if
you
have
ever
done
anything
you
know
called
you
know,
dynamic,
dns
or
whatever.
A
Then
it's
exactly
that's
exactly
the
problem
and
we
don't
really
need
standardization,
because
it's
between
the
device
and
its
cloud
component
and
it
could
be
whatever
okay
does
require
more
state.
So
there
has
to
be
a
database
at
the
vendor
of
mapping
names
of
devices
to
local
ip
addresses,
and
if
that
state
that
dies
or
disappears,
then
the
device
has
to
figure
out
when
to
renew
it,
and
you
know,
of
course
the
vendor
has
to
continue
to
exist
and
serve
that
name.
A
Of
course,
that
can
be
outsourced.
This
would
be
much
easier
to
outsource
than
the
previous
system.
It's
just
a
zone
with
updates,
it's
unclear
if
anyone's
doing
this
yet
for
https,
but
we
know
that
this
happens
all
the
time
with
with
other
with
otherwise
and
people
do
this,
you
know
on
their
own
systems,
they
put
up
a
raspberry
pi;
they
they
do
a
w,
get
blah
blah
blah.
They
get
their
outer
ip
address
with
a
port
map
and
they
get
a
let's
encrypt
certificate
and
people
do
this.
A
Certainly
you
know
engineers
do
this
tech
easily.
The
point
is
we're
trying
to
make
this
doable
for
light
bulbs
and
refrigerators
next
slide.
Please.
A
So
this
is
getting
a
little
bit
further
away
from
being
trivial.
Okay,
in
this
situation,
the
the
device
is
onboarded
using
well
right
now,
people
wind
up
with
you
know
an
lg
app
for
your
lg
refrigerator
and
a
samsung
app
for
your
samsung
refrigerator
and
all
this
kind
of
stuff
and
the
way
that
it
works
now
is
that
if
there's
any
security,
it's
all
private.
A
So
the
idea,
though
here,
is
that
we
will
move
towards
having
a
kind
of
app
or
a
skill,
which
is
the
word
that
the
intelligent
speaker,
people
use
to
describe
an
app
that
interacts
with
the
app
the
device.
A
Does
the
onboarding
and
that
process
collects
some
kind
of
a
certificate,
signing
request
and
enrolls
the
device,
perhaps
into
what
is
probably
a
private
pki,
and
this
is,
you
know,
there's
existing
practice.
Rfc
or
my
rfc
8995
does
essentially
this
the
chip
matter.
Effort
is
doing
essentially
the
same
thing.
Dpp
could
do
this
and
there
are
other
efforts
out
there
that
basically
are
saying:
okay,
we're
gonna,
somehow
bring
the
the
onboard
the
device
and
we'll
give
it
a
certificate
and
a
name
a
locally
relevant
name.
A
While
we
do
that,
if
you
do
this
in
this
simplest
and
stupidest
way,
your
phone
is
going
to
onboard
the
device.
Your
phone
will
know
the
name
and
the
the
the
certificate
and
have
the
trust
anchor
of
the
device
and
that'll
be
it.
And
so
then
you
go
to
your
desktop
and
you're
like
oh
well,
the
device
is
not
secure
and
I
don't
even
know
the
name.
Well,
so
that's
a
problem.
A
So
the
question
and
the
challenge
in
this
thing
essentially,
is:
if
I
do
this-
and
I
want
to
do
this,
how
do
I
propagate
this
information
throughout
the
home
and
that's
an
unsolved
problem,
but
it
may
not
be
that
complicated,
a
problem
right.
It's
just
you
know
some
kind
of
a
trust
anchor
discovery.
A
Protocol
that
runs
on
multicast
sounds
like
something
to
me
that
would
fit
into
a
dns
sd
or
something
like
this
and
maybe
actually
would
be
doable
as
a
browser
extension
or
something
like
this,
and
that
would
let
basically
let
you
get
the
local,
local
trust,
anchors
and
name
service
for
that
next
slide.
Please
so
same
thing,
but
we're
not
doing
it
from
your
phone.
A
Your
gateway
would
do
this
and
now
we're
getting
to
okay.
This
really
does
need
to
be
some
kind
of
a
standard,
the
gateway
would
we
involve,
as
I
said,
chip
matter
brewski
they
do
this
and
running
it
in
the
gateway
makes
a
lot
of
sense,
but
since
it's
the
gateway
involved,
we
can
also
imagine
that
somehow
dhcp
is
involved
or
lldp
or
some
other
kinds
of
things
that
could
work
for
this,
but
basically
we're
now
into
a
state
of
where
the
device.
This
is
really
a
proper
onboarding.
A
The
device
really
has
to
be
involved
in
this.
This
is
not
just
a
kind
of
a
hack
around
the
edges
that
gets
us
something
there.
So
these
are
the
three
the
four
things
that
we
we've
detailed
a
great
deal.
The
links
that
I
put
up
there
are
to
our
documents
there
they're
all
in
markdown
and
dockasaurus.
A
If
you
want
to
comment
on
them,
that
would
be
wonderful,
and
that's
really
it
for
for
me
from
today.
Next
slide.
A
H
So
what
I've
noticed
through
all
of
this
is
that
in
each
case,
whatever
the
mechanism,
it
is
that
you
use
to
get
the
trust
anchor
into
your
consume
well
into
your
device.
That's
ambiguous!
Sorry
into
you.
Your
browser
is
also
an
attack
surface
and
I
haven't
seen
anything
so
far
in
this.
No
that's
not
true
one
of
them.
H
The
two
of
them
were
all
right,
but
the
the
two
that
use
conventional
pki,
wind
up
broadcasting
a
whole
bunch
of
information
about
your
network
into
a
vendor-controlled
dns
and
the
others
open
a
new
attack
surface
for
someone
to
try
and
break
into
your
network.
So
I
guess
I
I
wonder
if
there's
something
that
we
can
do
that
sort
of
splits
the
difference
and
doesn't
have
both
of
these
problems.
A
That's
an
interesting
question
brendan
and
you're
exactly
right,
I'm
just
going
to
kind
of
repeat
it
back
to
the
room
and
to
you.
So
the
first
two
involve
some
kind
of
address
ip
address
information
being
shared
with
the
vendor
or
the
vendors
dns
server.
But
the
trust
tankers
can
come
from
the
normal
trust
anchors
because
the
vendor
either
has
has
allocated
certificates
with
the
right
names
already
into.
You
know
the
public
web
pki
or
it's
going
to
do
so.
You
know
lists
less
with
with
acme
at
runtime.
A
So
there's
no
trust
issue
but,
as
you
say,
you're
now
sharing
stuff
with
ip
addresses,
but
that's
about
it
with
the
vendor
and
the
other
mechanisms,
of
course
now
involve.
As
you
say,
there's
now
some
new
anchors
that
you
need
to
rely
on
and
if
you
rely
on
new
anchors
and
new
name
spaces,
then
what
you're
saying
is
that
anyone
could
possibly
insert
new
anchors
and
new
name
spaces.
Did
I
get
that
right
brendan.
H
Yeah,
absolutely
I
mean
there's
a
look
in
the
the
naive
solution
that
you
presented
on
slide.
Three
there's
it's
a
relatively
trivial
attack.
If
someone
has
physical
access
to
your
network,
to
get
you
to
connect
to
things
they
shouldn't,
so
I
mean
that
that
opens
the
the
door
for
malicious
implants,
and
things
like
that,
so
you
know
I.
I
really
wouldn't
support
that
one.
It's
quite
dangerous.
H
A
I
I
Please
add
it
to
your
keychain
type
thing
right,
yes,
and
have
you
looked
at
those
mechanisms
as
well,
because
I
don't
remember
exactly
how
complicated
they
are.
It's
been
a
while
since
I've
done
this
but
and
it's
basically
saying
I'm
trusting
whatever
you
gave
me
over
http
or
over
a
qr
code
to
be
a
trust
anchor
right.
However,
I
found.
A
That
for
my
device,
so
there's
there's
I
I
so
at
this
point
I
would
say
that
the
enterprise
base
is
not
not
rich
in
in
lots
of
experience
with
them,
but
that
effectively
brewski,
for
instance,
is
intended
as
an
enterprise
solution,
for
instance,
and
there's
other
mechanisms
like
that.
A
That,
and
one
of
the
features
of
them,
though,
is
because
they're
because
of
the
they
are
intended
as
an
enterprise
solution,
there's
an
assumption
that
the
enterprise
is
capable
of
running
a
pki
and
is
capable
of
communicating
those
trust
anchors
securely
to
their
desktops
right.
So
the
typical
enterprise,
you
know,
sticks
a
new
trust
anchor
into
microsoft,
whatever
it's
called
group
policy
and
then
everyone
trusts
it,
and
so
that
part
that
side
of
the
trust
problem
is
solved
right,
but.
A
Yeah
yeah,
there's,
there's
there's
absolutely
you
can
you
can
download,
there's
a
mime
type
right
and
your
browser
sees
that
it
will
say
you
know
it'll
put
it
up
and
say:
do
you
wish
to
trust
it
right
and
and
that's
still
there
I
think
in
almost
all
the
browsers.
It's
still
there,
but
in
some
cases
it's
it's,
it's
it
can
be
turned
off
or
like
enterprises
would
like
to
turn
that
off
and
they
control
it
or
the
user
is
simply
decides.
A
J
Todd
zeckert,
so
the
one
thing
we
eliminated
in
enema
is
the
this.
This
really
terrible,
you
know,
pre-deployment
location,
thingy,
yes
in
in
a
large
environment
like
an
enterprise
or
so
is,
is
really
a
large
cost
factor.
On
the
other
hand,
if
I
understood
maybe
I
misunderstood
the
the
scope
of
where
this
is
meant
to
go
to
like
in
the
home
or
so
yeah
we're
always
physically
handling
these
devices.
So
I
was
wondering
if
bringing
that
option
in
there,
because
it
was
never
there.
J
A
Think,
that's
that's
a
a
great,
a
great
suggestion.
You
know
go
to
the
the
bathroom
down
the
hall
on
the
second
floor
and
plug
in
the
device.
First,
you
know
and
it's
not
a
place
where
anyone
else
goes,
you
don't
you
know
or
if
they
do
then
they're
already
in,
but
I
think
that's
a
brilliant
thing.
The
problem
is
that,
of
course,
we
have
devices
that
don't
have
ethernets
well.
J
A
Yes,
the
the
issue
is
in
most
cases
is:
how
do
you
convince
the
device
that
it's
supposed
to
do
that
right
now
and
very
much?
The
matter
effort,
I
think
is,
is
is
in
that
direction
and
they
even
have-
I
don't
know
27
codes
to
say,
which
combination
of
buttons
you're
supposed
to
push
to
put
the
device
in
that
mode
and
to
doing
that.
So
so
that's
kind
of
there.
But
the
result
of
that
effort
is
that
the
device
is
enrolled
into
your
private
pki.
J
True,
but
I
mean
if
we
start
talking
about
the
wi-fi
devices,
as
you
said:
they're
they're,
all
type
of
crappy,
you
know,
but
very
often
we
use
things
like
device
opens
up
its
own
access
point,
so
it's
discoverable
by
other
devices,
and
so
on
so
I
mean,
I
think,
that's
a
longer
discussion.
It's
called
soft
ap
now.
A
D
D
Yeah
next
up
should
be
kiran,
yeah
and
she's
already
in
the
queue
welcome.
Thank.
F
F
L
E
L
L
This
is
built
on
document
we
presented
last
time
and
pretty
much.
Everything
has
changed
about
that
document
and
a
lot
of
it
was
driven
by
the
motivation
that
problem
statement
or
what
we
were
trying
to
solve
with
our
framework
document
wasn't
very
clear.
So
what
we
tried
to
do
was
pull
out
a
very
specific
portion
of
virtual
plc
and
build
the
use
case
around
it.
L
So
some
interest,
some
pretty
obvious
and
interesting
problems
came
out
and
that's
what
we
decided
to
share
in
this
document
and
since
the
topic
is
about
programmable
logical
controller,
programmable
logic
controllers.
So
these
plcs
are
like
rugged
computers,
they
control
and
monitor
devices,
and
also
manipulate
the
output
on
the
factory
floors
or
industry
systems.
L
They
are
pretty
much
the
fundamental
building
block
block
for
automation,
whether
you
want
to
perform
sequence
of
opera
operations
on
a
smart
manufacturing
or
control
motion
for
a
specific
robot
or
just
collect,
continuous
monitoring
data.
Plc's
are
the
computers
that
are
controlling
the
devices
they
come
in
different
shapes
and
sizes.
So
when
you're
talking
about
automation-
and
you
want
to
add
large
number
of
devices-
you
end
up
putting
a
lot
of
physical
computers
and
they,
since
they
have
to
be
environment,
they
have
to
be
rugged
environments.
L
L
The
good
thing
is
most
of
the
devices
are
these
plc
controllers
are
pretty
much.
They
have
the
same
design
like
you
have
a
control
unit
which
comprises
of
cpu
and
memory,
and
then
there
they
connect
to
io
modules,
which
then
directly
talk
to
field
devices.
On
the
factory
floor,
and
in
order
to
handle
this
problem
of
scaling
and
automation,
we
thought
about
the
virtualization
approach,
where
you
can
scale
out
and
elastically
change.
L
The
cpu
and
memory
configuration
because,
as
you
so
what's
related
to
automation,
is
number
of
process
controls
or
the
sequence,
the
depth
of
the
sequence
that
you
want
to
perform
in
terms
of
controlling
a
particular
process
like
you
want
to
control
certain
machinery
in
one
cell
and
then
correlate
it
with
sequence
of
operations
on
a
different
site
cell
on
the
factory
floor.
So
these
type
of
actions
require
a
lot
more
processing
power
and
more
memory
and
virtualization
of
plc's
is
one
way
to
achieve
it.
L
What
it
needs
now
is
an
interface
to
the
I
o
modules,
because
you
have
extracted
out
cu
portion
of
the
plc,
and
this
is
not
really
an
unrealistic
concept.
Any
all
the
devices
above
plc
have
already
been
virtualized.
We
have
already
seen
use
cases
where
hmi
scada
mes
these
devices
and
equipment
have
been
virtualized.
L
There
are
other
benefits
of
plc.
Some
of
them
are
pretty
straightforward
in
terms
of
what
virtualization
brings
for
us
in
terms
of
scaling
out
and
elastically,
adding
or
allocating
resources
for
that
plc.
So,
if
you
have
a
much
bigger
pipeline
of
the
sequences
of
operation,
operators
can
allocate
a
lot
more
processing,
power
and
memory
to
it
and
one
of
the
many
times
we
are
operators
are
using
different
plc's
to
control
lower
level
plc's.
L
So
now,
with
this
approach,
we
can
visualize
an
nfb
platform
or
a
service
function
chain
kind
of
thing
where
you
can
correlate
all
these
plc's
together
and
if
they
rely
if
they
reside
on
the
same
platform,
you
have
a
very
compact
data
movement,
you're,
just
moving
your
data
from
one
function
to
the
other
on
the
same
platform,
so
that
kind
of
simplifies
how
operations
are
working
on
a
factory
flow.
L
It
also
gives
a
tighter
and
integration
with
applications,
so
you
can
also
place
high-level
applications.
Business
logic
sitting
next
to
it
and
edge
compute
becomes
a
lot
more
realistic,
and
it's
a
very
interesting
that
once
we
have
moved
all
the
plcs,
not
all
or
whatever
some
few
plc's
into
the
edge
compute
network
support,
we
can
look
at
edge
data
centers
as
a
multi-tenant
solution.
L
Where
a
operator
on
a
factory
floor,
they
do
not
need
to
invest
that
much
on
the
memory
and
compute
infrastructure
and
they
can
lease
the
resources
from
a
third-party
vendor
or
if
you
want
to
interconnect
multiple
sites
together,
that
edge
compute
network
can
integrate
applications
from
different
sites,
and
we
also
have
constraints
for
low
latency
applications,
and
that's
where
I
ietf
technologies
like
that
net
or
other
high
precision
control
algorithms
can
be
used.
L
The
benefit
will
be
that
most
of
the
sensitive
silicon
part
of
plc,
which
is
your
control,
cpu
or
the
ram
part.
You
have
moved
them
out
of
a
hostile
environment
which
is
so
you're
right.
The
amount
of
the
volume
of
rugged
gear
from
the
factory
floor
has
reduced
a
lot
and
how
we
realize
digital
twins
that
also
becomes
much
simpler,
because
now
your
plc
is
a
software
form
and
integrating
into
some
kind
of
a
simulation
model
becomes
much
easier.
L
And
so
how
do
we
realize
these
virtual
plc's?
There
are
three
different
approaches.
The
first
one
is
just
extract
the
hardware,
so
you
will
have
a
program
or
the
plc
logic
that
you
can
run
on
commodity
hardware
or
any
hardware,
so
that
just
you
c
c?
U-
and
I
o
part-
are
integrated
in
that
case.
Your
interface
with
rest
of
the
applications
on
top
of
plc
has
not
changed
at
all.
L
L
In
that
case
it
becomes
a
problem
of
how
do
we
provide
a
common
interface
from
the
cu
portion
to
the
I
o
modules
on
the
factory
network
and
the
highest
highest
degree
of
disaggregated
case
will
be
when
we
are
actually
crossing
the
zone,
boundaries
where
applications
and
virtual
plc's
are
residing
together,
and
we
need
to
support
a
common
interface
over
a
van
or
a
large
scale
network
and
you're
crossing
the
factory's
own
boundaries.
L
And
the
third
part
would
be.
The
third
case
will
be
the
ideal
approach
that
we
want
to
achieve.
But
for
that
to
happen,
we
will
have
to
pretty
much
break
the
hierarchical
model-
the
purdue
model
here
since
we
are
moving
the
devices
from
l1
and
l2
level,
all
the
way
up
into
the
enterprise
applications,
so
that
that
imbalances,
the
security
paradigm
of
purdue
model
and
we
need
to
find
a
way
to
so.
L
Basically,
when
we
go
from
physical
plcs
to
virtual
plc
is
pretty
much,
we
are
looking
for
a
disaggregated
model,
and
that
is
something
we
need
to
look
into
in
order
to
support
virtual
plcs.
L
So,
based
on
this
input,
we
came
up
with
the
some
problems
of
realizing
for
realizing
virtual
plc's
and
first
one
will
be
related
to
now.
Your
control
unit
and
io
modules
are
separated.
So
what
will
be
the?
How
these
plc's
will
speak
speak
to
io
modules
since
they're
in
the
software
format?
Now
any
plc
can
control
the
I
o
modules
or
the
devices
underneath.
L
How
do
we
provide
authentication
and
association
mechanisms
to
these
devices,
and
then
there
is
also
a
problem.
How
do
we
determine
if
a
virtual
plc
was
talking
from
somewhere
outside
your
factory
zone
network,
or
it
was
in
the
edge
cloud?
In
that
case,
your
security
policies
have
to
be
programmed
accordingly.
L
L
What
are
the
addresses
for
these
virtual
plc's
depending
upon
how
they
reside
in
the
network
and
how?
What
is
the
scope
of
authentication?
How
do
you
authenticate
these
virtual
plc's,
because
we
still
want
to
preserve
the
safety
and
security
of
how
operations
are
performed
and
we
need?
We
also
need
to
define
some
key
performance
indicators
in
terms
of
how
we
describe
the
latency
resiliency
of
the
system.
L
L
Then
there
are
obviously
corresponding
network
environments,
and
this
is
where
I
think
it
leads
back
to
our
framework
draft
that
now
we
have
an
opportunity
to
build
a
converged
network,
because
we
have
already
taken
care
of
most
of
the
intelligent
components
out
of
the
network,
and
our
interface
can
now
be
really
unified,
because
id
and
ot
devices
are
pretty
much
sitting
together
and
the
interface.
How
cu
2
io
module
will
happen
is
something
that
will
be
one
of
the
problems
we
need
to
solve,
so
that's
pretty
much
it
before
going
deeper
into
it.
L
I
just
wanted
to
share
that
how
these
virtual
plc
realization
work
will
be
considered
within
iot
ops,
or
how
do
we
proceed
further
further
with
these
things,
the
things
I'm
trying
to
answer
at
least
raise
questions
from
problem
statement
are
like
how
do
we
disaggregate
different
security
zones?
How
do
we
come
up
with
a
formal
method
of
connecting
to
edge
compute
networks?
L
How
do
we
define
our
virtual
plc's,
and
hopefully,
if
that
work
is
consumed,
then
we
translate
into
the
framework
which
is
based
on
unified
fabric
and
share
it
with
external
stos
that
are
really
working
on
industrial
networks
and
tell
them
hey.
This
is
the
informational
or
best
practices
work
that
is
coming
from
idf?
We
have
some
protocols
and
technologies
that
could
help
you,
deploy
your
systems
and
or
how
you
use
idf
to
solve
these
problems
yeah.
So
that's
pretty
much
it.
D
That
would
be
nice,
so
thank
you
and
and
so
yeah.
This
is
after
hearing
the
problem
statement,
the
requirement.
This
is
a
lot
of
things
that
on
a
lot
of
different
layers.
So
when
I
look
at
this
problem
from
my
personal
point
of
problem
awareness
already,
the
different
field-
buses
like,
like
you,
said
modbus
and
profibus,
and
then
we
have
the
scada,
the
s5,
the
s7
already
getting
that
aligned
and
then
a
little
bit
homogenized.
D
That's
that's
its
own
problem
right!
So
so
yeah,
that's
that's
somewhat
involved
in
all
what
you
do,
but
that's
its
own
problem
space,
and
then
you
have
the
virtualization
of
the
glue,
which
is
now
the
virtual
plc
that
would
handle
that
and
itf
technology
can
help.
You
do
that,
but
I
think
passing
on
the
messages
in
a
way
that
is
not
utterly
confusing
or
from
the
80s.
D
D
It's
busy
setting
and
getting
things,
and
I
think
the
itf
has
very
good
building
blocks
for
that
and-
and
there
are
even
even
experimental
ones
like
new
ones,
like
the
semantic
data
format
right
where
the
safe
description
of
them
of
these
plcs
will
be
kicking
in.
So
I
think
this
is
a
multi-problem
thing
now
and
the
virtualization
of
plcs,
I
think,
is
a
very
high
level
goal,
and
maybe
it's
in
it's
it's
it's
very
useful
to
the
purpose
to
to
segment
like,
for
example,
the
messaging
problem
out
like
like.
D
I
have
all
these
proprietary
messages,
but
there
are
actually
not
so
many
they're,
just
proprietary,
sorry,
they're,
just
old,
not
necessarily
proprietary,
and
and
now
we
can
re
re
transform
them.
I
don't
know
an
objection
or
c
or
something
and
then
go
from
there,
expose
them
via
virtualized
thing
that
is
now
very
manageable
because
it
doesn't
have
to
take
into
account
all
the
different
things
you
already
know
how
to
transform
them.
D
L
M
Medical,
I'm
sorry
just
for
me,
but
one
question
I
have
is
as
far
as
I
thought
about
this
stuff
again
and
again,
it
always
comes
down
to
the
problem
that
we
have
real-time
systems
very
often,
and
we
need
to
have
these
yeah
real-time
network
communication,
which
is
going
through
active
layer,
3
devices
at
the
end,
which
usually
works.
Not
so
well.
So
that's
why
the
deterministic
network
stuff
is
there.
So
my
question
is
how
far
along
is
the
deterministic
networking
yeah
technology
already
is,
that
is
that
feasible
right
now,.
N
L
Is
pretty
much
feasible?
I
think
they
have
some
protocols
that
are
already
being
developed
and
that's
one
of
the
ideas
that
how
do
we
come
up
with
an
architecture
that
integrates
that
net
more
easily?
And
that's
where
the
idea
of
unified
fabric
came
in
so
they
have
already
developed
some
technologies.
They
are
actually
using
tsn.
I
guess
right
now
they
are
building
solutions
on
top
of
tsn
and
I
need
to
plug
in
with
them
to
see
how
feasible
it
is
for
them.
L
But
I
think
it
should
be
possible
to
connect
from
edge
compute
to
at
least
some
factory
site,
using
that
net
technologies.
K
O
K
N
Hi,
this
is
hannes.
I
think
it
would
be
good
to
drag
along
some
people
who
work
in
this
space
and
are
manufacturers
like
siemens
and
from
our
interactions.
I
know
that
they
are
not
using
off-the-shelf
hardware,
because
you
pretty
much
because
of
the
previously
mentioned
freedom
requirements.
You
cannot
we
at
arm.
We
have
our
own
class
of
processors
specifically
for
that
purpose.
N
It's
called
the
r-class
processor
which
uses
virtualization,
but
only
because
of
memory,
isolation,
sort
of
software
isolation,
which
includes
memory
resolution
to
because
you
can't
use
virtual
memory,
because
that
introduces
a
lot
of
unpredictability
in
the
in
the
whole
scheduling
and
then
a
whole
sort
of
response
time.
N
So
it's
an
extremely
it's
an
extremely
complex
space,
and
if
you
see
what
vendors
do
they
basically
rewrite
the
whole
software
stock
from
from
bottom
to
top,
because
current
software,
like
in
like
off-the-shelf
software
that
we
are
typically
using
in
other
areas,
is
not
bound
to
to
the
real-time
behavior
that
you
would
need
in
those
systems.
So
it's
it's
very
demanding
so
drag
some
of
those
guys
along.
It
would
be
interesting
to
hear
what
they
what
they
have
to
say.
N
L
Here
so
that's
an
interesting
point
and
do
understand
it
is
somewhat
difficult
and
I'm
not
promoting
that
we
should
use
off-the-shelf
hardware,
even
if
even
with
vendor-specific
platforms,
you
could
have
benefits
from
virtualizing
plcs
and,
as
I
said,
that
how
you
put
different
plcs
together
on
the
same
platform,
you
can
get
better
integration
between
applications
and
software,
but
yeah
it
is
a
paradigm
shift.
I
do
agree.
P
A
D
O
Right
so
good
morning,
I'm
pete
from
eth
zurich
new
here
and
today
I
will
be
presenting
a
paper
that
we
originally
presented
at
gritties
in
lausanne
last
year,
but
I
think
it
could
also
be
useful
feedback
here
or
useful
input
here.
So
this
is
work
that
some
colleagues
at
eth
did
together
with
franco,
monte
from
msf
partner,
their
company.
They
do
consulting
for
critical
infrastructure
security,
so
they
do
power
plants
and
those
kind
of
things.
O
So
the
presentation
has
two
parts
roughly
first,
it's
a
discussion
of
how
industrial
networks
are
structured
today
and
then
challenges
that
we're
seeing
in
these
networks
and
then
the
second
part
is
a
maybe
somewhat
futuristic
proposal
of
how
we
could
restructure
these
networks
in
a
more
modern
way
so
slide.
Please.
O
Right
so
when
we
look
at
industrial
networks
today,
what
we
almost
always
see
is
that
there's
this
very
strong
hierarchy
and
this
hierarchy
has
two
reasons.
Firstly
and
the
network
is
hierarchical
because
the
control
systems
that
the
network
is
controlling
or
that
the
network
is
connecting
to
is
hierarchical
and
these
control
systems
are
typically
located
together
with
the
processes
that
are
being
controlled.
O
So
hence
the
network
kind
of
naturally
inherits
this
hierarchical
structure
and
then
second
there's
this
general
notion
that
having
this
hierarchy
in
your
network
is
good
for
security,
because
typically
there
will
be
security
enforcement
points
between
every
level
of
the
hierarchy.
So
the
lower
you
go
down
the
hierarchy,
the
higher
your
security
level
gets
and
at
the
bottom,
that's
where
the
most
security
critical
devices
would
be
placed
slides
now
we're
seeing
that
this
traditional
way
of
organizing
the
network
is
more
and
more
being
challenged
in
the
last
couple
of
years.
O
So
first
one
of
these
challenges
is
that
we're
seeing
changes
to
the
network,
for
example
in
the
data
center
sdn,
has
pretty
much
or
is
pretty
much
taking
over
these
days
and
with
the
ipot
convergence.
That
means
that
it's
also
only
a
matter
of
time
before
we
also
start
to
see
these
things
coming
to
the
factory
floor.
O
At
the
same
time,
the
i3
is
working
on
tsn,
which
will
probably
make
ethernet
a
more
or
less
universal
replacement
for
all
of
today's
wired
field
buses.
So
over
time,
we
will
likely
also
see
all
of
these
field
buses
being
replaced
by
ethernet,
and
these
things
they
really
from
a
technological
standpoint.
They
bring
the
top
and
the
bottom
of
this
traditional
hierarchy
closer
together,
which
means
that
almost
by
definition,
it
becomes
harder
to
keep
them
separated.
O
Then
we're
also
seeing
changes
to
the
automation
infrastructure
itself,
so
we've
seen
already
a
couple
of
times
that,
as
the
requirements
that
are
placed
on
technology
kind
of
start
superseding
the
capabilities,
we're
moving
to
to
more
general
purpose
components
again
in
the
data
center,
we've
had
virtualization
in
the
industrial
world,
we're
seeing
ipot
convergence
right
now
and
as
kevin
was
discussing
we're
also
seeing
these
virtual
or
virtualized
automation
functions
like
soft
plc,
subscribers,
soft
hmi
and
these
things
or
what's
interesting
about
these-
is
that
this
virtualization
breaks
the
assumption
that
your
controllers
need
to
be
placed
close
to
the
processes
they
control,
so
they
could
be
placed
in
the
edge
or
in
the
clouds,
and
this
means
that
you
need
a
network
architecture
that
allows
you
to
decouple
the
logical
and
physical
location
of
your
assets.
O
Right
then,
we're
also
seeing
changes
to
information
flows
where
it
used
to
be
that
that
flows
would
really
always
only
cross
one
layer
of
this
hierarchy
at
a
time
now
there
are
more
and
more
flows
that
cause
many
or
even
all,
of
the
layers.
For
example,
if
you
have
a
device,
that's
sitting
in
the
field,
that's
uploading
data
to
a
to
a
cloud
service
or
something
like
predictive
maintenance.
And
now
you
need
to
punch
holes
all
the
way
down
your
hierarchy,
and
this
not
only
leads
to
high
management
overheads.
O
Then
we're
also
seeing
changes
to
the
threat
models
where,
with
the
original
network
design,
the
assumption
was
that
the
attacker
would
come
from
the
top
and
would
have
to
work
its
way
down
with
more
complex
devices
in
the
network
that
need
updates
or
more
mobile
devices,
with
more
devices
that
can
be
remotely
managed
or
increased
wireless
technologies.
O
It's
becoming
more
and
more
likely
that
the
attacker
can
actually
appear
somewhere
in
the
middle
or
even
at
the
bottom
of
the
network
instead
of
at
the
top-
and
this
undermines
this
assumption
of
incremental
security
and
then
we're
seeing
changes
to
operational
models
where
now
more
and
more
plants
are
sometimes
don't
even
have
anyone
in
them
and
they're
completely
managed
remotely.
So
all
this
control
traffic
needs
to
travel
over
the
inter
domain,
slides.
O
That,
in
principle,
has
full
connectivity
between
all
of
the
network
zones,
but
then
there's
a
central
controller
that
puts
limitations
on
which
transitions
or
between
which
zones
and
in
which
patterns
traffic
can
flow,
and
because
this
transit
network
is
relatively
open.
All
the
traffic
between
the
transition
points
is
tunneled
so
encrypted
and
authenticated
slides.
O
O
You
can
replicate
certain
zones
or
all
of
the
zones
that
you
have
in
your
physical
plant
into
the
clouds
and
then
by
configuring
this
policy,
you
can
place
zones
that
are
physically
distant,
adjacently,
close
or
logically
close,
but
you
can
also
put
zones
that
are
physically,
close,
logically
distant
slide.
O
And
you
can
do
things
like
partial
deployments
in
two
ways:
either
you
can
just
convert
one
part
of
your
network
to
a
tableau
architecture
while
keeping
a
hierarchical
architecture.
Otherwise-
and
this
within
that
part
that
is
tableau
oriented,
keeps
all
of
your
or
of
the
nice
tableau
properties
or
you
can.
If
you
have
a
network
that
follows
a
tableau
structure,
you
can
also
overlay
more
traditional
hierarchy,
hierarchical
zone
transition
policy.
So,
logically,
it
still
looks
like
a
traditional
network,
and
then
you
have
more
time
to
transition
your
policies
over
time,
flight.
O
Can
you
no
problem
as
a
technical
facilitator
for
this?
We
use
mondrian,
which
is
work
from
colleagues
of
mine,
which
creates
these
notions
of
transition
points
in
the
zone
controller
in
the
enterprise
setting
and
binds
these
transition
points
together
across
the
enter
domain
into
an
into
the
main
transition
zone.
That
then
allows
traffic
to
flow
unrestricted.
O
O
Structured
networks
is
that
this
hierarchy
is
necessary
for
defense
in
depth
and
to
have
a
strong
defense
of
your
network
and
specifically,
and
the
fact
that
you
have
these
layered
firewalls
and
that
you
have
a
lot
of
heterogeneity
and
what
kind
of
devices
are
used
in
the
network
is
argue
or
is,
is
used
as
an
argument
for
security
and,
and
it
said
that
that
facilitates
defense
in
that
our
point
or
our
take
on
this-
is
that
actually,
this
is
not
as
black
and
white
and
doing
these
things
or
having
layered
firewalls
and
having
heterogeneity
does
not
automatically
lead
to
defense
in
depth,
because
that
really
needs
you
or
requires
you
to
have
this
security
oriented
mindset
throughout
your
organization,
and
that
is
something
that
you
can
do
with
and
without
this
traditional
structure
and
there's
also
past
work.
O
That
shows
that
having
these
really
complex
policies
or
complex
networks
with
heart
administer
policies
can
actually
harm
security
in
some
ways
and
additionally,
as
I
discussed
in
the
beginning,
the
threat
models
are
actually
changing,
which
means
that,
because
this
hierarchical
network
model,
the
security
assumptions
of
it
rely
or
assume
make
some
assumptions
about.
The
underlying
network,
if
the
underlying
network
is
changing,
and
if
those
models
are
changing,
then
also
your
security
models
or
your
security
properties
will
stop
the
holds
in
tableau.
O
We
do,
however,
so
we've
been
thinking
about.
How
could
we
still
introduce
heterogeneity
into
the
network,
though,
because
it
definitely,
it
does
provide
a
benefit
and
in
some
in
some
situations,
for
example,
in
power
plants
or
in
hydro
dams
or
things
like
this.
You
might
still
require
this
head
virginity
and
we
looked
at.
O
Slides,
so
just
to
recap
that
so
you've
seen
that
specifically
or
that
that
changes
to
the
industrial
network,
and
specifically
these
changes,
come
from
the
iot
that's
coming
up
and
from
ite
convergence
are
challenging
the
traditional
ways
that
we
defend
its
networks.
O
We
see
that
some
of
the
assumptions
that
really
come
from
these
that
are
that
this,
that
this
purgiou
based
network
is
based
on
no
longer
holds
so
we
have
eroding
security
properties,
and
then
we
have
a
proposal
that
flattens
these
this
network
hierarchy,
enabling
more
flexible
inter-domain
traffic
management
and
that
has
centralized
policy
management
and
then
we've
shown
how
or
we've
talked
about
how
modern
security
practices
with
structured
head
virginity
can
actually
replace
this
layered
approach,
and
with
that
I'm
open
to
discussion
or
questions
or
comments,
outrage.
D
Q
Good
morning
and
good
afternoon,
and
a
very
early
morning
to
some
colleagues
and
friends,
yeah
thanks
very
much
for
for
your
presentation
as
a
side
comment,
I'm
based
in
the
zurich
area,
I
would
love
to
get
together
with
you
and
talk
about
this
at
eth
or
or
at
cisco,
where
I
work
or
virtually
whatever
people
feel
comfortable
with
two
comments.
Q
First,
the
there
there's
a
there's,
I
think,
a
little
bit
hidden
in
your
presentation,
which
is,
I
think,
natural,
when
you're
trying
to
give
a
summary
the
term
heterogeneous
heterogeneity,
has
to
be
very
carefully
understood
in
this
context.
Q
You
know,
there's
all
sorts
of
heterogeneity
and
I
don't
think
you
quite
defined
it
and
it
is
sort
of
key
to
your
presentation.
Q
So
maybe
you
can
take
a
few
minutes
after
I
finish
the
second
comment,
just
to
say
what
you
mean
by
heterogeneity
boy,
I
can't
even
speak
today
I
had
a
head
cold
earlier
now
it
was
tripping
over
my
tongue.
The
second
point
I
was
going
to
make
is
that
my
experience
when
it
comes
to
these
models,
and
if
you
look
at
the
way
that
esa
99
came
together,
it
really
sort
of
fit
itself
around
what
the
manufacturers
were
doing
and
now
what
you're
saying
is
well.
Q
Manufacturers
are
going
to
be
doing
something
different,
taking
advantage
advantage
of
the
various
virtualization
capabilities,
the
merging.
I
think
your
problem
statement
is
spot
on:
okay,
the
but
the,
but
the
magic
here
is
in
the
policy,
not
in
the
deployment
of
not
in
the
enforcement,
but
in
the
policy
we
have
gazillions
of
means
to
flatten
networks
in
terms
of
access
control,
for
instance
it
it
they
exist
throughout.
You
know,
since
since
day,
one
practically,
so
maybe
you
could
talk
just
a
little
bit
more
about
this.
Q
O
Right
so
the
first
comment:
the
question
was:
what
is
heterogeneity
so
here
I'm
trying
to
capture.
That
is
the
idea
that
if
you
have
a
network
where
you
have
different
security
enforcement
techniques
or
even
different,
just
firewalls,
that
are
designed
by
different
vendors
that
are
completely
independent
products.
O
There's
this
notion
in
this
in
this
industry
that,
if
you
by
having
that
an
attacker,
would
need
to
so
let's
say
that
that
from
the
top
layer
to
the
bottom
layer,
you
have
firewalls
from
five
different
vendors
in
there.
There's
this
notion
that
okay,
that's
good,
because
the
adversary
would
have
to
find
holes
in
five
different
firewalls
or
five
different
firewall
implementations
and
before
he
can
actually
break
the
network
sufficiently
to
really
hit
your
lower
field
layer
there
and
to
really
be
able
to
affect
the
physical
process.
O
Q
If,
if
I
may,
what
I'm
saying
is
that
how
is
it
that
you
program
are
you,
are
you
are
you,
how
do
you
program
access
and
how
do
you
decide
what
needs
access
to
what
or
what's
an
access
violation
when,
when
you're
not
enforcing
but
merely
observing,
thank
you.
O
Right
so
in
in
this
setting,
we
would
be
enforcing
right
because
you're
so
you're
only
this
solution,
which
again
is
from
our
perspective.
This
is
not
a
final
solution.
This
is
kind
of
a
first
conversation
starter
is
the
access
management
is
done
on
the
level
of
the
zones
right
so
which
transition
to
which
zone
is
allowed
and
which
one
is
not,
and
this
at
the
moment
in
the
in
the
monorail
implementation
that
we
have
is
very
enterprise
oriented.
So
it's
based
on
ip
ranges.
O
We
actually
I
find,
is
a
very
interesting
thing
and
we
would
like
to
to
look
more
into.
How
can
we
change
that
to
be
more
practical
for
the
industrial
setting?
And
we
also-
but
we
actually
also
find
this
quite
challenging,
because
it's
very
hard
to
get
corporations
or
get
access
to
real
world
data
from
from
these
kind
of
plants,
so
embarrassed
so
yeah.
D
So
again,
turles
is
next,
but
michael
you
have
30
seconds
yeah
make
it
fast.
Well,.
J
Thanks
a
lot,
but
please
take
it
positively
right
I
mean
it
was
great
marketing,
but
I
didn't
see
a
single
second
that
was
explaining
to
me
what
tableau
was
doing
so
I'm
really
just
guessing
like
it
could
be
a
set
of
coordinated
working,
distributed,
firewalls
you're,
throwing
in
that
are
somehow
magically
creating
the
zones,
so
I
would
have
really
loved
to
spend
one
minute
out
of
the
15
minutes.
We've
been
doing
all
of
this
on
some
technical
explanation,
what
it
really
does.
D
And
we
have
the
list,
so
you
can.
You
can
add
some
explanations
to
this.
That's
visible
to
everybody
here
and,
as
even
michael
might
have
more
comments.
Please
put
them
if
they're
addressable.
Also
to
this.
Thank
you.
D
So
next
up
is,
I
think,
called
heinz,
I'm
from
the
top
of
my
head.
I
hope
I'm
not
doing
this
wrong.
No,
I'm
doing
this
wrong.
Yeah.
D
All
markers
sorry,
both
of
you
yeah,
that
was
like
a
little
bit
confused
to
me,
hi
so
flaws
yours
presentation
should
be
on
the
way.
R
Yeah
hi,
I'm
marcus,
and
in
this
talk
we
would
like
to
present
our
envisioned
communication
architecture
for
future
energy
grid
operation
systems,
which
has
to
be
low,
latency,
reliable
and
secure,
which
is
part
of
our
research
project
venus
we
are
currently
working
on
and
the
scope
of
this
talk
will
be
next
slide.
Please,
the
scope
of
this
talk
will
be,
as
I
said,
the
introduction
into
our
research
project
venus
as
a
whole,
and
then
we
will
get
give
technical
details
about
the
communication
architecture.
R
We
are
envisioning
here,
and
the
goal
with
this
talk
is
to
find
out
which
itf
solutions
might
be
might
be
considerable
for
contribution
by
the
project
and
also
which
iotf
working
groups
might
be
interesting
for
the
technologies
we
are
facing
here
in
venus
and
yeah.
As
hank
already
said,
we
I'm
we
are.
We
are
two
here,
I'm
here
with
collins,
gender
from
aperios,
who
has
mainly
driven
this
talk
here
at
itf
and
I'm
marcus
from
the
chair
of
communication
and
distributed
systems
at
rwthr
next
slide.
Q
R
So
this
is
our
agenda,
but
I
would
suggest
to
get
right
into
it.
So
next
slide
please.
So
the
energy
distribution
grid
is
changing,
which
is
mainly
driven
by
measures
to
meet
climate
codes.
R
So
we
are
basically
moving
away
from
fossil
energy
sources
going
to
to
yeah
generating
energy
from
renewables,
and
this
also
means
that
the
production
of
energy
moves
from
yeah
conventional
centralized
power
plants
to
distributed
power
generation,
for
example,
by
solar
cells,
yeah
basically
placed
all
over
the
country,
and
this
also
introduces
changes
to
the.
As
I
said,
distribution
grid,
but
more
specifically,
to
the
power
flows.
R
As
now
not
only
centralized
a
few
centralized
power
plants
are
generating,
the
energy
and
the
distribution
grid
has
to
distribute
it
to
our
consumers,
but
all
of
the
yeah,
the
the
power
can
be
fed
into
the
or
need
to
be
fed
into
the
distribution
grid
all
over
the
place
and
yeah.
This
basically
leads
to
multi-directional
power
flows.
R
The
problem
or
one
problem,
the
distribution
grid
providers
are
facing
here,
is
that
their
traditional
static
distribution
grid
protection
systems
cannot
cope
with
that,
so
they
are
basically
parameterized
once
or
two
times
a
year
manually
at
every
station
out
in
the
field,
but
for
such
multi-directional
and
highly
volatile
power
flows,
it
needs
to
be
more
yeah.
They
cannot
cope
with
these.
These
volatile
power
flows
and
yeah.
This
basically
means
that
they,
for
example,
can
change.
R
It
can
detect
changes
in
your
power
flows
and
misidentify
them
as
a
short
circuit,
which
then
basically
can
result
in
false
containment
or
partial
shutdown,
which
of
course,
is
not
great
for
the
consumers,
but
elsewhere
is
not
great
for
the
con
for
the
for
the
efficiency
of
the
of
the
power
grid
and
power
generation
as
a
whole.
Next
slide.
Please-
and
this
is
where
venus
comes
into
play,
and
we
knows
we
want
to
basically
prepare
the
protection
technology
to
cope
with
these
new
challenges.
R
With
these
highly
volatile
multi-directional
power
flows,
and
the
idea
here
is
to
introduce
an
adaptive
and
interconnected
grid
protection
system-
and
we
can
see
here
on
the
right-
the
yeah-
a
scheme
which
basically
yeah
depicts
the
envisioned
architecture.
R
But
this
of
this
has
to
be
done
over
a
low
latency
communication
infrastructure.
As
these
control
messages
need
to
arrive
at
each
of
these
stations
at
the
same
time,
because
we
do
not
want
to
have
any
inconsistent
states
in
our
protection
system.
So
each
each
of
these
devices
need
to
be
configured
at
the
same
time,
and
this
is
also
the
the
reason
why
this
communication
infrastructure
has
to
be
reliable
because
we
do
not
want
to
lose
any
control
messages.
R
And,
furthermore,
this
system
also
needs
to
be
secure,
as
we
do
not
want
attackers
to
be
able
to
intercept
any
ongoing
communication,
for
example,
to
yeah,
to
attack
the
the
power
grid
and,
for
example,
shut
it
down,
but
also
the
systems
in
the
field
need
to
be
secured.
Hardware-Wise
to
yeah
ensure
that
attackers
our
attacks
are
are
detected
here
and
how
we
would
like
to
face
that
in
venus
is
what
khan
hands
will
elaborate.
Now
next.
D
Slide
please
just
a
second,
so
I
see
tallis
has
raised
his
hand.
D
Yeah,
no,
I,
but
I
think
maybe
questions
are
in
order
right
now
or
do
you
want
to
just
disrupt
your
presentation
flow.
R
So
the
protection
is
at
the
energy
energy
level,
so
it's
basically
completely
yeah
that
this
is
what
the
what
the,
what
the
electrical
engineering
guys
are
doing
in
our
project.
So
we
are
not
not
alone
here,
so
this
is
completely
in
the
yeah.
In
the
power
level,
the
protection.
M
M
The
energy
grid
is
shut
off
in
cases
where
it's
needed
before
stuff
breaks
yeah.
So
then,
then,
about
the
actual
communication,
the
rt
part
of
this,
because
the
force
thought
were
more
small
about
energy.
That's
the
stuff!
I
wanted
to
talk
about
now,
just
to
make
it
more
obvious
for
a
protection
system
right
now.
If
you
configure
it,
you
configure
it
once
you
put
it
into
a
into
into
the
grid
somewhere
and
it
will
stay
there
and
will
work
there
until
it's
decommissioned.
M
So
it
will
not
have
an
actual
connection
to
to
some
kind
of
control
system
which
actually
changes
parameters.
So
it
is
the
only
thing
it
does.
It
does
some
reporting
to
the
grid
control
center
and
that's
why
we
have
this
new
communication
flow,
where
a
protection
system
is
now
not
anymore,
just
a
reporting
system
which
is
steadily
configured
once,
but
now
it's
a
system
which
is
configured
all
the
time
and
has
different
profiles
and
will
react
on
different
states
of
the
energy
grid.
M
So
it
needs
to
communicate
also
from
the
configuration
point
as
well,
and
not
just
from
the
reporting
point
of
view,
and
for
this
we
have
some
yeah
some
kind
of
parallels
to
the
plc
talk
we
had
before.
We
need
to
have
a
communication
which
works
also,
sometimes
in
real
time,
and
that's
why
we
have
these
three
requirements:
low,
latency,
reliability
and
security
and
in
the
latency
part
we
start
to
tackle
these
requirements.
We
looked
into
itf
standards
and
other
stuff,
and
we
said
okay
for
low
latency.
M
We
might
be
able
to
use
sdn
to
actually
reserve
paths
to
systems
and
to
react
on
failures
and
do
some
failure
for
also
we
can
try
to
use
for
reliability
and
deliberate
for
low
latency
multi-pass
technologies
like
multi-pass,
dsp
or
multi-purpose,
quick,
or
to
be
able
to
transfer
more
data
on
different
paths
to
the
system
and
be
faster,
be
quicker
at
the
end,
be
more
reliable
so
that
if
someone
one
pass
fails
and
at
the
end
the
last
part
we
thought
about
was
how
can
we
do?
M
This
start
now
need
to
be
secure,
since
they
are
actually
communicating
through
the
internet
and
are
reachable
through
the
internet,
and
then
we
looked
into
trust
execution
environments
to
actually
protect
some
of
the
code
we
which
are
in
this
these
systems
and
which
is
like
the
code
that
is
very
mandatory
to
ensure
safety
or
their
safety
functions
and
also
look
into
how
we
could
actually
use
the
te
and
had
the
teeth
to
have
and
then
found
teep
and
suit
on
on
the
on
the
itf
agenda.
M
So
to
speak,
and
also
for
security,
found
rats
and
that's
the
stuff
we
wanted
to
to
apply
for
security,
but-
and
that's
the
next
slide
please,
but
we
are
still
at
the
beginning
right
now.
We
already
we
also
discussed
if
we
want
really
want
to
present
this
today,
but
we
thought,
after
talking
also
to
the
chairs.
It
would
be
good
to
to
actually
start
begin,
also
start
with
our
itf
contribution
from
the
beginning
of
the
project.
So
ask
you
guys
and
on
your
opinion,
on
your
experience
and
all
the
workshops.
M
You
know
what
what
could
be
considered
or
should
be
so
considered
from
from
our
side.
Where
should
we
also
look
at
maybe
besides
the
technology
already
said?
Maybe
one
of
these
technologies
may
also
be
not
the
right
fit,
and
that's
why
we
started
here
with
the
aim
to
contribute
to
the
itf
and
also
ask
you
all
which
work
groups
would
be.
J
J
We
can
certainly
chat
offline,
for
example,
and
gather
also
after
the
meeting,
I'm
still
quite
unsure
about
the
exact
scope
of
the
project,
because
I
would
assume
that
a
lot
of
the
things
you
are
looking
for
as
far
as
network
reliability
and
signaling
and
everything
is
concerned
should
be
solved
by
you
know
the
latest
generation
of
the
work
going
on
and
the
synchrophaser
grids
of
of
the
different
continents,
but
maybe
you're,
looking
into
a
more
edge
use
cases
where
you're
not
really
having
to
deal
with
the
you
know
the
synchronization
of
the
phase
of
of
of
the
power
generation,
which
puts
very
hard
time
and
reliability
requirements
on
the
network
so
and
you're
looking
for
more
lightweight
different
scoped
solution
for
probably
soft
switch
over
right
with
interruption
in
the
middle
or
so
so.
J
That's
why
the
the
better
understand
the
use
case.
I
think
the
more
easy
it
would
be
to
to
give
more
recommendations
what
you
had
seemed
to
be
top
down.
So
I
think
you
haven't
arrived
at
the
network
level
or
we're
having
things
like
that
net
and
then
appropriate
routing
technologies.
For
that
obviously,
ieee
tsn
is
there
as
well
so
yeah.
There
are
multiple
levels
where
you
can
look
at
things.
A
Michael
richardson
at
the
mic,
thank
you
for
coming
to
us
with
this.
This
is
really
actually
quite
exciting.
The
ietf
is
always
looking
for
operators
to
help
and
participate
in.
A
You
know,
figuring
out
where
things
go,
and
in
this
sense
you
guys
very
much
are
operator
or
proxy
for
operators,
and
you
have
lots
of
nice
logos
on
the
bottom,
which
is
something
we
don't
always
do,
but
anyway,
the
the
the
the
thing
here
is,
though,
that
all
of
those
things
that
you
said
are
really
good,
but
actually
what
would
be
help
us
the
most
and
probably
help
you
is
to
contribute
to
those
working
groups.
A
The
use
cases
that
you
need
to
fulfill
so,
even
though
whatever
the
rat's
architecture
is,
for
instance,
pretty
much
done.
That's!
Okay!
If
you
come
along
and
say-
and
this
is
our
use
case-
and
it
doesn't,
how
does
it
fit
into
this,
and
maybe
it
does-
and
maybe
it
doesn't-
and
it's
okay-
that
if
we
missed
your
your
specific
case,
it
doesn't
mean
it's
it's
you
know
illegal
or
something.
It
simply
means
that
no
one
contributed
it
yet.
A
So
I
think
that
would
be
really
do
good
and
I
would
be
really
excited
to
to
have
you
in
all
of
those.
You
know
different
groups
and,
yes,
as
turtles,
says,
det
net
and
other
all
sorts
of
stuff,
and
it
sounds
to
me,
like
you,
have
a
multitude
of
different
things
and
there's
a
little
bit
of
what's
the
right
word.
Well,
we
can
just
build
it
with
everything
right
kind
of
thing
that
that
I
I'm
concerned,
but
you
know
so
you'll
have
to
figure
that
out.
What
is
what
is
enough?
A
Do
you
need
quick
and
mptcp?
Probably
not
maybe
maybe
sdns.
Maybe
sdn
is
actually
a
failure,
because
you
have
a
single
point
of
failure
and
you
really
want
to
run
ospf
in
the
end.
Actually,
and
that's
good
enough,
I
don't
know
I
have
experience
with
voip
networks
where
people
try
to
do
stp
for
voip
failover
and
it
doesn't
work
because
it's
multiple
seconds
you
need
to
run
ospf
to
get
and
have
equal
cost
multipath
for
voip.
You
can't
do
that
way.
A
That's
kind
of
things
that
you
will
hear
and
if
you
come
to
the
ihf
and
talk
about
your
requirements
in
the
different
areas
there,
so
I
think
you
guys
have
a
very
a
busy
schedule
ahead
of
you,
where
you'll
have
to
go
to
five
or
six
different
areas
and
three
or
four
groups
within
that
area.
So
it
should
be
very
exciting
for
you.
May
you
live
in
interesting
times.
D
Yeah
so
we've
like
two
minutes
left
for
two
minus
the
minutes
left
for
two
people
so
go
ahead.
S
This
is
dave
robin
I'm,
I'm
curious
to
know.
I
I
agree
with
your
work
today.
I've
done
a
lot
of
work
with
smart
grid,
so
I
appreciate
the
real-time
aspect
of
some
of
it.
The,
inter
most
thing
interesting
thing
I
wrote
down
from
the
presentation,
is
this
concept
of
simultaneous
action,
and
that
is
a
problem
that
is
maybe
solved
in
a
different
way
and
I'm
not
sure
whether
you
did
net
or
other
methods
of
reliable
multi-path
everything
you
can
think
of
to
get
messages.
S
But
at
the
moment
that
you
require
some
action
to
take
place
in
two
places
the
network
could
drop,
and
so
so,
if
that
is
really
your
problem,
then
you
have
to
solve
that
in
a
different
way.
We've
done
that
with
with
pre-negotiated
time,
synchronized
actions.
In
other
words,
we
can
negotiate
one
second
from
now.
This
will
happen.
All
sides
acknowledge
then
at
that
moment
it
happens,
but
the
network
could
drop
at
the
moment,
you're,
not
actually
basing
the
action
on
a
message
at
that
point.
S
S
S
P
Yeah
so
dave
had
the
right
question
and
I
think
I
would
really
like
to
encourage
you
to
actually
look
at
your
use
case.
P
As
michael
said,
try
to
identify
the
the
sub
problems
there
talk
to
us
about
applying
the
right
technology
for
that,
and
then
your
contribution
really
could
be
finding
out
whether
the
components
that
we
have
developed
actually
are
solving
your
problem
or
not
now
that
that
is
part
feedback
to
a
working
group
who
has
just
been
doing
that
work,
but
it's
also
research,
and
I
would
like
to
point
out
that
there
is
actually
a
research
group.
P
That's
interesting
research
group
that
is
very
interested
in
research
in
in
this
space,
and
as
dave
mentioned,
there
are
some
application
layer
issues
that
that
also
are
interesting
and
may
have
to
figure
in
here.
So
maybe
we
should
look
at
this
in
the
thinking
research
group
in
some
future
meetings.
G
N
That
was
easy,
okay,
so
this
is
a
little
bit
different
to
what
you
have
seen
just
in
the
last
few
sort
of
minutes,
in
the
sense
that
I'm
presenting
to
you
of
work
that
is
done
elsewhere
in
the
u2a
group
on
tls
and
dtls
profiles
next
slide,
and
I
would
like
to
create
a
little
bit
of
awareness.
And
hopefully
some
of
you
are
actually
using
or
deploying
iot
devices
and
are
securing
those
with
dls
and
dtls.
And
I
would
like
to
get
your
feedback
as
a
reminder.
N
N
And
if
you
looked
at
that
rfc,
it
provides
a
lot
of
guidance
on
how
to
use
algorithms
and
extensions
in
the
iud
context,
because
for
dls
there
is
obviously
a
lot
of
choice
in
terms
of
extensions.
Not
all
of
the
extensions
can
be
arbitrarily
combined
to
make
sense
or
even
are
then
consequently
secure
and
some
of
them
obviously
date
back
to
earlier
days.
So
they
are
not
a
good
choice
to
begin
with,
and
that's
what
the
document
explains.
N
We
also
made
some
sort
of
profiling
of
dls
in
this
in
this
document.
That's
why
iod
profiles,
for
example,
when
it
comes
to
the
timeout
values,
the
dls
specification
provides
some
guidance
for
use
in
a
generic
internet
on
the
web
in
particular,
and
leaves
it
open
to
other
application
domains
to
change
those
values
and
that's
what
that
document
did
and
and
also
as
a
sort
of
smaller
thing.
N
It
also
describes
on
how
to
use
ddls
over
sms
the
on
in
the
appendix
okay,
so
that
was
1.2
and
it's
finalized
and
everything
great
and
people
are
using
it,
and
there
are
a
number
of
implementations,
production,
quality,
implementations
and
the
big
iot
cloud
guys
use
that
stuff
next
slide,
so
fantastic
and
then
dls
1.3
came
along
and
and
the
work
on
this
on
this
profile
started.
N
Luckily,
of
course,
there's
all
the
algorithm
recommendations
for
1.3,
obviously
current.
So
there's
this
led
to
a
much
shorter
document,
but
there's
still
a
few
things
that
can
be
said
about
1.3,
specifically
now
as
sort
of
the
embedded
implementation.
I've
also
picked
up:
1.3,
wolf,
ssl
and
empty
ls
have
a
1.3
implementation,
so
you
there
are
people
who
use
1.3
in
their
iot
deployments,
so
so
that's
also
a
good
development.
N
Many
of
the
recommendations
can
be
carried
over
from
the
other
rc
that
I
just
mentioned,
but
of
course
there
are
some
nuances
and
some
differences
with
1.3
compared
to
1.2,
of
course,
for
example,
in
the
post
handshake
the
resumption
cases,
there's
we
added
in
the
mean
by
the
connection
id
there's
the
possibility
to
use
the
encrypted
client
hello.
N
If
someone
cares
a
lot
about
the
privacy
protection
and
the
like,
there
is
also
an
application
profile
for
use
of
the
co-op
protocol
with
the
zero
rdd
exchange,
because
that
doesn't
provide
replay
protection
in
the
in
the
dls
handshake.
So
you
have
to
what
the
dls
specifications
calls
out
that
you
have
to
provide
a
story
there.
N
There
is
a
story
in
an
in
a
separate
document
for
http,
and
this
is
the
the
document
that
does
the
same
for
co-op,
and
one
thing
that
is
still
a
sort
of
a
controversial
aspect
is
the
choice
of
or
the
recommendations
for,
algorithms,
specifically
related
to
the
use
of
aes
with
the
mode
of
operation
and
ccm8,
which
has
a
shorter
authentication
tag
where
this
document
currently
recommends
to
use
gcm
and
ccm
with
the
long
authentication
tag
instead
of
the
of
the
shorter
ones.
N
So
that's
a
little
bit
controversial,
because
that
was
the
preferred
algorithm
in
in
sort
of
the
iod
circles
in
the
idf
previously,
so
we
are
gradually
moving
away
from
that,
but
this
is
not
cast
in
stone
yet
so,
obviously,
if
you
work
in
that
space
and
and
deploy
that
algorithm,
we
would
obviously
like
to
hear
from
you
the
ddls.
N
The
upcoming
or
dtlsrc
also
discourages
ccm8
yeah
for
security.
So
okay
next
slide,
so
there's
a
lot
of
stuff
in
there,
and
so
the
big
ask
to
you
is
like.
Are
you?
Are
you
using
tls
1.3
already
in
your
deployments,
in
your
iot
deployments?
And
if
so,
let
us
know
whether
you
stumbled
across
a
few
things
or
whether
you
find
some
of
the
recommendations
in
there
useful
or
also,
if
you
don't
find
them
useful,
then
obviously
we
want
want
to
hear
as
well
from
you.
N
So
this
is
more
sort
of
geared
towards
the
ones
who
are
actually
doing
it
rather
than
sort
of
thinking
about
it.
N
Yes,
exactly
yeah.
The
uca
working
group
is
the
right
place
to
discuss
those.
J
Yeah
cause
eckerd,
so
I
haven't
read
that
so
that
that
looks
quite
interesting
in
the
anima
working
group,
when
we
were
trying
to
you
know,
go
through
security
review.
J
I
was
fighting
long
and
hard
not
to
have
tls
1.3,
which
was
fresh
out
of
the
door
by
the
time
we
did
the
rfc
being
mandated,
but
just
1.2,
just
in
fear
of
not
knowing
what
speed
of
you
know,
availability
of
tls
1.3,
I
would
have
in
the
arbitrary
low-end
equipment,
primarily
iot,
so
would
really
be
good
to
hear.
You
know
some
some,
some
more
insight
from
from
you,
folks
that
understand
that
iot
equipment
right
at
which
point
in
time
you
know
for
any
type
of
solution:
environments
like
anima,
brewski,
bootstrap.
N
Yeah
yeah,
as
I
mentioned,
like
obviously
the
1.
two
sort
of
stacks
are
very
common,
but
if
you
switch
over
to
1.3
on
the
server
side
and
on
the
web,
it's
obviously
widely
deployed.
There
are
lots
of
stacks
available,
so
you
are
you're
really
good
there,
but
when
it
in
the
embedded
space,
everything
takes
a
little
bit
longer
development,
wise
and
but
luckily
you
can
get
commercial
stacks
in
in
the
meanwhile
and
yeah.
So
so
they
are
like
high
quality
implementations,
very
performant
integrated
with
hardware
and
so
on.
N
D
Maybe
I
can
have
a
final
comment
so
if
the
duplicate
the
application
of
ccm8
is
a
topic
to
you
that
has
been
raised
by
thomas
recently
just
on
the
core
working
group
list
again.
So
if
you
have
an
opinion
about
that
now's,
the
time.
G
Okay,
so
we
use
up
a
little
bit
more
time
than
we
expected,
but
I
think
that's.
Okay,
we
had
a
bit
of
spare
chairs
are
starting
to
think
about
after
a
year
of
running
iut
orbs
of
documents
to
adopt,
obviously
we'll
will
have
a
discussion
in
the
working
group.
H
So
I
originally
presented
this
document,
I
guess
two
ietfs
ago,
and
and
then
I
let
it
expire
next
slide.
Please
and
the
reason
for
this
is,
is
kind
of
rolled
up
into
what
security
documents
actually
are.
So
I
I
have
come
to
the
conclusion
that
security
documents
always
trend
towards
one
of
three
things:
they
either
become
an
architecture,
a
threat
model
or
a
document
that
details
requirements
or
mitigations
next
slide.
Please.
H
H
So
I
I
had
to
to
ask
the
question
sort
of
you
know:
where
does
this
document
go
next,
and
this
is
why
I
let
it
expire
it?
It
really
needs
an
architecture
or
a
threat
model,
but
it
didn't
make
sense
to
just
constrain
that
to
only
the
problems
that
were
addressed
in
the
in
the
iot
nets
draft
it,
it
was
really
that
would
have
left
it
very
limited,
and
I
didn't
see
why
we
should
leave
it
there
it.
H
It
actually
strikes
me
that
we
should
start
considering
what
an
iot
architecture
and
an
iot
threat
model
would
be
something
a
much
higher
level.
H
But
the
question
is:
where
would
these
end,
because
those
could
be
massive
documents
next
slide,
please,
so
enisa
did
produce
this
iot
best
practices
document,
and
that
covers
a
lot
of
this.
This
space
and
arms
psa
documents
cover
a
lot
of
the
device
side
architecture
for
doing
this
kind
of
security.
A
H
What
I've
realized,
though,
is
that
we
can't
do
a
top-down
structure,
and
I
don't
think
it
makes
sense
to
define
an
architecture
and
then
define
a
threat
model
and
then
define
mitigations,
because
each
architectural
element
adds
new
threats
and
each
threat
adds
new
mitigations
and
each
mitigation
adds
new
elements
in
the
architecture,
so
we're
going
to
end
up
with
through
you
know.
If
we
go
through
this,
it
will
end
up
with
three
tightly
coupled
documents
and
they'll
all
have
it'll
be
a
cluster.
That's
all
there
is
to
it.
H
I
think
they
all
have
to
be
developed
together
next
slide.
Please.
H
Now
that
being
said,
I
think
that
this
would
end
up
being
something
very
hierarchical.
So
there
are
many
security
area
working
groups
that
are
already
working
in
parts
of
these
problems.
There
are
some
architectures
and
some
threat
models
in
many
of
the
different
iot
working
groups,
and
I
don't
think
we
need
to
reproduce
any
of
that
work.
H
All
in
one
group
that
allows
a
the
the
information,
the
reference
integrity
manifest
the
co-rim
to
be
delivered
to
a
verifier
signed
by
the
firmware
author,
so
that
when
it
gets
an
attestation
report,
it
no
already
has
the
verification
information
to
to
verify
it,
and
that's
a
really
interesting,
a
really
interesting
more
than
the
sum
of
its
parts
kind
of
situation
next
slide,
please.
H
I
think
that
we
could
have
an
opportunity
here
to
describe
relationships
between
entities
from
different
standards.
There's
a
lot
of
places
where
standards
leave
things
open-ended.
They
don't
describe
relationships,
they
leave
things
up
to
the
implementer,
but
there's
this
overarching
view
that
many
of
us
have
about
where
these
these
relationships
should
be
described
and
which
what
kind
of
implementations
should
be
used
by
an
implementer.
But
this
isn't
really
documented
a
lot
of
the
time.
H
I
think
that
we
have
an
opportunity
there
to
explain
exactly
how
many
of
these
standards
should
be
used
together
and,
as
I
previously
gave
you
the
example
for
more
details
provided
to
attestation.
Verifiers
is
a
good
example
of
this
next
slide.
Please
now
there's
a
couple
of
different
iot
architectures
that
we
probably
will
have
to
describe.
H
So
you
have
the
centralized
architectures
where
you
have
one
authority
or
a
group
of
authorities
and
communication
passes
via
those
authorities
or
their
delegates
or,
alternatively,
you
have
peer-to-peer
architectures
that
are
decentralized
and
don't
have
authorities.
Now,
that's
a
very
wide
separation
next
slide.
Please.
H
So
I
don't
think
that
most
of
them
will
end
up
being
that
extreme.
I
think
that
we
have
will
primarily
have
hybrid
architectures,
so
we
have
to
describe
essentially
where
the
the
benefits
and
drawbacks
are
in
the
architectures
for
these
different
modes
of
hybrid
construction.
Next
slide,
please
that's
it!
Okay,
I
I
did
it
fast.
So
we'd
have
time
for
discussion.
D
Which
is
great
so
michael,
your
first
line.
A
Hi,
michael
richardson,
so
actually
so
I
had
a
thought
sitting
here
that
brendan
with
the
same
slides
and
the
same
words
had
it
been
ted,
lemon
or
lorenzo
speaking
to
us
that
we
would
understand
everything
very
differently
and
he's
a
brendan
has
a
very
security
and
attestation
point
of
view.
A
But
if
it's
lorenzo
speaking
to
us,
we
would
understand
this
was
about
ipv6
connectivity
and
yet
you
could
have
used
the
same,
slides
and
the
same
words
and
all
the
stuff
and
the
architectures
and
the
mitigations
and
all
this
kind
of
stuff
and
that's
kind
of
intro.
What
I
wanted
to
say
back
at
the
tableau
thing
was
I
you
know,
I
quipped
that
all
the
examples
were
ipv4
and
someone
said
well,
that's
actually
because
operational
plants
really
aren't
lost
in
ipv4.
A
But
but
a
thing
I
wanted
to
say
then-
and
I
think
I
want
to
say
now
again-
is
that
none
of
those
layers
of
firewalling
were
ever
designed
as
firewalls.
Those
were
all
designed
as
nat
four
fours,
because
there
was
no
architecture
that
allowed
anybody
to
plug
new
pieces
of
network
into
the
existing
network.
A
That's
not
just
a
security
diagram,
it's
actually
an
ietf
wide
diagram
and
the
problems
we
have
in
iot
is
that
we're,
basically,
you
know,
got
our
fingers
in
27
different
camps
at
the
same
time
trying
to
integrate
it
and
the
reason
why
tableau,
for
instance,
is
either
very
wishful
or
very
enlightened
is
because
effectively
we
need
to,
as
I
think
elliot
said,
we
need
to
actually
be
able
to
map
all
of
those
things
together,
and
so,
while
I'm
trying
not
to
boil
the
ocean
here,
I
actually
think
there's
some
things
that
we
can
say
involving
security
and
networking
and
connectivity
at
the
same
time
and
things
that
we
can
say.
A
Well,
you
should
do
it
this
way
like
that
tableau
backbone.
Honestly
should
be
ipv6
and
all
the
pieces
plugged
into
it
should
be
nat,
64,
okay,
because
they
are
living
in
v4
space
and
that's
actually
an
architecture
that
I
would
propose,
and
it
actually
has
really
good
security
properties
that
that
I
think,
are
relevant
to
things,
and
so
I'm
excited
about
this,
and
I
think
that
we
want
to
go
ahead
with
what
you
just
said.
I'm
very
enthusiastic.
I
don't
I
guess
I
don't
have
any
questions
for
you.
A
D
Q
Thank
you,
oh
hank,
okay,
so
brandon,
no
michael,
I'm
not
going
to
say
I'm
actually
going
to
slightly
disagree
with
both
of
you
in
that.
Quite
honestly,
I
liked
what
you
did
brandon.
It
basically
showed
how
all
the
parts
fit
together
in
in
your
initial
draft.
Q
I
think
that's
a
substantial
advance,
so
I
don't
want
to
get
mired
in
in
overthinking
the
the
way,
if
you
want
to
present
this
in
a
different
way,
I'm
all
for
it.
But
you
have
a
good
starting
point
and
we
should
go
with
that
and
if
you
want
to
restructure
the
starting
point,
I'm
okay
with
that,
but
I'm
not.
I
I'll
tell
you
what
it
would
be
a
shame
if,
if
we
lost
that
view
that
you
presented.
R
G
So
the
other
thing,
if
I'm
not
mistaken,
brandon
you
wanted
to
see
if
there
are
some
people
who
would
like
to
help
you
out
with
this.
H
Well,
I
mean
if
this
is
something
that
the
that
the
working
group
is
actually
interested
in
then
yeah.
Absolutely
it's
it's
a
it's
a
big
undertaking.
I
don't
think
I
can
do
this
myself,
but
that
being
said,
if
this
isn't
something
that
the
working
group's
interested
in
then
then
that's
fine
and
I
guess
to
elliott's
point.
I
don't
see
a
reason
that
we
couldn't
you
know
progress.
H
The
work
that
I
I
had
done
is
just
that
when
I
tried
to
restructure
it
into
you
know
to
to
explain
why
I
was
putting
things
together,
the
why
led
to
a
threat
model
and
the
threat
model
pointed
to
a
missing
architecture
and
that
sort
of
did
mire
me,
and
he
had
essentially
mentioned
that
what
he'd
like
was
essentially
a
table
of
the
things
that
could
go
wrong
and
how
these
different
combinations
of
technologies
fixed
them,
and
that
is
a
threat
model
right.
That's
a
threat
model
and
an
information
model.
H
So
I
was
attempting
to
put
that
all
together
and
that
sort
of
pointed
me
to
this
bigger
question.
D
I
I
agree
with
elliot
that
the
the
first
draft
of
yours
is
like,
like
the
cornerstone,
and
I
have
unfortunately
to
agree
a
a
a
frosting
of
a
threat
model
and
a
requirement
said
about
it
is,
is,
is
required
for
initial
work,
but
you
don't
have
to
again
take
all
of
it
in
because
there
was
also
mentioning
like
the
plc,
has
the
same
problem,
so
maybe
scope
it
to
what
you
just
had
at
a
very
specific
type
of
threat,
model
and
requirements
to
that,
and
I
think
that
is
already
a
big
scope,
so
maybe
maybe
do
not
exceed
that.
M
Just
a
comment
from
my
part,
as
far
as
I
understood
everything
right,
I
had
the
the
yeah
imposition
so
to
speak
to
actually
goes
through
different
standards
like
iso
2701,
six
iec,
six,
two
four,
four:
three
bse
gunshots
and
itc
right
catalog,
which
is
also
relevant
in
german-
to
put
all
the
security
measures
together
which
are
needed
for
foreign
industrial
control
system,
and
it
was
the
worst
kind
of
work
I
ever
ever
have
to
do,
and
it
was
quite
annoying
so
everything
which
kind
of
aggregates
stuff
into
something
that
can
be
evulated
evaluated
and
does
relieve
me
from
these
kinds
of
work.
M
J
At
all,
checkered
again,
so
I
hope
I
have
some
fun
closing
remarks.
Rent
rand
rand
rant,
so
I
think
we're
playing
here
in
the
iitf
for
decades,
some
harry
potter
game
around
voldemort,
don't
name
the
name
and
it's
the
firewall
right.
So
I
mean
we've
seen
one
presentation
here
today
about
what
I
think
ultimately
will
turn
out
to
be
some
form
of
distributed
firewall
architecture.
J
This
one,
I
think,
has
you
know
security
functions
for
filtering
in
the
network,
firewall
voldemort
right,
written
all
over
it
as
as
part
of
the
architecture.
We
have
done
great
work
on,
let's
say
the
whole
mud
stuff
right.
You
know
how
do
I
know
what
a
oops
firewall
should
do
and
I
was
asked
to
review
performance
measurements
for
oh
security
gateways
right,
it's
not
called
firewall
so,
but
I
mean
we're
we're
not
having
an
architecture.
We're
not.
You
know
openly
admitting
that
there
is
voldemort
oops
firewall
right.
J
So
what
what's?
What's
the
strategy
of
dealing
with
these
things?
Do
we
want
to
continue
kind
of
just
trying
to
scrap
some
bits
and
pieces
on
on
every
edge,
or
you
know
in
iot
they're,
just
front
and
center
center
everywhere
in
these
networks
and
a
lot
of
it
very
useful,
a
lot,
probably
very
painful,
so
I
think
it's
you
know
in
whatever
shape
or
form
we
do
it.
I
think
it's
it's
that
that
particular
type
of
middle
block
function
is,
is
really
front
and
center
for
something
like
iot
ops.
J
I
don't
know
exactly
how
to
answer
to
it,
but
doing
it
indirectly,
just
as
a
side
topic
through
an
arbitrary
set
of
of
documents
may
not
be
sufficient
enough
right,
so
you
know
firewalls
in
iot
right.
So
what's
what's
kind
of
the
io,
the
the
ietf
position
on
that?
Maybe.
H
So,
okay,
I
have
an
answer
for
that.
If
we
have
time,
my
answer
would
be
essentially
that
you're
absolutely
right.
We
definitely
need
to
focus
on
the
firewall
for
a
portion
of
the
problem
and
that
portion
is
probably
exactly
as
it
relates
to
mud.
Mud
is
absolutely
dynamic.
Firewall
configuration
probably
also
dynamic
layer,
3
switch
configuration,
but
that's
maybe
less
relevant
on
wireless
networks.
So
so
we
can't
make
this
a
dialogue
anymore,
because.
D
We
are
plus
minute
minus
one
minute,
but
what
I
hear
is
a
a
quick
draft
that
says:
why
is
this?
A
firewall
might
be
useful
to
get
yeah.
D
So
sorry,
for
breaking
this
up
anything
is
a
great
discussion,
guys
there's
this
list
iot
ops
at
itf.org.
Let's
meet
all
there,
you
might
have
an
interim.
We
will
plan
that
we
will
give
a
shout
out
and.
G
Yeah-
and
I
think
it's
probably
safe
to
say
that
we'll
spend
a
bit
more
time
talking
on
specific
deliverables
next
year.
Yes,.
D
No
not
only
next
time,
but
we
will
mold
a
deliverable
from
this.
So
if
we
heard
names-
and
we
make
that
thing
until
the
next
meeting.