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

[Mark Smith <[e-mail]>]

On Tue., 23 Jul. 2019, 10:00 David Lamparter, <[e-mail]> wrote:

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

If that's enough of a concern to you, them you must isolate your hosts to
their own individual links, virtual or physical, so the only other devices
on the link is one or more trusted routers.

You can't attach a set of untrustworthy hosts to a mutual trust,
multi-access link and then trust those hosts to always behave. The explicit
point of those types of links is to be able to send anything to anyone.



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

We invent the future here.

However, I have some small distant evidence that Mac OS X already does,
because it sends MLDv2 joins for the NI multicast group. (I don't have
access to OS X to further look, and it wasn't something I was looking into
at the time.)

There's already a BSD/Linux NI implementation available. The out of the box
version of 'ping' that comes with Fedora 30 can send NI queries.

So we're not talking about 'from scratch' implementation, or complete
replacement of ND.

There would need to be a transition mechanism and period for hosts that
don't support these queries. That's no different to any other solution that
requires changes to either or both host and router behaviour.



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

DAD doesn't occur with anycast addresses, do it isn't a complete solution.

I'm pretty sure Ericsson have IPR for that idea, because it came up with
the discussion of this draft.

Not that IPR is a reason not to use the idea, however I think it is better
to avoid it, combined with not supporting onlink anycast addresses.

Triggering ND Address Resolution on Receiving DAD-NS

https://tools.ietf.org/id/draft-halpern-6man-nd-pre-resolve-addr-00.txt





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