[ strong ended system discussion, please skip to /Paul/ if not interested
  in my response to tron ]

> That will cause lots of trouble in normal networking situations, e.g.:
> 
> server	ether 0		192.168.1.1
> 		ether 1		192.168.2.1
> 
> client	ether 0		192.168.2.2
> 
> If "client" tries to connect to 192.168.1.1 (e.g. because "server" has
> A records for both interfaces) the connection will fail although
> everything works as expected.

This is precisely what a strong ended system is intended to do.
The idea is that a box may have interfaces on both `green'
and `amber' security zones, and present different services
to each (using different local address binding in inetd).

Making the system `strong ended' would, in addition,
prevent clients in the `green' zone accessing resources
made only available on the `amber' zone address, and
vice versa.

Paul Goyette <paul@whooppee.com> has a more interesting concern:

> In other words, I want to be able to address a packet to a router's
> loopback (alias) address, and I want that packet to get there if at all
> possible.

In a traditional strong ended system, there would be no support
for this because the loopback would be treated no differently
from any other interface, and thus only the machine itself
would be able to access resources bound to the loopback interface.

Now, typically, this is a "good thing" because those resources
would normally be 127.1 resources of more trusted privilege.

However, in your case, you are using the loopback interface to
(or any other interface, for that matter) to provide a
`public' address for a resource, which is well-known by the other
side and perhaps exists in publicly known ACLs.  I can see
where this might be useful in situations where strong ended
behaviour is also useful.

Perhaps what is needed is to be able to mark individual
interfaces `strong' or `weak' instead.  So a system
with all interfaces marked `weak' would be exhibit
normal BSD behaviour, a system with all interfaces
marked `strong' would be a traditional strongended system.

So what would be the semantics be ?   The most `obvious'
semantics, that of making `strong' ends only accept their
own address would be the most obvious (and easiest to code)
but would unfortunately not provide the means of achieving
the `public' resource addresses goal.

The `useful' semantics would be that a `strong' end would
only accept packets addressed to its address *or any of its
weak end addresses*.  Problem is that I can't think of an
efficient way to implement this.  One would have to
traverse a list of weak end addresses for every comparison.
Eeeeuuuwww.....

A `pragmatic' solution would be to have a notion of a single
`primary' address which, if set,

	a) must be one of the addreses on one of the interfaces
	b) would be permitted access to from any interface
	   even if the system were marked `strongended'

It's an architecturally ugly solution that I would not
like to see in a showpiece of architectural elegance like NetBSD,
but is just the kind of hack that a customer might ask for.

All this leads me to wonder just how generally useful
a `pure' strong ended system would be in the real world out there.
Survey anyone ? :-)


--