►
From YouTube: IETF114 OPSEC 20220726 1730
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
A
If
you
join
in
from
laptop
keep
your
audio
and
video
off
and
don't
forget
to
leave
the
queue
when
done
what
yeah
and
speakers
for
those
who
are
inside
I'll
control,
the
slides
we
need
meeting
minutes
take
care
any
volunteers.
A
Thank
you
very
much,
really
appreciate
it.
Okay,
so
we
have
three
presentations
today.
A
First
is
working
group
item
indicators
of
compromise
and
we
have
two
drafts
which
are
individual
ones
since
we
met
last
time
about
a
year
ago,
we
we
finally
published
operational
security
considerations
for
ipv6,
but
it
was
10
years
12,
okay,
is
it
a
record?
I
don't
know
close
okay
close
so
and
it
got
nice
number
9099
and
we
have
another
old
draft
in
the
rfc
editors
queue
about
the
filtering
of
ipv6
packet
with
extension
headers.
A
B
Thank
you
hi
everyone,
so
I'm
here
to
present
draft
on
its
case
of
compromise
they're
on
attack
defense,
it's
on
behalf
of
myself
and
the
other
authors,
kirsty,
olly
and
james.
So
next
slide,
please
so
yeah
just
to
quickly
run
through
the
history
of
how
we
got
here.
So
this
originally
came
to
set
dispatch
at
itf.
107
brought
it
to
whatsec,
following
that,
following
the
recommended
dispatch
made
some
updates.
B
B
So
there
has
been
a
further
review,
but
I
don't
think
there
was
anything
in
there
that
significantly
changed
the
document.
With
some
helpful
points
and
yeah,
I
published
the
latest
version
earlier
this
month,
which
is,
I
think,
the
sixth
version
in
total.
B
So
it's
had
a
fair
few
rounds
of
feedback
and
review
and
change
now
next
slide,
please
so
yeah
as
a
quick
reminder
of
what
the
motivation
was
for
the
document.
B
So
I
just
wanted
to
document
what
is
an
operational
security
technique,
that's
sort
of
out
in
the
wild
and
widely
used
and
sort
of
just
record
the
best
practice.
So
I
don't
think
that's
actually
documented
anywhere.
Really.
We
also
wanted
to
try
and
share
it
with
the
itf.
I
think
it's
not
a
topic
that
necessarily
got
broad
familiarity
across
the
whole
of
the
itf,
so
we
thought
it'd
be
a
useful
thing
to
do.
B
We
also
wanted
to
just
try
and
address
that
it's
sometimes
overlooked
in
protocol
design.
So
a
lot
of
protocols
will
make
decisions
that,
like
basically
make
these
iocs,
which
I'll
cover
the
definition
again
later
just
make
them
harder
to
use.
So
we
just
wanted
to
make
people
aware.
So
if
a
protocol
is
coming
out,
that's
going
to
make
them
harder
to
use
that
people
know
they're
doing
that
and
know
what
the
trade-off
is
there.
B
And.
Lastly,
I
just
wanted
to
bring
some
cyber
defense
expertise
into
the
itf,
so
we
all
the
authors
work
in
cyber
security
so
want
to
try
and
bring
max.
I
think
there's
not
too
many
cyber
security
professionals
across
the
itf,
possibly
the
exception
of
this
room,
but
it
wants
to
sort
of
bring
that
in
and
thought
this
would
be
a
good
way
to
do
it
next
slide.
Please
yeah!
This
is
the
abstract,
I'm
not
going
to
read
it.
B
You
can
all
read
it
separately,
read
the
draft
if
you
haven't
already
but
sort
of
roughly
just
cover
what
indicator
compromise
are
some
ways
you
can
use
them
some
ways
they
have
been
used
and
roughly
what
their
benefits
are
and
what
their
limitations
are
and,
as
I
said,
some
best
practice
next
slide,
please
yep,
so
just
just
to
recover
what
iocs
are
for
those
haven't.
Read
the
draft
so
they're,
basically
artifacts
that
you
can
use
to
sort
of
identify
an
attacker
who's
attacking
your
network,
your
your
computer.
B
So
these
include
things
like
their
tactics
like
how
they
act
and
the
techniques
they
use
the
tools
they
might
use
or
just
like
sort
of
ip
addresses
that
they
come
from
and
domain
names
associated
with
the
attack.
So
some
more
examples
there,
including
sort
of
hashes
of
malicious
executables,
that
they're
using
and
yeah
more
more
of
the
tools
as
we
cover
in
the
draft,
like
the
range
of
iocs
that
exist,
have
different
sort
of
benefits
and
difficulties.
B
So
sort
of
dying
like
finding
a
domain
name
associated
with
an
attack
is
quite
easy,
but
it's
also
relatively
easy
for
an
attacker
to
change
if
you
start
blocking
it.
But
if
you
put
the
effort
in
to
diagnose
exactly
how
they
run
their
attacks
and
what
tools
they're
using
that's
much
more
fundamental
to
their
mo
so
much
harder
than
to
change,
but
iocs
run
that
whole
gamut
next
slide.
Please
yep!
So
a
quick
outline
of
the
draft.
So
we
cover
what
the
fundamentals
of
iocs
are,
so
what
they
are.
B
So
everyone
can
defend
themselves
and
through
to
like
retiring
it,
when
it's
no
longer
useful
as
attackers
move
on,
we
cover
how
to
use
them
effectively
what
some
of
the
benefits
are
of
using
them
and
a
couple
of
case
studies
where,
in
order
to
prevent
sort
of
widespread
attacks,
iocs
have
been
sort
of
collected
and
shared
and
been
put
to
good
use
to
prevent
attack
spreading
and
then
some
of
the
limitations
like
they're,
a
relatively
lightweight
way
of
defending
your
network.
B
So
that
comes
with
some
trade-offs
and
yeah
thinking
about
the
different
types
of
precision
you
get
with
different
iocs
and
the
time
and
effort
it
takes
to
diagnose
and
use
a
given
ioc
and
then,
lastly,
a
brief
bit
on
best
practice,
including
sort
of
how
you
should
share
them
amongst
defenders
next
slide,
please
yeah.
So
this
is
a
very
quick
presentation,
just
sort
of
remind
everyone
about
the
document.
So
we'd
love
further
reviews
and
comments.
B
I
said
you
know
had
one
from
kathleen,
which
will
will
look
to
work
into
a
future
version,
but
any
more
comments
and
reviews
really
welcomed,
and
I
suppose,
given
we
haven't,
had
any
major
like
comments
or
problems
coming
up
on
the
mailing
list
or
from
any
other
quarter
for
a
while.
We
want
to
know
like
do.
We
think
this
is
ready
for
working
group
last
call,
so
we
think
it's
pretty
stable.
We
think
it's
in
quite
good
shape,
so
yeah
that
that's
it
quite
quick
presentation.
Any
questions.
A
A
A
Oh
sorry,
I'm
trying
to
do
something
with
that.
Quite
I
think
click
on
the
wrong
one.
So
I
would
like
to
get
a
volunteers
to
review
it
during
the
last
call
any
volunteers
to
do
this.
A
Okay,
we
can
ask
on
the
list,
but
I
really
really
really
think
we
need
to
get
some
like
review
during
the
last
call
and
not
just
take
a
silence
as
a
indicator
of
yeah
the
draft
the
indicator
of
the
draft
should
be
progressed
but
yeah.
I
will
start
the
last
call
on
the
list
after
like
next
week.
Probably
sometime
so
I
can.
I
see
some
comments
on
the
chat.
Sorry,
yeah,
okay,
cool!
Thank
you
very
much.
Thank
you.
B
A
Oh,
we
lost
our
presenters.
Okay,
I
see.
C
Is
surprising,
I
don't
need
any
yeah,
I
will
present
it
up.
A
Okay,
so
would
you
like
me
to
present
this?
Oh
here
it
is
you
like
to
present.
A
D
Awesome
all
right,
so
I'm
igor
lubachev
and
I'm
gonna
talk
to
you
a
little
bit
about
our
take
on
source,
address
validation,
and
especially
this
is
the
work
we're
bringing
here
because
it's
based
it's
basing
on
updating
the
the
the
work
that's
actually
been
published
two
years
ago
by
this
group.
E
D
D
So
how
do
we
stop
address?
Proofing
unauthorized
packets
go
being
sent
into
the
network
since
2004
effectively?
The
only
technique
that's
been
used
is
look
at
the
bgp
update
messages,
try
to
infer
look
at
your
fib
or
rib
and
try
to
insert
something
that
information
what's
been
what's
valid,
feasible
path
is
was
the
best
thing
which
was
not
saying
too
much,
because
it
was
proven
quite
useless
in
practice.
It
assumed
absolutely
no
route
filtering
so
effectively,
very
little
traffic
engineering.
D
Well,
that's
not
real
world,
so
that's
in
2020
8704
was
published,
which
was
effectively
an
update
on
feasible
path,
which
said:
let's
look
at
those
bgp
update
messages
a
little
bit
closer
and
make
a
little
bit
more
inferences
and
look
at
the
origin
as
number
and
therefore
allow
paths
not
just
what
you've
seen
on
this
interface
in
reverse,
but
also
the
paths
that
are
advertised
by
the
same
origin.
As
than
any
of
the
paths
that
you've
seen
in
this
interface,
which
is
better
still
has
a
number
of
issues.
D
We'll
see
them
we'll
look
at
them
later
so,
but
it's
better.
It
also
has
a
little
small
paragraph
saying
that,
oh
by
the
way,
you
can
also
look
at
raw
information,
but
it's
kind
of
an
afterthought.
It
doesn't
have
any
details,
but
it's
an
interesting
idea
and
this
atf
we
have
actually
a
working
group.
I
mean
this
problem
is
still
not
solved.
Seventh,
so
more
people
look
into
it
next.
D
Okay,
good
very
simple
example:
to
show
where
8704
still
doesn't
work,
I
mean
you
have
an
as1
which
has
a
provider.
S2
s2
is
multi-homed.
D
It
sends
both
both
ways,
its
customer
routes,
but
for
whatever
reasons
reasons,
it
only
wants
to
send
its
own
path
to
a3
and
now,
looking
at.
If
as4
is
trying
to
do
some
sort
of
address
validation
using
8704,
it
will
only
see
path
announced
prefixes,
that's
where
s1
is.
The
original
asset
will
not
see
a
s2,
it's
an
origin,
as
it
will
not
consider
its
routes,
even
though
it
learns
that
there
is
a
route
from
from
the
pier
okay,
so
22
years
in.
D
D
So,
and
one
of
those
ideas
is
that
well,
not
one
of
the
ideas
says
hey.
We
have
another
sort
of
information
that
was
also
not
designed
for
it,
but
things
like
raw
and
aspar,
and
actually
it
was
recently
suggested-
maybe
also
signed
iar
data.
D
How
about
will
also
mine
that
for
source
of
use,
useful
information
next
and
just
quickly?
One
more
example:
that's
important
that
we
need
to
solve.
I
mean
this
problem
is
kind
of
familiar
to
me
because
it's
about
some
product
that
I
was
involved
in,
I
immediately
apologized
for
this
slide.
It
took
us
from
internal
presentation.
It
has
a
lot
more
graphics
than
they
usually
used
to
at
atf,
but
effectively
it's
a
cdn
implementation.
Where
you
have
any
cast
ap
that
cdn
wants
to
serve
content
on
the
anycast
home
pop.
D
I
would
call
it
that
way
receive
the
request,
decides
that
actually
you
want
to
send
a
service
from
another
pub.
That's
for
whatever
reason:
that's,
where
content
is
it's
closer
to
the
user
tunnels,
all
the
packets
on
that
connection
to
the
edge
and
the
edge
returns,
the
bulk
of
the
media
directly,
so
the
only
thing
tunneled
is
headers
and
x.
D
D
Does
a
request
can
open
the
connection
to
an
address
in
in
prefix
3,
which
lands
in
the
home
pub
home
pub
forwarded
through
tunneling
to
some
edge
pop
in
prefix
2,
and
that
h-pop
is
supposed
to
return
back,
but
it's
suppose,
but
it
has
to
source
the
packets
from
prefix
three,
so
that
the
connection
is
complete
on
the
client
side
on
the
user
side,
so
prefix
3
is
only
announced
from
autonomous
system
1,
but
that's
the
home.
The
has
2
does
not
announce
it.
It
doesn't
want
to
announce
it.
D
It
doesn't
want
any
direct
traffic
for
the
prefix
and
the
question
is:
will
as9,
which
is
its
provider?
If
it
does
source
address
validation
actually
permit
dsr
is
a
pretty
pretty
useful
use
case.
I
mean
it's
obviously
cdn,
but
so
with
mobile
roaming
and
some
gaming,
and
it
could
be
security
products
that
they're
using
it
and
so
forth.
Okay,
next
and
just
some
stats
for
fun
in
2015,
we
measured
at
several
thousand
of
akamai
pubs
around
the
world.
D
How
many
of
them
were
doing
some
sort
of
effective,
save
source
address
validation
and
we
found
about
15
and
just
before,
coming
to
this
meeting,
I
pulled
some
stats
and
2022
it's
about
15
percent,
so
what's
happening
there,
economics
have
been
suggested
as
a
possibility,
but
actually
for
small
networks.
D
It
is
in
the
interest
not
to
allow
floods
of
spoof
packets
through
the
network.
So
it's
not
the
full
answer.
It's
possibly
that
it's
just
the
techniques
we
have
are
ineffective
and
they
break
too
many
things
and
talking
to
operators.
Reducing
support
calls
is
one
of
the
big
incentives
in
deploying
or
not
deploying
things.
D
Okay.
Next,
so
here
is
our
proposal.
We
call
it
bar
cell,
which
is
effectively
using
information
from
bgp,
obviously,
but
also
augmenting
it
with
aspen
raw
and
it's
first
and
for
first
of
all,
is
just
an
improvement
on
8704
that
upsex
published
two
years
ago.
It's
effectively
using
existing
data
in
bgp
update
messages.
Better
8704
was
just
looking
at
the
originals
number,
as
a
signal
bar
save
is
looking
at
every
single
layers
number
in
the
as
pass
as
a
signal.
We
can
look
at
it
later.
D
A
bit
how
it's
doing
it
and
it's
augmenting
that
information
with
info
in
aspen,
raw
and
one
one
very
important
thing
is
deployability
is
key.
Deployability
is
super
important,
and
this
algorithm
requires
no
change
in
the
wire
in
any
of
the
protocols.
D
So
the
very
first
network
that
adopts
it
will
actually
reap
immediate
benefits,
and
that's
that's
important.
Next
all
right.
This
is
a
slightly
busy
slide
with
a
lot
of
circles,
but
its
only
purpose
is
to
say
that
the
algorithm
works
equally
exactly
the
same
thing,
both
on
customer
interfaces
and
peer
interfaces
to
do
to
come
to
build
a
save
list.
D
D
So
that's
a
basically
there's
a
customer
relationship
and
then
you
also
look
at
s
path
of
all
bgp
messages,
no
matter
where
they
received
no
matter
what
interface
it
could
be,
your
peer-to-peer
interface,
it
could
be
your
from
coming
from
transit,
doesn't
matter,
and
you
see
what
asp
look
at
all
the
asps
and
see.
What
is
the
previous
s
number
to
this?
D
When
you
have
a
customer
call,
you
look
at
raw
information
and
find
all
the
raw
entries
that
leads
the
customer,
and
you
look
at
all
the
bgp
entries,
bgp,
update
messages
and
just
like
87.04
find
where
this,
where
an
as
number
in
your
customer
column,
is
the
original
number
and
you
add
those
prefixes
to
your
save
list
and
you
merge
everything
together
and
that's
your
save
list
for
the
interface
next.
D
All
right.
Next
super
busy
slide,
don't
read
it,
but
just
the
point
is
that
it
has
a
lot
of
complex.
It
has
a
lot
of
different
cases.
It
has,
as
it's
got
route
filtering
in
it.
It
has
prefixes
that
are
published
in
raw
prefixes
that
are
not.
This
has
autonomous
systems
that
are
that
have
aspar
the
skeleton
system
that
don't
have
aspar.
D
D
So
first
you
discover
the
customer
code.
You
start
you're,
looking
at
the
as4
customer
interface
for
with
as3,
you
look
at
the
s3.
There
is
nothing
in
asp
that
defines
a
3s
provider,
but
there
is
a
bunch
of
asps
in
bgp
update
messages,
and
you
find
the
previous
as
numbers
you
saw.
You
discovered
a
few
new
autonomous
system
numbers
iteration,
two
for
all
the
new
ones.
Okay.
Well
now
we
discovered
that
as1
and
as2
are
listed
as
providers
for.
F
D
D
Next
now
you
look
at
for
each
s
number
in
your
customer
cone.
You
look
up
raw,
you
find
prefixes!
You
look
up.
You
look
at
all
your
rib
effectively
for
every
interface
and
you
discover
a
few
more
prefixes
where
this
autonomous
system
numbers
are
in
the
origin
in
the
origin
place
and
you
you
got
yourself
list
next
now
we
can
go
back
to
the
example
we've
seen
before
I
mean
it's
kind
of
a
very
trivial
example.
So
8704
wouldn't
discover
prefix
2,
but
barcelov
will
easily
do
that.
D
It
will
build
the
customer
code.
It
will
trivially
find
the
ts2
is
in
this
customer
cone.
Even
if
there
was
like
some
intermediate
system
between
s2
and
s4.
It
would
just
find
this
too,
by
following
the
rules
and
once
it
knows
that,
there's
two
in
its
customer
column,
it
will
use
the
bjp
update
message
from
its
peer
to
see
that
our
prefix
2
is
originated
by
as2.
So
add
it
to
the
save
list.
D
Next
cdn
example:
well,
our
cdn
owns
both
autonomous
systems,
one
and
two,
and
it
owns
prefixes
one
two
and
three.
So
what
it
needs
to
do
is
it
needs
to
publish
raw
that
says
that
autonomous
system
2
owns
can
advertise
effectively
prefixes,
2
and
3..
Now
it
never
means
to
advertise
prefix
3
it
never
will,
but
by
the
virtue
of
it
being
in
raw.
D
Barcelona
will
pick
it
up
now
that
the
autonomous
system,
nine
knows
that
as2
is
its
customer
because
it
sees
prefix
and
from
raw.
It
will
pick
up
prefix
3.
It
also
belongs
in
to
prefix
2,
and
therefore
direct
server
return
will
work.
Fine,
because
prefix
3
is
known
to
be
in
the
sub
list
for
that
interface.
D
D
Now,
looking
at
having
aspar
will
actually
help
you
find
route
leaks,
obviously
that's
kind
of
one
of
its
main
purposes
and
it
also
can
be
used
and
also
would
be
used
by
barcelov
algorithm
by
effectively
checking
the
path.
So
in
this
example,
you
have
as2,
which
has
leaked
a
route
from
its
peer,
so
the
route
to
the
so
the
red
one.
The
route
for
prefix
five
has
been
leaked
to
as9,
but
the
when
as4
is
doing
bar,
save
and
first
thing
it
will
do-
is
to
check
aspa.
D
So
when
it's
seeing
s2
it
sees
that
well,
when
c
is
a
prefix
that
has
s8
and
as2
is
after
it
in
the
path,
but
s8
is
found
in
aspa,
but
as2
is
not
its
provider.
D
So,
first
of
all,
of
course,
this
this
route
shouldn't
have
ever
been
even
accepted
for
forwarding,
but
it
will
also
not
be
used,
so
this
as2
will
never
be
added.
As
so
s,
s
8
will
never
be
added
as
a
customer
of
as2,
and
so
therefore
as8
and
therefore
s5
will
not
be
in
the
customer
cone.
So
s5
is
not
going
to
be
allowed
in
the
save
list
on
s4
to
s
as2
interface.
D
D
We
obviously
will
ignore
s2
to
as8,
but
we
can,
if,
for
whatever
reason
we
need
to
it's
still
in,
we
could
use
information
saying
that
s5
is
a
customer
of
s8.
Now
in
our
search
it
would
never.
It
was
never
needed
in
a
more
complex
network.
It
could
have
been
something
that
could
have
been
used.
D
Okay,
next
and
okay.
That's
basically
that's
the
highlight
of
the
proposal.
G
A
H
Okay,
thank
you.
My
name
is
eric
and
together
with
justin
within
the
room
as
well
and
benoit
is
on
vacation
somewhere,
I
don't
know
in
a
beach
or
in
a
winery.
We
wrote
this
small
draft.
This
is
most
probably
the
smallest
draft
I
have
ever
written,
so
it
will
be
pretty
quick
next,
so
where
is
it
coming
from?
So
if
you
attended
to
juice
dance
presentation
this
morning
at
v6
ops,
we
basically
send
packets
over
the
internet
to
do
some
measurement.
H
H
The
synthetic
traffic
is
in
sometimes
real,
because
you
want
to
test
the
reaction
of
the
global
internet
to
some
strange
packets,
in
this
case
extension
headers,
for
instance,
that
could
be
anything
sending
strange
packet
to
the
network
may
trigger
security
alert,
sometimes
unusual
traffic
pattern,
different
size
or
even
crush
some
system.
Of
course
it's
not
the
intent
of
the
researcher,
sending
those
red
packets,
those
probes
to
crush
the
systems
or
trigger
alerts,
but
it's
a
side
effect.
H
H
So
dri
could
be
an
url
pointing
to
some
specific
text
and
we
basically,
there
follow
rsc
9116,
which
is
the
foodie
security.
So
basically
it
has
a
text
file
human
readable
could
be
multiple
language
with
some
keywords.
Telling
phone
numbers,
language
description
and
so
on
could
also
be
that
what
we
used
in
the
james
experiment,
an
uri
which
is
a
male
2
or
if
you're,
there,
a
uri,
which
is
the
phone
number,
because
if
you
do
it
over
the
internet,
you
may
receive
call
at
2am,
which
is
maybe
not
what
you
want
to
do.
H
H
If
you
don't
do
this
and
again,
it's
not
rocket
science.
If
you
are
for
some
reason
unable
to
put
this
uri
in
the
packet
itself,
you
need
to
use
out
of
band,
you
rely
either
on
reverse
dns
and
you
use
a
well-known
uri
running
simply
if
it's
reversing
smash
example.net,
you
use
a
dot.
Well,
noun
probing.txt
test
require
an
ayanna
section
for
this,
which
is
in
the
draft
or
if
you
cannot
do
reverse
dns,
for
whatever
reason
run
a
web
server
on
your
source
address.
H
Obviously,
with
the
same
year
right
there
bi
right
the
same
path.
Everyone
will
notice
that
https
to
an
ipv6
address
is
not
common
right.
You
will
not
get
real
certificate
for
it,
but
you
can
still
run
https
on
the
top
of
it.
That
would
be
a
cell
sign,
obviously-
and
I
think
in
the
next
slide
this
last
one,
so
we
use
rista
and
the
students
and
myself
this
technique
based
on
previous
experience,
suggestions
were
already
received.
I
think
by
fernando
and
a
few
others
on
the
list.
H
E
An
unexpected
consequence
of
this
draft
might
be
that
network
operators
filter
packets
that
contain
the
uri
it's
of
no
benefit
to
them
to
participate
in
your
experiment,
and
there
is
risk
involved
that
may
bias
the
results
of
the
experiment
that
you're
performing.
Have
you
thought
about
that?.
H
No,
it
wasn't
thinking
about
this,
but
that's
for
sure
that
yeah
that's
a
to
come
back
on
the
first
presentation,
there's
a
kind
of
indicator
of
a
compromise
somehow
so
it
could
be
detected
as
an
attack
on.
H
Or
even
could
be
proved
as
a
dropping
packet,
so
improving
the
quality
of
service
for
these
packets
to
say,
hey,
this
isp
is
better
than
others
who
knows
yeah.
That's
the
first
statement.
It
deserves
at
least
to
say
it
in
a
power
graphene
or
in
a
section
in
the
draft.
Thank
you
ron.
A
G
H
H
Reacting
on
it
is
a
good
real
thing
as
an
basically
when
twice
in
my
lifetime,
I
generated
those
kind
of
packets
right
and
I
think,
as
a
goodwill
researcher,
you
want
to
do
something
good
for
the
network
and
you
do
this,
like
every
mechanism
can
be
bypass
right,
so
you
can
put
example.com
or
google.com
as
google
is
there
as
your
uri
or
the
email
address
of
of
jen
right.
That's
for
sure.
H
A
Okay,
nalini:
are
you
in
the
queue
intentionally
or
you
just?
I
can't
remove
you
just
okay,
fernando.
C
I
won't
necessarily
say
that
I
remotely
I
regularly
send
these
packets,
but
let's
say
that
I
know
people
that
regularly
send
this
kind
of
packets,
and
you
know
that
the
well
you
know
in
theory
it
seems
to
be
a
good
idea.
You
know
the
the
challenge
that
I
find
is
that
quite
often
it
do
affect
the
proof,
packets
that
you'd
be
sending
like,
for
example,
just
to
you
know
pick
on
one
specific
example,
but
that's
just
because
I
hear
it
during
the
presentation.
C
If
you
include
data
in
a
sin
packet,
there
are
systems
that
might
process
the
packet
differently
as
they
do.
Without
the
you
know,
the
the
data
in
the
you
know
sync
packet
itself.
What
I
know
that
people
do
when
they
want
to
be,
let's
say
friendly
about
the
experiments
they
do.
Is
you
know
if
they
are?
You
know
going
to
pull
the
network
from
you
know
some
address
is
you
know?
C
On
the
one
hand,
you
know
configure
the
reverse
dns
mapping
mappings
for
the
address
that
you
use
for
the
probes
and
then
host
a
website
on
that
address
such
that
you
can
explain
in
that
website.
You
know
what
it
is
it
that
you're
doing
you
know
what
you
are
doing
it
for
and
and
so
on.
C
H
J
Hi
robert
story
is,
I
had
two
comments
on
when
on
the
in
band.
Have
you
thought
about
maybe
putting
some
kind
of
identifier
in
the
packet
to
to
for
people
to,
for
example,
maybe
something
like
wireshark
or
tcp
dump
to
be
able
to
recognize
what's
in
the
packet
and
show
it
because
a
lot
of
people
they
look
at
a
raw
packet
dump
they're
not
going
to
go
to
the
effort.
They
see
some
ascii
they
may
or
may
not
delve
further.
But
if
wireshark
or
something
automatically
call
it
out
like
a.
J
And
speaking
to
the
earlier
point
where
people
could
be
filtering,
that
could
be
considered
a
feature.
Most
people
that
are
doing
research
projects,
allow
people
to
opt
out
and
having
the
identifier
they'll
be
able
to
recognize
those
packets.
There's
a
reason
discussion
on
nano
about
this
very
thing
by
somebody
very
irate
at
getting
some
packets.
So
I
think
that
that
could
be
considered
a
feature.
A
Yeah
I'll
hijack
myself
to
the
no
hats
on
I'm
just
thinking
that
iranian
web
server
or
something
on
the
source
address
of
the
probe,
probably
wouldn't
be
always
feasible.
If
you
have
a
lot
of
vantage
points
like
arri,
patlus
right
you're
like
no
way
you're
gonna,
do
it
on
your
like
every.
A
H
H
I
Thank
you,
yeah
warren
kumari,
again
yeah.
I
think
we
should
be
careful
that
we
don't
end
up
with
the
perfect
being
the
enemy
of
the
good
right
like
at
the
moment.
There
is
no
useful
attribution,
even
if
it's
not
perfect,
even
if
it
doesn't
work
under
all
conditions.
Even
if
some
people
don't
want
to
use
it
because
it
adds
data
at
least
it's
something
that
people
can
use
if
it
works
for
them.
So
yeah.
F
A
I
Warren
turn
the
mic
around
actually
yeah
I'll
just
stand
here
so
hey
all.
I
am
the
ad
for
opsec
and
I've
been
doing
the
80
thing
for
quite
a
while.
Now
my
term
is
up
in
march,
I
will
probably
run
again,
but
I'd
really
really
really
like
some
people
to
run
against
me
and
so,
if
anybody's,
even
potentially
interested
in
serving
as
opcady.
Please
come
along
and
talk
to
me
and
I'm
more
than
happy
to
explain
to
you
what
the
role
is
actually
like.
What
the
time
investment
is.
I
You
know
why
you
might
want
to
do
it.
It
is
actually
kind
of
fun.
So,
just
you
know
please
consider
putting
your
name
in
for
for
upc
when
the,
when
the
nominations
open.