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

[Patrick McHardy <kaber@trash.net>]

Yasuyuki KOZAKAI wrote:
> I try to comment based on discussion with Yoshifuji-san and Miyazawa-san.
> 
> We think it's confusing for user to mix decrypted packets and pre-decrypted
> ones to same hook. For example, if user want to accept packets encrypted by
> transport mode ESP and drop others, he will do "iptables -A INPUT -p esp -j
> ACCEPT" and "iptables -P INPUT DROP". But decrypted packets will be dropped
> because of the 2nd command. Of cause the match module 'policy' will be helpful
> in such case, but it's simple if he can different name of hook with INPUT.
> 
> And, in logical, the hook for decrypted packet and the one for pre-decrypted
> packet is different like the current LOCAL_IN and LOCAL_OUT. Their place and
> the packets they can see, are different.

I disagree. LOCAL_IN is for locally delivered packets, and both the
decrypted and the encrypted packet are delivered locally. This is
true for tunnel mode, handling transport mode the same way seem
consistent, not confusing to me. This is also the way klips has
done it for ages and users are used to this and are actually asking
for exactly this behaviour.

> This can be said about output path. The hook for encrypted packet and the one
> for pre-encrypted packet is different.

Well, this is not intended but one of the problems I want to fix.

> In the current, LOCAL_OUT see pre-encrypted packet. I've been assuming
> that LOCAL_OUT see the packets just before sending them from network device.
> This is the reason why I said "I support the way" - which means LOCAL_OUT
> doesn't see pre-encrypted packet.

Same holds here. LOCAL_OUT is for locally generated packets, and should
see both the plain text and the encrypted packet. This is entirely
consistent with other tunnels like IPIP or GRE.

> Meanwhile the hook to see pre-encrypted packet is necessary for NAT
> indeed as you pointed out. Then our suggestion is adding new hook
> with new name, and distinguishing cleary between the usage of new and
> current hook.

We can't do that because introducing new hooks to the tables breaks
userspace compatibility.

Regards
Patrick