Re: [Iot-directorate] [Last-Call] [v6ops] Iotdir last call review of draft-ietf-v6ops-nd-cache-init-05

[Michael Richardson <[e-mail]>]

Philip Homburg <[e-mail]> wrote:
    >> > This has huge privacy and security implications.
    >> 
    >> This is way, way too vague to be useful in the cons section.  Can you
    >> please elaborate, like an example attack? Also, is the current stack
    >> behavior exposing the user to that threat as well?

    > Suppose every device basics pings $vendor.com when it gets a new
    > address as part of a very low level function of the stack.

    > So basically we spend a lot of time worrying about tracking devices. We
    > have randomized MACs. We avoid embedding MAC addresses in IPv6

I agree with your observation.
That's why we need to specify a standard way, such that it could be an
anycast that is implemented in as many places as possible, so that it does
not leak too far.

    > I know that mobile devices do some weird stuff, but not all devices are
    > mobile devices. And the whole captive portal discovery seems to be
    > mostly a flight between device vendors and captive portals. There is no
    > technical reason it has to be this ugly for mobile devices.

The CAPPORT WG has produced some really good work.
HTTPS everywhere is rapidly killing the UX on most existing hijack-based
captive portals, and I think that once a few places have CAPPORT based ones,
the marketing/UX people will kill the rest of them.
Getting that anycast in place could be part of the new solution.

    > The situation would be better if there were a well-known anycast
    > address.  However that has operational implications (pinging $vendor as
    > well, because it has happened often enough that vendors stopped
    > renewing the DNS registrary after they stopped supporting a particular
    > brand of devices).

Anycast in DNS?
I was thinking about a well known L3 address, with some kind of AS119-like
support dealing with ISPs that haven't configured it locally.
If we need to give it a DNS name, then .arpa is the right place.

    > Even the well-known address may cause operational problems for
    > disconnected operation.


-- 
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-