►
From YouTube: IETF100-CAPPORT-20171114-1550
Description
CAPPORT meeting session at IETF100
2017/11/14 1550
https://datatracker.ietf.org/meeting/100/proceedings/
A
D
E
E
G
C
C
C
So
there
was
another
hackathon
and
more
participate
participation
at
the
hackathon
there's
some
implementation,
work
and
Kyle
has
a
presentation.
The
if
you
download
the
document
there.
The
thing
materials
are
linked
there,
Midori
and
here
also
I,
guess
under
Shikha
project
remotely,
and
they
sent
some
documents
that
are
linked.
All
the
materials
are
in
the
github
working
group
materials
repository,
there's.
H
C
We
had
a
milestone
to
have
a
protocol
to
discover
interact
with
captive
portals.
We
adopted
an
architecture
document
in
Prague.
We
still
have
77,
10
and
PVE
in
the
mix.
We
need
to
decide
at
some
point
what
to
do
about
that.
What
hopefully,
today
and
I
suppose
that
will
come
up
in
the
architecture,
npvd
latter
half
of
this
session.
C
We
also
have
a
milestone
for
having
an
API
document
which
we
adopted
in
Prague,
but
there
was
no
I
IETF
upload.
There
was
no
github
version
upload.
We
tried
to
email,
the
original
authors.
Does
anybody
know
if
they
are
around?
Has
anybody
responded
to
them?
They
haven't
responded
to
either
of
us,
and
so
that
being
the
case,
tommy
has
expressed
interest
in
taking
over
some
authorship.
Would
someone
be
willing
to
help
him
out
as
co-author.
G
G
G
C
If
you
both
send
us
some
github
coordinates,
we
can
add
you
to
the
repository
that'd
be
thank
you.
Both
I
will
be
having
to
discuss
some
some
ICMP
stuff
that
came
up
on
the
mailing
list
and
I
wanted
to
have
a
couple
of
slides
of
architecture,
since
we
mostly
have
walls
of
text
today.
This
is
the
capture
portal
architecture
diagram
for
those
of
you
that
might
need
to
be
reminded.
C
C
The
thinking
clearly
delineated
that
the
there
are
multiple
sort
of
off
network
authentication
vendors
that
need
to
be
supported
and
highlighted
that
there's
a
sort
of
an
enforcement
point.
But,
as
we've
been
talking
about
what
is
a
Yui
identifiers
and
IP
addresses
at
a
MAC
address,
is
it
some
other
kind
of
token?
And
how
is
that
learned?
C
How
is
that
communicated
to
the
FBI
I
felt
like
I
needed,
to
put
something
into
some
sort
of
like
that
network
architecture,
diagram,
and
so
here,
I
drew
like
a
client
like
UV
device
connected
to
an
AP
I
imagined
you
might
have
a
downstream
laptop
like
USB
tethering
through
that
device
as
well.
So
there's
a
set
of
infrastructure.
That's
on
link,
there's
a
obviously
a
cascading
set
of
highly
redundant
router
connections
to
the
internet,
because
it's
a
really
well
run
venue
and
there
are
multiple
login
vendors
that
need
to.
C
We
need
to
consider
the
locations
of
the
enforcement
point
or
is
the
API
endpoint.
Where
is
that
first
web
endpoint
before
you
might
get
redirected
off
to
one
of
the
login
vendors
and
these
architecture,
decisions
like
what
we
decide
is
in
scope
and
what
we
decide
is
out
of
scope
are
going
to
affect
what
we
think
of
as
Yui
identifying
tokens
and
also
the
guidelines
for
DHD
v4
and
PVD
deployment
they
DVD
and
HP
before
will
function
very
differently.
Dvd
needs
to
be
on
link
at,
whereas
DHT
before
link
can
be
relayed
from
off
link.
C
B
You
know,
and
peer
to
peer,
don't
relate
through
me.
Alright,
so
next
side
ignore
this
slide.
It
sucks
so
I'll
just
give
you
an
introduction.
So
basically,
what
we're
you
know
in
the
architecture
we
have
a
few
pieces
that
are
communicate
with
one
another.
You
have
the
user
equipment,
that's
trying
to
send
packets
out
to
the
internet
and
an
enforcement
device
is
blocking
those
packets
or
allowing
them
through,
and
it
may
be
responding
to
the
block
with
some
sort
of
ICMP
entry
to
a
message
or
ICMP
CAD
portal
message.
B
On
the
other
side,
the
user
equipments
going
to
communicate
with
an
API
device
or
sorry
API
server
to
you
know
understand
whether
it's
captive,
maybe
it'll,
go
to
a
login
page
to
log
itself
in
and
then
this
login
page
API
server
or
whatever
your
whatever
it
is,
is
going
to
communicate
with
the
enforcement
device
to
get
the
status
or
actually
log
the
user.
In
and
underlying
all
of
this
is
the
user
equipment
itself
there's
going
to
more
than
one
of
them,
and
all
these
devices
need
to
agree
on
how
to
identify
the
user
equipment.
B
They
can
make
the
right
decision
nine
exercise
and
that's
the
problem
right.
So
there's
a
whole
bunch
of
ways
of
identifying
a
device
on
a
network
you
can
use
later
to.
You
can
use
layer
three
so
on
and
so
forth,
and
we
want
to
sort
of
come
to
conclusion
as
to
what
we
want
to
recommend
or
require
that
implementations
of
the
architecture
actually
use
for
identification.
Nice
night
so
I
said
some
options.
You
could
use
the
L
to
address
or
MAC
address
and
that's
kind
of
what
they're
doing
a
lot
of
at
least
so.
B
Access
points
to
helicopter
portals
are
doing
right
now,
in
fact,
my
hotel,
for
example,
when
I
log
into
the
captive
portal
there
it
actually
sent
my
MAC
address
in
the
URL
to
the
to
the
cat
that
had
a
login
page,
so
I
mean
clearly
that's
being
used
right
now.
I
can
use
the
layer
3
address,
so
ipv4
ipv6
source
address
to
identify
the
device.
B
Maybe
you
want
to
use
some
combination
of
that
and
the
port,
if
there's
a
not
involved,
or
maybe
we
want
to
do
something
new
and
have
something
that
everyone
agrees,
that
isn't
necessarily
directly
derive
from
an
address
associated
with
a
device
but
still
uniquely
identifies
it.
So
the
session
ID,
if
you
will
that's
like
so
another
thing
that
I
want
to
discuss
aside
from
how
to
identify
the
device,
is
how
to
communicate
this
identification
to
the
API
server
from
the
enforcement
of
sorry
from
the
user
equipment.
B
So
I
mentioned
you
know,
implicit
identification
or
just
explicit
when
I
say
implicit
I
mean
that
the
API
infers
the
identity
of
the
user
equipment
from
the
requests
at
the
pack
that
the
these
are
coming
sends
to
it.
So,
for
example,
if
I
make
a
REST
API
call
to
the
API
server,
the
API
server
could
use
the
source
MAC,
sorry,
the
source
IP
of
the
request
to
identify
the
device,
and
then
you
send
that
source
IP
down
to
the
enforcement
device
to
make
it
to
make
the
query.
Now
that
has
some.
B
You
know
some
trade-offs
in
doing
that,
supplementation's,
which
I
hope
you
discuss
later
explicit
and
when
I
say
what
I
mean
there
is
it's.
Actually,
the
user
equipment
will
package
in
the
API
call
the
the
information
that
it
is
using
to
identify
itself,
and
this
the
example
I
gave
earlier
in
my
hotel
is
an
example
of
the
explicit
way
of
communicating
that
information
next
slide.
B
G
Want
to
poke
on
that
a
little
bit
Mountain
Thompson.
So
the
example
of
the
the
MAC
address
in
the
URL
has
a
number
of
interesting
implications
for
the
designer
I.
Don't
think
it
is
explicit
in
the
sense
that
the
client
was
involved
in
making
that
making
that
MAC
address
appear
in
that
thing.
So,
if
you
think
of
this
from
the
perspective
of
the
deployments
that
we're
talking
about
here,
you're,
actually
your
first
point
of
contact
for
an
API
or
a
login
service
would
be
the
thing.
G
That's
adding
the
MAC
address
to
that
information,
and
it
would
be
that
device
that
has
explicitly
added
to
added
the
MAC
address
to
that.
But
the
client
has
implicitly
identified
itself
to
that.
The
fact
that
you're
then
being
redirected
off
to
something
else,
with
extra
information
being
passed
along
with
that
redirect,
doesn't
change
the
fact
that
that
he's
actually
implicit
on
that
first
interaction.
So
I
guess.
G
G
B
G
The
user
agent
isn't
aware
user
equipment
isn't
lightly,
aware
of
the
fact
that
this
particular
field
happens
to
carry
its
MAC
address.
In
fact,
it
could
be
a
completely
opaque
and
in
fact
it
probably
should
be
completely
opaque,
because
in
that
case,
I
could
put
his
MAC
address
in
that
field
there,
and
if
we
get
into
discussions
of
these
things
and
I,
think
we
actually
should.
We
should
cover
the
security
around
ramifications
of
these
things.
I
have
a
slide
at
the
end
to
happen
for
the
security,
so.
C
C
C
G
M
Rick
Taylor
just
a
just
a
qualifying
question
and
I
suppose
you
talk
about
user
equipment
here,
but
we've
heard
now:
user
agents-
okay,
cool,
let's
see
everything's
to
user
agent;
okay,
because
I
don't
work
for
a
browser
vendor,
but
I
still
need
captive
portal
support
so
I'm
much
worse
than
in
the
fact
that
you're
using
user
equipment
and
I'm
really
pleased
to
hear
that
well
shut
up
and
sat
down.
But
you
can
david.
B
B
One
was
the
the
user
equipment
made
an
API
call
with
the
L
to
address
embedded
with
it
and
another
one
was
do
the
same
thing
with
the
allow
three
address
and
finally,
I
also
tried
out
doing
it
implicitly
so
having
the
server
and
for
the
address
based
on
the
source
IP
of
the
device
and
submitting
results
like
the
the
first
who
just
worked
it.
You
know
it's
it's
something
we
already
done,
basically
with
the
hackathon
in
Chicago,
but
the
third
one.
B
What
I
found
interesting
there
was.
There
was
sort
of
two
things.
First,
it
was
simpler.
I
was
able
to
cut
it
like
half
the
code,
because
now
you
didn't
have
a
bunch
of
stuff,
parsing
fields
and
understanding
stuff.
The
other
thing
is,
it
was
I,
also
messed
it
up
originally,
because
my
route
to
the
API
server
was
not
the
right
one.
B
I
basically
chosen
I
chose
that
the
API
server
was
on
a
it
got
a
different
source
IP
than
the
one
that
the
user
equipment
was
sorry
the
enforcement
of
I
seen
so
they
basically
disagreed
and
the
important
point
there
was
that
there's
some
restrictions
on
where
the
API
server
lives
in
order
for
this
sort
of
in
order
for
it
to
properly
infer
the
identity
of
the
user
equipment.
In
this
case
it
was
if
it
was
using
a
source
IP.
B
B
B
M
B
M
Being
hit
by
your
protection
device,
that
was
then
going
I,
don't
know
with
this
person's
access
the
internet,
so
was
the
protection
device.
Therefore
forwarding
the
requests
to
the
API
or
was
the
route
the
redirect
was
coming
from
the
ICMP
back
to
the
user
equipment
and
each
was
then
going
to
the
API.
Hence
your
two
different
subnets
tutor
from
the.
B
C
I
think
the
reason
this
came
up
in
the
context
of
the
ICMP
draft
was
the
ICMP
drafting
incorporated
well
two
different
sort
of
things,
but
in
the
newer
option
of
the
IC
m
in
the
new
in
the
new
ICMP
option,
it
incorporated
some
extensible
metadata
at
the
end.
That
included
all
manner
of
like
obsession
ID,
but
also
lots
of
other
information
to
be
communicated
to
the
client,
which
is
the
only
thing
that's
going
to
work
across
multiple
links.
Right.
H
So
the
shukaku
CableLabs,
so
I
think
marginalia
right.
So
if
you
go
into
the
security
implications,
it
looks
like
at
least
the
client.
There
should
be
some
amount
of
exclusiveness
in
the
sense
that
the
client
should
at
least
have
received
something
that
it
holds
back
and
sends
back
in
order
for
it
to
identify
itself,
then
that
would
probably
have
better
security,
maybe
I'm
wrong,
but
it
might
have
better
security
characteristics.
Then
the
implicit
where
the
client
doesn't
know
anything
which
means
that
is
you're
just
inferring
based
on,
but.
B
H
True
yeah,
so
that
may
be
that's
a
discussion.
Okay,
so
some
other
thing
is
in
the
implicit.
The
risk
is,
then,
that
the
you
may
actually
infer
the
wrong
thing
right.
Different
endpoints
mean
for
the
wrong
thing
and
if
the
client
can
still
go
ahead
and
spoof
its
MAC
address,
if
say,
you're
doing
it
implicit
based
on
right,
yeah,
I
know
if
I
know
that
you
are
doing
an
implicit
that
I
can
spoof
my
MAC
address
and
then
that's
all
I
need
to
really
do.
If
that's
what
you're,
depending
upon
yeah
I,.
M
Think
I
was
about
to
make
the
same
point.
The
implicit
data
is
still
kind
of
explicit.
It's
just
configured
in
a
lower
level,
and
you
know
I
can
change
my
MAC
addresses
if,
if
I
want
to
jump
onto
somebody
else's
thing,
just
off
from
I'm
sort
of
free
thinking
here,
a
little
bit
I
think
you've
got
the
model
right.
There's
the
user
equipment,
that's
actually
wants
the
access.
You've
got
the
production
device
which
is
providing
the
access
allowing
the
access
and
the
API,
which
is
doing
the
permission.
Authentication.
M
So
is
this
person
sorry,
author,
author
ization?
Is
this
person
authorized
to
be
given
the
access,
so
I
think
those
three
people
need
to
be
in
the
three
entities
need
to
be
involved
in
this,
so
the
protection
device
needs
to
be
able
to
go
to
the
API
server
and
say
I've.
Had
this
person
with
this
identifying
information,
I
may
have
implicitly
discovered
the
redirect
goes
back
to
the
user
and
equipment.
That
then
says
explicitly.
M
B
M
N
Yes,
the
current
icmp
draft
has
a
lot
of
you
know,
identifier
stuff
that
can
come
back
from
enforcement
to
Yui
I
believe
from
looking
at
the
hackathon
stuff
and
looking
at
how
we
would
do
implementation
of
that
on
a
client
that
can
be
problematic
for
a
lot
of
reasons
like
getting
the
just
the
normal
ICMP
message
that
you've
been
administratively
blocked.
It's
quite
simple
that
doesn't
require
changes
pretty
much
any
platform
should
be
able
to
do
that
today.
I'm,
getting
all
this
of
and
information
I,
think
that's
going
to
require.
N
That,
yes,
and
that
may
be
very
difficult
to
get
up
there
and
again
may
not
be
appropriate
for
that
identifier.
I
think
we
were
talking
about
the
API.
You
eat
API
leg,
there's
a
lot
of
flexibility
about
how
we
want
to
do
the
identifier.
We
can
have
relatively
complex
identifiers.
They
can
be
encrypted.
They
can
you
know
we
can
do
what
we
need
to
do
they're
explicitly
if
we
want
to
what
I
don't
understand.
Maybe
this
has
already
been
discussed
is
if
we
were
wanting
to
communicate
from
Yui
to
enforcement
enforcement
device.
N
B
N
B
Modifying
all
packets
coming
out
of
agree
but
I
mean
all
ultimately
I.
Think
that's
that's
the
question
of
correlation
as
it
was
raised
on
the
mailing
list.
It's
it's!
How
you
know
if
we
are
using
a
an
opaque
identifier
that
isn't
in
the
data
plane,
traffic
or
the
data
path
traffic?
How
do
we
correlate
that
identifier
with
the
identifier
in.
K
D
B
This
something
we
are
talking
about,
or
is
this
I
think
this
I
think
we
are?
We
are
the
very
least
with
it
with
multiple
IP
addresses,
because
we
were
considering
the
ipv6
case,
where
it's
pretty
easy
to
have.
Multiple
IP
addresses
and
Eric
had
a
proposal
on
mailing
list
to
deal
with
that
with
a
session
ID
and
it's
essentially
to
treat
the
first
session.
Id
user
equipment
gets
as
its
primary
ID
and
then
sort
of
linking
them
together.
B
D
G
G
If
we're
talking
v6
any
one
of
these
concepts,
it
could
use
to
identify
me,
it
decides
it
packages
that
information
up
into
a
into
this
concept
of
the
session
ID
and
sends
it
back
to
me
and
now
I
have
a
way
of
talking
to
other
things
within
that
network
that
allow
those
things
to
uniformly
identify
me.
The
the
enforcement
point
becomes
the
anchor
for
the
identifier
it
mints
me.
G
A
new
identifier
and
I
can
use
that
identifier
with
all
of
these
other
services,
and
those
services
can
then
use
that
identifier
and
go
back
to
the
enforcement
point
and
talk
to
the
enforcement
point
based
on
on
all
of
that
stuff,
and
that
is
I
believe
the
architecture
that
we're
describing
when
we
talk
about
the
session,
ID
stuff.
And
so
the
question
I
have
is
when
we
have
the
three
choices:
implicit,
something
like
this
session
ID
and
then
something
explicit
which
one
of
which
of
the
properties
of
each
one
of
those.
N
Tommy
poly
Apple,
so
I
I
get
that
that
could
work.
That's
yes,
a
lot
more
reasonable
than
sending
your
session
ID
and
every
single
packet
I
I,
don't
love
having
anything
like
the
session
ID
coming
back
in
the
ICMP
one,
because
it's
randomly
spoof
able,
but
beyond
that
I
think
as
I
was
I
responded
to
Kyle
and
Dave
on
their
architecture
document.
There's
the
point
of
ICMP
is
a
way
to
tell
you've
been
blocked,
but
it
is
not
necessarily
the
best
discovery
mechanism.
So
it's
fine
for
it
to
say.
N
Yes,
you
were
blocked
and
here's
the
session
ID,
but
hopefully
I've
already
discovered
it.
I've
already
talked
to
the
API
server
and
if,
if
I
get
the
session
IDs
from
the
enforcement
box,
I
hopefully
have
it
talked
to
it
yet
so
there's
kind
of
a
boot
trapping
problem
they're.
Also
so
beyond
that
like.
If,
when
we
talk
about
a
session
ID
tying
together,
multiple
addresses,
so
we
definitely
want
that
to
be
done
and
likely.
N
When
the
enforcement
device
talks
to
the
API
server,
it
should
have
some
shortened
way
of
communicating
about
this
device,
but
to
the
Yui,
if
I'm
tying
that
together,
why
wouldn't
I
just
say
each
each
session
ID
for
each
address
is
the
address
or
like
is
the
prefix,
because
these
addresses
are
already
known
by
the
network
right
like
I
got
it
from
DHCP
I
have
my
prefix.
This
is
mine.
The
network,
you
know
understands
that
I
have
it,
and
so
it
can
just
use
that.
As
my
identifier,
the.
N
I,
which
is
why
I
guess
that
this
diagram
is
like
super
important.
So
is
the
enforcement
point
or
someone
who
can
communicate
to
the
enforcement
point
on
link
such
that
they
can
do
this
determination,
because
if,
if
there's
a
communication
from
some
router
that
is
on
link
to
someone
else,
then
you
don't
need
explicit.
So
I
believe
that.
G
We've
had
people
come
up
with
use
cases
where
you
have
an
that
in
a
house
between
the
device,
the
the
user
equipment
that
is
ultimately
making
this
communication
and
the
enforcement
point
yep.
In
fact,
as
I
understand,
that
the
enforcement
point
is
is
is
a
long
way
into
the
into
their
networks
because
they
don't
use
them
particularly
often
yep,
and
so
they
don't
have
very
many
of
them,
and
so
that
suggests
to
me
that
MAC
addresses,
for
instance,
would
be
completely
unsuitable.
That's.
N
N
H
H
C
Let
me
try
to
clarify
I,
don't
know
what
the
answer
is,
but
I
think
what
we
have
today
is
we
have
two
enforcement
points.
One
of
them
enforces
that
your
IP
address,
which
is
visible
very
far
away,
but
crucially
before
between
you
and
the
Internet,
is
the
same
as
a
token
that
was
already
that
is
locally
visible,
which
is
the
MAC
address,
so
so
that
you
basically
pass
out.
C
The
local
enforcement
point
is
on
your
link,
and
it
knows
it
can't
for
you
by
you
by
the
MAC
address,
and
it
can
is
also
in
a
position
to
force
you
to
use
the
IP
address
that
it
gave
you
in
all
communication.
So,
in
effect
your
identifier
is
from
in
one
part
of
that
orchids,
ERP
v4
address
in
another
part
of
your
the
network.
It's
your
MAC
address,
but
there's
an
enforcement
point
that
those
two
the
same,
and
so
they
can
be
used
interchangeably,
no
ok,
I'm.
M
Gonna
generalize
this
cuz,
some
microphones
got
a
funny.
Somebody
hit
the
point
earlier
and
I
can't
remember
who
said
it,
which
was
the
protection
device,
is
making
its
own
mind
up
on
how
its
classifying
your
traffic.
If
it's
on
link
it
could
be
Mac.
If
it's
remote,
it
could
be
IP,
it
could
understand.
Ipv6
addresses
it
could
do
all
sorts
of
stuff.
You
might
be
going
to
run
at
between
the
two,
but
at
some
point
your
protection
device
goes
I,
don't
get
this
traffic
I,
don't
know.
M
So
you
see
your
ICMP
response
has
to
have
some
piece
of
identifying
information
and
a
place
to
go
to
to
be
authorized.
So
let's
call
it
an
opaque
token.
It's
a
thing.
The
ICMP
comes
back
says.
Take
this
token,
go
to
this
API
server
present
that
token
and
get
you
so
forth.
Arised
and
the
api
server
will
tell
me
banned.
You
won't
see
this
conversation
that
I
am
then
allowed
to
use.
I'm
then
allowed
to
pass
this
traffic
through
I'm
allowed
to
permit
you
access.
So
what
goes
into
that
token?
M
How
that's
mapped
in
its
internal
hash
tables
on
the
protection
device?
Is
the
implementations
problem
from
the
API
perspective?
It's
just
an
opaque
blob
of
stuff,
and
then
we
we
don't
have
to
argue
about
whether
it's
layer
to
honor,
three
or
whatever,
it's
whatever
the
equipment
does
and
is
designed
to
do
yeah.
You
have
a
bootstrapping
problem.
O
M
C
The
flaw
in
your
reasoning
is
this:
is,
if
that
you
don't
have,
if
you
don't
have
the
two
enforcement's
points
that
I
mentioned,
I
can
take
your
IP
address
and
I
can
steal
your
service,
and
so
that
is
always
enforced.
There's
always
DHCP
snooping.
There's
always
enforcement
of
one
MAC
address
pre-addressed
in
today's
networks,
so
they're
in
pretty
much
every
deployment
today.
There's
one
enforcement
point
here
and
one
there,
and
so
that's
why
they
can
use
this
token
interchangeably.
Okay,.
M
So
as
long
as
it's
installed
correctly
and
it's
functioning
correctly
sure
it
might
be
looking
at
your
Mac
or
it
might
be
talking
to
an
upstream
protection
device
and
using
the
IP
and
having
some
private
conversation
there,
but
between
the
two
of
them
they
say
here
is
an
ID.
You
need
to
go
take
to
the
API
server
and
we
will
compose
that.
It's
not
a
matter
of
the
ICMP
protocol
deciding
what
that
ID
is
defined
from
it's
just
an
ID
one.
B
Now
one
security
concern
there
is
I
mean.
Maybe
it's
not
a
big
concern,
but
what,
if
you
know,
yeah
party,
a
party
B
party,
a,
is
actually
logged
in
they're
doing
their
stuff
good
party
B
wants
to
know.
If
party
is
logged
in
so
they
figure
a
party
A's
address,
I,
know
I'm
token
and
just
ask
the
server.
Is
he
logged
in?
Is
he
logged
in?
Is
he
home
things
like
that?
Yeah.
M
B
M
C
Sram
in
in
this
model,
right
I
think
what
we
have
here
is
like
a.
We
have
a
three-way
communication
problem
yeah,
and
we
have
to
basically
start
making
choices,
to
simplify
things
so
that
we
can
get
down
to
something
that
right,
and
so
we,
in
my
mind,
we're
looking
for
choices
that
are
must
so
that
we
can
then
figure
out
what
else
is
shoulds
right.
So
we
just
eliminate
the
things
that
are
obviously
eliminated.
Both
we
could
figure
out
what
they
are.
C
One
of
the
things
in
the
model
where
its
address
based
I
was
trying
to
sort
of
figure
out
what
the
experience
would
be
for
an
ipv6
user.
This
generating
new
temporary
address
is
all
the
time
and
if
a
new
temporary
address
in
your
model,
a
new
temporary
dress
could
be
just
identified
as
it
is
not
identified
as
being
associated
with
the
device,
depending
on
how
far
away
apart
thee.
Okay.
I
M
N
N
Tommy
so
I
agree,
I,
think
it's
a
good
point
that
you
know
the
enforcement
device
it
can
have
whatever
mapping
it
wants
a
couple
things
with
the
ICMP.
Send
me
back
a
session.
Id
I
mean
the
ICMP
message.
Also,
does
you
know
it
reflects
back
to
me
the
IP
address
I
mean
the
IP
packet
I
sent
right
so
like
in
some
ways.
The
thing
that
failed
is
the
representation
of
a
key
into
that
dictionary,
because
anything
that
I'm
sending
to
the
enforcement
device,
because
I'm
not
adding
my
session
ID
explicitly
in
to
this.
N
N
H
N
G
But
on
the
other
hand,
it
could
simply
take
the
piece
of
wire
and
something
else
such
as
the
IP
address
that
was
taken
and
treat
them
separately
if
it
wanted
to.
What
Rick's
saying
is
that
all
of
this
information
is
under
the
control
of
the
enforcement
device
and
by
dictating
any
one
particular
identifier
where,
where
pigeonholing
in
a
way
that
may
not
allow
for
particular
deployments
to
actually
use
this
solution
now,
the
question
that
I
have
is
is
implicit
still
completely
off
the
table
in
this
model.
G
N
They
this
kind
of
comes
back
to
when,
when
you're
saying
like
in
your
experimentation
for
the
hackathon,
like
you
wanted,
like
you
had
issues
when
the
enforcement
device
and
the
API
were
on,
you
had
different
views
of
what
kind
of
like
what
link
you're
coming
in,
like
this
is
kind
of
another
instance
of
that.
So
it
is
possible
that
potentially
like
if
this
only
works
when
the
API
server
is
kind
of
on
the
same
fiber
as
my
enforcement
device,
then
they
actually
in
that
case,
do
have
the
same
view
of
it.
G
Is
so
my
question
I
think
largely
comes
down
to
if
we
go
and
plis
it?
What
are
the
constraints
on
the
design
that
naturally
flow
on
from
that,
and
if
we
allow
for
the
session
identification
stuff,
what
what
additional
things
does
that
gain
us
and
what
additional
costs
like
the
the
bootstrapping
problem,
you
talked
about.
I
think
we
still
need
to
to
work
through
that
in
the
in
the
session
ID
case.
G
B
Ben
Schwartz
I,
don't
know
too
much
about
all
the
stuff
that's
going
on
here,
but
it
does
seem
to
me
that
there's
a
really
fun
trust
problem.
If
you
try
to
use
IP
addresses
as
identifiers
with
all
these
multiple
layers
of
routers
like
it,
especially
in
the
in
that
case,
you
know
if
you
think
that
your
permissioning
one
person
behind
that
net
well
know
unless
you
have
a
trust
relationship
for
the
operator,
that
night
you're
permissioning
the
whole
net,
and
that
actually
goes
for
all
of
these
routers
and
ever
in
this
whole
multi-layered
diagram.
B
Unless
you
have
a
trust
relationship
all
the
way
from
the
top
of
that
stack
to
the
bottom
you're
permissioning,
the
next
layer,
though
you're
provisioning,
the
last
untrusted
layer
in
the
stack
and
if
you
do
have
a
trust
relationship
all
the
way
at
the
bottom.
Then
well,
you
know,
maybe,
if
there's
an
operational
reason,
why
you
can't
get
the
MAC
address,
but
you
at
least
have
the
relationship
you
could
get
the
MAC
address.
We
do
I
mean
later
on
in
my
slides,
which
we
don't
really
need
to
go
to.
B
C
We
just
say
that
this
is
the
prefix
and
then
we
are
essentially
in
the
same
boat,
where,
if
you
want
to
block
in
that
you
can
look
at
TCP
timestamps
that
I
know
you
had
a
bug
where
you
got
the
timestamp
wrong
and
these
on
captive
portal.
You
were
to
devices
and
they
blocked
to
use
okay,
and
so,
if
they
want
to
play
that
game,
it's
like.
Oh,
you
have
three
addresses
and
two
of
them
are
using
different
tzp
time.
Stamps
are
gonna
block
you,
that's
fine.
C
You
know
they
can
do
that
if
they
don't
care
if
they
care
that,
like
the
primary
user
of
this,
looked
at
their
the
captive
portal
page
on
the
screen,
maybe
we
can
just
use
the
same
thing
and
I
think
at
that
point
all
it
seems
to
me
that
most
of
the
rationale
for
doing
all
the
session
stuff
just
goes
away
right
and
so
I
wonder
if
we
can
like
do
that
as
a
simplifying
measure,
at
least
initially.
So
what
you're
proposing
instead
of
basically
scope,
limiting
assumptions
yeah.
B
M
Okay,
so
Rick
again
two
parts.
First,
our
quick
answer
to
I
can
tell
you
what
people
are
doing
at
the
moment
they're
trying
to
make
money
by
making
products
that
are
cooler
than
their
competitors,
products
that
do
clever
a
protection
to
give
you
a
lovely,
full
sense
of
security
and
to
pay
them
lots
of
money.
I
mean
that's
called
capitalism.
M
So
saying:
oh,
we
just
care
about
the
ipv4,
then
some
will
say
are,
but
we
do
clever
a
staff
on
this
and
suddenly
it's
all
broken
so
I
I
think
we
have
to
have
a
little
bit
of
a
reality
check
about
the
people
who
are
selling
protection,
equipment
and
I'm
sure
they're,
lovely
I'm,
trying
to
make
trying
to
make
money.
Out
of
this,
you
know,
might.
M
In
public
no
are
going
to
go
to
I
know
going
to
my
main
point,
which
was
about
the
implicit
versus
explicit
the
token
stuff
I'm
suggesting
which
I
see
is
a
superset
of
the
ipv4
or
concatenated
with
the
incoming
wire
or
the
fiber
port
or
whatever.
You
want
that's
required,
so
that
these
protection
equipment
manufacturers
can
differentiate
their
products
in
X
ways
yeah.
M
M
You've
got
your
token
for
your
traffic
that
is
being
classified
and
has
hit
the
I,
don't
know
button,
and
then
the
session
ID
you
get
in
response
from
the
API
server
having
presented
it
and
that
one's
explicit,
so
I
think
the
solution
to
this
is
to
tokens
one
pretty
ephemeral
and
one
is
the
one
you'll
hold
for
your
yeah
I
qualified
to
have
access
and
going
back
to
your.
They
may
only
be
allowed
five
IP
addresses,
or
five
ports
or
five,
whatever
five
magic
beans.
M
The
API
server
is
the
one
that's
counting,
because
the
client
just
gets
handed
a
token.
The
client
takes
that
token
presents
it
to
the
API
server
and
the
API
server
has
to
decide
if
it
has
to
talk
to
the
protection
device
in
order
to
do
that
or
a
whole
suite
of
protection
devices.
That's
a
whole
different,
API
and
I
think
outside
a
scope
for
this.
So
sorry,.
M
So
I
play
through
sure,
yeah,
so
I'm,
a
user
piece
of
user
equipment
I
wish
to
access
the
thing
that
the
internet,
the
protection
device
goes.
I
have
no
idea
who
you
are
I,
have
examined
your
traffic
and
decided
I,
don't
like
you,
so
ICMP
response
comes
back.
Saying.
Take
this
token
present
it
to
the
this
API
server.
So
I
present
that
token
to
the
API
server
over
some
protocol
and
the
API
server
goes
great.
You
have
permission
to
access.
The
network
here
is
a
much
that
here
is
a
different
session
token.
M
This
is
your
session
ID
you.
You
hope.
You
hope
that
this
gets
you
to
whatever
the
system
has
been
set
up
to,
let
you
get
to
so.
If
you
go
through
the
web
page
and
sign
your
children
away
and
all
that
kind
of
stuff,
whatever
it
needs
to
happen,
you
get
handed
a
session
ID.
You
don't
have
to
present
that
to
anyone
anywhere,
you
just
hold
that
if
you
change
your
IP
address,
you
change
your
MAC
address.
You
come
in
on
a
different
fiber.
M
Whatever
ICMP
comes
back,
says
dinner,
who
you
are
here's
a
token
new
token?
Go
presented
to
the
API
server
and
you
go
back
to
the
API
server
and
say
it's
still
me.
Here's
the
session
ID
you
gave
me
earlier
and
the
API
server
can
decide
whether
you're
allowed
to
go
in
as
this
new
token
or
do
whatever
clever
stuff
at
once.
So
it's
a
two-part
exchange.
How
do
you
make
sure
that
you're
talking.
D
Era,
I'm
not
sure
I
would
like
a
new
transaction
to
happen
every
time
there
is
a
new
address
or
so,
and
it's
really
desirable
that
a
host
would
be
able
to
use
multiple
addresses
and
so
I
kind
of
agree
with
Lorenzo
that
one
good
way
to
do
that
is
with
prefixed
per
hosts
and
Indian
in
terms
of
security.
The
only
way
I
see
that
would
work
which
we
would
be
with
an
enforcement
point
not
only
on
the
link
l2
speaking,
but
on
the
wire
or
on
terms
of
Wi-Fi,
the
the
virtual
wire.
D
C
D
Think
we
cannot
in
terms
of
security,
any
model
that
relies
on
layer.
3
security
doesn't
work
any
model
that
relies
on
layer.
2
security
doesn't
work
because
the
MAC
address
can
be
spoofed.
We
cannot
make
generalization
about
the
security
of
the
layer
2.
So
the
only
thing
we
can
say
is
that
we
need
something
that
is
kind
of
secure
like
wire
physical,
wire
or
Wi-Fi.
That
is
able
to
discriminate
between
multiple
crimes
connected
and
once
one
client
on
one
port
or
virtual
port
is
connected.
That
becomes
the
identity,
that's
the
that's.
D
B
B
D
P
Okay
shower
off
work
for
Google
Android
Wi-Fi,
so
the
association
is
as
far
as
I
know,
right
if
it's
an
open
network,
the
AP
is
gonna,
have
some
some
state
with
things
like
buffers
right,
and
so,
if
you
somehow
tie
to
the
buffer
state,
then
sure
you
could
say
there's
some
kind
of
strong
association
even
for
open
Wi-Fi,
but
I
think
without
going
to
that.
It
really
is
just
the
MAC
address
right
now.
P
P
N
L
L
L
L
C
Here,
I
just
wanted
to
say
that
I
think
that
you
you're
burning
of
the
port
I
get
like
I
said.
If
you,
if
you
have
it,
if
you
have
to
enforcement
points,
you
can
just
base
that
on
the
IP
address,
which
is
I,
think
what
we
do
today
so
basically
enforced
locally,
that
the
that
the
prefix
that
I
got
is
tied
to
a
MAC
address
and
then
later
on,
that
that
prefix
is
enforced.
I
just
wanted
to
say,
though
we
can,
we
can
use
extension
headers
to
pass
the
tuple
walk.
Q
C
Me
just
interject
them
with
a
time
check.
I
think
we
have
about
45
minutes
to
an
hour
left.
We
have
two
more
presentations
for
which
we've
allotted
like
15
minutes
normally
including
questions.
So
we
have
maybe
15
20
up
to
30
minutes
at
most
for
this
discussion,
and
we
should
probably
just
cap
it
at
15.
So
we
can
ask
some
questions
of
the
room
to
see
what
decisions,
if
any
we've
made
and
should.
C
B
O
B
Id
that
and
I
also
I
understand,
there's
more
more
depth
here
than
I
know
about,
but
I
think
it
might
be
a
little
bit
clearer
to
say
that
this
is
something
that
you
get
in
DHCP
or
at
least
something
that
you
could
get
in
DHCP,
because
because
the
point
is
that
it
has
nothing
to
do
with
with
activity
on
the
part
of
the
user.
It's
all
to
do
with
the
with
the
enforcement
devices
view
of
of
the
user
and
that's
stable
from
the
point
that
the
user
joins
the
network.
So
that
can.
O
B
That
network
attachment
time
and
not
as
nothing
to
do
nothing
to
do
with
some
future
share
point,
and
so
there's
actually
no
need
for
this
to
it
to
include
to
append
anything
to
include
any
metadata
in
this.
This
access
denied
ICMP
response,
if
the
user,
sorry,
if
the
important
device
is
elsewhere
in
the
network,
so
where
so,
where
it
may
not
be
able
to
communicate
with
the
DHCP
server
or
is
that
it's.
B
Device
is
is
farther
away
in
the
network,
then
the
best
identifier
it
has
for
the
for
the
client,
its
client
ID
is
going
to
be
what
it
can
associate
with
the
client
that's
going
to
depend
whether
it
can
cooperate
with
the
nearest
gnat,
whether
it
could
cooperate
with
that
access
point.
That
knows
the
Association
ID,
but
but
all
of
that
is
a
it
seems,
like
that's
all
knowable
at
attachment
time
at.
N
Okay,
Tommy
yeah
I
very
much
agree
with
bringing
up
the
attachment
time
as
an
important
thing
here.
I
agree
with
what
Lorenzo
was
saying
essentially
like
we
can
just
kind
of
use
either
something
if
it's
something
that
we
get
in
a
Dave,
CP
or
RA
I'm
fine
with
that
I
think
we
could
also
just
kind
of
use
our
addresses
and
prefixes,
because
that
seems
kind
of
equivalent
at
that
point.
N
With
that
IP
address
to
the
enforcement
box,
you're
not
really
able
to
enforce
much
with
it
yeah
so
I
would
just
say.
Yes,
let's
write
down
the
constraints
that
this
produces,
but
I
think
if
we're
trying
to
do
more
of
a
session
token',
it
adds
a
lot
of
complexity
and
it's
not
really
clear
what
use
case
that
we
want
to
happen
in.
B
A
deployment
we're
actually
enabling
I'm
wondering
about
the
case
where
the
enforcement
device
may
not
be
actually
enforcing
whether
or
not
our
traffic
is
allowed
in
a
normal
case,
but
it's
denying
access
when
a
certain
event
occurs.
So,
for
example,
you
are
infected
with
a
virus
and
the
ISP
you
said:
nope
you're
blocked
now
go
away.
I
I,
just
wanna
make
sure
that
we
still
support
that
use
case
because
I've
had
a
couple
of
vendors
talk
to
me
and
say
they
want
this
use
case
or
ISPs.
Talk
to
me
and
say:
I
want
this.
G
Someone
Thomson
I,
think
I've
been
relatively
convinced
by
the
discussion
about
the
fact
that
the
enforcement
avoid
device
needs
to
have
some
sort
of
stable
identification
for
the
thing
and
needs
to
be
relatively
certain
about
that
identification.
So
you
cannot
rely
on
things
that
might
change
across
the
various
parts
of
I
think
it.
It
reads
to
me,
like
the
the
group,
is
fairly
solid
on
that
point.
I
think
the
the
one
use
case
that
Rick's
sort
of
strong
suggestion
that
we
do
this
sort
of
opaque
sessionid
thing
it
has
would
would
be
I
mean.
G
That
API
server
does
not
necessarily
need
to
sit
on
the
same
in
in
in
approximately
the
same
location
as
the
as
the
enforcement
device
in
that
case,
because
it
can
rely
on,
say,
cryptographic,
protections
on
that
on
that
opaque
identifier
to
transitively.
So
it
basically
to
look
from
the
perspective
of
the
enforcement
device
by
virtual
receiving
that
thing.
So.
O
O
O
B
G
That's
one
particular
deployment
topology
that
would
be
enabled
by
this
now
I
think
I
think
to
Lorenzo's
point
here.
Yes,
if
you're,
if
you're
right,
if
you're
using
an
IP
address
and
the
IP
address,
is
not
suitable
to
the
enforcement
device
and
not
suitable
to
the
API
device,
you're
effectively
saying
that
they're
more
or
less
in
the
same
part
of
the
network,
and
so,
if
you're
willing
to
accept
that
constraint
and
I
I,
don't
know
whether
we
are
willing
to
accept
that
Rick's
shaking
his
head
and
saying
well,
I
think
we
can.
G
G
I,
don't
think
I'm,
seeing
much
call
for
people
putting
explicit
IP
addresses
or
anything
in
these
messages
or
anything
like
that.
I!
Don't
I
didn't
hear
any
of
that.
So
we
can
probably
scratch
that
one
which
to
me
would
be
a
win
and
then
it's
probably
up
to
folks
like
Kyle
to
actually
do
the
legwork.
Does
that
sound
like
a
reasonable
summation
of
the
position
we
kind
of
reach
in
that
discussion?
It
seemed.
N
So
we
brought
up
this
case
of
the
API
not
being
kind
of
co-located
on
the
same
link
or
the
same
path,
and
so
I
see
that
I
mean
maybe
that's
a
problematic
thing
that
we're
adding
a
constraint
to
you.
Could
let's
say
if
you
don't
have
a
session
ID
explicitly
send
you
know
here's
the
packet
that
I
would
have
sent
to
the
enforcement
device.
N
You
know
here's
my
MAC
address,
here's
my
IP
addresses,
etc,
and
so
that
is
kind
of
like
a
token,
and
so
what's
the
problem
with
that,
that's
you
could
just
say:
spoof
it.
It
could
be
whatever
you
want.
I
I
don't
actually
see
how
there's
any
difference
between
that
and
the
security
between
this
token
that
I
get
back
for
my
session
because,
let's
say
I
on
my
phone
talk
to
the
enforcement
device.
I
talk
to
the
network,
hopefully
I
don't
have
to
get
ICMP
just
to
realize
them
captive.
N
N
That,
let's
just
lets
me
get
to
this
other
entity
on
the
internet
and
like
get
in
I,
can
now
give
it
to
all
my
other
devices
and
like
in
the
same
way
that
all
my
other
devices
can
spoof
like
it's
a
slightly
harder
thing
to
construct,
but
I
can
just
advertise
this
to
the
entire
world,
and
now
everyone
in
the
world
can
act
as
if
they're
my
session
ID.
So
the
only
way
to
fix
that
is
to
have
again
the
API
server
in
a
place
where
you
can
say
you're
on
that
network.
N
C
M
G
Other
identified
that
he's
talking
about
is
a
safe
database
key,
for
instance,
that
says
this
is
Rick
or
my
understanding
of
brick
and
coffee
and
he's
bought
a
coffee
so
he's
allowed
in
and
would
have
a
number
of
the
other
identifiers
listed
against
that
such
that
the
API
server,
when
it
decides
to
let
Rick
use
the
network,
can
go
to
the
enforcement
device
and
say,
if
you
see
X,
let
it
through.
If
you
see
Y,
let
it
through.
G
F
B
M
O
C
So
so
I
think
we
we
had
a
while
ago,
there's
a
pretty
strong
statement
that
we
did
not
want
to
be
able
to
facilitate
differential
treatment
on
the
basis
of
destinations.
Okay,
so
I
would
argue
and
maybe
I'm
wrong,
but
in
in
first
instance,
I
would
argue
that
that
means
that
your
token
cannot
change
and
you
can't
get
a
new
token,
because
if
I
have
to
ask
for
permission
from
the
network
to
get
a
new
token,
then
that
means
well.
If
you
want
to
get
to
Facebook
here's
a
token.
C
G
M
C
My
point
was
therefore:
if
we
made
the
token
intentionally
static,
we
would
at
least
not
be
facilitating
such
abuse,
and
we
would
in
fact
be
designing
a
system
that
was
clearly
not
intended
now,
whether
it's
not
intended
and
whether
it's
secured
against
abuses
at
different
things,
but
I
mean
I.
Think
then,
if
it's
not
intended
for
abuse,
then
we're
not
gonna
have
a
difficult
time
later
on
securing
it,
because
we
know
what
we
built
right.
So,
even
if
we
don't
secure
it
immediately,
then
we
know
that
well,
this
is
the
way
it's
design.
C
B
Then
Schwartz
I,
just
on
top
the
topic
of
abuse
I,
just
want
to
emphasize
again
that
if
this
is,
however,
the
token
is
constructed
if
it's
something
that
you
do
at
network
association
time
once
rather
than
something
that
comes
back
in
an
ICMP
packet
and
I,
don't
think
it
matters
how
the
token
is
constructed.
I
was
one
thing:
I
was
thinking
about
with
respect
to
Association
time
or
attach
time,
whatever
we're
calling
it
is
it
unreasonable?
Supposing
we
do
have
the
API
server
somewhere,
you
know
across
the
world.
B
G
We
can
think
about
so
I'd
like
to
make
sure
that
we
have
someone
on
the
hook
for
this.
If
you
put
the
assistance
of
the
minutes
look
into
this,
do
you
think
you
could
provide
a
short
description
of
the
two
things
that
we
discussed
here?
I
mean
that
the
minutes
will
be
great
I'm
told
they're
awesome,
but
that
will
contain
a
level
of
detail
that
I
think
most
people
will
be
unwilling
to
spend
the
time
to
wade
through.
E
B
B
B
The
other
issue
that
was
raised
is
that
it
doesn't
give
you
an
explicit
indication
of
whether
or
not
you're,
actually
behind
a
cavity
portal,
which
is
something
that
could
be
desirable
and
we
could
do
with
PVD.
It's
really
slider
pivot
order,
but
next
slide
and
yeah.
That's
what
this
is
so
I
guess
it's
probably
a
question.
We
want
to
ask
I,
don't
know
if
we
want
to
hum
on
it
or
not,
but
do
we
want
to
should
I
just
ask?
B
N
N
Think
we
need
to
talk
more
about
essentially
cap
deferral,
discovery,
I,
guess,
I
think
the
only
thing
we
have
enough
information
right
now,
for
is
to
say:
do
we
think
that
7
7
10
alone
is
insufficient,
because
I
think
that's
the
one
thing
I've
heard
being
relatively
clear
that
either
needs
to
be
updated
or
replaced,
but
we
should
discuss
more
length.
The
nature
of
that
update,
I
great.
C
So
I
think
the
only
deficiency
I
mean
there
is
a
diffusion,
see
in
7710
that
it
says
it
doesn't
say
what
it
is
right.
But
you
know
we
can
say
that,
and
we
can
say
you
know
if
you,
if
you
I
mean
I,
don't
know
of
any
existing
compliment.
Ation
you'd
say
basically,
if
you,
if
you
use
this
content
type
or
this,
this
accepts
header,
then
then
you
get
like
the
API
server
and
that's
a
poor-man's
version
of
PVD
I
mean.
B
C
E
C
The
document
it
doesn't
say
what
to
do
explicitly,
but
it
seemed
to
be
designed
such
that
implicitly,
it
was
the
web
endpoint
from
which
you
begin
your
travails
right,
but
like
given
the
absence
of
implementations,
it
would
be
easy
to
say
well.
We
can
just
update
that
document
and
say
ask
a
question
with
this
epps
header
and
then
you
will
get
the
API
or
something
so
now
we're
gonna
do
the
PVD
download
anyway.
You
know,
given
that
we
don't
have
an
implementation.
C
M
L
B
G
So
I'm
gonna
expect
that
we're
gonna
get
something
in
the
next
few
weeks
about
this
and
then
I
I
hope
that
the
people
are
here
will
provide
their
feedback
on
that
and
we
will
try
to
make
a
decision
on
list
before
the
next
meeting.
If
this
doesn't
happen,
we'll
be
organizing
a
call
of
those
people
interested
so
I've
no
interest
in
having
the
next
meeting
occur
without
a
decision
on
this
particular
point.
It
would
be
good
if
we
could
take
the
discussion
on
7710
a
little
further.
G
I
am
not
averse
to
providing
it
producing
a
document
from
this
working
group.
Speaking
a
rare,
a
director
may
disagree,
but
I
I
would
talk
to
our
area
director
and
try
to
convince
him
that
producing
a
document
that
obsoleted
7710
by
improving
it
in
some
mother
would
be
a
reasonable
thing.
If
the
working
group
decided,
that
was
a
good
idea,
but
Adam
can
speak
to
that
right.
So.
G
K
So
I'll
have
to
talk
to
him
about
whether
that's
something
that
he
thinks
is
reasonable,
I,
don't
think
I'd
have
to
read
it
very
carefully.
I,
don't
think
that
charter
currently
includes
that,
but
I
wouldn't
necessarily
be
averse
to
adding
that
if
it's
something
that
we
think
is
necessary
for
success,
and
if
it's
something
that
the
the
Alpes
folks
thinks
is
a
reason
that
ops
folks
think
is
reasonable
to
do
correct.
G
D
G
We
can
talk
about
it,
but
I
think.
First,
we
want
to
decide
here
whether
or
not
we
want
to
take
that
take
that
on
and
whether
we
identify
the
shortcomings
and
see
whether
or
not
we
want
to
take
it
on
that
would
have
been
an
explicit
signal
that
you're
not
captive
or
that
there
isn't
a
captive
portal.
I
will
say
and
the
clarification
of
what
happens
go
over
to
the
URI
Thanks
I
think
those
are
minor
things
yep.
C
So
the
previous
slide,
we
say
you,
you
want
a
decision
on
that
point.
I
think
I'm
gonna
say
that
we
could
I'm
gonna
say
that
we
need
the
combination
of
Mac
and
okay,
like
combination
of
Mac
and
IP,
for
ap6,
with
enforcement
happening
two
different
points
which
presumably
could
be
something
else,
but
it's
I,
yeah
I
would
like
that
to
be
one
of
the
options
that
we
decide,
because
that
I
know
does
that
make
sense.
Those
are
all
properties
of
the
attach
time
too
right.
Yeah.
N
N
N
So
there
are
a
number
of
editorial
changes
made
there.
Among
other
things,
in
the
privacy
considerations,
it
is
kind
of
captive.
Portals
has
been
re
added
back
in
as
an
explicit
thing.
That's
been
called
out
in
the
document,
as
it
has
a
side
effect
because
essentially
when
we
are
doing
the
PVD
attachment,
because
this
is
a
network
attached
thing-
we
are
not
actually
having
to
create
any
traffic
on
the
network
that
is
showing
kind
of
what
we
were
trying
to
access.
First
before
we
have
done
some
negotiation
to
figure
out.
N
Do
we
even
want
to
connect
to
this
network
so
again
either?
The
PVD
approach
is
really
all
about
how
we're
getting
the
discovery
of
the
captive
portal
based
on
things.
We
can
do
it
attach
time.
A
lot
of
implementations
ios/android
are
in
some
sort
of
state
in
which
you
don't
want
to
really
be
using
your
network.
Until
you
know
you
are
not
captive,
I'm
so
doing
something
that
doesn't
rely
on
throwaway
probes
is
very
useful
for
this,
so
yep.
So
the
docum.
It's
going
well
going
head
next
slide.
N
Okay,
so
here's
the
pitch
for
why
we
should
use
PV
DS
for
captive
oral
discovery
in
here
I
mean
clearly
I'm
fine.
If
we
also
take
seven
seven
ten
and
try
to
update
it
to
do
the
equivalent
things
from
a
practical
standpoint,
because
I
believe
the
PVD
work
is
important
and
useful
is
kind
of
filling
the
same
role.
I'd
like
to
see
our
kernels
changed
once
so
that
we
can
get
this
information
up.
N
N
Can
we
take
it
further,
so
the
way
that
this
works
is
a
PVD,
the
PVD
information,
so
I
get
a
PVD
identifier
coming
down
to
me
and
our
a
it
says:
here's
the
kind
of
long-lived
static
information
that
you
can
go
fetch
as
it's
API,
that
long
live
static.
Information
can
point
to
your
captive,
API,
server
or
whatever.
N
That
could
also
go
here
and
hopefully
would
be
easier
to
extend
than
adding
more
DHCP
and
Ra
options,
because
it's
a
little
bit
more
flexible
of
a
dictionary
and
a
key
thing
of
this
also
is
that,
because
we
are
using
RA,
is
for
this
this.
If
your
overall
network
configuration
changes
at
some
point,
it
can
push
you
a
new
RA
and
here's
your
new
generation
count
of
your
PVD.
You
fetch
it
again.
You
realize
that
there
is
now
a
new
law
enforcement
in
town,
so
yeah
we
have
the
side
effect
of
you
know.
N
If
you
are
doing
captive,
you
better
put
the
captive
pointer
in
here
and
if
you're
not
doing
captive
I
mean
then,
if
you
give
pvd's.
Otherwise
we
assume
that
you're
not
giving
a
captive
Network.
Of
course
you
can
still
be
evil.
You
can
still
block
traffic,
but
then
the
devices
can
feel
free
to
be
evil
or
not
join
your
network
back.
N
But
so
one
option
is
that
even
on
these
v4
only
networks,
you
can
still
send
an
RA
and
you
don't
ever
give
them
a
v6
address
or
a
v6
prefix
or
a
route,
but
they
can
still
get
the
information
that
way,
and
then
you
still
have
your
pointer
over
to
your
PVD
server.
So
that's
an
option
all
right
next
slide.
N
So
here
are
just
some
open
discussion
questions
and
we
can
talk
about
these.
So
one
thing
is
that
this
solution
does
add
a
little
layer
of
indirection.
It's
not
necessarily
too
terrible,
because
this
is
something
that
you're
probably
going
to
fetch
anyway.
The
moment
you
attach
it's
just
kind
of
like
one
little
extra
roundtrip.
N
N
N
The
PVD
lookup
is
sent
over
TLS.
So
there's
a
you
know
some
level
of
encryption
privacy,
not
necessarily
client,
authentication
or
anything
like
that,
but
it's
better
than
just
dumping
out
everything
that's
going
on
between
these
two
devices.
So
if
we
wanted
to
put
more
private
session
tokens
or
something
it's
a
better
Avenue
for
that
yeah
and
and
there's
more
flexibility
to
pointing
for
other
things,
great
so
that's
kind
of
where
I
am
on
that.
N
If
people
have
opinions
and
thinking
this
is
a
non
helpful
layer
of
indirection
I'd
love
to
hear
that
we
can
discuss
so
another
discussion
that
was
happening
with
some
people
at
the
hackathon.
When
we
were
kind
of
brainstorming
about
captive
portals
is
when
we're
gonna.
We
want
to
publish
a
captive
API
document,
and
this
is
essentially
here's
your
dynamic
JSON
that
you
interact
with
to
say
am
I
still
captive.
How
much
time
do
I
have?
Where
do
I
go
to
pay
you
money,
terrible
things
like
that.
N
One
question
I
have
is:
is
that
a
truly
just
captive
API
and
this
RFC
is
this
is
just
for
captive
stuff?
Or
do
we
view
this
potentially
as
here's
mechanisms
for
interacting
with
a
more
dynamic
per
device,
a
sub
set
of
properties
such
that?
If
we
had
other
similar
cases
that
weren't
the
traditional
captive
Network,
we
would
put
it
there.
N
That's
an
open
question
in
that
regard.
You
could
almost
view
it
as
a
4-time
I,
like
that,
the
yin
and
yang
of
you
have
your
static
side
of
a
PVD
which
changes
on
a
generation
count
and
that's
your
network
configuration
and
it
can
point
to
one
or
more
more
dynamic
objects
captive
being
one
of
those
and
being
the
primary
one.
Right
now,
but
potentially
on
other
situations
like
we
were
talking
about
a
carrier
network
that
starts,
you
know
saying
your
plan
is
gone,
and
so
you
can
go.
N
Ask
other
information
on
a
more
per
device
level.
So
that's
more
about
a
terminology
question
how
we
talk
about
things
going
forward,
but
it
could
be
interesting
and
then,
lastly,
so
I
think
we
believe
the
Peabody
authors
that
you
know
dropping
in
a
pointer
to
how
you
get
to
captive
makes
a
lot
of
sense.
N
N
That
is
a
question
that
would
need
to
be
worked
out
as
well,
so
I
think
that's
all
I
have
if
there
are
any
questions,
I'd
love
to
hear
discussion,
I
think
you
know
today,
we've
been
mainly
trying
to
nail
down
this
identifier
thing
that
is
very
important,
but
there's
also
the
looming
question
of
how
are
we
discovering
these
things
and
we
just
need
to
make
up
our
minds
so
any
pros
and
cons.
I'd
love
to
hear.
J
Some
Michael
Abramson
just
on
the
before
there
one
reason
for
not
deploying
at
Music's,
is
because
you
don't
have
first
top
security
for
v6,
so
you
might
just
do
block
the
through
type
or
something
like
that
to
not
have
v6
at
all
to
do
abuse
handling
so
then
to
tell
them
that
they
need
to
deploy
our
ace
in
order
to
do
PVD
announcements
for
v4
only
that
might
be
hard
for
some
network.
That's
a
good
point!
Yeah.
C
Now
you
now,
when
you
also
news
when
you
use
Ras
and
a
v6,
only
Network,
someone's
gonna
tell
you
that
now
interview
for
only
network,
so
yeah,
then
then
someone's
going
to
tell
you
that
a
rogue
device
can
send
the
RA,
and
so
now
everyone
has
to
you
know
deploy
are
a
guard
on
legacy
infrastructure.
That's
never
going
to
be
changed,
so
it's
it's
non.
Non-Trivial
I
am
on
the
specify.
C
N
All
I
want
to
have
is
to
make
it
possible
to
be
good
and
right
now
it
is
not
right
now,
every
time
I
do
an
in
network
I
have
to
send
a
probe
to
something
either
to
something
that
the
user
really
wanted
to
get
to
or
something
that
gives
away.
The
fact
that
I
am
an
Apple
device
or
an
Android
device
running
this
particular
version
of
the
operating
system,
because
here's,
the
probe
that
it
sends
out
you
just
need
to
change
them
more
frequently.
C
Sorry,
okay,
like
I,
said,
but
there
I
don't
anyway,
if
we
sure
I,
don't
think
it'll
be
benefit,
but
I,
don't
think
it's
harmful!
One
thing
that
I
wanted
to
say
about
the
the
let's
see
so
the
the
whether
we
should
have
sub
pvd's
on
a
per
device
basis
I'm
anxious
not
to
so
in
order
to
Rev
those.
How
do
you
rev
them?
Do
you
send
a
multicast
array
with
a
new
sequence
number
right.
N
So
that's
I
think
captive
has
a
really
clean
solution
to
this,
because
the
the
failure
case,
the
timeout
case
of
captive
information-
is
you
get
blocked
and
you
get
ICMP
back
in
bad
better
than
that
as
beautiful
right.
So
ideally,
I
would
say
my
ideal
case.
I
get
my
PVD.
It
says
your
captive
I
talked
to
my
captive
server.
It
tells
me
you're
logged
in
you
have
this
much
time
and
then
I
can
re-up
it
or
do
something
before
I
get
blocked.
But
if
something
changes
we
get
ICP
so
that
solves
itself.
But
there.
C
C
N
C
Back
and
I'm
gonna
say
that
we
shouldn't
be
using
per
device
out.
So
yes,
if
they're
Network,
wide
things,
yes,
we
can
use
our
raise,
but
we
shouldn't
use
our
raise
on
on
like
oh,
your
sub
PVD
has
changed.
Therefore,
I'm
gonna
send
either
you
and
you
are
a
which
means
that
the
Rooter
has
to
keep
a
lot
of
state
or
I'm
going
to
send
everyone
a
new
RA,
which
means
that
everyone
drops
them
right.
N
C
N
C
M
Rick
Tyler
again
one
quick
question:
the
question:
several
people
have
raised
the
point,
with
ipv4
only
networks
and
requiring
Ras
on
ipv4,
which
I
agrees.
It's
not
it's
just
not
going
to
take
off
they're,
just
not
going
to
do
it.
So
is
it
boss?
It
would
one
way
forwards
be
to
look
at
doing
a
7710
base
to
just
handle
the
ipv4
case
just
say:
yeah,
PV
DS.
This
is
the
way
forwards.
It's
all
built
on
Ras
in
the
dual
stack
and
all
your
new
stuff
is
great.
Go
this
way
guys,
but
for.
M
M
N
Cool
so
I
mean
I.
Think
the
first
order
of
business
for
the
group
is
to
kind
of
follow
up
on
the
main
identifiers
stuff,
but
I
would
like
to
have
kind
of
also
at
the
same
time,
convergence
and
discussion
on
the
discovery
aspects.
So
I
think
the
main
thing
that
I
want
to
take
back
as
an
action
item
is
the
v4
only
case
and
just
make
up
our
minds
and
then
we'll
send
it
out
and
say:
does
this
look
good
to
everyone?
Yes
or
no
great.
C
C
How
many
people
here
have
have
read
the
ICMP?
You
draft
okay,
so
you
know
that
it
has
two
portions
right:
it's
got
sort
of
one
half
that
defines
a
new
destination
unreachable
sub
code
and
then
it's
got
second
half
which
defines
an
entirely
new
capture
portal
code
point
and
had
a
bunch
of
extension,
information,
new
message
right
and-
and
it
was
in
fact
from
the
from
the
letter
that
the
whole
session
ID
discussion
was
I.
C
G
So
so
my
understanding
is
that
there's
destination
unreachable
with
an
extension
and
the
extension
carries
I.
Think
some
of
these
extra
parameters
like
like
this
session
ID
that
we've
talked
about
and
so
I
think
we're
gonna
wait
for
a
little
more
discussion
about
the
implications
of
session
IDs,
first,
not
having
session
IDs
on
the
list,
once
we've
seen
more
of
a
summary
and
has
some
time
to
think
about
them,
but
the
so
that
will
determine
the
fate
of
ICMP.
G
To
that
extent,
but
we'd
like
to
get
an
idea
of
whether
people
are
interested
in
the
part
1
of
the
ICMP
thing,
and
then
whether
people
are
interested
in
the
part
2
and
we
haven't
talked
a
lot
of
our
part
2
in
this
room,
but
but
we
saw
that
a
large
number
of
people
have
actually
read
the
document.
My
understanding
of
the
the
use
cases
behind
part
2
is
to
provide
things
like
advanced
warning
of
captive
portal
enforcement
coming
down
so
five
minutes
ahead
of
things.
G
N
I'm,
just
looking
at
the
document
now
to
kind
of
figure
out
what
the
options
that
we
have
are.
So,
as
it
says,
in
the
very
beginning
of
the
document,
one
option,
the
do-nothing
option
would
be
send
unreachable
with
administrative
lepra
hibbott,
which
I
believe
is
when
we
were
doing
hackathon
stuff,
actually
the
code
that
was
being
sent.
So
that's
the
do-nothing
option,
but
still
prescribed
that
you
should
send
it
for
captive
portals
to
I.
N
N
N
G
N
B
B
Or
the
new
vice
and
p-type
was
that
it
would
be
ignored
by
devices
which
don't
understand
it,
and
the
problem
is
if
you
were
to
send
a
destination
reachable
for
a
just
to
say,
hey
you're,
about
to
expire.
You
would
actually
in
a
blocking
a
traffic
that
you're
responding
to,
and
that
could
be
problematic
because
you
don't
want
to
interrupt
that
flow
or,
as
with
the
new
one,
you
can
send
it
and
it
won't
actually
cause
anything.
If
you
don't
understand
it
so
I
mean
I'm,
not
sure.
M
That's
quite
hard
to
follow
target,
slightly
less
doomed,
I
think.
The
second
part
of
that
question,
which
was
using
the
ICMP
new
ICMP
code
to
say,
hey
your
sessions
going
to
expire
in
five
minutes,
I
think
that's
the
wrong
latter
bit
we're
not
there
as
it's
the
wrong
channel
to
be
sending
those
messages
that
should
be
tied
into
the
router
adverse
minore,
the
DHCP
or,
however,
where
we're
doing
the
PVD
stuff.
That's
sort
of
control
plane,
rather
than
hey
your
traffic's,
not
going
anywhere
so
I'd
be
against
the
second
half
of
that
is.
C
M
Portal
enforced,
oh
I,
think
there's
benefit
in
saying
your
destination
is
unreachable
because
there's
a
captive
portal,
whether
that
is
the
sub
code
on
destination
unreachable
or
whether
you
want
to
do
it.
The
next
code
layer
up
fine.
What
I'm
against
is
having
another
ICMP
message
in
there
to
say
it's
about
to
be
unreachable,
that's
a
more
of
a
provisioning
thing
and
should
be
covered
by
the
relevant
provisioning
protocol,
not
ICMP.
N
So
yes,
I
think
there's
there
could
be
a
generic
problem.
If,
if
you
just
started
sending
unreachable
back
legacy
captive
portal
approaches
like
probing
would
fall
over
quite
likely
right,
but
you
may
actually
block,
like
you
may,
in
giving
getting
a
different
user
behavior
on
devices.
Do
we
like?
Is
that
a
negative
thing?
Do
we
want
to
avoid
that?
N
Because
one
option
we
have
is
to
say
that
we
have
a
new
ICMP
unreachable
code
point
that
says
by
the
way
I'm
captive,
and
this
is
coming
from
the
enforcement
device
and
presumably
the
enforcement
device
knows
whether
or
not
you
went
through
the
captive
portal
API
already,
so
you
could
imagine
that
I
mean
so
it
knows
how
I
ever
opened
this.
So
if
I
go
through
the
new
path
to
say,
I
discover
the
captive
portal,
API
I
say:
oh
look:
you're
you're
there
I'm
going
to
open
this
up.
N
The
ICMP
is
a
great
way
to
say
now
you
have
closed
right
to
say
you
used
to
be
open.
Now
you
have
closed,
and
presumably
anyone
who's
implementing
the
new
captive
for
LAPI
stuff
would
be
aware
of.
We
could
say
you
have
to
be
aware
of
the
captive
portal
ICMP
blocking
responses
and
used
as
a
mechanism,
but
anyone
who
did
not
already
open
up
their
portal-
maybe
we
don't
generate
the
ICMP
for
them
or
we
generated
in
some
legacy
compatible
way.
M
Just
jumping
in
rotator
again
you've
got
a
very
good
point
there
and
I'm.
In
my
opinion,
as
I
speak,
the
problem
with
saying
destination
unavailable
with
the
ICMP
message
in
the
presence
of
a
captive
portal
is,
is
that's
actually
not
what
happens
in
practice.
If
there's
a
captive
portal
in
the
way
there
is
the
destination,
it's
just
not
the
destination.
You
thought
it
was.
G
C
Got
there,
let
me
ask
another:
questions:
like
is:
is
a
clear
text
notification
really
the
best
we
can
do
here
like
we're,
defining
a
greenfield
deployment
with
an
API
and
we're
really
saying.
Well,
you
know
the
first
strategy
for
this
isn't
on.
Is
it
basically
an
unauthenticated
ICMP
message?
Is
that
really
the
best
we
can
do
can't
we
at
least
like
stuff
a
token
in
it
or
something?
Oh,
yes,.
C
G
J
It's
effectively
signing
it
with
the
symmetric
key
words.
So
somehow,
when
you
contact
the
EPI
first,
you
learn
like
a
public
key
or
something
ability
of
the,
and
then
it
signs
to
pack
it
with
whatever
private
key
was
there,
so
you
can
now
say
it
these
two
people,
these
two
devices,
know
about
each
other,
a
shared.
J
G
G
Icmp
unreachable
would
contain
something
that
is
derived
using
a
hash
from
the
private
key.
Therefore,
okay,
it
would
not
contain
any
of
the
key.
Therefore,
no
one
color
and
and
the
only
two
devices
then
that
are
able
to
deny
trigger
this.
This
new
behavior
is
the
API
device,
anyone
that
tells
the
key
to
and
the
endpoint
anyone
who
tells
a
key
to
it
goes
to
or
the.
B
To
make
this
whole
thing
work
that
you
could
just
join
the
network
and
when
connecting
externally
the
ICP
will
come
back
and
say:
hey
crap,
you
know
something's
wrong,
go
and
connect,
and
this
would
help
if
you,
you
know
you
accidentally
disconnected
or
a
computer
reboot
or
you
lost
your
session
ID
or
something
like
that.
The
second
thing
is
that
there
is
right
now,
there's
nice
properties
with
the
icing
with
the
destination
and
reachable
in
that.
B
Then
Schwartz
I
just
want
to
point
out
that
it's
not
obvious
that
there's
nothing
true
P
for
this
H
Mac
to
prevent,
replace
if
I,
because
I
don't
know
if
the
packet
is
it's
replying
to.
You
is
actually
a
syn
packet
like
it's
not
a
whole
lot
of
entropy
in
there,
but
there's
probably
a
design
with
a
counter
or
some
additional
entropy
or
some
replay.
N
Think
we
discuss
whether
or
not
we
want
to
keep
the
assumption
that
you
don't
have
to
talk
to
the
API
server
because
I
feel
like
if
we,
if
we
want
to
have
you
essentially
blocked
later
and
then
you
go
talk
to
the
API
server.
Clearly,
you
have
written
the
code
to
be
capable
to
talk
to
the
API
server,
so
you
may
as
well
do
that
at
provisioning
time,
if
you're
not
capable
of
talking
to
it,
I
feel
like
we're
kind
of
in
the
existing
cap
deferral
world
I
mean
we
haven't,
moved
the
ball
forward.
N
One
nice
thing
is:
if
we
use
something
like
the
API
server
to
be
the
bootstrapping
factor,
then
we
can,
from
that
point
on
essentially
clearly
distinguish
on
a
captive
portal
enforcement
device.
People
who
have
kind
of
gone
the
legacy
way
and
people
have
gone
the
new
way,
and
so
that
actually
also
creates
a
transition
mechanism
in
which
they
can
kind
of
know
per
thing
that
they're
blocking
or
allowing
how
that
actually
got
in
there.
B
Don't
think
the
full
solution,
I
think
the
full
solution
certainly
needs
an
API
server.
Like
you
can't
just
being
told
you
you're
behind
a
captive
portal,
isn't
super
helpful.
You
need
to
tie
it
all
together,
but
I
I
guess
can
I
seem
he
on
its
own
at
least
improve
what
we
have
now,
even
if
it's
not
making
it
so
you
log
in
pop
up
the
ought
to
pop
up
the
page.
Am
I
happy
things
like
that.
C
C
O
N
So
today,
let's
say
I'm
running
current
version.
You
know
this
year.
Ios
11
iPhone
joins
this
captive
portal.
I,
try
to
load
random,
clear
text
webpage
because
I
know
I
need
to
get
onto
this
portal
by
using
clear
describe
page
I
get
unreachable,
I
close
the
connection.
You
can
no
longer
join
the
portal
ever
on
any
device
that
was
built
before
next
year.
I
C
C
Okay,
thank
you
all
I
think
we
have
some
discussion
of
identifiers
and
and
so
on,
to
look
forward
to
on
them
on
the
list.
We
also
have
a
new
API
document
to
look
forward
to
with
some
awesome
crypto
to
look
forward
to
always
very
exciting,
see
we'll
see,
hope
to
see
people
in
London,
safe
travels
and
heavy
holidays.