Re: Thinking about "branes" for netbsd...

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 4 May, 2012, at 01:43 , David Young wrote:
> The general idea is to have more than one forwarding domain per router.
> Belonging to each forwarding domain are the routes for that domain and
> some interfaces.  Each route/interface can belong to just one domain.

Okay, but maybe I can reword what I understand this to say in terms that
(to me) more clearly describe mechanism.  It would be possible to configure more
than one route table for a protocol, with routes being added to, changed
deleted from each table independently.  This actually requires replication
of several address-bearing structures in addition to the route table (e.g.
tables for PCB lookups), so let me call this group of structures a "routing
instance".

The basic configurables around this are that each interface (or "interface",
for some logical definition of this) in the machine running this network
protocol needs to be told which of these tables it should use to route
incoming packets, with the interface routes generated as a side effect
of address configuration on that interface being stored in the same table.
In addition, each open socket needs to be configured (or somehow come to
understand) which table it should use to route outbound packets and
which "routing instance" its socket binding should be stored in.  The
collection of a routing instance, the interfaces configured to forward
packets through and install routes in that routing instance and the
sockets which are using the instance are what I think you are calling
a "domain".  Beyond this, what each of these routing instances does that
is "special" is defined by the routes installed in each table, and perhaps
the filters operating around the table.

> Packets cannot cross from one forwarding domain to another except by
> going through an interface.

And this is a place where I stumble.  If you want to implement a
policy which prevents packets from crossing from one domain to another
except by going through an interface (and if I understand what that
means), why is it not sufficient that you can configure each of these
tables with routes which only route packets from one domain to the other
via an interface?  Why is it necessary to go the extra step and prohibit
someone else from installing a route in one table with a next hop which
directly routes out an interface whose inbound packets are forwarded via
another table (i.e. an interface in another domain), if that is what is
required for that someone else to get their work done?

The last question isn't rhetorical, either, since I know there are some
VRF operations which require routes to be installed which work exactly
like that (i.e. the next hop sends packets out an interface which is not
part of the VRF the route is installed in) and I know there are other
VRF operations where the result of one route lookup is to make it
immediately do another route lookup in another table.  By not stopping
at "I can configure this policy", but rather going all the way to
"No other policy can possibly be configured" I think you make the
mechanism less generally useful and I'd sort of like to see the
justification for that.

> ISTM that a process may have (or may not) several privileges that
> pertain to forwarding domains.  It may have a create/destroy-domain
> privilege.  It may have privileges on more than one domain for the
> purpose of examining/setting both routes and interface configuration.
> It will have privileges to socket()/bind()/connect()/send()/recv() on
> zero or more domains, and one domain (ordinarily the 0th domain) will be
> its default domain.

Note that the traditional privilege model for the network stack is that
processes running as the superuser are allowed to configure whatever can
be configured while other processes, with some constraints, are allowed
to look at and use the configuration the superuser has provided.  I get
that this might not work well for some arrangements, and there might be
other good ways to slice and dice this, but the traditional privilege
model does still work for a lot of things.

I can see the possible need to constrain certain operations in association
with a non-traditional privilege model, but I don't think it is wise to
do this by placing constraints on what the superuser can do when running
in the superuser-can-do-anything-it-wants traditional model.  Starting with
the most unconstrained implementation of multiple routing tables that can
be justified by its implementation costs (i.e. if there are to be constraints
it should be because those things are expensive or otherwise hard to do)
and only paring this back when the privilege policy actually implemented
suggests that certain things are unwise to allow.

Dennis Ferguson