►
From YouTube: IETF102-OPSEC-20180720-1150
Description
OPSEC meeting session at IETF102
2018/07/20 1150
https://datatracker.ietf.org/meeting/102/proceedings/
A
B
B
A
A
A
Another
thing
it's
11:50,
so
it's
time
to
start
the
meeting
in
a
OPSEC.
My
name
is
erik
van.
Can
you
see
here,
ronbo,
Nika
and
now
the
ad
is
passing
the
blue
sheet.
So
you
know
the
story
by
now
and
by
the
way,
thank
you
for
being
here
on
the
Friday
last
session.
Thank
you.
There's
another
one
here
right.
A
A
A
Looking
at
the
front
row
Chris
you
take
it.
Thank
you
very
much
so
note
Whalum,
I,
guess
on
Friday.
The
good
thing
is
that
you
don't
need
to
read.
It
is
the
same
as
the
old
one.
On
the
other
days
blue
sheet,
they
are
secreted.
So
please
fill
them
agenda.
This
is
for
bashing
it.
We
will
make
a
status
on
the
group
document
and
hopefully
Ron
will
be
there,
because
you
got
some
description
about
the
lack
of
active
document
into
this
working
group.
A
So
how
can
we
get
more
working
group
document
and,
as
you
are
doing
quite
often
now
we
are
presenting
documents
from
other
working
group
because
they
intersect
both
the
security
and
the
operation
area.
So
a
mr.
alia
regarding
the
status
of
the
working
group,
lessons
London
no
RFC's
has
been
published.
We
have
a
two
active
working
group
document,
one
which
is
the
unique
RPF
check
improvement.
A
Past
three
it
published
now
is
draft
as
a
week.
A
group
document
is
in
the
IETF,
but
it's
not
here
today
did
not
want
to
present
any
update
draft
op
security
v6.
As
you
may
know,
I
am
one
of
the
co-author
of
the
four
authors
no
updates
since
London,
and
this
document
is
version
13,
it's
a
real
snail
in
the
sense
of
advancing
forward.
I.
A
Think
the
author
will
really
need
to
do
something
about
this.
The
if
another
gaunt
document
about
extension
at
the
filtering
as
being
true
within
group
last
call.
There
was
some
comment
asking
from
Darren
Dukes
and
there's
been
addressed
by
Fernando,
so
is
published
draft
and
it's
up
to
me
and
and
run
basically
to
to
push
it
forward.
A
C
C
Well,
I,
look
around
the
room
and
I
see
it's
almost
empty.
That's
a
good
sign
that
it's
sleepy
so
I'd
like
to
propose
some
some
new
work.
First
is
a
long
time
ago
we
did
our
xc60
192,
protecting
the
router
control
plane.
Since
that
has
happened.
Most
vendors
have
gotten
a
little
bit
more
clever
about
their
Ackles
for
ipv6.
That
can
probably
be
updated
to
reflect
what
our
new
capabilities
so
I've
asked
for
folks
to
work
on
it,
the
original
author,
Dave,
dugal
and
Stefan,
who
want
both
stepped
up.
C
So
we
should
see
updates
to
that
another
thing:
the
ipv6
security
document.
There
are
lots
of
pieces
of
that.
Where
we
kind
of
touch
on
an
issue.
We
don't
really
talk
about
what
the
what
the
threat
is
or
of
what
the
mitigation
is
in
any
detail.
It
might
be
interesting
for
somebody
to
walk
through
that
document
and
see
if
there
are
any
spin-offs.
And
finally,
there
was
some
work
done
by
Fernando
and
Jen
a
few
years
ago
where
they
looked
to
see.
C
How
many
paths
in
the
internet
would
allow
ipv6
extension
headers?
It
might
be
interesting
to
revisit
that
work.
Maybe
update
the
the
experimental
procedure
see
if
we
can
do
something
a
little
bit
more
inclusive
also
replicate
it
to
see
if
the
findings
are
the
same
this
year,
as
they
were
a
few
years
ago,
maybe
even
identify
the
Pat,
the
guesses,
where
extension
headers,
are
getting
dropped
and
contact
those
people
figure
out.
Why,
if
it's
for
a
security
reason
figure
out
why
so
people
will
stop
dropping
packets?
D
Gory
gory
past
we
have
a
tool
that
we
use
for
probing
insight
for
all
sorts
of
things.
If
people
here
understand
the
extension
had
a
thing
why
I
want
exactly
what
what
they
want
to
reproduce.
We
could
put
it
in
our
tool
and
we
could
run
it
on
a
million
targets
and
just
do
it,
but
somebody's
gonna
have
to
work
with
us
to
tell
us
exactly
what
was
done
previously
and
what
it
is
we're.
Looking
for
before
we
invest
time
kind
of
putting
tooling.
D
B
F
Thanks,
thank
you
so,
but
well
quite
happy
to
present
this
draft
also
in
the
OPSEC
working
group,
so
earlier
this
week,
Sarah.
So
these
are
my
co-presenters
co-authors,
sorrel,
Dickinson
Ronald
for
Iraq
and
Ellison
Menken.
We
presented
this
draft
earlier
in
the
deprived
working
group,
so
it
has
some
overlap
with
a
previous
presentation,
but
I
want
to
give
a
little
bit
more
context
how
we
came
to
be
to
write
his
draft.
F
The
figure
is
there
and,
of
course,
what
we
expect
feedback
from
this
working
group.
So
a
brief
history
of
Lena's
privacy
DNS
was
never
to
be
meant
private.
It
was
always
in
the
clear,
but
with
the
post
with
the
Snowden
revelations
there
was
this
action
in
the
ITF
brought
brought
wide
and
one
of
the
exit
was
the
ITF
deprived
working
group.
So
we
looked
into
it.
There
were
a
number
of
RFC's.
You
see
here
the
timeline
2015
2016
17.
It
is
about
DNS
privacy,
coronations
considerations
and
more
the
implementations.
F
So
it's
kind
of
what
are
the
threats
and
how
can
we
deal
with
it
and
the
different
implementations
to
protect
the
privacy
of
the
DNS
and
and
its
users
to
important
outcomes
are
DNA
Serfaty.
Let's
do
T
we
I
want.
I
will
use
that
quite
often
in
the
remainder
of
the
slides
Dinah's
of
Detailers
there's
a
RFC,
but
until
now
now
implementation
and
in
2017
we
mention
it
DNS
over
HTTP
s.
So
this
also
encryption
here
and
privacy.
So
we
mentioned
that
later.
F
There
is
CloudFlare
I
call
it
also
caught
one
one,
one,
one
one,
one
with
the
DNS
of
atilla's
and
doe,
and
this
is
recently
also
Google
as
an
experimental
doe
interface,
maybe
even
more
than
experimental,
but
I
have
to
look
at
Warren.
Okay,
that's
one
of
this
okay,
thanks
good,
so
Sarah,
Roland,
Ellison
and
I.
We
came
up
with
a
document
because
if
operators
want
to
run
their
own
Dinah's
privacy
service,
what
are
the
minimum
requirements?
What's
moderate
requirements
and
how
do
we
can
have
the
kind
of
optimal
configuration
of
this
dreamless
privacy?
F
So
we
want
to
give
really
practical
directions
to
the
operators,
and
so
these
are
the
operational
policy
and
security
considerations.
But
with
that-
and
that's
also
important,
what
do
you
do
with
the
data
on
the
surface?
How
these
are
the
DNS
privacy
policy
practices
statements?
So
what
is
published?
What
operators
will
do
with
the
information?
How
long
will
stay
on
the
server
etc
tension
policies?
F
So
it
has
documents
to
girls
and
I.
Think
I'll
come
back
to
that
later.
At
the
end
of
the
presentation,
current
deployment
of
DNS
privacy
services,
Sarah
yeah.
Well,
not
anymore,
doesn't
matter
so
the
d-o-t
service
Seraph
maintains
a
website,
Dinah's
professes
org
and
that
has
20
tests
service.
These
are
people
like
you
in
the
room
organizations
they
set
up
their
DNS
of
a
TLS
recurse
fir
and
open
that
to
the
public
to
test
genus.
Alpha
t
less
traffic
and
there
are
the
large
scale-
operators,
the
quad,
nine
and
the
court.
F
G
E
G
It's
just
a
tiny,
but
at
the
moment
I'm
their
feedback
her
so
far,
it
seems
to
be
working
really
well
for
their
BIOS
also
had
been
confused
about
that,
and
they
do
also
pop
up
an
interstitial
saying,
hey
just
so.
You
know
we're
doing
this
for
you.
We
hope
you
like
it.
You
can
opt
out
yeah
which,
from
this
stuff
I'd
originally
read,
I
hadn't
known
like
they
died,
mentioned.
F
F
F
We
hope
to
get
some
feedback
from
from
the
working
group
and
IOP
discussed
for
improvement,
etc.
I
think
we
let's
go
on.
We
touch
everything,
so
we
have
some
definitions
here.
It's
also
in
the
document,
a
privacy
enabling
DNS
server.
Well,
it
supports
implements
genus
of
rutila's
and
also
we
need
to
add
more
text
about
de
natura
HTTP
and
how
do
we
sort
of
sorry
authenticate
the
de
OT
service
or
do
it,
though,
service
with
certs
SPI?
F
So
there's
some
definitions
here,
but
the
Dinah's
privacy
service
is
everything
above
and
privacy,
enabling
deenis
with
some
documentation
and
essence
statement
about
policy
in
practice
or
in
formal
DP.
Pps
I
come
to
that
back
later,
right,
operational
guidance.
So
the
girls
is
we
try
to
set
out
in
the
document
the
goals
to
reduce
user
tracking
and
information
leaking
file
up
streams,
so
user
tracking
from
the
stop
or
a
user
to
the
resolver
and
upstream
from
the
resolve
to
the
authorities.
F
Kind
of
as
well
here's
a
server
capability,
so
it's
on
the
wire,
that's
from
the
step
and
use
it
to
the
resolver
at
this,
let
the
resolver!
How
do
we
deal
with
information
and
data
and
data
queries
actually
sent
up
screens
on
the
wire
every
mall?
This
is
clear:
perhaps
the
protocols
yet
the
authentication,
certificate
management
and
some
specific.
F
We
have
data
at
the
server
so
of
course,
there's
from
real
time
on
turning
to
run
your
server,
that's
the
only
instead,
but
what
about
logging
tracking
of
users
at
the
server
who
can
get
data
access
and
cache
snooping?
These
are
still
some
empty
headers
in
the
document.
So
we
need
text
here,
but
this
is
the
outline
mainly,
but
also
indeed,
you
have
to
talk
about
trade
or
atomization
of
atomization
of
the
data
on
that.
F
So
it
is
now
more
or
less
more
a
discussion,
not
very
definite,
but
the
input
is
very,
very
welcome
here
and,
let's
see,
let's
consider
this
is
the
upstream
and
that's
important.
So
it's
not
only
about
encryption
here
but
upstream
is
also
leaking
information
to
the
authorities
and
there's
an
DNS
option:
Huhn
a
minimization,
so
you
don't
ask
for
the
full
qualified
name
to
an
authoritative
names
of,
but
only
the
label
you
want
to
have
to
find
a
delegation
for
so
to
the
routes.
You
only
ask
for
calm
so
calm.
F
You
only
ask
for
that's:
let's
listen,
let's
take
with
the
IDF.
What
what
do
you
want
here?
Example.
Thank
you.
Thank
you.
You
guys
you
always
forget
about
that.
One!
So
yeah
the
dot-com!
You
were
asked
about
example,
and
example.
You
finally
ask
dub
dub
dub
dub
example.com,
so
you
don't
expose
more
information
in
stick
necessary
traffic,
ossification
and
data
sharing.
So
sometimes,
while
there's
overlap
with
data
at
rest
right
and
how
do
we
timewise?
F
F
Policies
and
statements
of,
for
example,
cloud,
fair,
Google
and
I
think
we
mentioned
here,
someone
else,
Google,
Cloud,
fair
quad,
9
and
Open
DNS
yeah,
and
we
want
to
compare
them
so
in
which,
to
its
extent,
do
they
overlap,
differ
and
can
we
kind
of
formalize
of
ultimate
ultimate
a
Akamai
automate
this
process?
So
it's
easy
for
the
user
to
see
what
is
covered
and
what
is
not
covered
right.
F
Think
yeah
I
think
I
mentioned
everything
here.
I
want
to
talk
about.
So
what
I
really
like
to
ask
the
room
here?
Isn't
it
get
some
well?
This
is,
of
course,
this
presentation
is
getting
your
interest
in
the
document
read
the
document
of
course,
I
mean
here
also
to
to
answer
more
specific
questions.
I
might
not
be
telling
right
now
in
this
presentation,
but
we
also
our
obscure
feedback
review
and
an
comments
on
that
to
improve
the
document.
F
So
we
that's
what
one
thing
I
want
to
mention.
What
the
discussion
about
the
discussion
in
the
DPI
working
group.
It
was
positively
received
by
the
working
group,
but
it
was
a
discussion
what
about
a
b-cup,
a
BCP
which
has
to
be
kind
of
a
strict
list
of
things
she
has
to
comply
to
versus
the
data
policy,
which
is
a
little
bit
more
less
strict.
So
if
you
want
to
be
PCP
compliance,
maybe
you
should
split
the
document
in
some
prescriptive
things
you
should
implement
as
an
operator
and
a
more
data
retention
compliance
document.
F
Others
say:
well,
it
should
stick
together.
It
should
stay
in
one
document,
so
this
is
a
kind
of
ongoing
this
while
ongoing
this.
Is
it
the
current
discussion,
but
also
get
is
this
interest
in
the
documents
for
the
working
group?
So
there's
a
working
group
adoption
call
for
absorption
in
in
on
the
mailing
list
and
from
there
we
want
to
proceed
another
thing
and
that's
it's.
A
busy
P
will
be
published
as
an
ITF
document,
but
you
also
might
want
to
have
kind
of
a
living
document.
F
H
E
H
F
F
A
I
I
B
Okay,
great
so
the
what
I'd
like
to
talk
about
is
some
context
and
then
about
the
draft
that
I
that
I
produce
so
carrier-grade
NAT
is
what
it's
about
in
general
and
it
produces
an
information
gap
when
it
comes
to
criminal
investigations,
basically
and
a
proposal
for
how
to
deal
with
this,
which
is
logging
of
source
ports.
So
if
we
could
move
on
to
the
second
slide,
please.
B
Okay,
so,
on
the
right
hand,
side
we
have
an
ISP
and
the
ISP
is
in
virtually
every
jurisdiction
is
required
to
retain
logs
that
allow
for
the
identification
of
their
subscribers.
Should
that
information
be
needed
in
a
criminal
investigation
and
RFC
six,
eight
eight
eight
provides
common
requirements
for
carrier-grade
nuts
that
outline
what
those
logs
it's
recommended
that
those
logs
consist
of
and
what
it
generally
consists
of
is
time
the
external
IP
address
and
the
external
port.
B
B
However,
here's
the
problem
most
victims
say,
for
example,
a
website
that
has
been
hacked
or
most
service
provider
platforms
only
keep
logs
of
IP
address
and
time,
and
what
that
means
is
that
when
it
comes
to
the
criminal
investigation,
you
find
out
the
IP
address
and
the
time,
but
you
can't
figure
out
which
of
the
subscribers.
It
was
because
you
haven't
got
the
port
number
that
they
were
using,
so
everything
is
looking
a
little
crazy.
Can
everybody
hear
me?
Okay,
yeah.
Okay,
fine
thanks,
and
so
so
that's
the
problem.
B
There's
this
information
gap
between
the
information
that
is
retained
in
the
logs
that
are
being
recorded
by
say,
a
victim
or
a
service
provider
and
the
logs
that
the
ISPs
have
everybody
thinks
they
have
enough
information,
but
there's
this
gap
so
how
to
deal
with
this
gap.
There's
basically
four
options.
B
In
other
words,
what
you
have
to
do
as
an
ISP
is
record
every
connection
that
all
of
your
subscribers
make
outgoing,
which
is
a
problem
for
the
ISP
in
terms
of
the
volume
of
records
that
you're
talking
about,
but
also
it's
a
huge
privacy
problem
as
well,
because
you're
retaining
a
massive
amount
of
information
about
your
subscribers
and
the
implications
of
a
breach
are
very
substantial
at
that
point.
But
it
is
a
solution
to
the
problem.
B
So
if
we
move
on
to
the
next
problem
or
the
next
slide,
please
solution
number
two
is
add:
migrated
ipv6,
which
effectively
eliminates
the
need
for
carrier
grade
nat,
because
everybody's
got
an
internet
IP
address
no
matters
require
the
ISP
gives
you
an
IP
address.
You
use
that
IP
address
or
a
prefix.
Indeed
it
may
be,
it
may
be
a
prefix,
but
nevertheless
the
carrier
grade
not
problem
goes
away.
B
Third
slide.
Our
next
slide,
please,
which
is
solution,
number
three,
that
don't
use,
carrier
grade,
nat
or
severely
limit
the
ear,
the
effectiveness
of
carrier
grade
nat
through
either
regulation
or
voluntary
code
of
practice
by
ISPs.
So,
for
example,
an
ISP
could
say:
I
will
only
have
a
maximum
of
16
people
16
subscribers
using
a
given
IP
address
at
a
given
point
in
time.
B
That
way,
if
an
IP
address
is
associated
with
criminal
activity,
you
can
tell
that
it's
at
least
it's
one
of
those
16
IP
addresses,
or
at
least
one
of
those
16
subscribers
I
really
don't
like
this
idea,
because
what
about
the
15
innocent
people-
and
you
know
it's-
it's
not
a
great
one,
but
anyway
it's
what
some
people
have
chosen
to
do.
And
finally,
if
we
move
on
to
the
next
slide,
please
there
is.
B
If
the
victim
had
logged
source
port
as
well
as
IP
address,
then
it
will
be
possible
to
a
uniquely
identified
a
subscriber
without
changing
the
is
what
the
ISP
is
currently
recording.
So
this
is
the
this
has
been
proposed
by
an
RFC.
Previously
RFC
6302
recommends
are
the
internet
facing
servers
record,
not
only
IP
address
but
also
source
port,
and
so
what
I?
What
I?
B
Why
isn't
it
being
done,
and
so
what
idea
does
I
did
some
analysis,
I,
so
I
wrote
a
draft
and
I
slightly
changed
the
recommendations
of
6302
and
because
they
were
a
little
bit
out
of
date,
but
also
some
analysis
of
to
make
some
more
recommendations
for
making
this
a
routine
making
logging
of
source
port
routine
at
at
internet-facing
servers.
So
some
of
the
challenges
that
I
identified
are
shown
on
the
next
slide.
B
The
first
is
awareness
most
most
people
don't
know
that
there's
a
problem
until
they
become
a
victim
and
then
they
find
they
haven't,
got
the
information
to
identify
the
person
who
hacked
them,
and
the
second
is
that
some
saw
meant
in
server
software
doesn't
support
the
logging
of
source
ports,
not
without
introducing
a
very
verbose
level
of
logging,
which
would
be
unacceptable
in
a
production
server.
The
volume
of
of
storage
required
can
be
a
problem,
but
isn't
really
another.
B
So
so
that
is
another
one
of
the
significant
challenges
to
the
logging
of
source
port
and
finally,
the
accuracy
of
the
log
actually
of
the
accuracy
of
the
times
in
the
logs
can
be
a
problem
as
well.
You
need
the
logs
to
have
accuracy
of
at
least
a
second,
so
these
were
the
main
challenges
that
I
identified.
B
Moving
on
to
the
next
slide,
please
I,
then
did
did
some
analysis
of
the
selection
of
different
types
of
server
software.
Looking
at
whether
or
not
it
was
possible
to
log
source
port
and
fortunately
enough
in
most
cases,
it
is
possible
to
log
source
port
in
most
common
server
software
and
then
I
looked
at
whether
or
not
it
was
feasible
and
by
feasible
I
meant.
Is
it
possible
to
log
it
in
a
way
that
wouldn't
severely
impact
the
production
performance
of
server?
In
other
words,
I?
B
Don't
consider
it
to
be
feasible
to
log
source
port
if
you
have
to
enable
a
really
verbose
level
of
logging.
So
there
are
some
server
software
packages
that
only
enable
query
and
it's
only
possible
to
log
source
port.
If
you
are
doing
debug
logging,
the
next
category
is
default.
Are
there
any
server
software
packages
available
that
by
default
log
source,
port
and
I
was
only
able
to
log
one
or
identify
one
which
was
open,
SSH
and
no
other
serve
software
package?
B
That
I
could
find
either
by
default,
logged
us
or
had
in
its
configuration
a
configuration
section
that
would
have
allowed
for
the
logging
of
source
port?
Then
there's
two
other
questions
where
there's
virtually
no
information
available,
which
is,
supposing
you
have
a
large
volume
of
logs
generated
querying
by
IP,
address
and
source
port?
Is
that
possible?
How
do
you
manage
the
logs
are?
Is
the
information
in
those
logs
accessible
I?
Have
no
information
about
that
and
I
couldn't
find
any
sources
of
information
about
that?
B
So
so
what
I
did
next
slide?
Please
what
I
did
was
I
published
an
internet
draft
which
is
now
on
version
4
and
I,
presented
this
at
IETF
101
to
the
interior
group
and
I
also
participated
in
an
extensive
discussion
on
the
interior
group.
Speaking
candidly,
it
wasn't
tremendously
favorably
received
by
the
interior
group.
B
I
think
it
would
be
fair
to
say
and
because
there
seems
to
be
quite
a
bit
of
resistance
to
any
form
of
logging
whatsoever,
any
form
of
additional
logging
whatsoever
or
making
any
recommendations
for
any
form
of
additional
logging,
but
nevertheless,
I
found
it
to
be
a
useful
discussion
and
it
did
help
to
advance
my
thinking
on
some
of
the
problems
and
I
would
appreciate
if
people
have
any
feedback.
I'd
definitely
be
very
interested
in
hearing
what
it
is
and
I
also
thought.
I'd
just
do
a
little
plug
for
the
landing
page.
B
For
my
work
on
this
is
the
top
of
the
other
two
links
there,
the
one
that
ends
in
carrier
grade
mass,
where
I
have
links
to
the
presentations
that
I've
provided
on
this.
The
documents
that
I've
published
on
this
and
I
keep
that
maintained,
and
then
the
bottom
link
is
a
link
to
my
blog.
You
can
get
the
RSS
feed
on
that
page.
B
If
you
want
so,
and
that's
really
all
I
wanted
to
say,
I
wanted
to
present
you
with
the
challenge
and
then
show
you
what
the
possible
solutions
where
and
why
and
source
port
logging
is
of
the
available
options
somewhat.
The
kind
of
least
worst
of
the
available
options
for
dealing
with
this
problem,
the
four
solutions
that
I
outlines
their
connection,
logging
ipv6,
don't
use
carrier-grade,
NAT
and
source
port
logging.
B
All
of
them
have
been
tried
and
all
of
them
are
in
in
use
somewhere
or
other
in
the
world,
and
but
the
source
port
logging
I
think
is
the
one
that
solves
the
problem.
With
the
least
privacy
implications
for
most
people-
and
that's
all
I
have
to
say
so,
questions
or
comments
would
be
appreciated.
Thank
you.
J
B
J
J
B
B
K
K
If
we're
thinking
about
trying
to
make
logging
recommendations
the
we
need
to
be
thinking
much
more
clearly
today
about
what
the
privacy
concerns
are
for
logging
recommendations,
including
questions
about
how
you
can
reliably
ensure
your
logs
are
destroyed
as
soon
as
possible,
and
so
I
would
be
much
more
interested
in
seeing
this
as
part
of
a
bigger
question
about.
How
can
we
help
people
who
end
up
having
to
keep
some
log
keep
as
minimal
logs
as
possible?
K
I
had
a
additional
point
for
you
also,
which
is
that
I
looked
at
your
blog
page
and
I'm,
getting
PHP
errors
with
the
PHP
messages
published.
Oh,
you
might
want
to
check
to
see
what
source
port
that
came
from
okay.
D
D
It's
about
the
impact
of
Transport
header,
confidentiality
on
network
operation
and
evolution
of
the
Internet.
The
aim
is
to
talk
about
just
the
impact
that
we
know
on
the
way
networks
are
currently
operated
and
the
evolution
as
a
whole
and
where
it
may
change
this,
we
are
not
trying
to
make
recommendations
for
what
happens
next.
In
the
IETF
protocol
series,
there
are
other
documents
that
might
do
this,
we're
looking
just
at
the
transport
perspectives,
but
it's
button
operations
and
security
things.
So
it's
probably
good
to
talk
about
it
here.
D
D
Aims
and
goals
identify
in-network
uses
of
transport,
layer,
header
information
and
if
anybody
has
additional
uses
that
are
currently
being
used,
or
of
recently
being
used
of
Transport
header
information
to
help
operations
to
analyze
performance,
to
support
users,
we'd
love
to
know
review
the
implication
of
transport
protocols
that
use
integrity,
protection
encryption
to
protect
the
transport
protocol
header.
What
are
the
things
we
know
that
we
might
gain
when
things
are
encrypted.
D
One
of
the
things
we
may
lose
when
we
encrypt
transport
information
and
discuss
their
impact
on
transport
protocol
design
is
a
transport
activity,
so
it
is
primarily
aimed
at
the
trans
particle
design,
but
never
cooperation
is
also
part
of
this
inherently
and
finally,
we
have
a
small
bit
which
speculates
about
the
impact
on
transport
and
application.
Evolution.
D
It's
important
that
this
particular
document
takes
a
view
which
is
the
consensus
of
the
ITF
community,
we're
putting
this
two
TS
vwg
as
a
work
item
for
the
group
to
work
on.
So
we
need
to
be
quite
from
different
people.
At
the
moment
we
have
taken
a
lot
of
feedback
from
al
Morton
and
Kathleen
Moriarty,
Spencer,
Joe
touch
and
Chris
Neil,
etc
have
been
helping
us
more
people
very,
very
welcome
and
I
know.
D
People
from
this
group
have
actually
helped
in
the
previous
round
of
revisions,
so
I
also
especially
say
thanks
and
there's
some
related
work,
and
my
primary
point
of
putting
these
on
the
slide
is
to
indicate
that
this
is
the
only
document
in
this
space
which
these
documents
is
meant
to
be
complimentary.
The
two
documents
that
are
mentioned
here
are
about
other
aspects
of
this
problem
space
and
we
don't
intend
this
to
be
overlapping
or
conflicting.
D
So
we
will
work
with
the
document
authors
to
make
all
three
documents
progress
if
these
documents
also
progress
so
what's
different
and
in
the
work
over
the
last
time,
I
spoke
to
you
and
the
main
thing
is:
we've
tried
to
adopt
a
neutral
point
of
view.
We've
realized
that
there's
value
in
publishing
things
in
the
IETF
which
look
at
difficult
topics
from
different
perspectives,
but
present
them
neutrally
so
that
other
people
can
read
them
and
we
don't
end
up
with
a
great
big
gunfight
and
lots
of
exciting
emails
when
people
just
take
different
positions.
D
D
D
It
is
to
understand
how
exactly
people
are
currently
using
TCP,
headers,
RTP,
headers,
etc
in
the
network,
or
what
the
difference
will
be
if
these
are
encrypted,
and
we
added
some
notes
also
on
accountability
and
network
neutrality,
because
I've
been
helping
some
people
with
network
neutrality,
stuff
and
trying
to
say
what
is
a
network
neutrality
issue
and
what
isn't
so?
We
added
that
a
little
bit.
Also
to
this.
The
security
considerations
have
been
added,
so
that's
really
good
to
get
feedback
on.
D
Please
look
at
the
security
considerations
because-
and
we
started
to
kind
of
unpack
what
we
think
of
the
takeaways
from
this
document
in
that
session,
and
we
also
added
a
conclusion
section,
which
I
think
would
benefit
from
much
more
review.
So
what's
the
status
and
the
statuses
we
talked
at
this
yesterday
in
TS
vwg-
and
there
was
support
for
this-
for
adopting
this
as
a
working
group
item
and
we're
going
to
take
that
to
the
list
in
TS
vwg
and
confirm
this
and
then
hopefully
adopt
the
document
shortly
after
this
ITF.
D
If
there
is
feedback
on
a
list
to
support
it,
if
you
want
to
comment
on
the
TS
vwg
list
on
adoption,
please
do
if
you
want
to
comment
on
any
aspect
of
this.
Please
do
we're
looking
for,
if
you
know
from
the
operator
community
from
those
people
security,
the
considerations,
those
people
who
think
that
this
document
is
not
the
right
thing
to
do.
Those
people
who
think
the
wording
is
not
quite
right.
Yeah,
please
shoot
at
us.
Please
help
us
get
this
right,
because
then
we
want
to
create
a
document.
D
That's
generally
useful
to
the
community.
I
think
that's
it.
It
was
short
that
the
the
point
is
the
documents
actually
no
readable,
so
you
can
actually
go
out
and
read
the
document.
Oh
I
should
say
thank
you
to
Steven
Thank
You
Steven
for
comments.
A
lot
of
comments.
Please
please
tell
me
something
so.
J
Yeah
sorry
I
appreciate
the
attempted
neutral
point
of
view.
I
think
it's
I
I
haven't
read
it
since
Christmas
I
think
was
the
one
I
reviewed.
So
it's
a
long
time
ago,
and
but
they
looked
quick
scanner
did
if
I
had
it
does
seem
to
be
improved
in
many
ways.
That's
good
and
I
will
definitely
review
us.
I
would
support
adoption
of
a
nice
neutral
point
of
view.
Document
like
this,
like
I,
did
with
draft
encrypt.
J
D
D
D
Encryption
case
so
one
of
the
things
we
could
definitely
talk
about
which
we
kind
of
started
to
impart
and
justice
ITF
is,
we
could
bigger
a
list
of
points
we're
not
encrypting.
Things
has
really
acted
as
a
problem
to
the
transport
layer,
so
this
isn't
a
security
thing,
but
it's
a
revealing.
It
is
a
strong,
has
really
impacted
bad
things.
Going
on
in
the
transport,
I
mean
I'm
talking
about
MP
TCP
I'm,
talking
about
MSS
clamping
I'm
talking
about
horrible
stuff
that
goes
on
when
TCP
middleboxes.
D
D
D
E
So
my
name
is
maya
KU,
Leuven
I'm,
also
mostly
working
in
a
transport
area
and
Gauri
gave
me
just
a
very
nice
introduction
to
the
work
I'm
talking
about
here.
That
is
a
draft
that
I'm
co-authoring
was
Brian
Trammell
and
it
came
out
of
our
work.
We
do
in
transport
and
transferred
evolution
also
a
little
bit
in
a
quick
working
group,
but
it's
also
most
actually
of
the
input
is
coming
from
the
IEP
stack
evolution
program.
So
that's
an
IEP
program
looking
at
how
to
evolve
the
stack
on
on
various
layers.
E
Actually,
what
the
draft
does
it
defines?
What
a
why
image
is
because
that
that
term
comes
up
more
often
and
there's
some
confusion
about
it,
and
so
clear
definition
makes
sense.
But
before
I
give
you
the
definition,
I
start
a
little
bit
back
there,
yeah
where's
the
problem
and
I
mean
it's
the
same
problem
that
Cori
is
addressing
and
I
just
tried
to
spell
it
out
more
clearly.
So
we
all
talk
about
the
same
thing
and
actually
have
a
swing
over
here.
That's
great
I
take
yeah.
E
So
the
stick
that
like
was
originally
designed,
which
is
like
kind
of
title
here
as
the
90s
style
steak,
is
what
we
also
know
today
and
learned
at
university
or
school
or
somewhere,
and
it
didn't
really
include
security
that
much,
but
it
had
a
clear,
separate
preparation
of
layers
and
the
transport
layer
was
really
meant
to
be
end-to-end
operation.
So
all
the
information
you
need
at
both
of
the
endpoints
to
make
some
communication
going,
given
the
fact
that
this
information
is
visible,
like
as
all
the
other
layers
to
everybody
who's
like
involved
in
the
communication.
E
So
all
the
middle
points
all
the
end
points
every
passive
observer.
There
has
been
an
evolution
of
actually
doing
a
lot
of
additional
things
with
this
information.
An
easy
example
is
you
look
at
the
ports
and
you
do
some
filtering
of
the
ports
more
complicated.
As
you
use
some
of
the
transport
header
information
to
do
like
round-trip
time
measurements,
you
can
do
loss
detection.
All
these
information
is
used
in
various
middle
boxes
in
various
different
ways,
for
good
and
for
bad,
so
that
wouldn't
be
a
problem
on
its
own.
E
The
problem
really
appears
a
little
bit
more
if
you
actually
start
also
to
change
this
information,
and
at
that
point
you
make
assumptions
about
what
these
informations
are
used
for
at
the
endpoint,
and
you
try,
of
course,
to
change
them
a
way
to
not
interfere
with
the
endpoint
operation.
But
that
also
means
you
cannot
evolve
the
endpoint
operation
anymore.
E
If
the
assumptions
out
this
information
have
to
be
used
are
not
holding
anymore,
if
you
change
something
everything
breaks
and
then
there's
actually,
of
course,
another
expect
where
people
actually
go
actually
deeper
in
the
layers
and
use
all
the
information
available
there,
and
at
some
point
you
even
go
to
the
payload,
where
you
have
might
have
like
privacy
sensitive
or
like
just
private
information
that
should
not
be
accessible
to
everybody.
So
clearly
the
solution
is
security.
Here
you
want
to
encrypt
your
data.
E
You
want
to
make
sure
only
those
data
is
accessible
to
those
people
that
we
need
them.
So
what
we
did
is
we
build
transport
layer,
security
which
is
actually
on
top
of
the
transport
layers
in
the
application
there
right,
which
gave
us
a
possibility
to
encrypt
everything
that,
as
as
I
said
on
top
of
transport,
but
still
like
this
end-to-end
operation,
which
is
also
meant
for
the
endpoint,
is
still
available
as
so
open
its
the
readable.
You
can
still
modify
it,
that's
good
and
but
definitely
has
some
evolution
in
ossification
problems.
E
E
So
what
we
see
right
now
is
something
more
like
this,
like
especially,
was
quick
where
you
have
end-to-end
information
that
is
part
of
the
encryption
envelope,
and
you
have
n
to
end
information
that
is
outside
the
encrypting
and
envelope
and
still
readable.
That
doesn't
select,
even
suppose,
is
like
part
of
the
transport
header,
because
you
needed
to
operate
your
transport
layer.
E
Part
of
that
is
visible
and
really
only
accessible
from
the
endpoint
and
the
other
one
is
outside,
and
the
reason
why
this
information
is
outside
is
not
like
always
explicitly
because
it's
used
by
the
past.
Sometimes
it's
just
information.
You
need
to
set
up
actually
akan
Krypton
context,
so
you're
like
you,
cannot
hide
it
from
the
past.
E
So
you
have
still
the
end-to-end
operation,
which
uses
mainly
the
inner
information,
and
then
they
still
have
some
modifications
or
inspection
on
the
outside.
Actually
modifications.
Also,
not
that
much
anymore,
because
you
can
also
use
this
encryption
context
to
at
least
Integra
to
check
your
information
and
make
sure
that
they
don't
get
modified,
at
least
in
the
transport
layer.
E
So
the
why
I
mentioned
specially
this
part,
everything
that
is
visible
to
the
network
right
and
when
I
say
everything.
It's
actually
not
only
the
outer
transport
header
bits,
so
the
outer
hand
turns
but
head-up.
It
is
some
information
that
is
clear
what
they
mean
and
you
can
interpret,
but
after
all
the
wire
image,
it's
like
everything
that
is
was
about
to
the
part,
which
also
means
having
they're
having
this
blue
box
here,
knowing
the
size
of
the
blue
box.
E
It's
also
some
information,
that's
visible
to
the
path
and
knowing
the
length
and
entropy
of
all
the
bits
of
the
packet
is
part
of
the
wire
image
and
also
the
timing
of
the
package,
because
that
can
reveal
information
about
what
the
application
is
doing
in
the
application
that,
on
top
of
it
and
that's
what
we
mean
by
why
I
merge
that's.
Why?
There's
a
difference
between
outer
header
bits
and
a
wire
image?
It's
like
painting
the
whole
picture
of
what
your
transporters
right,
what
your
connection
your
traffic
does,
and
so
why
is
it
important?
E
Yeah
the
second
point
here:
it's
also
giving
we
have
this
clear
boundary.
We
have
a
chance
to
decide
if
it's
inside
or
outside
and
we
have
some
integrity
protection.
We
can
actually
make
a
clearer
decision
about
which
information
to
expose
and
when
and
so
providing
the
information
if
needed
in
a
case
where,
like
you,
want
to
do
troubleshooting,
for
example,
from
the
operations
point
of
view.
E
Of
course,
what
I
said
already
it's
it's
like
it's
not
the
same
as
you
have
before
it's
less
bits,
it's
less
information
that
you
have
to
adapt
to
it,
but
that's
probably
not
the
new
message
here.
Just
yet
I
guess
this
message
came
already
to
this
room,
but
the
positive
part
of
this
is
also
that
if
you
have
a
single
in
your
wire
image,
then
it's
more
designed
to
be
usable
for
the
network
as
well
and
like
one
excellent
simple
example
is,
for
example,
the
TCP
times
the
option.
E
Well
like
as
a
different
example,
the
spin
bit
that
we're
designing,
quick,
it's
actually
explicitly
designed
to
provide
round
with
time
information
and
therefore
can
be
emoni
toward
much
much
easier
yeah.
So
after
all,
the
message
is
that
there
is
this
document
and
maybe
worth
read
it's
a
short
document.
There
is
a
second
document
which
quarry
re
also
mentioned,
which
goes
with
the
document,
so
the
first
one
really
just
defines
the
wire
image.
What
I
told
you
here
right
now?
E
D
Hi
Mira
is
going
first
again
and
yeah,
but
that's
okay,
and
but
you
just
draw
a
great
blob
of
a
blue
blob
and
when
I
talked
to
operators-
and
they
don't
see
what
they
like
in
the
blue
blob,
then
they
add
a
pink
blob
in
between
which
is
the
enter
and
or
edge
to
edge,
or
am
signaling
or
gtp
encapsulation,
with
options
to
do
time.
Stance
because
I
no
longer
see
time
stamps.
So
there's
an
extra
bit
to
this
evolution,
which
I
don't
know
whether
you
want
to
consider.
D
E
D
I
mean
if
I
wanted
to
operate
a
network
and
I
want
to
seek
measure
packet
loss.
An
RTT
and
I
can't
find
a
way
of
doing
it,
because
maybe
this
IPSec
encrypted
or
whatever
I
don't
know
that
I
can
just
add
a
edge-to-edge
header
on
it
and
take
some
bytes
and
at
my
time
stamps
has
plenty
of
IDs
bets
for
doing
this.
So
it
doesn't
go
you
don't
make
it
private,
but
no.
E
The
the
thing
that
we
have
to
care
for
consider
is
whenever
we
connect
a
mechanism
to
the
endpoint
mechanisms
that
we
make
sure
we
don't
reveal
information,
we
don't
want
to
reveal
so
the
risk
when
you
actually
add
some
tunneling
headers
is
probably
smaller
than
that.
But
again,
this
is
also
protocol.
Where
you
view
information,
and
you
should
like
design
it
carefully
in
the
in
the
content
of
the
Hawaiian.
Much
maybe.
J
Instinct
vote
and
just
say,
I
heard
about
your
definition.
I've
got
the
only
part
the
document
I
read
so
I'm,
sorry,
and
so
it.
It
looks
to
me
that
the
definition
doesn't
quite
capture
issues
like
sending
multiple
messages
in
a
single
flight,
as
is
commonly
done
tos,
for
example,
and
I'm,
not
quite
sure
how
that
might
impact
on
things.
But
the
definition
seems
to
assume
that
you
can
see
that
the
protocol
messages
in
the
wire
image,
even
if
they
may
be
multiple
messages,
could
be
sent
in.
Who
knows
what
order
inside
the
cipher
text
so.
E
I
mean
actually,
it
doesn't
matter
where
you
put
the
packet
boundary
right,
because
the
wire
image
covers
like
everything
anyway,
right
like
it
doesn't
matter.
If
you
have
some
unencrypted
bits
in
the
front
and
another
piece
of
unencrypted
bits
in
the
head,
like
everything
you
can
see,
that
belongs
to
the
same
communications,
part
of
the
wire
image,
yeah.
E
So
I
mean
like
this
is
this:
is
a
this
might
be
a
way
to
be
great,
to
reveal
this
information
right,
but
at
least
a
pick
up
a
packet
boundaries.
You
cannot
take
away
so
like
if
you
have
magical
message
encrypted
inside
the
same
packet
and
you
cannot
see
the
boundaries
there
anymore.
Then
you
review
this
information,
that's
fine
yeah,
and
then
you
don't
have
to
consider
it
anymore.
Like
do
we
talking
past
each
other.
E
E
A
E
Definitely
not
in
this
document,
but
so
the
only
thing
I
really
recommend
is
to
consider
all
these
points.
When
you
do
do
your
design
at
the
station
right,
but
whatever
the
trade
of
it
is.
It
is
the
decision
for
like
this
specific
protocol
for
that
Pacific
use
case.
So
I
don't
think
it's
possible
to
make
you
a
general
recommendation
here
enough.
A
K
You
this
is
d
kg,
so
thank
you
for
writing
this
stuff
down.
I
think
this
is
really
useful
as
a
reminder
for
the
Associated
design
protocols-
and
you
know
we're
already
following
some
of
this
guidance
I
think
within
the
IETF,
so
I
think
it's
very
useful
to
have
this
kind
of
framing
written
down
and
yeah
I
would
agree
with
with
Stephen
that
the
location
of
the
protocol
data
units
and
the
actual
packet
edges
may
be
different,
and
that's
worth
that's
what
I
lighting
I'm
answer
to
Jeff
you're
concerned
about
that
you
could
just
go
sorry.
K
I
apologize
was
that
your
you
said
that
the
network
operator
could
add
things
to
be
absolute
packet.
That's
surely
true
and
we're
not
gonna
change
reality
by
mandating
otherwise
in
the
ITF,
but
the
deaths
within
the
network
that
you
control
and
the
and
and
not
something
that
the
endpoint
needs
to
decide
on
your
behalf
right
so
so,
I
think.
The
point
that
merely
strapped
is
making
stands
right,
that
the
endpoints
need
to
think
as
clearly
about
the
information
that
they
leak,
regardless
of
what
the
network
operators
might
tag
or
annotate
a
packet
with.
D
Gory
Fairhurst
I'm
wondering
what
happen
is
when
we
have
mobile
operators
who
PA
gtp
and
then
start
exchanging
their
Auriemma
cross.
It
they'll
never
do
that,
of
course.
So
it's.
E
D
All
there
is
a
place
we
can
put
information
here
and
that
information
currently
will
be
contained
in
the
edge
of
a
now
work
in
the
future.
That
doesn't
have
to
be
the
case
if
people
agree
to
do
other
stuff,
so
just
have
to
be
able
to
be
careful
about
where
things
can
go.
If
you
squeeze
one
place,
it
might
appear
somewhere
else.
That's
all
I'm
saying
answer
the
question
because,
because
it's
things
a
useful
question,
I.
K
E
D
Okay,
so
my
take
is
it
should
improve
the
security
perspectives
on
this.
So
I
agree
on
that,
but
it
may
create
more
options
for
how
you
use
this
data
and
then
fragmental
people
do
it
and
they
end
up
with
more
information
being
added
than
you
would
have
needed
to
add
it
another
case.
So
so
you
may
benefit
security,
but
you
may
be
create
more
complexity
in
the
OEM
and
management
infrastructure
as
a
result
of
this,
so
you
want
to
talk
more.
K
E
Me
give
an
example:
we
talk
a
lot
about
link
ability,
so
if
you
want
to
like,
if
an
operator
decides
I
want
to
at
a
time
stamp,
for
whatever
reason
and
leaks
is
information
to
the
other
networks
as
well
and
the
operator,
because
that
the
access
network
knows
actually
all
the
flows
that
belong
to
you,
you
can
get
a
link
ability
between
different
flows
that
you
don't
want
and
that's
just
because
the
operator
did
implement
it
stupidly
and
leaked
that
information.
It
didn't
want
right.
E
E
K
They
do
we
have
the
evidence
of
the
Verizon
super
cookie.
At&Amp;T
did
a
similar
thing.
The
fact
that
we
are
not
linking
something
is
not
the
fact
that
we
are
going
ahead
and
producing
linkable
data
publicly
is
not
going
to
prevent
the
network
operators
from
leaking
that
information
as
well
right
and
if
the
metadata
that's
being
leaked,
is
something
that
the
network
operators
operate
on
I
guarantee
you
that
endpoints
will
start
to
lie
about
it.
K
In
which
case
then
network
operators
again
have
an
incentive
to
go
ahead
and
make
their
own
mistakes
and
add
their
metadata
back
in.
So
the
better
approach
is
I,
think
what
you're
outlining
here
or
what
this
is
pointing
towards,
which
is
to
go
ahead
and
hide
as
much
data
as
you
can,
so
that
the
network
operator
passes
the
traffic.
So
that's
my
okay.
D
On
the
counterpoint
to
that
would
be
that
forces
the
operators
to
use
things
like
machine
learning
for
categorizing
orders
just
that
they
need
to
find
which
will
produce
a
more
variable
and
less
useful
service
and
consume
more
CPU.
This
is
this
trade-off
here.
This
is
a
straight
trade
of
things.
Security
is
probably
the
most
important
thing,
but
if
you
drive
only
on
increasing
security,
well,
maybe
there
are
comes
so.
E
C
C
G
C
G
G
A
C
G
C
Talk
a
little
bit
about
what
those
issues
are:
I
see:
I've
woken
you
up.
Let's
talk
about
how
ipv6
fragmentation
works
or
for
that
matter,
IP
fragmentation
period,
a
packet
comes
in.
It
is
larger
than
the
MTU
going
out.
So
you
chop
it
up
into
segments.
Every
segment
has
an
IP
header.
Let's
talk
about
ipv6
fragmentation,
it's
the
easiest.
It
has
an
ipv6
header,
followed
by
a
fragment
extension
header,
followed
by
stuff,
and
the
stuff
is
the
original
packet
that
you
had
to
salami
up.
C
How
many
say
yes,
good
you
good
student,
it!
No!
It
does
not!
So,
let's
think
about
this
for
a
minute.
How
would
a
stateful
firewall
behave
if
it
saw?
Let's
say
we
have
a
stateful
firewall
and
its
policy
is
to
admit
all
packets
directed
towards
TCP
port
80?
Can
it
process
the
first
packet,
the
first
fragment
correctly?
Yes,
it
can
because
it
can
see
the
TCP
header.
How
does
it
do
with
the
second
pack?
Our
fragment
did
I,
say
state,
fuller,
state,
less
sorry,
state
less.
C
The
stateless
guy
has
two
options,
both
of
which
are
bad.
One
is
to
pass
the
packet,
which
means
he
passes
more
stuff
than
he
should.
The
other
is
to
drop
the
packet,
which
means
he
might
as
well
have
dropped
the
first
fragment
too,
because
it
can't
be
reassembled.
Let's
talk
about
load
balancers
again,
the
stateless.
If
they're
load,
balancing
based
on
two
transport
layer
port
did
they
do
a
good
job?
C
No
okay!
So
we've
convinced
that
convinced
ourselves
that
IP
fragmentation
breaks
some
middleboxes,
some
stateless
middle
boxes.
There
were
also
some
interesting
security
vulnerabilities
associated
with
reassembling
things,
overlapping,
fragment
attacks,
attacks,
in
which
you
send
a
bunch
of
fragments,
which
you
know
damn
well
can't
be
reassembled,
because
there's
one
fragment
missing
in
each
packet.
So
it's
a
resource,
exhaustion
attack
other
problems
with
fragmentation.
So
what
we're
doing
in
this
draft
is
pointing
out
that
fragmentation
is
break
some
things
pointing
out
that.
C
We
should
not
be
designing
new
protocols
that
rely
on
fragmentation.
They
will
be
as
fragile
as
fragmentation
is
second
for
those
protocols
that
do
particularly
DNS.
We
should
go
back
and
look
at
a
way
to
break
that
dependency,
because
you
know
the
application
is
going
to
be
only
as
stable
as
fragmentation
is
and
that's
not
very
stable
and
that's
all
I
have
to
say
we
can
all
go
out
and
go
for
in
the
sunshine.
Now
questions
arguments.