>> Indeed -- Jonathan -- can you please describe the semantics that you
>> have confirmed that we have?
> See sys/netinet/ip_input.c, the sysctl net.inet.ip.checkinterface,
> and the comments just above the line

> int	ip_checkinterface  = 0;

For those who don't want to bother trying to figure this out, the
comment in question is (as of ip_input.c,v 1.214 - Jonathan didn't
specify what version of ip_input.c, and indeed the first one I checked
doesn't _have_ ip_checkinterface):

/*
 * XXX - Setting ip_checkinterface mostly implements the receive side of
 * the Strong ES model described in RFC 1122, but since the routing table
 * and transmit implementation do not implement the Strong ES model,
 * setting this to 1 results in an odd hybrid.
 *
 * XXX - ip_checkinterface currently must be disabled if you use ipnat
 * to translate the destination address to another local interface.
 *
 * XXX - ip_checkinterface must be disabled if you add IP aliases
 * to the loopback interface instead of the interface where the
 * packets for those addresses are received.
 */

> That, plus:

> 1.  a-priori knowledge that a given host has at most one
>     address per interface, and at most one interface on a given subnet;
> 
> 2.  A-priori knowledge of a [statically-configured]  routing table;
> 
> 3.  Conscious reliance on the fact that *BSD kernels use, for
>     unbound sockets, the local address of the outbound interface;
> 
> Then 4.4BSD (posibly earlier) and descendants gives one a reasonably
> good strong- ES model.

Not quite.  If you explicitly bind a socket to a local address that is
on interface A and then use it to try to send to an address that's
routed out interface B, strong ES would require the packet to be sent
out interface A, or else error out (1122 3.3.4.2 item B), whereas even
assuming all of the above, NetBSD[%] will send out interface B (and, if
checkinterface is turned on, drop replies if they come in interface B).

[%] When was the 4.4 merge done?  ip_checkinterface, at least in
    ip_input.c, came in between 1.6 and 2.0 - wasn't the 4.4 merge well
    before that?  This forces me to question which is wrong: my own
    impression that 4.4 was merged in well before 1.6, or Jonathan's
    implication that 4.4 had ip_checkinterface.

> Was this news to anyone?  I confess I didn't understand, at all,
> Mouse's response over the weekend.

Let me see if I can rephrase it.

As I understood the discussion at that point, you were saying "don't do
that, it breaks strong ES".  I was just trying to point out that NetBSD
doesn't do strong ES, and therefore "it breaks strong ES" is about as
relevant to NetBSD as "it breaks the B2 security model": "breaking"
something that doesn't work to start with is irrelevant.

Now, if what you meant is "it makes it impossible to get as close to
strong ES as one could before", or "it significantly increases the
patches necessary to give it strong ES", or some such, that could
arguably be relevant, but that wasn't what I saw you saying.

> Manuel's config has two NICS with only one address per NIC, so to fix
> Manuel's problem, you *have* to break the strong-ES behaviour

Yes.  As 1122 notes (excerpted),

                 o    Weak ES Model

                                      ...  This model ...
                                 ... is necessary for hosts that have
                      embedded gateway functionality.

Since in both Manuel's case and mine, the host under discussion is
acting as a router, it has "embedded gateway functionality" in 1122's
sense, so whether to preserve strong ES on it is not even in question
(though "preserve" isn't the right word, since NetBSD doesn't have
strong ES to preserve).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B