Subject: Re: making our tcp/ip a strong-end system
To: Luke Mewburn <lukem@netbsd.org>
From: Paul Goyette <paul@whooppee.com>
List: tech-net
Date: 11/10/1998 04:40:45
On Tue, 10 Nov 1998, Luke Mewburn wrote:

> in PR kern/991, darren reed outlines how to modify netbsd (1.0a) to
> enforce the `strong end system' model in tcp/ip. this is where a
> packet destined for this machine is not accepted on an interface other
> than the one that is configured for that address.
> 
> i've taken the ideas in darren's pr (and subsequent followups to it)
> and merged them into -current (19981010). before i go and totally
> screw the pooch, i was interested in feedback from the tcp gurus
> to see if my mods were the appropriate solution.
> 
> the patch below adds support for a new sysctl, net.inet.ip.strongendsystem,
> which if set to non-zero enforces the semantics described above. you
> can hardcode this on by defining IPSTRONGENDSYSTEM to non-zero.
> 
> comments/thoughts on this suggested patch? problems people see with
> this implementation (especially when you've got a multihomed box
> that's routing)?

I'm definitely not a TCP/IP guru (at least, not when it comes to the
implementation of the network stack), so the source code patches won't
mean too much for me.  But I do have one question:

Does the loopback interface still work?

In particular, is it still valid for a packet addressed to the NetBSD
system's loopback interface (or any of its routable alias addresses) to
arrive via _any_ available physical interface?

This is important for those who may be running their NetBSD system not
just as a "router" but also as a "routing engine".  If anyone is using
their NetBSD system as a BGP router, they are probably using the
loopback interface's address as the local address on all of their
peering sessions.  It is also quite common for one to use the loopback
interface as the OSPF Router ID and to advertise that interface as a
"stub host" into the OSPF routing domain.

Also, it sounds as though your changes might break some other useful
diagnostic tools, such as sending a ping with a particular source
address and being able to see the response.  This is a quite common
troubleshooting technique in the world of dynamic routing protocols.

Finally, you note that setting the IPSTRONGENDSYSTEM option in the
config file will "hardwire" the option on.  Would it not make more sense
to make the option simply set the initial default value, thus enabling
one to turn it off later if needed?  If you're really paranoid, you can
always come up with another config option that disables changing the
sysctl variable.

-----------------------------------------------------------------------------
| Paul Goyette      | PGP DSS Key fingerprint:   | E-mail addresses:        |
| Network Engineer  |   BCD7 5301 9513 58A6 0DBC |  paul@whooppee.com       |
| and kernel hacker |   91EB ADB1 A280 3B79 9221 |  paul.goyette@ascend.com |
-----------------------------------------------------------------------------