Re: Temporary IPv6 addresses vs. netgroups

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

On 6/02/2013 10:18 AM, Robert Elz wrote:
>     Date:        Sun, 03 Feb 2013 10:56:24 +1100
>     From:        Darren Reed <darrenr%netbsd.org@localhost>
>     Message-ID:  <510DA7A8.3010106%netbsd.org@localhost>
> 
>   | 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.
> 
> No, not at all - or rather, once again, you are contemplating a different
> problem than the one I am concerned with.
> 
> To be more clear, I am trying to get a mechanism that can be used by
> NetBSD and pkgsrc developers, when they write/patch code for network
> applications so they can have the application (as it gets shipped to
> the users) can operate in the best possible mode, assuming the user
> supplies no additional configuration information at all.

I suspect that maybe you're concerned with a different aspect
of the privacy implications of EIDs than I am.

From a personal perspective, I neither want to burden those
maintaining pkgsrc with extra "tweaks" nor do I want to need
to write networking code on NetBSD in a "special way".

Similarly, I don't want to have to tell each application what
kind of addresses it can use.

> Once again, this is not saying that the kind of policy control that
> you're concerned with - which almost must be set up at the actual
> user site, as they're the only ones who can know these policies, is
> less important - it also doesn't mean that they cannot share some of
> the same mechanism - but what you are proposing is simply not what I
> am concerned with, or what I would like to be able to achieve.

I think you're right about that.

I'll say more on this below.

>   | 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.
> 
> Yes, but from telnet, only if I am connecting to port 25 (and even
> then I'm not sure it really matters, as I am probably not either
> patient enough, or accurate enough with my time keeping, to get
> through a greylist filter that way) - if I am using telnet to connect
> to a HTTP server (port 80) I want a temporary address, and if I am
> connecting to port 23, I probably don't care.  That suggests that
> telnet (the program) should have no default address choice, but a
> config option (command line switch, or telnet "set" command) to allow
> me to choose one way or the other if I happen to need it.

The reason that I raised telnet as an issue is that when
I use that to connect to a service, I want to see the same
address in the log files for telnet as the actual application
so that I know it is me and not someone else making the
connection to the service.

I suppose one way to approach that is to allow telnet to be
tweaked from the command line, another would be to define a
policy for that service and for which everything follows it
by default.


>   | 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?
> 
> Because I do not want to construct a policy at all.   Nor do 99% of
> other users.   I want things to simply work as they come out of the
> box, and work as well as possible.   If I find that I have some
> unusual requirements, then I'll learn how to configure those (and I
> certainly should have some ability to do that), but as long as I'm
> just an ordinary user, I just want things to work.

But in your email, you've almost defined the beginnings of
a policy that is something like this:

* use a temporary address for connecting to any web server
* use a stable address when connecting to NFS servers for
  all SunRPC services
* use a stable address when connecting to SMTP servers

The problem with a policy like this is that it is very
difficult to express in the usual manner that involves
addresses and ports because services can live all over
the place. That said, just because it is difficult does
not mean that we cannot find a way to make it possible.

Why am I insistent on a policy?

Because when I'm debugging network issues, it is of
great help if all communication on my network from
a given device is using the same address. It does
not help me if the web server records a different
address in its logs than does the ssh server and
so on.

If there are going to be multiple sources of data that
defines how stable/temporary addresses are to be used
then what takes preference?

I see a problem here of conflicting requirements:
1) where the application has a built in policy that is
   not selectable by the user but the user wants to
   override the application;
2) a default policy or somewhat generic policy (such
   as the current algorithm) that we want to override
   with the application.

Darren