►
From YouTube: IETF-MADINAS-20221007-1400
Description
MADINAS meeting session at IETF
2022/10/07 1400
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
B
A
So
please,
if
you
are
not
speaking,
make
sure
that
your
audio
and
video
are
off.
We
ask
you
to
join
the
the
queue
if
you,
if
you
have
any
questions
and
then
we'll
pass
the
the
word
the
agenda.
This
is
where
you
can
find
it,
and
you
have
need
for
technical
assistance
you
can
get
to
to
the
page
below.
A
So
again.
As
a
reminder,
the
minutes
are
taken.
We
are
recording
this.
Your
persons
Will
Be
Loved,
according
to
the
to
your
logging
into
the
data
tracker
and
well
thanks
to
Matia
and
anyone
else
that
wants
to
join.
Also
with
the
with
the
notes
you
can
do
that
by
clicking.
On
top
of
the
screen
to
the
note
taking
tool
or
the
link
that
you
see
on
the
on
the
screen
for
today's
agenda,
we
would
like
to
give
you
a
quick
update
about
the
working
group.
A
A
Then
we'll
give
you
an
update
about
the
up
and
running
experiment
that
we've
been
discussing
with
the
WBA
and
and
then
we
will
go
to
the
next
steps.
Preparations
for
the
for
the
London
meeting,
then
Matthew
will
be
presenting
us
the
work.
The
latest
work
on
rotating
Mac
address
for
privacy
protection.
A
E
B
All
right,
beautiful
yeah,
so
thank
you.
Mr,
chair,
hi
everyone.
So
we
updated
these
documents
and
you
probably
saw
those
who
were
night
owls
that
it
happened
yesterday
night,
so
a
little
bit
late.
Since
last
July,
we
received
quite
a
few
comments
around
these
these
documents,
mostly
where
around
typos
and
you
know,
I
I,
saw
this
morning.
There
was
another
comment
that
says
you
still
have
typos
so
I'm
sure
we
still
have
typos.
B
So
as
you
as
you
keep
reading
this
document,
as
you
find
these
typos,
please
you
know
single
them.
You
know,
please
tell
us
that
we
have
typos,
but
also
tell
us
where
you
see
them,
so
we
can
correct
them.
So
you
know
there
were
a
bunch
of
of
Corrections
in
this
in
these
documents,
but
one
way
to
attract
your
attention
to
is
in
fact,
two
elements.
One
of
them
is
one
common.
So
remember
the
structure
of
these
document
right.
B
We
know
the
access
founder
switches,
all
these
services
that
may
use
the
MAC
address
at
layer
3,
you
know,
upper
Services
there'll
also
be
non-machine
devices,
that
is
to
say
not
Network
functionalities,
but
humans,
because
the
humans
are
going
to
be
operating
or
acting
in
the
network
at
some
point
of
it.
So
they
may
have
an
interaction
with
the
Mac
addresses
and
also
Define
a
little
bit
the
environment
into
where
Mac
addresses
are
used
and
what
kind
of
trust
degree
you
can
have
in
those
various
environments.
B
B
Then
we
have
a
quick,
as
you
may
remember,
a
view
of
why
these
various
entities
may
want
to
interact
with
the
MAC
address
and
what
they
do
with
it.
And
then
the
main
change
I
wanted
to
to
bring
to
your
attention.
Is
this
one
where
you
know
one
common
comment?
We
got
around
this
table
where
we
summarize,
you
know
these
various.
B
What
we're
calling
places,
Hall
management,
residential
campuses,
Etc,
the
trust
degree
Etc.
We
had
a
quite
a
few
people
coming
and
telling
us
well
what
you're
defined
here
are
not
really
places.
There
are
environments.
In
fact,
those
are
use
cases.
You
know
there
is
a
home
use
case,
a
managed
potential
use
case
Etc.
So
one
thing
we
did
was
to
you
know,
change
this
nomenclature
to
environments,
and
we
did
the
same
in
the
title
above.
B
Another
common
comment
we
got
was
when
you're,
although
the
trust
degree
is
explained
above
the
Network
Services
here
that
you're
defining
the
level
of
service
that
to
expect
from
the
network,
is
something
that
is
not
defined
anywhere.
So
when
you
say
that
you
expect
a
medium
type
of
level
for
medium
Services.
What
does
that
mean?
So
what
we
did
as
well
was
to
add
at
the
beginning
of
section
6
here,
a
section
that
we
call
Network
Services,
where
we
know
we
simply.
B
You
know
remind
the
reader
that
you
know,
as
you
are
stationed,
connecting
to
a
network,
you
may
be
expecting
from
that
Network
a
certain
amount
of
services
at
the
most
basic
level.
The
service
you
expect
is
an
IP
address
and
the
Gateway
getting
you
onto
the
internet,
nothing
else
so
that
that
would
be.
You
know
the
basic
level
of
service
you
would
be
expecting.
B
Then,
of
course,
if
you're
getting
a
more
involved
environments,
you
may
have
two
branches
in
one
is,
for
example,
in
your
home,
where
you
may
have
more
of
those
and
more
services,
because
you
I
don't
know
you
have
a
file
server.
For
example,
you
have
iot
objects
that
we
need
to
have.
You
know
some
specific
interaction
with
some
some
web
service
that
would
be
running
on
VM,
or
something
like
that.
So
you
may
have
more
advanced
services,
so
you
get
in
complexity
here
higher
from
basic
to
you
know,
someplace
medium.
B
The
same
goes
into
an
Enterprise
where
you'll
probably
also
have
you
know
some
printers
web
servers
Etc
and
then,
if
you
grow
in,
if
you
increase
even
more
especially
in
Enterprise
environments,
you
would
have
differentiated
service
that
would
then
be
applied
to
different
types
of
traffic.
For
example,
you
would
have
your
iot
traffic
that
would
be
directed
into
one
branch.
Then
you
would
have
you
know
your
voice
traffic.
That
would
be,
for
example,
in
another
VLAN,
your
voice
traffic.
You
may
want
to
recognize
it
so
that
you
can
prioritize
it.
B
So
all
these
differentiated
levels
of
services
brings
the
relationship
in
complexity
even
higher,
because
of
course,
if
you
want
to
recognize
voice
traffic,
you
want
to
recognize.
You
know
that
voice
traffic.
You
need
to
characterize
it
and
also
recognize
that
the
device
that
is
sending
that
voice
traffic
is
supposed
to
be
sending
that
voice
traffic,
because
it's
a
smartphone,
for
example.
Not
you
know
fire
alarm,
that's
sitting
on
the
top
of
your
ceiling.
B
That's
one
thing:
another
thing
I
have
heard:
a
lot
is
about
the
title
of
this
documents,
so
those
of
you
who
have
been
on
this
call
for
the
thing
the
beginning.
You
may
know
that
this
is
something
that
keeps
coming
back
before
this
document
was
called
framework
documents
and
quite
a
few
people
came
in
commenting
that
this
is
not
really
defining
a
framework.
It's
defining
use
cases
and
where
those
use
cases
are
Define,
you
know
what
kind
of
a
existing
Protocols
are
out
there
that
could
allow.
B
You
know
privacy
to
be
maintained
in
a
world
where
RCM
would
be
active
and
because
of
that
second
part
we
also
had
since
July
some
comments
coming
in
and
say
well
now,
the
document
is
called
use
cases,
but
you
do
more
than
use
cases,
and
that's
very
true,
you
point
into
that
last
section:
That
We
examined
together
last
time
which
are
no
existing
Solutions.
You
know
that
allow
interact
action
with
the
opportunity
device
on
the
network
without
impeding
into
the
the
user
identity,
and
we,
of
course,
name
your.1x
and
we
named
open
roaming
last
time.
B
So
it's
true
that
this
document
is
in
essence
use
cases,
but
also
in
the
use
cases,
definition
for
RCM,
also
browsing
through
or
coming
through,
the
existing
solutions.
To
maintain,
you
know,
RCM
conditions
and
good
Network
conditions
with
the
RCM
environment,
so
it
might
be
that
we
would
need
to
have
more
discussions
around.
Do
we
want
to
rename
this
documents
and
the
last
comment
we
received
and
then
I'll
I'll
pause
for
four
questions
and
comments.
B
Is
this
last
section
on
the
requirement
formulation,
as
you
may
remember,
as
we
were
defining
these
use
cases
way
before
the
group
was
formed?
You
know
as
we're
still
discussing
the
creation
of
99s.
We
were
thinking
of
what
would
be
the
requirements
for
interaction
of
an
RCM
based
device
with
a
network
that
would
not
impede
with
the
you
know,
intent
of
RCM
in
the
first
place.
So
we
had
these
requirements
that
were
listed
here,
eight
of
them
that
were
you
know
some
of
them.
B
You
know
expectations
some
of
them
assumptions
about
the
network,
interaction
with
the
network,
but
also
some
of
them.
You
know
guidance
that
would
be
given
to
the
group
into
what
the
group
should
be
working
on.
So
now
that
the
group
is
formed,
we're
moving
more
in
Focus
direction.
We
got
a
few
comments
from
people
asking
if
that
section
is
still
relevant
or
if
we
should
not
entirely
drop
it.
B
A
B
F
D
D
So
I
think
that's!
That's
fine
and
I
wonder
if
we
want
to
explicitly
say
that
in
the
in
the
title
requirements,
I
will
be
fine.
If
we
don't
do
it
as
well,
because
it
may
be
implicit
that
do
you
recommend
the
use
cases
and
then
you
do
requirements.
But
then
what
I
think
may
be
good
to
do
is
that
this
document
documenting
the
the
existing
Solutions.
Maybe
that
should
go
into
analytics
or
something
like
that,
because
that's
not
really
like
the
main
goal
of
the
document.
D
That's
this
one
come
and
a
half
and
then
another
common
copies
on
the
requirements
I.
Even
if
at
least
to
me,
it
seems
that
we
have
like
two
type
of
requirements
like
one
type
of
requirements.
That
is
for
the
solutions
to
have,
and
then
there
is
another
type
of
requirement
that
is
like
requirements
for
us
as
a
community
to
do
which
their
requirements,
but
they
are
completely
different
type
of
requirements.
So
I
think
that
that
needs
to
be
also
clarifying
the
document
to
distinguish
between
okay.
D
A
A
So
maybe
we
can
clarify
in
discussing
the
group,
but
exactly
the
use
cases
I
think
it's
clear:
it's
the
identity
requirements,
probably
that
we
are
discussing
here
and
if,
if
this
document
is
answering
to
that
or
if
we
need
to
to
clarify
what
we
meant
by
identity
requirements,
then
we
have
the
best
practices,
which
is
probably
what
you
Carlos
mentioned,
that
should
map
into
analytics
or
is
getting
into
there
like.
What
exactly
are
they
the
existing
Solutions
and
the
ones
that
work
and
the
ones
that
don't
work?
A
E
I
think
you
basically
summarize
my
point,
and
that
was
what
I
was
pasting
this
part
of
the
charter.
So
this
is
what
the
working
group
must
deliver.
I
think
we
got
the
two
informational
documents.
I
mean
a
few.
Things
need
to
be
changed.
Obviously
they
are
not
really
for
publication
like
it
is,
but
it's
good
progress,
but
we
need
to
start
the
vcp
and
I
think
Jerome
news
document,
including
the
open
roaming,
the
dot,
One,
X
and
so
on.
E
E
I
I
would
go
step,
I
would
Skip
One
Step,
Jerome
I
would
simply
use
I
mean
I
would
need
to
read
the
document,
but
the
thing
when
you
propose
a
programming
and
what
we
can
there
and
there
you
directly
remove
it
from
the
current
document
and
create
an
individual
draft
right
draft
on
real
draft
blah
blah
madines
being
the
BCP
later
you
need
to
be
adopted
and
so
on.
When
you
start
to
get
the
the
process.
B
A
A
A
Necessarily
documented
in
this
in
this,
they
think
that
that
is
fair
but
doesn't
have
to
be
in
in
the
draft.
The
other
comments
that
we
can
direct
to
the
working
group
and
if
they
are
not
included
in
the
charter,
we
can
always
revise
a
charter,
but
probably
those
should
be
removed,
I
think
from
from
this
document,
and
we
should
focus
on
on
on
what
is
the
technical
part.
D
So,
thank
you,
everybody.
This
is
presented
on
behalf
of
my
co-authors,
an
update
on
on
the
marketers
randomization
draft,
just
a
short
kind
of
summary
or
quick
recap.
The
the
goals
is
to
basically
document
the
current
state
of
affairs
in
terms
of
my
current
randomization.
So
what
are
the
approaches
that
are
being
clicking
or
adopted
by
sdos
and
operating
systems?
So
what
is
going
on
on
the
different
sdos
regarding
macular
randomization
and
what
is
going
on
in
terms
of
what
are
the
usual
practices
from
the
the
devices
themselves
in
terms
of
Mac
address
randomization.
D
So
this
is
the
current
table
of
contents
from
what
we
discussed
in
the
past,
ITF
that
the
main
change
that
we
did
was
to
move
the
actual
content
from
the
OS
current
practices
section
number
seven
into
a
GitHub
kind
of
a
live
content,
so
it's
just
a
pointer
to
the
GitHub
so
where
we
have
the
actual
content
that
may
change
over
time.
So,
even
if
this
document
is
published,
we
could
be
updating
that
OS
current
practices
on
the
GitHub.
So
the
kind
of
the
document
doesn't
really
get
this
kind
of
obsolete
too
early.
D
That's
basically
just
a
snapshot
of
of
the
GitHub
with
the
the
content
as
it
is
right
now
and
then
let
me
go
into
the
comments
part
which
I
think
is
the
main
point
of
today's
presentation.
So
we
receive
a
bunch
of
comments
from
Michael
already
in
July
and
then
I.
We
are
trying
to
summarize
the
comments
here
in
the
in
the
slides.
First,
there
was
a
comment
about
the
BCP
14
terminology.
D
That's
true,
and
we
will
be
removing
the
terminatory
section
referring
to
BCP,
14
and
and
the
viewers
on
in
the
next
version,
because
the
rest
of
the
document
is
true
that
there
is
no
using
of
it's
not
making
use
of
this
keyword.
So
it
doesn't
really
make
sense
and
for
this
type
of
informational
document
we
don't
really
need
that
type
of
language.
D
Then
well,
the
commentary
referred
to
this
document
and
the
and
the
previous
one
I
I
do
think
that
in
the
previous
one
is
trippy,
but
I
I
guess
the
for
the
requirements.
We
may
need
to
have
this
this
keywords,
but
here
I'm
just
referring
for
this
current
document.
Okay,
then
there
was
a
comment
about
I've,
been
a
figure
with
the
AO
2.11
header,
and
so
in
there,
the
the
MAC
address
and
why
this
header
can
be
or
not
can
be
encrypted,
though
we
do
have
in
the
document.
D
Sun
diagram
for
the
actual
Mac
address
structure,
but
not
really
the
MAC
address
in
terms
of
the
header
I.
Think
I
would
like
to
get
the
opinion
for
the
working
group
from
my
individual
opinion.
I
believe
we
probably
don't
want
to
get
into
that
type
of
details,
and
we
already
have
a
details
enough
for
the
MAC
address
part,
but
this
is
a
working
loot
document.
D
So,
of
course,
if
people
think
otherwise
let
us
know,
and
then
we
will
be
happy
to
add
that
if,
if
people
think
that
should
be
there,
so
this
is
just
a
call
for
feedback
to
the
to
the
people.
Here
and
probably
we
will
send
an
email
to
the
mailing
list
kind
of
repeating
this
question.
So
we
get
some
feedback.
D
Then
there
is
another
point
that
I
think
is
relevant
to
discuss.
Michael
did
send
several
GitHub
pull
requests.
There
were
some
about.
You
know
some
minor
typos
or
even
not
typos
spaces
and
things
like
minor
things
and
and
procedural
things,
and
so
regarding
content,
there
was
only
one
if
I
remember
that
is
this
one.
He
basically
suggested
to
create
a
section
on
taxonomy.
He
decent
or
critics
and
text
related
device
and
kind
of
different
type
of
Mac
addresses
per
vendor.
D
Here,
the
question
is
for
the
working
group,
whether
you
think
is
useful
to
add
this
into
the
document
or
not.
I
will
tend
to
agree.
That
is
a
nice
thing
to
to
add
I'm,
not
sure
if
with
the
current
Continental
slightly
modified.
But
again
this
is
just
my
individual
opinion.
I
would
like
to
get
feedback
from
the
working
group,
and
if
so,
we
will
be
happy
to
to
basically
accept
this
into
the
the
document.
Jerome.
Please
go
ahead.
B
Thank
you
Carlos
first,
you
know
going
back
to
your
slide
number
number.
Five.
If
you
would
on
the
suggestion
to
have
this
UI
show
up,
I
I
think
it's
it's
a
little
bit
difficult
because,
as
as
you
know,
the
8011
header
is,
you
know
something
which
is
evolving.
For
example,
a
total,
even
bi
is
talking
about
encrypting
this
Mac
address,
so
you
know
I.
Think
writing
this
into
into
this
document
would
probably
Force
us
to
conduct
updates.
B
You
know
every
time
there
is
something
before
or
after
the
MAC
address
field
that
is
being
added,
so
I'm
thinking
it
may
be
a
little
bit.
You
know
adding
some
work
for
not
a
lot
of
value.
To
add
those
in
our
document
you
know.
Maybe
it
would
be
useful
to
point
to
the
IEEE
document
where
people
can
read
those,
but
you
know
repeating
the
content
of
the
I3
police.
B
Back
to
me
is
a
you
know,
always
a
risk
in
terms
of
updates
that
you
know
that's
just
my
thought
on
the
taxonomy
I
I
also
see
yeah
a
lot
of
value
in
what
is
being
proposed.
What
I'm
not
entirely
sure
about
is
how
this
would
be
used,
and
you
know
my
thinking
here
is
vendors,
that
Implement
randomized
Mac
addresses
typically
do
so
in
an
effort
to
protect.
B
You
know,
privacy
of
the
user.
The
way
the
MAC
address
is
generated
depends
very
much
on
the
environment
and
and
the
constraints
that
they're
they're
you
know.
They're
they're,
facing,
for
example,
per
device
generating
Mac
address
is
something
that
doesn't
change,
which
is
probably
you
know
very
well.
If
you
want
traceability
or
track
the
device,
for
example,
in
a
in
in
an
Enterprise
environment
per
boot,
that
means
you
have
to
reboot
your
device.
B
It
is
a
different
from
a
burr
device
because
I
don't
know
how
often
you
you
generate
your
your
Mac,
but
you
know
you
can
manually
also
regenerate
your
Mac,
even
if
it's
fertilized
generated
so
so
you
know
I'm
I'm,
trying
to
figure
out
how
we
would
use
that
that
taxonomy,
what
we
would
do
with
it
and
a
risk
I
I,
see
there
as
well,
is
that
we
might
create
a
sort
of
hierarchy
of
of
which
you
know
of
those
modes.
Is
you
know
more
conducive
to
privacy,
less
conducive
to
privacy
Etc?
B
So
you
know,
I
see
the
value
of
going
this
direction
of
naming
various
mode,
but
I'm
also
seeing
some
some
risk
associated
to
doing
so.
You
know
in
terms
of
comparison
on
one
side
and
also
the
complexity
of
keeping
track
to
you
know
what
the
environment
allows
and
what
each
version
of
the
operating
system
allows.
D
Can
you
hear
me
yes
and
no?
No,
you
didn't
get
any
any
additional
feedback
on
that
I.
My
understanding
on
my
personal
interpretation
would
be
that
we
want
to
kind
of
document
what
type
of
practices
a
device
may
follow,
which
is
a
bit
independent
on
what
a
device
may
do
in
terms
of
capability,
so
the
per
device
or
per
boot.
That
doesn't
mean
that
I
mean
by
per
device
I
would
understand
a
policy
or
an
approach
in
which
the
device
only
generates
a
random
address
once
in
their
own
lifetime.
D
The
whole
lifetime
of
the
device,
independently
of
whether
the
device
per
se
could
change
the
MAC
address
or
not
it's
like
they
will
not
change.
You
will
only
do
once
and
per
boot
is
like
there
will
be
changes,
but
only
when
rebooting,
so
you
reboot,
the
change
is
address,
is
it
the
address
is
changed.
D
Sorry
and
the
same
thing
for
the
other,
behaviors
I
do
agree
that
we
need
to
be
very
careful
and
we
very
need
to
be
very
explicit
or
clear
on
what
we
mean
by
this
taxonomy,
but
I
think
it
may
be
useful
to
document
behaviors
of
devices
that,
at
the
end
of
the
day
we
may
have
in
the
future
because
I
foresee
it.
Maybe
it
may
make
sense
to
have
better
device
device
generated,
Mac
addresses
policies
or
approaches
and
pervert
generated,
my
calories
and
the
other
one.
D
B
Okay,
thank
you.
Then.
I
I
fully
support
your
suggestion
to
bring
that
to
the
list
for
for
discussion.
For
example,
I,
don't
know
any
device
that
implements
per
device
generating
Mac
address
because
they
all
do
on
the
persist
ID
basis,
so
it'd
be
probably
some
some
more
dialogue
and
discussion,
but
I
I
like
your
direction.
Thank
you.
A
C
Yeah,
thank
you.
Yeah
regarding
the
taxonomy,
I
I.
Think
it's
interesting,
especially
things
since,
because
we
have
a
Mac
addressee
that
may
have
different
lifetimes
and
the
the
impacts
on
the
rest
of
the
network.
May
really
depend
on
this
lifetime.
If,
if
you
create
a
new
address
per
boot,
I
mean
it
it
can
stay
for
days
months.
But
if,
if
you
change
it,
every
I
mean
there
are
some
cases
where
you
change
it
every
15
minutes.
C
A
A
So
if
you
remember,
we
had
mentioned
briefly
last
time
that
we
were
discussing
with
the
WBA
proposal
to
to
run
an
experiment
at
the
upcoming
ietf
to
Showcase
and
assess
open
roaming
as
one
of
the
potential
Technologies
to
address
some
of
the
use
cases
where
we
want
to
preserve
an
identity
across
the
network,
and
we
were
discussing
the
the
details
and
requirements.
So
I
want
to
give
you
an
update
on
the
on
the
discussions
that
we've
been
having
offline
with
the
WBA.
A
So
if
you
remember
open
roaming
is
trying
to
simplify
it,
for
those
that
are
familiar
with
that
ROM
is
that
kind
of
authentication
that
allows
users
to
roam
onto
different
networks
still
being
authenticated
by
their
identity
provider.
So
another
roaming
is
not
normally
an
academic
institution
but
open
roaming
by
using
pass
point
and
other
Technologies
takes
that
further
into
multiple
identity
providers.
A
So
the
purposes
for
someone
that
has
some
engagement
or
subscription
or
association
with
an
identity
provider
that
could
be,
you
know,
a
cloud
provider
that
could
be
a
and
Enterprise
that
could
be
a
service
provider,
a
retail.
So
examples
could
be
my
own
company
or
it
could
be,
you
know
like
Google,
Apple
Samsung
account
or
it
could
be
Starbucks
Etc.
A
So
that
is
the
the
good
experience
from
the
user's
point
of
view,
looks
like
open
roaming
and
because
it
relies
on
NATO
2.1x.
You
know
it
preserves
privacy,
so
secure
connection,
and
it
of
course
provides
a
good
experience
to
to
the
user
so
because
this
is
something
that
WBA
is
actively
promoting
and
and
suggesting
that
we
run
an
experiment.
A
We
we
thought
that
this
is
in
scope
for
for
madinas
to
do,
and
we
are
considering
doing
this
experiment
at
the
upcoming
meeting
in
London,
where
we
could
light
up
open
roaming
at
the
ietf
network,
allowing
users
to
connect.
Of
course,
users
in
the
ietf
network
already
connect
if
they
have
attended
a
previous
meeting.
The
credentials
are
there,
so
there's
no
new
thing
about
it.
A
So
the
discussions
are
ongoing
and
we'll
keep
you
updated,
but
so
far
the
intention
is
to
at
least
light
up
the
the
network
at
at
the
ietf
in
London,
so
that
people
can
see
and
experience
the
open
roaming
connection
at
the
network
in
idea,
ideally
of
course
roaming
to
foreign
networks
later
on.
Depending
on
how
this
goes,
we
could
see
taking
it
further
for
upcoming
meetings
as
well.
So
now
I
guess
we'll
keep
you
updated
right
now.
A
It's
it's
not
technical,
but
rather
you
know
like
commercial,
legal,
political,
Etc
discussions
that
have
to
take
place
to
to
enable
this
outside
the
the
ietf.
But
otherwise
it
looks
like
an
interesting
technology
that
we
could
consider
to
address
multiple
use
cases
that
are
being
discussed
right
now
here,
foreign.
Does
anybody
have
any
questions.
A
C
A
All
right,
yes,
so
indeed,
if
you
are
familiar
with
with
the
okay
durum,
probably
that
that
that
could
be
a
similar
scenario,
but
it's
yeah,
normally
the
the
access
network.
Will
you
know
we
will
try
to
find
that
who
is
the
identity
provider
and
then
the
identity
provider
will
return
a
token
that
allows
the
user
to
to
join
and
it
indeed
it's.
It
relies
on
nato2.1x
and
radius
to
do
all
these
exchanges,
but
yeah
we'll
we'll,
probably
show
more
more
details.
A
In
fact,
since
this
may
require
a
you
know,
a
more
detailed
discussion
at
the
technical
level,
one
one
thought
that
we're
having
is
to
to
run
either
a
site
meeting
or
some
place
where
we
can
actually
run
the
the
demo
and
see
the
details
and
have
a
detailed
discussion
without
necessarily
taking
the
whole
of
the
of
the
Medina's
working
group
slot.
So
that's
still
TBD.
C
Yes,
okay,
so
yes,
I
wanted
to
to
share
this.
This
work
with
you.
This
is
something
that
we've
done.
So
this
is
a
work
that
we've
done
with
some
colleagues
in
in
my
lab
and
I
thought
that
yeah
it
might
interest
you,
because
it
raises
some
interesting
changes
regarding
the
exhaustion
of
resources
when
we
use
address
randomization
so
so
yeah.
We
all,
we
all
know
some.
What
is
address
organization
so
because
we
have
this
tracking
that
may
happen
based
on
the
identifier
spawning
frame,
especially
in
802.11.
C
We
can
use
that
westernization
as
a
control
reserve
and
to
change
this
address
periodically
for
random
value.
This
has
been
used
by
several
companies
in
their
products
here,
I'm,
citing
again
up
on
the
iOS
first
implementation,
iOS
8
of
random
addresses
that
were
mainly
at
the
beginning,
used
in
from
requests
and
probe
responses.
In
this
case,
we
are
not
connected.
C
It's
quite
straightforward
to
randomize
the
address,
because
changing
the
address
does
not
have
a
real
impact
on
those
features
so
yeah
changing
the
address
when
a
device
is
not
connected
to
an
AP
is
easy.
On
the
other
hand,
when
you
are
connected
to
Knight
AP,
you
may
have
other
issues,
so
the
first
one
I
think
you've
already
studied
is
that
you
may
have
some
Collision,
because
you
may
you
have
a
limited
number
of
identifiers
other.
C
There
are
the
Mac
addresses
or
the
IP
addresses,
and
but
this
is
one
issue,
but
I
think
there
is
also
one
that
is
very
important.
Is
that
when
you
change
your
address,
you
need
to
reconnect
so
either
you
only
change
when
you
change
the
network
or
you
need
to
have
a
gap
in
your
connectivity
while
you
change
your
address
and
reconnect
to
the
to
the
network.
C
So
this
is
a
I
think,
a
big
problem
that
I
think
today
is
preventing
actual
renewal
periodical
renewal
of
the
addresses,
like
we
have
in
non-connected
mode,
where
addresses
are
renewed
every
15
minutes.
So
we
cannot
do
that
without
a
loss
of
connectivity
when
we
are
connected
to
an
AP,
so
we
have
a
an
ID
that
we
develop
in
this
paper.
We
call
Roma
rotating
Mac
address
for
privacy
protection
that
was
published
as
a
poster
during
the
conference,
ACMC
com,
2022
and
I'm.
C
Going
to
present
to
the
the
basic
idea
here,
so
it's
based
on
the
principle
that
we
can
use
multiple
interfaces
in
parallel
to
perform
this
rotation
without
losing
the
connectivity.
So
each
interface
will
regularly
rotate
its
address,
as
as
we
do
when
we
are
not
connected,
but
so
we
can
keep
the
idea.
So
each
interface
can
change
each
address
every
15
minutes
and
we
want
to
ensure
that
at
any
moment
we
have
at
least
one
address
that
is
connected.
C
But
the
problem
is
that
most
of
the
device
that
we
have
today,
they
only
have
one
interface
and
I.
Think
it's
not
going
to
change
soon.
Fortunately,
we
can
use
what
is
called
virtual
interfaces
that
exist
for
wireless
interfaces,
so
you
have
one
physical
interface
on
which
you
can
create
spawn
addition
or
virtual
interfaces,
each
of
them
having
its
own
Mac
address.
C
So
using
virtual
interfaces
on
the
those
Wireless
Hardware
interfaces
is
limited
because
not
all
Hardware
supported,
so
we
had
to
struggle
a
bit
to
find
hardware
that
was
supporting
it
along
with
the
drivers
that
we're
supporting
it.
So
it
was
not
not
easy
to
do
that,
but
we
found
some
very
specific
Hardware
that
is
doing
it,
and
we
suspect
that
many
other
interfaces
Hardware
interfaces
May
support
it,
but
the
driver
do
not
allow
it
yet.
C
Maybe
how
do
you
maybe
compartmentalize
the
the
different
traffics
between
the
interfaces,
because
you
may
have
all
the
benefits
by
using
server
interface
with
all
of
the
scope
of
the
discussion
today?
What
I
want
to
discuss
briefly
is
the
the
the
experiment
that
we
had
based
on
the
main
leader
performances.
So
we
had
a
very
basic
setup
in
which
we
have
one
device
and
one
access
point.
C
There
is
only
one
interface
that
is
handling
all
the
traffic
of
the
device
and
we
pushed
us
much
traffic
as
we
could,
and
you
can
see
that
overall,
the
traffic
remain
constant
events,
even
if
sometimes
you
have
a
small
discontinuity,
as
you
can
see
here
when
you
change
the
interface
interface,
so
you
have
a
drop
but
quickly
you
regain
your
throughputs
So
based
on
the
performances,
so
it
may
have
some
glitches
when
you
switch
the
interface.
But
overall
you
keep
the
the
connectivity
and
then
we
looked
at.
C
Maybe
if
you
want
to
increase
the
number
of
interfaces
and
you
want
to
spread
your
traffic
across
the
different
interfaces,
you
may
have
some
inefficiency
that
is
introduced
by
the
fact
that
you
have
to
switch
between
I
mean
the
hardware.
Interface
needs
to
switch
between
one
virtual
interface
and
the
other,
but
you
can
see
here.
That's
there
are
some
variations,
but
it's
basically
not
not
that
big,
so
the
impact
is
very
limited
yeah.
C
So
these
are
the
performances
impacts,
but
you
also
can
have
problems
regarding
the
resources
of
the
network
on
which
you
are
connected,
because
you
will
have
much
higher
consumption
of
The
Logical
resources.
We
know
that's
using
address
organization,
changing
the
address
having
multiple
addresses
for
each
device.
We
consume
more
than
just
having
one
address
per
device,
and
this
is
here
additionally
multiplied
by
the
fact
that
now
a
device
does
not
only
have
one
interface
but
multiple
interface.
C
So
you
will
multiply
the
total
number
of
Hardware
identifier
that
will
be
used.
So
there
is
a
real
risk
of
resources
exertion,
so
the
slots
in
the
access
points
that
may
be
exhausted
also
with
the
DHCP
Services
IP
address-
may
be
kept.
So
we
may
need
here
to
enforce
the
fact
that
IP
are
released
before
changing
the
address,
and
there
are
probably
many
other
cases
where
there
are
probably
issues.
So
I
just
wanted
to
to
present
this
new
approach,
and
none
of
it
will
be
implemented
in
the
wild
someday.
C
E
Yeah,
so
I
will
grab
the
floor
mat
here.
Thank
you
for
presenting
this
and
without
any
head
right
simply
because
I'm
curious
there
you
talk
about
the
HTTP,
obviously
in
the
case
of
rpv6,
probably
not
used.
So
that's
not
a
real
problem,
but
you
have
either
the
neighbor
cat
or
the
arc
cache,
which
is
also
consuming
another
thing
and
you
also
used
to
be
disrupt.
Ip
I
mean
TCP
session,
except
if
you're,
using
multi-pass,
CCP
right.
E
C
Yeah
yeah,
so
this
is
the
multiple
CCP
will
be
so
we
can
combine
all
of
them,
but
yeah
your
rights.
This
is
we
want,
so
we
we
are
looking
at
ways
to
I
mean
close.
Those
connection
nicely
without
yeah
losing
I
mean
keeping
open
connection
on
the
server
or
on
the
client's
method.
Yeah.
We
are
looking
into
that.
B
And
no
thank
you.
In
fact,
the
question
I
was
asking
was
asking
you
know
from
America
I
was
you
know,
worried
about
this
section
resumption?
You
know
having
to
begin
an
IP
address
and
the
drop
there
not
to
mention
you
know
the
the
load
on
the
on
the
servers.
I'll
be
more
in
detail
about
the
paper
thanks
a
lot
for
sharing
that
Matthew.
A
C
We
are,
but
we
don't
have
the
human
resources
to
to
to
progress.
So
now
we
have
the
proof
of
Concepts,
we
know
it's.
We
have
the
adware
to
make
it
work.
There
are
some
issues,
but
there
are
many
many
Avenues
to
to
explore.
That's
the
performances
issue
that
we've
discussed
here,
but
also,
like
I,
said
the
rotation
strategies.
C
C
No,
we
haven't,
so
we
were
kind
of
assuming
that
there
will
be
no
modification
on
the
network
side
that
only
we
only
add
control
on
the
device
but
yeah
they
will
probably
like
you,
suggested
many
features
that
can
be
added
to
make
this
Behavior
more
fluid
for
the
the
network,
yeah
that
it
is
very
good,
very
good
idea.
I'm
gonna
write
this
down.
A
A
Thanks
we're
almost
at
the
top
of
the
hour
and
then
I
guess
what
happened,
as
we
mentioned
before,
is
to
to
run
the
meeting
and
at
IDF
in
London,
which
is
like.
We
have
an
interesting
work
to
do
from
here
to
there.
We
have
some
some
comments
that
the
progress
has
been
slow
and
it's
true
that
the
the
list
has
been
rather
quiet,
so
I
encourage
people
to
to
continue
discussions
on
the
list
from
now
till
London,
and
hopefully
we'll
have
a
very
productive
meeting
in
London.