| To: | Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [RFC/PATCH] "strict" ipv4 reassembly |
| From: | Patrick McHardy <kaber@xxxxxxxxx> |
| Date: | Wed, 18 May 2005 01:36:47 +0200 |
| Cc: | "David S. Miller" <davem@xxxxxxxxxxxxx>, akepner@xxxxxxx, netdev@xxxxxxxxxxx, Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx> |
| In-reply-to: | <20050517232828.GA26894@gondor.apana.org.au> |
| References: | <E1DYAHF-0006qW-00@gondolin.me.apana.org.au> <20050517.151352.41634495.davem@davemloft.net> <20050517230833.GA26604@gondor.apana.org.au> <20050517.161641.74747565.davem@davemloft.net> <20050517232828.GA26894@gondor.apana.org.au> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2 |
Herbert Xu wrote: > On Tue, May 17, 2005 at 04:16:41PM -0700, David S. Miller wrote: > >>Good point, in both cases what ends up happening is that >>the queue is invalidated. In the existing case it's usually >>because the final UDP or whatever checksum doesn't pass. >>With your idea it'd be due to the artificially deflated timeout. > > > It just occured to me that the optimisation in IPv4/IPv6 that performs > fragmentation after tunnel-mode IPsec is fundamentally broken. It > makes IPsec vulnerable to fragmentation attacks. You mean vulnerable at reassembly time? Isn't that something reassembly and policy checks should take care of? Regards Patrick |
| Previous by Date: | Re: [RFC/PATCH] "strict" ipv4 reassembly, Herbert Xu |
|---|---|
| Next by Date: | Re: [RFC/PATCH] "strict" ipv4 reassembly, Herbert Xu |
| Previous by Thread: | Re: [RFC/PATCH] "strict" ipv4 reassembly, Herbert Xu |
| Next by Thread: | Re: [RFC/PATCH] "strict" ipv4 reassembly, Herbert Xu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |