James Carlson wrote: > Eric Cheng wrote: <SNIP> >> 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? > > The point I'm making is that it seems to me to be a fairly rare thing to > be worried about MAC address spoofing in particular but not worried > about other aspects of network protection. > > For instance, I don't want my clients emitting routing protocol packets > or attempting to provide certain services on my network -- such as being > a rogue DHCP server -- or cutting off use of particularly sensitive > (SNMP) or just plain obnoxious (WINS) protocols. Filtering that stuff > away requires much deeper inspection than what's being proposed here. > (And may get fairly complex: for instance, allowing outbound RIP Query > and inbound RIP Response messages would be quite sensible, while I'd > obviously want to block at least outbound Response. Knowing the > difference between these takes more than IP Filter has today.)
Refer to Erik's suggestion, my reply and the documents pointed to in the earlier email. Between MAC spoofing and allowing selective ethertypes, lot is achieved based on today deployments and people who use it. Most of what we are doing right now in Crossbow land is driven by the deployers. >> >> 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. > > The other side of that equation is how it holds up to the test of time, > and how likely it is that this solution will actually be usable by the > intended audience -- that is to say, whether it's really "complete." > I think thats how we are progressing. The Phase 1 was beta tested by two dozen odd customers in various industries some of them started using it in production already. We are taking the input from them in making the usability better and helping the adoption. At the same time, the valuable feedback from community members who help write some of the code is much appreciated and we try to balance the two and keep making forward progress. We will discuss this next week and see if the ACL parts can be simplified more to make it easier. Will post an updated proposal soon. Cheers, Sunay
