I'm putting this fast track back into "waiting need spec" as the submitter has taken this conversation offline.
If there any members reading this, I'd like them to consider derailing this fast track as, in my opinion, it has become less than obvious (this is the 3rd time to "waiting need spec") due to the requirements and interactions being less than trivial to sort out. Darren Reed wrote: > ... >> | Relative Hooks ordering >> | ======================= >> | Order with Bridging >> | ------------------- > ... >> With regard to bridging, L2 filter works on top of the bridge, >> instead of >> underneath it, as the filtering is based on MAC clients instead of >> the MAC >> instance that the bridge uses. This means in certain cases L2 hooks >> is not >> able to see the actual interface used for transmit or receive, but >> only the >> interface that the network layer believes it's using, as when IP sends a >> packet on one interface, the bridge may end up transmitting that packet >> on another interface - if that's the interface on which the destination >> exists or if the destination is unknown. This is by design as l2 >> filtering >> aims more on controling what packets a VM can send to the wire via >> the data >> link it is using, insted of which physical link the packets actually >> get sent >> out from. > > Let me spell out the issue here: without being able to reliably > associate packets presented by the layer 2 packet events, it is > not possible to use them with bridging to implement a security > device, be it with IPFilter or something else. > > If the packets published by the layer 2 hooks NH_PHYSICAL_IN > and NH_PHYSICAL_OUT do not correspond 100% of the time to the > actual physical interfaces that the packets are sent out on > and received on, what events would? And therefore what should > the packet events being delivered by this project really be > called? > > Darren >
