Eric Cheng wrote: > On Thu, Jul 09, 2009 at 01:44:29AM -0700, Darren Reed wrote: > >> One way or another, the ultimate goal should be to support l2 filter hooks. >> >> The internal implementation that supports the l2 filter hooks is not if any >> great importance when compared to the external interfaces exposed. >> >> If Erik completely changed the way the internal IP layer hooks were used >> as a part of data path refactoring but kept what's important (the external >> interfaces the same), it would be of no consequence. >> >> One way to read what you're saying is that the crossbow teams intends >> to transform the mac code from being able to support l2 filter hooks to >> a code base that cannot support l2 filter hooks. >> >> > > I answered this partially in my mail to Jim. > but in summary, what I was saying is l2 hooks would require too much > common mac changes to work properly. and as of now, since we know we'll > be evolving the mac datapaths significantly, we are concerned that if > we allow l2 hooks in now, we'll burden ourselves with having to > evolve l2 specific mac changes together with the core mac. > neither subsystem is at fault. it just happens that l2 hooks don't > fit very well with mac. you could still jam all this into the mac > *now* if you want to. it's just that the eventual unwind would be > very painful. >
Well, at some point we will need l2 hooks. I don't see why this should be such a great burden. People have been aware of this since last year... One would hope that the relevant people are aware of this and are taking it into consideration when doing design... I'm pretty sure we will see layer 2 filtering hooks available on all of the other open source platforms (Linux & FreeBSD already do), which will leave us at a competitive disadvantage if we continue to put it off. This kind of thing is a great enabler for 3rd parties to do value added software development. For example, I recently became aware of someone using the pfhooks in Solaris 10 to develop software that does bandwidth limiting (there is no Crossbow for S10, so that vacuum creates a market.) >> Of course there's going to be a performance hit from that because every >> packet will require an extra routing table lookup to find where the >> source address should be found, but at the same time it is dynamic (the >> same rule works with small/simple routing tables, as well as >> large/complex ones) and very easy to configure. Two commands and all of >> the IP networking interfaces are protected against source address >> spoofing. I'm not sure I could make it any simpler than that, except, >> perhaps, to make RPF validation mandatory or automatically turned on >> when a bad-src rule is loaded. >> >> > > what if there isn't a route? > (e.g. you have ipfilter running on the host domain but you want to > antispoof a guest's vnic, in this case host would not have a > route for the guest's vnic) > would you have to resort to using hardcoded rules in the host? > how would you deal with dhcp addresses acquired by a guest (no > route in the host for this case too)? > At present, IPFilter only deals with IP packets, so if packets are bridged or make their way out of the host via some other means, IPFilter won't see them. But by way of illustrating, if you wanted to restrict packets going out a network interface to those that have a matching address, the following rules woud be sufficient: block out on bge0 all pass out on bge0 from bge0/32 to any - that'll work with DHCP or static addresses. Now if you wanted to restrict communication out of bge0 to hosts on the bge0 network, you could do: block out on bge0 all pass out on bge0 from bge0/32 to bge0/netmasked Darren
