Re: draft-gont-6man-managing-privacy-extensions-00.txt

[Mark Smith <[e-mail]>]

On Sat, 12 Mar 2011 21:57:14 -0300
Fernando Gont <[e-mail]> wrote:

> On 12/03/2011 09:44 p.m., Christian Huitema wrote:
> 
> >> It doesn't. The I-D aims at allowing routers specify which policy
> >> they want hosts to employ when generating their IPv6 addresses.
> > 
> > Uh? I definitely don't want to give the router at Starbucks the means
> > to specify the privacy configuration of my laptop.
> 
> Override the advice provided by the router at Starbucks, and you're done
> (e.g., I guess this could even be automatically done by the OS depending
> on how you tag the network you're connecting to (e.g., Public, Home,
> whatever)).
> 
> 

I doubt typical end-users will be capable of getting this right often
enough for them to accept the possible privacy compromise when they
don't.

So what is wrong with the record and observe model, avoiding modifying
existing protocols and end-nodes to achieve your goal?

I don't understand why proactively putting an entry in a
neighbor cache when an end-node performs DAD, on a designated audit
device, and then letting NUD observe and report state changes for that
neighbor cache entry won't achieve the goal. There may need to be some
minor changes to ND state mechanisms to achieve this (e.g. ignore the
DAD if there is already an entry for the DAD tentative IPv6 address,
as DAD will fail, and maybe report it), however those changes
would only be required to be deployed to the audit device.

> 
> > If we want policy options to be applied safely, they have to be
> > propagated by trusted mechanism, where the host can verify the
> > authority of the policy source. Anything else is abuse waiting to
> > happen.
> 
> The threat model for this case is no different to that for ND in general...
> 

Existing addressing mechanisms in ND only have a goal of advising
end-nodes what method they should use to acquire their IPv6 addresses.
The end-node has a vested interest in following that advice, as it
will provide connectivity to other peer nodes as well as off-link
connectivity. However, end-nodes can ignore it, and e.g. use static
addressing or link-local addressing to still achieve useful
connectivity, albeit more limited than if they followed the advice in
an RA.

If you want to place far more trust in the end-nodes' address
selection choice, for audit purposes, I think you're going to have to
build much more complicated mechanisms that the one proposed, that allow
you to be assured that they've followed your advice.

Regards,
Mark.