On Wed, Jul 08, 2009 at 11:52:46PM -0400, James Carlson wrote: > > (Does this mean that the L2 filtering project is dead? There's probably > some administrivia at both the OpenSolaris and the PSARC level if so.) >
no, it's not dead. it's just lower priority on our list at the moment. > >2. if I remember correctly, the l2 filter hooks were intended to be > > stable interfaces. but unfortunately the mac interfaces they had to > > consume were/are far from stable. we (the crossbow team) have plans > > for further, potentially non-trivial changes to the mac datapaths. > > allowing l2 filter hooks to consume these private interfaces could > > severely constrain what we can do. > > That doesn't make sense to me. > > It's perfectly reasonable (and indeed _expected_) for an interface that > provides stable interfaces to use private interfaces as part of its > implementation. It's a good thing, because that layer mediates between > the stable consumers and the unstable bits within the implementation. > > However, I do see your point that even a "good" stable interface could > constrain the evolution of any inadvertently exposed underlying > artifacts. I didn't recall seeing that anywhere in the L2 filtering > proposal, but I suppose it's possible. > that's what I was trying to get at. whether l2 hooks were stable was not the issue. I was just uncomfortable with the way l2 hooks were attached to things that were not meant to be exposed. I don't want to digress too much; but the l2 implementation had to add 1k+ lines of mac code just to loosely "glue" itself to mac. this was not function pointer flipping but involved changing common mac structures, adding global tables that were useless for everything but ipfilter. we found out about this during code review and could have reluctantly accepted this had the owner stayed. again, this is just an FYI, so don't dwell on this too much. > As an aside: does anyone know when the MAC interfaces are going to be > made more stable? This seems like a relatively important thing. In > fact, based on the driver work I've seeen, it appears to be something > that some vendors seem to be assuming has _already_ happened. > the mac interfaces I mentioned are mac client interfaces. they are meant to be used by other gld related modules, kernel clients..etc. but these are not meant to be made public, at least not in the short term. the mac driver interfaces, although still private, are quite stable and we do have plans to officially make them public soon. Nicolas did send out the gldv3 interfaces document for review a while back. > >3. ease of use and performance are of concern to customers too. with > > this new link property based scheme. you need at most 2 commands to > > setup link protection (one for enabling a protection type, another > > for configuring the accompanying ACL). the same cannot be said for > > setting up ipfilter. discounting what's needed to enable ipfilter > > and to understand the rules syntax, my guess is you'll need to add > > more than a few rules to support something seemingly simple as > > IP antispoof. what about performance? while I cannot claim that the > > built-in scheme has zero-cost, it is a certainty that ipfilter would > > perform significantly worse. > > I'm not on board with that answer. First of all, configuring per-link > IP filter entries is both easy and results in at last scalable > performance characteristics. Anti-spoof should be one line per > interface at most, and could easily be trimmed down by simple (and > generically useful) feature additions to the existing system. If I want > anti-spoof mechanisms, and I'm already using IP Filter to protect my > system (due to limitations in other subsystems, such as RPC), I > shouldn't have to reach too far to get those features. > let's say ipfilter can do all that and more. it doesn't mean it has to be *the* solution, right? why can't the user choose a less capable alternative like the one proposed here or a third party filtering package? > However, if full-featured filtering doesn't perform well enough for an > important application, and if that's what's driving this, then I view > that as an OS level defect. It's something that must be fixed. As a > user, I simply don't care a whit whether it's in the "IP Filter" > subsystem or the "Crossbow" subsystem. It's all Solaris, and it'd > better all work well, or I'll replace it with something that does. > > Abandoning and working around parts of the system that are too slow to > use isn't a good answer to me. It just means I'll run into those > limitations a few steps further down the road, or be forced into dealing > with a hodge-podge of partial solutions. > no, we are not abandoning or working around anything here. the original focus of the proposed scheme has been on l2, in particular, to protect the network from untrusted guest VMs. it just so happens that some basic l3 functionality (ip anti-spoof) could be included as well at very little cost. the fact that this performs better than full-blown ipfilter is a nice side benefit but not a primary goal. I understand the appeal of a generalized, one size fits all, solution. but realistically we have to weigh whether achieving this idealized goal is worth holding up urgent customer needs. eric
