On 24/10/2013 10:59, Benedikt Stockebrand wrote:
And it provides negligible - perhaps zero - improvement in privacy.
Sorry, but I disagree on that. While you may be right when it comes to
Ah, I was unclear:
Privacy addresses are fine - no problem with them.
What I meant is that the specific strategy Apple devices seem to be
using to re-generate them - on link-up - provides little or no benefit
*above* a per-link & time-based rollover.
I assert that rolling the address on a timer, not on power/link
activity, is the intent of the RFCs, and the desired behaviour, and
that Apple are doing the wrong thing here.
This is too simple: If I want to avoid people/devices being tracked when
moving from one link to another, then I need to use a new temporary
Sorry, again I was unclear: of course the strategy needs to be more
involved than just a global timer. Clearly address rollover needs to be
per-link - probably per prefix&link.
As a substitute for the SSID, the IP address(es) of the router(s) could
be used to check if a device connects to the same link again. But then,
this doesn't provide any crypto protection, so it can be used to spoof
things.
Or just per prefix, as seen in the RAs, which are present on every link.
Specific strategies for determining the domain within which a privacy
address is valid for a specific time are many and varied.
In the long run, a move to RAM-based trie lookups seems to be the way
to go for FIBs, for the superior power use characteristics if nothing
else.
Somebody from the hardware implementers correct me, but this should be
both difficult to implement and is likely too slow. You don't use
CAM/TCAM unless you are really desperate for speed.
There are already high-speed devices using RAM for FIB e.g. Juniper Trio
chipset uses RLDRAM.
