►
Description
Internet Threat Model (Model-t) Program Meeting, 2020-04-20
A
A
Okay,
so
it's
treatment
first,
so
like
I
say
we
we
don't
have
a
camera
room
because
we're
not
an
idea
for
group
we're
an
IV
program
which
is
a
bit
different,
but
we
can
use
the
WebEx
chat
and
the
ether
pad
either
patters
for
notes.
So
don't
myself
too
much
and
maybe
use
the
WebEx
chat
for
any
chitchat.
I,
don't
know
if
we'll
need
to
run
a
mic
line
or
enough.
A
If
it
starts
to
get
confusing
as
to
who
wants
to
talk,
then
we
can
use
the
post
Q
minus
Q
convention
that
ITF
working
groups
using
for
remote
access
meetings
so
feel
free
to
use
that
convention.
If
you
want
to
come
in,
we
so
I'm.
Just
looking
at
the
agenda,
which
I
hope
is
being
displayed
on
your
screens
and
is
there
any
agenda
bashing.
C
A
Okay,
so
now
you
should
get
to
see
the
agenda
and
now
is
a
good
time
to
patch
the
agenda.
If
you
need
to
I
think
we
have
two
hours
slash
but
I
hope
we
don't
take
two
hours,
maybe
an
Irish
but
we'll
see
okay,
so
any
agenda
bash.
We
basically
have
a
bunch
of
chats
about
the
drafts
and
then
some
planning.
D
A
A
E
Perfect
so
I
promise
this
will
be
short
and
I'm.
Sorry,
I
added
six
slides
to
the
otherwise
lightweight
session.
Here
this
is
a
kind
of
informational.
This
is
a
draft
that
attempts
to
identify
classes
of
end
points.
That's
the
idea
behind
it.
Primarily
the
idea
is
it's.
It's
part
of
another
effort,
that's
going
on
to
basically
establish
the
capabilities
and
limitations
of
endpoint
only
security.
That's
that's
the
idea
of
the
larger
the
larger
effort.
E
What
consideration
should
be
given
for
adapting
protocols
for
those
particular
endpoint
types
now?
The
idea
is
that
the
intuitive
idea
is
that
endpoints
environment
has
changed
since
2003,
and
so
what
we
see
in
RFC
3550
has
probably
changed,
and
if
that's
true-
and
we
could
classify
the
endpoints,
what
I'd
wondered
in
before
I
wrote
the
strap.
Then,
as
I
was
writing
the
strap
is,
could
we
go
ahead
and
classify
those
endpoints
and
if
we
were
able
to
classify
them,
could
we
talk
about
this
security
characteristics
right
so
next
slide?
E
So
the
my
metric
for
whether
or
not
this
kind
of
work
would
be
useful
is
that
if
you
could
actually
do
a
classification
of
endpoint
types
and
then
you
could
talk
about
in
some
granularity,
what
the
security
characteristics
of
those
endpoint
types
would
be,
and
maybe
what
you
could
do
are
these
two
things
here:
some
research
could
be
done
on
those
security
characteristics
and
influence
protocol
design.
That's
number
one
and
number
two.
If
that
were
true,
it
might
be
something
that
helped
helped
us
in
Model:
T
reconsider
the
landscape.
That's
documented
in
3552.
E
So
the
first
draft
of
this
document,
which
I
I,
did
not
bring
to
model
ta
I
brought
it
to
the
work
that
was
going
on
in
smart
and
in
class.
The
first
document
was
entirely
flat
in
that
it
was
a
taxonomy
that
divided
endpoint
types
into
eight
different
classes
and
then
attempted
to
describe
those
classes
and
I'll
talk
about
that
in
a
second
one
of
the
suggestions
is
to
go
ahead
and
provide
a
hierarchy
so
that
the
endpoint
classes
were
a
little
bit
deeper
than
our
very
high
level
characteristic.
The
correct
graph
doesn't
do
that.
E
I
took
that
as
advice,
but
I
think
that
there's
some
danger
in
doing
a
highly
granular
taxonomy
here
and
what
we're
trying
to
do
instead
is
to
provide
an
upper
level
characteristics,
a
sort
of
lineage
so
that
protocol
designers
can
understand
certain
characteristics
of
of
larger
groups,
of
endpoint
devices.
Right
and
so
I
took
the
advice
that
a
hierarchy
might
be
useful,
but
I
didn't
act
upon
it.
So
that's
one
of
the
changes.
E
So
the
goal
of
the
draft
is
truly
purely
informative.
There's
no
normative
language
in
it
at
all
and
the
reason
I
brought
it
to
model-t
was
because
I
do
think.
It's
informative
to
Model,
T
I.
Think
part
of
our
work
in
reconsidering
3552
is
reconsidering
the
threat,
landscape
and
part
of
reconsidering
the
threat
landscape
is
reconsidering
sort
of
the
the
endpoint
architecture
that
we
currently
support,
both
on
public
and
private
internets.
E
So
it's
informative,
there's,
no
real
intent
here
to
to
provide
any
normative
text
at
all,
and
one
of
the
goals
is
to
try
to
show
that
such
a
taxonomy
is
possible.
That's
that's
one
of
one
of
the
goals,
because
if
it
is
I
think
it's
my
intuition
anyway,
that
that
would
show
that
the
description
of
the
threat
landscape-
that's
currently
in
RFC
3550
certainly
needs
to
be
updated
and
that's
a
conversation
that
is
just
one
part
of
what's
going
on
with
Model
T,
so
maybe
I'll
take
to
the
next
slide.
E
This
is
just
one
small
part
of
it,
a
part
that
I'm
interested
in,
but
it
is
one
small
part
of
it,
because
we're
talking
about
endpoints
here
entirely
I
do
I
will
go
back
and
reconsider
the
idea
of
doing
a
hierarchy
instead
of
a
taxonomy,
though
I'm
reluctant
reluctant
to
go
down
that
path
and
then,
of
course,
further
discussion
inside
a
Model
T
whether
or
not
this
is
actually
useful
for
the
discussion.
E
One
of
the
goals
here
is
not
not
related
to
T
at
all,
but
to
combine
this
work
with
other
work.
That's
going
on
in
class
and
I
promised
I
would
be
short,
but
my
next
slide
is
how
I
get
out
of
here.
So
there's
the
there's,
the
draft,
my
email
address,
I'm
thrilled
to
take
questions
and
comments
and
I'll
just
wait
for
that.
Thanks
great.
A
F
You
so
skimming
through
this
draft
I
noticed
that
the
classes
you
have
in
this
taxonomy
actually
described
the
row.
Will
that
end
points
may
the
interactions
they
have
with
their
digital
and
their
physical
or
human
environment
just
mean
to
infer
the
characteristics
of
the
end
points
from
the
kerrick's
characteristics
and
an
end
point
for
one
of
these
roles
should
have
and
actually
I've
been
trying
to
work
on
something
similar
or
different,
which
is
revisiting
RFC
72
to
age.
We
try
to
come
up
with
some
of
those
actual
characteristics
of
the
devices
themselves.
E
So
thanks,
Kirsten
and
I
I'd
be
very
happy
to
talk
offline
about
whether
it's
possible
to
combine
the
work.
I
actually
would
kind
of
welcome
that.
One
of
the
things
that
you
said
first
was
that
part
of
part
of
my
descriptions
of
the
classes
is
to
talk
about
the
roles
of
the
endpoints
and
I
wrestled
with
that.
To
be
honest,
because
I
think
that
the
that
the
classes
should
be
as
generic
as
possible
and
that
anything
where
you
describe
rules
should
just
be
as
examples,
they
shouldn't
help
define
the
classes.
If
that
makes
any
sense.
F
A
D
Great,
thank
you.
Hey
Mark,
thanks
a
lot
for
the
presentation
and
the
draft
which
I've
read
a
couple
of
times.
Just
a
quick
question.
You
have
another
draft.
Smart
threat
changes
a
problem
statement.
I
was
just
wondering
how
that
into
this
work
and
sort
of
how
you
see
the
two
going
together,
Thanks.
E
The
threat
landscape
hasn't
changed
that
much
in
the
time
since
3.52
it
was
written
and
it
only
needs
minor,
tweaks
and
I
kind
of
thought
about
that
and
thought
gee
that
that
doesn't
seem
right
to
me
that
it
seems
like
there
have
been
major
changes
to
both
the
architecture
and
the
endpoints
that
are
supported
in
the
public
Internet.
So
that
draft
is
a
response
in
many
ways
to
some
of
the
discussions
is
the
idea
behind.
It
is
really
for
it
to
be
part
of
the
conversation
going
forward
in
Model
T.
D
G
So,
thank
you
Mark.
This
is
quite
interesting.
I
often
think
about
things
from
their
point
of
view
like
how
can
I
use
this
information
and
I
have
a
question
about
that.
The
case
of
your
categories,
also
like
the
phone
that's
on
my
table,
is
probably
all
the
categories
that
you
listed
in
the
in
the
draft,
and
you
know
how.
E
Like
your
phone
on
the
table,
then
what
we
would
be
given
protocol
designers
is
not
just
one
set
of
security
considerations,
but
multiple
things
to
take
into
account
as
they
design
protocols,
and
so
that's
what
I?
That's
what
I
had
him
back
in
my
mind
and
how
those
thoughts
link
up.
Certainly
your
your
remark
about
the
application.
Endpoints
is
exactly
right
and
I
don't
disagree
with
that.
E
H
H
But
in
fact
the
origin
of
Mark's
job
is
when
Claire
started
and
we
started
to
list
and
organize
the
limitations
and
capabilities
of
endpoint
security
solutions.
We
started
to
realize
that
we
were
completely
missing
a
proper
model
of
endpoints,
so
what
I
hear
is
I?
Did
this
section
in
class
I
had
to
really
limit
myself
to
the
minimum,
but
it
was.
It
is
a
problem
because
later
in
class
itself,
what
Mark
has
do
now,
but
in
class
itself
the
problem
is
that
there
is
no
uniformity
to
describe
type
of
attacks.
H
That's
one
thought:
what
we'd
be
then
missing
is
the
is
the
the
attack
landscape
document
that
we
was
supposed
to
be
started
by
another
person,
but
it's
thought
to
be
slow,
so
the
idea
is
class
itself
would
be
the
joint
between
mark
documents
and
other
document
to
be
defined
so
that
we
make
less
lighter
and
clear
so
that
it's
even
more
uniform.
So
so
perhaps
we
can
start
to
find
new
extraction
layers.
H
We
can
find
perhaps
a
way
to
describe
in
a
more
uniform
manner
the
characteristics
of
the
endpoints,
whether
they
are
on
the
left,
side
or
right
side
of
the
communication.
So
we
think
we
believe
is
now.
There
is
a
very
good
photo
this
situation
in
this
way,
so
that
we
can
then
be
more
equipped
with
express
better
descriptors
of
the
future.
For
example,
what
what
you
guys
are
trying
to
do
is
Model
T
I
stop
here.
Thank
you.
E
I
I
It
seems
that,
if
we're
going
to
talk
about
a
threat
landscape,
that's
that's
what
attackers
like
to
do
and
so
I
think
there's
a
there
might
be
a
gap
here
between
sort
of
imagining
how
we
talk
about
the
threats
and
what
we
actually
need
to
design
protocols
or
bus
to
threats
that
haven't
necessarily
thought
of
that
I
mean
if
you
look
at
RFC
at
the
RC,
we're
thinking
about
replacing
that's
what
it
does
it's
entirely
about
everything
that
can
be
done.
I.
E
A
J
I
am
I,
have
reservation
about
classifications,
because
pretty
much
every
classification
exercised
ends
up
finding
that
we
have
a
continuum
and-
and
basically
you
end
up
picking
points
in
the
continuum
and
I'm,
not
too
sure
that
this
is
a
very
productive
and
specifically,
there
is
always
temptation,
because
this
is
a
continuum
to
go
to
a
very
large
number
of
points,
and
then
it
becomes
none.
Usable
more.
Interestingly,.
J
That
there
are
a
couple
of
big
questions
that
care
on
the
device
which
is
effectively.
Can
the
software
be
updated
and
by
whom
who
can
install
software
on
the
device
and
basically
did
is,
are
more
about
the
management
of
the
device
about
the
size
of
the
software.
We
think
that
the
management
is
kind
of
as
important
as
your
devices.
Sixty
four
hundred
six
hide
forty
K
of
memory
or
64
megabytes.
It's
in
my
mind,
more
important,
especially
for
that
model.
E
E
Imagine
imagine
a
continuum.
What
I'm
trying
to
do
here
is
to
provide
kind
of
arbitrary
slices
of
that
continuum
and
give
them
descriptions
and
provide
characteristics.
So,
while
I
recognize
that
it
is
a
continuum
and
I
was
not
hopeless
about
the
fact
that
you
could
possibly
divide
the
continuum
up
into
distinct
segments.
That
much
said
the
second
stream
of
what
you
said
that
you,
you
were
very
interested
in
the
management
of
classes
of
devices
rings
really
true
to
me
and
I
think
that
that
would
really
improve.
E
The
subsequent
draft
is
that
for
each
classification
and
recognizing
that
you're
skeptical
that
we'll
ever
get
the
classifications
for
right.
But
if
I
were
optimistic
and
I
said
that
in
a
future
draft
for
each
one
of
these
classifications
as
part
of
the
description
of
the
characteristics
of
those
classes,
we
also
described
their
manage.
The
devices
were
managed
and
what
their
management
capabilities
were.
I
think
that
that's
a
very
useful
suggestion
and
I
will
definitely
take
that
on.
A
We
don't
actually
have
anybody
in
the
queue
unless
I've
forgotten
somebody
else,
in
which
case
my
apologies
in
advance
I
mean
one
case.
People
want
to
join
the
queue
Marc
did
you
have
any
kind
of?
When
is
a
good
time
for
people
to
read
this
draft
and
send
comments
to
the
list?
Yeah
I'm
the
current
one,
or
wait
for
another
revision
or
roughly,
when
that's
might
that
happen?
Do
you
think
so.
E
E
A
A
A
D
I'm
gonna
take
them
as
two
things,
because
one
sort
of
a
leads
to
the
other
so
for
having
the
call
and
great
to
see
quite
a
few
people
on
the
call
and
I'm
gonna
talk
about
my
two
drafts.
The
first
one
is
an
update
to
an
older
draft
and
I
renamed
it.
So
it's
called
the
use,
focus
internet
threat
model,
I,
don't
have
slides,
because
I
thought
I
would
completely
try
to
keep
it
simple
in
any
case.
D
But
if
you
read
through
your
losslessly
that
there's
still
a
bit
of
work
to
be
done
and
I
want
to
put
an
attack
model
into
it
and
in
various
other
things
like
that,
it
also
points
out
some
other
endpoint
vulnerabilities.
But
again
it's
not
a
massive
update
to
the
last
one.
On
that
I
presented
last
year,
actually
so
under
point
6
in
that
in
that
draft,
there's
a
TBD
D
protocol
designs
and
instead
of
kind
of
filling
that
out,
I
decided
to
put
in
a
new
draft
which
is
the
next
one
that
we're
talking
about.
D
Let
me
just
pull
it
up,
which
is
a
security
considerations
for
protocol
designers.
This
is
a
much
longer
draft
and
it's
also
a
first
draft.
So
there's
still
a
lot
of
a
lot
of
sort
of
things
that
need
to
be
filled
out.
However,
the
point
of
this
one
in
particular
looks
at
considerations
for
protocol
designers
focuses
on
attack
defense.
D
There's
still
quite
a
few
more
that
I'd
like
to
to
add
as
well
and
and
also
you
know,
based
on
what
we've
experienced
in
the
last
couple
weeks
in
the
last
couple
months,
with
their
current
current
pandemic,
going
on
I
think,
there's
some
really
interesting
case
studies
that
can
be
added
as
well.
So
that's
basically
the
overview
and
I.
D
A
I
Thank
you
very
much
for
writing.
I
think
it
really
highlights
where
you
want
to
go
with
this.
Just
looking
at
the
protocol
design
one,
it
seems
to
be
talked
like
a
lot
of
these
threats
are
ones
the
where
I
take,
for
instance,
a
SQL
injection
right.
This
can
be
mitigated
through
software,
improve
it's
not
a
protocol
issue
per
se
and
then
we're
talking
about,
say,
hijacking,
traffic
with
BGP
hijacking
and
DNS
problems.
I
mean
this
is
a
consequence
of
the
security
model
of
BGP,
but
that's
already
identifiable
it's
a
problem.
I
If
you
look
at
the
existing
threat
model
and
consider
how
B's
you
know
fails
to
authenticate,
you
did
as
being
sent
in
so
looking
at
this
I'm.
Just
not
really
it's
not
clear
to
me,
which
of
these
threats
require
changes
to
the
threat
model
protocol
designers
to
look
at
or
what
those
changes
would
be.
Iii
think
you
have
specific
problems,
but
if
protocol
designers
can't
mitigate
them
or
can't,
you
know,
can't
change
a
protocol
to
be
able
just
to
solve
them,
then
that
raises
questions
of
what
the
update
has
to
look
like
to
enable
that.
D
Well,
thanks
thanks,
so
much
for
that
and
I
actually
totally
agree.
What
I
was
trying
to
do
here,
at
least
on
the
strap,
is
that
I
was
basically
throwing
everything
in
you
know
to
highlight
the
fact
that
these
tat
attacks
do
exist
and
I
totally
take
your
point,
because
not
all
of
them
are
specifically
related
to
protocols,
but
I
do
think
that
at
least
on
the
initial
first
pass
you
know
some
of
the
threats
we
could
be
aware
of
them
right,
especially
if
it's
sort
of
unintentionally
the
protocols
are
sort
of
contributing
to
it.
D
So
so
I
think
that's
actually
really
good
feedback
for
me
because
again,
I
was
trying
to
capture
just
everything
and
and
try
to
see
if
I
can
just
sort
of
come
up
with
a
list,
not
necessarily
a
taxonomy,
but
come
up
with,
like
a
chaos
of
case
studies,
for
that,
so
I'll
try
to
be
more
specific
about
effectively
about
that.
You
know
what
are,
but
are
directly
impact
protocols
and
directly
in
pepero
to
call
design
versus
things
that
are
probably
perhaps
more
unintended
consequences
or
have
unintended
results.
So
thank
you
for
that.
G
I
think
there's
really
good
list
of
attacks
and
good
list
of
things
to
that
that
we
need
to
deal
with
in
order
to
prevent
attacks,
maybe
a
depressingly
long
lists
both
of
them.
Naturally,
it's
entirely
complete,
though
so,
for
instance,
I,
I,
think
you're
kind
of
missing
some
of
the
insider
attacks.
G
Compromised
just
because
it's
incentives
or
or
its
interest
for
a
different
time
line.
So
let
me
that's
a
thing
that
you
could
perhaps
add
and
also
I,
think
the
list
of
remedies
is
more
in
the
type
of
what
can
we
do
in
the
network
them
and
what
can
we
do
in
the
protocol?
Design
phase?
I.
Think
if
you
think
otherwise,.
C
Thank
you
for
this
draft
I'm.
Looking
at
the
security
considerations
for
protocol
designers,
Wendy
Seltzer
here
and
I
think
what
what
strikes
me
is
sort
of
it's
a
very
good
list
for
users
of
protocols
and
designers
of
systems
that
build
on
sort
of
the
layered
stack
to
be
thinking
of
all
of
the
ways
that
technology
can
be
abused
and
subverted
and
used
against
them.
I
wonder
some
of
them
look
less
amenable
to
being
addressed
in
the
protocol,
design
and
yeah
on
the
layered
thinking
of
of
protocol
design.
D
Yeah,
that's
that's
actually,
a
really
really
good
point,
so
the
first
pass
of
this
was
just
like
breaking
it
down
into
two
sections:
I
could
actually
almost
from
your
comments,
see
breaking
it
down
into
further
sections
based
on
the
yeah
on
the
different
layers,
and
it's
actually
really
I.
Think
that's
really
helpful.
I
can
probably
even
do
that
in
my
next
pass.
So
thank
you
for
that.
That's
really
really
useful.
K
G
K
I
hear
you
no
I
am
good.
Okay,
on
so
I
mean
3552
was
intended
to
serve
two
purposes
right.
One:
two
I
guess
three
I'm
one
destined
to
toriel
material
and
I.
Think
about
that
bottling,
one
about
medevac
protocols.
One
to
you
know,
try
to
set
a
baseline
kind
of
like
expectation
about
what
protocols
should
be
like
do
and
third
to
describe.
You
know
how
to
how
to
write
this
agree,
because
their
intersection
with
the
document
actually
nominally
about
so
I
mean
I,
guess
and
one
of
things
we
haven't
started
been
doing.
K
That
was
to
actually
write
these
example.
Security
considerations
and,
on
you
know,
see
how
with
instructions
we
were
getting
people
actually
delivered
the
security
considerations
sessions.
We
were
hoping
that
they
would
have
so
I
guess.
My
question
here
is:
if
one
were
to
take
these
documents
on
board,
how
would
this
affect
these
security
considerations
or
the
design
of
protocols
which
you've
already
built.
D
First
of
all,
I
think
that
basically
I
think
all
the
documents,
including
yours
that
are
well
denied
yours.
The
area
sets
yaari
and
Stevenson
said
that's
coming
up
right
that
have
different
approaches.
All
of
them
should
be
included
in
the
sense
that,
like
they,
they
highlight
different
aspects
right
so
I
think,
regardless
of
whether
or
not
the
protocol
has
already
been
built
or
is
going
forward.
D
My
my
feeling
for
the
I
came
up
with
is
that
it's
just
awareness
raising
issue
on
you
know
on
awareness,
raising
sort
of
thing
on
some
of
the
issues
and
as
Wendy
rightly
pointed
out,
there
are
different
issues
depending
on
different
layers.
Right,
so
I
think
that,
depending
on
well
I
think
that
going
forward.
D
All
of
this
fits
into
one
thing:
right:
cuz,
cuz,
they're
different
because
you
are
en
Steven
actually
basically
highlights
different
approaches
right
and
highlight
different
risks
and
I
love
different
threat
models,
which
I
totally
think
is
actually
completely
useful
in
a
different
way
than
the
sort
of
endpoint
threat
models
and
the
and
the
different
sort
of
aspects
that
I
have
in
my
draft.
So
maybe
maybe
on
too
much.
D
K
I'm
asking
a
different
question,
which
is
on
like
the
purpose
of
producing
these
documents,
is
to
give
guidance
to,
or
any
document
of
this
kind
is
to
give
guidance
to
the
people.
Writing
the
RFC's,
which
we
then
then
describe
the
protocols
through
then
implement,
and
so
my
question
is:
if
what
is
what
would
in
what
way,
would
this
document
and
try
to
understand
what
the
invite
of
this
document
is?
D
K
I
guess
I
guess
maybe
but
I'm
trying
to
I
guess
what
I'm
trying
to
understand
and
so
surely
take
some
protocols
which
are
currently
being
developed,
but
I
guess
understand
is
but
I
mean
like
we
have
like
Lenti
of
protocols
to
republished
like
in
the
past
two
years.
Right
and
so,
and
so
my
question
is
like
I
guess
you
know
like,
like
so
I
think
like
how
would
you
shape?
K
D
Not
even
I
mean
I'm,
not
even
sure
that
there
are
gonna
be
many
changes
to
that
right.
I
mean
unless
they're
like
massive
updates
to
like
quick,
Ordo
or
anything
like
that,
because
they're
in
a
I
mean
that's
what
I'm
trying
to
think
I'm
trying
to
think
about
going
forward
from
now
right,
I
don't
know:
do
we
want
to
talk
about
this
offline
and
maybe
take
specific
sure.
K
K
D
J
Thanks
Dominic
I
I,
really
like
this
idea
of
doing
a
list
of
examiner.
I
I
do
understand
what
Eric
is
saying
that
it's
not
directly
actionable
in
terms
of
protocol
design,
but
nevertheless
that's
quite
interesting
either.
When
I
read
your
draft,
there
are
two
additional
things
that
I
would
like
to
see
into
effect
that
the
first
one
is
what
we
are
the
assets
that
the
attacker
were
looking
after,
and
the
reason
for
looking
at
the
assets
is
that
the
basic
threat
modeling
starts
with.
J
What
is
it
that
you
want
to
protect
exactly,
and
it's
often
very,
very
fuzzy,
but
if
we
have
a
clear
view
of
what
attackers
are
after
it
becomes
easier
to
say,
okay,
the
weakness
in
this
protocol
may
drive
and
attack
against
these
or
that
kind
of
assets.
With
examples
we
have
seen
attacks
in
the
past
that
we
are
looking
at,
for
example,
getting
a
stone
getting
a
foothold
in
a
protected
network
which
were
basically
typically
trying
to
do
you.
J
Several
of
the
attacks
in
the
past
have
been
attacks,
trying
to
get
listing
about
user
IDs
listing
about
what
people
are
doing
access
to
databases,
but
they
could
be
also
accessed
about
what
is
the
activity
going
on
on
a
particular
network,
and
so
I'd
like
in
your
description,
to
see
basically
to
get
examples
of
those
targeted
attacks
against
specific
assets?
And
finally,.
A
J
Have
attacks
about
databases
about
secrets
and
things
like
that,
and
we
have
also
publicize
attacks
against
a
just
in
order
to
drive
extortion
against
the
continuous
operation
of
the
business
extortion,
attacks
using
either
denial
of
service
attacks
or
when
somewhere,
which
are
kind
of
into
the
same
goal.
But
with
different
means.
J
Typically,
the
attackers
in
most
of
those
attack
don't
attack
one
system
in
isolation
or
one
endpoint
in
isolation.
They
attack
typically
a
system,
a
network
and
then
to
provides
a
school
of
something
at
that
and
and
they
go
for
loss
of
getting
a
foothold
and
then
getting
to
data,
and
things
like
that.
So
that
keeps
us
also
the
idea.
J
Basically,
one
of
the
problem
we
have
with
all
deployments
is
that
with
water
defense
in
depth,
and-
and
that
will
be
in
my
mind
here
too,
and
so
it
makes
question
showing
how
the
absence
of
defense
in
depth
leads
to
catastrophic
effects.
Very
interesting
because
defense
in
depth.
It's
something
that
we
can
incorporate
in
protocol
design
some
level
so
that
we
saw
that
the
two
things
that
I'd
like
to
see
in
this
kind
of
evolution
of
one.
D
Thank
you
so
asset
protection
and
defense
and
depth
and
I
think
that
could
be
accomplished
by
filling
out
some
of
the
sections
that
are
that
are
already
there
on
data
protection,
but
going
a
little
more
specifically
on
sort
of
what
kind
of
data
and
and
sort
of
the
characteristics
of
of
how
that
how
that
was
breached.
So,
thank
you.
That's
really
really
helpful.
Yeah.
J
J
And
and
that's
illuminating,
because
it
tells
you
how
a
very
benign
system
like
who
cares
about
the
temperature
control
in
an
aquarium,
many
yeah,
you
might
use
some
fishes,
but
what?
What?
What?
What
is
the
a
pole
and-
and
in
fact,
what
that
gives
you
is
a
foothold
in
someone's
data
network
that
can
then
be
used
to
go
further.
I
mean
we
have
to
precise
kind
of
things,
yeah.
A
H
Thank
you
Steve.
So
in
fact,
I
would
like
to
continue
from
what
Christian
said.
So
so,
in
fact,
the
issue
of
the
assets
is
that,
yes,
that
needs
is
very
relative
value.
It
really
depends,
for
example,
right
now.
My
phone
has
no
interest
for
Iker,
but
the
phone
that
would
be
used
by
some
other
person.
Some
of
the
context
would
be
very
valuable
for
the
attacker,
the
and
these
feeds
back
to
the
risk
management,
because
this
is
a
risk
management
issue.
H
This
is
defined
already
elsewhere
in
ICC
and
in
other
places.
So
it's
true,
but
at
the
same
time
things
would
be
very
difficult
to
describe
that
in
this
draft.
From
my
perspective,
the
point
of
the
campaign
is
very
good,
I
think
the
campaigning-
and
this
is
why
we
need
to
have
a
way
to
describe
atomic
attacks.
That's
part
of
the
mother
burst
of
the
landscaper
syncwords
own
campaign
is
actually
an
orchestration
of
the
attack
in
a
certain
way,
and
the
defense
is
an
orchestration
of
the
defense
to
fight
to
certain.
H
Contain
we
do
not
deform
is
that
we
do
not
have
the
Lego
bricks
of
language
to
actually
describe
that.
So
now,
when
I
look
at
this
draft,
for
example,
Dominique
fishing.
For
me,
fishing
is
not
an
attack
on
on
on
a
device
sewn
attack
on
the
brain
right,
but
you
have
all
the
places
where
you
have
an
attack
on
the
device
and
these
links
back
to
what
Mark
is
trying
to
do.
What
I'm
trying
to
do
the
issue.
H
We
have
nabbed
coming
back
to
the
problem
of
howie
and
what
Eric
said
about
how
it
speaks
to
those
protocol.
Designers
do
not
have
the
mapping
is
in
these
type
of
documents
or
what
I
do
was
not
doing
versus
what
is
important
for
the
for
the
the
the
protocol
designer.
We
are
missing
some
long
wedge
here,
I'm
the
language.
What
I
would
like
to
have
his
mark
is
a
long
ways
that
goes
beyond
the
category
to
describe
the
attack
surface
problem.
H
What
is
the
attack
surface?
Does
that's
the
attack
surface
that
is
coming
from
the
asset
on
what
Cristiano
said.
The
problem
no
needs.
We
do
not
see
the
view
we,
we
need
to
distinguish
the
two
things
from
the
asset
side
versus
the
attack
side.
We
really
need
to
make
this
explicit
distinction
and
we
organized
the
wrong
wage
on
both
sides
to
understand.
Okay,
now
we
have
a
long
way
to
describe
our
vulnerability
in
terms
of
we
can
create
management.
H
We
can
click
the
way
that
the
physical
system
is
organized
bla,
bla
bla
on
one
side,
and
then
you
have
the
attack
on
the
other
side,
and
then
you
have
the
mitigation.
Is
that
he's
trying
to
answer
the
attack
that
he's
trying
to
attack
the
attack
surface,
and
we
addressed
me
thing-
is
long
wait,
first
of
all
to
organize
that
better,
so
I
think
this
is
a
gap
that
we
have
between
at
least
the
few
drafts
that
that
you
have
seen
so
far
stop
here.
D
H
A
Great,
so
I
don't
have
anybody
else
in
the
queue
at
the
moment.
One
little
bit
of
housekeeping.
We
have
a
Colin
user.
If
you
could
identify
yourself
that
week,
just
for
the
notes
that
we
grace
it
may
be
somebody
who's
in
twice
or
something,
but
there's
a
:
user
v.
If
you
could,
let
us
know
who
you
are:
that'll
be
cool
and
that
colored
users
are
meeting
you're
trying
to.
A
D
Yeah
and
just
to
highlight
I
got
feedback
from
Watson
when
dek
are
Christian
and
Arno,
and
also
Randy
and
Mark
in
the
chat
as
well.
Building
a
little
bit
more
on
Christian,
so
I
will
incorporate
those
comments
and
I'll
probably
reach
out
to
all
of
you
on
that
and
also
you
know,
I'm
happy
and
open
to
any
collaboration.
If
there's
any
sections
or
any
particular
individual
parts
that
people
want
to
work
on
or
add
to,
please
let
you
know,
please
feel
free
I'd
be
happy
any
more
than
happy
for
that.
So
yeah
thanks.
G
Think
this
will
be
relatively
brief,
so
this
is
an
update
on
the
on
the
draft.
That
means
Steven
wrote
this
nice
percent
on
the
lists.
If
you
Steven
go
to
the
second
slide,
that's
the
only
slide
so,
as
you
may
remember,
this
draft
essentially
talks
about
like
why
do
we
need
to
go
blonde
one
sec
and
all
the
details
of
that
and
two
things
happened.
The
previous
round
of
updates
draft
updates.
So,
first
of
all,
we
added
material
on
what
tracking,
thanks
to
Eric
and
Chris
for
some
video
and
text.
That's
great.
G
So
that's
one
thing
and
feedback
on
the
specifics
of
Texas
always
welcome,
of
course,
and
the
other
thing
that
that
we
sort
of
reformulated
in
a
graph
of
slightly
keeper
exactly
what
do
we
want
to
do
for
RFC
3550,
and
we
basically
offered
three
alternatives
and
just
for
background
and
this
sort
of
ties
into
the
previous
discussion
that
we
had
with
very
current
you're
about
like
what?
What's
the
output
of
this
this
exercise?
G
Are
we
changing
35:52
and
you
know
I
like
one
document
or
install
update
or
four
documents
whatever
so
my
personal
view,
at
least
that
there's
some
sort
of
supporting
documentation?
What
Stephens
and
my
draft
is
one
example
of
that
rather
other
classes
law
and
they
could
be
published
on
their
own
and
I
at
least,
would
have
some
interest
in
doing
that
that
for
our
draft,
but
in
addition
to
that
there
is
this.
G
You
know
question
of
whether
we
should
add
you
know
a
little
bit
to
the
the
existing
RFC
and
exactly
what
is
that
a
little
bit
and
we
basically
came
up
with
three
choices
here.
Like
one
is
this
essentially
one
sentence?
It's
simple
but
obvious,
it's
easy
to
add,
but
entirely
fit
that
one
sentence.
We
could
talk
for
adoption
to
a
slightly
more
about
the
capabilities
required
for
the
attack
can
happen
and
what
happened
and
some
analysis
is
not
what
you
need
to
do
in
order
to
defend
against
this.
G
But
you
know
stuff
like
two
to
two
more
paragraphs
or
we
could
provide
a
more
comprehensive
set
of
defense
guidelines.
You
know
still
act
that
would
be
highly
relevant.
This
is
like
a
new
subsection
in
the
document
this
again
by
the
way
text
that
was
contributed
by
Aaron
crystal.
Thank
you
very
much
again
so
here
we
would
talk
about
things
like
how
to
live
in
time
of
exposure
is
making
backers
have
to
use
active
attacks
and
so
forth,
and
this
could
be
one
new
subsection.
G
A
A
I
Look
to
wrap
that
I.
Think
it's
pretty
good.
One
thing
I'd,
like
to
add,
is
there's
discussion
about
sort
of
control.
There's
some
discussion
about
sort
of
control,
plane
things,
but
there
isn't
a
lot
about
the
way
in
which
say
you
have
a
kubernetes
cluster,
all
your
network,
accesses
and
policies,
etc,
a
really
kind
of
useless,
because
everything
goes
over
poor
date
or
port
443,
and
so
you
have
a
layer
of
authorization,
authentication
concerns
which
are
sort
of
above
the
HTTP
layer,
and
so
it's
very
easy
to
make
mistakes.
G
J
Have
a
concrete
laughter
you
two
have
been
preparing,
but
I'm
really
walking.
Knowing
that
we
are
missing.
The
overarching
surveillance
is
an
attack.
Laughter
I
mean
a
lot
of
the
practical
attacks
on
mean.
Dominic
has
been
looking
at
the
big
attacks,
the
one
that
coup
against
the
witches
and
year
advance
weights
and
things
like
that.
G
J
B
G
A
Kind
of
works
for
me
as
well,
so
that's
good
okay,
so
we
have
nobody
else
in
the
queue
we've
talked
about
drafts.
The
only
other
agenda
is
I.
Guess
might
be
worth
spending
just
a
couple
of
its
on.
How
would
people
like
to
proceed
given
we're
probably
enough
going
to
Madrid
so
I
guess
the
obvious
thing
is
to
kind
of
have
these
kind
of
calls
at
some
frequency,
but
what?
What
are
people's
thoughts?
What
would
you
like
and
mark.
E
Thanks
so
I
agree
to
I
I'm,
pretty
skeptical
that
will
meet
physically
in
Madrid,
although
there
should
be
no
counting
on
my
crystal
ball
in
any
way.
On
the
other
hand,
I'd
like
to
see
progress,
keep
going
there
and
then
I
heard
yari
sort
of
talked
about
getting
a
draft
done
in
May
early
May,
mid,
May
I
would
be
committed
to
revising
life.
My
work
by
that
time,
I
think
it
would
be
great
if
the
chairs
scheduled
a
notice.
A
virtual
session
like
this
trying
to
keep
it
to
an
hour
again.
A
G
Okay,
so
Steven
can
I
can
I
ask
something
sure
please,
yes,
so
the
course
to
do
this.
One
thing
maybe
month
is
good,
but
I
think
we
need
to
talk
about
back
now.
What's
the
project
otherwise,
also
because
I
see
that
there's
like
potential
to
come
out
with
some
concrete
things,
some
actual
arses
relatively
soon,
if
we
spoke
them
properly,
but
then
there's
also
like
more
of
a
long
term,
almost
like
a
permanent
reach.
A
Yeah
yeah,
maybe
so
maybe
so
we
having
some
meetings,
cadence
of
monthly
ish,
seems
reasonable.
We
can
set
up
some
poll
big
times
and
so
on,
Gary,
maybe
in
terms
of
your
you
know,
setting
out
of
a
sketch
of
the
future
of
something.
Maybe
we
can
try
and
construct
an
email
and
send
it
to
the
list
that
is
a
bit
more
concrete
than
that.
Does
that
make
sense,
yeah
sure,
okay,
so.
G
A
A
A
Lunch
for
some
indeed,
please
I
just
have
to
the
participant
list
in
the
ether
part
which
is
on
screen
there
now
and
if
there's
no
other
business
other
than
lunch,
enjoy
your
lunch
hope
everybody
keeps
well
and
we'll
talk
on
the
list
and
have
another
chat
like
this
in
mid
to
end
May.
So,
thanks
very
much
and
good
evening,
chaps.