►
From YouTube: IETF95-OPSEC-20160405-1620
Description
OPSEC meeting session at IETF95
2016/04/05 1620
A
A
C
D
D
D
D
D
D
So
then,
going
on
words
before
we
actually
start,
so
we
did
not
really
have
a
meeting
at
the
previous
two
I
etfs.
Another
new
element
is,
you
know.
I
would
like
to
formally
thank
it.
Also
the
Kiran
Kumar
cheetahmen
any
who
has
been
the
object
culture
for
quite
a
couple
of
you
know
for
quite
some
time.
So
thanks
actually
playing
for
you
know
all
this
effort,
and
you
know
making
this.
You
know
working
group
quite
a
success
actually
during
this
time.
D
So
thank
you
and
also
would
like
to
introduce
a
new
coach
at
editing
sitting
here
next
to
me,
so
welcome.
Thank
you
so
and
also
it
is
coming.
You
know
the
the
expiration
is
that
you
will
see
you
know
the
last
couple
of
months.
The
interaction
on
the
email,
alias
has
been
relatively
light,
and
you
know
with
the
arrival
of
etiquette.
You
know,
the
intention
is
that
it
will
become
like
super
active
again
and
now
with
lots
of
interesting
discussions
and
interesting
topics.
D
You
know
going
forward
so
also
in
the
you
know
between
about
a
year
ago,
and
now
we
actually
did
have
like
two
rfcs
published
so
RFC
7610,
which
is
also
a
bcp,
and
we
also
had
RFC
7707
published
here
for
the
rest,
the
remaining
work-
it
is,
you
know
nothing
really
in
iesg
processing
and
not
really
anything
else.
You
know
happening
as
such
at
this
point
in
time.
E
So,
let's
start
the
sharing
of
the
mic
here
as
you
enter
s
set
little
traffic
on
the
email
list,
but
at
least
we
have
now
two
new
brand
new
and
draft
in
this
upset
working
group
that
will
be
presented
today.
So
they
are
new
life
coming
in
upside
there.
And
if
you
look
about
the
Charter
and
the
milestones
page
on
the
website,
all
the
milestones
has
been
completed,
meaning
that
all
documents
are
becoming
now
RFC
and
Matt.
If
you
look
at
the
Charter,
the
job
is
not
yet
done.
The
goal
are
not
finished
and
nothing.
E
It's
kind
of
normal
for
this
kind
of
working
group
to
continue
the
work
as
long
as
we
are
deploying
networks
and
deploying
new
photo
cards
and
your
system-
and
we
welcome
your
feedback
here
on
this
one,
so
agenda
bashing,
I
miss
ravier,
that's
what
we
are
doing.
We
will
get
Daniel
speaking
about.
Second,
that's
another
working
room,
but
we
think
that
op
SEC
is
a
working
group
is
a
ton
of
the
border
between
operation
and
security.
E
So
when
we
see
some
draft
from
the
security
adding
in
a
personal
impact-
and
vice
versa,
I
think
is
very
important-
that
we
get
presentation
of
those
draft
by
the
authors
in
this
working
group.
Even
if
they
are
documenting
other
working
groups,
then
we
we
see
a
removed,
so
cross
fingers
with
it
will
be
working
and
our
speaker
is
based
out
of
Japan.
E
So
if
you
do
the
math,
it's
very
very
dark
knight
ways
now
and
it
will
be
about
the
threat
analysis
about
all
the
pv6
transition
technique
and
we
present
the
work
done
by
kk
and
mary
kay
about
OPSEC
for
pv6.
This
will
be
one
hour
in
total,
then
a
short
break
of
20
minute
if
at
mistaken,
and
we
continue
with
Stefan.
So
we
need
to
find
another
minute
taker
for
why
presenting
a
brand
new
draft
as
well
I
know,
will
present
MLD
security.
E
E
F
F
Better
here
we
go
back
real
quick,
so
this
basically
for
a
quick
introduction.
You
know
I
work
primarily
in
the
sack
and
working
group,
which
is
a
security
automation
in
continuous
monitoring
working
group
and
basically
we
are
chartered
to
develop
data
models
and
protocols
for
endpoint
posture
assessment
and,
as
we
found
out
in
working
this
area,
it's
a
very
broad,
broadly
defined
space,
and
we
ran
into
some
challenges
just
trying
to
focus
on
a
particular
problem
and
that's
kind
of
where
this
vulnerability
assessment
draft
came
into
play
so
give.
F
We
have
to
you,
know,
get
this
information
off
the
endpoints
that
may
be
software
inventory
data.
You
know
what
software
is
installed,
what
hardware's
on
your
endpoints
and
also
the
different
configuration
states
of
that
software
in
basically
the
interaction
you
know,
then
points
report
to
the
server
which
can
then
put
that
information
in
the
repository,
and
you
can
do
a
shin
and
we'll
talk
about
that.
A
little
bit
more
detail
after
in
so
basically
the
assessment
scenario,
the
use
case
breaks
down
into
a
few
different
steps.
F
The
first
is,
you
know,
knowing
what
endpoints
you
have
on
your
network
being
able
to
identify
them,
and
then
this
the
next
part
of
that
is
basically
in
a
kind
of
an
ongoing
basis,
which
we
don't
specify.
You
know
what
that
basis
is
collect.
Information
on
your
end
points,
and
this
kind
of
gives
you
knowledge
about
those
in
endpoints
that
you
have
identified
on
your
network
then.
F
So
the
next
part
is
the
vulnerability,
description
data
and
that's
like
I,
said
it's
basically,
the
security
advisory
and
then
there's
endpoint
applicability
and
assessment,
which
is
basically
determining
burst.
Is
this
vulnerability
description,
data
or
security
advisory
applicable
to
my
endpoint?
And,
if
so,
do
I?
Have
information
I
need
to
make
the
determination
of
whether
or
not
it's
in
a
vulnerable
state
or
do
I
have
to
go
and
find
additional
information
and
make
an
assessment?
And
then,
lastly,
how
do
I
present
that
information
or
the
results
of
that.
F
F
Use
cases
so,
as
I
said
in
the
beginning,
you
know
what's
a
comb,
it
was
a
very
broad
area
and
we're
having
trouble
kind
of
making
progress
and
we
decided
that
if,
if
we
come
together
and
focus
on
a
very
small
piece
of
that
that
problem
space
we
can
just
work
from
there
drive
it
to
a
to
the
data
models
and
protocols.
We
need.
You
know,
understanding
that
you
need
to
leave
room
for
extensive.
F
You
know
to
extend
those
protocols
and
data
models
for
our
other
needs,
but
really
just
try
to
work
that
to
the
to
the
end,
and
so
far
it's
you
know.
It's
helping
us
focus
our
work
much
better
in
at
the
end
of
the
day.
As
part
of
this
scenario,
we
use
it
to
you
know,
get
input
from
people
actually
are
going
to
have
to
you
know
or
want
to
use
this.
These
data
model
some
protocols
to
understand
you
know
what
information
do
we
need
to
collect
off
the
endpoints?
F
You
know
what
are
the
different
interactions
between
the
different
components.
You
know
throughout
the
lifecycle
of
this
scenario
and
try
to
understand
what
protocols
kind
of
fit.
That's
that
area-
and
you
know
just
kind
of
how
it
all
works
together,
really
with
the
end
result
of
being.
You
know,
really
just
you
know,
focusing
our
work
to
solve
this
particular
problem.
F
So
if
you
guys
know
who's,
read
the
draft,
but
there's
a
handful
of
assumptions
that
we
go
through
with
that
with
this,
mainly
because,
if
we
don't
do
that
again,
it
becomes
a
very
intangible
problem.
So
by
scoping
it
down,
we
just
worked
a
really
kind
of
site.
Our
focus
in
some
of
the
big
ones
are
that
we
don't
really
talk
about
how
an
organization
decides
which
vulnerability
description,
data
it
wants
to
use.
F
What
that
vulnerability
description
data
looks
like
that's
all
kind
of
just
assumed
that
an
organization
can
get
that
information
and
put
it
into
a
format
that
its
tools
can
use,
and
it
can
make
a
determination
whether
or
not
the
endpoint
is
in
a
vulnerable
state
and
then.
Lastly,
we
also
assume
that
you
know,
obviously
the
enterprises
have
a
way
to
collect
information
off
their
system
or
they're
in
points,
and
also
evaluate
it
to
make
this
determination
there's
some
other
assumptions,
but
those
are
the
few
big
ones.
F
So
the
first
part,
as
I
mentioned,
was
the
employee
identification
then,
and
in
data
collection,
and
in
really
you
know,
in
order
to
collect
information
off
your
endpoints,
you
need
to
know
what's
there
and
this
may
come
in
the
form
of
you
know.
When
you
put
an
end
point
on
your
network,
you
may
have
some
step
that
kind
of
registers
it
with
with
your
enterprise,
or
you
may
be
getting
this
information
from
external
sensors.
F
Looking
at
you
know,
traffic
on
your
network
and
say:
okay,
I'm
getting
you
know,
packets
from
this
particular
endpoint
in
you
have
an
idea
of
you
know
what
what's
out
there
and
you
want
to
look
at
things.
You
know
obviously
like
IP
address
back
here,
so
those
are
kind
of
some
of
the
you
know
very
basic
identification
information
that
we
care
about.
F
Of
course,
at
the
end
of
the
day,
it's
going
to
very
much
very
independent
on
your
enterprises
particular
deployment
situations,
and
so
basically,
once
you
have
that
you
want
to
take
that
information
and
put
in
a
repository
where
you
can
either
you
know,
use
it
right
away
or
you
know,
use
it
to
do.
Follow
follow-up
evaluations.
So,
right
now
we're
focused
on
determining
whether
or
not
an
endpoint
is
vulnerable,
but
you
may
want
to
use
the
same
data
to
determine
you
know
just
what
software
do
you
have
installed
across
your
enterprise?
F
F
F
You're
vulnerable
things
like
that
in
really
what
you
need
to
do
is
once
an
organization
takes
that
in
you
want
to
put
that
somewhere,
because
you
one
may
not
want
to
you
know,
perform
all
these
assessments
right
away
or
you
may
want
to
so
that's
one
part
of
it
and
then
the
other
part
is
basically
you
know
you
need.
You
want
to
keep
a
record
kind
of
the
different
vulnerability
description
data
over
time
because
one
it
may
be
updated
by
the
vendor
or
you
may
just
want
to
keep
it
for
historical
purposes.
F
Saying
oh
I
did
an
assessment
at
this
time.
This
was
my
results.
Here's
what
I
use
to
drive
those
that
assessment
and
then
so
after
that,
as
part
of
that
bomb
description
ditty,
you
may
also
be
able
to
look
at
you
know.
Basically
what
initial
data
you
collect
it
off
the
end
point
and
say:
okay:
does
this
particular
below
in
video
description
data
apply
to
me
right?
F
However,
in
some
cases
that
it
no
it's
not
that
easy
to
determine
whether
or
not
something
is
wrong.
It's
not
always
just
a
software
version
to
look
at.
You
may
need
to
check
some
registry
setting
or
something
like
that,
and
basically
we
want
to
enable
some
secondary
assessment
where
you
can
go
out,
and
you
know
ask
that
endpoint,
you
know,
what's
your
state
for
this
in
you
pull
that
information
back
to
to
make
that
final
determination
and
then
lastly,
is.
D
F
F
Because,
maybe
you
had
old
data
and
you
know
that
can
potentially
throw.
F
H
F
Protocols
were
working
on.
Does
this
and
potentially
to
be
used
and
I'm
not
going
to
go
over
that
now,
because
I'm
going
to
talk
about
that,
a
little
bit
more
detail
tomorrow
at
the
sac
obsession,
but
all
this
kind
of
give
you
a
quick
overview
of
the
actual
solutions
that
we're
working
on
so
that
the
first
thing
is.
F
We
need
a
way
to
exchange
this
information
between
our
endpoints
in
the
server
and
what
we're
looking
at
to
do
that
to
do
that
with
is
basically
the
NIA
protocols
which
are
out
of
the
ITF
as
well
as
some
additional
TCG
specifications,
and
really
this
is-
is
kind
of
outlined
in
how
to
use
this
as
outlined
in
the
end
point
compliance
profile,
which
is
another
TCG
fact
that
was
submitted
to
the
IETF
and
really
it
shows
you
know.
How
do
you
use
Nia?
F
That's
a
an
extension
to
the
NIA
panc
protocol
to
support
carrying
sweet
tags
in
addition
to
this,
so
that
cover
is
kind
of
the
software
aspect
of
the
data
collection,
but
there's
also
information
about
the
configuration
of
that
software
and
we
have
brought
in
oval,
which
is
the
open,
vulnerability,
an
assessment
language
as
a
starting
point
for
that.
That
is
a
effort
that
was
been
going
on
for
13
or
so
years,
and
in
doing
so,
we've
learned,
you
know
a
lot
about
it,
a
lot
of
the
challenges
you
know
in
trying
to
use
it.
F
You
know
in
in
an
enterprise,
and
so
we'd
like
to
take
that
work
and
really
build
off
it
and
really
improve
on
you
know
all
those
lessons
learned
we've
learned
over
that
time
and
really
you
know
it's
very
happy
to
come.
Talk
to
you
guys
because
you
guys
have
may
have
more
insight
into
other
standards.
You
know
data
models
and
protocols
that
we
should
be
considering
for
this
work
and
I,
don't
know
if
anyone
has
any.
You
know
off
the
top
of
their
head
or
things
that
you
know
might
be
look
useful
here.
B
F
D
F
Sure
we
have
a
a
very
complete
scenario
that
covers
what
what
people
need
in
their
enterprise
and
I
guess.
I
just
want
to
also
briefly
discuss
two
other
specifications
that
may
be
useful
in
this
area
and
that's
server
discovery
and
validation,
which
basically
allows
provides
a
basic
protocol
that
allows
you
to
determine.
F
You
know
if
you're,
that
endpoint
on
the
network,
how
do
you
find
a
server
and
how
do
you
ensure
that
it's
a
trusted
server
that
you
should
communicate
with
and
then
there's
also
I
FM
segmentation,
which
basically
allows
you
to
break
up
that
data
that
you'd
want
to
send
from
the
endpoints
of
the
server
into
more
manageable
pieces
across
the
network?
That's
primarily
it.
The
last
few
slides
were.
I
Lucy
Lynch
NSR
see
this
draft
has
made
a
lot
of
progress
since
last
time
around
I'm
pleased
to
see
it
scope
to
enterprise
now
I
do
have
some
questions
about
the
security
considerations
and
the
server
discovery
piece
since
there's
a
handshake
there
between
both
the
endpoints
and
the
server
and
I
think
the
server
discovery
mechanism
assumes
that
initial
handshake,
but
given
the
side
channel
possibilities
here,
what
are
you
doing
or
those
endpoints
being
capped
by
an
unknown
server?
So.
I
F
G
A
co-author
actually
on
the
specifications
that
Danny's
talked
about
the
server
discovery
basically
uses
vns
SRV
records
as
a
way
to
identify
the
the
server
that
the
endpoint
will
communicate
with
that
provided
software
inventory
information,
so
it
that
can
be
mitigated
through
things
like
dns
and
other
capabilities
to
ensure
that
only
authorized
dns
servers
are
providing
that
information
to
the
endpoint
can't.
G
One
thing
I
also
wanted
to
point
out
is
one
of
the
one
of
the
existing
areas
of
work.
The
IETF
has
been
doing
within
mile
is
a
draft
called
Rollie,
which
is
a
basically
about
lightweight
information
exchange
using
Adam
hug
as
a
protocol,
and
that's
a
one
of
the
efforts
that
I'm
working
on
to
try
to
address
some
of
the
information
repository
kinds
of
considerations
that
we
need
to
address
to
support
this
scenario.
G
Rowley
and
Adam
pub
can
basically
be
a
method
to
provide
a
repository
of
both
vulnerability
information
as
well
as
sweet
tag,
information,
and
it
potentially
can
provide
a
federation
mechanism
to
allow
vendors
to
publish
their
their
vulnerability
data
and
to
allow
organizations
to
discover
that
information,
probably
ginn
through
SRV
records
associated
with
the
vendors
domain,
identify
the
collection
of
vulnerability,
records,
pool
and
information
down
and
then
use
it
as
part
of
the
scenario
we'll
be
talking
about
that
in
the
mile
session.
Immediately
after
this
one,
if
anyone's
interested.
B
B
Well
I'll
start
by
saying
a
few
things
about
the
history
of
the
dress:
I
I
did
a
presentation
in
1994
at
an
early
stage
of
the
project,
and
at
that
time
I
was
well
thinking
about
writing
this
craft
and
lab
the
suggestion
was
to
associated
with
holder,
upset
working
group
and
gather
that's
how
I
ended
up
presenting
today
here.
So
can
you
move
to
the
next
slide?
Please.
C
B
So
a
bit
about
the
draft
motivation,
I'm
pretty
sure
everyone
knows
by
now.
The
idea
536
is
not
backwards,
compatible
yeah.
That
means
like
the
the
internet
will
have
to
undergo
people
to
which
both
for
80
countries
have
to
co-exist
and
in
them
for
now
only
have
five
percent
of
Internet
users
with
ipv6
connectivity,
which
is
a
problem
considering
that
ipv6
was
introduced
in
1998
almost
20
years
ago.
B
B
As
you
can
see
from
from
this
slide
in
2006,
are
this
is
a
chart
of
the
evolution
after
nation
technologies
in
July
idea
for
a
part
of
the
transition
technologies.
Actually,
you
can
see
there
wasn't
too
much
diversity
at
the
beginning,
but
but
now
there's
a
lot
of
diversity.
So,
aside
from
well
essentially
being
a
problem,
it
got
a
bit
more
complicated
to
diversity,
to
the
diversity
of
the
scenarios
and
the
use
cases,
so
the
implications
are
essentially
more
complex
because
of
it
next
slide.
Please.
B
So
this
this
drop
their
own.
There
are
already
there
is
already
a
published
RFC
or
no
on
the
constant
security
considerations
of
your
using
vacuum
extraction,
consistent
mechanisms,
namely
RFC
49
or
two.
However,
this
draft
is
trying
to
put
the
context
around
the
transition
technologies.
It
also
offers
some
structure
by
proposing
the
stride
cred
classifications
as
the
base
of
of
a
bed
low
fat
red
model.
Also,
we
are
considering
a
generational
classification
of
high
pivot
extraction
technologies,
mainly
few.
B
B
Also,
the
job
contains
a
list
of
stress
and
mitigation
score
for
protocol
associated
ipv6
traction
technologies
that
were
proposed
in
the
IDF
so
and
welder.
Of
course,
the
list
is
not
exhaustive
and
it
contains
some
sometimes
or
it
doesn't
contain,
sometimes
mitigation
solutions,
and
we
will
definitely
we
will
definitely
need
your
feedback
on
this.
Some
collateral
contributions
of
the
draft
would
be
that.
B
B
So
now
the
main
part
of
the
draft
is
the
thread
thread
model,
so
the
third
model,
instead
we're
proposing
in
our
first
and
foremost,
establish
the
function
so
that
the
function
of
the
extraction
technology
has
to
be
clearly
identified.
In
order
to
understand
what
is
the
attack
surface
or
why?
What
the
threats?
Could
you
also
another
important
step
would
be,
will
be
identified
in
a
category,
because,
once
you
have
that
established,
you
can
use
some
of
that
information
you
had
from
from
other
well
handsome
technologies
in
the
same
category.
B
Also,
an
important
step
would
be
decomposed
the
technology,
so
understanding
the
basic
use
case
or
customized
use
is
requires
building
some
sort
of
diagram
in
which
you
analyze.
What
are
the
notes
out
with
an
interactive
each
other?
All
of
that,
the
most
important
part
is,
of
course,
identify
the
tracks
until
we
propose
a
couple
of
subscripts
and
here
the
destroyed
or
we
are
destroyed,
mnemonic
on
track.
B
Classification
is
used
at
first
to
do
Association
of
the
trout's
with
the
elements
of
the
data
flow
diagram
which
we
are
proposing
as
a
tool
to
build
diagrams
for
for
the
composing
the
technologies.
Then
we
analyzed
the
level
of
crusts
of
the
entry
points
and
then
associate
some
likelihood
values
deduced
from
close,
of
course,
documented
threads
detailing
the
format
and
analyzing
some
of
the
complex
stress
that
can
result
from
the
interaction
of
the
protocols
worker
of
the
basic
facts
that
were
introduced
by
the
protocol.
B
B
Okay,
so
before
she
went
before
I
wanna
give
a
short
description.
Try
them
p
for
most
of
the
people
I
have
heard
about
its
stride
stands
for
spoofing,
tampering,
repudiation
information,
disclosure
in
all
of
tourism,
elevation
of
privilege
and
is
a
threat
classification
mnemonic.
You
can
give
a
basic
integration
solution,
so
if
we
bring
the
threat
is
associated
with
spoofing,
you
would
want
all
the
desired
property
to
be
identification.
So
you
have
to
improve
the
authentication.
B
Some
examples
for
camera
from
the
network
elements
perspective
so,
for
example,
in
the
network,
this
wolf,
it
would
be
now
an
example
of
smoking
with
the
IPL
spoofing.
Also
like
it
might
be
hard
to
wrap
your
head
around
elevation
of
privilege
in
this
context,
but,
for
example,
accessing
the
privileged
parts
of
the
network
can
be
associated
with
this
type
of
that
slightly.
B
B
So
next
slide,
please
yeah,
so
for
those
that
the
transition
technology
is
the
function
would
be
to
ensure
safe
data
exchange
which,
over
those
like
infrastructure.
So
we
are
mainly
focusing
on
the
forwarding
capability,
so
this
oh.
This
includes,
of
course,
interior
great
poet,
routing
solution,
and
then
we
start
with
the
assumption
that
services
like
address
provisioning,
dns
resolution
or
exterior
gateway
rating
are
performed
by
other
nodes
within
the
within
touch
core
network.
So
we
are
excluding
these,
as
as
potential
attack
surface
like
slightly.
B
Okay,
so
II
in
terms
of
identifying
the
generic
category,
we
put
together
a
list
of
categories,
so
we
set
dual
stack:
single
translation,
double
translation,
encapsulation.
We
think
this
is
a
exhaustive
category
group
that
can
enrich
all
of
the
treasure
technologies
can
can
fit
so,
for
example,
for
those
that
we
have
the
old
IP
layer
of
operation
such
as
they
were
described
in
a
secret
code
213
in
terms
of
single
transmission
with
with
have
not
64
and
IV,
for
example,
yup.
It
doesn't
contain
all
the
transition
technologies
existing.
B
B
Okay,
now
in
terms
of
decomposing,
the
technology,
so
this
this
is
based
on
it's
a
essentially
was
inspired
by
by
application
for
a
web
application
chat
thread
model
III
tried
to
map
some
of
the
concepts
that
were
defined
there
to
network
elements,
so
I
had
to
redefine
some
some
of
some
of
those
elements.
I
already
have
some
feedback
that
it's
not
actual
great
job,
but
yeah.
Your
feedback
will
be
grateful,
be
greatly
appreciated,
so
to
improve
these,
for
the
definition
so
for
now
are
for
external
entity.
B
We
said
represents
left
one
note,
which
is
outside
control
over
network
provider,
so
essentially
outside
the
trust
of
a
network
provider
and
the
process.
We
said:
okay,
basically
supposed
to
be
a
middle
box
or
network
node,
which
processes
8.8
I.
What
I
think
yeah
this,
for
example,
can
definitely
be
improved
and
I
I'm,
not
sure
exactly
how
for
now
but
I
know
it's
not
the
greatest
definition.
B
Datastore
represents
an
eighth
note
where
data
is
stored
again,
another
one
that
definitely
can
be
improved.
Data
flow
I
think
it's
sufficient.
Data
exchange
between
network
elements
and
transponder
is
singular,
so
the
border
which
marks
the
part
of
the
network
considered
outside
of
the
control
of
a
network
provider.
So
this
is
were
the
basic
elements
I
think
they
are
needed
in
order
to
build
a
basic
use
case
diagram.
So
next
I
will
I'll
show
you
an
example
of
that
I
think.
B
Okay,
so
this
is
a
data
flow
diagram
for
lost
activation
technology.
So
essentially
we
said,
okay,
that
the
simplest
use
case
would
be.
We
will
have
considering
three
domains
and
a
network
provider
that
is
involved
in
this
process
will
have
domain
a
which
is
those
that
the
core
domain,
which
is
under
the
control
of
the
network
provider
and
ami
domain
D,
which
ear
as
well
as
close
like
and
the
we
are
signing
as
functions.
B
We
have,
let's
say,
client
to
answer
a
server
or
customer
or
and
provider,
and
in
these
contexts
you
have
on
the
on
the
clients.
I
will
have
a
customer
device
which
is
an
exterior
external
entity.
In
the
middle
we
will
have
a
process
which
is
the
dos
and
don'ts
that
node
and
ideal
will
have
a
provider
data
data
storage,
very
something
that
customer
device
will
try
to
get,
and
essentially
the
data
data
flow
is
exchanged
over
ipv4
or
ipv6.
So
this
is
the
basic
gist
use
case.
The
data
flow
diagram.
B
Another
important
point
will
be
about
protecting
assets.
Entry
points
also,
essentially,
we
are
looking
at
this
as
the
the
whole
system,
so
we
are
trying
to
protect
every
element
of
the
system.
So
that's
why
every
element
of
the
diagram
has
a
tea
which
stands
for
protected
and
also
every
element
of
diagram
can
be
an
entry
point
again.
His
diagram
as
well,
could
be
improved
by
by
by
specifying
which
were
which
are
for
potential
entry
points
like
the
physically.
Is
it
an
interface?
Is
it
something
else
so
yeah?
B
B
You
can
do
an
association
with
the
elements
of
the
diagram.
For
example,
you
know
the
customer
device
is
an
external
and
it
is
of
course,
that
can
be
by
association
associate
by
association.
So
all
the
threats
could
be
specific
and
reputation.
So
this
is
the
yeah,
but
the
stripe
proposed
or
the
house
tried
was
you,
madam
just
a
kin,
I
think
2008,
and
it
was
an
example
on
how
house
try
can
be
used
at
that
point.
Yeah
next
slide.
Please.
B
Yeah
so
essentially
from
the
level
from
the
level
of
the
trust
of
the
entry
point
we
conduct,
we
can
associate
some
likelihood
of
attack
values
which
are
initial
values
for
for
for
mitigating
or
prioritizing
the
mitigation
solutions,
so
yeah,
essentially,
since
the
customer
device,
for
example,
is
a
untrusted
entry
point.
The
likelihood
here
would
be
high.
So
that's
that's
what
if
our
the
H
stands
for
make
slightly.
B
B
So
yeah
this
is
a
kind
of
a
simplified
version,
because
I
wanted
to
put
the
threads
in
a
table
like
the
view.
So
essentially
we
will
have
a
threat
ID
which
for
now
I
okay
I,
said
the
macaroni,
my
TF
t
degree,
which
stands
for
trade
database
and
then
the
protocol,
in
this
case
our
plight
for
the
first
thread
and
then
a
serial
number
and
then
a
short
description
so
via
our
cache
poisoning
is
an
example
and
then
the
association
with
the
stride
element.
B
B
So,
essentially,
from
looking
at
the
simple,
simple
threads
by
looking
at
the
the
interactions
that
could
potentially
exist
between
them,
the
impact
or
the
likelihood
can
increase
the
first
complex
thread
that
I
gave
an
example
of
here
actually
says.
Also
another
thing
that
we
haven't
really
like
for
the
44
for
the
first.
The
impact
would
be
increased
that
we
didn't
really
propose
any
way
to
you
is.
E
B
B
H
E
B
B
Essentially,
the
most
important
in
my
opinion
would
be
having
a
thread
database
maintained
somehow
in
the
idea
for
speaking
the
draft,
maybe,
and
also
a
tentative
way
to
organize
the
security
considerations
for
protocols
like
if
we
can
have
some,
instead
of
just
generally
writing
about
the
threats
craving
some
structure
like
was
the
function.
What
like
the
steps
that
I've
already
presented
so
yeah?
This
is
this-
is
about
it.
I
have
some
questions
if
there's
still
time,
if
not,
we
can
just
jump
to
questions
like
feedback
from
the
audience
as.
A
H
Julie
egli
I
think
you
saw
my
comments
on
the
references
on
the
mailing
list
and
I
think
that's
probably
a
a
reasonable
thing
to
update
I
think
this
is
actually
as
threat
models
go.
This
is
pretty
reasonable
coverage
of
the
subject
area.
B
H
F
E
E
Revision,
8
is
simply
fixing
some
typos
and
refreshing.
The
reference,
as
you
may
remember,
this
document
is
basically
a
roadmap
that
there's
a
if
you
want
to
deploy
ipv6,
and
you
want
to
do
it
in
a
secure
way
regarding
the
operation,
please
think
about,
for
instance,
low-gain
things
about
this
and
we
simply
a
refaire
to
other
documents.
It's
mainly
kind
of
a
roadmap
against
all
the
document.
The
big
issue
is
that
ID
to
the
draft
are
becoming
RFC,
so
we
need
to
refresh
a
reference,
but
it's
kind
of
easy
to
do
so
now.
E
E
We
can
group
chairs
well
that
some
of
you
review
the
document
and
safe,
yes
or
no
at
least
get
some
momentum
again
around
this
document.
So
we
can
push
it
into
the
queue
and
go
forward.
So
that's
really
really
important.
People
have
we've
read
this
draft
the
dates
23
ago
like
it.
So
if
we
can
just
spend
10-15
minutes
to
do
it
would
I
dare
to
ask
for
volunteers
Fernando.
Thanks
Fred
thanks
me
thanks
and
thanks.
Ok!
So
far!
Oh
thank
you.
Thank
you
very
much
and
done
for.