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

[Philip Homburg <[e-mail]>]

> > 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 addresses and then
we have all devices advertise what their vendor is and their current addresses.

Anybody who wants to do monitoring will have a field day.

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 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).

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

> See
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-03#section-8.3

Of the disadvantages:
- The first point can be solved by pinging the first hop router 
- The second point also applies to pinging an off-link destination
- There can always be broken middle boxes. I.e., if a wireless device does
  ND proxying then it is up to the network admin to make sure that the
  router has enough capacity to perfom ND. In any case, the existance of 
  weird middle boxes should not be a reason to start pinging off-link 
  destinations.