netdev
[Top] [All Lists]

Re: IPsec and Path MTU

To: "David S. Miller" <davem@xxxxxxxxxx>
Subject: Re: IPsec and Path MTU
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 18 Jun 2004 09:09:18 +1000
Cc: kuznet@xxxxxxxxxxxxx, jmorris@xxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20040617152216.00a5cec9.davem@redhat.com>
References: <20040616202341.GD29781@ms2.inr.ac.ru> <E1BajZO-0001UK-00@gondolin.me.apana.org.au> <20040617105843.314dfe30.davem@redhat.com> <20040617213130.GB14089@gondor.apana.org.au> <20040617152216.00a5cec9.davem@redhat.com>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.5.1+cvs20040105i
On Thu, Jun 17, 2004 at 03:22:16PM -0700, David S. Miller wrote:
> 
> Right.  I'm sorry, is someone trying to do NFS/UDP over IPSEC?
> My condolences.  :-)

Nope, it breaks TCP as well.  Whether you're TCP/UDP or whatever,
you have to pass xfrm4_tunnel_check_size().  That function uses
an incorrect derivation of the MTU, thus potentially blocking
maximal packets from getting through.

As I said before, this only strikes for certain device MTUs.
So if you're having problems reproducing this, try setting your
device MTU to 1480 (or 1480 + 8x for any integer x).

> More seriously, it is a fringe case.  We do need to handle it,
> but it is no accident that there haven't been very
> many folks complaining about it.

I agree it's not a common problem.  But the reason is not what
you think it is :) It's because the common MTUs 1500, 1492 etc.
are not of the form 1480 + 8x.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email:  Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

<Prev in Thread] Current Thread [Next in Thread>