►
From YouTube: IETF101-OPSEC-20180321-1520
Description
OPSEC meeting session at IETF101
2018/03/21 1520
https://datatracker.ietf.org/meeting/101/proceedings/
A
C
Ok,
joke
aside,
it's
1520,
so
let's
start
and
open
the
obstacle
group
session,
it's
chaired
by
three
people
for
now
SIL
for
few
seconds:
I
guess!
So,
let's
start
with
wrong,
which
is
the
new
co-chair.
You
know
him
Ginter,
with
a
and
taking
minutes
today
is
stepping
down
from
the
role
of
what
he
could
chair.
So
thank
you
for
using
my.
C
Co-Chair
on
this,
for
a
while
and
my
name
am
Eric
link,
we
have
a
Java
stripe,
which
is
rollin
and,
as
I
just
said,
the
ginger
is
kind
enough
to
take
the
notes
of
this
meeting.
Please
do
note.
Well,
everyone
knows
it,
but
we
change
it
recently.
So
and
this
idea
the
note
one
is
slightly
different
than
the
other
one.
Basically,
it
says
whatever
you
say
here
is
public
blue
sheet.
You
know
the
trailer
by
now
fill
in
your
name
and
your
affiliation,
it's
mainly
to
get
a
room
bigger
or
smaller.
C
Next
time
it's
important
I
joined
up.
So
we
are
doing
this
a
mystery
here
right
now.
We
will
spend
some
time
mainly
on
one
document,
which
is
the
OPSEC
ipv6
I
have
striked
out
the
aah
filtering
with
the
agreement
via
other
care,
because
this
document
is
basically
ready
for
working
group.
Last
call:
we
will
issue
the
group
glass
code
in
the
coming
days.
It
is
only
to
change
compared
to
the
previous
version.
A
lot
of
typos
has
been
fixed
and
the
ripple
options
for
the
room
that
the
role
of
working
group
has
changed.
C
Numbers
there's
only
change
compared
to
the
other
ones.
So,
let's
go
there
then
I
will
present
the
object
v6,
the
document,
which
is
there
for
many
many
years.
This
is
the
only
two
working
group
documents
that
we
have
today
and,
as
usual,
we
try
to
invite
Nanak
a
group
document,
because
OPSEC
is
an
intersection
of
security
and
operation.
So
sometimes
they
are
interesting,
documenting
ops,
that
is,
security
impact
and
vice
versa
document
in
security.
That
is
an
operational
impact.
C
So
there's
always
interesting
for
authors
to
get
the
feedback
from
the
object
community
here
and
we
will
get
a
swing
arm.
We
tell
represented
couple
of
times
here
and
maybe
working
group
adoption
of
this
document.
Then
you
have
as
well
tree
with
Lance
Ian,
Fleming,
Jodie
and
castle
will
present
the
owner
of
they're,
mostly
fifteen
minutes,
each
I
missed
radium.
So
just
said,
we
have
two
documents:
I
will
present
the
object.
V6
and
honestly,
the
aah
filtering
is
ready,
at
least
for
if
to
go
within
a
school.
C
C
Changing
role
so
wrong:
you
are
the
only
one
chairman,
but
it's
okay,
I
guess
so
presenting
this
revision
13
of
these
documents
and
you
will
notice
something
has
changed
there
is
we
have,
for
you
know
the
story
from
Erickson
oedema
right,
the
three
musketeers
it
was
Kiki,
Mary
came
and
Eric
we
were
always
with.
All
of
us
has
got
to
K,
at
least
in
our
names,
even
two
or
three
in
some
times,
so
we
did
it.
Somebody
else
and
we
found
an
array.
So
just
a
few
slide
1
slide
to
introduce
him.
C
It's
a
well-known
person
out
of
Germany
I
mean
some
people
knows
him
here.
He
knows
ipv6
very
well
in
a
basic
security
value
address
as
well.
He
founded
a
company
doing
security
and
is
also
running
a
conference
called
troopers,
which
was
last
week
in
Germany
in
either
Berg
I
was
speaking
there
very
nice
conference.
So
with
this
and
many
many
idiotic
people
that
has
reviewed
the
document,
sometimes
quickly,
sometimes
more
profound
I
see
some
of
them
in
the
room
here.
C
So
thank
you
again
and
just
to
give
you
a
long
long
history
of
this
document
right.
It
started
as
a
individual
document
in
2012
six
years
ago
and
I
to
put
history
in
two
lines
visiting
so
a
long
long
time,
I
saw
Co.
Quite
a
long
to
the
change
from
12
to
13
is
mainly
about
100
changes,
growth,
many
by
an
array
able
to
come
here
today
by
the
way
wrong.
You
propose
one
or
two
and
wouldn't
have
proposed,
or
so
many
many
as
well
as
a
few
others.
C
We
fixed
all
the
text
using
common
sense,
but
there
are
two
issue
brought
up
by
Elaine
and
maybe
others
that
I
think
we
need
to
work
as
a
working
group.
There
remember
the
structure
of
this
document
is
the
forming
general
consideration,
which
are
basically
what
about
a
pv6.
That's,
where
do
we
need
to
fix
I?
Think
two
points,
then
something
which
is
specific
for
enterprise,
something
specific
or
service
provider
and
something
specific
for
Oh
music.
C
If
you
look
about
this
section
about
general
security,
you
see
couple
of
points
and
those
two
points
are
the
one
I
want
to
talk
with
you
today
or
on
a
meaningless
later.
The
addressing
consideration
needs
to
talk
on
ula
when
I
talk
to
customers
or
other
people.
They
always
come
to
me
a
Eric.
What
about
ula?
So
we
need
to
read
a
section
on
ula
in
this
document
and
of
course,
transition.
We
talked
about
Tina's
even
and
we
can
say
tuners
a
thing
of
the
past.
C
We
still
a
ipv4
as
a
service
or
garner
PVCs
right,
so
channels
will
stay
here.
So
don't
kill
me
right,
but
let's
talk
about
you
awake
and
it
is
basically
for
paragraph
and
I
hope
it
can
see.
Sender.
Can
you
read
this
on
the
back?
Okay,
so
I
put
the
text
all
day
on
one
side
just
to
get
a
change
right
if
he
spoke
right,
so
you're
a
I
intended
for
scenarios
where
I
can
resist
and
globally
reachable.
Despite
my
family
evening,
a
global
scope
indeed
assumed
to
be
unique.
C
The
Manasa
P
in
the
routing
system,
also
democracies
domain,
where
the
considered
valid
first
statement
with
an
insecurity
impact
in
blue,
therefore
pockets
with
you
sauce
or
the
season
address,
must
be
fitted
at
the
domain.
Boundary
I
think
this
one
is
pretty
loose.
Yeah
I
see
nobody
frankly,
disagree.
D
C
D
F
F
F
I
F
E
Insecure,
you
know
it
has
to
be
a
source
or
destination
because
otherwise,
if
if
you
forget
to
drop
stuff
with
the
ula
source,
inbound
I
can
send
packets
of
pretending
to
be
inside.
Your
network
and
I
can
bounce
between
two
hosts
on
your
network
and
send
the
other
hosts
arbitrary
packets
and
they
think
they
come
from
inside,
and
this
is
just
like
a
bad
idea,
so
it
has
to
be
source
or
destination.
G
J
K
L
C
I
mean
it's
is
part
of
the
RFC
right,
don't
think
it
works
perfect,
easy
way.
You
will.
Let
me
be
used
for
internal
communication
in
conjunction
with
globally
reachable
unicast
address.
You
are
for
us
that
also
require
external
connectivity
through
a
firewall,
so
meaning
the
austere
circuit.
If
you
are
to
go
outside
and
you
LA
on
the
inside.
For
this
reason,
no
form
of
address
translation
is
requiring
conjunction
with
ul
ace.
When
you
use,
you
are
I
put
it
in
green
because
I,
don't
want
to
say
translation.
M
M
E
Well
so
Renzo
Khalidi,
we
like
I,
don't
know
how
many
years
ago
it
was
that
this
draft
went
to
v6
office
and
that
and
that
text
was
torn
apart
and
the
consensus
on
I
think
definitely
in
the
room
and
I
think
also
even
on
the
v6
ops.
Mailing
list
was
that
we
should
instead
say
that
the
this
form
of
only
deployment
is
unspecified
and
not
recommended.
E
I
In
China
you
could
look
at
the
I
mean
this
comes
up
in
so
many
places,
and
this
draft
is
7
years
old
as
the
answer.
So
it's
in
the
enterprise
deployment
RFC
it's
in
the
ula
usage
considerations.
Draft
that's
been
hanging
around
probably
for
about
seven
years
as
well,
and
you
just
can't
get
consensus
on
it.
If
you
suggest
or
imply
that
running
MPTV
six
is
a
good
thing.
K
Already
said
it
right
so
I,
you
know
these
were
supposed
to
be.
No,
no,
no,
no
I'm
find.
If
the
language
is
it's
sorry,
Lee
Howard,
I'm,
fine
with
the
language
as
it
stands,
I
think
that
it
doesn't
imply
that
the
on
alternative
doesn't
exist
or
is
it
used?
It's
just
saying
it's
not
the
the
use
of
ula
does
not
imply
err.
The
use
of
prefix
translation,
I.
Think
that's
what
it
says.
I
think.
That's
all.
It
needs
to
say.
C
C
The
minister,
sorry,
okay,
hey,
we
may
not
got
the
draft
on
this
run
right.
We
said
the
rough
consensus
very
rough
in
this
case
and
then
the
other
one
is
basically
saying
the
last
one
using
your
lay
described
here
might
simplify
the
filtering
rules
meeting
at
the
domain
boundary
by
renewing
a
regime
in
which
O'neill's
that
we
try
external
connectivity,
processor
globally,
reachable
address.
However,
it
does
not
remove
the
need
for
careful
design
of
the
filtering
rules
of
you.
C
C
We
still
have
text
on
canals
that
do
not
really
exist
anymore,
like
the
radio
or
6
to
4,
but
an
Elaine
Karen
of
six
man
once
removed
the
text
on
six
to
four
and
Teredo
on
my
side
and
on
all
the
three
other
authors
of
this
document.
We
do
believe
that
people
reading
and
starting
to
understand
the
physics
security
of
those
questions
in
mind.
So
we
need
to
keep
the
test
even
if
it's
kind
of
useful
and
the
text
is
pretty
clear.
C
C
C
E
Delay
you
even
further,
but
since
this
draft
was
written
so
many
years
ago,
the
consensus
and
addressing
practice
best
practices
of
bench
has
changed,
and
so
you
have
some
text
about
disabling
dhcpv6
and
disabling
privacy.
Addresses
and
vv6
of
these
images.
Oh
s-sorry,
disabling
slack
and
enabling
HP
v6
only
needs
to
say
that
the
best
practice
that
this
is
not
recommended,
because
it's
the
best
practice
that
it's
not
recommended
seven
nights
before
also.
It
says
that
ipv6
addresses
are
assigned
based
on
MAC
address
using
UI
64.
That's
deprecated,
not
true
anymore.
E
C
E
Right,
yes,
right
here
in
front
of
me
and
disabling
privacy
addresses
is
pretty
silly
I.
Think
for
this
purpose,
because
the
document
really
needs
to
say
something
about
layer,
2,
filtering
and
how
you
can
have
lay
through
security
without
layer,
2
filtering-
and
you
know,
if
you're
not
using
savvy,
then
it
doesn't
matter.
If
you
use
dhcpv6
static
slack,
you
have
a
hole,
that's
wide
enough
to
drive
truck
through
and
the
don't.
C
E
E
Don't
need
this
if
you're
doing
savvy,
then
you
don't
need
to
disable
the
then
you
don't
need
to
disable
slack
figure
savvy.
Is
it
can
contract
this?
This
is
all
written
by
the
way
it's
all
written
in
7,
9,
3,
4,
section
9.1,
so
I
guess
what
I
wouldn't
write
or
what
I
guess
I'm
trying
to
say
is
section
2.1
for
needs
an
overhaul,
2.15
2.1
at
6:00
yeah,
so
that
that
part
needs
to
overhaul.
Okay,
thank.
I
You
for
attention,
doctor
do
ya
know:
I
was
gonna,
say
some
similar
things
so
yeah
eighty
64
is
mentioned,
and
it
just
implies
that
you
can
use
72
one
seven,
where
in
fact
it's
recommended
that
you
should
now
I
believe
I,
don't
think
you
cite
79
34,
it's
cool,
so
you're,
not
talking
about
multiple
addresses
and
the
topic
that
I
get
from
admins
in
my
sphere
is
gosh.
With
all
these
addresses.
How
do
I
account
for
the
use
of
these
addresses
so
I
think
a
section
on
address
accountability.
I
C
G
G
N
K,
oh
yeah
I
was
frantically
taking
notes.
I
came
in
a
little
late
just
so
that
I
can
capture
everything
that
lens
or
nobody
else
was
saying
to
me.
It's
clear
that,
whatever
we
say
in
your
lay
there's
going
to
be
factions,
we're
not
going
to
be
happy
with
it,
so
we're
going
to
have
to
figure
out
what
both
consensus
is
yeah,
but
but
I
do
think
that
at
least
the
ERC's
and
the
language,
what
what's
more
right
from
what
we
had
created
in
the
past?
N
Absolutely
we
need
to
make
the
changes
of
so,
if
some
of
you
could
just
say,
even
just
the
pointers
to
a
paragraph
just
say
at
this
point
at
this
paragraph
from
this
RFC
to
the
mailing
list.
Right
then
at
least
Eric
and
I,
and
maybe
somebody
another
author
can
capture
that,
and
we
can,
you
know,
make
it
easier.
Okay,.
G
I
O
I
I
A
A
P
C
Q
S
Good
afternoon
my
name
is
freedom,
and
this
is
joint
work
with
that
Montgomery
who's
here
and
also
Jeff
has
so.
This
is
about
enhanced,
feasible
path.
Filtering
I
have
like
Eric
mentioned.
I
have
talked
about
it
a
couple
of
times
before
it
got
a
lot
of
good
feedback,
and
based
on
that,
we
have
been
updating
the
draft
so
quickly.
The
idea
here
is
that
strict,
your
your
PF
is
not
very
effective.
Those,
so
that
is
effective.
Only
in
limited
scenarios
lose
your.
If
is
generally
not
very
effective
and
feasible
path.
S
What
happens
is
that
the
the
very
feasible
path
is
correctly
defined.
The
ISP
or
the
network
provider
is
afraid
that
they
may
be
denying
legitimate
traffic
from
their
customers,
so
that
that
does
happen
when
there
is
multihoming
and
asymmetric
routing.
So
the
what
we
are
trying
to
do
here
is
to
enhance
the
feasible
path
you
RPF
and,
and
the
idea
behind
that
is
to
try
to
see
if
we
can
encourage
deployment
with
the
making
feasible
path
you
RPF
more
attractive,
more
efficient
in
terms
of
how
it
works.
S
S
S
So
you
look
at
all
your
customer
interfaces
and
look
at
all
the
routes
received
on
customer
interfaces
make
the
list
of
a
unique
list
of
origin,
a
SS
that
appear
in
those
routes
and
then
take
one
of
those
areas
and
ask
the
question
for
this
as
the
origin
areas.
What
are
all
the
routes
that
I
have
on
any
of
the
edge
ribbons
and
you
take
that
list
of
prefixes
and
then,
whenever
you
see
that
you
have
the
same
origin,
a
s
on
any
of
your
customer
prefixes
apply
all
the
prefixes
for
that
origin
areas.
S
If
you
received
one
prefix
with
a
certain
origin,
a
s
on
a
customer
interface,
then
any
other
prefixes
that
you
received
on
any
of
the
other
interfaces.
With
the
same
origin,
is
you
apply
them
to
that
customer
interface
it'll
become
easier
if
we
go
through
some
examples
to
try
to
grasp
that
it's
very
fairly
simple.
So
this
is
a
basic
scenario
where
s
1
is
a
color
is
MIT
home,
the
customer
s
2
and
s.
3
are
two
transit
providers.
S
A
s1
originates
two
subnets
p1
p2,
and
it
announces
only
p1
towards
s2
and
only
p2
towards
s1.
So
in
this
case,
what
the
problem
that
we
are
trying
to
solve
is
that
there
can
be
data
packets
from
a
s1
towards
a
s2
with
source
address
in
p2,
vice
versa
for
s3.
So
we
want
to
be
tolerant
to
that
and
in
order
to
be
able
to
do
that,
we
simply
look
at
that
customer
interfaces
and
we
figure
out
that
we
have
two
prefixes
p1
p2,
both
of
which
have
a
common
origin,
a
s1.
S
S
Both
I'll
include
them
in
the
RTF
list
and
by
doing
that,
I'm
offering
the
flexibility
of
accepting
all
data
source
data,
packets
from
a
s1
with
a
source
address
in
p1
or
p2,
and
it's
and
in
this
case
the
feasible
path
doesn't
work
because
they
are
not
following
the
recommendation
in
PC
p84,
that
is
to
say
that
each
of
your
prefixes,
you
should
announce
it
to
each
of
your
transit
providers.
They
are
not
doing
that
in
the
next
example.
S
They
are
doing
that
they
are
announcing
each
of
their
prefixes
to
each
of
their
transit
provider
with
repenting
in
order
to
depress
second
routes
and
in
this
case,
feasible
path,
also
works,
and
all
of
these
three
nosepiece
is
feasible
path
or
enhanced.
They
all
work
fine.
Now,
let's
look
at
more
interesting
scenarios.
S
S
3
are
customers
of
a
s
4
so
in
this
again
is
for
applies
the
enhanced,
feasible
path
algorithm
and
it
figures
out
that
I
am
looking
at
this
s,
1,
which
is
a
common
origin,
a
s
between
these
three
prefixes
I.
Look
at
P,
1
I
got
a
prefix
on
this
customer
interface
towards
a
s
2
with
a
origin,
a
s
1
so
now,
I
can
I
would
also
add
p2
and
p3
to
that
interface
because
they
have
the
same
origin
alias.
S
To
the
feasible
path-
and
then
dot
pointed
out
this
interesting
challenging
scenario
in
back
in
Prague,
and
here
what
is
happening
is
that
now
a
s1
puts
no
export.
It
announces
p1
p2
both
to
s2
as
well
as
a
s3,
but
it
puts
no
export
so
when
from
a
s
to
a
p1,
p2
don't
propagate
to
a
s4,
but
they
do
propagate
from
s3
to
s4.
So
again,
so
in
this
case
it
doesn't
work.
S
Even
the
enhanced,
feasible
path,
algorithm
a
doesn't
work
because
it
doesn't
get
any
doubts
on
the
interface
from
a
s2,
and
so
basically
it
is
found
of
routes,
and
it
cannot
apply
that
that
logic
that
that
is
part
of
the
enhanced
feasible
path.
So
we
get
went
back
and
thought
about
it
and
then
came
up
with
an
algorithm
B
so,
depending
on
whether
the
operator
decides
that
they
have
the
list
challenging
scenario
such
as
a
scenario
one
or
the
more
challenging
scenarios,
such
as
scenario
2.
Here
they
can,
if
they,
if
they
think.
So.
S
If
you
have
scenario
one
type
of
situation,
they
can
apply
algorithm
a
and
it
would
be
fine.
And
if
it
is
scenario
2
that
that's
likely
to
be
applicable
in
their
customer
corner,
they
would
use
algorithm,
B,
algorithm,
B
generalizes,
the
the
the
algorithm
a
further.
It
makes
it
more
a
bit
more
relaxed
and
and
by
doing
that,
it
meets
the
challenge.
So
the
idea
is
that
the
P,
so
this
is
the
formal
algorithm.
Let
me
go
to
the
example
to
try
to
explain
how
the
algorithm
works.
S
So
so
we
have
this
scenario,
including
the
the
challenging
part
in
which
there
is
no
export
on
the
left
side.
So
the
other
way
the
algorithm
works
is
that
it
looks
at
all
the
interfaces
customer
interfaces.
There
are
two
in
this
case
and
if
it
makes
a
list
of
all
the
prefixes
that
were
received
on
those
interfaces
which
in
this
case
is
p1
p2
p3,
let's
call
that
the
list
P
and
then
it
makes
a
list
of
all
the
audit
analysis
that
we
received
on
interfaces
on
routes
received
on
the
customer
interfaces.
S
So
in
this
case,
the
there
are
two
origin
interfaces,
a
s1
and
the
s2,
and
then
at
that
point
it
looks
for
any
other
prefixes
that
we
received
of
our
routes
that
we
received
from
a
peer
or
a
provider
which
might
have
one
of
those
origin
a
SS.
So
so
so
by
doing
that,
what
it
is
trying
to
say
is
that
I
might
not
receive
some
of
these
prefixes
on
my
customer
interfaces.
But.
S
S
It's
taking
the
union
of
the
P
and
the
Q,
the
Q
being
the
set
of
prefixes,
unique
prefixes
that
exact
umming
from
fears
or
providers
which
happen
to
have
origin
areas
that
is
in
the
set
of
a
SS
that
are
represented
on
its
customer
interfaces,
and
now
it
generously
adds
P
and
Q
makes
the
union
of
P
and
Q
and
that's
what
it
applies
to
all
the
customer
interfaces.
So
in
this
case
it
is
able
to
meet
the
challenge
so
to
say
and
P
1
P,
2,
P,
3
and
P
4.
H
S
Thank
you.
So
this
is
so
the
question
came
up
like
okay,
what
kind
of
requirement
that
does
it
impose
on
the
paper,
and
we
make
some
estimates
of
the
the
worst
case
for
four
different
sized
ISPs,
and
then
we
compare
it
with
what
kind
of
ribs
memory
size
is
available
and,
as
you
can
see,
compared
to
their
this
slide,
the
next
slide
the
available
fit
memory
size
is
ordered,
I
mean
order
or
two
orders
of
magnitude
larger.
So
that's
the
that
is
pretty
good,
so
it's
not
a
significant
increase
in
the
fifth.
S
So
this
is
my
final
slide.
So
I
wouldn't
I
mean
all
I
said
like
what
eyes
like
like
I
said
before
there
are
these
two
scenarios
they're
not
so
challenging,
and
the
challenging
and
algorithm
a
works
for
they're,
not
so
challenging
and
algorithm
B
would
work
for
the
challenging
type
of
scenario.
Thank
you.
Questions.
F
Marilla
for
Deutsche
Telekom,
first
on
your
first
slide,
I
think
your
definition
should
clearly
say
yeah
that
you
are
oh
yeah,
okay,
you
did
it
I,
just
I
just
lost
the
word
for
did
you
consider?
Did
you
consider
how
the
use
of
various
any
cos
routing
schemes
actually
interacts
with
what
you're
proposing.
T
F
F
Kind
of
kind
of
for
the
old
arguments
are
essentially
arguing
in
this.
The
state
of
a
routing
system.
Whenever
you
have
changes
a
failover
I
would
guess
that
the
intermediate
States
will
have
packet
losses,
yes,
and
in
some
cases
that
may
be
negligible.
In
other
cases,
it
may
be
actually
pretty
pretty
bad.
Is.
F
Strict
with
strict
with
with
with
the
strict
kind
of
kind
of
you
never
would
would
use
that
in
cases
were
you
depend
on
no
packet
losses.
No,
and
so
that's
not
really
a
relevant
question,
I
think
and
a
kind
of
in
general
in
general.
Looking
at
a
couple
of
decades
of
evolvement
of
routing
system,
I
I
see
that
for
something
like
20
years,
nobody
cared
about
the
transient
states
and
they
the
view
result
in
packet
losses
and
while
okay,
we
got,
we
got
a
little
bit
better
and
for
any
new
proposal.
Q
J
J
J
The
here's
what
we
see
as
a
problem
in
the
bgp
level,
if
you
think
about
the
internal
scheme
of
things,
if
you
have
some
sort
of
internal
routing,
that
information
is
also
present
and
can
contribute
to
this
exact
same
list.
So
there
there
are
other
possibilities
to
further
seed
things
that
are
not.
You
know
directly
up
your
same
interface.
This
is
a
way
of
injecting
initial
information.
So
that's
that's
a
first
thing.
The
second
thing
is
you're
correct.
In
terms
of
do
we
really
want
the
do
this
stuff
real
time?
I'm
gonna
tell
you.
J
We
could
not
do
this
algorithm
real
time.
It
is
big
and
messy
and
there's
a
lot
of
state
to
do
here,
but
in
terms
of
is
it
know
from
a
functionally
correct
point.
Yes,
so
that's
the
goal
that
we're
currently
working
towards
is
functional
correctness.
Implementations
will
have
to
have
hysteresis
memory.
You
want
to
eventually
have
it
arrive
at
the
correct
filters
that
are
good
enough
for
a
computer
type
and
you're
not
going
to
try
to
update
them
super
real-time
and
as
long
as
you're,
not
trying
to
do
that.
J
U
Little
bit
of
a
combined,
so
obviously
you
guys
are
doing
a
great
work
in
terms
of
you're
in
the
right
space.
Security
is
very
important
and
PC
PC
g8
doesn't
really
work
for
complex
systems.
Just
a
few
comments
on
the
approach
here,
one
is
so
obvious:
algorithm
2
does
not
is
not
going
to
apply
to
bid
networks
that
have
many
customers,
because
essentially
it's
come
to
NOAA.
U
It's
also
limited
to
cases
where.
So,
if
you
have
a
peer
that
basically
did
not
receive
advertised
announcement
from
another
peer
that
peer
was
still
block
you
right
and
the
third
comment
about
it
is
that
so
we
said
that.
Well,
if
you
want
to
deprioritize,
just
do
a
prepend
and
it's
a
different
AAS
system.
U
It
might
not
work.
You
might
still
get
quite
a
bit
of
traffic
that
way.
So
one
of
the
things
we
find
is
that
if
we
will
not
be
absolutely
sure
that
we
do
not
get
traffic
on
a
particular
link,
you
do
not
advertise
and
some
set
of
course,
more
cases
where
it
doesn't
completely
work.
Last
thing
is
that
she's
gonna
say
that
I'm
gonna
have
a
talk.
A
talk
tomorrow
in
RT
g
WG
are
trying
to
solve.
Basically,
this
very
similar
problem,
maybe
in
a
slightly
different
way.
So
we'll
talk
more.
Thank
you.
So.
S
U
I
mean
it's.
The
biggest
problem
we
filed
is
that
it's.
If
we
try
to
do
something
interesting
in
terms
of
traffic
engineering,
we
could
have
a
conversation
with
our
partners,
but
then,
depending
on
how
many
up
streams
and
piers
they
have,
they
may
be
more
reluctant
to
do
any
sort
of
allowances
because
it
becomes
harder
for
them
to
do
it.
So
anything
that
will
help
in
that
area
is
thumbs
up
and
I,
really
don't
care
about
the
particulars
of
implementations
or
any
things.
That's
in
this
area,
I
think
it's
very
important
area
to
work
out.
V
Hi
hi
Jared
mark
Akamai
recovering
a
backbone
operator.
Maybe
so
so
so
one
of
my
concerns,
you
know
just
about
some
of
the
data
later
on
in
the
slides,
for
you
know
the
the
the
fib
scale
and
whatnot.
Is
that
often
we're
looking
at
yeah?
If
you
have
this
slide,
you
know
if
you
know
the
often,
when
you're
looking
at
service
providers,
many
people
are
trying
to
shove
their
fib
table
inside
of
what
are
functionally
switches
and
based
on
the
Broadcom
chipsets,
based
on
what
they
have
available
when
you're
going
and
you're.
V
Looking
at
this,
you
know
a
large.
You
know
when
you
say
a
very
large
global
isp.
Anyone
who
really
falls
into
that
category
has
a
customer
cone,
that's
greater
than
128
thousand
prefixes,
and
that
includes
common
folks.
Like
my
former
employer
Telia,
you
know
and
and
the
list
goes
on,
you
know
you,
you
know
you
go
and
you
look
at
them
and
somebody
like
hurricane
sorry,
not
Hurricane.
Electric
level
3
has
course
too
close
to
a
quarter
million
prefixes
in
just
in
their
customer
comb,
trying
to
go
and
do
an
algorithm.
V
Didn't
make
it
clear
you
have
not
targeting
them
because
you
have
to
say
the
numbers,
but
it's
shorter,
but
the
one
the
one
point
I
want
to
make
is
that
if
you're
not
targeting
them,
the
issue
here
is
the
average.
A
s
path.
Length
has
shortened
significantly
as
rüdiger
mentioned
over
the
past
20
years,
and
the
core
tends
to
be
more
densely
interconnected
than
ever
was.
So.
V
J
J
Specifically
to
jerd
actual
implementation,
you're
absolutely
right-
and
the
goal
of
this
is
not
to
say
this-
can
be
done
right
now,
with
current
hardware
is
to
say
with
a
solution
that
is
correct,
looks
like
know
whether
you
can
deploy
that's
a
different
question,
then,
after
that,
can
you
deploy
it
successfully
and
smaller
things?
The
further
you
get
away
from
Skinner
core?
More
likely
you
are
to
be
able
to
get
there
you're
absolutely
correct.
We
stood
a
decision
here
if.
C
You
don't
mind:
it
was
15
minutes
allocated.
We
already
25
I,
think
it's
a
pretty
dense
decision.
So
there's
a
reason
why
and
useful
efficient.
That
is
why
we
let
it
go,
but
a
support
of
time
we
needs
to
stop
I.
Think
is
to
prove
that
is
an
interest
of
the
working
group.
So
I
say
you
were
working.
You
wanted
to
get
this
document
adopt.
It
is
a
working
room
document.
So
looks
like
it
should
based
on
the
discussion
here.
We
will
ask
it
on
the.
Why
not
Methodist
were
that
client.
J
C
C
H
C
C
W
Can
I
go
ahead
and
get
started
since
we're
running
long
time?
Yep?
Okay!
So
thank
you,
Eric
and
the
chairs
for
inviting
us
to
present
this.
So
we
have
a
draft
that
talks
about
the
implications
of
the
current
set
of
network
security
solutions,
as
we
understand
them
the
implications
of
what
will
occur.
What
can
occur
as
we
transition
into
TLS,
1.3
and
transition
is,
is
the
highlight
here.
Okay,
so.
W
Basically,
what
do
the
network
security
solutions
do
today?
They're
there
to
provide
auditing
monitoring
functions
as
well
as
access
control
and
security
controls,
and
so
security
controls
fall
into
the
area
of
beyond
the
access
and
why
we
split
them
a
little
separately.
The
security
controls
goes
towards
not
just
compliance
metrics,
and
some
of
you
may
already
be
aware
of
this,
but
to
provide
firewall
all
the
way
to
intrusion,
detection
and
intrusion
prevention.
W
W
Or
they're
being
proactive
and
I'll
describe
what
we
mean
by
by
proactive
they're,
so
redundantly
you'll
see
in
some
of
our
diagrams.
We
refer
to
them
as
middle
boxes,
but
in
the
actual
flow
diagrams
we
call
them
out
as
helix
proxies
proxies
from
the
notion
of
especially
when
they're
being
active.
If
you
will,
in
that
sense,
they'll
act
as
a
proxy
meaning
from
the
TLS
client,
the
proxy
will
act
as
TLS
server
and
then
to
the
actual
TLS
server.
The
proxy
will
act
as
the
TLS
Connie,
okay,
okay.
W
W
Okay,
so
I'm
not
going
to
in
the
interest
of
time,
call
out
each
and
every
one
of
the
use
cases,
but
they
are
enumerated
and
there's
more
description
in
the
actual
draft.
But,
as
you
can
see
from
the
outbound
case,
we've
tried
to
enumerate
them
and
if
I
were
to
just
do
the
general
categorization,
a
lot
of
them
go
towards
again
policy
decisions,
whether
it's
for
access
control
or
from
a
security
perspective,
especially
down
as
we
get
to
looking
at
posture
and
compliance.
W
W
Those
use
cases
again,
they're
very
from
a
general
category.
They're
very
similar
from
a
standpoint
of
what
we're
trying
to
do
is
protect
the
data
resources
in
your
administrative,
the
being,
which
is
why
we've
called
out
some
of
the
use
cases
there.
The
other
one
that
we've
been
hearing
requests
for,
which
we've
listed
in
the
bottom
and
again
this
gets
to
the
auditing
and
compliance,
and
that
is
from
a
cryptographic
perspective
on
doing
the
crypto
security
of
it.
W
W
Inspecting
and
gleaning
as
much
information
as
it
can,
while
the
TLS
session
is
being
established
so
today
up
to
TLS
1.2
most
of
the
information,
the
identities,
the
negotiation
of
the
versions,
as
well
as
the
cipher
suites,
do
come
in
clear
text,
they're
not
encrypted
yet
and
so
from
there.
The
policies
can
make
the
early
decision
and
before
that
tunnel
is
actually
established,
whether
and
how
that
access
control
may
get
affected.
Okay,.
W
In
the
actual
proxy
or
what
I'm
calling
an
active
State,
the
middle
box
is
really
acting
as
that
proxy
meaning
as
a
TLS
server
to
the
client
or
as
client
to
the
TLS
server,
and
so
in
here.
It
can
still
do
the
inspection,
because
the
information
is
in
clear-text,
but
now
what
it's
going
to
do?
Is
it's
actually
going
to
get
an
active
or
have
the
ability
to
encrypt
and
decrypt
the
application
data,
if
you
will
so
that
it
can
further
do
deeper
inspection
of
the
data
for
doing
things
like
application
level,
intrusion,
detection,
okay?
W
X
X
W
Okay,
so
basically,
there
is
a
draft
there
that
is
proposing
that
we
obscure,
even
than
we
client
hello,
the
server
identification
which
can
become
an
issue
on
the
other
ones.
That
I'll
call
out
is
in
TLS,
1.3
they've
optimized,
the
number
of
handshakes
they
achieve
this
by
effectively
compressing
in
the
server
hello
and
all
of
the
other
messages.
They
begin
to
encrypt
the
messaging
there,
including
the
information
of
the
server
the
server
certificate,
basically
so
effectively.
W
W
It's
in
the
draft,
the
summary
here
basically
I,
think
I've
already
stated
because
of
the
obscurities,
especially
during
the
handshakes.
It
will
be
much
harder
for
us
to
make
decisions
on
the
initial
access
control,
even
on
the
resumption,
as
well
as
the
security
controls
leading
up
to
the
intrusion
detection
capabilities.
So
this
is
the
example
for
the
outbound
and
again
highlighting
the
the
one
that
I
wanted
to
call
out.
The
encrypted
is
a
draft
right
now
that
hasn't
been
adopted,
but
we
wanted
to
highlight
here:
I,
don't
think
it
was
Christians
draft
okay.
Y
Z
H
AB
X
Is
it
yeah,
it's
very
short,
Q&A,
no
discution
to
Metro?
Okay,
my
name
is
Tim.
This
draft
is
riddled
with
inaccuracies.
There's
many
places
where
it
makes
assertions
or
things
are
impossible,
which
are
just
not
true.
There
are
ways
we
own
things.
So,
for
example,
you
claim
that
you
can
no
longer
kind
of
see
what
somebody's
using
edit
eight
certificates.
You
can
easily
survey
servers
in
the
network,
etc.
It's
at
the
list
of
a
long
list,
a
longish
list
of
enoch
creases.
Here
then
also
I'm
kind
of
curious
about
the
point
of
this
practice.
X
W
Was
requested
that
we
put
out
how
network
security
solutions
are
behaving
today,
so
all
I'm
trying
to
do
is
articulate
the
behavior
of
security
solutions.
Today,
I'm
not
saying
TLS
1.3
is
bad.
All
I'm
trying
to
state
here
is
it's
actually
good.
Well,
I,
anyway,
you're
quoting
that
I
have
inaccuracies
in
the
draft
I.
You
know,
we've
discussed
some
of
those
I,
don't
see
how
they're
inaccurate,
because
I
tried
to
quote
some.
W
But
anyway,
my
point
is
I.
Did
this
because
it
was
requested,
all
we're
trying
to
show
is
there's
going
to
be
a
transition
period.
Okay,
in
the
notion
of
how,
as
network
security
solutions
evolve,
we
now
have
to
account
for
how
do
we
deal
with
the
fact
that
we're
going
to
have
clients
that
can
only
support
one
got
through
two
I'm,
not
sure
if
clients
moving
forward
in
the
IOT
case,
those
clients
are
going
to
take
a
long
time
if
they
get
upgraded
at
all
the
TLS
1.3.
Ok,.
X
So
again,
I
think
it
would
be
interesting
to
describe
the
network
security
things.
People
do
I,
think
the
idea
of
kind
of
at
the
end
of
each
section
of
trying
to
do
that
say
here's.
Why
idea?
That's
one
point:
three
is
bad,
which
is
how
I
read
what
you've
written
is
not
a
good
idea.
I,
don't
think
the
existence
would
verify
that
is
useful.
X
AC
H
AC
The
draft
is
to
try
to
understand
what
are
the
implications
of
TLS
1.3
to
network
based
security
solutions.
That's
what
we
try
to
highlight
if
there
are
inaccuracies
in
there,
let's
get
them
corrected.
If
you're
saying
all
of
these
issues
that
we
call
out,
they
are
solvable
by
all
means,
that's
argument
how
we
solve
them.
That
is
the
purpose
of
this
draft
and
we
welcome
any
help
we
can
get.
But
we
haven't
gotten
healthier.
Okay,.
K
Yes
finish
very
quickly:
three
short
PC
Howard
I
haven't
had
a
full
comparison
between
the
two
documents
but
I
think
there's
some
overlap
with
the
draft
mm
WG
effect
encrypt,
which
is
right
so
and
I.
Think
there
and
I
didn't
see
a
reference
to
that
drives
at
all.
I.
Think
that
says
there
is
some
overlap.
We
had
there
at
least
ought
to
be
a
reference.
Okay,.
AD
Would
actually
deploy
that
sort
of
thing
because
it
completely
compromises
security
with
certain
cipher
suites?
So
that's
a
that's
a
real
concern,
so
I.
The
meta
point,
though,
is
why
is
this
known
in
Taylors?
Why
we
not
having
these
presentation
in
Taylors,
because
this
is
directly
relevant
to
that
group?
I.
W
C
C
AE
AE
First
of
all,
I
will
make
a
short
introduction
to
blockchain
and
Bitcoin
for
those
who
are
not
familiar
with
it,
and
then
I
will
explain
it.
How
it
would
be
useful
to
store
IP
addresses.
I
will
try
to
discuss
some
considerations
regarding
operational
considerations.
I
will
end
up
with
some
data
on
our
prototype.
So,
first
of
all,
what
chain
blockchain
very
short,
is
a
decentralized,
secure
and
trans
database,
so
you
can
see
it
as
a
token
tracking
system
so
a
way
to
know
who
has
worked.
AE
It's
built
adding
blocks
of
data
one
after
another
and
it's
protected
by
two
mechanisms:
tenure
signatures
which
ensures
the
ownership
of
the
data,
tokens
and
contention
which
ensures
an
infinity
of
the
data.
So,
as
you
know,
the
first
one
ever
will
Bitcoin
it's
computed
to
change
money
between
two
parties.
You
don't
need
any
intermediary,
but
our
applications
are
possible.
So
it
was
like
we
summarized
briefly
how
blockchain
works.
So
the
basic
unit
of
a
blockchain,
all
transactions
transaction
has
three
elements:
the
adapter,
the
sender,
signature
and
the
public
is
ready.
AE
So
when
you
want
to
add
any
interaction,
you
broadcast
it
to
build
up.
Your
network
at
some
level
interesting
time
design,
note
electronic
transactions
acts
them
into
a
block
completely
with
Ponte
jogger
rhythm
and
turns
the
clock
back
to
the
network.
All
the
nodes
in
the
network
receive
this
block,
they
verify
the
transactions
and
the
constants
are
real
and
if
they
are
K,
they
add
the
new
block
to
the
chain,
since
the
blocks
are
linked
it
one
after
another,
with
a
rush,
that's
why
they
are
called
Scott
the
blockchain.
AE
So
this
is
my
present
summary
of
the
features
of
blockchain
compared
to
traditional
PK
systems.
So
advantages
is
that
it
is
a
centralized.
So
there
is,
no
hierarchy
is
only
certification
authorities
which
makes
management
more
simple,
making
it
also
very
simple:
you
need
a
limited
private
trust,
it's
a
regular
because
you
have
a
history
of
all
the
transactions
and
its
censorship
resistant,
because
I
did
data
can
be
modified
and,
of
course,
it
has
also
some
drawbacks.
The
first
one
being
that
you
don't
have
crypto
is
like
in
a
PCI.
AE
It
really
depends
on
the
behavior
of
its
participants.
It
was
really
positive
starts
because
the
blood
chain
keeps
always
growing,
which
also
makes
strapping
costly,
because
you
have
to
do
a
lot
on
the
blockchain
so
how
this
work
for
IP
addresses.
So
basically,
we
want
to
store
three
things
in
the
blockchain
who
holds
an
IP
address
and
it's
public
key,
the
chain
of
locations
and
allegations
of
IP
addresses
and
the
binding
of
these
prefixes
to
a
is
numbers.
AE
So
why
boxing
must
do
question?
We
can
see
IP
addresses
as
quaint.
They
are
not
exactly
equal,
but
they
share
some
similar
properties,
so
they
are
unique.
I
can
to
people
who
have
the
same
ideas.
They
are
transferrable.
I
can
send
a
message
to
some
someone
else
and
then
tip
is
evil,
because
I
can
spit
perfect
of
IP
addresses
and
allocated
channel
to
if
an
entity.
So
we
can
see
this
idea
as
a
means
of
sending
IP
addresses
to
our
people
like
in
Bitcoin.
You
send
money
to
our
people,
so
quick
example.
AE
So
this
mocking
would
start
with
a
Jana
Jana
right
attendance
block,
which
is
the
first
one
saying
I
have
all
the
prefixes.
Then
it
starts
on
locating
prefixes
to
the
resistance,
and
then
the
registers
allocate
prefixes
to
its
customers
like,
for
example,
an
isp
and
finally,
an
asp
as
a
transaction
binding.
It's
a
perfect,
it's
a
guest
number.
AE
So
I
don't
know
how
I'm
buying
in
time
five
minutes
five
minutes.
Okay,
perfect
suppression
of
considerations
so
in
between
there
is
no
application.
So
that
means,
if
you
lose
your
keys,
you
lost
your
money.
It
has
already
happened,
but
we
will
leave
that
in
our
scenario.
If
you
want
to
store
IP
addresses,
this
does
not
make
sense
because
IP,
as
you
said,
they
are
finite.
AE
So
Bailey
between
two
scenarios
in
a
traditional
PID,
the
centralized
control
and
in
big,
is
totally
decentralized.
But
in
our
use
case
we
think
that
the
best
situation
would
be
a
middle
ground.
So
in
other
words,
I,
don't
want
any
acting
registry
relocating
my
prefixes
arbitrarily
at
any
time,
but
I
want
to
leave
the
door
open
because
at
some
point
in
time,
I
may
have
a
problem
and
I
want
to
fix
it
and
to
solve
this,
there
are
some
possible
alternatives.
AE
AE
So
a
blockchain
is
a
public
ledger.
Anyone
can
access
it,
so
we
have
mass
district,
which
information
do
we
need?
So
our
vision
is
that
in
the
blockchain
you
should
only
have
the
pairs
of
prefixes
and
public
keys
and
any
private
data
like
business
relationships.
Internal
registry
policies
should
be
kept.
Private
and
changes
in
his
policies
should
only
be
reflected
by
an
update
of
the
prefix
public
key
pairs.
AE
So,
finally,
with
the
prototype
there's
no
idea
it's
written
in
Python.
We
use
a
simple
mistake.
There's
about
time
of
60
seconds
we
used
to
megabyte
gloves
and
we
support
both
IP
version.
4
and
IP
version.
6
I
have
open
source
it
here,
so
you
can
have
a
look
if
you
want
and
we
can
toggle
fighting
an
experiment.
So
we
have
a
master
node
that
has
a
Jenny's
work
with
over
IP
LZ
space
and
first
it
allocates
all
those
less-dense
to
eighth
notes
in
the
system.
AE
Then
these
8
notes
allocate
between
themselves
as
much
under
16
addresses
and
finally
is
not
allocate
again
between
themselves
around
150,000
for
fixes
that
we
extracted
from
the
registries
exchange
files
and
well.
How
did
it
go
so
here
you
have
our
test
run
that
lasted
more
or
less
24
hours.
You
can
see
the
block
number
and
the
team's
actions
that
we
broke
had
formation
for
transactions
equation
sheet
transactions.
AE
Here
you
can
see
this
small
space,
the
first
allocation
from
the
master
to
the
8th
notes,
names
50
months.
Then
you
can
see
here
around
300
abstractions
per
block
the
location
of
the
/
sixteens.
It
is
very
regular
because
all
the
nodes
have
the
same
number
of
transactions
to
do,
and
then,
finally,
you
can
see
how
we
located
all
the
register
files
perfect,
is
it's
more
irregular,
because
the
relations
3
is
unbalanced.
So
with
this,
I
mean
that
you.
AE
It's
a
loved
one,
so
I
mean
that
the
relations
these
imbalanced
and
some
prefixes
have
super
fixes
and
other
stuff.
So
much
so
notes
run
out
of
transactions
at
different
point
in
time.
So,
just
to
note,
the
chain
was
around
when
the
1
gigabytes
for
this
150,000
prefixes
and
it
took
more
or
less
6
hours
and
a
half
bootstrap
it
thank.
C
AF
So
I
just
start
yeah,
so
my
name
is
Carsten
whatever
I'm,
with
TC
independent
test
lab
in
Berlin
Germany
and
we've
been
testing
a
firewall
performance
network
security
solution
performance
for
many
years
and
Reis
more
recently,
it
kept
started
knowing
us
a
lot
that
what
we
find
in
our
tests
is
very
different
from.
What's
what
we
find
in
data
sheets
of
vendors
and
I'm,
not
sure
if
you,
if
you've
seen
that,
as
always,
there
have
always
been
a
discrepancy,
but
it's
getting
worse
and
worse,
especially
with
like
next-gen
firewall
functions.
AF
You
know:
intrusion,
detection,
unified
threat
management,
all
of
these
more
advanced
functions,
and
so
we
went
to.
We
got
together
with
a
group
of
like
six
vendors
who
actually
started
to
see
like
their
datasheet
numbers
are
starting
to
hurt
them
because
the
customers,
don't
trust
them
anymore,
and
to
tests
to
test
tool,
vendors
and
three
test
labs
and
we
started
to
create
a
new
next-gen
firewall
benchmarking
methodology
that
was
actually
initially
outside
ITF.
And
then
we
looked
for
a
home.
That's
for
our
standard!
AF
That's
has
a
good
reputation
and
is
seen
is
looked
at
both
by
enterprises
and
service
fighters.
So
that's
how
we
came
here.
The
point
is
actually
to
create
a
benchmarking
methodology
for
next-gen,
firewalls,
IDs,
UTM,
web
application,
firewalls
and
a
couple
of
enterprise
and
service
wider
use
cases,
and
especially
to
strongly
improve
the
reproducibility
and
transparency
of
benchmark.
So
we
want
to
take
this
document
which
we
are
currently
developing
in
the
benchmarking
methodology
working
group.
We
want
to
take
this
as
the
basis
for
an
open,
multi
lab
multi
tool
certification
program.
AF
AF
So
we
want
to
make
the
attack
vectors
public
and
standardize
them.
Of
course,
there
is
a
lot
of
dynamic
in
attack
vectors,
so
we
can't
just
nail
them
down
in
an
RC
and
keep
them
fixed
forever.
So
we
will
have
to
refer
to
external
databases
that
are
public,
such
as
the
NIST
database,
for
example.
So
I
think
I
don't
want
to
run
through
each
of
the
slides.
Please,
if
you're
more
interested
in
more
details,
look
at
the
slide
deck.
AF
That's
part
of
the
materials
generally
we're
looking
for
contributions,
of
course,
and
for
review
and
in
general
for
interest
in
the
initial
coverage
areas
that
are
shown
here
on
the
slide.
So
obviously
there
are
a
lot
of
functions
beyond
just
basic
forwarding
and
rule-based
filtering
that
the
next-gen
firewall
has
to
implement,
and
some
of
them
require
effectiveness
test.
AF
A
lot
of
them
require
performance
tests
and
in
most
cases
they
actually
require
a
security
effectiveness
like
attack
tests
together
with
a
performance
background,
because
most
of
the
tests
are
done
in
lab
environments
that
are
not
very
realistic
these
days.
So
either
you
test
functional
attacks.
It's
like
the
firewall,
sits
there.
It's
completely
idle,
it
just
waits
for
something
and
you
send
it
one
attack
it
handles
it
nicely.
You
say
you're
like
wonderful,
this
firewall
as
well,
but
you
have
no
idea
how
this
attack
actually
influences
the
performance
of
background.
AF
So
it's
actually
about
much
about
doing
making
test
more
realistic,
I
think
the
the
combined
experience
of
the
three
labs
that
are
involved
and
all
of
the
vendors
will
enable
us
to
provide
a
much
better
standard
than
in
the
past.
So
there
is
an
old
document
called
RC
3511,
which
exists
for
10
years
was
also
conducted
created
from
the
benchmarking
methodology
working
group
for
old
legacy.
AF
Firewall
tests,
I
think
our
document
is
going
to
supersede
it,
but
of
course,
3511
will
still
be
applicable
for
like
lab
based
testing
of
traditional
firewalls,
so
I
think
I
can
skip
most
of
that
one.
One
last
thing:
maybe
traffic
mix
actually
firewalls
are
usually
tested
with
a
very
uniform
traffic
like
let's
use
as
large
as
possible
request
sizes,
let's
use
as
few
as
possible
certificates
and
so
on,
and
this
helps
the
vendors
to
typically
optimize
the
memory
in
their
firewalls,
so
that
the
datasheet
numbers
are
blown
up
or
grown.
H
AF
You're,
a
vendor
increased
so
and
traffic
mix
I
will
define
in
an
NX
will
actually
help
to
make
this
testing
more
realistic
and
will
prevent
this
kind
of
optimization.
That
is
not
real,
so
we
have
a
pretty
aggressive
schedule.
There
are
quite
a
few
contributors.
We
hope
to
get
this
through
until
August
a
couple
of
questions.
That's
that's
basically
and
based
on
this
IRC
once
it
might
have
been
ratified
approved.
We
want
to
create
a
certification
program
so.
AG
AF
Important
part
here
is,
it's
all
web-based
traffic's
of
an
interrupt.
Enterprise
parameter,
probably
that's
realistic,
so
the
important
part
here
is
to
have
unique
certificates
and
those
certificates
are
supposed
to
be
real
because
that's
you
know,
and
the
apart
from
that
I
don't
care,
whether
it's
Outlook
or
YouTube
or
whatever.
What
counts
is
the
number
of
URLs.
The
number
of
domain
names.
H
AG
AF
And
this
is
only
the
first
profile,
so
if
you
are
interested
in
contributing
something
that
would
be
more
than
welcome.
Currently,
this
profile
is
implemented
in
one
emulator,
another
from
Spirent
and
other
company,
as
keysight
is
about
to
implement
it,
and
we
also
want
to
make
it
available
publicly
as
capture
like
a
peek
app
that
can
be
played
by
a
open
source
generator
such
as
t-rex
great.
AF
AF
I
I
In
universities
at
the
moment
is
being
able
to
push
several
gigabytes,
a
second
of
flows
through
the
firewall,
while
all
the
other
stuff
goes
on
most
universities
now
starting
your
engine
in
the
network,
so
the
high
performance
stuff
is
redirected,
a
different
path
into
the
network,
but
having
some
measurements
of
existing
firewalls
to
show
just
how
bad
their
architecture
is
at
mixing.
Those
two
types
of
traffic
would
be
really
useful,
but
I
don't
see
that
in
there
at
the
moment,
yeah.
AF
J
AF
J
Not
a
for
right,
I'm,
inappropriate
in
advisers
that
I
filled
the
second
question.
Our
second
observation
is
about
your
traffic
mixes.
One
of
the
things
I
strongly
recommend
is
that
you
have
traffic
mixes.
That,
not
only
are
you
know,
large
large
Foligno,
large
full
frames
that
you're
doing
at
the
appropriate
throughput
rate
of
lots
of
small
frames
that
are
high
no
packet
per
second
I
mean.