From: Steffen Klassert <steffen.klassert@secunet.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH 2/5] ipv4: Kill ip_rt_frag_needed().
Date: Wed, 13 Jun 2012 10:01:52 +0200 [thread overview]
Message-ID: <20120613080152.GN27795@secunet.com> (raw)
In-Reply-To: <20120612.133333.527780673034196147.davem@davemloft.net>
On Tue, Jun 12, 2012 at 01:33:33PM -0700, David Miller wrote:
>
> We can't do exactly as my patch did, because it allows remote entities
> to easily poison PMTU information. All they have to know is that
> there is some UDP or RAW socket open with a certain ID and then send
> forged ICMP to us.
Yes, I know what you mean. But not updating the the cached pmtu
informations results in slow path fragmentation along the path.
Btw. what happens to ipv6 if we stop doing pmtu discovery?
Shouldn't we reduce the packet size to 1280 bytes then?
>
> What we possibly could do is adjust the socket's IP_PMTUDISC_* setting
> from IP_PMTUDISC_WANT to IP_PMTUDISC_DONT in response to PMTU
> messages.
>
I think an application that sets IP_PMTUDISC_WANT explicitly will
rely on the fact that the kernel does pmtu discovery. Changing
the socket setting to IP_PMTUDISC_DONT the first time we get into
trouble makes IP_PMTUDISC_WANT pointless for udp and raw sockets.
Another option would be to change the sockets default setting
from IP_PMTUDISC_WANT to IP_PMTUDISC_DONT (at least for udp and
raw) and do pmtu discovery if an application sets IP_PMTUDISC_WANT.
With this we don't have the pmtu cache poisoning issue as the default.
We would only have it if a sockets sets IP_PMTUDISC_WANT explicitly.
This is not perfect too, but I fear there is no perfect solution here.
next prev parent reply other threads:[~2012-06-13 8:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-11 9:29 [PATCH 2/5] ipv4: Kill ip_rt_frag_needed() David Miller
2012-06-11 11:16 ` Steffen Klassert
2012-06-11 11:20 ` David Miller
2012-06-11 11:28 ` David Miller
2012-06-11 11:42 ` Steffen Klassert
2012-06-11 23:02 ` David Miller
2012-06-12 11:44 ` Steffen Klassert
2012-06-12 20:33 ` David Miller
2012-06-13 4:22 ` David Miller
2012-06-13 8:01 ` Steffen Klassert [this message]
2012-06-13 9:42 ` David Miller
2012-06-13 10:07 ` Steffen Klassert
2012-06-13 10:22 ` David Miller
2012-06-14 5:35 ` Steffen Klassert
2012-06-14 5:42 ` David Miller
2012-06-14 5:58 ` Steffen Klassert
2012-06-14 5:59 ` David Miller
2012-06-14 6:36 ` Steffen Klassert
2012-06-14 6:54 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120613080152.GN27795@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).