[NF+IPsec 4/6]: Make IPsec input processing symetrical to output

[Patrick McHardy]

YOSHIFUJI Hideaki / $B5HF#1QL@ wrote:
> In article <20051027121545.GA5530 at gondor.apana.org.au> (at Thu, 27 Oct 2005 22:15:45 +1000), Herbert Xu <herbert at gondor.apana.org.au> says:
> 
> 
>>On Mon, Oct 17, 2005 at 09:49:19AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>>
>>>Stack should process the packet just once if it is of transport mode.
>>>(It is okay to process one twice if it is of tunnel mode.)
>>
>>Thinking about this again, I'm not sure that I agree.
>>
>>OK, I don't actually care whether we process it once or twice for
>>pure transport mode, but I think that it is absolutely essential
>>that LOCAL_IN/LOCAL_OUT see the decapsulated packet instead of
>>the encrypted version.
> 
> 
> Well, I really care.
> I strongly believe that we SHOULD NOT mix encrypted
> packets and plain text packets at the same hook.
> e.g. LOCAL_IN is NOT for decrypted plain text packets,
> but for the original encrypted ones.

It is in tunnel mode. LOCAL_IN is for all packets that are
locally delivered, independant of encryption. Using new
hooks for decrypted transport mode packets is inconsistent
IMO.

> I believe that we should have another set of hooks
> after decryption (other than LOCAL_IN) if we want to
> look inside the encrypted packets.

This isn't possible without adding completely new tables since
we can't add new chains to existing tables without breaking
userspace compatiblity. If we want existing functionality to
continue working we would need an "xfrm" version of the raw,
mangle, nat and filter table and need to change conntrack (and
possibly NAT) to use the new hooks. Rerouting after NAT (with IPv4)
won't work if we don't pass the packet through the stack again.
I think adding new hooks has too many drawbacks compared to simply
sending the decrypted packet through the stack again.