James Carlson wrote:
- If this project is right, and the Hooks Framework is not general
enough to solve this problem, then it's certainly fair to ask why
that should be so. It seems, at least at first blush, that
anything that can filter packets ought to be also functional
enough to simply _observe_ them. If that's not true, it'd be nice
to know why. This would likely end up as advice to management.
My take is that there are two things going on here for the various
callouts from the IP code paths.
One is whether there is a small set of places where the callouts happen,
or whether each "function" ends up wanting access to packets at slightly
different places in the IP stack.
The second is whether we want all those callout locations to support the
richest semantics.
For the first item, for the set of callouts we have (IPsec policy
lookup/enforcement, IPsec application of encrypt/decrypt, IPQoS
classification, IPQoS queueing/dropping, IP Filter drop/allow, IP Filter
NAT, IP observability), is that there isn't a lot of commonality for
their placement; maybe a few of them need to be at exactly the same
place in the stack.)
Looking at the second item, there can be different environmental impact
statements for a hook in terms of the impact on the code in IP which
calls the hook. This ranges from the simplest to the hardest as:
- just do observability - some code which looks at the packet (and
perhaps copies it). IP just calls this hook and moves on.
- above + allow/drop. IP calls the hook and checks some return value
whether the packet was dropped or not.
- above + optional queuing. IP calls the hook, but also need to
provide some indication of where to resume processing when the packet is
dequeued.
- above + optional rewrite. On return (or resume after dequeue) the
packet headers might be different. This requires some re-evalution of
other parts (IRE lookup, re-classification).
I don't think it makes sense to have 7 generic transmit and 7 generic
receive hooks that can all do the most complex operation.
For instance, I think it makes more sense to have explicitly designed
hooks for a specific purpose. If we can place the rewrite capability
closest to the wire, then the impact of re-classification is minimized.
As things stand today, there is no one, generally-available, generic
framework for packet inspection. Every project to date places its own
hooks into IP, sometimes labels them as yet another "generic
solution," and then drives on. That alone is worth some advice.
The solution to that might be to not claim that any of them are generic.
If it turns out that two hooks end up in the same place, then we can
collapse them into one hook.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
