Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache

[David Lamparter <[e-mail]>]

On Tue, Jul 23, 2019 at 09:13:19AM +1000, Mark Smith wrote:
> On Tue., 23 Jul. 2019, 07:37 David Lamparter, <[e-mail]> wrote:
> > I'm generating a privacy address.  I do DAD for it, and I send it to,
> > say, ff02::1:ffc6:3a4b.  On shitty networks, this will be a broadcast,
> > so everyone knows the address I'm using and can associate the MAC.  But
> > on non-shitty networks, it doesn't go anywhere because no one is
> > interested in that particular group.
[...]
> > The third option is for the router to pick up all DAD groups.  It
> > certainly won't report /ALL/ DAD groups in MLD, so this would break if
> > you have MLD-snooping switches... unless you configure multicast routing
> > properly with "all multicast on router ports".
> >
> > Is there another choice? How about ff02::16 (All MLDv2-capable routers)?
> >
> 
> Why not have routers on the link learn of a node's link-local address via
> source addresses of the node's RSes and MLDv2 joins, and then have the
> routers query the node via unicast for all its other addresses.

Neither of these contains the global address(es) that a host generated,
so you would need...

> There's already two ways the unicast query could be supported to collect
> the node's other addresses, via ICMPv6 Node Information queries (RFC 4620)
> , or Inverse ND (RFC 3122).

... either of these options, which I strongly hope no one implements
because then I can just chuck all my privacy considerations straight out
the window...

(Coincidentally, I'm pretty sure most hosts won't respond to either of
these two.)



I'm tentatively in the DAD snooping camp, but this is a tricky problem.
My decision tree for DAD is this:

1. do you have a network with multicast snooping / limited multicast
   propagation?

=> No: your router sees all DAD anyway, but also your privacy is already
   f*cked from the DADs you sent.  Either way we're not making it worse
   by picking the DADs up on the router.  End tree.

=> Yes: it seems someone configured multicast.  (You don't get this
   without config, it's a bit of a PITA honestly.)  Proceed to 2.

2. is whoever configured multicast competent?

=> No: you're screwed already because broken multicast is broken DAD.
   So if not all DAD makes it to the router, some or all clients will
   experience connectivity delays.  ff02::1 or ff02::2 could /lessen/
   these issues, but they come with their own bag of troubles and your
   broken multicast setup might be messing with them anyway.

=> Yes: the competent person needs to understand that unicast routers
   need to receive all multicast traffic in order to catch and snoop
   DAD.  Set the "multicast router present" bits on the appropriate
   ports on your L2 devices and you're golden.  Also, this is the only
   scenario where some measure of address privacy can be provided, since
   this is the only scenario in which DAD wouldn't turn into a
   broadcast, and it remains so even with the router picking up all DAD.


-David