From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output Date: Sat, 05 Nov 2005 08:55:44 +0100 Message-ID: <436C6580.6030007@trash.net> References: <4352EEC8.9000602@trash.net> <20051017.094919.56989341.yoshfuji@linux-ipv6.org> <20051027121545.GA5530@gondor.apana.org.au> <20051027.235732.01166239.yoshfuji@linux-ipv6.org> <20051105063030.GA32385@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, netfilter-devel@lists.netfilter.org Return-path: To: Herbert Xu In-Reply-To: <20051105063030.GA32385@gondor.apana.org.au> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netdev.vger.kernel.org Herbert Xu wrote: > On Thu, Oct 27, 2005 at 11:57:32PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > >>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. > > > OK. Would it be workable for you if LOCAL_IN only saw the decrypted > packets without ever seeing the encrypted ones? How exactly would that work? I guess we couldn't do NAT with the encrypted packet anymore? > I'd like to know where the boundaries are so we can find a compromise > that works for everyone. I would prefer something similar to the second set of patches. Instead of calling netif_rx we could use NF_HOOK and simulate the relevant parts of the input path for IPv4 and NAT. This would assure that statistics are still correct and tcpdump is not affected, which were Yoshifuji's biggest concerns if I understood correctly.