--n8g4imXOkfNTN/H1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 31, 2003 at 04:31:14AM +1100, Darren Reed wrote:
> What really needs to happen is for the routing code to support multiple
> routes to the same destination (as a starting point!) and be able to
> select one based on some sort of path cost.
>=20
> Another feature that the routing code should support is matching on the
> source address or even more fields from headers for policy based routing.
> This is not at all trivial given the current radix tree support for the
> routing table.

These would certainly be very nice abilities, and ones I have wished
for and wanted on a number of occasions to solve real issues.

> Why should the routing table do it ?
>=20
> Because it's a specious argument, at best, to say that this sort of
> feature somehow belongs amongst code implementing access control.
> Whatever way I look at it, at least, it seems to clearly fit in the
> routing group of things, not filtering of any kind (or NAT, for that
> matter!.)

Almost. I agree in principle, but there is overlap.

The overlap is in the need for a language to express which
packets/sessions should match what processing (whether that's a
filter, NAT, or routing). Looking at what Cisco does (a generic
access-list that can be used in all sorts of other places in the
config) is informative, including the warts from the visible
access-control heritage of these (like having "deny" mean "ignore" for
some usages).

It would be lovely if there was a nice way to factor some of this out
of strict ipf usage, and make it accessible and used elsewhere; though
clearly that may have implications for ipf's habitation in other
kernels.

Although I've never looked at it, it sounds like OpenBSD (and KAME?)=20
are taking PF in this direction for things like ALTQ and IPSEC rules.

Also, note the "packets/sessions" a few para's back.  It would be even
nicer if, once something matched a "keep state" session, that was
visible to some of the other parts of the stack that might be using
ipf filter syntax, so I could (for example) set policy routing based
on the incoming SYN and have outgoing replies for this session act
accordingly.

> Furthermore, you shouldn't need to be using firewall software to do
> this, anwyay.  Code was added to ipfilter to allow exceptions to
> routing to be put in rules, and I'm kind of inclined to leave it
> like that, not as a mechanism for implementing policy based routing.

I have used ipfilter to solve some of the real issues mentioned above,
as special cases, but it is awkward and not always entirely
successful, even ignoring aesthetic concerns.

Anyway, just some pre-coffee ramblings.

--
Dan.
--n8g4imXOkfNTN/H1
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE/9IYREAVxvV4N66cRAhVkAJ95uOBB+GHoxGfWzYFJ10XsBZDl3ACeLsWa
+d26LgG0jZukCKMOHXnAovk=
=vpAi
-----END PGP SIGNATURE-----

--n8g4imXOkfNTN/H1--