►
From YouTube: IETF101-INTAREA-20180319-1550
Description
INTAREA meeting session at IETF101
2018/03/19 1550
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
So,
first
of
all,
not
well
I.
Guess
you've
heard
that
there's
a
there's
a
new,
not
well,
so
please
take
a
look
at
it.
Especially
there
is
a
privacy
policy
at
the
end
that
we
encourage
you
guys
to
take
a
look.
That
is
a
new
addition
to
the
node.
Well,
all
the
rest,
pretty
much
the
same
as
I
said
used.
A
A
Okay,
so
thank
you
very
much
Ian
for
helping,
but
please
do
help
whenever
you
can
to
get
more
notes
or
to
clarify
your
points.
If
you
see
them
jabber
do
you
have
do
we
have
someone
that
can
help
us
with
the
Java?
Please
thank
you.
Thank
you
perfect.
A
So,
moving
down
to
the
agenda
now
we're
going
to
give
you
guys
a
quick
update
from
all
the
chairs
in
the
ad
on
document
status
and
some
other
topics.
Then
we
have
the
presentation
from
Eric
on
the
PVD
IP
tunnels,
quick
update
from
mark.
If
he's
around,
then
we
have
a
gooey
generic
UDP
encapsulation
from
tom
some
presentation
about
iLab
there,
something
there's
going
to
be
the
debuff
that
we
also
have
our
quick
heads
up
here.
A
That's
going
to
be
presented,
then
we
we
have
the
presentation
about
the
privacy
network
address
from
Tom
as
well
IP
fragmentation
from
Ron
toxics
from
Vladimir
and
availability
of
information
in
criminal
investigations
from
David.
Sorry,
here
this
okay,
could
we
increase
the
volume?
Thank
you
very
much,
yeah,
all
right.
So
moving
down
to
this
working
group
status
update,
so
the
privacy
considerations
for
i3
broadcast
multicast
protocols.
It's
now
in
the
RFC
editors
q.
A
Re
just
a
quick
answer
to
the
to
the
jabber.
We
did
receive
the
slides
from
the
presenters,
their
remote
presenters
as
well
so
privacy
considerations
for
IP
broadcast
and
now
it's
an
RFC
editors
queue
so
hopefully
soon
will
become
an
IRC
GUI.
We
have
the
presentation
from
that
working
group
draft
the
IP
over
internationally
partially
partitioned
links
and
that's
a
trap
type
expired
and
we
encourage
people
to
take
a
look
for
please.
If
you,
if
you
have
interest
in
this
topic,
send
comments,
make
a
review.
That
would
be
very
useful
for
the
author
right
now.
A
The
the
draft
is
stalled
because
we
haven't
had
any
any
update
on
it
and
but
we
do
need
the
community
feedback
if
we
want
to
advance
that
topic.
So
please
take
a
look
at
that.
One
probe
nights
now:
RFC
8335.
So
thank
you
very
much.
Congratulations
there
and
IP
tunnels
in
the
internet
architecture
we'll
get
a
presentation
so
moving
to
the
announcements
is
Suresh
in
the
room.
Yeah
thanks.
B
Isis
krishnan
area
to
do
so.
We
had
a
like
discussion
in
the
iesg,
so
one
of
the
documents
that
it
came
in
through
the
independent
stream-
and
it
was
trying
to
update
like,
are
actually
change,
staying
and
document
that
was
done
here,
which
is
the
recommendations
for
logging
with
ports.
So
what
we
did
in
the
IES
G
is
like
sent
a
note
saying
like
don't
publish
this,
because
it
needs
to
be
done
in
interior
because
we
published
the
original
document.
So
that's
the
last
document
on
the
list
over
there,
the
draft
divorce,
eg
and
logging.
B
So
this,
like
personally
me
I,
spoke
to
the
author
and
he
was
willing
to
present
remotely
the
document
and
daddy
has
to
see.
Is
the
recommendations
like
in
the
RFC's
he's
talking
about
is
like
whether
it's
practical
and
how
he
can
actually
go
about
logging,
the
boats
properly
based
on
like,
what's
in
the
servers
and
everything
so
there's
like
this
one,
contains
like
a
inventory
of
what's
in
the
servers
and
what's
being
done?
A
C
By
being
here,
okay,
anyway,
so
compared
to
what
happens
last
time,
we
got
a
big
big
news
and
we
can
show
the
next
slide.
If
you
don't
know,
remember,
can
the
discussion
whether
we
can
get
already
anionic
code
point
basically
for
the
option
we
have
now.
So
thank
you
to
the
chair
and
Suresh
I.
Don't
know
s
Eurasia
disappear.
So
thank
you
for
this.
It
allows
us
to
make
a
multiple
implementation
of
sending
this
array
option
and
receiving
this
array
option
to
be
compatible
there
and
make
more
tests.
C
We
use
this
number
21
and
I
think
you
know
it's
a
fan
answer
with
21,
but
at
least
we
got
the
number
it's
late
right
answer,
41
anymore
anyway,
it's
like
a
guide
is
obviously
not
read
in
this
room
anyway,
so
we
use
this
number
for
di
cottan
on
this
weekend.
Next
slide
other
change,
so
we
make
the
things
clear.
There
were
a
lot
of
section
regarding
using
the
PVD
additional
information.
Remember
it
is.
The
G
is
on
file
that
we
are
fetching
to
describe
and
the
connection
based
on
the
bandwidth
of
latency.
C
We
even
think
to
change
the
name
into
additional
application
information
to
make
it
very
crystal
clear:
we
try
to
improve
the
security
and
privacy
section.
Of
course,
mostly
we
can
maybe
improve
it.
We
made
a
mistake
in
doing
the
padding.
You
know
all
the
options
in
our
ASO
actually
in
any
neighbor
discovery.
Message
must
be
aligned
on
8
bytes
and
we
basically
at
the
previous
one,
aligning
on
the
four
bytes
so
easy
to
fix.
Last
time
in
Singapore
there
was
a
huge
amount
of
discussion
about
all.
C
Can
we
send
different
information
to
PVD,
aware
host
and
non
PVD
aware
both
so
the
authors?
We
got
a
design
meeting
in
a
nice
room
in
Singapore
we
considered
as
an
option
such
as
using
another
specific
multicast
group
to
send
this
array
to
PVD
away
only
at
this
weekend
of
dirty
and
a
few
other
one.
So
we
end
up
in
an
idea,
not
new
code
container.
Next
slide,
you
don't
mind.
So
that's
the
new
option
and
you
see
them
in
this
option.
C
We
can
add
at
the
bottom
additional
option,
like
Pio
array
of
a
row,
deformation
option
prefix
information
option,
a
with
other
options
that
can
validly
exist
into
a
route
advertisement
can
be
included
into
the
PVD
option,
as
we
need
as
well
sometimes
to
include
options
like
MTU,
which
are
not
per
se
an
option,
but
our
feeling
to
the
array
header
itself.
We
have
the
option
based
on
the
bid
a
to
include
yes
or
no,
a
repetition
of
the
routing
advertisement
header.
So
we
can
add
their
next
slide,
so
example
look
about
this
one.
C
C
Okay,
actually
I
counted
at
least
three
used
it
to
make
12.
So
now
we
put
12
in
the
lines
there,
meaning
next
slide.
A
PVD
aware
understand
deception.
No,
he
is
a
duty
to
look
inside
the
option,
and
now
you
know
that
okay,
the
a
flag
is
not
set.
So
after
the
name
and
the
padding-
and
we
know
the
name
is
finished
because
they
are
lengths
right
is
the
fully
qualified
domain
name
is
expressed
as
a
DNS
request.
Name,
we
have
another
option,
which
is
our
DNS
s.
We
got
the
length
of
this
one.
C
We
go
to
the
next
one
and
so
on
so
for
p,
video,
where
they
will
see
not
only
the
PVD
ID.
It
is
used
to
bundle
all
information
together
and
present
it
to
the
application.
But
we
they
also
got
this
our
DN
SS
and
the
PIO
next
slide
and
non
PVD
aware
do
not
understand
the
type
xxi
that
we
just
receive.
C
So
they
say:
okay,
I
skip
it
and
the
length
is
12,
so
I'm
going
to
the
option,
which
is
after
so
with
this
we
can
present
Pio,
aardeen,
SS
or
whatever
you
want
to
PVD
away
oast,
while
the
options
outside
of
the
container
as
simply
use
only
by
non
p,
video
a
host.
Of
course,
an
array
can
only
contain
if
you
want
just
the
PVD
ID
option.
Okay,
that's
not
a
problem!
Next
line
implementation
status,
nothing
has
changed
compared
to
Singapore.
C
We
make
progress
on
Nanak's,
obviously
next
line
and
the
hackathon
as
I
said,
we
work
together
with
two
universities.
Relation
Aberdeen
got
some
people
from
Cisco,
but
Kyle
is
well
from
San
vine
and
another
University.
Three
I
forget
wenching
from
three
Campari
Tech,
and
basically
it
was
the
mix
of
pvd's
or
9x,
a
neat
which
is
in
another
taps
project
source
address,
dependent
routing
because
we
like
this
and
Cal
port.
It
was
done
by
acharya
next.
C
So
it
has
really
all
the
piece
we
touch
and
all
those
piece
were
using
the
new
ini
code
next,
so
we
are
not
ready
room
class
cold
for
sure,
even
if
the
implementation
exists-
and
we
are
working
for
this
for
more
than
a
year
now,
but
I
would
love
to
get
a
service
review
by
this
group
as
well
as
I
will
ask
later
to
six
men
and
v6
ops,
so
review
are
really
important.
I
mean
modern.
C
Mp3,
apply
two
questions,
of
course
here
and
ring
the
week,
but
you
can't
commit
to
review
this
document
and
it
changed
any
volunteer.
Okay
done,
Ted,
Michael
and
Yin
I,
don't
know
who's
taking
notes,
but
you
can
put
this
into
our.
Thank
you.
Don't
forget
to
put
your
name
right
and
for
me
that's
it.
That's
all.
I
have
to
say
today
and
thanks
again
for
your
support
for
Unicode.
C
C
So
we
provide
into
the
JSON
file
some
information
right
and
we
use
a
specific,
well-known
URL.
So
if
you
know
the
name
of
the
company,
you
can
mostly
guess
the
fully
qualified
domain
name
and
guess
the
URL.
It's
well
known
right
as
on
purpose,
so
you
could
download
from
everywhere
this
JSON
file.
So
my
advice
is
that
don't
put
anything
confidential
here
right
because
anyone
can
igneel
access
and
you
can
also
restrict
the
access
on
the
web
server
hosting
this
JSON
file
to
addresses
that
belongs
to
you.
C
Okay,
working
for
Cisco
I
will
accept
only
request
from
prefixes
allocated
to
Cisco,
not
to
say
another
company.
That's
one
aspect
next
now,
even
if
we
provide
a
PVD
ID,
it
could
be
something
like
example.org
or
whatever.
It's
just
information
right.
We
don't
provide
anything
more
anyway
than
array
but
think
about
a
rock
DVD
I,
don't
know
what
it
was
really
useful
to
do
as
Montana
Tech,
but
we
can
F.
As
I
said,
the
black
ed
we
can
have
the
JSON
file.
C
Server
can
be
a
black
hat
guy,
the
network
can
be
of
style
and
the
first
device
can
be
also
hostile.
So
they
can
basically
send
you
rogue
route
advertisement
if
a
fake
DVD
ID
or
they
can
deliver
to
you,
a
fake
JSON
file
with
wrong
information.
So
that's
all
we
try
to
do
it
now.
Next,
so
first
one
I
am
layer.
C
Two
adjacent
and
I
want
to
send
you
a
packet,
pretending
a
you
are
connected
to
cooperate,
comma,
a
regard
block
it
right,
there's
no
more
dangerous
than
anything,
so
problem
solve
as
long
as
you
run
a
decent
network
next
slide.
So
now,
in
this
case,
the
router
is
a
bad
guy,
so
you
I
not
spot
somewhere
and
the
spot
somewhere
pretends
to
be
again
cooperate,
or
in
this
case
good
calm.
C
So
what
you
do
you
try
to
connect
to
the
JSON
5
server,
and
this
guy
is
a
wrong
one
as
well
right
they
affect
you
DNS
and
they
figure
the
certificate.
Oh,
but
you
cannot
affect
a
certificate
right.
So
when
you
try
and
download
the
JSON
file,
TLS
will
refuse
to
connect,
and
if
you
have
a
look
at
configuration
on
the
end
point
telling
a
I
only
accept
PVD
that
retries
the
fetch
of
this
JSON
file.
C
Now
the
thing
we
have
in
the
JSON
file
a
mandatory
field,
key
which
is
prefix,
which
is
basically
in
this
case
vb8
beef
I,
forget
to
put
a
slash
for
TX
or
in
the
slide.
Now,
when
you
receive
it,
you
need
to
compare
this
covering
prefix
from
the
JSON
file,
with
the
prefixes
you
receive
as
API
or
in
this
case
the
Pio
was
including
bed
/
64
bed
/
64
is
not
including
in
B
/
48
will
reject
it.
C
C
In
this
case,
the
protection
is
very
simple
again
pretty
much
like
the
confidentiality.
The
server
will
only
serve
the
JSON
file
to
its
own
address
and
the
request
after
being
knighted
or
NPDES
is
coming
from
bed.
So
it
drops
the
request.
It
doesn't
receive
the
JSON
file
and
again
I'm
configured
to
use
only
if
there
is
a
JSON
file,
I
don't
get
it
I
refuse
to
use
this
PVD.
C
Next
now
we
find
a
place
and
it's
actually
PA
within
the
room.
We
find
this,
which
is
can
intricate
right.
We
can
fool
everything.
Nothing
is
really
secured
100%.
What
do
we
have?
Now?
We
have
a
bad
guy
bottom
left,
which
managed
to
get
access
to
the
real
network,
so
his
access
in
the
beef,
Network,
okay-
and
you
know
that
the
PVD
is
good
calm
now
with
a
companion
somewhere
and
the
victim
is
on
the
top
left.
The
next
router
is
sending
a
sending
PVD.
C
The
name
is
good
calm
and
please
use
the
address
beef
as
well.
Remember
the
big
arrow
Janel,
whatever
you
want,
is
tuna
right,
GRE
or
whatever.
Now
the
victim
somewhere
on
the
top
left
receive.
Oh,
is
good
calm.
Let's
do
it.
Let's
connect
to
the
server,
and
then
this
is
the
small
line
going
via
the
dinner.
That's
rotting
decision
proxy
by
the
bad
guy
in
the
good
comm
network
that
goes
to
the
server.
C
The
server
sees
a
good
sauce
address
is
surveyed
and
to
NSSL
works,
fine
right
because
the
right
certificate
right
address,
and
then
in
this
case
the
attacker
is
able
to
pretend
is
good
calm
but
on
your
honestly,
is
already
in
good
calm.
So
what
can
you
do
there
right?
So
basically,
in
this
case,
we
can
do
nothing
more,
but
we
never
pretend
to
be
a
fully
secure
right.
Pvd
are
here
not
to
secure
erase
PVD,
sorry
to
give
you
more
information
and
the
application
layer,
and
nothing
is
the
last
100.
C
Yes,
sorry
privacy.
So
obviously
there
is
some
minor
issue.
Is
that
when
the
goose
boat
would
arrest
even
a
PVD
a
wants
to
get
information
about
it,
it
will
basically
go
and
fish
the
error
right
access,
your
elevator
LS.
So
anybody
on
the
path
can
know
that
this
v6
address
is
trying
to
connect
to
this
DVD
right.
It
is
thus
nice
in
the
clear
you
can
even
know
who
is
there?
C
Okay,
but
what's
different
than
all
our
device
run
now
here
going
to
captive
that
example.com
or
whatever
your
operating
system
use
right
now
to
detect.
There
is
a
captive
Potter,
it's
even
better,
because
normally
when
here
all
of
us
in
the
room,
except
some
exception
right,
we
do
not
go
to
our
own
cooperation
to
see
what
there
is
a
captive
portal
right.
We
go
to
some
other
vendors,
which
is
not
Python
the
service
providers
or
the
user.
C
What
indeed,
when
you
use
PVD
you
stay
within
one
Operator,
say
or
support,
or
whatever
that's
one
thing,
and
we
advise
in
the
draft
as
well
it
as
soon
as
you
have
used
your
ipv6
address
to
fetch
this
JSON
file,
you
change
of
a
pv6
address
and
the
other
one
is
no
more
no
more
used.
You
throw
it
away.
That's
basically,
our
status,
a
little
bit
fast,
explained
its
little
bit
more
explanation
into
the
draft.
C
A
So
maybe
we
have
asked
the
the
security
Directorate
to
take
a
look
to
give
us
another
point
of
view.
Okay,
so
hopefully
they
will
provide
some
feedback,
I
guess
they
were
swamped
by
this.
He
knows
this
meeting
I
mean
so
not
yet,
but
hopefully
we'll
get
some
song
external
point
of
view
and
take
a
look
at
this
answers.
I
don't
know
if
everything
is
capturing.
The
in
the
eye
wants
to
you:
okay,
perfect,
okay,
so
thank
you
and
thank
you
for
asking
Thanks.
E
So
there's
two
drafts
that
we'll
talk
about
so
one
is
base.
Goo
draft,
that's
in
version
5.
It
is
in
working
group.
Last
call
not
a
lot
of
comments
in
the
last
call,
but
we
did
have
quite
a
few
pretty
in-depth
reviews.
Previously,
the
only
major
change
to
the
latest
revision
goo
version
became
goo
variant,
so
joke
touch
had
a
concern.
That
version
implies
kind
of
precedents
for
obsolescence
of
previous
versions.
E
E
So,
just
a
couple
of
possible
future
updates,
so
one
of
the
things
we
may
do
the
C
type
field
right
now.
If
the
control
bit
is
said
in
one
of
the
goo
header,
this
indicates
a
control
type.
It
occurred
to
me
that
you
will
encapsulate
any
IP
protocol,
but
there
are
things
that
we
may
want
to
encapsulate
in
the
future,
for
instance
another
UDP
based
protocol.
So,
for
instance,
we
could
have
Lisp
over
go
a
beer
over
go
the
reason
to
do
that
is
goo
kind
of
provides
some
general
and
capsulation
features
and
capabilities.
E
It's
not
really
about
specific
use
cases.
So,
for
instance,
if
you
wanted
to
add
fragmentation
of
go
to
something
like
list,
we
could
do
that.
So
it's
a
possible
thing.
We
could
add
another
thing
that
could
be
pondered
as
I'm,
adding
a
private
data.
So
goo
has
this
concept
of
private
data
within
the
header,
but
we
never
really
specified
a
format
for
that
conceivably,
we
could
add
a
flag
field
that
says
what
the
format
is,
so
it
could
be.
Some
sort
of
tlvs
or
additional
types
of
format
could
be
an
embedded
alternative
protocol.
E
So
one
possibility
the
other
thing
is
goo
is
udp-based.
However,
it's
not
really
inherent
that
it
has
to
be
in
UDP
conceivably.
We
can
make
it
an
IP
protocol
in
itself
or
Ethernet
code,
point,
probably
a
little
easier,
since
it
has
a
larger
space.
The
advantage
of
that
is
would
be
kind
of
a
common
encapsulation
protocol,
similar
to
how
GRE
operates
in
those
three
modes,
but
in
case
of
goo
might
be
a
little
more
extendable
in
the
future.
E
So
the
other
draft
is
go
extensions.
This
is
in
version
3
again
in
working
group.
Last
call
not
many
comments.
It
has
received
some
some
review.
The
current
state
is,
there
are
eight
extensions
defined
and,
like
I
mentioned
they're
really
about
encapsulation
and
an
11
of
16
flag
bits
have
been
allocated
so
the
obvious
problem
here
is
we
only
have
16
flag
bits.
So
what
happens
when
we
run
out
of
flag
bits,
because
we
had
extensions?
E
The
answer
to
that
which
is
actually
on
the
next
slide.
The
antenna
is
at
the
last
bit
in
the
flag
field
will
indicate
a
new
set
of
flags
as
in
another
field,
this
was
actually
an
earlier
version
of
good.
We
removed
it
because
the
point
was
that
our
definition
of
defining
Flags
we
wanted
to
find
them
contiguously.
So
in
the
future,
once
we
hit
the
limitation,
that's
last
bit
is
intended
to
give
us
another
set
of
flag
fields,
and
then
that
gives
us
32
more.
E
E
Few
extensions
really
are
just
about
encapsulation,
not
specific
use
cases.
So
for
specific,
specific
use
cases
we
would
want
to
put
those
in
a
different
place
in
the
packet
either
the
private
fields
or
inside,
like
I
said
we
could
have
an
encapsulation
of
another
type
protocol
and
I
forgot
to
mention.
So
we
didn't
make
one
major
edition
in
the
latest
version
of
the
go
extensions.
That's
an
alternate
checksum.
This
is
something
similar
to
UDP
options.
In
this
case
we
have
a
crc32
CRC,
16
and
CRC
ccitt.
E
The
reason
why
there's
two
CRC
16
it
was
really
difficult
to
find,
which
one
kind
of
has
is
more
important,
they're,
both
equally
used
in
different
contexts,
so
UDP
options,
for
instance,
you
is
that
the
latter
linux
turns
out.
It
has
the
first
one
implemented
so
they're
both
there.
The
good
news
is
that
it's
a
configuration
thing,
so
you
can
only
use
this
if
both
sides
kind
of
agreed
on
it.
Anyway,
there
was
one
important
point
and
I
think
this
is
actually
coming
out
in
UDP
options.
E
Also,
if
we
make
a
CRC
or
security
field
or
anything
like
that
optional
and
it
covers
the
header,
they
do
not
protect
the
actual
option.
So,
for
instance,
if
this
were
a
TLV
and
we
had
a
TLV
type,
it
said
this
is
a
CRC.
If
that
TLV
type
became
corrupted,
it
would
turn
into
something
else.
The
receiver
might
not
see
the
CRC,
so
the
value
of
having
the
CRC
goes
down.
If
this
is
one
reason
why
we
like
to
have
like
TCP
check
sum,
UDP
checksum
are
inherent
in
the
packet.
E
E
So
the
idea
is
the
I
guess
that
the
31st
bit
would
be
the
e
bit
and
that
will
point
to
a
new
flag
field,
so
that
32-bits
it
looks
like
just
like
any
other
Flags
field,
but
when
we're
processing
the
flags
after
the
initial
flags,
our
process
will
hop
down
to
that
and
then
continue
processing,
flags
and
then
fields
for
those
flags
follow
all
of
that's
fairly
straightforward
thinking
about
new
possible
new
extensions,
I
think
the
OEM
measurement
bits.
So
there
are
two
of
them
defined
for
8321.
E
G
F
E
It's
it's
a
two
bit
field,
so
we
have
four.
We
have
three
combinations,
so
crc32
kind
of
makes
sense,
because
that's
either
at
CRC.
But
the
argument
there
is
well
that's
kind
of
expensive.
So
what
about
a
CRC
16?
So,
like
I
said
it
was?
It
was
kind
of
a
coin
toss
I
did
not
have
a
strong
opinion,
but
I
couldn't
find
any
good
precedence
either
with
an
IETF
or
with
in
general
networking
community
about
which
is
preferred
I.
Don't
think
it
particularly
cost
us
anything
except
a
couple
of
flag
bits.
Yeah.
F
F
Crc
the
earth
you
can
choose
either
CRC
and
30
to
depend
on
what
you
want.
What
you
think
is
better
I
mean
it.
They
don't
have
that
much
different
properties.
There
is
a
document
actually
discusses
the
difference
between
the
two
computationally.
It's
not
that
much
more
expensive
than
their
CRC
16
I.
Don't.
E
Have
a
strong
opinion
honestly:
if
we
can,
we
can
chuck
the
CRC
16.
If
that's
fine
I
would
point
out
one
thing
that
we
did
do
all
the
CRC's,
the
checksum
that
we
have
and
the
security
they
all
have
the
length
field.
So
it's
kind
of
like
a
UDP
light
thing,
so
we
cover
so
it
is
optional.
Data
included,
so
I
kind
of
like
that
aspect
of
it
like
I,
said
I,
don't
have
a
strong
opinion.
It's
that's
good
feedback.
H
They've
heard
like
verbal
ink
CRC
hurts
you
oughta,
hey
you
you're,
trying
to
verify
integrity.
You
shouldn't
make
it
more
complex.
Let
me
give
if
you
want
to
use
more
than
one
format.
Let
me
give
you
a
second
option
and
explain
why
it's
cheaper
and
why
it
helps
the
second
option
is
to
grab
the
grab.
What's
commonly
known
as
the
I,
scuzzy,
CRC
or
crc32,
see.
There's
two
good
reasons
to
do
this.
One
is
the
polynomial
is
different.
H
H
E
F
Gory,
fascist
is
TS,
VW
culture.
Why
don't
you
just
ask
auntie
s
vwg,
because
if
you
want
to
choose
a
CRC,
then
I
think
you'll
get
some
feedback,
wait
which
one
Oh
ask
about
your
chosen
CRC.
Is
it
suitable
on
TS,
vwg,
okay,
yeah
on
the
transport
area,
will
give
you
some
fever
a
lot
and
different
other
prom
skills?
Okay,
that's
a
good
point.
E
So
we
have
the
ILA
buff
on
Thursday.
This
is
a
non
working
group
forming
boss.
The
intent
is
to
highlight
problem
statement
use
cases.
This
is
not
intended
to
be
an
in-depth
discussion
in
of
solutions,
and
we've
had
quite
a
bit
of
discussion
on
the
mailing
list.
So
since
last
IETF
there
was
an
ila
mailing
lists
created.
A
lot
of
the
discussion
gets
down
into
security,
scalability
mapping
systems,
denial
service
threat
and,
most
recently,
there's
discussion
on
an
Iowa,
Lisp
kind
of
control
plane.
So
the
idea
is
to
use
list
control
plane
for
ila.
E
That's
a
pretty
promising.
There's
also
been
some
discussions
on
DMM
and
the
five
gang
an
IP
list.
Those
discussions
tend
to
be
more
specific
to
the
mobile
use
case.
It
would
point
out
that
ila
is
kind
of
trying
to
be
a
generic,
but
mobile
is
one
of
the
use
cases,
data
center,
virtualization
network
virtualization
or
some
of
the
others
we're
also
looking
at
the
3gpp
steady
item
that
they're
looking
at
perhaps
ila
could
be
part
of
that
solution.
E
So
that
I'm
getting
a
little
bit
of
update
on
the
data
plane
discussions,
so
ila
is
explicitly
not
encapsulation,
and
that
means
there
are
no
bits
at
it
to
do
transformations.
So
we
have
no
extensibility
no
way
to
encode
everything.
In
that
sense,
it's
kind
of
the
the
opposite
of
generic
UDP
encapsulation.
E
What
that
means
is
everything
needs
to
fit
into
basically
the
destination
address,
and
the
idea
idea
viola
is
that
we
transform
addresses
in
order
to
get
them
to
their
destination
and
before
the
receiver
actually
gets
the
packet
we
always
transform
back
to
the
original
address.
So
it's
kind
of
like
a
paired
address
modification
so
because
everything
fits
needs
to
fit
into
this
small
space.
We
have
relaxed
a
little
bit
on
the
canonical
64
64
split
so,
for
instance,
in
il
NP.
E
There
was
this
idea
of
a
64
bit
locator
64
bit
identifier,
that's
kind
of
some
simple
architectural
e,
but
when
you
start
thinking
about
different
encodings
and
different
things,
you
might
want
to
do
it's
a
little
less
flexible,
so
we're
relaxing
on
that,
and
that
gives
us
the
ability
to
do
some
interesting
techniques.
One
of
the
techniques
is
locator
indexing
which
you
would
use
if
we
wanted
to
encode
/
64
assignments
into
il
a
another.
One
is
chaining,
so,
instead
of
just
doing
one
il
a
transfer
transformation,
we
may
do
multiple
ones
on
the
path.
E
This
is
kind
of
a
poor
man's
segment,
routing
where
we
can
adjust
the
destination
address,
have
the
packet
visit
certain
destinations
based
on
hop-by-hop
routing
and
at
the
very
end
again
the
packet
has
to
be
transformed
back
into
the
original
packet,
so
that
the
receiver
has
no
idea
that
this
happened.
This
does
represent
a
bit
of
a
trade
off.
So
in
order
to
keep
the
data
plane
simple,
that
implies
a
little
more
complexity
in
the
control
plane.
So
that's
kind
of
the
the
ILA
trade-off.
E
The
control
plane
pretty
quickly
gets
to
identify
your
locator
split,
scalability
type
of
issues,
and
this
has
a
lot
to
do
with
mapping
systems
an
identifier,
locator
split.
We
do
think
there's
gonna
be
mapping
systems,
so
imagine
a
large
network.
Everything
is
somehow
virtualized
or
mobile.
We
need
a
way
to
find
out
where,
where
identifiers
are
identifiers
are
basically
the
logical
nodes.
So
for
that
we
need
a
mapping
system.
This
is
pretty
I,
guess
pretty
accepted
in
the
identifier
locator
space.
E
So
the
question
right
now
is
how
to
do
this
mapping
system
it's
little
little
independent,
violate
I
think
there
are
some
things
that
ila
kind
of
implies
in
a
mapping
system,
but
fundamentally
the
mapping
system
does
have
kind
of
four
pillars:
the
scalability
security
privacy
and
das
ability
aspects.
So
I
think
a
lot
of
that
will
come
out
in
the
ILA
Boff,
maybe
a
little
bit
more
detail
but
again
the
solution.
E
A
E
Okay,
one
more
so
this
is
like
kind
of
an
out
offshoot
of
some
of
those
things.
We've
been
looking
at
ila,
and
this
is
particularly
looking
at
the
privacy
and
prefix
assignment
so
I.
We
have
a
few
caveats
up
front
just
to
make
it
clear,
so
this
is
only
considering
privacy
at
the
networking
layer,
specifically
in
addressing
privacy
itself
on
the
internet,
has
to
be
considered
every
layer.
We
know
that
this
is
considering
one
aspect
of
that.
E
This
is
also
only
considering
risk
from
third
parties
interpreting
or
inferring
information
from
IP
addresses,
so
that
specifically
means
we're
not
considering
network
providers
that
have
say
for
mapping
of
IP
address
device,
it's
up
to
them
to
to
secure
that
data
and
I'm,
not
sure
we
can
do
much
technically
to
solve
that
problem
and
equivalent
equivalently.
This
doesn't
address
law
enforcement
or
authorities
who
can
compel
say
network
providers
to
release
that
information.
So,
like
I
said
those
are
caveats
up
front.
We
understand
that
and
privacy
is
a
multi-pronged
problem,
as
we
know.
E
So
what
about
prefix
assignment
so
/
64,
addressing
it
to
host,
is
actually
becoming
quite
common,
so
slack,
for
instance,
is
doing
that
and
it's
actually
pretty
common
in
mobile
networks.
You
E's
get
full
/
64.
This
actually
recommended
no
RC
33
14,
so
that
gives
us
some
properties
and
since
the
prefix
is
being
assigned
to
the
device,
that
means
there's
kind
of
a
1:1
relationship
between
a
prefix
and
a
device.
So
given
two
addresses
that
share
the
same
prefix,
even
if
the
ID
is
different,
the
interface
identifier.
E
In
this
scenario,
they
actually
would
refer
to
the
same
device
and
that
becomes
a
little
more
problematic
in
the
case
that
we're
assigning
to
say
a
Ewing
in
a
mobile
network
like
a
smartphone,
then
there,
because
of
much
higher
probability,
that
that
devices
actually
corresponds
to
a
specific
user.
So
now
we
have
a
one
to
one
relationship,
potentially
between
the
prefix
and
then
actual
user
and
another
issue.
Prefix
may
contain
fine
grain
hierarchy
for
routing
and
that's
going
to
have
to
do
become
a
problem
if
that
reveals
location
of
the
device
and
hence
the
user.
E
So
the
privacy
issue
is
kind
of
implied
from
that
the
prefix
becomes
an
identifier
for
the
device.
The
addresses
are
used
in
the
public
internet.
So
if
a
third
party
knows
that
a
site
is
assigning
prefixes,
then
if
it
sees
two
addresses,
it
can
infer
that
they
are
the
same
device
if
they
have
the
same
prefix.
So
this
exposes
the
risks
of
revealing
user
identity
and
communicate,
Shen's
and
location
location
of
users.
E
So
we
could
extrapolate
from
our
C
49-41
to
just
change
the
prefix
periodically
and
conceptually
that's
possible.
We
do
know
that
changing
addresses.
If
there's
only
one
and
you
change
it
periodically
will
probably
kill
all
the
existing
flows
and
they
have
to
be
restarted.
So
assuming
we
solve
that
problem,
then
the
real
question
becomes.
What
is
the
correct
frequency
to
change?
E
Addresses
in
order
to
ensure
privacy
and
it's
a
tricky
question
I
did
pose
this
on
a
couple
of
lists
and
there
really
isn't
a
very
good
answer,
because
someone
could
say
a
day
or
a
week
or
an
hour
and
there's
no
way
to
quantify
what
kind
of
privacy
you
get
out
of
that.
So
the
conclusion
that
I
posted
it
was
anything
less
than
a
different
address
per
connection
or
per
flow
theoretically
could
have
a
privacy
exploit
and
actually
gave
an
example
in
the
in
the
draft.
E
What
can
I
infer
from
these
two
addresses,
and
it
is
obvious
that
you
can
infer
they're
from
the
same
provider
same
organization,
so
they
will
share,
say
a
common
network
prefix,
that's
kind
of
basic
and
maybe
also
that
they
belong
to
a
very
broad
geographic
grouping,
so
would
be
expected
that
a
large
organization
would
probably
want
to
have
some
Geographic
or
regional
hierarchy.
But
beyond
that,
the
idea
is.
The
viewer
of
these
addresses
should
not
be
able
to
do
this
any
other
information.
E
Specifically,
they
can't
tell
that
the
notes
that
are
associated
with
these
addresses
are
not
the
same
node
or
in
the
same
rack
or
at
the
same
location
or
have
any
other
proximity,
so
that's
I,
think
kind
of
a
I,
don't
think
it's
strict
I
think
that's
just
some
criteria
for
privacy.
Addressing
that
will
propose
now.
I
would
point
out
that
network
address
translation
net
can
actually
meet
these
criteria.
E
If
there's
a
large
enough
address,
pull
because,
basically,
what
NAT
does?
Is
it
obvious
gates?
The
underlying
addresses
of
the
network
and
what
you
get
on
the
wire
on
the
Internet
is
the
address
of
the
net
device
and
some
port
number,
and
the
port
number
refers
to
the
specific
instance,
but
external
users.
They
don't
see
that
so
it
turns
out
net,
actually
meets
these
strong
criteria
as
pointing
on
the
document.
E
So
the
document
does
present
a
possible
solution
and,
like
I,
said
this
kind
of
wasn't
sub
problem
of
NAT
or
not
at
NAPA
to
vial
a
so
with
identifier,
locator
split.
The
idea
is
that
we
can
use
identifier
locator
split,
so
the
identifier
becomes
independent
of
location
and
we
can
assign
multiple
identifiers
x',
hence
untrackable
addresses
to
host
the
address
is
still
share
a
common
prefix,
but
if
this
is
done
with
enough
randomization,
they
would
share
nothing
else.
So
to
address
is
assigned
to
a
host.
E
The
same
host
would
have
nothing
in
common
except
that
prefix,
so
that
would
meet
the
strong
criterion
and
then
add
a
privacy
and
a
dressing
so
for
maximum
privacy.
Then,
because
of
the
the
result
that
we
need
to
use
an
address
per
flow
means.
We
have
a
lot
of
addresses,
potentially
that's,
obviously
a
scaling
problem.
E
So
looking
at
some
of
the
potential
mitigations
there,
one
thing
is
not
everyone
necessarily
needs
his
privacy,
so
in
some
sense
this
could
be
a
service
if
somebody
really
needed
that
level
of
privacy
in
one
of
the
one
time
yes
address.
This
could
be
a
way
to
accomplish
that.
Maybe
there
are
other
communications
or
aren't
necessarily
that
private.
They
don't
need
that.
Obviously,
that's
not
a
great
solution,
because
now
we're
forcing
the
user
to
make
a
decision
and
we'd
rather
give
them
perfect
privacy
all
the
time.
E
So
another
way
to
look
at
this
problem
is
what
we're
actually
trying
to
do.
We
actually
want
to
aggregate
addresses
as
being
as
belonging
to
the
same
host,
so
we
can
get
the
addresses
to
the
right
host
and
that's
the
problem
that
the
mapping
system
has.
So
there
is
aggregation
here,
so
the
question
we're
pondering
is:
can
we
do
a
sort
of
hidden
aggregation
where
the
network
can
assign
a
host
a
block
of
addresses
and
to
the
outside
world?
E
This
block
looks
completely
randomized,
however,
the
network,
either
through
some
sort
of
public
key
encryption
or
some
type
of
hash,
is
able
to
deduce
that
these
addresses
actually
aggregate
to
the
same
node
in
this
case.
So
this
is
the
concept
of
hitting
aggregation,
so
the
first
level
would
be
local
network
has
a
way
to
create
these
addresses,
assign
them
to
the
hosts,
and
only
the
local
network
would
understand
this.
E
If
that
problem
is
solved,
then
the
question
becomes:
how
do
I
do
a
bulk
aggregation
because
we
still
don't
want
to
have
to
give
hosts
individual
address?
Theoretically,
they
could
require
thousands
or
millions
of
these.
Is
there
a
way
to
give
a
host
a
way
to
create
a
block
of
addresses
itself
and
whatever
needs
a
new
address?
It
can
create
an
address,
say
we
give
it
blocks
of
64,000
IP
addresses
and
it
can
use
them
as
needed
and
when
it
runs
out,
it
can
ask
for
new
ones.
E
G
G
Is
I
think
this
is
useful
having
prefix
privacy
I?
Think
if
you
compare
it
to
the
privacy
for
hosts
as
it
stands,
you're
probably
going
to
want
to
be
able
to
have
persistent,
prefixes
and
private
prefixes.
So
you
need
to
be
able
to
somehow
delegate
a
prefix,
that's
Marxist
for
use
as
a
kind
of
a
privacy
review.
First
I
guess
so.
E
G
Well,
if
I
was
say,
for
example,
in
mine,
something
has
been
allocated
to
my
home
network,
for
example-
then
maybe
having
a
rotating
prefix
out
of
the
ISPs
prefix,
that
I
can
use
to
initiate
new
connections
for
movie
good
thing,
while
I've
still
got
a
persistent
prefix,
that
I
can
have
my
services
on
without
running,
don't
DNS
or
other
things
to
update
and
essentially
have
to
renumber
my
network.
Every
time
you
continue
and
privacy
prefix
I
think
would
be
important.
Well,.
E
I
mean
so
I'm,
not
sure
it's
it's
so
much
for
numbering
right,
it's
more
temporary
address
assignment
I
think
is
the
best
way
to
phrase
it,
so
the
addresses
could
be
requested
on
demand
in
some
sense.
So
obviously,
if
you
want
a
persistent
prefix
because
you're
a
server,
then
that
that
might
be
a
different
story,
yeah.
J
G
Problem
with
doing
this
big
block
and
giving
a
host
Zeeland
addresses
that
it
can
use,
you
are
into
all
sorts,
the
other
things
that
have
been
discussed
for
things
like
nd
cache,
exhaustion
and
so
on.
There's
all
sorts
of
things
that
if
you
try
and
use
an
address
per
application,
they're
going
to
hit
you
in
in
otherwise
I.
G
A
K
K
Yes,
you
can
declare
ISP
sort
of
privacy
to
be
out
of
scope,
but
the
fact
of
the
matter
is:
if
we
build
the
scheme,
then
the
ISP
has
to
maintain
a
record
of
everything
that
you
did,
whereas
in
the
case
where
it
has
to
keep
every
base,
essentially
every
tea,
every
TCP
connection
right,
whereas
in
the
ski,
where
the
SP
just
assigned
to
your
prefix
that
rotates
they
don't
have
to
keep
all
that
information
about
you.
So,
yes,
you
could
declare
it
out
of
scope
but
you're,
basically
moving
a
slider
around
where
you
know.
K
E
K
E
E
At
that
time,
I
think
that's
that's
the
argument
that
law
enforcement
is
making,
but
it's
not
clear
to
me
why
that
or
that
argument
is
because
it
seemed
like
the
nat
logs
are
sufficient,
in
which
case
if
the
net
logs
are
sufficient,
then
the
logs
of
address
assignment
in
this
case
should
also
be
sufficient.
At
least
that's
my
understanding
of
the
problem
so.
K
E
K
You're
behind
in
that,
if
you
have
the
logs
yeah,
nothing
that
keeps
lux,
but
so
like
I
said,
I
think
it
was
not
necessarily
a
specific
suggestion
about
these
points.
I
think
I
think
basically
I
think
basically
declaring
that
attack
vector
to
be
out
of
scope
is
an
error,
because
it
means
that
we
can
like,
because
it
means
that
any
solution
that
entirely
gives
the
ISP
with
access
TSP
all
this
information,
basically
we're
completely
disregarding
that
downside,
because
the
way
we
set
the
goals
right
but.
E
E
K
K
E
Right,
but
look
at
this
way
if
I
saw
assign
an
address
now
and
they
use
it
only
for
one
connection,
then
they
only
use
it
for
one
connection,
the
ISP
doesn't
know
what
connection
they
use
that
for
it's,
not
it's
not
like
NAT.
Now
you
actually
have
more
information,
because
that
is
about
the
actual
connection.
This
is
I
mean
it
I
know
it's
a
subtle
point.
This
is
just
the
address
assignment.
That's
what
needs
to
is
what
needs
to
be
tracked
when
the
request
doesn't
say:
I
want
to
create
a
connection
to
this
destination.
K
K
A
I
G
M
M
A
lot
and
I
understand
their
perspective
and
the
perspective
on
a
situation
like
this
would
be
and
that
if
there
has
been
some
criminal
activity
and
that
activity
is
associated
with
a
particular
IP
address,
what
the
law
enforcement
officer
is
going
to
be
interested
in
is
who
was
controlling
that
IP
address
at
a
particular
time
at
the
moment,
almost
everywhere
in
the
world.
I
can't,
obviously
I
can't
speak
for
the
entire
planet,
but
everywhere
that
I've
ever
worked.
M
It
has
been
a
requirement,
a
regulatory
requirement
on
ISPs
to
be
able
to
identify
their
customers,
and
this
touches
on
what
I'll
be
talking
about
later.
But
it
seems
to
me
that
whether
a
whole
block
of
64
IP
addresses
is
allocated
to
a
particular
person
to
a
particular
host
or
whether
the
IP
address
has
to
keep
connection
logs.
There
are
two
solutions
to
the
ultimate
problem,
which
is
that
ISPs
will
be
required
under
regulation
to
be
able
to
identify
their
subscribers
now.
So
that
was
my
first
point.
M
Whatever
way
it
pounds.I,
that's
gonna
be
the
case.
The
other
point
that
I
wanted
to
make
was
I
am
of
the
opinion.
I
hope
this
is
not
too
controversial
comments
that,
for
a
plethora
of
reasons,
connection
logging
is
a
terrible
idea,
and
the
main
reason,
I
think
is
the
risk
of
loss
of
that
data
is,
is
huge
to
the
privacy
of
the
individuals
concerned.
M
So
ISPs
have
data
breaches,
just
like
everybody
else,
and
if
all
my
connection
logs
got
out,
they
can
see
everything
that
I
was
browsing
at
every
moment
and
so
on
and
so
forth,
which
is
why
and
I
I'm
resistant
to
that
idea.
So
as
long
as
there
is
some
alternative
mechanism
by
which
individuals
like
ISPs
can
meet
the
regulatory
obligations
to
be
able
to
identify
to
subscribers,
that's
really
the
point
that
I
wanted
to
make.
E
Okay,
those
are
good
points
but
again
I
point
out
that
the
this
solution
actually
is
not
connection
logging.
It's
more
budget
address
registration,
so
it's
effectively
what
we
have
today
with
a
prefix
to
device,
but
it
might
be
a
greater
scale,
so
it'd
be
address
to
device,
but
it
wouldn't
be
going
as
far
as
NAT,
which
is
clearly
connection
logging,
so
that
that
wouldn't
occur
and
I'm,
assuming
that
law
enforcement
has
to
have
NAT
logs
today
already.
L
L
K
New
to
this
area,
I
work
mostly
at
the
web
level,
but
and
I'm
particularly
curious
about
you're.
Talking
about
the
timing
of
rotation
of
rotating
identifier,
z'
and
I
feel
like
there's
a
particular
concern
about
like
that.
If
we
have
too
many
AI
identifiers
that
are
getting
rotated
at
different
times,
we
might
lose
the
privacy
benefit
of
rotating
identifiers.
K
E
So
real
quick,
so
one
I
think
the
client
should
have
the
control
plane
gets
addresses
from
the
provider.
Client
should
use
them
as
it
sees
fit.
So
I
think
that's
pretty
clear.
Two.
Please
look
at
the
draft
because
I
give
the
example
a
potential
exploit
that
could
defeat
any
frequency
except
once
per
connect
or
once
one
per
flow.
E
That
example
hasn't
been
refuted,
so
it
may
be,
may
be
accurate.
So
if
you
have
any
ideas
on
whether
it
could
actually
happen,
I
I've
received
this
one
thing,
I
think
is:
privacy
is
probably
such
a
big
problem
that
maybe
HAP.
Maybe
the
attackers
haven't
gone
down
to
this
level
yet,
but
I
do
think
it's
gonna
be
a
problem
at
some
point
doing
it.
Oh
thank.
J
Helooo
ron
Bonica,
the
chairs,
have
asked
me
to
shorten
the
presentation
up
a
little
bit
so
I'm
gonna
skip
over
a
couple
slides
this.
This
craft
used
to
be
called
ipv6
fragmentation
considered
fragile
and,
as
we
were,
writing
it
realized
most
of
our
criticisms
applied
to
ipv4
as
much
as
ipv6.
So
we
renamed
it
it's
now.
Ip
fragmentation
considered
fragile.
J
What
are
we
doing
in
this
draft?
Well,
we've
known
for
a
long
time.
Fragmentation
reduces
the
reliability
of
internet
communication
in
this
document.
We're
going
to
talk
about
what
fragmentation
is
a
little
bit
and
that
we
do
it
with
document
we'll
skip
over
it
in
the
presentation
we'll
talk
about
how
fragmentation
fragmentation
reduces
reliability
and
we'll
put
out
some
recommendations
for
protocol
developers
and
network
operators
now
keep
in
mind
we're
not
talking
about
deprecating
fragmentation
that
just
can't
be
done.
J
So
there's
some
terminology:
you
need
to
know
to
play
the
game.
I'll
assume
that
you
all
everybody
in
this
room
knows
what
an
MTU
the
minimum
link,
MTU
and
PMT
you
is
I'll.
Also
assume
everybody
in
the
room
knows
how
IP
fragmentation
works.
I'm
just
gonna
point
out
two
things:
one
is
a
small
difference
between
how
ipv4
fragmentation
works
and
ipv6
fragmentation
works.
An
ipv4.
You
have
this
thing
called
the
DF
bit.
If
it
is
set,
a
packet
cannot
be
further
fragmented
downstream.
J
J
The
next
thing
that
fragmentation
has
in
common
between
ipv4
and
ipv6
is
when
you
fragment
a
packet,
you
divide
it
into
pieces.
The
upper
layer,
header
always
appears
in
the
first
fragment.
It
never
appears
in
subsequent
fragments
this.
This
observation
about
where
the
upper
layer
header
is,
is
what
brings
half
of
the
fragility
into
the
argument
now.
J
In
an
environment
where
only
the
source
can
fragment
a
packet,
the
source
of
a
packet
needs
to
do
one
of
three
things:
either
restrict
itself
to
sending
packets
that
it
knows
will
never
be
fragmented.
That's
for
ipv6,
never
sending
a
packet
back
bigger
than
12
80
for
ipv4
and
never
sending
a
packet
bigger
than
some
arbitrarily
small
size.
J
So
that's
one
thing:
it
can
do
another
thing
it
can
do
is
PMT
UD
path,
MTU
discovery,
so
it
discovers
the
MTU
of
the
path
ahead
of
it,
and
the
third
thing
is
packetization
layer,
P,
MTU
discovery
and
we'll
talk
about
each
of
those
for
a
second
PM
tud.
The
source
node
makes
an
initial
estimate
of
the
PMT
you
to
a
destination.
That
estimate
may
be
too
large.
It
then
starts
sending
packets
to
the
destination.
If
the
packet
is
larger
than
the
actual
PM
tud
of
the
actual
PM
to
you,
it
will
not
be
fordable.
J
It'll
get
dropped
and
a
downstream
writer
router
will
send
an
ICMP
packet
too
big
message
to
the
source,
the
source.
Having
received
that
will
update
its
estimate
of
the
PM
to
you.
Now
this
strategy,
PMT
UD,
absolutely
requires
the
network
to
be
able
to
deliver
ICMP
PT
P
messages,
if
it
can't
do
that,
it's
black
hole
time.
J
The
next
alternative
is
PL
PMT
UD.
Here
we
push
the
problem
up
to
the
packetization
layer.
The
packetization
layer
will
say:
TCP
in-band
sends
packets
of
different
sizes
to
its
TCP
peer.
What
it's
doing
is
probing
to
find
the
PMT
you.
It
relies
on
two
things.
Primarily,
it
relies
on
acknowledgments
of
its
probes
at
the
TCP
layer.
It
can
also
rely
on
ICMP
feedback,
but
then
again
it's
perfect
in
PLM,
PLP,
MTU
D.
The
endpoint
is
perfectly
able
to
ignore
the
ICMP
messages.
It
doesn't
need
them
at
all.
J
Plp
MTU
D
is
defined
for
TCP
in
RFC
48:21,
it's
being
defined
for
some
other
protocols
and
draft
Fairhurst
going
on
in
the
TSV
working
group.
Sadly,
it's
not
defined
for
UDP
and
it
can't
be
because
PLP
MTU
D
kind
of
assumes
a
long
live
session.
Well,
a
session,
not
a
one
in
dumb
packet,
the
other
thing
about
PLP,
MTU
D.
It
doesn't
rely
on
ICMP
ptb
messages
at
all.
If
they're
all
dropped,
PLP
MTU
D
still
works
just
fine,
so
we've
talked
about
the
status
quo.
Now
it's
time
to
leap
in
and
talk
about.
J
Why
is
it
that
fragmentation
makes
communications
unstable
or
fragile?
Well,
one
problem:
well,
these
problems
all
link
back
to
the
problem
that
the
frag
only
the
first
fragment
has
the
transport
layer
header
in
it.
What
are
the
impacts
of
that?
Well,
let's
say
for
a
minute:
you're,
a
load
balancer
and
you're
a
load
balancer
that
load
balance
is
on
TCP
ports
if
the
TCP
port
is
only
in
the
first
fragment
you're
bound
to
suboptimal
load.
J
Balancing
next
issue
is
firewalls,
let's
say
you're
a
firewall
and
you
have
a
rule
that
says:
block
all
packets
based
on
the
TCP
destination
port.
Well,
you
can
configure
that
firewall.
Two
ways
one
way
is
to
accept
all
subsequent
fragments.
That's
a
little
bit
too
liberal.
Another
way
is
to
drop
all
subsequent
fragments
that
one's
a
little
too
restrictive,
there's
no
healthy
middle
ground.
Other
middleboxes
can
have
the
same
kinds
of
problem
because
they
need
access
to
the
TCP
header
or
the
transport
layer
header,
for
instance.
J
J
There
are
some
other
well-known
problems
with
fragmentation
that
don't
have
to
do
with
the
TC,
with
the
transport
layer
header
not
being
in
subsequent
fragments.
There
are
bunches
of
security
vulnerabilities
that
have
been
documented
over
the
over
the
years:
overlapping
fragment
attacks
like
the
ROS
attack,
resource
exhaustion,
attacks
and
many
more.
We
won't
go
into
them
now,
they're
in
the
draft,
but
there's
an
interesting
problem:
around
TCP
loss
around
ICMP
loss,
PM,
tu,
PM,
tu
d-
fails
when
you
are
losing
ICMP
packets,
ICMP
packets
can
be
lost
for
bunches
of
reasons.
J
One
is
because
network
operators
are
filtering
them,
they
shouldn't
there's
an
RFC.
That
said
that
says
they
shouldn't
another
is,
you
know
just
play:
don't
packet
loss
or
rate
limiting
those
things
happen,
but
they're
not
insurmountable
problems.
There
is
at
least
one
insurmountable
problem
and
it
has
to
do
with
any
caste
I'll
give
you
this
example
from
Jeff
Houston's
work.
J
J
That
response
gets
to
a
point
where
it
cannot
be
forwarded
because
of
an
MTU
problem,
so
the
node
that
could
not
forward
the
DNS
response
sends
an
ICMP
message
back
to
the
of
the
packet.
The
source
of
the
packet
is
in
anycast
address
and
it
goes
to
some
DNS
server
that
has
that
anycast
address,
unfortunately,
not
the
one
that
sent
the
packet
that's
problematic,
it's
black
hole
time.
J
A
J
We
have
some
solutions
at
the
transport
layer.
We've
talked
about
them
already,
we'll
go
quickly.
Let's
get
to
the
recommendations,
so
I
can
yield
the
floor.
We
have
some
recommendations
to
application
developers
that
they
should
not
develop
applications
that
rely
on
a
PI,
P
fragmentation
and,
what's
more,
if
there
were
any
that
accrue
shal
to
the
Internet
infrastructure,
they
should
be
rethinking
those
applications,
so
they
will
rely
less
on
IP
fragmentation.
J
The
next
is
for
network
operators.
They
must
not
filter
ICMP,
Petey
B's,
that's
already
in
another
RFC,
so
it's
not
crucial,
but
the
big
one
is
for
DNS
and
especially
when
DNS
is
using
DNS
SEC,
they
should
be
finding
ways
to
not
rely
on
IP
fragmentation
and
anyhow.
They
ask
next
steps
is
to
adopt
this
as
a
working
group
document.
Okay,.
A
So
can
I
have
a
raise
of
hands.
How
many
people
have
read
this
draft
okay
to
be
starting.
So,
as
you
know,
we're
running
out
of
time,
so
maybe
I'll
take
one
question
and
then
we
keep
moving
we'll
take
it
to
the
list,
I
think
before
adopting
as
working
group,
but
that's
a
good
show
of
interest
in
it.
David.
H
Black
I
mean--the,
another
transfer
area
and
I'm
here
to
help
you
Ron
I'm,
going
to
say
a
dirty
word
tunnels.
Please
make
sure
that
what
you
do
here
is
lined
up
with
the
int
area.
Tunnels
draft
we're
fragmentation
is
used
to
solve
some
nasty
problems
with
tunnels
it.
We
really
ought
to
have
a
consistent
story
across
the
two
of
them.
Thank
you.
Okay.
Thanks
a
lot.
A
O
Hi
so
I'm
gonna
give
you
a
quick
update
on
our
work
on
Sox
version.
Six
I'll
start
by
giving
you
a
brief
overview
of
where
we're
at
so
we've
trimmed
down
the
are
cheating
the
overhead
in
terms
of
our
GT
down
to
0.
If
0
RTT
authentication
is
used
for
in
order
to
protect
against
malicious
l
parties,
we've
taken
a
step
back
and
rather
than
having
sox,
provide
an
encryption.
We've
decided
to
run,
run
it
over
TLS
and
then
handle
whatever
issues.
Tls
has
notably
TLS
TLS.
O
Only
data
is
prone
to
replay
attacks
and
we
have
a
mechanism
that
mitigates
such
attacks.
Now
that
we're
running
we're
also
running
stocks
over
TLS
plaintext,
password
authentication
is
actually
viable.
And
finally,
we
have
added
a
new
we've
leveraged
stocks
options
to
add
a
new
set
saw
copped
and
get
saw
cup-like
mechanism
and
we've
used
it
to
implement
some
stuff
related
to
MPT
CP
more
on
that
later
so
stocks
version
5
starts
by
negotiating
the
method
of
authentication.
O
Then
it
does
within
the
authentication
and
the
client
requests
that
the
server
the
proxy
establish
some
connection
to
the
server
and
then
finally,
application
data.
Can
pass
through
Sox
version
6,
in
contrast,
sends
as
much
data
out
front
as
possible,
so
we
cram
in
the
authentication
method,
negotiation,
negotiation
and
the
address
of
the
server
and
also
some
application
data.
O
O
Basically,
we
can
just
take
the
the
the
initial
message
sent
by
the
client,
which
contains
the
username
and
password
and
place
it
inside
a
Sox
authentication
data
option.
Now,
of
course,
there's
a
small
caveat
to
that.
If
the
username
or
and/or
password
I
are
exceptionally
long,
it
simply
won't
fit
in
that
option
and
you
have
to
do
it
the
old-fashioned
way,
which
takes
up
one
extra
RTT.
However,
this
is
unlikely.
O
Next
up,
we've
got
socket
options.
There's
been
some
discussion
on
the
mailing
lists,
notably
David.
He
brought
up
the
point
that
sockets
are
actually
an
OS
construct
and
connections
are
necessarily
TCP.
Connections
are
necessarily
done
using
sockets,
so
we're
going
to
rename
these
options
in
the
next
version
of
the
draft.
O
O
The
fields
I
want
to
draw
your
attention
to
are
like
level
code
and
data,
so
the
leg
baker
basically
indicates
what
what
leg
behavior
reply
refers
to.
It
can
either
be
a
client
proxy
like
the
proxy
server
leg
or
both
legs,
then
the
next
three,
the
next
three
fields
were
actually
inspired
by
sets
or
captain
gets
a
cop.
We've
got
left
operation
code
and
data
for
possible
levels
are
a
genetic
socket
level.
Then
we've
got
levels
for
eye
for
the
track
left
three
protocols,
namely
ipv4
and
ipv6,
and
two
more
levels
for
TCP
and
UDP.
O
We've
used
the
socket
options
to
handle
GFO,
so
that
previously
was
a
field
in
the
request
which
indicated
whether
or
not
the
proxy
should
attempt
to
use
the
fo.
Now
we've
removed
that
field
and
when
a
client
wants
the
proxy
to
use
the
fo,
it
simply
includes
this
option
as
part
of
its
request.
The
absence
of
such
an
option
means
that
the
server
must
not
use
must
not
attempt
to
use
the
fo.
O
Next
up,
we've
also
used
these
options
to
implement
a
use
case
called
proxy
bypass.
So
let's
say
that
a
mobile
phone
once
has
both
a
Wi-Fi
and
the
4G
interface,
and
it
wants
to
take
advantage
of
both
interfaces.
Now
most,
as
you
probably
know,
MPT
CP
deployment
is
lagging
behind
on
the
server
side.
So,
if
you,
if,
let's
say
a
mobile
phone,
wants
to
take
advantage
of
both
of
its
interfaces,
it
probably
has
to
go
through
a
proxy.
O
Now
some
servers,
my
template,
might
start
start
deploying
MP
TCP
now,
in
case
in
case
on
a
server,
does
support
MP
TCP
the
proxy
can
place
an
MP
TCP
option
in
its
operation.
Reply
signaling
to
the
client
that
the
upstream
server
does
indeed
support
MP
TCP,
then
the
client
can
forego
the
use
of
the
proxy
and
talk
to
the
server
directly
in
further
connection
attempts.
O
And,
finally,
we
can
use
these
options
which
to
change
the
MP
TCP
scheduler
used
by
the
proxy,
so
clients
can
can
place
such
a
request
to
indicate
what's
what's
what
packet
scheduler
they
want.
We
currently
support
the
packets
Jewellers
available
in
the
the
lyrics
NP
tcp
implementation
and
proxies
can
include
them
as
part
of
operation
replies
to
tell
clients
what
schedulers
they
are
using.
O
We
found
one
possible
use
case
for
this
option,
namely
low
latency
services.
So
if
a
client
wishes
to
have
low
latency,
it
can
tell
the
server
it
can
get
tell
the
proxy
to
duplicate
data
across
all
MP
TCP
sub
flows
such
that
the
delay
is
always
minimal
and
with
that
I'll
be
happy
to
take
questions
thanks.
A
Can
I
have
a
raise
of
hands
who
has
read
the
the
latest
version
of
this
draft?
Ok,
who
has
read
any
version
of
this
draft?
Ok,
so
we
definitely
encourage
people
to
comment
on
this
latest
version.
If
you,
if
you
can,
please
take
a
look
and
send
comments
to
blood.
Thank
you
very
much.
We're
ranking
short
of
time,
so
we're
gonna
move
being
be
moving
on
now,
Thanks.
So.
M
I
M
Hi,
okay,
so
hello,
everybody,
and
thanks
for
the
opportunity
to
present
this
I'll,
be
as
close
to
five
minutes
as
I.
Possibly
can
so
now.
Next
slide,
please
yep,
so
I'd
like
to
begin
by
describing
what
the
currently
published
best
practice
is,
which
is
RFC
6002
on
logging
recommendations
for
internet
facing
servers.
Okay.
So
what
that
document
recommends
is
that
as
well
as
logging,
incoming
IP
addresses
servers,
also
log
incoming
source
port
numbers
and
time
stamps
and
transport
protocol
as
well?
M
This
additional
information
is
required
in
order
to
attribute
the
activity
of
an
IP
address,
two
to
two
at
the
very
least,
to
an
ISP,
but
ideally
down
to
an
individual
from
a
crime
investigation.
Point
of
view,
so
in
the
presence
of
large
scale,
Nats
IP
address
is
not
enough.
You
need
this
extra
information
as
well.
That's
not
to
say
that
if
you
did
have
all
this
information,
you
would
successfully
be
able
to
identify
an
individual
from
this.
M
M
So
I
did
a
little
bit
of
research
and
what
I
found
was
that,
while
stars
recommendation
stats,
that's
fine,
they
are
what
they
are,
but
they're
not
enough,
and
here
are
some
of
the
issues
that
I
that
I
identified.
So
somebody
who
was
considering
implementing
those
recommendations
might
find
that
their
server
software
might
not
support
logging
of
source
ports
and
that
would
prevent
them
from
being
able
to
achieve
the
recommendations.
M
Another
thing
that
has
that
I
have
seen
is
that
certain
server
software,
the
only
way
that
you
can
enable
logging
of
source
port
is
by
enabling
a
ridiculously
verbose
level
of
logging,
like
debug
logging,
or
something
like
that,
which
you're
never
going
to
do
on
a
production
server.
So
whilst
it
may
be,
it
may
be
technically
possible.
It's
infeasible
to
implement
source
port
logging
now
practically
no
server.
Software
enables
it
by
default,
and
indeed
no
server
software
that
I
could
find
a
bar
one
even
has
a
default
configuration
sample
that
includes
logging
of
source
port.
M
M
It's
one
that
one
of
the
first
things
you
learn
as
a
forensic
examiner
that
you
don't
need
to
know
the
exact
time
which
something
happened
at
all
you
need
to
know
is
what
time
the
time
that
was
recorded
and
as
long
as
the
time
is
recorded
consistent.
You
can
offset
the
time
then
to
be
the
real
time.
So
if
you--if,
you
are
analyzing
a
computer,
for
example-
and
it's
time
is
set
one
year
wrong-
you
can
look
at
the
older
times
on
those
computer
compared
them
to
real
times
and
then
offset
all
the
time.
M
So
you
you
know,
as
long
as
time
is
recorded
consistently,
it
doesn't
need
to
be
retorted
recorded
against
a
reference
time.
So
I
take
exception
with
that
point
in
in
the
recommendations
in
the
current
recommendations
and
then
the
last
point
that
I
wanted
to
to
raise
for
for
whatever
it's
worth,
which
is,
logging
information
doesn't
exist
in
a
vacuum:
people,
log
information
for
a
reason
and
oftentimes
people
have
all
sorts
of
scripts
and
tooling,
and
so
on.
That's
built
based
on
their
logs
and
by
changing
log
formats.
M
D
M
Okay,
so
I've
only
five
minutes,
so
I
just
wanted
to
summarize
and
say,
but
the
absence
of
primarily
source
port
information
in
logs
is
a
big
problem
from
a
crime
attribution
and
a
public
safety
point
of
view,
and
this
was
a
point
that
was
made
by
Europol
in
2014
and
repeated
again
in
2016
in
their
crime.
I
forget
what
the
document
is
called:
some
sort
of
crime
problems
on
the
internet
and
and
as
I
mentioned
earlier,
it
doesn't
logging
of
source
port
wouldn't
make
a
crime
attribution
problem,
go
away
what
it
does
address.
M
The
problem
of
these
address
sharing
technologies
to
a
certain
extent,
not
in
all
scenarios,
but
to
a
certain.
It
certainly
would
improve
things
and
I
I'm,
suggesting
that
the
current
best
practice
needs
revision
to
address
more
of
the
practical
issues
with
with
locking
source
port.
It's
not
just
say,
source
ports
should
be
logged,
but
also
to
make
some.
You
know
a
more
encompassing
set
of
recommendations
that
can
actually
maybe
help
make
it
happen,
and
then
last
slide.
M
Please,
and
in
order
to
move
the
discussion
along
I'm
being
completely
new
to
engaging
with
the
IETF
I
rolled
up
a
document
and
I
published
it,
which
is
now
in
its
second
draft
and
the
link
is
there
for
anyone
who
wants
to
to
read
it
or
comment
or
my
contact
details
are
there
and
everything
so,
and
so
that
was
everything
that
I
wanted
to
say.
Thank
you
very
much.
Thanks.
A
D
M
That's
a
fantastic
question
and
the
answer
is
it's:
the
server's
who
are
logging
and
not
the
nut
and
the
nut
itself,
as
I
mentioned
in
my
intervention
in
on
Tom's
talk,
most
people
who
are
running
and
that
are
have
a
regulatory
obligation
to
be
able
to
identify.
If,
if
a
law
enforcement
agency
comes
to
them
and
goes,
who
was
using
a
particular
IP
address
at
a
particular
time,
they
have
to
be
able
to
tell
them.
The
problem
is
in
cases
of
carrier-grade
NAT.
M
If
the
law
enforcement
officer
doesn't
also
have
the
time
and
the
source
port,
they
can't
even
ask
the
ISP.
The
ISP
will
say
a
million
people
were
using
that
IP
address
at
that
time,
or
you
know
some
large
number
of
people
and
without
the
source
port
on
the
time
stamp.
We
can't
tell
you
so
there's
an
information
gap
between
the
information,
that's
being
protect
aend
in
that
cenar
in
psalm,
carrier-grade
NAT
scenarios
versus
the
information
that
is
being
retained
at
let's
say,
for
example,
a
victim.
M
A
P
P
P
M
L
Microburbs
so
I've
been
successful
in
in
using
carrier-grade
NAT
port
block
allocation,
so
that
one
ipv4
address
is
shared
by
16
people
and
I
just
say:
okay,
you
want
to
know
where
that
IPR
is
at
that
point
of
time.
It's
one
of
these
16.
It's
not
millions.
It's
16
and
I
mean
police
will
immediately
rule
out
most
of
them
and
I'll
say
it's
one
of
these
three
and
then
then
they
have
something
go
on.
It
have
to
be
millions.
L
M
G
M
One
IP
address
at
a
particular
time,
and
but
that's
not
the
case
everywhere
and
and
yes,
I
am
aware
of
the
situation
in
Belgium
and
that
there
are,
and
that
has
as
how
did
I
guess
a
positive
side
effect
of
they
are
now
using
ipv6.
An
awful
lot
more
than
carrier-grade
NAT,
but
and
ipv6
also,
then
comes
with
its
own
separate
kind
of
worms.
But
that's
another
description
and
I'm.
M
B
So,
like
responsible
lady
here
so
like
I
wanna,
like
not
focus
on
the
content
of
the
graph
at
this
point.
Okay,
so
like
the
idea
of
presenting
this
here
is
to
figure
out
if
there's
interest
in
updating
6302,
like
you
know,
Alan,
maybe
there's
like
stuff
to
be
done
and
I
want
the
working
group
to
own
that
work.
So
that's
the
first
step
we
wanna
figure
out
like
sit
down
and,
like
you
know,
ask
the
working
group
at
some
point
like
on
the
mailing
list
or
if
you
wanna,.
G
B
Here,
that's
fine,
but
we
are
probably
running
out
of
time
you're
asking
the
mailing
list
like
do.
We
won't
have
this
date
like
6302,
to
make
it
like
more
practical,
so
whatever
changes
then
need
to
get
done.
So
that's
really
what
I
wanted
to
get
out
of
this
saying
like
there's
some
feedback
saying
the
recommendations
we
made
are
not
practical,
okay,
so
the
question
is
we
need
to
maintain
our
work.
So
that's
really
the
reason
I
got
like
Dave
to
come
and
present
here.
Okay,.