[Sorry for not responding sooner.]
Darren Reed wrote:
> An issue with the design I brought up with Yukun, before I left
> China, that doesn't seem to have been addressed in the current
> code is that it is not possible to selectively apply the global
> zone filtering policy to zones with an exclusive stack instance.
Yes, we talked about this. I don't know if you were cc'ed (and I can't
find those emails - I have just too many places to look).
> As it stands we currently have two scenarios with SI:
> 1) shared stack instances where filtering is done in the global
> zone
> 2) exclusive stack instances where filtering is done "in" the
> local zone
>
> With (2) it is not possible for the administrator of a machine to
> specify a machine policy whilst delegating network control to
> a local zone. I'd consider this a serious design flaw that needs
> to be fixed with a knob that is either on or off for each stack
> instance that tells IPFilter whether or not to run the global
> zone policy before/after the local zone policy. Running the
> global zone policy before/after the local zone policy isn't
> something that everyone will want to do, but I'll put money on
> it being high on the wanted list very quickly if you leave it out.
>
> What needs to happen for exclusive stack instances is:
> packet inbound --> global zone policy? --> local zone policy --> kernel
> packet outbound --> local zone policy --> global zone policy? --> nic
I think this is a capability that we should move towards.
But first of all, the IP Instances project doesn't need this capability
in order to solve the current need; the pressing need is to ensure
IP-level separation when different zones are connected to different LANs
or different VLANs. In that case it is sufficient to give each zone the
same ability to send and receive packets as a separate server that is
connected to the same LAN or VLAN.
But for other applications having the global/machine admin be able to
put a filter between the zone/container/domain and the Ethernet wire is
a useful capability. I think this is useful with zones as well as with Xen.
For that reason I think the best approach to do this is to have IP
Filter hooks in GLD, since that is the common code path that is used in
and out of the machine whether we use IP Instances for virtualization or
Xen.
And it seems simpler than maintaining two sets of policies inside a
single instance of IP Filter and track who can change which policy set.
Erik
