Erik Nordmark wrote: > > [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).
No, I don't believe I was....I wasn't aware that any discussion had been had as a followup. >> 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. I would have liked to have seen this gap filled with the delivery of stack instances but you don't see it as a pressing need? The use-case model that we got a lot of questions about was when people wanted to consolidate servers from a real network into a single box, there was no way to control what happens between zones. Moving to stack instances and delegating root authority to groups that aren't necessarily trusted, we're perpetuating the same problem whereby we're losing the ability to enforce a network security policy on the "host" in question. Or to put it more clearly, if I today have 2 boxes connected via a firewall, if I consolidate them onto 1 host with zones then I need pfhooks to bring the firewall into the hosting server. Roll the clock forward, if I give each of those two zones its own stack instance, that firewall capability disappears. > 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. Agreed. I suppose we need to consider how severe is this problem and is it worth holding up SI in order to solve it or can it be put off until later. > 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. Are you saying here that the current hooks should be moved from inside IP to be inside GLD? Or to add additional hooks in GLD? And when you say inside GLD, do you have any thoughts on if it should be inside the MAC code or inside the DLS code? > 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. My view here was that there would be a single instance of a global policy that could be selectively applied to a zone that has an exclusive stack instance. The view that I'm using here is that the global zone is more of a provider of services to the individual zones than an actual machine itself. Darren
