From: Florian Weimer <fweimer@redhat.com>
To: David Miller <davem@davemloft.net>, hannes@stressinduktion.org
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net-next] ipv4: introduce new IP_MTU_DISCOVER mode IP_PMTUDISC_INTERFACE
Date: Tue, 29 Oct 2013 08:36:35 +0100 [thread overview]
Message-ID: <526F6583.4000506@redhat.com> (raw)
In-Reply-To: <20131029.000844.1092862708536984032.davem@davemloft.net>
On 10/29/2013 05:08 AM, David Miller wrote:
> I do not like this reasoning. You have several more acceptable paths to take
> to resolve this problem:
>
> 1) "I don't trust path MTU information at all"
>
> Just turn it off globally, end of story. It has the same effect as your
> new per-application mode.
We can't push this as a security update. We could tell everyone running
DNS servers to reconfigure their systems in this way, but I always
consider this a bit of a cop-out.
A new knob to turn IP_PMTUDISC_DONT into something that behaves like
IP_PMTUDISC_INTERFACE would be more conservative and easier to deploy, I
think.
> 2) "I don't trust path MTU information unless the full socket ID is available
> in the ICMP packets quoted headers"
>
> Then simply implement a policy as such and submit it to me.
There are IP protocols where these bits aren't readily available and
where we don't want the kernel (outside the Netfilter code) to be aware
of the payload structure. Netfilter isn't a solution because it
requires state and doesn't work well with request-response UDP protocols
like DNS (even before source port randomization).
You could make the path MTU dependent on the protocol (which would even
be the correct solution from a technical point of view) and use
validation for TCP and UDP, but that's a fairly invasive change for such
relatively minor functionality.
--
Florian Weimer / Red Hat Product Security Team
next prev parent reply other threads:[~2013-10-29 7:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-26 20:11 [PATCH net-next] ipv4: introduce new IP_MTU_DISCOVER mode IP_PMTUDISC_INTERFACE Hannes Frederic Sowa
2013-10-29 4:08 ` David Miller
2013-10-29 7:36 ` Florian Weimer [this message]
2013-10-29 19:38 ` David Miller
2013-10-29 12:04 ` Hannes Frederic Sowa
2013-10-29 12:50 ` Hannes Frederic Sowa
2013-10-30 20:07 ` Hannes Frederic Sowa
2013-10-30 21:36 ` David Miller
2013-10-30 22:58 ` Hannes Frederic Sowa
2013-10-31 4:29 ` David Miller
2013-10-31 9:42 ` Hannes Frederic Sowa
2013-11-04 23:25 ` Hannes Frederic Sowa
2013-11-05 0:52 ` David Miller
2013-11-05 0:58 ` Hannes Frederic Sowa
-- strict thread matches above, loose matches on Subject: below --
2013-11-05 1:24 Hannes Frederic Sowa
2013-11-06 2:57 ` David Miller
2013-11-06 3:11 ` Hannes Frederic Sowa
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=526F6583.4000506@redhat.com \
--to=fweimer@redhat.com \
--cc=davem@davemloft.net \
--cc=hannes@stressinduktion.org \
--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).