Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
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 - 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
Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
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
Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
Herbert Xu wrote:
On Sat, Nov 05, 2005 at 10:19:51AM +0100, Patrick McHardy wrote:
What I propose is to keep tunnel mode handling as it is, so
for each tunnel mode SA we hit PRE_ROUTING and LOCAL_IN in
the normal packet path. If the final SA is a transport mode
SA, we don't call netif_rx as in my first patchset, but pass
the packet through a new PRE_ROUTING hook in xfrm{4,6}_input
and LOCAL_IN afterwards. The packet won't be processed a second
time by the stack, just the netfilter hooks will be called.
NAT be will be handled manually for IPv4 by doing a new route
lookup and calling dst_input if NAT took place.
In other words LOCAL_IN will still see the packet twice for
pure transport mode packets? That's going to be a problem for
me for the reasons that I outlined earlier:
[EMAIL PROTECTED]
Well, once encapsulated and once decapsulated.
What I propose is actually exactly what you suggested in that mail:
Would it be workable to try something like this? We invoke netfilter
after each tunnel mode transform as we do now. In addition to that,
we invoke netfilter at the very end of IPsec processing, that is,
just before the point where the original xfrm*_rcv_encap would have
returned.
In my last patchset I did it by calling netif_rx at that point,
now I want to add new hooks.
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.
-
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
Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
On Sat, Nov 05, 2005 at 10:55:57AM +0100, Patrick McHardy wrote:
[EMAIL PROTECTED]
Well, once encapsulated and once decapsulated.
What I propose is actually exactly what you suggested in that mail:
You got me there :) I was confused. Yes this is OK with me.
In my last patchset I did it by calling netif_rx at that point,
now I want to add new hooks.
The only problem I can see is that at some point we're probably
going to add an AF_PACKET hook there as well for the pure transport
mode packet so that people can diagnose their transport mode IPsec
problems.
However, I reckon that's still miles ahead of passing the packet
back through netif_rx when we already know that it's still the
same address family as what we started out with.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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
Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
Herbert Xu wrote: On Sat, Nov 05, 2005 at 10:55:57AM +0100, Patrick McHardy wrote: In my last patchset I did it by calling netif_rx at that point, now I want to add new hooks. The only problem I can see is that at some point we're probably going to add an AF_PACKET hook there as well for the pure transport mode packet so that people can diagnose their transport mode IPsec problems. Yes, that would be useful. However, I reckon that's still miles ahead of passing the packet back through netif_rx when we already know that it's still the same address family as what we started out with. Great. I'm moving to a new appartment right now and will be offline until monday. I'll try to get some patches ready until then. Regards Patrick - 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
Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
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. 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 - 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
