David S. Miller wrote:
On Fri, 18 Mar 2005 20:11:29 +1100
Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
BTW Patrick, how is the IPsec netfilter stuff going?
That boy is seriously backlogged, so I'm not sure how much time
he's gotten to work on that yet.
Indeed, but in case of the netfilter patches that's not the problem.
They are basically working fine, but I have doubts about submitting
them. First, and most importantly, the input patch is incredible ugly.
To recap, we want to pass the encapsulated packets to the netfilter
hooks, then again the decapsulated packets after all decapsulation has
been done. The current input patch makes packets that have been
handled by IPsec skip the netfilter hooks until we know no further
IPsec processing will be done (route is non-local or protocol handler
is not marked as xfrm_prot). The packet is then marked as completely
decapsulated and passed through the stack again and the plain packets
go through netfilter again. There are a couple of problems with this
- decapsulated tunnel-mode packets go through the stack twice
- netfilter only sees them once, everything else multiple times
(statistics, packet sockets, ...)
- racy, xfrm protocol could be registered after we determined
decapsulation is done.
The second reason is that I'm not sure at all wether this is the way
to go. With KLIPS-like IPsec-devices you can sniff the plain packets
before they are handled by IPsec and you can perform traffic shaping
on them. These two points are completely unhandled, and people seem
to want them.
So what's holding back these patches is getting some consensus on what
exactly we want to do and finding a better method for determining when
decapsulation is done. One possibility would be stealing packets
in xfrm_policy_check(), but I haven't thought much about this yet.