►
From YouTube: IETF92-OPSEC-20150326-1740
Description
OPSEC meeting session at IETF92
2015/03/26 1740
A
Okay,
I
think
we
hit
the
540
button.
So
maybe,
let's
start
you
know
I
think
we
can
squeeze
everybody
into
the
room
with
just
able
to
do
that.
So
welcome.
You
have
managed
to
end
up
in
the
object
working
group,
so
the
first
things
we
need
to
figure
out
here
is
who
is
willing
to
take
some
minions
and
I
could
volunteer.
A
A
So
everybody
knows
the
note.
Well,
the
blue
sheets
are
going
around
just
to
make
sure
the
next
time
we
get
again
a
room
which
fits
everybody
with
the
large
numbers
we
are
here
and
let's
have
a
look
into
the
chancel
is
the
note
well
you've
already
seen
it
a
few
times,
just
make
sure
that
you
read
it
and
that
you
understand
everything
which
is
in
there
yeah
the
sheets
important.
So
where
are
we
right
now?
So
there
was
no
object.
A
A
B
A
Let's
do
that
sounds
a
good
one.
Then
another
document
will
be
progressed
further
on,
so
that
is
waiting
for
a
shepherd
right
up.
That's
me
still
on
my
to-do
list
and
also
we
have
the
wonderful
enjoyment
about
high
PR
disclosure
for
one
of
the
documents
misprint
on
my
cisco
on
RC
six
to
192,
so
that
is
being
hope.
It
also
somewhere
in
parallel.
In
the
background.
A
C
C
This
one
is
spinning,
look
back,
pain,
prepare
the
water
anyway,
so
it's
a
very
long
presentation,
let's
start
immediately.
So
does
the
elaborate
on
the
draft
that
we
started
a
long
time
ago
regarding
the
procedures
to
operate
securely
in
a
pv6
network,
so
mary
kay
and
kk
dakota
and
the
last
one,
and
since
last
the
IETF
dress
revision.
Actually
nothing
was
moving.
C
So
what
we
did
basically
refresh
the
references,
because
a
lot
of
draft
from
Fernando
has
become
now
RFC,
so
we
needed
to
change
this
change.
A
few
warning
fix
typos
as
I'm
a
co-author.
My
coder
fix
my
English
so
simply
improving
next
and
now
the
to-do
list.
We
just
need
to
ensure
that
we
started
this
work
in
2012
so
that
three
years
ago
we
have
security.
As
we
all
know,
it's
moving
target,
it's
an
ever-changing
field
and
as
Fernando
is
the
on
the
first
row,
cannot
save
an
eight.
You
are
finding
out
the
back.
C
C
The
three
of
us,
the
authors,
to
basically
push
his
document,
which
was
ready
at
ninety-five
percent
and
basically
the
trio
tirso,
is
three
part
of
text
and
we
clearly
use
sometimes
different
vocabulary,
different
style
and
we
wanted
to
get
a
document
which
was
nice
from
the
English
and
readability
and
clarity,
point
of
view,
but
basically
to
be
honest-
and
I
think
mary
kay
will
agree
with
me.
We
are
running
out
of
steam
because
you
know
going
from
95.
99
is
ok
going
from
99
percent
299,
nine
percent
completion
takes
forever.
C
We
sincerely
believe
that
what's
inside,
and
we
got
multiple
comments
already
one
year
and
a
half
ago
when
the
document
was
active
and
out
is
mostly
complete
in
the
sense
of
siting
and
doing
in
order
the
aspect
and
all
their
issues
and
proposing
mitigation
techniques.
It's
not
finished.
Regarding
ability
what
we
really
believe
document
is
finished
right,
so
we
really
say
this:
one
should
go
for
that
school
know.
C
D
Yeah,
and
so
we
believe
that
the
content
is
all
there,
we
were
trying
to
wordsmith
it
and
kind
of
make
it
aesthetically
a
little
more
cohesive,
but
the
last
time
we
looked
at
it,
we
felt
that
you
know
it
may
not
actually
be
necessary.
So
for
us
to
be
spinning
those
cycles-
and
you
know,
were
all
involved
in
a
lot
of
different
work.
C
A
You,
okay,
so
so
something
what
I've
seen
also,
which
was
happening
like
in
another
document,
for
going
to
like
anakin
complete,
was
nearly
impossible
or
the
beach
pre-filtering
element
the
way
they
circumvented
it
is
to
refer
to
particular,
you
know
references
to
take
those
things
into
consideration
to
make
a
document
actually
more
static.
That
may
be
something
you
can
look
into
words.
It's.
C
Not
so
much
the
references
that
changing
it
honestly
I
mean
it
takes
some
time
to
change
all
the
idea
to
a
receipt
as
for
sure,
but
we
are
adding
sometimes
new
fields,
for
instance,
that
through
post
conferences,
the
capitalist
way
we'll
get
something
like
ma.
Ds
issue,
mostly
someplace,
to
write
another
idea,
but
we
will
not
update
our
document
because
that's
it's
at
least
text
whatever.
A
So
I
think
out
of
the
room
like
28
people
actually
afraid
it.
So
what
I'm
made
before
going
to
work
route
possible?
Actually,
you
know,
is
like
people
in
the
room
willing
to
give
this.
You
know
a
rate
of
the
document,
given
you
know
the
feeling
about
how
ready
it
is
before
we
go
to
the
who
know
the
next
up.
Oh
yeah,
it's.
B
B
B
The
time
we
publish
a
document
on
the
filtering
of
ipv4
packets
containing
ipv4
options,
so
this
is
an
ipv6
version
of
it.
The
ultimate
ultimate
goal
is
that,
to
some
extent,
this
document,
my
help
with
you,
know
improving
the
current
state
of
affairs.
When
it
comes
to
the
you
know,
packets
pin
drop
as
a
result
of
containing
extension
headers.
B
It
tries
to
summarize
security
and
operational
implications
of
extension,
headers
and
ipv6
options.
This
is
again
like
the
same
thing
that
we
did
for
RFC
7126,
so
for
each
extension
header
an
option.
We
try
to
summarize
what
that
header
an
option
is
useful
and
what
might
happen
if,
for
some
reason,
you
were
to
drop
packets
containing
them
and
then
what
we
try
to
do
also
is
to
provide
advice
to
what
to
do
with.
You
know,
with
each
extension,
header
and
option
type
next
slide.
B
So
this
is
the
changelog
since
the
last
revision
of
the
document,
one
of
the
things
was
that
we
clarified
that
we
assume
that
the
rules
in
70
RSC
74
five
are
in
place
then,
regarding
the
hope,
I
hope,
options.
Extension,
header,
farruko
correctly,
the
previous
version
of
the
IDs
actually
just
advise
it-
to
drop
packets,
containing
hop-by-hop
options
and
based
on
working
group
feedback.
What
would
it
is?
B
You
know
modified
advice
and
say
that,
well,
if
the
platform
can
process
hope,
I
hope
options
in
the
fast
path,
they
should
pass
the
packet,
otherwise
they
should
bravely
meet
those
packets.
But
if
the
first
option
on
the
second
option
are
not
available,
then
as
a
last
whistle,
they
should
drop
those
pockets
and
another
thing
that
we
clarified
was
done
and
that's
essentially,
you
know
the
same
discussion
that
we
have
for
RFC
7126
is
that
we
are
not
really
specifying
configuration
defaults,
but
actually
providing
unbiased
on
how
to
configure
devices.
B
That's
essentially
what
what
we
believe
was
at
the
time
already
the
IETF
consensus.
So,
in
those
cases
in
which
we
are,
let's
say
about
advising
to
let's
say,
rate
limit
or
drop,
some
pocket
is
not
that
we
are
advising
implementations
to
ship
with
our
advice
by
default,
but
they
should
have
their
honor.
You
know
there
are
defaults
and
then
the
guy
manually
configuring,
you
know
the
device
should
probably
follow
the
advice
that
we
are
providing
here
next
line.
B
I
think
that
we,
a
couple
of
people
had
mentioned
that
you
know
having
to
go
through
the
entire
document
and
look
up
for
the
advice
was
not
that
nice,
so
it
would
be
great
to
have
a
table
that
just
you
know,
mentions
the
advice
and,
if
you
want
like
you
know,
if
you
want
to
look
for
the
rationale
for
that,
you
can
do
it.
There
are
quite
a
few
sections
that
are
mostly
placeholders.
Okay.
B
The
reason,
of
course,
is
that
I
mean
we're
covering
all
day
caterers
and
options,
and
some
of
them
are
at
times
are
you
know
hard
to
find
well
what
they
were
specified
for
and
what
they
are
used
for,
etc.
So
that's
the
other
thing
that
is
it's
in
our
to-do
list
for
the
next
revision
and
I,
don't
know
if
there
are
any
comments
or
whether
we
have
you
know,
miss
anything
among
other
things.
B
B
E
Jen
link,
oh
I,
read
the
previous
version
and
I
just
tried
to
look
through
the
current
yeah.
A
version
of
it
here.
I
probably
will
put
some
comments
on
the
list.
My
like
first
impression,
I
don't
know,
I
read
it
and
it
looks
like
you
quite
often
say
device
should
drop.
I
don't
know
if
you
should
say
you're
polish.
You
should
not
permit
this
or
something
like
Zach,
because
it
basically
for
me
I,
have
to
go
to
the
beginning
and
double-check
that
we
explicitly
say
this
is
no
default
configuration
on
the
device.
E
This
is
recommendation
for
a
policy,
but
all
text
in
the
document
as
a
device
should
buy
/
default
dropsies.
So
probably
we
should
make
more
clear
like
we
talked
about
policy
not
about
what
forwarding
device
does
with
the
packet
okay.
Another
issue
is:
do
you
think
we
might
need
to
separate
advisors
for
like
transit,
network
and
situation
when
you
protect
your
own
network?
That's.
E
It
might
be
useful
because
you
I
read
it
as
like:
forwarding
device
should
drop.
That
said,
but
probably
you
don't
care,
if
you
just
a
transit
provider,
probably
you
do
care.
If
it's
your
network,
can
you
protect
in
it
and
you
apply
these
firewall
rules
on
your
router
I
might
become.
Your
approach
might
be
completely
different.
Yeah.
B
That's
actually
that
we,
you
know
we'd
like
to
hear
from
the
working
group,
because
we
have
even
talked
you
know
among
they
co-authors,
and
you
know
some
of
what
we
were
talking
about
this
ID
some
were
suggesting
to
you
say
well
kind
of
like
that
yeah
what
to
make
a
difference
between
the
transient
routed
from
another
one
and
but
we
weren't
sure
about
that.
So
that's
up
to
the
work
in
you
jamesha.
D
Yeah
I
just
took
a
real
quick
look
at
the
document
in
hearing
Jen's
comment
and
from
the
gentleman
behind
there.
I
also
think
that
looking
at
specific
different
use,
cases
like
transit
providers
or
otherwise
would
have
different
implications,
and
so
I
would
probably
add
that
language
and
but
also
promised
to
read
it
in
detail
that
show
you
put
some
comments
on
the
list.
Awesome
thank.
B
B
The
idea
was
quite
simple:
if
you
were
to
spoof
ICMP
packet
to
Vigoroth
messages
claiming
an
MTU
smaller
than
1280,
you
could
trigger
the
use
of
fragmentation,
okay
and
then,
as
a
result
of
the
network,
filtering
fragments
fragments.
Then
that
would
lead
to
the
edenite
of
service.
I
mean
the
background
is
don't
need
it,
but
I'm
just
explaining
how
we
got
into
this
document.
This
stuff
was
discussed
in
the
basics
of
mailing
lists
and
a
few
folds
suggested
or
or
we
started
discussing
how
we
could
possibly
filter
ICMP
error
messages
to
mitigate
these
attacks.
B
So
this
is
what
this
document
is
about
next
slide.
So
essentially,
if
you
look
at
vc
p38,
it's
about
mitigating
attacks
that
require
the
spoofing
of
the
source
address,
but
these
PCP
silly
838
doesn't
address
icmp
based
attacks,
because
when
you
spoof
ICMP
error
messages,
you
don't
really
need
to
spoof
the
source
address
of
the
outer
pocket.
You
need
to
put
the
sorcerer
or
the
addresses
on
the
packet
that
is
embedded
in
the
ICMP
error
message:
okay,
next
line,
so
this
is
like
a
very
small
refresher.
B
So
let's
say
that
we
have
caused
a
sending
packets
do
koske
on
the
other
side,
and
then
this
water
find
that
there
is
some
problem.
It
will
send
an
ICMP
or
to
cause
a
so.
The
Alvis
is
that
you
will
get
is
in
the
source.
Address
address,
be,
of
course,
which
is
the
source
destination
address
our
essay,
which
is
the
destination
of
the
error
message
and
then
in
the
payload.
You
will
get
a
chunk
of
the
original
packet.
B
Of
course,
the
original
packet
was
directed
from
A
to
D,
so
in
the
source
you
will
find
a
and
the
destination.
You
will
find
thee.
Okay,
I
mean
no
no
magic,
their
next
life.
So
this
could
be
an
attack
scenario
which
you
have
like
you
know
some
networks
in
there,
and
the
idea
in
here
is
that
you
have
this
air
occur
in
some
point
of
the
network
that
wants
to
attack
the
connection
between
these
two
systems.
Okay,
so
the
idea
is
that
the
are
occur
that
is
like
connected
to
the
network
at
some.
B
You
know,
random
message
at
some
random
part
of
the
network
wants
to
attack
the
connection
between
these
two
guys.
Now.
The
problem
is
that
when
this
other
person
says
spoof
ICMP
message,
it
doesn't
really
need
to
spoof
the
source
address.
Why?
Because
you
know
error
messages
can
come
from
any
water,
so
you
don't
need
to
pretend
or
in
person
I
any
specific
router.
B
So
in
this
case,
if
we
are
attacking,
for
example,
the
connection
between
these
two
and
you
are
selling
their
own
error
message
to
this
guy,
the
source
address
you
can
use
your
own
address
this
one,
the
destination
address
is
going
to
be
the
target
of
the
other.
That
is
this
one,
but
the
address
is
that
you
are
really
spoofing.
Are
the
two
addresses
that
are
in
the
embedded?
Pelo?
Okay?
Now,
if
you
look
at
the
error
message
from
the
point
of
view
of
these
routing
here,
there's
nothing
wrong
with
the
assessing
here.
B
But
when
you
look
at
the
addresses
that
are
in
here,
I
mean
it's
clear
that
you
know
the
error
message
cannot
really
come
from
this
side.
Okay,
so
this
is
essentially
like
doing
English
filtering,
but
rather
than
looking
at
the
addresses
of
the
outer
pocket,
you
are
looking
at
the
addresses
that
are
embedded
in
the
pillow.
Okay.
B
Of
course,
let's
say
if
we
have
the
source
service,
which
is
222,
so
if
it's
clear
that
you
know
a
pocket
that
comes
from
the
internet
in
this
case,
assuming
there's
a
single
connection,
of
course,
could
never
have
these
services.
You
know
in
the
bed
and
embedded
palin,
so
you
could
do
english
filtering
by
looking
at
the
addresses
in
the
bed
pillow
next
line,
so
this
check
is
essential,
an
extension
to
bc
p38
and
the
advice
is
actually
in
line
with
bc.
B
P38
next
line-
and
this
dissolve
the
rules
we
are
studying
them
in
the
same
way
as
in
bc
p38.
When
you
look
at
the
address
that
is
in
the
destination
address
of
the
embedded
bailar,
that
is
not
the
outer
pocket.
Can
you
go
back
like
choose
yeah,
so
you're,
looking
at
the
embedded
packet
in
here
right?
So
this
is
the
outer
pocket?
No
need
to
look
here,
because
the
address
is
here
are
not
going
to
be
spoofed.
These
are
the
addresses
that
are
going
to
be
forged.
B
Ok,
so
two
more
yes,
so
you
look
at
the
destination
address
and
if
the
destination
address
of
10
bedded
payload
is
from
your
network,
you
forward
the
packet
and
what
you
do
essentially
English
filtering
based
on
the
destination
address
of
the
of
the
packet
that
is
embedded
in
the
payload.
Ok,
so
in
the
same
way
as
you
do,
English
filtering
on
the
utter
sorceress
for
the
ICMP
error,
you
do
the
same
thing
on
the
destination
address
of
the
embedded
payload
in
the
same
way
as
and
in
the
same
case
as
in
bc.
P38.
B
C
F
B
Actually,
you
look
at
the
destination
address,
because
that
this
means
that,
let's
say
if
you
are
receiving
a
mess,
a
wrong
message
from
here,
so
the
filtering
is
happening
here:
okay,
so
that
means
that
if
a
packet
is
coming
from
here,
this
means
that
these
Rooter
eventually
sent
on
this
link
a
pocket
this
time
to
these
destination.
Address
that
that's
impossible.
Okay,.
B
B
Of
course
it's
different
to
check
on
the
you
know,
sorceress
of
the
outer
pocket,
as
opposed
to
the
address
that
is
embedded
in
the
payload.
So
there
might
be
cases
in
which
you
could
do
like
traditional
PC
p38,
but
not
look
at
you
know
the
addresses
of
the
ICMP
error,
but
again
this
is
an
extension
to
bc.
P38
next
slide.
So
I
don't
know
if
there
are
comments.
E
E
Well,
no,
because
you
can
okay,
could
you
please
show
picture
yeah.
So
basically,
this
machine
on
the
left,
yeah
it
might
help
dual
connection
and
send
packets
to
the
Internet.
Somehow
yeah,
we
should
be
coming
back
through
nuzzling.
Your
PF
is
dangerous.
Here
you
can
enable
it
in
very
specific,
like
topology
and
all
other
cases
just
caught
in
traffic,
but
according
yeah.
E
I'm
really
concerned
that
if
you
start
doing
this
on
router,
it's
going
to
be
dangerous
because
I,
a
spiel
etsy
start
enabling
this
on
the
router,
and
then
this
network
on
the
left
getting
dual
connection,
and
then
they
have
to
go
to
ISP
and
explain
to
them
that
their
configuration
is
causing
traffic
black
hole.
What
you're
talking
about
is
actually
deep
packet
inspection.
It
should
be
done
on
firewalls
in
very
specific
scenario
close
to
destination.
Yes,
it
shouldn't
be
done
on
the
routers.
We.
B
E
Whole
not
sorry
to
cook
so
I
think
as
soon
as
you
get
in
a
duel
connectivity,
especially
in
case
of
v6,
but
isn't
that
the
case
for
busy
be
sorry
I
know
already
know,
because
in
bcbg
trade
you
always
should
always
send
traffic
with
a
proper
source.
But
reply
to
some
packet,
which
might
come
to
you
through
completely
different
link,
might
be
sent
through
another
link.
Well,.
E
B
E
Example,
we
divide
war
next
time,
I
whiteboard
I
said
we
need.
Oh,
there
are
some
pictures
here,
but
believe
me
as
soon
as
it's
routing
and
it's
not
like
firewall
close
to
you
James-
that
when
you
absolutely
sure
there
is
no
but
the
door
to
your
network,
this
is
not
gonna.
Work
on
is
gonna,
be
dangerous,
so
I
think
it
should
be
done
on
fire
walls
as
a
part
of
deep
packet
inspection
of
a
favor
and
notice,
like
any
recommendation,
related
to
be
CP
search,
shade.
E
D
Understand
what
why
you're
saying
that
it's
kind
of
like
PCP
38,
but
the
problem
I
think,
is
the
fact
that
you
have
to
look
deeper
into
the
packet
and
what
I'm
trying
to
think
of
now
is
you
know
this
is
true
for
any
error
messages
for
any
protocol.
That
can
actually
say
hey.
The
error
messages
actually
come
coming
from
a
quote-unquote
spoofed
source.
D
So
while,
while
I
think
this
is
interesting,
right
and
I
mean
people
may
need
to
be
aware
of
this,
I
am
squinting,
because
I,
don't
I'm
I'm
worried
that
that
that
this
can
be
misconstrued
okay,
because
because
if
this
document
is
out
there,
that
means
that
oh
gosh,
we
should
do
something
about
it,
and
what
you're
going
to
be
doing
is
deep
packet
inspection
on
absolutely
everything
and
from
where,
on
the
cpe
on
the
router
on
the
firewall.
What
and
so
I
have
to
think
about
this
a
little
more
but
I
mean
it's.
E
Since
I
forgot,
I
think
I
think
I,
don't
remember
who
discussed
it
sure
when
we're
talking
about
a
fragmentation
header-
and
this
is
host
problem,
it's
a
host
which
is
broken
because
the
host
should
verify
her
person
suspected.
What
is
inside
behind
this
IP
header
is.
Do
I
have
actually
any
TCP
session
which
much
what
is
going
on
what
I
received?
We
should
fix
host
implementation
if
it's,
if
this
attack
is
actually
possible,
not
trying
to
break
crouch
and
they're
actually.
B
There
are
actually
two
comments
that
I
could
may
about
that:
I'm,
not
saying
that
what
you're
saying
is
not
correct,
but
there
are
a
couple
of
problems
there.
So
first
problem
is
that,
since
you
know
the
extension
header
chain
can
grow
as
much
as
you
want,
then
you
are
not
guaranteed
that
in
the
embedded
payload
here
you
are
going
to
get
a
TCP
header.
E
E
That
we
probably
should
fixes
it
probably
need
some
recommendation
on
how
to
price
what
to
do
with
precision.
I
see
Imperial
messages
on
the
host
instead
of
trying
to
fix
every
single
possible
attack
scenario
on
the
network
level
when
host
is
stupid
enough
and
not
properly
checkin.
If
it's
valid
I
see
if
it
has
a
channeler.
B
Ok,
because
since
the
original
packet
you
know
cesium
same
thing
as
always
right
extension
togethers,
you
might
get
as
many
as
you
want
and
since
you
only
get
like
a
chunk
here,
for
example,
let's
assume
that
you
have
a
packet
that
has
let's
say
1300
bytes
in
headers,
ok,
and
then
after
that,
you
get
the
transport
header.
The
chunk
that
you're
going
to
get
here
is
going
to
be
1280,
and
it's
not
going
to
contain
the
transport
Heather.
E
B
Now
we
get
to
the
second
item:
I
tried
exactly
that
10
years
ago,
thats
RFC
5927.
We
took
me
seven
eight
years
and
while
I
agree
with
your
view,
let's
say
that
TC
p.m.
didn't
agree
on
that.
That's
why,
when
you
look
at
the
ICMP,
if
occasions
they
kind
of
like
say
well,
you
know
you
should
look
at
750
927,
but
are
they
kind
of
like
they
don't
recommend
anything
because
TCP
wasn't
that
much
in
favor
of
that
did.
E
B
To
be
honest,
I
think
that
two
things
are
orthogonal,
so
I
think
that
when
it
comes
to
the
validation
on
the
client
side,
that's
something
that
should
be
done
in
many
cases
is
not
done.
The
simple
example
is
Linux.
The
only
thing
that
you
need
to
you
know
to
guess:
to
perform
any
ICMP
vasotec
on
linux.
It's
just
the
endpoint
addresses
I.
Try
that
and
you
don't
need
to
even
like
boot,
like
a
valid
protocol
inside
as
long
as
you
get.
The
right
addresses
that's
as
much
as
that's
everything
that
you
need.
B
So
that's
one
part
of
it,
so
they
currently
they
don't.
You
know
they
don't
perform
that
validation
and,
on
the
other
hand,
I
agree
that
it.
You
know
you
wouldn't
do
this
sort
of
thing
in
any
arbitrary
devices,
but
there
are
some
in
which
you
can
do
this
kind
of
stuff
and
that
prevents
the
systems
that
are,
you
know
behind
the
poem
you
know
behind
the
device
where
you
are
doing
this
filtering,
that
you
prevent
those
devices
from
performing
attacks
against
other
systems
on
the
Internet
I.
E
So,
basically,
to
summarize
I
believe
the
damage
which
could
be
done
comparing
to
damage
which
we
are
trying
to
prevent,
is
much
bigger.
So
we
try
to
cover
one
very
specific
particular
use
case
and
try
and
even
to
fix
it
from
the
wrong
side,
not
where
it's
actually
broken,
and
we
give
people
ability
to
miss,
configure
the
network's
even
more.
C
Now
most
of
the
far
wall
do
it
it's
not
basically
DPI.
They
simply
look
about
the
state.
If
they
have
a
TCP
connection
on
this,
because
they
need
to
know
so
stupidly,
a
45
were,
can
do
it
and
I
see
an
ICMP
coming
back,
not
much
no
matching,
then
I
can
drop
it
now.
If
Lennox
is
buggy,
then
it
should
be
fixed
though
yes,.
B
C
B
C
Don't
forget:
icmp
error
messages
are
critical
for
debugging
and
there
could
be
some
case
that
we
have
seen
this
right-
VPN,
for
instance,
from
the
top
o'the
to
the
internet
and
send
in
the
traffic
back,
and
this
is
of
course
abnormal.
It's
an
error,
autism
mr.
exam
where,
but
we
should
get
this
icmp
mess
so
I
think
the
the
mitigation
technique
is
worse
than
the
disease
mitigation.
C
E
F
E
Some
again
multi-home
increase
and
the
host
might
return
package
through
the
internet
icmp
packets
to
internet
right.
So,
basically,
your
scenario
works
only
because
you
have
one
single
link
from
each
host
to
the
router
and
one
wink
from
joe
internet
as
soon
as
you're,
a
drink,
multi,
home
and
and
ability
for
packets
go
in
a
symmetrical.
E
F
B
B
B
E
On
ice
spear
right,
you
don't
know
what
you
don't
necessarily
know.
What's
going
on
with
the
host,
the
host
might
get
another
connecting
another
up
link
to
another
SP
I
couldn't
remember
a
lot
of
cases
when
transit
providers
turned
on
your
pear
and
Bullock
hold
my
packet,
and
when
you
came
to
the
reward
security
feature
well,.
E
B
E
Younger
PF
is
break-in.
Bcp
search
age
is
different.
Yeah
yeah
yeah,
because
bcp
scituate
has
nothing
to
do
with
asymmetric
origin,
but
you
don't
we
have.
Does
your
PM
doesn't
work
properly?
If
you
have
a
symmetrical
routing,
uh-huh
but
bcp
situated
just
says,
okay
I
know
that
I
should
not
receive
spec
it
from
I
should
receive
only
sole
source
from
the
clink.
It
says
nice
and
about
where
I
route,
packets
for
those
destinations.
B
B
D
The
only
comment
I'm
gonna
say
is:
we
really
should
stop
talking
about
bcp
30,
a
call
it
anti
spoofing
there
bc
p84
that
deals
with
the
asymmetric
routing
issue
and
actually
pekus
avila
had
written
a
draft
that
expired,
but
had
really
good
content
in
it
where
he
had
operation
experience
with
anti
spoofing,
a
lot
bc,
p38
or
ingress
filtering
by
using
a
symmetric
routing.
So
I
think
we
should
take
this
conversation
to
a
white
board
right,
but
I
I
very
much
also
agree
with
Arik.
That
I
think
this.
D
A
G
G
Is
an
edge
because
an
edge
could
be
the
guy
one
hop
up
from
a
dsl
modem
or
an
edge
could
be
the
guy
one-half
up
from
a
ds3
connector
customer
they're,
both
edge
case
yeah
case
one.
You
absolutely
should
be
doing
European
strict,
and
this
will
work
beautifully
case
to
you-
do
that,
oh
my
god,
you're
going
to
break
things
yeah!
That's
why
your
PF
loose
was
created.
Uh-Huh.
F
B
F
The
way
it's
described
in
bc
p38,
if
it
could
be,
everyone
would
use
it
everywhere,
and
things
would
be
hunky-dory,
and
this
would
never
be
a
problem,
but
it
can't
be
so
it
isn't,
and
so
everybody
who
says
just
use
bc
p38,
it's
like
that,
doesn't
work
if
your
transit
customers
are
multihomed
like
even
if
they
are
edges,
because
they
might
withdraw
prefix
that
they're
advertising
to
you
and
still
want
to
send
traffic
outbound
on
that
link
and
that
causes
a
black
hole
every
single
time.
If
you
do
strict
right.
G
D
A
A
F
F
E
E
B
B
F
F
E
E
F
B
E
E
In
Bishop
is
your
change
all
you
have
to
ensure
that
all
packets
coming
from
here,
if
from
subnet
at
one
and
from
some
nettle
tea,
let's
eat
how
they
said
if
they
send
it
through
another
minute.
Okay,
you
just
have
to
make
food
packets
from
them
from
well-defined,
something
that's
it.
It
is
not
you
mean
bcp
should
share
here.
This
pc
traders
say
I
have
11
here,
so
I'm
only
accepting
this
prefix
here,
if
I
get
with
the
source
here
and
take
it
from
sisters
here,
that's.
E
E
B
H
E
F
H
F
H
F
F
F
E
F
E
Yep,
exactly
so
h1
router1
age
to
internet.
We
connected
like
this
right.
This
they
have
default
pointing
here
today.
Is
this
a
backup
they
don't
want,
normally
use
it.
Yeah
I
get
went
like
this
right
I
think
we
reached
this
router
sub-editor
on
packet
reached
this
router
somewhere
the
internet,
and
because
they
have
her
out
and
qwali
says
they
decided
to
send
this
ICP
back
here,
not
true.
Another
link.
B
E
B
E
B
B
F
E
E
F
E
Your
firewall,
which
sits
like
yes,
even
the
same
subnet
that
will
protect
you
first
and
has
all
this
session
table
and
looks
at
all
these
sequence
numbers
my
channels.
Its
top
is
used
to
book
and
such
a
CP
and
say
I
don't
have
session
for
the
record.
Oh
I
should
probably
because
it's
the
same
weighs
the
same
as
resilient
as,
if
equated
with
love
me
too
long
procession,
just
as
forth
an
eyepiece
much
right.
It's
your.