Darren Reed wrote: > James Carlson wrote: >> Eric Cheng wrote: >>> Link protection is a new feature we are planning to introduce >>> to Solaris and we would like to solicit your feedback >>> on it. Please see attached document for >>> details. >> >> I'd thought that we already had an IP filter simplification and >> automation scheme that's based on SMF. Why not extend that rather >> than inventing a new mechanism? Could these two be merged together at >> some point, or are they just fundamentally different? >> >> With IP filter, I can use ipmon to debug my filter settings. It's not >> unusual that I have to add "log" to my filters to figure out what's >> going wrong when some application stops working. Is there a similar >> capability here? >> >> You mention extensibility as a goal, as well as the use of ACLs. How >> much extension will be needed? Won't extensions to this feature end >> up getting confusing to administrators who have to deal with the >> existing profusion of packet filtering mechanisms (including the one >> in IPsec, and the one in IP filter)? > > And there's the IPQoS one too... > And Crossbow... > 4, and we want to add another, to make 5...
I think you got classification confused with filtering. > But I think your questions raise an important point - is the > architecture being pursued here correct? Correct from whose perspective? Yours, mine, as a server administrator or from a OS that wants to be more than a server OS (specially wants to be a hypervisor for other OSes as well as a good platform for networking functionality). > And by architecture, I mean the big picture, not just whether dladm (or > something else) should be used to control all of the layer 2 features. > > My understanding is that this path is being pursued because proper layer > 2 filtering is perceived as being "too hard" to do correctly (or at > least that's the feeling I get from the current state of things.) > > And because that's too hard, we're looking to do something simpler. Partly. But also from talking to customers and users in the virtualization and network computing space. They expect our layer 2 to function similar to other hypervisors in allowing layer 2 protection and ACLs. Using ipfilter when IP is not even involved (for a virtual machine) is considered *architecturally bad* by most users in this space. So yes, dladm is adding some link protection properties to allow virtualization users to meet there needs (and yes, its a new paradigm that didn't exist before). And ipfilter can still be extended to allow the same behaviour and use the same kernel code but for people who just want L2 protection and ACLs, it meets the needs. Again, not interested in a philosophical debate with you Darren but we did explore other options and don't see anything wrong if someone can set simple link protection and ACLs both from dladm and ipfilter and it uses the same kernel code and interfaces. Forcing people to understand and use IPfilter for everything is too heavy handed. Cheers, Sunay > Except that that something simpler has a real risk of exploding out from > being something simple to something complex if it continues to grow as a > result of further RFEs (because people can do X with ipfilter or > something else and want to do it with the layer 2 filtering in dladm too.) > > If someone asked how to do anti-ip-spoofing in IP today, the answer > would be to use ipfilter - a tool dedicated to doing it properly. Yet > this proposal suggests that it should be done in layer 2, with > suggestions that perhaps DNS should also be protected. What next - will > we use dladm to configure IP addresses on NICs too? > > Eric, I'd encourage you to think about what it means to protect a link > at the link layer and focus on the link layer, not the layers above it. > That's where we need the effort. We don't need a DNS pollution > protection in layer 2. If someone needs that protection then they'll run > a modern, local, caching, DNS server/proxy. Things like this are "known" > entities and in general, people who care about security know how to use > things like this. > > But what's really missing, from this proposal, is the lack of exposure > with pfhooks. Obviously you've found the "right" places in the mac layer > at which to intercept packets for this purpose, so why isn't there an > accompanying section introducing mac layer hooks for layer 2? If you've > got the architecture correct for yourself, then there should be no > problems exposing the intercept locations as hooks for others to use. If > you can't expose the locations you're using to intercept packets as > proper packet filtering hooks, then how can we have any certainty that > your implementation has the correct architecture? > > Darren > > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss -- Sunay Tripathi Distinguished Engineer Solaris Core Operating System Sun MicroSystems Inc. Solaris Networking: http://www.opensolaris.org/os/community/networking Project Crossbow: http://www.opensolaris.org/os/project/crossbow
