►
From YouTube: IETF95-OPSEC-20160405-1740
Description
OPSEC meeting session at IETF95
2016/04/05 1740
A
B
E
F
Afternoon
and
thank
you
for
listening,
I
will
be
talking
about
a
configuration
file
format
for
network
services
on
beef
devices,
which
is
a
bit
of
a
barky
term
to
describe
end-user
devices
like
ass,
laptop
or
smartphone,
maybe
smartwatches,
and
maybe
I
OT
devices,
all
of
which
could
benefit
from
being
configured
properly
and
not
all
of
them
can
easily
become
be
configured
properly.
So.
F
F
Because
you
might
wonder
hey,
why
is
this
guide?
Upcycled
I've
seen
him
at
other
locations
before
so
I
was
presenting
something
very
similar
in
both
ops
area
working
group
I
give
Matty
one
I'd
in
sac
in
the
IDF
93like
plan,
with
a
slightly
different
name.
I
was
only
calling
this
JEP
metadata
lost
that
conflict
metadata,
but
well
I'm
here,
because
this
topic
definitely
has
an
operational
component.
F
You
want
to
make
sure
that
some
kind
of
device
actually
works
and
people
get
network
service,
but
there's
also
a
security
component,
because
you
also
want
to
be
things
to
be
configured
so
securely
that
nothing
I,
think
that
happens
with
the
device
once
it's
on
the
network.
Some
examples
for
render
protocols
here.
So
imagine
you
are
configuring,
some
IMAP
access
and
you
didn't
select,
start
TLS,
but
instead
some
default
was
about
start
here
less
if
available.
So
this
means
the
man
in
the
middle
can
just
rejected
the
start.
F
So
the
draft
I'm
presenting
huge
day
is
actually
has
grown
out
of
these
comments
from
apps
are
a
working
group
and
from
sag,
and
it's
now
significantly
extended
according
to
these
comments,
so
I'm
here
on
this
slide
here
and
basically
one
big
use
case,
which
motivated
me
for
starting
this
black
rod,
so
I'm
a
Wi-Fi
person-
and
we
have
this
wonderfully
secure
network
called
at
your
own,
which
is
based
on
EAP
and
attributed
to
them
for
max,
and
this
is
really
a
perfectly
secure
protocol.
Many
years.
F
Of
working
in
the
IDF
in
this,
this
is
using
EAP,
and
the
story
goes
that
when
you
connect
to
the
network,
the
first
thing
that
happens
is
that
the
end
user
device
authenticates,
which
network
it
is
talking
to
so
there's
some
kind
of
server
certificate
being
presented
by
the
authentication
server
and
the
end
user
device
verifies.
Yes,
I
can
safely
sent
my
username
and
password
to
this
very
server,
because
I
know
this
is
the
right
server
to
talk
to.
F
Only
after
this
verification
of
the
server
side
has
been
done,
the
client
actually
sends
a
username
password
or
whatever
he
has
to
authenticate.
We
use
this
extensible
authentication,
protocol,
JP
and
business.
Really
one
of
those
cases
where
you
say
wonderful,
nothing
can
possibly
go
wrong.
Jp
was
carefully
designed
and
you
can't
can't
do
this
incorrectly.
F
This
is
the
last
theory,
but
the
problem
with
is
is
there
is
some
practice
in
this,
and
we
have
learnt
that
this
is
pretty
much
a
heart
fail
and
this
doesn't
work
as
expected
problem
we
have
is
that
client
devices
have
to
be
configured
by
end
users
in
many
cases,
so
there
are
some
secure.
There
are
some
enterprise
deployment
where
the
admin
actually
does
everything.
F
It's
still
manual
work,
but
you
know
it
gets
done
correctly,
but
if
you
are
talking
and
bring
your
own
device
and
actually
end
users
fiddling
with
settings
on
the
laptop
which
they
don't
understand,
things
typically
the
wrong.
So
what
we
see
is
that
when
user
interfaces
like
an
Android,
basically
ask
you,
oh
you
don't
want
to
validate
this
service
it.
If
they
do
you
and
you
actually
have
to
manually
say:
oh
yes,
I
want
this
server
certificate,
verification
to
actually
do
actually
get
your
security
and,
as
it
happens,
nobody
ever
does
that.
F
F
So
so,
if
you
just
tap
on
an
enterprise
network,
you
don't
verify
the
server
certificate
you
can
just
type
in
your
username
and
your
password
and
if
you're
connect
you
to
the
general
network,
that's
all
fine
and
you're
using
a
password
gets
validated
in
your
online,
but
as
it
happens,
a
robe
access
point
could
just
present
itself
with
the
same
SSID
and
since
you
didn't
verify
the
server
certificate
you
just
sent
the
username
a
password
to
some
random
third
party.
Oh,
that's,
not
good!
It's
kind
of
a
zombie
state!
F
It's
it's
hid
enough
to
work,
but
it's
not
good
enough
to
be
secure
and
unfortunately
we
see
that
quite
a
lot
in
the
deployed
world
out
there.
So
what
you
have
here
is
a
kind
of
an
odd
situation.
You
have
something
that
was
designed
to
work.
Well,
it's
somehow
it
doesn't,
and
you
wonder,
who's
to
blame
for
that
or
just
to
wake
you
up
with
some
random
animation,
asking
the
question
who
killed
the
page
so
on
one
side
of
the
world.
F
Who
is
a
design
team
which
created
a
wonderful
protocol
and
something
that
runs
in
squeaks
and
then
all
my
stuff
and
on
the
other
side,
is
the
unsuspecting
user
who
doesn't
know
anything?
What
happened
on
the
other
side,
so
somebody
designed
a
protocol
and
the
end
user
doesn't
know
under
which
conditions?
Is
it
secure?
F
What
we
have
to
do
to
deploy
this
securely,
and
he
said
there
was
nothing
he
particularly
doesn't
know
that
there
is
any
current
pig
and
that
he's
supposed
to
catch
it
and
where
exactly
it's
coming
over
the
world,
so
it
could
be
sending
at
any
point
and
as
a
result,
our
this
wonderful
design
team
with
its
complicated
protocol
here
just
thirsting
over
the
wall.
The
user
is
not
in
a
position
to
actually
receive
the
pic
correctly
and
the
files
on
the
floor.
It
is
it
and
now
the
question
is
okay,
who
is
responsible
for
that?
F
And
the
user
will
say.
Okay
I
didn't
know
that
there
was
big
coming
so
I
couldn't
possibly
catch
it
and
the
design
team
says
oh
well,
but
when
we
did
on
our
side
it
was
actually
working.
Just
as
designed
it
was
grunting
and
squeaking
like
crazy
when
we
food
of
the
wall
so
must
be
offered
on
first
iteration.
F
Then
well,
we've
done
a
suboptimal
job
so
now
the
question
is
how
many
pigs
died
and
how
many
actually
get
caught
by
end
users
and
well.
The
news
is
that
we
bad-
and
there
are
many
studies
happening
mostly
in
Germany-
also
other
places
about
how
much
bad
news
is
they're
out
there
in
our
at
your
own
network
and
well.
These
people
are
found
out
that
share
of
fifty
two
percent,
wrongly
configured
devices
existed
and
out,
of
which
twenty
percent
just
sent
the
username
in
here
texts
are
to
a
random
attacker.
F
So
we
are
not
talking
about
a
bottom
of
the
barrel
situation
here,
it's
not
just
those
few
users
who
didn't
care
enough
to
get
things
right.
This
is
actually
a
slight
majority
of
devices
which
just
don't
Gary
Athens,
throw
their
credentials
away.
F
Unfortunately,
I
have
to
say
this
was
even
our
with
administrators
at
the
University,
where
this
was
conducted,
who
are
really
loving
and
caring.
So,
a
few
weeks
before
they
actually
ran
the
test.
They
infirmed
users
how
important
it
is,
and
they
gave
them
a
lot
of
instructions
that
producers
ok.
Do
it
now
you're
insecure?
If
you
don't
do
it,
and
even
with
that,
fifty
percent
failure
and
I
think
that's
pretty
much
a
catastrophe
security
wise.
So
we
really
should
be
doing
something
about
this.
F
The
same
study
also
are
has
some
silver
lining
on
the
horizon
because
they
found
out
something
else
as
well.
The
comparatively
smaller
of
thirteen
percent
of
Romney
configured
ever
devised
might
be
due
to
simplifications
of
the
Wi-Fi
configuration
by
importing
pre-built
configuration
profiles.
Hey
that's
good
news,
so
the
difference
between
Apple
and
operating
any
fingers.
But,
let's
see
android,
is
that
Apple
has
this
conflict
format
type
mobile,
config
file
and
there
you
can
put
all
kinds
of
service
configurations
in
not
just
Wi-Fi.
It's
also
about
VPNs
in
the
fundamental.
F
F
So
this
is
why
I
started
this
and
it
used
to
be
just
about
the
EAP
configuration
parts
right.
It
was
Wi-Fi
networking
after
some
comments
here
in
the
IDF.
We
changed
the
coverage
to
do
more
than
just
based
Wi-Fi,
but
I
could
use
some
help
here
and
that's
on
the
next
slide
so
on,
but
I
have
here
is
first
of
all
the
realization
that
some
of
the
things
you
use
for
your
Wi-Fi
network
can
probably
be
reused.
F
So
if
you
have
a
root
CA
certificate
for
your
server
name
verification,
if
it's
bit
for
Wi-Fi,
maybe
your
VPN
server
uses
the
same
root
certificate.
So
maybe
you
want
to
specify
this
once
in
the
configuration
file
and
reference
it
from
the
Wi-Fi
and
from
the
VPN
configuration
one
thing.
We
also
think
we're
doing
actually
better
than
apple
and
is
that
the
same
username
and
password
is
often
used
or
more
than
one
service.
C
F
This
on
another
mobile
config
file,
you
have
for
Wi-Fi
networks
in
the
VPN
and
then
I'm
observer
during
the
import
of
the
config
file
will
be
asked
for
six
times.
What
is
the
username
for
this?
That
is
aspect
for
this,
and
there
is
no
way
in
the
proprietary
apple
format
to
say:
ok,
ask
the
user
once
voice
credentials
and
apply
to
all
those
services.
F
Another
common
I
got
where
I
started
with
XML,
because
I
like
XML,
but
the
ops
people
told
me
I-
should
really
be
using
yang.
So
this
new
draft
here
is
now
a
young
man,
you
hopefully
people
I
mean
this
is
quite
extensible,
so
that
if
you
want
to
plan
more
services
into
this
config
format,
you
can
just
do
that.
F
Well,
I'm,
the
wife,
a
person.
So
if
you
look
at
the
yang
module,
which
is
referencing
the
draft,
you
will
see
that
Wi-Fi
and
EAP
are
get
the
bag
off
of
detail
here,
because
I
know
that
best
and
here
I
could
could
use
some
some
people
actually
working
with
me
to
plug
in
some
more
services,
particularly
VPN.
F
So
if
you
do
take
a
look
at
the
draft,
the
draft
is
hopefully
an
easy
narrative
style.
It
doesn't
explain
every
single
detail
of
the
yang
module.
You
will
see
that
we've
taken
some
care
to
to
be
extensible
here
there
is
one
block
which
is
provider
info.
So
when
you
import
the
comic
file,
you
should
be
told
who
is
sending
you
this
file
and
what
other
terms
of
use
of
the
network
and
so
on.
How
can
you
reach
the
help
desk
of
something
as
well?
F
It's
some
kind
of
meta
information
here
and
there
is
a
block
where
you
can
specify
certificates.
This
will
be
a
certificate,
mediates,
client
certificates
and
so
on.
Now,
then,
you
have
a
blog
called
client-side
grin
credentials
which
can
be
hold
to
store
user
names
and
passwords,
maybe
a
private
key
to
a
certificate.
It
can
also
be
pretty
much
empty
and
you
can
just
say:
okay,
this
is
a
client-side
credential.
It
has
a
new
ID
but
I'm
not
telling
you
the
actual
user
name
and
password.
F
So
when
you
consume
this
kind
of
fun
fig
file,
you
would
realize
hey.
I
have
to
ask
the
shoes,
of
course,
using
a
password,
but
since
there
is
a
year
uid
attached
to
this
block,
even
if
it's
otherwise
empty
I
can
still
say
whatever
the
user
puts
in
here
once
can
be
the
credential
for
all
kinds
of
other
services.
What
lenses
were
talking
about
configurations?
There
is
something
for
IP
settings
like
dhcp,
a
device
used
to
put
your
network.
F
What
the
draft
is
currently
quite
silent
about
is
one
important
thing,
but
we
haven't
figured
out
yet
so
when
these
config
files
will
need
some
kind
of
signature
end
encryption
at
some
point,
so
we
have
yang
as
a
source
format
which
it
doesn't
go
on
why
anyway,
but
it
produces
XML
and
JSON
formats
among
others.
So
once
you
have
this
fight
in
your
hand,
you
may
want
to
sign
it
just
to
figure
out.
Is
this
actually
coming
from
from
my
provider?
F
So
well,
if
you
are,
what
in
the
world
could
drip
the
xml
file
or
you
can
use
the
encryption
for
a
json
from
jose
again,
we
don't
really
know
which
path
to
take
just
yet
since
we
are
having
one
android
app
would
actually
consumes
an
earlier
version
of
this
file.
We
took
a
look
at.
We
realized.
Okay,
if
we
want
to
go
xml
signature
end.
Encryption
are
nothing
on
androids
about
this,
so
we
are
forced
to
live
some
and
there
are
some
hits
which
do
these
signature
and
encryption
our
JSON.
F
Right,
I'm
pretty
much
done
next
steps
for
this
left.
What
I
would
love
to
see
people
like
a
chiming
in
and
say:
okay,
we
have
some
network
services
like
VPN,
and
we
would
also
appreciate
if
these
settings
can
be
positive
entries
of
devices
and
welcome
the
yang
module
and
also
at
some
point
I
would
love
to
see
this
picked
up
in
the
IGF.
That's
why
I
came
here
so
fabulous.
E
G
E
H
D
Stimulus,
I
haven't
read
the
draft
and
I
was
involved
with
eduroam
many
years
ago
when
way
up
it
is.
It
sounds
like
a
useful
concept.
It
is
really
hard
for
users
to
get
this
right
and-
and
you
know,
there's
been
similar
things
a
little
bit
like
tunnel
set
of
protocols
for
ipv6
tunnels
or
stp
files,
for
instance,
or
its
kind
of
useful
to
have
some
way
of
describing
this
and
some
kind
of
standard
format
and
other
users
to
buy
all
the
parameters
manually.
D
F
Actually
dhcp
has
an
authenticated
mode
r,
which
could
just
let
you
talk
to
one
dhcp
server,
but
you
have
to
configure
some
kind
of
authentication
key
so
that
the
client
device
notes
which
gets
you
supposed
to
talk
to
this
was
never
deployed
anywhere
and
I.
Guess.
One
of
the
reasons
is,
it
is
just
ask
too
much
from
an
engine
user
to
manually
configure
HTTP
to
then
get
an
automatic
address.
But
if
you
have
some
kind
of
conflict
format,
you
could
just
say:
hey,
there
are
the
settings
here.
Is
my
lips
abusive?
I
H
Ten-Chan
again,
Stefan
may
come
at
me
with
a
big
stick
if
I
say
this,
but
I
wonder
whether
this
is
something
that
might
be
relevant
in
the
captive
portal
group
as
well,
since,
presumably
they
want
to
do
secure
configuration
of
their
devices,
but
it
would
be
a
bit
ironic
going
there
to
solve
an
eight.
Your
own
problem
well.
F
C
E
K
My
name
is
Andrea
I'm,
going
to
present
on
a
draft
wink,
Tim
MLG
security,
which
is
offered
by
free
persons,
Eric
wink
Antonio,
said
Lazarus,
who
works
for
him
as
a
researcher
for
an
agency
in
the
Netherlands
and
myself.
The
background
of
this
draft
is
that
in
the
organization
where
I
walk,
we
do
a
lot
of
protocol
in
security
research
and,
like
two
years
ago
we
started
looking
at
MLD
security
from
a
very
practical
perspective,
which
means
we
build
a
test
lab
with
different
operating
systems.
House.
C
K
K
With
Andi,
which
presumably
goes
back
to
this
statement
and
RCA
4861,
which
says,
are
joining
the
solicited
note
group
which
I
mean
4861,
is
about
neighbor.
Discovery
is
done
by
means
of
MLD,
and
there
is
a
statement
is
done,
which
can
either
be
like
descriptive,
describing
reality
or
be
prescriptive
or
normative.
K
She
would
say
how
it
should
be
done.
Point
is
that,
strictly
speaking,
when
looking
at
MLD
I
assume,
most
people
in
the
room
are
familiar
with
what
Emily
does
very
shortly?
It's
about
forwarding
it's.
It's
a
it's
for
routers
to
find
out
on
an
adjacent
link
which
is
there
actually
listeners
interested
in
certain
multicast
groups.
For
that
purpose,
router
sent
out
packets
or
queries
asking
house
on
the
link
like?
Are
you
interested
in
any
multicast
groups,
and,
if
so,
which
are
those
and
house
can
respond
to
these
by
means
of
report?
K
All
operating
systems
involved
had
MLD
running
being
active
by
default,
enabled,
except
for
obviously,
and
sending
Emma
the
reports
evening
without
being
query
to
as
part
of
their
interface
initialization
process.
So
it's
there
as
I
as
I
say
that
pretty
much
every
operating
system
has
it,
but
it's
susceptible
to
certain
attacks
at
the
very
same
moment,
and
these
attacks
are
somewhat
based
on
the
fact
that
emily
has
certain
properties
as
a
protocol,
I
mean
there's
to
Washington
adv.1
specified
as
of
27
10
and
emily,
we
to
mainly
specified
in
RFC
38
n.
The.
K
K
So
that's
an
election
process
which
can
be
easily
forged.
These
are
the
properties
and
the
there's
three
main
types
of
attacks
that
we
identified.
First,
it's
very
easy
to
our
enumerate
hosts.
Actually
you
can
do
so
passively.
K
One
doesn't
have
to
interact
actively
just
listen
to
mr
d
and
one
will
see
which
which
also
active
on
the
local
link,
and
it
is
easy
we
identify
the
operating
system
as
the
host
join
multicast
groups,
depending
on
their
like
windows,
sir
joints
and
a
lemon
I'll
group
and
Linux
systems
join
mdns
once
he
Allah
he
demon
is
running.
So
it's
it's
easy
to
identify
active
speakers
and
to
identify
the
operating
system
which
in
itself
isn't
big
deal,
isn't
a
big
deal.
But
it's
it's
one
of
the
potential
attack
paths.
K
D
K
K
To
the
point,
when
I'm
going
to
cover
that
the
types
of
attacks-
actually
there
is
issue
is
with
his
unique,
has
communication
I'll
get
back
to
this
in
a
second
to
them
that
the
second
much
more
interesting
say
attack
path
is
flooding
and
amplification
attacks.
First,
it's
easy
to
flatten
local
linked
by
say,
send
an
MLT
query
watch
one
and
create
high
number
of
answers.
K
Usually
you
can
expect
each
each
host
to
respond
for
TV
too,
but
we
want
it
to
be
different
with
it
doesn't
get
better
in
any
case,
for
every
multicast
group
to
join
the
host
has
joined,
which
is
he
about
four
by
peter
/
e
fault
sent
to
reports,
and
this
is
done
by
every
host.
So
simply
MAF.
There
say
assume:
there's
200
active
house
on
a
link.
K
You
send
one
packet,
you
get
2
x,
4
x,
200,
packets
back,
so
it's
1,600
packets
by
just
sending
one
so
there's
a
high
amplification
wake
tour
which
can
be
easily
have
used
to
flatten
local
link,
and
we
did
some
testing.
We
flooded
actually
devices
by
sending
specific
packets
just
to
them
and
we
were
able,
with
one
simple
tool,
sending
packets
too
high,
and
that
case
Cisco
devices
we
were.
We
were
able
to
render
an
ASR
1000
to,
in
that
case,
unresponsive
by
just
sending
packets
from
one
single
host
and
ASR
1000.
K
That
is
not
like
that's
not
a
soul
device
and
there's
the
third
type
of
devices
and
now
I
get
back
to
your
questions.
The
point
is
once
you're
on
the
locally
it's
pretty
easy
to
exclude
or
to
disrupt
multi-car
swimming
on
Beaufort
ml
db2
and
we
won.
The
specifics
are
a
bit
different.
We
have
a
technical
report,
a
very
detailed
one,
laying
out
tech
types,
that
the
basic
rationale
is
a
first
step
take
over
the
courier
role,
which
is
easy.
K
Second
step
is
sent
and
now
comes.
The
unique
art
thing
send
unique
aspects
to
the
former
Korea's,
which
are
still
in
for
walling
state,
like
the
active
routers
on
the
link
you
sent
by
unique,
has
packets
like
telling
oh,
please
MLD
done
or
a
report
leave
the
group
messages.
What
happens
then,
is
usually
I
depicted
in
finally
be
one
as
this
is
the
easier
case
the
courier
will
like
it
doesn't
keep
state
who
are
the
actual
listeners.
K
It
just
keeps
state
there
is
at
least
one
so
once
such
a
packet
is
received
like
I'm
leaving
the
group,
the
the
courier
sends
out
so
called
last
listener.
Query
like
okay,
have
you
been
the
last
guy
or
anybody
else,
and
the
remaining
hosts
are
expected
to
reply
it
on
that?
If
you
send-
and
we
did
all
this
in
practice,
so
it
actually
was.
If
you
send
unique
ass
to
those
holes,
no,
you
don't
have
to
use,
send
you,
because
you
just
sent
another
report
message,
so
they
think
oh
wait.
K
What
we
don't
have
to
respond
and
the
the
following,
the
pre
aquarius
early
aquarius,
which
are
still
in
forwarding
state
and
now
delete
the
group
as
they
send
out
the
last
listen
aquaria
didn't
get
a
response
and
they
think
oh,
doesn't
already
left
this
works
for
we
want
when
we
too
will
be
different
slightly
different.
The
tech
know
that,
but
actually
what
is
possible.
K
D
So
yeah,
you
know
one
more
thing
could
be
to
say:
okay,
you
should
only
send
messages
to
the
multicast
group,
but
there's
also
because
of
issues
with
multicast
and
layer
to
you
and
like
Wi-Fi.
There
are
implementations
that
might
use
a
actually
like
a
unicast
mac
address
as
a
destination,
even
for
even
yeah.
Even
although
is
in
a
emily
report
to
multicast
group
grip
address,
it
might
be
actually
unicast
it
anyway
at
layer
2.
K
K
We
don't
think
there
are
so
much
reason
why
host
should
be
permitted
to
send
our
queries.
They
are
supposed
to
send
reports
in
response
to
various
sent
out
by
others
so
similar
to
our
I
God.
We
suggest
coming
up
with
j
feature
which
we
right
now
called
MLD
guard,
which
essentially
says,
which
is
a
stateless,
simple
filter,
filtering
icmpv6
type
on
the
32
to
inhibit
host
from
seneca
varies.
This
would
probably
are
very
much
block
most
of
the
attacks
that
we
described.
It
will
still
allow
a
house
to
send
high
number
of
malformed.
K
We
put
responses
reports
which
we
did.
That
is
one
thing,
but
it
will
block
many
of
the
attacks.
The
second
path
for
that
we
actually
suggested
some
kind
of
walk
on
these
properties
of
Mr
D,
which
actually
enable
those
attacks
which
the
handling
of
the
hob
limit,
which
could
be
substituted
by
like
send
packets
with
255
and
check
up
on
reception
if
they
still
have
255
there
was
this
thing
well
is
it
should
be
allowed
to
get
Emily
packets
on
unicast
addresses?
K
So,
overall
we
said
we
bring
up
the
idea
of
walking
on
some
of
the
protocol
properties,
but
this
would
mean,
while
working
on
a
new
spec
on
a
piece
of
27,
10
and
30
8
10.
This
might
be
much
more
difficult.
Overall,
the
MLD
got
feature
that
would
be,
we
think,
a
very.
D
Couple
of
comments,
if
I
may
and
stick
with
us
so
certainly
understand
there
are
security
issues
with
unique
Austin.
It's
interesting.
What
to
explain
earlier.
I
have
some
concerns
about
making
making
it
illegal
low.
For
instance,
it
has
been
talked
about
various
optimizations
for
improvements,
so
Emma
leave
our
unit
costs
might
be
helpful
and
for
air
one
example
is,
if
you
do
explicit
tracking,
so
you
know
exactly
who
has
joined
that
the
multicast
group
when
you
send
like
them
the
last
you
know
if
had
to
check,
if
you're
still
receivers,
if
people
are
still
interested.
D
There
are
suggestions
that
you
could
unicast
carries
to
just
those
particular
members
instead
of
multi
casting
to
everyone
on
the
link
and
the
other,
smaller
in
suggestions
tip
or
basically
how
to
basically
a
better
handle,
Wi-Fi,
n
and
multicast.
But
this
it's
something
we
should
discuss
for
the
hop
limit.
I
wish
it
said
355
in
this
back
and
they
couldn't
change
it,
but
I'm
a
little
bit
concerned
about
how
we
will
actually
do
that,
because
it
will
take
a
long
time
to
get
hosts
tax
upgraded
and
you
can't
really
mandate
is
on
the
router.
D
Silent,
you
know
that
all
your
hosts
supporters
does
say,
though,
in
the
spec
for
at
least
imma
leave
it
to
that
you
should
use
a
link,
local
source
address
and,
in
theory,
router
should
not
follow
those
packets.
The
be
interesting
to
see
if
our
implementations
that
actually
do
it
anyway,
but
if
the
routers
don't
forward,
link
local
source
address
packets
and
the
router
implementations
and
house
implementations
check
for
a
source
being
linked
local
than
in
theory.
D
K
I
have
a
comment
on
this,
like
the
idea
of
keeping
state
of
actual
listeners
to
address
those
on
a
unique
has
basis
once
a
leaf
or
a
done
message
has
been
received.
Personally,
I
would
be
quite
skeptical
about
this,
as
it
would
heavily
increase
the
amount
of
state
to
be
kept
on
an
emetic
area
and
in
general
I'm.
Not
a
big
fan
of
giving
my
security
background
of
keeping
much
state
on
on
routers.
C
K
Me
so
I
intuitively
I
I
would
be
skeptical
about
that
one
as
I
say
that
I
think
the
most
important
thing
would
be
having
like
an.
K
D
G
H
D
E
K
So
on
the
adjacent
link
on
Zoe
and
we
checked
the
number
of
operating
systems,
none
of
which
accepted
packets
with
a
non
linked
local
sausage
Wes
some
expected
packets
with
a
up
limit
bigger
than
one
which
I
shouldn't,
but
still
they
did
but
I,
don't
think
remote
attacks
from
what
we've
seen
would
be
very
feasible,
but
part
of
the
attacks
that
are
laid
out
is
that
you
can
interact
in
a
one-to-one
manner
without
the.
H
Tim
Chang
and
so
I
assume,
if
it's
remote,
it's
going
to
be
very
difficult
for
thee,
remote
toaster,
to
determine
what
the
unicast
address
to
send
that
message
to
would-be
on
link.
I
guess
you
can
apply
these
types
of
filtering
methods
so
that
other
hosts
on
the
same
on
the
same
subnet
may
not
even
see
the
reports
that
the
host
is
sending.
I
guess
yeah.
H
D
Oh,
there
is
another
carrier
here,
for
instance,
I
know,
but
before
with
multicast,
it's
really
hard
to
do
enough
link
attack
right.
At
least.
I
think
most
implementations
check
that
the
group
is
the
correct
multicast
group
and
if
you
are
off
link
and
it
and
you
have
to
do
multicast-
I
mean
if
it's
not
a
link-local
multicast
group,
then
someone
on
the
link
must
have
joined
the
group
party
to
be
forwarded
to
the
link.
So
it's
very
hard
to
do
an
uplink
attack
with
multi
costs.
Yeah
I
would
agree
that.
I
E
L
It
is
an
update
of
the
document
that
we
had
presented
at
the
last
object
meeting,
based
on
the
feedback
that
we
got
at
that
point.
So
the
goal
of
this
document
is
to
specify
filtering
that
could
be
enforced
close
to
the
end
user.
Such
that
attacks
that
rely
on
spoof
error
messages
can
be
mitigated,
as
I
said
it
has
to
the
goal,
is
to
you
know
the
post:
is
this
filter
this
filtering
policy
next
to
the
user
and
must
never
be
apply
in
cases
where
you
have
multi
home
scenarios?
L
Okay,
this
is
a
kind
of
background
or
overview
on
the
ICMP
error,
message
and
generation.
So
in
this
case
we
have
the
house
a
that
is
trying
to
say
to
send
something
to
cos
T
and
if
the
router
finds
that
there
is
some
sort
of
error,
it
will
send
an
ICMP
error
with
a
structure
that
we
have
here.
Okay,
obviously,
the
source
address
of
the
ICMP
error
will
be
that
of
the
router.
L
So
one
thing
that
is
important
is
that,
obviously,
since
this
error
messages
could
be
sent
from
any
node
potential
Rueter
in
the
network,
if
you
want
to
perform
an
ICMP
base
attack,
you
don't
really
need
to
spoof
the
source
address
of
the
error
messages,
because
you
know
they
know
that
is
receiving.
The
error.
Message
doesn't
really
know
from
which
router
that
that
error
is
coming.
L
L
L
If
this
node
here
tried
to
do
that,
we
could
say
that
he
could
easily
dis
note
could
easily
use,
for
example,
it
sounds,
or
service
I
mean
it
doesn't
need
to
spoof
its
own
salaries
are
all
it
can
pretend
to
be
a
Rueter
there
was
you
know
in
the
path
of
these
packets?
The
destination
address
of
the
error
message
would
be
that
obviously,
the
target
of
the
attack
in
this
case
would
be
this
node.
Okay.
L
So
obviously
this
error
message
has
to
pretend
that
it
was
elicited
by
a
packet
sent
from
this
node
to
this
order
sent
to
this
other
node.
So
that's
why
the
source
address
here
is
the
address
of
this
node
and
the
destination
address.
Is
the
IP
address
of
this
other
node?
Now,
if
you
look
here,
okay,
this
node
can
tell
that
you
know
based
on
the
destination
address,
this
bucket
couldn't
possibly
be
generated.
L
So
the
idea
here
is
that
we
don't
look
at
the
source
or
destination
addresses
of
the
outer
pockets,
because
they
don't
need
to
be
spoofed
at
all,
but
actually
look
at
the
address
that
is
here
in
this
error
message.
Okay,
obviously,
this
network
couldn't
possibly
have
we
seen
this
because
it's
meant
for
a
completely
different
network.
Ok,
again,
we
are
assuming
that
there
is
no
multihoming
here
and
it
was
clear
you
know
in
the
first
slide,
you
don't
deploy
this
in
scenarios
in
which
you
have
multihoming.
L
So
what
is
the
rule
like
or
if
the
destination
address
that
is
embedded
in
the
ICMP
message
belongs
to
your
own
network?
You
let
the
packet
go
through.
If
it
doesn't,
you
just
drop
the
packet,
it's
that
simple
and
what
they
pay
the
kind
of
attacks
that
no
these
filtering
can
prevent.
It's
essentially
any
attacks
that
are
based
on
spoof
IC,
icmp
error
messages.
L
There
have
been
attacked,
like
you
know,
the
traditional
nuke
attacks,
where
you
spoof
an
ICMP
error
and
that
triggers
the
abortion
or
termination
of
a
tcp
connection,
but
other
possible
attacks
are,
for
example,
those
in
which
you
spoof
and
fragmentation
needed
by
DF
bit
set
or
an
ICMP
packet
to
big
message
that,
depending
on
you
know
whether
whether
that's
six
or
before
I
can,
you
know,
led
to
a
reduction
in
the
MTU
that
is
being
used
for
the
connection
or
even
you
know,
in
the
case
of
ipv6,
those
error
messages
could
be
employed
to
trigger
fragmentation.
I
I
L
So
this
other
document
is
about
the
role
of
firewalls
in
network
security,
as
a
kind
of
you
know
background
on
this
particular
document.
This
version
of
the
document
is
is
based
on
a
document
that
had
been
published,
or
you
know,
aimed
at
the
ops
area
working
group
a
few
years
ago.
It
had
actually
been
adopted
at
the
time.
I
have
liked
it
that
document
and
after
a
while
I
contacted
the
outdoors
regarding
what
was
the
status
of
that
document,
and
it
resulted
that
I
mean
it
was
the
case
that
this
document
had
been
dropped.
L
Apparently,
as
far
as
I
know,
because
there
were
two
others
and
they
didn't
share
the
same
view
on
the
contents.
So
I
asked
them
if
they
would
be
willing
to.
You
know
just
to
revive
the
document
and
they
say
the
urine,
but
if
I
wanted
to
do
it,
I
could
so
I.
Did
we
presented
this
document?
I,
don't
recall
if,
once
or
a
couple
of
times
in
the
ops
area
working
group,
the
reason
for
which
we
did
it.
L
L
What
are
the
goals
of
this
document,
and
this
is
actually
you
know
one
of
the
you
know
things
that
we
change
it
from
previous
versions,
even
if
it's
the
so,
if
it's
the
first
time
that
you
get
to
hear
about
this
document
last
time
that
we
presented
this
some
folks
ask
a
well.
What
specifically,
are
you
trying
to
achieve
with
this
document?
L
So
first
item
is
to
recognize
the
role
of
firewalls
and
internet
architecture,
and
this
is
essentially
saying
that
quite
a
few
times
firewalls
are
fly,
that's
something
that
is
evil,
so
these
document
is
trying
to
do
actually
the
contrary,
saying
that
they
are,
you
know,
part
of
the
architecture.
It
also
tries
to
analyze
a
common
kinds
of
files
and
claims
associated
with
them.
L
Assumptions
may
around
firewalls
analyze
straight
off
in
different
para.
Didn't
we
try
to
provide
some
conceptual
guidance
when
it
comes
to
the
use
and
deployment
of
firewalls
identify
harmful
behavior
that
is
at
times
you
know,
implemented
in
files
such
as
you
know
stuff
that
they
do,
that
they
that
prevents
deployment
of
of
protocols
and
so
on
and
possibly
trigger
other
working
in
this
area.
So
I
will
try
to
briefly.
You
know,
go
through
the
stuff
that
is
covered
in
this
document.
L
So
things
like
you
know
whether
the
device
or
software
resides
in
a
house
or
in
the
network
whether
it's
implemented,
you
know
in
special-purpose
hardware
and
so
on
the
specific
layer
which
the
device
operate.
We
think
that
it's,
like
you
know
it's
a
detail,
an
implementation
detail,
obviously
again
that
you
know
results
in
implications
regarding
what
kind
of
policies
you
can
you
know
enforce,
but
we
are
meaning
with
this.
L
Is
that
we
are
not
focusing
on
any
kind
of
you
know
specific
layer
firewall,
but
you
know
on
firewall
such
a
general
concept,
the
role
of
firewalls
in
network
security.
Essentially,
what
we
say
is
that
they
provide
prophylactic
perimeter
security
and
essentially
means
that
it's
not
a
replacement
for
you,
no
more
powerful
security
measures,
but
it's
like
a
first
line
of
defense,
the
analogy
that
is
in
the
in
this
document,
which
was
actually
in
Fred
Baker's.
L
Another
topic
that
these
document
covers
is
the
relationship
between
the
firewalls
and
the
end-to-end
principle,
and
one
of
the
usual
comments
that
you
know
you
hear
when
talking
about
firewalls
is
that
essentially
they
are
evil
because
they
break
the
end-to-end
principle
and
what
these
document
arts
is
that
that's
not
really
the
case,
and
essentially
the
end-to-end
principle
argues
in
favor
of
in
all
simplicity,
inconsistent,
you
know
behavior,
but
it
doesn't
really
mean
that,
for
example,
you
it
doesn't
really
argue
against
things
such
as
firewalling,
like
you
know,
enforcing
consistent,
for
example,
policies
for,
for
example,
security
reasons,
couple
kinds
of
firewalls.
L
We
briefly
describe
three
different
types
like
context
or
song
based
firewalls,
a
purposive
broken
base
measures
and
IPAs
IPS
systems.
We
provided,
we
categorize
firewalls
into
the
these
three
different
kind
time
and
provide
a
brief
discussion
of
those.
We
briefly,
you
know
cover
the
you
know,
two
main
firewall
strategies,
the
fall
deny
and
default
alone,
and
the
implications
of
that.
L
We
also
discuss
assumption
assumptions
in
general
that
are
usually
made
in
files
and
some
of
these
assumptions
change.
For
example,
when
you
move
from
before
to
be
6.
For
example,
in
the
case
of
5p,
before
generally,
the
IP
addresses
and
the
ports
are
assumed
to
be
stable
in
the
case
of
five
BB
6.
This
is
not
really
the
case
when
you
have
temporary
addresses
the
the
assumption
of
a
IP
address
is
being
stable,
is
not
longer
the
case,
and
we
also
discussed
or
mentioned
the
fact
that
you
know
in
general.
L
You
know
many
firewalls
assume
that
the
service
board
identifies
the
protocol.
That
is
actually
you
know,
employing
that
port
number,
and
essentially
we
say
that
that
is
not
actually
the
case.
Obviously
that's
not
use,
but
what
we
say
here
is
that,
for
example,
they
saying
I
mean
the
assumption
that
a
given
port
number
identifies
the
service
is
not
really
the
case
and
probably,
if
you
really
mean
to
block
a
specific
lesabre
call
a
service.
Well,
you
have
to
make
sure
that
you
identify.
L
We
also
have
some
text
on
areas
where
firewalls
could
do
better.
This
is
not
meant
to
be
complete,
but
we
mentioned,
for
example,
the
case
where
firewall
is
firewalls
tries
to
enforce
protocol
syntax,
and
there
are.
There
are
obviously
many
examples
of
this,
for
example
where,
if
I
will,
let's
say,
if
you
have
tcp
at
the
time
they
were
there
were
you
know,
firewalls
that
were
checking
whether
the
ecn
bits
were
set
to
zero
and
obviously
when
we
try
to
deploy
ACN
that
change
it,
and
at
the
time
you
know.
L
Obviously
there
was
a
problem
for
easy
and
deployment.
It's
not
just
for
easy
end.
The
NSA
and
other
protocols
suffer
from
the
same
thing.
So
here
we
discuss
the
topic
you
know,
but
at
the
general
level,
but
we
might,
you
know
end
up.
You
know
either
either.
You
know
including
more
specific
discussion
in
this
document
or
not
possibly
doing
separate
document
or
separate
documents
with
specific
issues
that
are,
you
know,
affecting
concrete
particles.
L
So
I
don't
know
if
there
are
any
comments,
so
the
last
time
that
we
left
this
in
the
obsidia
working
group,
let's
say
the
remaining
eaten
or
what
way
or
what
we
were
required
at
the
time
was
to
you
know,
try
to
clearly
specify
the
goals
of
of
the
document,
and
we,
you
know,
took
that
advice
apply
that
to
this
version,
and
this
is
what
we
came
up
with
so
I,
don't
know
if
there
are
any
comments.
If
people
have
read
this,
if
they
think
it's
worth
working
group
adoption.
J
Oh
yay
glee
I
mean
over
time
it's
generated
a
fair
amount
of
controversy,
just
not
in
this
group
because
weirdly
enough
I
think
most
people
here
like
understand
what
firewalls
and
for
so
I,
think
it's
actually
a
bit
of
a
challenge
to
edit
over
the
hump,
as
it
work
like
to
say,
adoption
or
working
group.
Last
call,
but
that's
just
my
opinion,.
E
Yeah
I
think
actually,
even
before
you
know
going
to
you
know
like
asking
for
adoption,
I
think
I
would
prefer
to
see
like
some
discussion
on
the
email
list
itself,
so
I
would
really
encourage
people.
You
know
to
sort
of
like
read
the
document
and
provide
feedback.
So
we
have
an
understanding
of
you
know
how
this
document
can
make.
You
know,
networks,
you
know
more
secure
and
improve.
You
know
the
security
building
networks
and.
L
L
For
some
reason
we
just
forgot
about
the
document
and
a
number
of
people,
yeah
prolly
and
the
number
of
people
actually
asked
it
as
well.
What
about
the
document?
Are
you
going
to
revise
it
or
what
are
you
going
to
do
with
it?
L
So
essentially,
what
we
did
we
revised
it
I,
don't
to
be
honest,
I,
don't
really
know
in
this.
If
weather
in
this
last
Rev,
we
actually
applied
any
changes
or
we
just
you
know,
bring
it
up,
you
know
to
for
it
not
to
be
expired,
and
so
that
you
know
we
could
discuss
it.
So,
for
the
most
part,
these
presentation
is,
you
know,
just
to
describe
what
we
are
currently
doing.
It's
an
extremely
drafty
version
of
the
document.
L
L
L
So
it's
not
an
issue
of
the
case
that
you
know
when
someone
wants
to
know
get
a
v6
firewall.
They
have
to
resort
to
producing
their
own
RFP
from
from
scratch.
Actually,
this
document
is
exactly
based
on
that
on
an
RS,
a
RFP
that
was,
you
know,
produced
by
guys
that
were
trying
to
buy,
be
65
walls,
but
didn't
have
anything
actually
to
you
know
to
show
benders
regarding
what
they
wanted
in
terms
of
firewalls.
L
L
L
For
each
of
those
areas
where
you
know
this
document
has
a
set
of
requirements,
it
tries
to
specify
whether
that
you
know
that
requirement.
That
requirement
is
mandatory,
recommended
or
optional.
You
know
whether
that
has
to
be
there
whether
you
know
that
is
desired,
but
not
required,
or
whether
that's
optional
in
and
it's
up
to.
You
know
where
you
know,
whoever
is
producing
that
firewall.
The
goal
is
obviously
to
have
you
know
something
like
to
refer
to
when
it
comes
to
what
we
mean
by
a
basic
firewall,
so
feedback
that
we
have
received
so
far.
L
So
essentially,
what
we
did
as
I
mentioned
was
to
you
know,
essentially
grab
that
original
RFP
that
have
been
produced
by
Marco.
We
change
of
tough
remove
some
stuff,
and
we
came
up
with
this
document
based
on
that
and
the
feedback
that
we
got
so
far.
Is
that,
for
example,
that
we
should
separate
between
state,
full
and
stateless
firewalls,
not
sure
if
you
know
false
were
meaning
to
do
that
within
the
same
document
or
whether
they
were
meaning
that
they
should
actually
be
separate
documents.
L
All
the
feedback
that
we
received
is
that
when
it
comes
to
anything
that
is
low-level
details
on
what
to
do
with
TCP
UDP
and
you
da
and
ipv6
should
be
in
separate
documents.
So
this
you
could
think
of
this
for
the
most
part
as
something
that
is
you
know
talking
about,
whereas
in
the
case
of
you
know
the
TCP
UDP
and
IP
6
low-level
stuff,
there
could
be
a
document
that
you
know
describes.
L
You
know
how
to
implement
those
things
or
clearly
specify
how
what
we
are
referring
with
those
requirements
without
getting
into
such
a
broad
discussion
of
features
such
as
the
ones
that
are
describing
this
document
other
thing,
but
was
a
lot
more
consistent,
a
consistent
use
of
defined
terminology
and
what
else?
And
then
the
I
think.
The
last
item
which
we
received
feedback,
is
that
it
was
okay
to
actually
say
what
kind
of
data
should
be
offered
to
the
user.
L
C
H
10
China
say:
I
had
a
quick
glance
through
it.
There
haven't,
read
it
in
detail,
it
seems
to
have
some
useful
information
in
it.
I
know
to
you,
don't
make
any
reference
to
write
554,
that's
a
document
that
does
discuss
requirements
or
so
I
enumerate
list
requirements
for
network
security
devices
amongst
all
sorts
of
other
enterprise,
ipv6
devices,
switches,
Reuters,
blah
blah
blah,
and
it
does
that
for
a
sort
of
standard
file
for
an
IPS
and
for
an
application,
firewall
three
different
categories,
so
you
might
want
to
look
at
that.
I
think
right.
H
554
in
itself
is
not
something
you
can
take
and
cut
and
paste
a
tender
fear.
Obviously
I.
Don't
think
this
is
so
I
think.
The
most
useful
thing
for
this
is
for
people
that
want
to
know
that
the
firewall
getting
has
got
the
v6
functionality.
They
need
not
necessarily
how
to
configure
it,
but
to
make
sure
it's
got
the
functionality
so
I
think
that
should
be
the
focus
of
it
right.
554
us
in
the
network
device
section
include
in
that
section
the
v6
requirements
as
well
for
the
firewall
device.
H
I
Morden
area
would
love
to
get
the
feeling
of
the
working
group
regarding
whether
document
regarding
with
requirements
belongs
to
OPSEC
or
even
the
atf,
rather
compared
to
write
any
comments
on
this.
What
I
mean
your
document
among
Vikraman
belongs
to
obscurity
for
sure
operation.
I
got
my
reservation
somehow
there,
but
what
is
the
feeling
of
the.
H
Side
I
think
if
say,
young
Souls
was
here
he'd,
be
saying
it
should
be
a
peacock
or
he
might
say,
take
it
to
the
right
community
and
improved
554.
Since
554
is
in
itself
an
update
to
a
previous
version.
I,
don't
know
whether
the
other
regional
registry
communities
have
done
similar
things,
but
I
think
right.
Pi
phi
4
is
referred
to
in
an
awful
lot
of
places
as
good
practice
for
enterprise,
v6
equipment
and
the
functionality
you
need.
I
Just
will
be
clearly
tamara's
playing
attendees
now,
regarding
the
section
of
everything.
Thank
you
so
much
regarding
the
requirements
section
there
is
one
I
would
really
really
love
to
be
removed
as
the
one
about
denial
of
service
I
do
not
want
a
door
that
90f
document
claims
that
a
firewall
can
protect
against
a
denial
of
service.
I
would
really
love
you
to
remove
this
section
completely
and
I
understand
what
you
want.
It
is
more
blocking
ping
of
death
or
this
kind
of
stuff,
but
don't
call
it
those
rename
this
section.
I
L
I
Consistent
right
in
the
title
and
the
requirement
that
and
then
I
think
the
VPN
and
the
search
sections
with
a
lot
of
masks,
and
it
looks
for
me
like
a
list
of
features
into
a
commercial
data
sheet
like
a
list
of
feature
from
a
commercial
firewall.
So
it
should
not
be
masked
when
you
say
it
must
present
this.
It
must
it's
I
would
say
first
nice
to
have,
but
it
looks
pretty
much
like
non
technical
requirement.
Oh
that
very
subjective
requirement.
L
I
would
say
that
and
that's
you
know,
part
of
the
feedback
that
we
were
after
is
that
what
we
have
in
the
current
version
of
this
document?
It's
like
a
mix
of
many
things
because
on
one
hand
you
have
stuff
that
is
like
low
level,
technical
detail
and,
as
you
say,
there's
other
stuff.
That
is
just
talking
mostly
about
products
rather
than
you
know.
You
know
like
low-level
details,
so
that's
something
on
which
we
were.
Actually
you
know
asking
for
for
feedback.
Okay,.
E
I
I
I
H
And
tension
I
guess
I'll
bite.
So
there
was
a
discussion
in
v6
ops
about
what
the
ITF
shouldn't
should
not
do
in
terms
of
specifying
filtering
I.
Just
wonder
what
you,
as
chairs
SAT
there
think
about
what
we
should
and
shouldn't
do
and
if
you're
at
v6
Ott's
what
you
think
about
what
the
chairs
or
the
what
was
said
there
I.
I
Mean
it's
typically
operational
issue
featuring
okay,
as
you
know
my
point
of
view
on
on
this
document.
If
we,
the
ITF,
wants
to
specify
the
list
of
extension
headers
that
in
2016
with
the
specific
option
is
this
visited,
subtype
must
be
blocked,
I'm
all
for
it.
The
only
issue
is
that
most
of
you
will
be
adding
more
and
more
options
in
extension,
headers.
H
Yeah,
I
think
one
of
the
things
we
can
do.
Maybe
it
was
a
result.
What
came
out
of
basic
salts
is
people
tend
to
be
cautious
and
default
block
stuff,
just
natural
behavior,
I
suppose
and
in
my
context,
talking
to
universities,
wedding
campus
networks,
that's
what
they
tend
to
do
and
so
I
think
we
could
maybe
spin
that
to
be
more
positive
about
these
are
the
things
you
should
definitely
be
strongly
recommend
you
allow
through
and
the
reasons
for
it
and
be
that's
more
positive
about
it,
and
the
implied
thing
is
well.
H
J
Yeah,
surely
a
glee
I'm,
not
I,
can
I
think
add
a
little
to
that,
because
I
think
there's
something
that
I
want
to
amplify,
which
is
that,
like
there's
a
bit
of
a
dramatic
tension
between
what
operators
find
necessary
and
what
what
people
say,
we
should
or
should
not
do
and
I
personally,
like
the
idea
that
the
community
would
be
able
to
document
what
people
do
without
necessarily
saying
that
you
should
do
those
things
right,
because
that
actually
I
think
informs
protocol
designers
and
a
protocol
evolution
a
little
bit
without
actually
making
the
things
that
I
do,
that
I
find
necessary
normative
for
other
people
right
and
so
I
think
that's
where
some
of
the
useful
discussion
around
what
is
observed,
behavior
without
necessarily
making
value
judgments,
is
actually
pretty
useful,
but
I
think
we
can
also
be
stronger
than
that
because
we
can
actually
they
characterize
why
people
do
the
things
that
are
observed,
which
actually
does
have
a
value
judgment,
but
it's
and
it
should
inform
other
processes
at
10
shine
again.
H
With
that
completely
I
think
the
interesting
thing
in
the
case
of
the
extension
heard
of
stuff
in
peace,
it
sorts
is,
there's
measurements
you
can
take
of
the
effect
of
what's
happening,
but
it's
a
little
bit
harder
when
you
try
to
tease
out
what
the
causes
are.
So
Fernando
has
been
informally
speaking
to
some
operators
and
produces
a
drop
based
on
that,
but
that
isn't
representative
what
everyone
does,
of
course,
so
it's
going
to
naturally
be
that's
controversial
or
create
discussion.
H
So
I
think
it's
just
about
getting
the
right
mindset
when
we're
writing
the
documents
to
think.
What's
the
most
productive
way
of
mocha
Pro
is
productive
perspective
to
produce
the
document
broth.
So
I
think
what
joel
just
said
is
is
something
we
should
bear
in
mind.
I
don't
know
whether
fernando
agrees
with
that,
but
it
would
be
nice
to
progress.
The
type
of
things
are
doing
we're
trying
to
do
in
v6
ops
and
get
it
through,
and
do
it
the
right
way
and
have
the
most
positive
impact.
By
doing
it.
L
Haven't
I
agree
with
of
you.
I
would
say
that
in
any
case
in
basic
shops,
even
when
you
know
trying
to
do
stuff
with
that
mindset,
we
have
a
hard
time
just
to
name
a
specific
item.
We
were
presented
on
discussing
a
document
on
the
filtering
of
packets
with
extension,
headers,
noting
that
we
were
just
describing.
L
You
know
something
that
operators
were
doing
without
actually
saying
that
we
were,
you
know,
recommending
that
to
happen,
and
that
was
still
controversial,
so
I
probably
say
that
it's
probably
easier
or
less
controversial
to
just
you
know
describe
what
is
being
done,
but
at
times
that's
not
even
enough
at
times.
Apparently
the
you
know
the
take
is
that
we
don't
like
that.
Even
if
that's
happening.
J
Yeah
just
to
make
an
observation
on
that
Julian
extension
headers
in
the
real
world.
That
document
actually
was
kind
of
an
interesting
phenomenon
because
it
actually
doesn't
it
is.
It
takes
a
value,
neutral
position
with
respect
to
the
observed
behavior,
so
it
passed
relatively
smoothly
through
the
community,
even
making
those
observations,
but
the
iesg
doesn't
like
it.
That
word
didn't
like
it
that
much
because
it
doesn't
take
a
position
so
I
mean,
like
that's
a
there's
a
bit
of
a
this,
a
bit
of
a
conflict.
There
I'll
be
it.
J
You
know,
I'm,
three
abstentions
or
just
abstentions
and
not
discusses.
So
I
take
I
take
all
the
winds
that
I
can
get
and
you
know,
I
I
do
I
think
respect
the
idea
that
any
consensus
that
we
do
produce
around
this
is
going
to
be
pretty
rough,
and
that's
part
of
the
reason
that
I
like
encourage
the
observable
results
or
the
phenomenon
or
the
recommendations
that
we
produce
to
not
like
look
like
they're
strongly
normative
statements,
because,
as
with
other
firewall.