►
From YouTube: IETF97-RADEXT-20161116-0930
Description
RADEXT meeting session at IETF97
2016/11/16 0930
A
Okay,
so
good
morning
everybody
it's
a
9
30
sharp.
So
let's
get
started
with
the
radix
meeting.
If
you
don't
want
to
get
a
text
go
elsewhere,
so
let's
as
usual,
start
with
a
note.
Well,
if
you
manage
to
get
to
a
you,
IDF
Wednesday,
without
seeing
it
Congrats,
but
your
days
are
counted
here.
It
is
so
the
agenda
for
today
is
actually
not
very
fact.
A
I
was
with
enthusiastic
after
the
last
meeting
in
Berlin,
where
huge
amounts
of
people
showed
up
great
discussions,
so
reserved
90
minutes
to
have
a
bit
more
time
turns
out
that
we
actually
only
have
60
minutes
full
of
speaking
times.
So,
if
you
have
lots
to
discuss,
take
your
time
we're
going
to
have
it.
A
A
Okay,
so
Ryan
is
30
minutes.
Thank
you,
okay.
So
the
rest
of
the
agenda
is
that
I
will
give
a
short
overview
about
our
document.
Size
now
now
talk
much.
That
is
overview,
as
you
will
see
from
that
overview.
It's
a
bit
special
this
time
because
pretty
much
most
/,
almost
all
of
our
documents,
which
we
have
on
the
charger,
are
pretty
much
done.
A
So
we
don't
have
anybody
talking
about
active
working
group
grafts
this
time,
so
instead
we
will
have
plenty
of
new
things
to
talk
about
and
I
think
that's
actually
great
opportunity
to
think
again
about
what
radix
to
be
doing
the
future.
So
there's
an
influx
of
work
and
I
find
that
pretty
well,
so
there's
going
to
be
a
10-minute
presentation
about
radios,
extensions
for
mud
at
the
Brian,
then
we
have
dhcp
packet
signing
via
attitude
of
1x,
just
a
short
presentation
of
five
minutes.
You
might
be
wondering
hey
what
is
this
doing
here?
A
So
enemy
is
actually
presenting
this
in
sac
and
he
is
aiming
for
an
ad
sponsorship,
but
this
is
something
we
should
well.
We
might
want
to
be
aware
of,
even
though
there
is
no
radius
in
the
title.
Then
we
have
laura1
authentication.
Reviews
on
this
is
the
second
presentation
of
that
topic.
Last
one
was
very
well
received
and
very
vivid
discussions
around
it,
so
that's
gonna
be
nice,
I
hope.
A
And
lastly,
there
is
a
not
quite
ready
work
about
proxy
considerations:
how
to
do
proxy
write
and
tell
not
again
help
better
the
remotely
mm-hmm,
but
there
is
no
ID
to
read
about
that
yet
so
we
will
all
be
surprised
and
finally,
our
five
minutes
for
the
rapid
next
steps
and
actually
well.
We
should
have
30
minutes
of
leeway
at
that
point,
so
everybody
gets
to
the
next
meeting
on.
But
again,
if
you
feel
you
have
to
discuss
something,
please
do
go
ahead.
A
But
couple
of
hours
ago
it
went
to
the
RFC
editor
q,
so
these
were
two
working
group
items
which
we
don't
have
to
do
anything
about
anymore.
So
can
we
considered
down
here
and
that's
pretty
much
empty?
Is
our
charter
set
for
two
documents,
one
of
which
we
also
have
very
much
done
in
terms
of
working
group
stage?
Sorry.
C
A
A
We
had
a
one
in
the
last
call
just
after
the
ITF
96
meeting
and
nobody
spoke
up.
So
I
think
that
as
a
good
sign-
and
this
means
my
process
when
we've
asked
or
completed
without
comments-
means
we
can
move
forward
with
publication.
So
we
still
have
to
assign
a
deck
document
shepherds
and
do
the
document
right
up
turns
out
that
leone
on
the
war
isn't
here
today
so
well,
that
was
a
mistake.
So
we
have
a
new
chef
Rick.
A
No
just
kidding
am
so
nearly
let
me
we'll
sort
it
out
who
is
shepherding
these
documents,
but
it's
on
its
way,
basically
and
stuff
in
water
be
done,
and
the
last
document
we
have
is
then
my
own
document
on
considerations
on
how
to
use
eep
response,
identity
right,
I
still
didn't
manage
to
submit
an
update.
So
I
just
have
a
few
words
on
it
on
the
rack
up
slide
and
that's
basically,
all
it
is
the
only
document
that
is
actually
still
in
the
works
in
this
working
group.
In
terms
of
our
charter.
A
A
Okay
and
yeah,
this
would
be
a
document
which
is
very
definitely
inside
our
chargers.
I
think
this
is
clearly
knew
were
coming
up.
We
also
have
the
laura1
authentication
radios
the
office
submitted
in
no
to
version
or
just
be
caught
before
the
cutoff,
and
we
discuss
about
this
today.
We
had
a
good
reception
already.
So,
let's,
let's
see
how
it
goes.
Another
document
that
is
surfing
around
since
of
why
now
is
the
radius
extensions
for
network
assisted,
multipath
TCP.
A
There
is
meanwhile
in
our
free
version,
and
the
authors
requested
a
call
for
adoption,
so
I
don't
think.
There's
any
problem
with
that.
So
as
soon
as
I
DF
is
over,
I
will
start
a
two-week
call
for
adoption.
Please
do
read
the
latest
revision
first
and
then
form
your
opinion.
Do
you
think
that's
something
we
should
be
working
on
in
a
text
or
not
and
last
well,
maybe
at
least
I
don't
know
is
the
extended
packet
header
for
radius.
A
They
also
got
fair
amount
of
beating
in
the
last
meeting,
so
I
don't
know
what
their
what
their
plans
are
for
this
one
unless
I
hear
from
them,
I
think
we
can
drop
this
off
the
radar
unless
they
say
otherwise
right.
That's,
that's
it
for
the
your
document
update.
So,
let's
now
think
about
the
video
draft
discussion
and
the
first
one
up
would
be
a
Ryan
for
the
radius
extensions
for
mud.
D
Good
morning
this
is
so
this
work
is
in
conjunction
with
some
work.
That's
happening,
the
OP
started
working
group
and
you
can
go
to
the
next
slide.
Please
so
I
think
everybody
understands
for
the
events.
The
last
few
weeks
there's
no
longer
any
doubt
that
how
to
devices
are
under
attack,
and
we
knew
that
already
before,
but
this
is-
and
this
is
the
some
work
we've
been
doing
for
some
time-
there's
try
to
address
this.
D
We
understand
that
not
only
the
device
is
under
attack
like
so
are
the
network's
the
devices
to
attach
to,
and
that's
really
the
focus
that
we've
come
from.
You
know:
how
can
we
better
increase
in
security?
The
network
from
these
things
that
are
just
it's
hopeless,
just
assume
that
they're
secure
her
ever
will
be
secure.
Sup
next
slide,
please.
D
So
what
our
goal
is
to
be
able
to
protect
the
network
from
the
things
and
put
up
the
things
from
the
network.
I'm
sorry
to
keep
looking
up
here,
but
I
can't
see
otherwise,
and
so
the
from
a
network
security
perspective
think
we
don't
understand
that
the
best
place
to
protect
against
something
connected
to
your
network
is
that
the
network
edge,
where
the
support
that
this
is
connected
to
and
that's
what
we'd
like
to
do.
D
We
also
understand
that
most
of
these
things
are
gonna,
be
authenticating
themselves
with
82
that
when
X,
so,
though,
there's
some
provision
for
that,
but
practically
speaking,
many
of
them
won't.
We
also
understand
that
there'll
be
a
lot
of
different
types
of
IOT
things
showing
up,
and
we
it's
really
going
to
be
impractical
to
assume
that,
on
your
triple
a
server
that
you're
going
to
know
about
them
ahead
of
time,
you're
going
to
sign
some
sort
of
policy
to
them.
D
D
So,
in
fact,
most
of
the
time
they
have
very
simple
needs,
which
is
they
need
to
talk
to
an
dhcp
server,
get
my
address
and
then
they've
got
some
manager
somewhere
in
the
enterprise
or
in
the
cloud
that
they
have
to
actually
talk
to
to,
for
example,
maybe
they're
relaying
sensor
data
up
to
it
or
maybe
they're
getting
data
back
down
from
it.
But
what
you
really
like
is
to
just
have
these
things
be
allowed
on
your
network
to
do
just
that.
D
Just
get
dates
to
be,
for
example,
and
just
talk
to
its
supposed
to
talk
to.
But
how
in
are
we
going
to
know
that
and
given
the
previous
statements
I
made?
So
the
goal
is,
with
this
thing
called
manufacturer
usage
descriptions
where
a
manufacturer
can
describe
usage
of
what
this
device
needs
and
go
to
the
next
slide
please.
D
So
the
main
draft
is
this
off
Terry
working
group
craft
and
very
simply
what
the
way
that
mud
is
intended
to
work
and
is
it
their
manufacture
when
you
produce
a
device,
he
does
a
couple
of
things.
He
crazy,
basically
a
file
on
a
web
page
in
the
particular
format
that
describes.
If
you
will,
what
we're
really
interested
in.
D
What
he's
going
to
describe
is
some
information
about
network
access
policy,
that's
necessary
and
then
plenty
of
the
device
woody
manufactures
the
devices
it
includes
a
URI
and
one
of
the
discovery
protocols
that
this
thing
is
going
to
send
out,
which
is
basically
a
hint
telling
that
where
Kate,
if
you
want
to
know
more
about
me,
go
resolve
this
uri
and
it'll.
Tell
you
some
interesting
things.
D
So
this
draft
defines
the
format
for
the
file
defines
different.
What
is
that
the
URI
can
be
propagated
by
the
device
which
could
be
a
third
DHCP
option
or
LDP
tlv,
and
then
additionally
could
also
come
in
x509certificate
there's
a
certificate
extension
that's
been
defined,
but
for
the
purposes
of
this
discussion,
that's
not
as
interesting
as
the
other
two.
D
So
once
those
that
you
aright
to
the
network,
then
the
network
can
forward
that
to
the
radius
server
and
he
can
work
with
an
associated
device
called
the
mud
controller,
which
simply
is
going
to
resolve
the
or
I
and
discover.
What's
in
it
created
ackles
and
then
send
it
down
to
the
access
port
on
the
network
on
the
network
edge,
so
what
we've
discovered
in
when
we
were
going
through
implementing
this
is
well
if
this
is
coming
from
dhcp
or
LDP.
D
Access
port
can
pick
this
thing
up,
but
he
really
doesn't
have
a
way
to
get
this
to
the
radio
server.
So
we
need
a
new
attribute
in
radius
to
send
that
off
to
the
radius
server,
and
that's
really
all
this
draft
is
doing
after
all
that
explanation,
but
it's
a
missing
piece
of
the
puzzle
next
slide
please.
So
this
is
the
is
just
a
Pretoria
Lee.
When
I
was
just
mentioning,
you
can
see
at
the
top
that
the
thing
is
advertising
then
my
dr.
D
I
then
that
network
edge
needs
to
forward
that
over
radius
to
the
triple-a
server,
which
is
working
with
this
mud
controller,
sort
of
role
to
resolve
this
mud
file,
My
dear
I,
to
get
the
file
back
great
the
apples
and
send
them
back
down,
and
the
only
thing
missing
is
what's
in
red.
So
that's
what
this
draft
does
next
line.
Please,
in
fact
that's
most
of
the
draft
I
guess
is
describing
a.
D
Attribute
this
necessary
Ellen
had
commented
against
the
dash
0
0
that
we
should
be
using
the
data
types
draft,
so
we'll
be
doing
that
the
next
version,
instead
of
putting
the
ASCII
art
in,
but
we
still
would
need
the
same
thing
in
the
end.
Okay
next
slide,
there's
a
little
bit
of
context
in
the
draft
around
what
I
just
described
verbally
and
then
there's
some
security
considerations
in
there
about
well.
D
So
she
you
really
except
this
year-
I
that's
coming
across,
maybe
unsecured
or,
if
and
another,
and
then
the
next
steps
that
might
be
Talon
pointed
out
in
his
comments
that
maybe
the
radio
service
should
be
a
little
worried
about
what
he's
getting
you
or
you
arrive
in
the
from
this
radius
attribute
that
maybe
didn't
come
in
an
ascent,
ocado
fashion.
So
the
answer
to
these
things
is
generally.
D
Yes,
if
the
URI
comes
unprotected,
you
really
shouldn't
completely
protect
it,
but
there
is
some
so
there's
two
answers
to
two
sort
of
points
here.
At
one
point
is
it's
definitely
helping
devices
that
are
not
lying
in
that
they
are
protecting
themselves
and
there's
value
in
that,
and
then
the
question
is:
how
do
we
protect
against
devices
that
are
lying
and
really?
D
The
answer
is
you
need
some
correlating
information,
some
device
profiling
or
some
other
kind
of
events
that
you're
actually
looking
at
the
traffic
from
this
thing
and
deciding,
if
he's
really
acting
as
that
kind
of
device
or
not,
this
I
think
it's
a
little
bit
of
a
fuzzy
answer,
but
that's
that's
pretty
much
where
we
are.
The
best
possible
approach
really
would
be
Ford
assembly
you
or
I
in
the
certificate,
in
which
case
we
don't
need
this
radius
option,
but
in
that
case
it's
going
already
to
the
triple
a
server.
D
It's
actually
as
part
of
a
fennec
ation
certificate,
authentication
validation
he's
going
to
actually
discover
the
URI,
and
then
you
can
get
the
resolved
and
get
the
policy
from
there.
But
as
I
said,
we
understand
most
devices
aren't
going
to
act
like
that
place
to
start
with
I
think
it
might
be.
My
last
slide
yeah.
So
this
is
just
a
request
for
comments.
We're
not
ready
to
ask
that
for
anything
beyond
that.
C
E
C
D
A
your
eye
that
is
non-existent,
it's
certainly
possible,
that
is
to
say,
maybe
the
manufacturer
goes
out
of
business
right.
So
if
it's
not
there,
you're
no
worse
than
you
were
before
you
didn't
have
a
URI.
I
would
say
that
second
of
all,
there's
certainly
strategies
were
you.
I
can
be
put
on
a
third-party
server.
Something
like
that.
Actually
Impractical
circumstances.
I
would
expect
the
mud
controller
sort
of
operation
probably
to
cash
it
after
he
gets
it
the
first
time,
so
he
always
has
it
available.
D
D
Really
you
just
need
to,
as
I've
said
before,
I'm,
not
sure
I've
a
better
answer,
then
you
need
to
do
some
additional
device,
profiling
and
evaluation
of
the
traffic
of
this
thing,
using
maybe
some
IDs
or
something
the
additionally,
of
course,
there's
you
can
put
things
on,
so
you
can
put
RT
devices
in
particular
vlans
and
there's
other
sorts
of
separation
techniques
that
could
also
might
you
must
also
do
along
with
akal
right.
There's,
there's
no
restriction
here
on
what
you
would
normally
do
with
your
policy.
D
It's
just
we're
trying
to
give
the
network
a
hint
of
hey.
This
is
this.
This
is
the
kind
of
device
it
is,
and
here's
a
hint
about
what
kind
of
access
it
needs
and
then
they
certainly
the
radius
server
can
apply
any
kind
of
policy
of
months,
as
he
would
normally
we're
just
trying
to
automate
the
ability
for
him
to
know
what
this
is
and
what,
when
it
needs
to
do,
I
don't
know
Alan.
If
that
answered
your
question
and
on.
C
Yeah
so
personally,
to
the
pitching
so
Alexandra
probe
on
this
I
agree
and
to
maybe,
of
course
this
is
not
the
problem
of
this
draft,
but
mostly
of
the
mud
draft.
That's
that's
going
to
be
there.
It
is
because
IOT
devices
will
tend
to
to
live
much
longer
now
without
potentially
without
for
more
updates.
Then
what
we
are
seeing
today
so
this
could
be.
You
know
it
could
be
interesting
to
see
how
the
mad
draft
advances
in
in
the
other
working
group.
C
A
You
just
are
just
a
sec
idea.
I
also
have
couple
of
questions
all
as
an
individual.
Do
you
underst
as
an
ideal
video
I'm,
very
sympathetic
to
the
through
the
much
work
I'm
just
trying
to
wrap
my
head
around
here?
So
what
you
have
on
the
network
edge
here
is
what
we
would
usually
call
the
mass
and
device
they
just
try
to
authenticate
with
the
IOT
thing,
but
you
know
it's
this
draft.
Basically,
the
nass
also
is
the
authenticated
device
by
proxy.
Well.
D
Actually,
we
didn't
mean
to
say
that,
so
if
the
then,
as
should
be
just
forwarding
me
in
it,
in
a
standard
environment
with
the
radius
server,
you
should
be
just
forwarding
you,
the
URI
off
to
the
radius
server
to
decide.
Essentially
it's
an
informative
thing
right.
The
radius
server
can
decide,
I
could
ignore
it
or
he
could
decide
to
use
it
as
I
was
describing
earlier.
So
we
and
the
certainly
you
know
the
bottom
line
they're
showing
from
the
trip
flies
over
to
the
network
edge
after
the
nez.
D
There's,
absolutely
no
change
there
whatsoever
effect
in
our
implementation.
You
knows
all
existing
attributes,
you
know,
Brady's
attributes
is
just
cost
because
you're
trying
to
do
the
same
thing,
you
would
do
for
any
other
device.
At
that
point,
you
just
we're
trying
to
enable
the
ability
to
to
decide
what
those
after
it
should
be.
Yeah.
A
That's
exactly
my
point,
so
every
other
device
can
trigger
the
authentication
itself
because
it
was
gonna
fight.
So
then
the
man's
here
has
to
decide.
This
is
an
IOT
device
connecting
to
me
and
do
I
have
to
take
this
authentication
by
proxy
roll
forward
and
then
my
question
is:
there
is
only
this
DHCP
option
and
if
this
is
there,
the
nest
will
act
on
it
and
then
do
stuff
and
consider
the
device
being
an
IOT
device.
But
if
that's
correct,
maybe
there's
some
interesting
attack
coming
up
itself.
D
A
F
G
Right,
so,
if
you
put
up
the
slides,
this
is
work
which
came
out
of
the
security
area
where
there
was
some
discussion
of
the
dhcpv6
and
various
dhcp
security
options,
and
I
pointed
out
that
dhcp
v4
was
entirely
insecure
and
that
perhaps
we
might
want
to
leverage
in
0,
2
and
X.
So
if
you
go
to
the
next
slide,
yeah
there's
no
ties
between
80
2
and
X
and
dhcp.
So
you
have
this
wonderful
super
secure,
TLS,
enabled
method
to
get
on
the
network.
You
prove
who
you
are.
G
You
prove
that
you
know
who
the
network
is
and
soon
as
you're
on
the
network.
You
send
this
DGP
packet
and
hopefully
someone
somewhere,
who
might
be
the
current
bgp
server
answers
on
the
point
from
ted,
lemon
and
various
other
DGP
people
was
that
the
switch
mostly
blocks
all
the
bad
DGP
traffic,
so
you're
pretty
sure
that
you're
talking
to
the
realty
H&P
server,
but
it
never
hurts
to
have
cryptographic
signing
in
my
opinion.
So
if
you
go
to
the
next
slide,
so
the
idea
is
basically
take
a
page
from
EEP.
G
You
have
a
2
and
X
msk,
various
derivation
methods
for
it.
So
like
TTLs
there's,
you
know
this
string,
ttls
signing
key
or
something-
and
you
just
do
something
similar
14
GP.
But
this
thing
is
that
both
ends
can
do
I
the
same
key
without
communicating
with
each
other
or
without
exchanging
things.
And
then
you
just
start
signing
packets
and
you
gain
some
additional
level
of
security
by
how
actual
security
at
GP.
So
next
slide.
G
That
sorry,
still
there
I
think
we
do
that
next
slide.
How
does
it
work?
You
sign
the
keys,
yes,
exchanging
the
keys,
so
this
is
the
beta
2
and
X
Server.
More
typically,
the
radius
server
leads
to
exchange
the
keys
with
the
dhcp
server,
and
this
is
where
the
phrase
you
know
insert
magic.
He
replies.
G
There's
no
api,
all
between
radius
and
dhcp.
There's
no
shared
database.
There
there's
nothing.
These
keys
tend
to
be
fairly
secure.
You
probably
don't
want
to
put
them
in
a
database
because
he
used
us
on
package
them.
Other
people
can
get
at
your
database
so
that
sort
of
implementation
to
find
and
open
to
discussion
next
slide.
G
So
what
does
it
mean
when
you
sign
the
DHCP
packets?
It
means
that
the
servers
can
talk
to
each
other,
but
they're
run
by
people
who
talk
to
each
other
anything
else-
and
this
is
one
of
the
questions
that
Ted
London
brought
up
you
know:
does
it
mean
that
it's
a
trusted
dhcp
server?
Well,
no,
because
you
know
this
is
a
new
thing,
we're
adding
with
new
new
meaning.
All
you
can
say
if
the
minimum
is
that
the
two
servers
have
talked
to
each
other
and
exchange
data
next
slide,
so
problems
yeah.
G
There's
a
lot
of
details
not
worked
out.
It's
sort
of
a
stab
in
the
dark
at
this
point.
Dgp
doesn't
provide
for
capability
negotiation,
so
there's
no
way
for
either
in
to
say
that
they
could
do
this
other
than
they
just
start
signing
back.
It's
better
to
an
ex
doesn't
provide
for
this
kind
of
capability
negotiation.
So
there's
no
real
way
in
any
of
the
existing.
G
In
conversations
to
say,
hey
I
can
do
this
dhcp
thing
you
might
shoehorn
it
into
the
inner
tunnel
in
TTLs,
because
that
allows
you
to
exchange
any
radius
attributes
essentially
bought.
It's
not
generic
and
it's
not
really
good
for
any
other
three
batteries.
So
there's
really
lil
wayne
for
either
end
to
signal
that
this
is
happening
so
next
slide.
G
Can
it
be
implemented
and
will
people
implement
it?
I
know
for
me,
taking
a
look
at
it.
I
can
cheat
a
little
bit
here,
because
I
can
radiate
radiant,
/
dhcp
server
that
caches
the
keys
in
memory.
It's
you
know,
maybe
a
thousand
lines
of
code
and
a
couple
of
flags
and
a
configuration
file
somewhere.
Other
people
who
have
other
implementations
will
find
this
rather
substantially
more
difficult.
G
C
G
Simplest
thing,
I
think
from
implementation
point
of
view
is
for
the
radius
server
to
tell
the
dhcp
server
that
it
has
keys
available
and
either
can
push
the
keys
via
some
pre-configured
secure
channel,
but
otherwise
the
dhcp
server
has
to
ask
the
radius
server.
Every
time
now
the
dhcp
signing
in
RFC
3118
allows
for
a
secret
identity.
So
it
doesn't
just
sign
the
package.
It
says
which
secret
and
signed
with.
So
that's
one
of
the
questions
you
could
reserve
a
number.
G
C
A
A
G
Those
are
separate
keys.
So
if
you
look
at
the
draft
as
references
to
TLS
to
the
TTLs
think
so
those
MPGe
Kings
are
derived
by
taking
server
random
from
TLS
and
the
client,
random
and
the
fixed
string,
and
then
don't
appear
a
factual
with
that.
That's
fine
for
every
eat
method,
and
so
did
you
do
something
similar
and
say.
Well,
you
have
these
nests
katie's.
You
go
one
willing
to
drive
the
msf,
kinky
keys
and
you
go
another
me
to
derive
tht
37
keys.
D
Brian
wise
cisco,
say
Alan
I
think
this
is
interesting.
I
do
some
work
and
the
I
Triple
E
a
tattoo
that
one
group
on
a
2,
0
and
X
so
I've
had
some
kind
of
questions
about
how
we
would
actually
extract
the
king
material
and
actually
I'm
not
sure.
If
anybody
does
that
today,
I'm
just
wondering
at
me,
it's
an
interesting
idea
if
it
could
even
be
a
more
with
a
general
concept.
4802,
not
mine,
x,
ability
to
extract
king
material
for
different
purposes
such
as
TLS.
D
G
This
requires
any
changes
to
get
into
an
ex
it's
just
once
you
have
that
msk
derived
from
the
deep
session.
You
derive
an
additional
key,
a
subkey
from
that,
so
I
don't
think
it
requires
any
changes.
Other
than
implementation
changes
on
the
radius
server,
the
TTP,
the
supplicant,
the
dhcp
client,
add
the
dhcp
server
and
all
these
systems
now
have
to
talk
to
each
other
in
exchange
information.
G
I
think
so,
so
my
initial
look
through
the
various
eat
methods
bug
show
that
this
seemed
to
be
possible.
The
hope
is,
you
don't
have
to
come
up
with
derivation,
which
is
specific
to
each
eat
method,
but
that
might
be
required
on,
in
which
case
you
have
to
issue
sort
of
a
jumbo
draft
that
would
patch
all
of
the
existing
eat
methods
which
I'd
prefer
not
to
do
sure.
C
Yes,
I
know
on
jabber
by
Jim,
sorry,
okay,
yeah,
so
I'll
not
read
it,
but
I
would
say
that
it's
interesting
or
I
I
wouldn't
be
bitching
that
it
would
be
worth
thinking
about
a
more
generalized
idea
of
having
this,
especially
for
IOT
devices.
Where
you
can.
You
would
like
to
limit
the
number
of
key
exchanges
over
the
year,
so
you
could
you
could
use
the
radius
server
to
actually
push
lots
of
keys
too
many
different
servers.
C
So
in
this
case
here
we
have
the
DHCP
and
the
in
the
access
point,
for
example,
but
it
can
be
some
other
servers
and
if
there
is
like
a
generic
wave
which
this
could
be
achieved
like
pushing
the
keys
two
different
entities
that
are
not
co-located,
then
that
will
be.
That
would
be
a
nice
thing
to
have.
G
Yeah,
so
that
that
that's
interesting
and
in
terms
of
value,
read
James
comment
on
Jan
or
two.
My
only
concern
with
driving
a
DGP
signing
key
from
the
nsk
that
gets
sent
to
the
AP
is
the
MSM.
Ppv
genes
are
visible
to
everyone
in
the
radius
infrastructure,
but
that's
sort
of
bad
for
key
security.
On
the
other
end,
it
does
mean
that
these
thtt
signing
keys
are
now
independent
of
the
eat
method,
and
you
don't
have
to
patch
on
the
existing
methods.
A
Ok,
so
this
is
Stefan
again
as
a
personal
comments.
I
was
going
to
be
in
those
security.
Our
discussions
and
the
thing
for
me,
is
in
the
Roman
Colosseum
like
we
have
an
addy
Rome.
It
may
very
well
be
that
the
triple
a
server
the
past
he
is
on
the
other
side
of
the
planet
compared
to
the
competitive
dhcp
server
which
hands
out
the
IP
address.
So
in
any
kinds
of
a
roaming
scenario.
I
think
this
has
no
chance
of
flying
high.
A
A
H
Hi,
oh
hello,
everyone,
I'm,
Arun
I'm,
going
to
present
the
updates
and
the
current
status
on
the
law,
ro
and
radius
draft.
So
since
we
have
a
couple
of
buffer
time,
I
would
take
the
opportunity
to
have
a
quick
refresher
of
what
is
this
draft
about
so
next
slide.
So
this
is
more
about
the
authenticating,
the
device
which
is
really
constrained
in
resources.
H
So
we
have
a
lp1
architecture
here,
which
is
which
consists
of
n
device,
which
is
really
constrained,
and
the
manufacturer
and
the
network
server.
So
in
the
manufacturer
he
provides
certain
amount
of
identifiers
and
the
root
key
to
the
N
device
and
also
to
the
network
server.
He
provision
the
same
kind
of
keys
and
ID's.
H
H
So
these
are
the
two
main
messages
which
are
exchanged
between
the
end
device
and
the
network
server.
So
the
join
request
has
the
identifier
plus
the
random
numbers,
which
is
generated
by
the
end
device,
whereas
the
joint
response
or
join
accept
has
the
application
random
number,
which
is
generated
from
the
network
server.
H
So
what
we
going
to
do
is
to
delegate
the
functionality
of
authentication
from
the
network
server
to
the
grade
a
server,
so
we
are
going
to
have
the
same
kind
of
messages
across
the
radio.
What
we
are
going
to
do
is
to
introduce
new
radius
attributes,
suggest
John
request
and
join
accept
which
are
transferred
using
the
radius
protocol
to
the
radius
server.
H
There
are
a
few
modifications
in
the
introduction
part
in
the
section
1
which
inches
or
which
emphasizes
the
importance
of
the
triple
a
server
in
this
scenario,
and
we
added
a
reference
to
RFC
6158
radius
design
guidelines
which
specifies
the
data
structures
outside
which
are
defined
outside
the
radius
and
in
the
lp
one.
They
had
the
first
working
group
session
in
co,
ITF
97,
though,
in
the
current
shatter,
they
don't
have
any
specific
specification
on
the
radius
infrastructure.
H
There
are
quite
a
bit
of
interest
from
other
private
or
other
individual
persons,
and
also
in
one
of
their
architectural
draft
they
have
mentioned,
or
they
have
included
triple-a
as
a
part
of
the
architecture.
So
what
we
are
so
what
our
plan
is
to
keep
updating
the
draft
with
the
inputs
from
LP
1
group,
plus
the
individual
individuals,
and
wait
for
the
next
charter
to
be
included,
and
also
since
we
use
the
radius
protocol
for
transport.
We
would
like
to
get
the
inputs
from
the
radix
group
as
well,
and.
F
E
H
H
On
the
client
and
the
server
side
on
what
kind
of
state
machine
handling
and
like
how
does
it
affect
my
implementation,
my
current
radius,
client
and
server
implementation?
If,
if
there
is
like,
if
for
some
reason,
the
the
triple-a
server
see
that
this
device
cannot
be
authenticated
or
something
is
wrong,
then
what
should
it
send
to
the
network
server
and
like
let's
open
for
discussion?
Actually
right?
Now
we
have
a
current
implementation
in
go,
so
we
don't.
H
Actually
we
have
a
failure
in
the
in
this
step
on
the
third
step,
and
so
we
failed
to
generate
the
network
session
key
and
other
session
Keys.
Maybe
we
can
include
a
radius,
reject
or
access
reject
in
this
and,
like
my
second
question,
is
more
fundamental:
why
do
we
need
new
attributes?
Why
can't
we
just
put
like
in
the
access
request,
access
except
payload,
like
maybe
I'm,
missing,
something
but
like
what's
so
special?
A
So
a
question
from
me,
then
radios
always
needs
attributes
to
send
data
from
A
to
B
as
part
of
the
payload.
So
if
you
think
there
is
an
attribute
which
can
convey
all
this
data
here,
please
let
us
know
but
I'm
not
not
aware
of
generac
generally
sending
a
bite
screen
in
any
way.
So
that's
me.
I
think
that
attributes
are
needed,
that's
fun!
For
me
as
an
individual.
A
In
any
case,
you
will
have
to
have
the
excess
reject
on
the
red
part
of
the
conversation
in
your
spec,
because
there's
nothing
radius
hates
more
than
not
getting
a
reply,
because
this
simply
means
maybe
the
radio
service
actually
dead,
and
I
have
to
ask
a
different
server
and
have
to
fight
over
and
the
ambiguity
of
non-response
is
either
a
reject.
The.
A
A
A
A
C
So
I
would
like
to
ask
like
a
general
Alexander
Pope,
a
general
question
to
to
the
group
into
the
room
is:
if
there
is
an
interest
at
some
point
to
and
to
what
would
be
the
the
chances
of
getting
this
document
as
part
of
the
working
group
item.
So,
of
course,
we'll
be
publishing
this
as
individual
submission
for
as
long
as
there
is
interest,
but
it's
how?
How
is
there
any
interest
here
and
yeah?
A
If
you
ask
me
up
front
about
how
your
chances
are
there,
it's
a
bit
difficult
but
yeah.
This
is
something
that
is
doing
radios
for
authentication
things
and
that's
what
we
decide
radios
for.
So
it's
certainly
not
out
of
the
line
and
I
think
it
has
chances
yeah.
But
in
the
end,
if
you
want
to
have
it
as
a
working
group
item,
you
have
to
a
call
for
adoption
and
enough
people
have
to
say
yeah.
That's
a
good
thing
to
do
and
whether
that
happens
or
not
is
really
a
question
of
the
future.
A
G
So
go
to
the
next
slide
this.
This
comes
out
of
some
discussions
with
gin
chatted
about
practicing
in
UDP
versus
tcp
discussions
we
have
in
in
Berlin,
so
UDP
is
required
to
retransmit,
so
proxies
clients
are
required
to
be
transmitted
as
per
RFC
1580
section
2.2,
because
tcp
is
reliable,
tcp
client
don't
be
transmitted
and
what
happens
with
proxies
then.
So
if
we
go
to
the
next
slide,
there
should
be
a
very
simple
diagram.
So
let's
say
there's
an
ass
which
sends
data
to
proxy
via
UDP.
G
G
G
Also
is
the
UDP
retransmission
behavior
optimal
and
what
I
mean
by
that
is
Bernard
at
least
was
very
clear
or
that
for
you,
TP
chains
of
proxies
each
UDP
proxy
must
not
retransmit
unless
told
to
do
so
by
re
transmission
from
the
mass,
because
this
has
to
end
behavior
that
might
work
for
routers.
It's
not
clear
that
it's
the
right
thing
to
do
for
radius,
especially
once
you
have
failover
and
all
these
kinds
of
stuffing,
especially
in
a
complex
environment.
Like
add
your
own.
G
So
all
these
proxy
issues
are
not
adequate
covered
by
the
existing
RFC's.
So
if
we
go
to
the
next
slide,
so
what
we
know
is
the
radio
servers
are
relatively
smart
and
can
be
upgraded
easily.
The
naz's
are
dumb
and
they're
hard
to
upgrade
for
very
good
reasons.
Mine
loathes
upgrade
my
switches
be
clean,
there's
no
radius
routing
protocol.
So
ideally
you
don't
need
to
discover
that
the
upstream
servers
down
by
doing
retransmits
you
get
told
by
your
routing
protocol,
except
we
don't
have
them.
G
So
I
think
we
would
be
useful
to
have
a
best
current
practices,
just
document
covering
proxy
considerations,
but
we
also
need
consensus
on
what
it
recommends.
I
think
some
things
are
relatively
straightforward,
like
in
the
design,
the
diagram
earlier,
you
know
if
a
proxy
is
receiving
packets
over
TCP
and
forwarding
them
over
UDP,
then
the
proxy
is
responsible
for
retransmits
on
the
UDP
each
side.
G
But
another
documents
say
that
and
then
the
harder
issues
are
UDP
proxy
chains.
What
do
they
do?
I
think
most
current
implementations
to
we
transmit
whatever
the
upstream
retransmits,
but
there's
not
a
lot
of
consensus
as
to
why
this
is
a
good
thing.
I
think
especially
when
you
get
into
things
like
add
URL,
correct
me
if
I'm
wrong,
Stefan,
but
most
of
engine
room
is
all
TLS
anyways.
G
A
So
before
we
start
with
the
discussion,
maybe
I
have
to
correct
human
cost.
You
are
wrong
turns
out
that
we
have
TLS
in
many
countries,
but
that's
like
15
to
20
and
a
Jerome
is
now
in
70
countries
worldwide.
So,
unfortunately,
the
typical
admin,
even
the
country
level,
finds
it
easier
to
provision
a
UDP
shared
secret
once
and
have
a
tea
room
for
the
next
20
years
running,
rather
than
updating
a
certificate
every
year
or
so.
So
we
are
not
quite
at
the
point
where
we
say
everything
is
TLS.
G
This
is
this
perhaps
basin
you
to
define
what
the
UDP
retransmission
that
reviewers
are
and
why.
Those
are
good
ideas,
because,
right
now,
my
recollection
is
that
I
think
going
back
to
2865
might
be
that
old
or
maybe
maybe
a
bit
later.
I
was
having
discussions
with
Bernard
about
this
trying
to
figure
out
which
things
you
know
with
which
retransmission
behavior
was
best
at
Bernard
who's.
B
A
Yeah
I
can
only
echo
that
bedroom
we've
been
doing
this
for
more
than
a
decade
now,
but
it's
pretty
much
like
yeah.
It
works
sawed
off
and
that's
it,
but
nobody
really
has
has
any
good
answers
so
far.
If
we
can
find
them.
That's
great
question
is:
do
we
find
an
answer
that
actually
fixes
all
kinds
of
proxy
problems
or
or
is
the
best
thing
we
can
do,
is
document
them,
but
it
has
to
be
that
somebody
has
to
think
about.
It
then
has
to
put
it
in
writing.
Yet.
A
A
A
A
You
should
always
have
exactly
one
choice:
how
to
authenticate
to
1
given
network
that
I
agree
with
that
would
be
nice.
It's
been
the
world
so
far
that,
especially
if
you
take
a
look
at
the
Wi-Fi
Alliance
past
point
past
point
things:
there
is
a
sequence
of
events
that
where
this
gone
wrong
is
certainly
possible.
So
it
might
be
that
you
do
end
up
in
this
situation,
the
reason
being
that
any
network
is
not
necessarily
one
network.
A
So
you
can't
have
an
access
point
with
one
SSID
advertising
that
you
can
connect
to
it
with
a
multitude
of
identities
and
if
you're
particularly
unlucky,
that
you
have
identities
with
more
than
one
provider
which
are
all
compatible
with
this
access
point,
you
do
have
that
choice.
So
I
will
rephrase
the
document
to
point
in
the
direction
that
you
only
have
to
read
this.