Yasuyuki KOZAKAI wrote:
Hi, Patrick,
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Sat, 05 Nov 2005 10:55:57 +0100
Also, I thought Yoshifuji-san's objection is not just about
transport mode packets passing through netif_rx twice, but
passing through netfilter twice as well?
I think so, but he didn't mention a reason why he objects to it.
I also don't think it can be done otherwise while still keeping
netfilter "just working" for all cases, which IMO is highly
desirable.
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.
This can be said about output path. The hook for encrypted packet and the one
for pre-encrypted packet is different.
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.
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.
I agree to add new hooks. I think current LOCAL_IN and LOCAL_OUT have
two roles. One is a filter in the IP or the layer 3 and the other is
a filter of the layer 4 such as TCP.
I guess contrack and NAT may work as a filter of the layer 4 even if
they affect IP stack. On the other hand, LOCAL_IN and LOCAL_OUT are used
as a layer 3 filter.
If we keep current LOCAL_IN and put new hook in front of the layer 4 processing,
I think, it will be useful for IPv6 users because we will able to filter a
packet
before and after the extention header processing, which are routing header,
IPsec and
Mobile IPv6 for example.
I can not explain advantage in the output process clearly because the stackable
destination process is too special :-<
BTW, tunnel mode is special case. We can avoid confusing by operation
and so on. For example, using different address for inner and outer header.
We agree to call netif_rx() twice for tunneled packets, as ever.
Regards,
-- Yasuyuki Kozakai
--
Kazunori Miyazawa
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
