►
From YouTube: IETF100-OPSEC-20171113-1550
Description
OPSEC meeting session at IETF100
2017/11/13 1550
https://datatracker.ietf.org/meeting/100/proceedings/
A
A
A
C
C
C
Again
it's
the
first
day,
so
please
circulate
the
blue
sheet,
as
you
may
only
know,
it's
simply
to
size
the
room
for
the
next
IETF.
So
that's
important
I
joined
the
bashing.
So
this
is
the
agenda
that
has
been
on
the
web
as
well
so
game,
2
and
I
will
do
some
a
nice
trivia,
quick
because
it's
not
so
much
activities
on
this
working
group.
There
are
two
documents
and
we
shall
spend
five
minutes
on
each
at
the
table.
C
We
can
group
documents
the
one
for
Fernando
about
eh
filtering
that
went
into
working
group
last
call
and
was
kind
of
back
to
to
the
bench,
and
this
one
that
takes
forever
of
SEK
v6
with
Mary
Kay,
Kay
Kay
and
myself.
We
make
a
status
over
there
and
then
we
start,
as
we
don't
capital
of
upset
meeting
ago,
to
have
working
group
at
create
added
documents.
They
do
not
belong
all
the
time
to
OPSEC,
but
they
have
an
operational
and
security
aspect
and
they
are
put
into
different
groups.
C
C
Okay,
so
let's
go
I'm
mister
via
very
quick.
As
I
said,
Fernando's
draft
on
object,
pv6
extension,
a
header
filtering:
when
there's
you
can
group
last
goal
in
September
and
is
coming
back
and
Fernando
will
explain
which
will
be
changing.
It
was
minor
changes
in
my
opinion,
so
it
could
be
easy
OPSEC.
The
document
objects
is
a
version
12.
C
Now
it
went
on
April
in
the
wiki
book
last
goal
and
it
come
back
with
many
many
comment
which
is
pretty
good,
so
we
need
to
improve
it
and
there
are
two
active
individual
documents,
one
on
ICMP
ingress
filtering
from
Fernando
and
another
one
from
Sri
Rama
about
object,
unique
asset.
We
have
improvement
and
it
will
be
presented
if
waste
time
at
the
end
of
this
session.
E
E
So
these
are
the
changes
since
the
last
version,
not
many,
essentially
one
of
the
things
that
this
IDE
had
it
had
references
to
RFC
2460,
so
that
was
updated.
That
meant,
for
example,
that
there
were
places
in
which
the
document
was
talking
about
behaviors
that
were
not
specified
in
2460,
but
in
updating
documents.
E
So
that
was
updated
because
those
changes
were
incorporated
into
24
into
a
8200,
probably
the
most
important
one
being
the
difference
in
the
processing
in
the
requirement
for
processing
the
hope,
I
hope
options,
extension
header,
which
in
2460
it
said
that
it
was
required
for
all
nodes
to
process
them,
whereas
in
8200
it
essentially
says
that
they
may
process
them
like.
If
you
have
a
reason,
if
you
have
it
been
explicitly
configured
to
process
them,
you
can.
E
But
it's
not
that
you
are
required
and
the
other
thing
is
I
mean
this
was
already
noted
in
the
abstract
or
introduction
as
far
as
I
remember,
but
we
are
in
an
applicability
state
with
notes
that
the
advice
is
for
transit
routers
for
packets
that
had
not
been
directed
explicitly
to
them.
So
if
you
have
one
of
the
rudders,
we
are
not
advising
what
to
do
for
packets
that
are
sent
to
your
router,
but
for
traffic
that
is
going
through
next
time.
E
F
Take
it:
okay,
hello,
uh-huh,
much
better,
a
couple
things
we
probably
should
do
before
we
ship
it
again.
One
is
to
make
a
distinction
about
which
transit
router.
These
recommendations
are
for
one
inside
an
ISP
or
wanted
a
got.
A
customer
reg
another
possibility
it
well.
Actually,
that's
that's
the
big
one.
That's
the
one
that
came
off
the
mailing
list
and
we
probably
need
to
spend
some
time
on
that
uh-huh.
F
E
G
I
Bobby
ended
I'm,
so
I
first
I
agree
with
what
Ron
said,
but
I
I
think
this
also
needs
to
get
some
review,
if
not
a
last
call
in
six-man,
because
if
this
is
in
some
ways
changing
I
mean
six
men
just
went
through
a
you
know:
big
review
of
extension
headers
with
a
what
in
butlet
RFC,
8200
and
sort
of
updated
it
to
what
we
thought.
The
you
know,
the
way
extension
header
should
be
handled,
and
so
this
is
sort
of
saying
something
slightly
different.
I
also
think:
there's
a
issues
like
I.
G
G
E
E
If
you
didn't
want
to
not
process
the
hop-by-hop
option,
so
essentially
the
only
thing
that
we
need
that
we
actually
change
it
in
that
respect
was
that
before
the
publication
of
8200,
we
were
kind
of
like
referring
to
that
behavior
as
non-compliant
behavior,
because
2460
didn't
allow
that,
but
that
was
already
there.
There
was
already
boxes
that
were
not
processing,
hope,
I,
hope
options.
So
what
we
now
did,
the
change
that
we
did
in
this
respect
is
saying.
G
E
Well,
what
we
try
to
do
is
both
actually
we
say
well
we'd
like
them
to
do,
but
for
some,
if
you
have
a
case
where
you
have
an
router
implementation,
that
that's
the
2460
behavior
that
tries
to
say
to
process
all
pi,
you
know
they
hope
I,
hope
options,
and
in
that
case
that
means
that
the
plan
the
packet
is
being
processed
in
the
slow
path.
What
we
say
is
that,
in
that
case,
you
might
want
to
let's
say
no
process
it
at
all
or
prop
it
or
whatever.
That
is
I
mean.
F
Okay,
this
is
one
of
the
areas
where
we
could
use
a
little
refinement.
It
may
well
be
oh,
it
may
well
be
that
there
is
a
router
with
these
extension
header
filters
and
behind
it
is
a
legacy
device
that
doesn't
have
the
8200
and
hop-by-hop
behavior.
It
has
the
2400
2460
behavior.
What's
worse,
it
might
not
even
be
able
to
filter
hop-by-hop
extensions.
So
for
that
purpose
it
might
be
a
good
idea
for
say
a
c
e,
a
transit
router.
That's
a
c
e
to
drop
packets
with
hop
by
hops.
F
Maybe
maybe
not,
but
the
thing
is
it's
only
in
some
very
specific
conditions
and
that's
what
we
have
to
work
out
in
the
draft.
When
does
it
make
sense?
When
is
it
because
you're
protecting
a
device
behind
you
that
can't
protect
itself
or
if
you
assume,
every
all
the
devices
behind
you
already
200
compliant,
then
pass
it?
Let
the
device
behind
you
protect
itself.
E
Like
volunteers
for
review,
or
should
we
ask
that
for
them
so
on
the
mailing
list
there's
like
because
we
did
some
changes
and
if
there's
like
new
people
particular
that
they
can
look
at
the
document?
That'll
be
interesting,
let's
say:
is
they
spot
something
that
the
previous
guys
that
reviewed
the
document
didn't?
But
you
will
see
comment
today
right.
Sorry,
you
receive
comment
today,
so
you
this
should
be
incorporated.
E
Notes
they
coincide
we
received
so
far
they
have
been
incorporated.
So
what
we
like
is
that
for
folks,
that
did
the
comments
they
review.
If
the
changes
that
we
applied.
Actually,
you
know
address
the
issues
that
they
rise,
because
maybe
we
didn't
do
a
good
job
and,
on
the
other
hand,
to
have
like
folks
that
maybe
didn't
look
at
the
document
to
look
at
the
document
because
they
might
but
stuff
that
you
know
so
far.
Other
people
didn't.
H
E
H
E
H
E
H
So
one
of
the
things
that
I
know
they're
doing
in
TLS
now
is
to
just
you
know,
sort
of
include
undefined
options,
but
their
well-formed
with
TL
DS
that
are
correct
so
that,
if
you
just
ignore
them
and
skip
them
and
the
rest
of
everything
parses
correctly,
okay,
there's
a
thing
called
well,
it's
called
greasing
and
it
actually
is
an
acronym.
That
means
I
can't
record
it
means,
and
in
the
in
the
sort
of
a
certificate
format
for
TLS,
everything
is
sort
of
well-formed
TL
of
ease.
H
And
if
you
don't
know
something
you
can,
you
could
skip
it
right,
but
there
are
certain
problems
where,
due
to
ossification
general
ossification
of
the
internet
right,
you
can't,
you
can't
add
new
new
certificate
options
unless
you
have
breaking
things
so
they
they're,
they're
experimentally,
adding
things
that
are
undefined
just
to
sort
of
deliberately
provoke
bro
and
provoke
correct
behavior
I,
wonder
if
we
should
have
such
a
thing
for
extension
options.
Well,.
E
E
By
the
way,
would
you
write
about
experimental
options,
what
we
did
but
Brian?
My
correct
me
is
to
do
what
74,
if
I
was
saying
so
it's
in
line
with
that,
so
just
a
clarification.
The
fact
that
the
document
is
called
blah
blah
blah
filtering
is
not
that
we
are
saying
it's
not
the
white
list
in
document,
but
it's
the
other
way
around.
It
permits
lot
of
stuff
everything
essentially
except
the
stuff
that
is
known
to
be
bad.
Thank
you.
I
I
And
I
agree
with
Bob
that
I
think
six-mile
needs
to
have
a
look.
The
other
thing
I
want
to
comment
on
is,
although
at
the
beginning
of
the
document,
its
scoped
clearly
for
transit,
routers
and
as
Ranas
suggested
props,
you
should
even
scope
it
more
narrowly
for
different
classes
of
transit
routers.
But
in
the
text
of
recommendations
that
says
you
know
the
advice
chapter,
you
don't
talk
about
routers.
I
You
talk
about
intermediate
systems,
which
is
a
very
very
general
term
in
ipv6
land,
so
I
think
it
would
be
actually
just
a
language
change,
but
a
useful
one
too.
When
you
mean
transit
router
in
the
advice
just
remind
the
reader
each
time,
it's
a
transit
route
you're
talking
about
it's,
not
any
arbitrary
intermediate
system
anywhere
in
the
ipv6
internet.
It's
specifically
aimed
at
scoped
for
transit
routers.
That's.
E
K
Point
on
ie
every
with
a
yeah
Lee,
Howard
I
wonders,
responds
to
Erik
from
my
reading
of
the
draft
right
now
it
says
section
4
for
package
with
unknown
v6
options
specifically
defines
unknown
as
not
being
in
the
IANA
registry,
so
Greeson,
and
then
it
says.
Well,
we
can't
do
a
security
assessment
unknown
options
because
they
haven't
been
defined
yet
I
mean
that's
the
it
literally
says,
for
obvious
reasons.
Is
it
possible
to
turn
is
determined
specific
security
implications
of
unknown?
K
Obviously,
every
six
options,
4.4.4
discarding
unknown
ipv6
options
may
slow
down
the
deployment
of
new
ipv6
options.
Exactly
your
point,
as
noted,
the
corresponding
I
net
registry
should
should
be
monitored
such
that
v6
option.
Filtering
rules
are
updated
as
new
v6
options
are
standardized.
So
as
I
read
that
it's
a
it
addresses
the
point
it
says
greasing
would
not
work.
It
says
once
an
options
defines
to
find
meaning
in
the
Ayana
registry.
So
it's
been
through
the
process,
then
we
can
talk
about
which
which
do
it
if
it
shouldn't
shouldn't
discard
automatically.
E
C
C
We
got
a
couple
of
comments
in
April
and
again,
a
couple
of
them
in
July
I
tried
the
version
12
to
address
most
of
them,
but
not
fully
done
yet
so
next,
so
thanks,
Eric
Toby
and
maybe
others
which
end
refusing
related
the
text
was
basically
based
on
the
consensus
that
it's
six
years
ago
and
for
instance,
at
the
last
line
we
say
do
I
stack
is
a
preferred
method
for
transition,
while
I'm
pretty
sure
right.
Now,
it's
not
the
preferred
method.
C
We
can
go
directly
to
ipv6
only,
for
instance,
which
is
more
common,
so
we
remove
the
most
prefer
we
get
it.
I
think
was
from
another
of
the
80/60,
with
stable
addresses
notifier
as
the
prefer
way
to
under
privacy.
Address
case,
a
recline
was
clear.
The
text
around
the
usage
of
ula
was
not
negative
enough
right.
C
My
reading
was
negative,
but
he
did
not
like
it.
So
I
made
it
more
negative.
Send
for
instance,
which
was
six
years
ago,
may
be
useful.
It's
basically
now
no
more
useful
at
all.
So
we
put
at
the
end
of
the
text
and
something
like
that
so
and
then
/
64
post,
we
put
a
couple
of
lines
there
as
well.
That's
the
change
we
see
need
to
do
more
stuff
and,
to
be
honest,
the
three
authors.
We
are
a
little
bit
tired
of
these
documents.
We
cannot
read
it
with
a
fresh
eye
anymore.
C
We
need
fresh
blood.
Okay,
so
we
make
some
inspection
among
the
friends
and
the
security
people
that
knows
about
that
pv6
and
that
one
we
are
ready
to
help
this
with
an
operator
background
as
well,
and
we
found
a
German
guy
called
NRA,
which
is
very,
very
brilliant.
He
knows
a
lot
about
a
pv6
and
security,
so
you
accepted
to
be
a
coder
and
will
be
refreshing
it
that's
the
only
way.
For
what-
and
you
know
a
variety
is
really
good.
Now
we
are
still
open,
of
course,
for
other
people
coming
here.
C
The
goal
is
basically
to
review
thing,
fix
a
couple
of
errors
and
address
it.
In
the
remaining
comment,
I
mean
the
three
others
are
and
I
would
say.
Really.
We
are
fed
up
with
this
document
right.
We
like
it
so
much,
but
we
spend
so
many
time
that
we
cannot
do
but
not
everything
enough
energy
there.
Okay,
America,
does
not
agree
so
much.
L
All
of
the
comments
that
we
received
three
months
ago,
because
when
we
then
put
it
out
last
call
I
but
Lee
had
tapped
into
a
bunch
of
ipv6
operational
folks
who
sent
a
slew
of
comments
that
were
really
good
but
then
actually
looking
through
them,
figuring
out
consensus
and
then
updating
the
document.
It's
something
that
all
of
us,
three
authors
really
haven't,
had
time
commitments
for,
and
so
we
finally
have
decided
that
we
probably
would
like
to
have
a
fourth
co-author.
I
know.
I
know
quite
well
also.
L
So
when
Eric
mentioned
his
name,
I
was
hands
down
for
that.
But
the
question
that
I
have
for
the
group,
especially
those
that
have
have
had
provided
comments,
I
I,
do
have
a
question
in
terms
of
whether
or
not
the
issue
tracker
is
the
best
way.
Like
and
get
to
actually
get
to
consensus
on,
probably
5
10
15
comments
that
we've
had
because
part
of
the
issue
is
that
as
the
years
go
by
some
older
discussions
get
resurrected
and
that's
a
pain
in
the
ass
right
and
so
sorry
for
the
French.
L
L
M
N
Right,
oh
hey,
just
one
comment:
Erik
this
Elliot
on
the
discussion
of
ula
is
in
the
document.
There
there's
one
missing
news
case
where
so
it
seems
for
you
LA's,
which
is
where
you
have
no
internet
connectivity
and
plan
to
have
no
internet
connectivity
so
that
it
really
isn't
a
firewall
issue
there
right.
It's
just
that.
That
was
one
of
these
kids.
Yet.
I
C
I
N
Right
good
afternoon,
my
name
is
Eliot
Leah
I
work
at
Cisco
and
I'm
working
on
something
involving
IOT
security
that
the
chairs
thought
might
be
useful
for
me
to
talk
about
here.
I
see
that
Warren's
in
the
room
here
in
wrong
warrant.
This
this
document
just
went
past
Warren
and
my
goal
actually
is
to
address
IOT
security
from
the
network
perspective
next
slide.
Please
next
slide,
please:
okay,
the
obligatory
blah
blah
blah
25
billion.
N
N
Next
slide,
please,
this
is
not
really
my
problem.
Actually
the
25
30
billion.
Whatever
the
problem
is,
we
don't
know
how
to
enumerate
even
the
number
of
types
of
devices
that
are
that
we're
going
to
that
are
going
to
attach
the
network.
We
can't
even
define
what
a
type
of
a
device
is.
Thus
we
must
once
more
rely
on
big
num
next
slide,
please
within
the
the
axis
of
problems
that
we're
addressing.
The
other
thing
is
we're
dealing
with
a
multitude
of
environments.
Anytime,
we
talk
about
a
thing
right.
N
It
could
be
anything
from
a
one-time-use
device
that
gets
dropped
into
a
lake
which
is
intended
to
survive
for
eight
minutes
or
something
like
that
versus
something
that
is
meant
to
be
dropped
into
a
ground
and
then
to
survive
for
40
years
and
so
in.
In
that
latter
case
there
on
the
right.
You
know
you
can
do
your
configuration
and
amortize
it
over
well
40
years.
N
On
the
other
hand,
if
you're
in,
like
the
medical
industry,
for
instance
and
you're
using
a
device,
the
patient
needs
what
the
patient
needs
when
the
patient
needs
it
and
you
don't
get
to
amortize
anything.
In
fact,
if
it
doesn't
work,
people
are
going
to
go,
frantic
and,
and
possibly
somebody
might
be
injured
or
otherwise
have
a
problem
next
slide,
please.
N
N
You
can't
do
this
just
through
two
network
controls
right,
but
you
you
absolutely
want
the
device
to
protect
itself.
On
the
other
hand,
you
know
defensive
layer
strategy
says
well,
let's
find
a
way
for
the
network
to
help
for
this
purpose,
especially
in
an
enterprise
environment
which
is
where
I
started
and
I
know.
Other
people
are
looking
in
the
in
the
consumer
environment
as
well.
You
know
we
basically
want
the
device
say:
hey
here's,
what
I
am
here's
the
communications
that
I
need.
N
Please
protect
me
and
and
limit
access
to
me
for
only
those
purposes
in
an
abstract
way.
Next
slide,
please
so
I'm
going
to
run
through
this
really
really
quickly,
because
I
know
we
don't
have
a
lot
of
time.
Basically,
the
the
assumption
here
is
that,
in
the
context
of
IOT
the
internet
of
threats,
a
thing
is
a
single
or
is
a
device
that
has
a
single
or
small
number
of
uses,
and
so
it's
we're
not
talking
about
general-purpose
computers.
Here
we're
talking
about
things
with
limited
purpose
and
for
purposes
of
this
discussion.
N
Let's
assume
that
we're
talking
about
things
that
are
relatively
tightly
constrained
and
that
even
the
things
that
can
protect
themselves
today,
probably
won't
be
able
to
protect
themselves
tomorrow,
and
we
can
have
that
discussion
at
the
bar
for
a
very
long
time
and
I'll
get
very
drunk
and
the
other
thing
we'll
make
the
assumption
on,
or
at
least
the
assertion
on,
is
that
network
administrators
get
the
final
say
as
to
how
to
protect
their
networks.
What
I'm
going
to
talk
about
is
more
about
configuring,
the
network
than
about
configuring,
the
things
so
that
seems
fair.
N
N
So
what
does
this
translate
into
in
network
terms?
Very
basically
access-list
right?
We
say
well
this.
This
is
new
technology,
not
right.
It's
been
around
since
you
know,
I
started
in
this
organization
when
you
know
Bob
Hinton
was
young,
and
so
so
this
this
is
good
right,
because
mature
technology,
sorry
Bob
and
just
I'm
having
fun
up
here.
Okay-
and
so
the
good
news
about
mature
technology
right-
is
that
it's
easy
to
integrate
in
and
into
new
solutions.
So
next
slide,
please.
N
So
the
basic
concept
here
is:
the
device
is
going
to
emit
a
URL,
also
not
new
technology
right
using
DHCP
or
lldp
or
802
dot
1x
with
an
AR
certificate.
Also,
not
new
technology
get
that
over
essentially
to
what
I
call
my
control.
The
solution
is
called
manufacturer
usage
descriptions.
The
acronym
is
mud,
which
means
my
marketing
people
hate
me,
and
that
thing
essentially
is
a
triple-a
server
and
it
says
aha
URL.
What
will
I
do
with
this?
So
it
goes
and
retrieves
a
file
write.
N
The
file
is
a
yang
based
JSON
file
next
slide,
please.
So
that's
the
URL
next
slide,
please
that
looks
sort
of
like
this
we're
changing
it.
A
little
bit
based
on
last
call
comments
which
is
basically
an
access
list
and
the
idea
is
to
abstract
out
IP
addresses.
So
you
have
to
fill
in
certain
class
information
on
this
or,
if
you
can
get
it
automatically
filled
in
in
some
cases,
so
that
devices
can
then
just
talk
to
the
things
that
they
want
to
talk
to.
N
So
the
manufacturer
is
providing
this
file
into
the
deployment
the
deployment
gets
to
fill
this
out
and
all
of
a
sudden
you've
just
narrowed
the
scope
of
control
in
terms
of
in
terms
of
who
can
attack
the
device
next
slide.
Please.
So
here
are
some
of
the
abstractions
that
we
have
to
play
with
same
manufacturer.
Let
me
talk
to
things
that
were
built
by
the
same
manufacturer
in
some
cases
just
manufacture.
N
Let
me
talk
to
things
that
are
built
by
a
particular
manufacturer,
and
a
manufacturer
in
this
context
is
basically
the
authority
section
of
a
URL,
so
you
can
create
arbitrary
numbers
of
manufacturers.
My
controller-
and
this
is
more
the
simpler
case
where
you
know:
if
you've
got
a
heater,
for
instance,
it
wants
to
talk
to
its
thermostat,
then
maybe
it
has
a
list
of
thermostats
that
it
is
willing
to
talk
to
and
it
can
list
those
in
a
mud
file.
N
J
N
Are
the
sort
of
capabilities
that
we're
introducing
next
slide?
Please,
and
so
all
that
basically
goes
back
into
the
mud,
controller
mud
controller
in
stalls
it
into
some
sort
of
access
wish
or
something
else
that
can
do
access
control,
and
you
have
yourself
a
party
and
by
that
I
mean
if
you
have
a
light,
bulb
there,
it's
going
to
talk
to
a
light.
Switch.
It's
not
going
to
talk
to
amazon.com!
Probably
okay!
Next
slide!
Please
next
slide!
N
Please
I'm
going
to
skip
the
marketing
stuff,
so
there's
a
little
tension
that
we
always
have
in
the
ietf
between
permissionless
innovation
and
wild
wild
west
and
andrew
sullivan
talked
about
this
in
the
IAB
plenary
a
year
ago,
and
the
basic
idea
is
to
find
a
happy
medium
in
which
the
intent
of
the
users,
the
intent
and
the
intent
of
the
local
network
is
taken
into
account
and
they
get
and
those
people
get
to
make
the
decisions
that
are
based
on
recommendations
from
the
manufacturer.
So
that's
the
meaning.
N
The
minds
network
functions
implement
those
those
that
intent.
If
you
will-
and
this
is
essentially
trying
to
balance
that
tug-of-war-
that
we
see
that
goes
on
next
slide,
please
so
summary
what
you
get
a
URI,
its
new,
its
nifty,
no
use
of
DHCP
or
you
know,
or
TLS
or
lldp,
to
transport,
the
URI
retrieval
of
a
Lud
file
using
essentially
HTTP
as
FTP,
and
not
much
more,
but
a
secure
version
and
instantiation
of
class
information
into
a
router
or
switch
or
a
policy
enforcement
point
in
order
to
protect
the
device.
N
So
that's
it
in
a
nutshell.
Next
slide,
please!
So
recently,
all
right!
The
document
is
completed
both
working
group,
a
last
call
on
IETF
last
call.
We
have
a
bunch
of
changes
to
make
we're
trying
to
address
privacy
considerations
as
best
we
can
with
mod,
but
I'll
point
out
that
the
the
extreme
privacy
consideration
here
is
we're
trying
to
keep
the
device
from
being
attacked.
N
N
We
have
a
bunch
of
other
issues
that
we've
addressed
terminology
editorial
some
clarity
around
HTTP
processing
that
Mark
Nottingham
is
helping
me
with
he's,
also
helping
me
with
making
sure
the
URL
actually
looks
good
we're
gonna
have
a
new
draft,
probably
more
and
I'll
probably
need
to
send
some
new
graphs.
A
new
draft
out
on
this.
Once
I've
talked
to
you
and
a
few
other
people
and
the
ops
area
working
group.
N
So
we
have
one
normative
dependency
issue,
which
is
driving
me
a
little
batty,
which
is
that
we're
in
an
infinite
loop
or
I
should
say
the
ACL
model
is
in
an
infinite
loop.
The
ACL
model
is
an
infinite
loop,
the
ACL
models,
but
anyway
so
and
I'm
trying
to
work
with
the
well
it's
gone
through
last
call
after
last.
F
Bonica
Juniper
Networks
first
like
to
compliment
that.
It's
a
really
good
idea.
The
one
comment
I've
got
is:
it
makes
some
assumptions
about
there
being
minimum
capabilities
for
a
device
to
be
able
to
apply
Ackles.
Your
mud
device
may
suggest
in
a
Collett
says
something
like.
Oh,
if
you
see
such-and-such
a
destination
option,
don't
let
it
through.
It
may
be
that
the
device
doing
it
can't
do
that
right.
N
So
the
model
that
we're
using
is
the
ITF
ACL
model
and
we're
using
even
a
constrained
version
of
that.
So
you
know
you're.
Typically,
the
where
this
gets
implemented
is
in
access,
switches,
routers
and
such
it's
based.
It's
it's
targeted
towards
those
capabilities,
but
montt
has
an
extensive
ility
mechanism
to
target
other
things
that
people
want
to
go
there
I'm
just
not
going
there
now
for.
E
Another
one
I
question
I
mean
the
idea
is
good,
but
I
have
like
a
question
which
is
what
did
you
decide
to
pull
the
policy
from
the
bender
I
suppose
from
the
device?
Because
the.
N
Open
so
yes,
you're
you're,
you're
right,
that's
that's
one!
That's
one
vector
of
attack.
Let
me
let
me
talk
a
little
bit
about
that,
the
first
of
which
is
one
of
the
things
we're
out
for
is.
If
what
we
have
is
a
URL,
that's
in
a
certificate
that
is
signed,
it's
not
the
device
actually
making
an
assertion
about
what
it
wants,
but
it's
the
vendor
of
the
device
making
that
assertion-
and
that's
very
important
because
more
like
the
bigger
likelihood
here,
is
that
the
device
itself
is
going
to
get
hacked,
not
not
some
web
server.
N
N
F
N
So
it's
entirely
up
to
you
as
to
whether
or
not
you
want
to
use
this
functions.
Furthermore,
once
you
get
the
policy
you
get
to
review
the
policy
I
doubt
people
are
gonna
blindly
install
policy
into
their
routers
right
and
then
you
can
decide
you
want
to
use
it
not
want
to
use
it
that
point.
You
know
it's
it's
totally
up
to
you.
It's
your
network,
okay,
cool.
O
N
O
N
So
there
are
a
couple
of
things
that
you
can
do
and
you're
hitting
a
really
good
point
right.
This
is
one
of
the
scaling
points.
The
first
of
all
is
you
can
the
first
thing
you
can
do
is
scope
down
right
just
how
broad
that
you're
going
to
allow
a
manufacturer
to
be
you
can
limit
it
to
within
a
building.
You
could
limit
it
to
within
some
range.
You
can
limit
to
some
number
of
devices
and
you
can
also
say,
hey
wait
a
minute.
This
is
going
to
impact
more
than
n
devices.
I'm.
N
Not
installing
this
today
or
you
can
say,
hey
here's
a
recommended
approach,
use
VLANs.
You
can
allow
for
some
manual
processing
from
Cisco's
perspective.
We'll
probably
do
some
some
things
with
trust
sect,
for
instance,
to
try
and
to
try
and
scale
it,
but
the
the
key
thing
you
know
as
they're
about
the
key
thing
about
mud
right.
Is
it
talks
about
intent
right?
So
here's
a
it
says,
here's
the
intent
and
it
leaves
in
your
local
environment
different
means
for
you
to
implement
that
intent.
N
So
you
could
do
it
with
some
people
wanted
to
play
some
games
with
Sdn
I
know
we
have
one
one
particular
partner
who
wants
to
play
some
games
with
Sdn
in
that
regard
in
terms
of
implementing
intent.
We've
done
some
code,
that's
available
with
that
that
uses
radius
and
uses
free
radius
actually
to
implement
that
intent.
So
there
are,
you
know
a
couple
of
different
ways
you
can
implement
the
intent.
The
key
thing
here
is
to
standardize
the
expression
of
intra
of
intent
between
the
manufacturer
and
your
local
deployment.
How
your
local
deployment
implements.
O
N
N
H
N
Device,
well,
it's
it's
part
of
the
the
authentication
process
in
802.
Don't
want
X,
you
need
a
certificate
and
it's
just
a
manufacturer's
certificate
to
do
the
authentication
in
an
enterprise
right.
You
need
a
scalable
way
to
onboard
devices.
So,
what's
going
on
in
other
working
groups
is
anama
and
things
like
that
in
order
to
do
that
onboarding,
so
you
have
inventory
inside
inside
an
enterprise.
H
P
Okay,
so
I'll
try
and
adapt.
This
presentation
is
one
that's
been
brought
by
calling
on
me
to
the
transport
area,
primarily,
but
it's
of
interest
to
other
areas
and
that's
kind
of
why
we're
doing
the
whole
thing
I'm
going
to
talk
about
the
a
draft
that
describes
the
impact
of
transport
header
encryption
on
operation,
evolution
of
the
Internet,
let's
go
on.
That's
like
transports
are
designed
to
discover
and
adapt
and
where
transport
people.
So
that's
what
we
want
to
do,
make
the
internet
a
better
place
and
over
the
30
years
or
so.
P
Since
transport
people
have
been
doing
this
they've
benefited
from
measurements
and
various
insights
from
operations
on
how
well
these
things
work.
So
that's
where
we're
at
next
slide
and
the
world
was
once
different
to
it
it
to
how
it
is
now
by
back
in
1981,
when
TCP
was
defined.
There
was
some
notion
of
encryption
above
TCP
that
came
to
be
quite
common.
Now
the
world
has
changed
so
that
encryption
might
become
the
norm.
Most
of
the
traffic
flowing
through
the
network
could
be
encrypted
in
some
form.
P
Well,
if
some
of
it's
like
that,
then
nothing
will
break
for
sure
because
I'm,
it's
being
like
that
for
a
while,
with
its
second
VPNs
and
other
things
running
encrypted
mode,
but
there's
a
growing
amount
of
this
traffic
and
there's
proposals
to
make
a
very
large
amount
of
the
traffic
like
this.
It
would
be
good
for
many
reasons.
Right
I
mean
encryption
can
overcome
ossification
your
it
can.
P
P
Oh
and
this
side
was
written
for
you
and
why?
Why
would
operators
want
to
look
at
transport
headers
next
slide,
yeah?
Well,
the
first
ones,
not
particularly
exciting
volume
type
of
traffic.
If
you
can
see
what
the
traffic
is,
you
can
start
dissecting
it
and
understanding.
What's
going
on
quite
important
for
some
people
in
the
operations
area,
particularly
when
you
don't
know
what
some
large
chunk
of
traffic
is
doing
in
your
network
or
you
want
to
say
how
is
it
behaving?
Does
it
conform
to
this
sort
of
compliance
statement?
P
P
Maybe
transport
people
are
more
care
about
dynamics
of
traffic
understanding.
The
scale
of
impact
for
new
features
as
features
are
introduced.
You
need
to
be
able
to
measure
what's
going
on,
and
transport
headers
actually
give
you
a
way
to
measure.
What's
going
on
at
the
point
where
the
change
is
having
impact.
Maybe
if
you
have
switches
deploying
some
new
queuing
mechanisms,
you
can
actually
look
at
the
packets
going
through
categorize
the
flows
look
at
the
behavior
of
the
protocol,
so
you
can
look
at
feature
interactions
that
might
become
more
difficult
if
everything
is
encrypted.
P
So
there's
some
trade-off
here.
Next
slide.
The
protocol
interactions
looking
in
more
detail
about
how
these
protocol
mechanisms
work
try
to
identify
whether
a
new
mechanism
is
being
used
on
a
network
trying
to
identify
what
combination
of
network
level
features
are
used
with
what
transport
level
features.
P
P
If
you
can't
tell
what
the
traffic
is,
then
the
operator
is
going
to
say:
oh
you've
got
this
many
packets
through
your
network
and
it's
still
working,
which
isn't
quite
the
level
of
detail
they
could
offer
if
they
could
say
right
and
looks
like
the
and
your
tcp
is
behaving
oddly
or
your
dns
isn't
working
or
whatever
so
encryptions
got
some
challenges
ahead.
The
purpose
of
our
draft
isn't
really
to
talk
about.
The
motivations
of
this
is
more
I
think
to
look
back
and
say
well
over
30
years,
we've
done
all
this.
P
G
P
Yeah
designing
transport
protocols.
Isn't
that
easy,
it's
possible
to
get
things
wrong,
it's
possible
to
design
applications
that
kind
of
mess
up
other
applications
that
share
the
Internet
and
next
slide
measurements
are
needed.
Where
do
we
get
the
measurement
data
from
well,
we
could
get
it
from
endpoints.
There's
a
trust
relationship
here.
P
If
you
actually
trust
your
content
provider
to
provide
all
the
statistics
about
their
traffic,
that's
a
bit
kind
of
difficult
to
know
the
incentives
for
them
to
provide
you
with
the
right
information,
and
it's
certainly
not
a
good
idea
to
allow
monitoring
at
all
the
edge
devices
to
merge
the
traffic
that
goes
there.
So,
if
the
traffic
monitoring
has
to
be
based
on
measurements,
I'm
measuring
characteristics
will
have
to
be
done.
The
network,
then
you
have
to
give
the
network
at
least
enough
information
to
operate
upon,
go
on
next
slide.
P
P
If
the
world
changes
to
a
fully
encrypted
world,
where
you
don't
see
any
headers,
where
you
don't
know,
what's
using
your
network,
where
you
have
no
idea
about
the
scale
of
deployment
of
anything
using
that
network,
it
might
be
very
hard
to
know
whether
the
mechanisms
we've
built
and
standardized
here
actually
work
for
all
networks.
There's
a
reasonable
diversity
out
there
of
different
link
speeds
it
used
to
be.
P
We
had
an
internet
back
in
the
days
of
the
original
TCP
that
worked
up
to
megabits
I
mean
that
was
unbelievably
huge
here,
no
100
gigabits
is
possible
and
we
want
a
network
technology
that
scales
over
all
these
different
types
of
network.
We
have
networks
with
delays
submit.
Second,
we
have
networks
with
delays,
someone
potentially
ICC
RG
with
over
a
second
of
delay.
We
have
a
very
wide
variety
of
networks,
a
very
large
variety
of
underlying
infrastructure.
P
In
terms
of
the
way
we
get
the
bandwidth
and
capacity,
and
how
do
we
make
sure
all
of
this
fits
together,
well,
I
think
helping
to
do
that
would
be
good
measurements.
That's
the
way
we
would
run
to
date
and
the
IRT
F
procedure
has
usually
looked
at
that
broadness
through
things
like
the
ICC
RG
research
group.
Next
slide
so
trying
to
be
really
quick.
How
does
the
ITF
provide
incentives
to
ensure
a
good
practice
that
benefits
the
wide
diversity
of
requirements
for
the
internet
community
as
a
whole?
P
The
encryption
piece
plays
into
this
space
and
we
want
help
to
try
and
understand
whether
the
piece
that
we've
written
here
actually
heads
in
that
direction,
version
4
of
the
document
has
been
reelected
and
restructured
so
that
you
can
read
the
different
arguments
and
we'd
love
impact
useful
input,
preferably
but
input
of
any
type
go
ahead.
Hey.
Q
Hi
Nalini
Elkins
this
is
this
is
great.
We
actually,
as
a
group
of
large
enterprises
who
run
data.
Centers
are
very
very
interested
in
this
and
in
fact,
we've
been
coming
up
with
a
bunch
of
requirements
and
we
would
absolutely
like
to
see
inside
the
payload
as
well
for
many
many
reasons,
but
definitely
looking
at
the
transport
header,
you
know
helps
us
solve
any
number
of
problems,
because
because
you
can't
really
scale
your
networks
to
up
to
a
certain
point,
I
mean
before
you
really.
You
know
before
the
performance
problems.
Q
J
Fleming,
andrea
is
echoing
a
lot
of
the
comments.
I
think
this
is
great
work.
I
think
we
need
more
awareness
of
these
issues.
It
seems
like
there's
a
lot
of
focus
and
for
good
reason,
of
course,
around
privacy
unions
and
security,
but
we're
forgetting
some
things
in
the
process
and
I
think
we
need
to
have
a
more
balanced
view.
The
operational
considerations
that
you're
bringing
up
here
is
one
of
them.
J
R
Hi
Chris,
Morrow,
Google,
so
I
know
mostly.
This
seems
interesting,
although
I
think
a
lot
of
the
problems
that
you're
sort
of
hidden
or
you
know
linking
to
our
tooling
problems
right,
like
I,
can't
see
inside
the
payloads
I,
don't
know
what
this
is
well,
it's
not
really
true.
There
are
lots
of
behavioral
analysis.
You
can
do
for
the
traffic
they'll
tell
you
yeah,
yeah,
right,
yeah,
sorry,
so
I
think.
Maybe
some
of
the
problem
is
the
world
is
changing
and
the
tooling
has
to
change,
and
so
how
do
we
change
the
tooling?
R
R
Okay,
I
guess
it
seems
like
there's
at
least
three
or
four
different
conversations
about
this
exact
same
topic
and
the
IETF
there
is,
and
they
really
seem
a
lot
like.
We
just
need
better
tools.
Instead
of
we
can
encrypt
stuff
because
I
don't
know,
I
think
I,
I
think
crypting
is
actually
a
good
idea
anyway,
thanks.
Thank
you.
P
So
Warren
quarry
just
want
to
say
this
is
good
work
and
also
use
this
a
little
bit
as
the
soapbox
to
mention
a
related
draft.
The
effects
of
pervasive
encryption
on
operators
yeah,
which
you
do
reference
the
number
of
times
the
soapbox
bit-
is
everyone.
This
is
an
IETF
last
call.
It
went
it
had
a
very
entertaining
last
call
last
time
and
would
be
very
useful
if
people
can
read
it
and
comment,
etc.
It's
very
closely
related
to
this.
P
S
P
But
in
the
IETF,
maybe
we've
done
that
process
and
people
haven't
thought
about
how
we
operated
up
to
the
point
where
that
encryption
takes
place
and
what
actually
we
were
using
those
headers
for
for
other
purposes
than
the
end-to-end
communication,
so
I
mean.
Does
it
hurt
to
expose
an
RTT
measurement?
Does
it
hurt
to
expose
a
packet
sequence
number?
How
much
pain
is
there
in
exposing
somebody
with
connection
ID
I
mean
these
are
things
which,
if
you
took
a
pure
security
model,
for
you,
will
encrypt
everything
because
you
don't
know
what
the
risk
is.
S
Is
the
goal
of
this
graph
to
enumerate
everything
that
all
of
this
unencrypted
headers
are
used
for
and
then
suggest
what
should
should
not
be
kept
or
just
enumerate
or
just
talk
about
stuff?
That
is
being
done
because,
again,
like
Chris,
is
saying
a
lot
of
the
data
that
is
currently
unencrypted
that
may
become
encrypted.
Some
sort
of
frequency
analysis
will
get
you
enough
or
you
could
fast-forward
to
a
world
where
everything
isn't
wrapped
and
quick
and
maybe
not
yeah.
P
P
T
T
How
much
time
do
I
have
seven
minutes
great
okay
afternoon?
Everyone?
My
name
is
Chris
Wood
and
Soph
for
engineering
Apple
and
we're
talking
to
you
about
our
draft,
which
is
on
separate
encrypt
negotiation
and
communication.
This
is
also
something
that
emerged
in
the
taps.
Working
group
next
slide.
Please,
to
give
you
a
little
bit
of
background.
T
Part
of
the
charter
of
the
chaps
working
group
is
to
identify
some
minimum
set
of
requirements
that
transport
services
should
provide
to
applications
and
until
recently,
things
that
related
to
security
were
kind
of
omitted
from
that
particular
set
or
that
minimum
set,
and
we
wanted
to
go
out
and
actually
see
what
you
know.
Particular
security
services
should
be
offered
by
you
know
modern
transport,
security
protocols
and
kind
of.
T
In
that
same
vein,
we
also
started
realizing
know
that
certain
features
of
transport
security
protocols
are
becoming
more
and
more
common
like
session
resumption,
and
things
like
session
resumption
can
happen
on
different
connections
that
the
original,
for
example,
you
can
resume
a
connection
on
a
different
connection
than
when
I'm
the
one
you
originally
received
the
ticket
or
all
right
in
in
TLS
case.
It's
a
particular
ticket,
long
story
short:
you
don't
need
to
use
the
same
transport
connection
for
all
of
your
crypto
needs.
T
You
can
obtain
key
material
and
tickets
on
one
connection
and
use
this
key
material
encrypt
on
a
different
connection.
I
wanted
to
kind
of
see
if
we
could
separate
these
out
and
in
doing
so,
this
led
to
a
more
grand
vision
in
which
we
kind
of
decomposed
transport
security
protocols
into
three
constituent
modules
or
bits
and
pieces.
T
Please,
and
so
this
is
exactly
how
we
define
these
three
things
next
slide
and
they're
related
in
various
ways,
depending
on
which
particular
protocol
you're
using
so
like
TLS,
for
example,
kind
of
lumped
together
the
handshake
and
the
record
protocol
into
the
same
spec
things
like
quick
kind
of
decouple,
the
two
or
the
IDF
quick
or
you
have.
You
know
one
particular
draft
that
defines
how
you
do
handshake
a
handshake
with
TLS
and
another
draft
that
defines
how
you
would
do
the
transport
bits
of
quick
using
key
material
that
you
get
from
TOS
next
slide.
T
Please,
and
so
each
of
these
different
pieces
are
like
I,
said
responsible,
for
you
know
unique
features
or
unique
services
that
are
provided
by
these
transport
security
protocols
like
the
handshake.
One
I
kind
of
enumerated
already
is
responsible
for
things
like
you
know,
authenticating,
an
endpoint,
doing
sorts
of
just
validation
in
a
DTS
world
and
doing
actual
key
exchange
slide.
T
Please
the
record
protocol
or
the
record
module
is
responsible
for
actually
encrypting
data
next
slide
and
the
transport
one
is
basically
about
moving
bits
over
the
wire
and
we
point
to
this
particular
RFC,
which
is
basically
enumeration
of
all
the
existing
IT
of
transport
protocols
and
the
services
they
provide
like
congestion,
control
and
you
know,
multiplexing
and
so
on
and
so
forth.
Next
slide.
T
Here
you
can
kind
of
you,
you
can
decouple
them
accordingly,
like
the
the
record
layer,
for
example,
can
just
suck
in
like
a
pre,
Shirky
or
a
ticket,
and
then
just
are
sending
data
over
to
a
particular
endpoint
using
some
TCP,
socket
or
TCP
connection
you've
established
accordingly
or
if
you're,
establishing
a
fresh
connection
you
can.
Actually
you
would
actually
use
the
handshake
bit
to
you
know,
derive
a
shared
secret
with
the
other
endpoint
next
slide.
Please
quic
is
a
bit
different.
T
The
like
I
said
the
giraffe's
kind
of
keep
these
things
much
much
much
more
decoupled.
So
there's,
like
the
actual
you
know,
main
quick
draft
which
is
responsible
for
things
like
transport.
There's,
a
separate
draft,
defining
exactly
how
you
would
do
handshake
to
derive
the
king
material
with
TLS
and
then
there's
that
also
kind
of
describes
how
you
would
do
like
packet,
protection
and
encrypting
individual
frames,
quick
frames
using
the
secret,
that's
derived
from
TLS,
and
all
these
things
are
kind
of
kept
distinct.
T
So
you
could
in
theory,
for
example,
swap
in
a
different
key
exchange
protocol
instead
of
TLS
and
achieved
the
same
output,
provided
that
the
security
guarantees
of
that
particular
handshake
protocol
matched
that
of
TLS.
That's
to
say,
you
have
the
same
ability
to
authenticate
the
endpoint.
You
have
the
same
ability
to
drive
the
same
kind
of
secret
and
so
on
and
so
forth.
Next
slide,
please
I
mean
TCP,
it's
another
example,
but
these
are
pretty
much
and
you
can
lump
these
all
into
the
same
particular
bucket.
You
know
it
does.
T
So
this
seems
to
be
a
common
pattern.
I
mean
you
can
look
at
many
of
these
different
girls
and
easily
clearly
separate
out
the
relevant
pieces.
The
three
relevant
bits
and
and
actually
doing
this
in
practice,
seems
to
have
a
number
of
different
benefits.
For
example,
you
can
reduce
connection
latency
by
you,
know,
auto
band
going
and
fetching
like
cryptographic,
key
material
like
a
TLS
session
ticket,
for
example,
and
then
using
that
later,
to
resume
your
session
without
as
many
round-trip
times
I
mean
you
might
imagine
a
setup
where
you
have
some
daemon.
T
For
example,
you
know
prefetching
tickets
and
then,
actually
you
know
vending
them
to
clients
that
want
to
use
them
for
faster
results,
a
good
idea,
but
that's
in
theory
you
could
do
that
and
be
fine.
It
also
offers
you
protocol
flexibility
where
you
can
kind
of.
If
you
have
a
common
interface
for
these
bits
and
these
particular
modules
you
could
swap
in
different
implementations
and
in
theory,
have
the
same
effect
so
going
back
to
the
quick
example.
T
If
we
had
a
different
non
TLS
way
to
derive
a
shared
secret
that
was
ID
approved,
you
could
just
shove
that
into
the
handshake
portion
of
the
quic
protocol
and
just
it
would
just
work.
You
can
also
use
this
exploit
this
particular
separation
to
negotiate
protocol
capabilities
out
of
bands.
So,
for
example,
you
could
probe
an
endpoint
to
see
what
particular
protocols
are
offered
like
if
you're
using
kiosk,
for
example,
you
could
learn
that
oh
this
particular
endpoints
before
it's
quick
by
its
LPN
value
that
it
sends
back
and
then
you
could
upon
resumption.
T
So
you
quick
or
h2
or
whatever,
to
talk
to
that
particular
end
point.
So
you
can,
you
know,
learn
things
a
priori,
that
kind
of
help
drive
how
you
would
use
or
connect
use,
a
connection
to
a
particular
different
end
point
or
that
same
end,
point
at
different
point
in
time
and
also
kind
of
leads
to
better
or
more
modular
software
design.
T
Of
course,
if
you
have
these,
you
know
decoupled
components
that
are
nicely
separated
you
can
and
with
a
clean
interface,
you
can
mix
and
match
them
as
needed,
instead
of
having
kind
of
everything
lumped
together
like
in
the
case
of
TLS.
Next
slide,
please
so
this
is,
you
know,
kind
of
brand
new
work
and
still
ongoing.
T
One
of
the
main
goals
were
trying
to
do
right
now
is
to
integrate
the
you
know
the
the
module
interfaces
that
we've
identified
here,
that
is
the
Penn
support
and
shake
transport
and
record
interfaces
into
the
taps
min
set.
So,
like
security
is
reflected
as
a
service
provided
by
a
you,
know,
actual
transport
protocol
about
to
actually
go
out
and
you
know,
get
complete
coverage
of
all
the
popular
transport.
Secure
transport
protocols
that
are
used
today,
and
we
have
we've
looked
at
most
of
the
major
ones.
T
I
mean
the
ones
I've
enumerated
here
and
things
like
minimal
T,
which
are
not
actually
IETF
but
still
relevant.
To
you
know
transport
security
in
general
and
then
the
third
one
is
probably
most
important.
We
need
to
actually
have
this
review
by
the
security
area,
particularly
because
there's
a
lot
of
work
that
went
into
the
analysis
of
TLS
as
a
you
know,
single
complete
protocol,
and
it
requires
a
delicate.
T
You
have
to
be
very
careful
on
how
you
compose
these
things
to
make
sure
that
they
are
still
safe,
like,
for
example,
just
taking
a
record
implementation,
and
you
know
a
key
that
you've
established
out
of
ban
and
using
them
together
and
in
theory
it
should
work.
But
you
know
it,
we
need
to
be
careful,
I
think
that's.
It
did
I
make
the
time.
Thank.
U
U
Describes
it
challenges
to
a
beautified,
IOT
Society
and
consists
of
two
part
of
themes.
One
is
the
problems
in
and
among
industries,
for
the
prompter
realization
of
IOT
and
another
is
safety
considerations.
Problems
in
this
ID
are
result
of
our
interview
to
both
ICT
industry
and
things.
Industry
and
the
safety
considerations
comes
from
our
study
at
the
University
of
Tokyo.
Next,
please
motivation
for
writing.
This
ID
is
to
prototype
engine
of
openly
far
about
the
document
of
very
barriers
against
building
up
IOT
society.
Next,
please
objective
our
activity.
U
U
Up
till
now,
there
has
been
divided
debate
on
whether
that
data
belong
to
the
company
or
to
the
users,
but
one
specific
example
is
of
a
company
that
had
obtained
permission
from
the
head
of
the
household
to
use
a
data
when
it
carried
out
and
him
to
try
out
later
on,
the
suppose
of
the
head
of
the
household
this
agreed
and,
as
a
result,
permission
to
use
of
the
data
was
withdrawn.
So
in
this
case,
who
is
the
user
next
one?
U
Please,
traffic
patterns,
questions
such
as
how
much
traffic
will
come
from
what
kind
of
things
and
how
will
they
superimpose
each
other
have
to
have
not
been
surfaced
sufficiently
studied?
There
is
no
complete
explanation
about
the
backbone,
design
and
operations
of
traffic,
and
there
have
been
many
cases
in
which
the
unclear
specifications
for
IOT
traffic
made
a
design
difficult
on
the
communication
company
side.
Additionally,
the
configuration
of
the
equipment
with
a
large
number
of
sensors
involves
a
lot
of
hard
work.
Next,
please
item
for
the
physically
handling
acquired
data
and
data
calibration.
U
Next
one,
please
highlight
five
product
lifetime.
The
life
life
of
most
ICT
equipment
is
about
five
years
or
less
why
the
life
of
IOT
equipment
and
the
devices
is
at
least
ten
years
in
the
example
of
the
entrance
door
is
connected
to
the
network.
The
communication
technology
and
the
communication
service,
with
most
likely
hub
undergone
numerous
generation
changes
in
that
twenty
to
thirty
years
time
span
of
door
so
ICT
in
the
ICT
field.
The
lifetime
is
almost
under
five
years
versus
in
the
thingis
word.
Lifetime
is
twenty
or
thirty
years.
U
Number
six
fault:
isolation.
If
users
are
left
to
isolate
the
fort
on
their
own,
they
have
not
know
which
manufacturer
they
they
contact
for
repairs
if
they
are
able
to
isolate
the
fault
on
their
own
or
a
manufacturer,
may
refuse
to
perform
repairs
because
r44
outside
the
scope
of
the
Yale
responsibility.
So
we
do
have
to
say
when
the
air
conditioning
is
bad
in
home,
the
end-user
can't
know
which
element
of
the
system
is
out
of
order,
application,
network
or
air
conditioner
itself.
Next,
one
please
next,
please!
U
They
often
ask
question
about
how
many
meters
ready
where
we
can
travel
or
whether
radio
waves
can
actually
travel
the
lack
of
engineers
who
can
advise
on
specialized
the
matters
such
as
this
process.
Major
obstacle
next
one
please
next
to
is
a
corporate
management.
After
now,
companies
in
things
industry
have
developed,
developed
products
in
a
closed-loop
process
seeking
to
capture
users
with
the
company
own
products.
U
For
this
reason,
the
lock
open
design
design
concept,
where
interoperability
today
entirely
new
design
concept,
is
needed
to
design
product
that
can,
inter,
inter
connect
with
products
of
our
other
companies.
Next,
please
and
ecosystems.
In
the
IOT
era,
the
traditional
partically
integrated
way
of
producing
things
is
manufacturing.
Industries
will
consume
too
much
time
and
cost.
U
This
approach
will
makes
it
difficult
to
incorporate
the
ideas
of
other
cultures.
The
need
for
path
need
for
paradigm
shift
is
easy
to
understand
but
difficult
to
implement.
Next,
please
safety
considerations.
I
will
believe.
We
explained
it
next
one,
please
the
challenge
in
protecting
lives
and
property
from
IOT
related
threats.
We
call
that
IOT
safety,
the
introduction
of
IOT
man,
may
generate
the
threat
to
safety
through
the
actual
operation
of
mechanical
devices.
In
addition
to
the
information
security
problems.
U
We
think
in
our
t
word,
we
need
a
countermeasure
to
keep
both
cyber
security
and
safety
in
this
ID
safety
means
avoiding
action
or
a
physical
threat
or
or
from
IOT
devices.
We
call
it
IOT
safety
and
think
we
think
I
OT
safety
is
different
from
cyber
security.
We
show
the
three
examples
in
Hawaii
next,
one,
please,
safety
of
body
body
or
life,
the
missive
application,
sensing,
the
absence
of
a
smart
house
with
smart
meters
or
something,
and
it
send
unloader
commander
to
the
door
keys
and
inform
the
thief.
U
U
U
Next,
please,
we
have
the
experimental
house
in
our
campus
and
in
the
coma
house,
and
the
house
is
connected
the
web
api
at
the
internet,
so
application
benders
can
get
access
to
the
real
world
via
Web
API,
with
out
to
study
the
special
protocol
to
control
the
things.
Next,
please,
we
promote
our
open
innovation
scheme
as
follows
that
all
for
my
presentation,
thank
you.
M
M
M
Yeah
so
last
time
in
Prague
we
presented
this
enhanced
feasible
path.
You
RPF,
and
the
idea
was
that,
and
this
would
work
in
certain
scenarios.
So
the
discussion
we
had
in
Prague
was
that
it
would
work
in
certain
scenarios,
but
there
are
some
other
challenging
scenarios
where
it
might
not
work
by
work.
M
Here
we
mean
that
when
you
do
you
RPF
as
an
opera
as
a
network
operator,
you
want
to
be
careful
about
not
not
dropping
data
packets
of
that
come
in
with
legitimate
source
addresses
and
that
that
could
very
well
happen
with
a
feasible
path.
I
mean
it
does
happen
with
strictly
RPF,
but
it
could
also
happen
with
feasible
path.
M
You
RPF,
so
we
proposed
an
enhancement
which
tries
to
overcome
that
and
the
and
that
that
was
explained
through
this
example,
and
the
basic
idea
here
was
that
if
I,
here,
prefix
p1
on
my
mas
4
on
top
I'm,
the
network
operator
of
a
s4
I
on
this
int
on
the
interface
on
the
Left
towards
a
s
I
have
prefix.
P1
is
what
I
get
in
a
route
and
I
don't
get
p2
on
that
interface.
M
And
what
is
challenging
here
is
that
on
the
left
side
now
s1
uses
no
export
and,
as
a
result,
a
s2
does
not
propagate
p1
and
p2
to
a
s4.
So
in
the
in
the
proposal,
s4
dependent
on
depended
on
a
case
1,
prefix,
p1
or
p2
to
make
it
on
that
interface.
Have
it
out
announced
on
that
interface,
but
that's
not
happening
now.
So
that's
the
challenge
in
this
case.
M
A
so,
which
means
that
you
have
a
picture
of
your
customer
corn
and
some
of
your
prefixes,
maybe
multi-home.
Then
they
are
only
announced
to
you
appear.
Who
is
a
another
ISP
for
your
customer,
and
you
are
hearing
that
prefix
through
the
through
you
appear.
Can
we
go
to
the
next
slide
so
as
just
one
two
minutes?
Okay,
great!
Thank
you!
So
so
they
so
then
this
is
adds
more
flexibility
compared
to
what
we
already
proposed
before,
and
that
additional
flexibility
is
that
I.
M
Look
at
all
my
customer
interfaces
I
make
the
union
of
the
prefixes
that
that
I
see
in
the
routes
on
on
the
customer
interfaces
and
in
addition
to
that,
I
also
figure
out
from
my
peers.
What
are
the
routes
that
are
that
I
am
hearing
in
which
I
see
the
same-origin,
a
SS
that
are
in
my
customer
phone
and
by
so
now
now?
M
So,
by
combining
those
now
I
make
a
union
of
those
prefixes
and
apply
them
in
the
reverse
path:
filter
list
for
each
one
one
of
my
customer
interfaces
and
that
would
then
take
care
of
the
challenging
scenario
that
that
we
earlier
presented,
which
is
there
on
the
left
side,
the
no
export
situation.
So
this
kind
of
addresses
the
problems
or
concerns
that
we
had
in
Prague
and
this
one
next
slide.
M
Please,
the
other
Cooper
concerned
that
we
had
in
Prague
was:
do
we
have
enough
or
how
much
additional
burden
is
it
going
to
impose
on
the
RHIB
memory?
And
for
that
we
estimated
the
customer
cone
sizes
for
different
ISPs,
global,
large,
global
midsize,
regional
etcetera,
and
what
we
see
that
is
that
the
prefix
ranges
might
be
in
the
30,000
to
the
1000
range
and
the
customer.
Concise
equals
zero,
reverse
path,
filter
size
next
slide,
please
so
the
reverse
path.
Filter
size
is
the
additional
50
that
you
need
in
the
line
card.
M
In
order
to
implement
this,
you
Artie
and
what
we
gather
from
from
product
literature
that
you
can
have
larger
ESPYs
might
have
two
million
to
6
million
smaller
ice
bees
might
might
have
only
100k,
but
no
matter
which,
if
you
compare
these
numbers
with
the
with
the
Archaea
filter
size
on
the
previous
slide,
are
those
the
additional
fit
memory
that
you
require
is
only
ordered
on
the
order
of
one
percent.
So
we
are
hoping
that
this
analysis
is
good
and
it
addresses
the
fit
memory
issue
as
well.