James Carlson wrote: >Darren Reed writes: > > ...
>>But the idea of tieing it in with bridging is interesting...how would >>bridging communicate its presence and how would that presence >>be used? >> >> > >There are (or will be) bridge instances, just as there are IP stack >instances. Each one has a forwarding table that has the learned >sources, and we could easily supply an interface that maps from a >given destination MAC address into an output link (of some sort). > >I'm a little puzzled in how or why anyone would be manipulating >forwarding down at this level (it's a little easier to see how someone >would want to bypass IP routing), but I guess it'd be possible. > >It might be better, though, to step back and figure out what sorts of >problems such a feature would solve. Not just what the IP Filter >syntax allows or what could be done with the bridging code, but what >sort of problem a user would be trying to solve with something like >this. > >I'm not too clear on what that'd be. > > Hmm, with IP, the problem is usually when someone wants to do asymetrical or routing that doesn't obey the table. The usual use case is if I've got two links to the internet, DHCP gives me a default route down X but I want t a certain set of traffic to use Y instead. How does this apply to a bridge? Due to the nature of what we're dealing with, ultimately both links (X & Y) need to result in a "connection" with the destination, so it kind of means the links run in half-duplex mode. For people doing cheap packet sniffing, this could be a way of ensuring that neither link ever has more than its full capacity to watch - but that assumes that only one of X & Y is used to receive packets. I could conceive of other scenarios, where you might have a link based network tap attached to one NIC and you select which packets to record on the network tap as a function of which NIC they're sent down, even though that seems unlikely because there is not much use in being able to choose between MAC addresses. Maybe if you were building a wireless access point, where the incoming MAC addresses fit into two bundles: those that you know about and those that you don't. If your wireless access point has down different "down sides", the choice of "routing" you do at the ethernet level might be different because you don't trust the IP layer. That this implies trusting the MAC header is another issue. >>>When I heard "L2 Filtering," I'd expected that we were going to >>>intercept packets at L2, do L3 (and above) filtering on them, and then >>>pass them along -- as in something useful as a stealth firewall, but >>>not quite a statically-routed bridge. Is that right? >>> >>> >>> >>> >>The best solution (for my money) in doing a stealth firewall is >>to marry layer 2 filtering with bridging and I've been pushing >>for this for quite a long time. >> >> > >In that case, I think you really don't need "to" or "fastroute." The >bridge itself learns the destinations and sends the packets where they >go. > >The most important part is to get hooked somewhere in the bridge >forwarding path so that you have a chance to inspect the packets and >do your filtering. (You can get a _little_ more detail on what we're >doing in the RBridge project ON gate, but it's a work in progress.) > > So, my vision of what happens is that we can plugin layer 2 filtering hooks to the MAC layer today, providing inbound and outbound filtering. When the bridging code arrives, it simply provides the "routing" layer that will sit above the MAC layer - no additional hooks are needed to firewall inbound/outbound with IPFilter. We may, however, want to add another hook that is for the packets that the bridge gets and forwards...I'm not sure how that one will work. It maybe that the bridge would add in/out/forward for itself and those would be used instead of the MAC layer filters when that style of operation is exepected/required? >>>I'm not sure what a "MAC header for delivery to 1.2.3.4" looks like >>>... that's an IP address, and it has to be resolved to some local MAC >>>address first. You don't mean taking the ARP-resolved MAC address >>>seen on bge1 and using that on bge0, do you? That seems like >>>surprising behavior to me. >>> >>> >>> >>> >>This was with respect to use with layer 3 rules... >>And yes, if 1.2.3.4 has its MAC address resolved only on bge1, >>using that in the MAC header for sending out bge0. >> >> > >Other than the passive monitoring port I mentioned earlier, I don't >see how doing that is terribly useful. > >What do people _do_ with it? > > Complain when it doesn't work right ? :) Seriously, I've no idea... sometimes I get to deduce things from "help with configuration" questions, but I don't ask too much so as not to push it in case it is security sensitive. It was designed to allow for packet logging to another device that is separate to the device doing the firewalling. So if bge0 gets a copy of all my suspicious packets that I otherwise allow and bge0 is connected to something that does not respond to any packets, what goes down it must not require any ARP, etc. >>Whilst this may not seem to make a lot of sense, it allows the >>ARP cache to be primed with static IP-ethernet mappings and >>for those to work - when using "arp(1m)", there is no way to >>specify which network interface the address is to be used with. >>Whether or not that's a bug, is another matter altogether :) >> >> > >It's a feature gap, in that the stack allows us to set ARP entries >with more information. But I think it's also a bug if you've got to >use that command at all. Static mappings are for the birds; they're >too hard to manage in any real sense. Your first hardware swap or >upgrade will give you a really bad day. > >It's like trying to manage a network with static routes. We're >surrounded by these computers with the ability to figure out how to >talk to each other, and it seems that some are afraid to use that >awesome power or just want to do it all by hand. > > For people who want to build (stealth) firewalls, the desire is to configure everything and leave little to discovery. So static routing is the key, even static population of the ARP table is not unheard of. It might be an anathma to routing folks but...:) If the link to somewhere drops... it drops... Darren _______________________________________________ networking-discuss mailing list [email protected]
