The following is a proposal on a MAC address mediator
protocol.
Its purpose is to resolve MACaddr collisions, meeting
the 802 policy
that if local scope addresses are used, there will be
such a mediator
feature (or some such; someone help me with the exact
wording that Pat
used monday evening).
To work, this protocol is crypographically
based. Paul Lambert had
point out to me how my own ideas in HIP could be used
for MAC addresses
as well. I have thought a lot about this and I will
cut to the chase,
skipping over why I chose want is here. I am willing
to put together a
few slides for thursday evening.
Here goes:
Every participating device has a MAC entity Identity
consisting of the
public key of a ECDH keypair. A hash of this key
into a 128 bit value
is the MAC entity Identifier, much like the HIT in
HIP. A hash with a
nonce will be used to create the actual MACaddr used
by the device. For
privacy purposes, the ECDH keypair are ephemeral, a
device can
precompute a number of these and have them ready to
use at will. For
collision avoidance a device must be ready to use a
different Identity
or nonce to present a different MACaddr.
The media MAC mediator will regularly broadcast its
ECDH public key.
This key MAY be contained within a digital
certificate that a
participating device can validate from cached
information; this is not
required. The timing of these broadcasts will help a
device to
recognize the mediator of the media. In practice
this could be a
function of a DHCP or RADVD server (or AP BEACON).
At linkup time, a device will listen for these
broadcasts, use the
public key therein along with its Identity key and a
nonce to construct
a shared secret. This secret will be used to MIC a
packet to the
mediator that will contain the devices: MACaddr,
Nonce, Identifier, and
Identity. If this is a new MACaddr for the mediator
it would reply with
an ACCEPT MICed message. If there is a collision, it
will REJECT,
causing the device to select a new MACaddr and try
again.
The use of crypto should be apparent to most here, to
protect against
attacks. ECDH is the lightest weight algorithm we
have. I would even
recommend using a fold rather than a SHA hash as I do
in HIP-DEX to
further lighten to load (for very small IoT devices,
though 64 bit MACs
will should have a larger number space anyway). Plus
the active nature
of an ECDH protocol protects against replay
attacks. A 'key' feature
here is that it is actually the Identifier (and
Identity) that are
registered with the mediator, and thus presenting a
much larger number
space to lower the probablity of collisions.
A 'downside' to the existance of such a mediator
protocol is that it can
be argued that given a collision resolution protocol,
the privacy
feature CAN operate within a smaller number space.
This mediator protocol would be optional in
environments where ZEROconf
is used. Afterall, who is the mediator on such a
media?
This is basically a 3 packet protocol: BEACON,
REQUEST, RESPONSE. It
can be fit into many existing such protocols already
deployed on various
media.
Thank you and goodnight.