-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Many daemons, including named, sshd, and sendmail, can be explicitly
given a set of interfaces to listen on.  They would be configured
normally to listen on the outside interface (or both interfaces, in a
strong-host-model environment).

Other daemons, including those mentioned, can only listen on INADDR_ANY.
At this point, there is _no_ way to prevent them from listening on an
outside interface.  This would be addressed by the new flag.

More generally, such a flag would provide an easy way to classify which
interfaces were to be used for general services, which is useful in many
situations.

On Wed, 2 Jan 2002, Paul Goyette wrote:

>So, you have two sets of interfaces, "inside" and "outside".  And you
>have two sets of daemons, some which should listen only on "inside"
>interfaces and some which should only on "outside" interfaces.  (And
>maybe a third set, which should listen to all interfaces.)  And maybe
>you even have one daemon where you need to run two separate instances,
>one on each set of interfaces.  (Named comes to mind here.)
>
>How would restricting INADDR_ANY provide the required segregation of
>interfaces into two groups, except in the simple case where one group
>(probably "outside") has only one member?
>
>On Wed, 2 Jan 2002, Jim Wise wrote:
>
>> Let me provide a clear example of a situation where I would like to have
>> this capability, BTW:
>>
>> For a number of shops, I have set up NAT routers with one or more
>> outside interfaces, and one or more inside interfaces.  In a small
>> office situation, such a system will want to have named, sshd, and
>> sendmail listening on the outside interface(s), and a wider range of
>> services listening on the inside interface(s) (lpd, samba,
>> netatalk-over-ip, nfs, to pick some examples).  Many of these services
>> _cannot_ be configured to listen on anything but INADDR_ANY, even if
>> they can be configured not to authorize connections on certain
>> interfaces.
>>
>> To date, ipf is the only available solution for this, and as mentioned,
>> configuring ipf to block all services invisibly on the outside
>> interface(s) is both error-prone and subject to both race conditions and
>> user error.
>>
>> I would _like_ to be able to mark the external interface(s) as excluded
>> from INADDR_ANY, allowing INADDR_ANY to be used normally over the set of
>> internal interfaces...
>>
>> On Wed, 2 Jan 2002, Paul Goyette wrote:
>>
>> >Then, what would you do if you _did_ want some daemons to listen on
>> >all interfaces, but had other daemons which should listen only on a
>> >subset?
>> >
>> >Perhaps INADDR_MOST_BUT_NOT_ALL would be useful here?   :)
>> >
>> >On Wed, 2 Jan 2002, Jim Wise wrote:
>> >
>> >> Please note:  this is *not* a strong-vs-weak host model post.  I
>> >> strongly believe a sysctl to choose strong or weak host model is in
>> >> order, but this is a separate question, specifically:
>> >>
>> >> What do people think of the idea of adding a per-interface flag,
>> >> settable with ifconfig, to indicate that an interface should not be
>> >> included in INADDR_ANY?
>> >>
>> >> Such a flag would be especially useful in a strong host model of course,
>> >> but even in the current model, there are many instances of hosts which
>> >> have one or more interfaces on which it is not desirable to have daemons
>> >> listening (think a management-lan interface, or the outside interface
>> >> of a NAT or proxy gateway).
>> >>
>> >> As many daemons, (in particular all current RPC services) provide no way
>> >> to limit the daemon to listening on a particular subset of interfaces on
>> >> the system, it seems to me valuable to have the ability to indicate that
>> >> an interface is _not_ intended to be listened on by general services.
>> >>
>> >> (And yes, of course this can be done with ipf, but let's face it, having
>> >> a daemon actually listening on the undesired port and then blocking
>> >> access with ipf in a way designed not to be picked up by port scanners
>> >> is error-prone at best, and worse, subject to race conditions, such as
>> >> connections in the brief interval between ipf stopping and starting when
>> >> invoking /etc/rc.d/ipfilter reload).
>> >>
>> >> --
>> >> 				Jim Wise
>> >> 				jwise@draga.comSignature by unknown keyid: 0xC398730E
>> >>
>> >
>> >----------------------------------------------------------------------
>> >|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:   |
>> >| Network Engineer | BCD7 5301 9513 58A6 0DBC |  paul@whooppee.com   |
>> >|  & World Cruiser | 91EB ADB1 A280 3B79 9221 | pgoyette@juniper.net |
>> >----------------------------------------------------------------------
>> >
>>
>> --
>> 				Jim Wise
>> 				jwise@draga.comSignature by unknown keyid: 0xC398730E
>>
>
>----------------------------------------------------------------------
>|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:   |
>| Network Engineer | BCD7 5301 9513 58A6 0DBC |  paul@whooppee.com   |
>|  & World Cruiser | 91EB ADB1 A280 3B79 9221 | pgoyette@juniper.net |
>----------------------------------------------------------------------
>

- -- 
				Jim Wise
				jwise@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE8MywZN71lEcOYcw4RApfaAJ9EZA34UhxSkJmL3sR9JkkBiOpKWACgv767
df6LBVJyCRem99uUol9iYto=
=2gy9
-----END PGP SIGNATURE-----