Re: Temporary IPv6 addresses vs. netgroups

[Darren Reed <darrenr%netbsd.org@localhost>]

On 3/02/2013 2:08 AM, Robert Elz wrote:
...
>   | ... it isn't just web browsers that will leak that piece
>   | of private information to the Internet, it is anything that
>   | connects out through the Internet, be it the web browser,
>   | ftp client or ssh.
> 
> Yes - I was just giving an example of the kind of application for which
> avoiding stable addresses is useful, not attempting to be exhaustive.
> ftp clients would be another application.  I'm not sure ssh matters as
> much, as ssh clients tend to identify the actual user, which is even more
> precise identification than just identifying the host.   But it wouldn't
> harm ssh clients to use temp addrs.
> 
>   | This indicates to me that the policy for when a temporary
>   | address should be used is not something that we can depend
>   | on an application to provide.
> 
> I don't grasp that leap - for sure, the user might want to override
> the application's default, which would usually be done by telling the
> application to request a different policy.  You might just as well say
> that the application cannot be entrusted with selecting the destination
> address, as the user might want to connect to different destinations.

The desire to use a temporary address doesn't change with
the application, it changes with the destination or to be
more precise, with the remote service with which the
application wishes to communicate.

I don't particularly care which application is communicating
with (say) www.fbi.gov but whichever application does I want
it to use a temporary address irrespective of what the
application itself might want to do. For example.

Additionally, how is address selection policy enforced for
those applications for which source code is not available?

If I was to think about what is happening in the Windows
application space, today binaries for free software are
being provided that want to "phone home" to check for
updates, etc and some will not work unless they can do
that. If they were allowed to choose to not use a
temporary address when communicating with their "home
server", then the whole point of temporary addresses
is lost.

When you consider the NFS problem, is it important whether
or not it is rpcbind or rpc.lockd or mountd or the kernel
that needs the non-temporary address for talking to the
NFS server? No. What's important is that all communication
with the NFS server for the purpose of using that NFS
server all use a stable address and preferably the same
one that the NFS server expects!

Why do I trust the application to use the correct destination
address? Because if it doesn't then it doesn't give me the
correct service. If a web browser connects to a random IP
address rather than the one associated with the domain name
that I want then I'll see that. If my RPC utilities connect
to the wrong server then that'll be visible when I do "df"
or "ls" for the files. If my popper connects to some random
POP server rather than the one at my ISP, my email won't be
there. And so on.

To go back to your examples, one of them was connecting to
an SMTP server. Chances are that you want the same source
address used regardless of whether the connection is made
using the telnet program or a dedicated mail program.
If that is the case, why would you want to instruct each
of those separately as to how to choose a source address
rather than simply define a policy around communication
between the two hosts which by default governs how both
telnet and the mail program communicate?

Darren