From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: John Heffner <johnwheffner@gmail.com>
Cc: David Miller <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>,
Eric Dumazet <eric.dumazet@gmail.com>,
steffen.klassert@secunet.com, fweimer@redhat.com
Subject: Re: [PATCH net-next v4 0/3] path mtu hardening patches
Date: Mon, 13 Jan 2014 23:03:56 +0100 [thread overview]
Message-ID: <20140113220356.GL6586@order.stressinduktion.org> (raw)
In-Reply-To: <CABrhC0=CfPxB7rNrA0ukfZyNLuTNSBB2srohr-Yt2b4k6oHWxg@mail.gmail.com>
On Mon, Jan 13, 2014 at 04:50:38PM -0500, John Heffner wrote:
> On Mon, Jan 13, 2014 at 4:28 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > On Mon, Jan 13, 2014 at 04:08:22PM -0500, John Heffner wrote:
> >> Would it be sufficient to allow Linux to be configured in a way that
> >> matches FreeBSD's behavior? (I believe you can do this easily with
> >> stateful firewall rules now, or possibly in the ICMP processing code
> >> with a sysctl switch.) I feel this would be a much cleaner approach.
> >
> > Actually, this is part of this series. The hardened path mtu mode provides
> > exactly that (Patch 3).
> >
> > But because we cannot switch this on by default, I also protected the
> > forwarding path. UDP path mtu discovery has been too long available on
> > Linux and, I guess, a lot of applications, especially running on routers,
> > depend on that.
>
> Perhaps I misunderstood your description of FreeBSD then. It seems
> hard for me to believe that MTU discovery for UDP is broken by default
> in FreeBSD. It was not as of a couple years ago...
I have to admit, I have not tested that. But I could not find an icmp handler
dealing with pmtu updates in the UDP protocol path. Neither did the icmp
layer.
TCP and sctp do handle the PRC_MSGSIZE callbacks and update the path
mtu on the route.
Maybe I overlooked something and I also did not check the history just
their current subversion checkout.
> The nice thing about stateful firewall rules is that they give you
> fine-grained policies over which ICMP messages you want to trust, and
> can filter out messages that don't match "connections" with existing
> state across a wide variety of protocols (including TCP, UDP and
> ICMP).
I really don't like to depend on firewalling to do that. Especially on
big routers one can use the routing table to protect interfaces for
management and thus don't need to introduce stateful firewalling to
realize a secure router setup which could cause performance degradation,
especially with lots of small and shortlived flows (e.g. UDP/DNS).
Greetings,
Hannes
next prev parent reply other threads:[~2014-01-13 22:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-09 9:01 [PATCH net-next v4 0/3] path mtu hardening patches hannes
2014-01-09 9:01 ` [PATCH net-next v4 1/3] ipv4: introduce ip_dst_mtu_maybe_forward and protect forwarding path against pmtu spoofing hannes
2014-01-09 9:01 ` [PATCH net-next v3 2/3] ipv6: introduce ip6_dst_mtu_forward and protect forwarding path with it hannes
2014-01-09 9:01 ` [PATCH net-next v2 3/3] ipv4: introduce hardened ip_no_pmtu_disc mode hannes
2014-01-13 19:25 ` [PATCH net-next v4 0/3] path mtu hardening patches David Miller
2014-01-13 19:35 ` John Heffner
2014-01-13 20:42 ` Hannes Frederic Sowa
2014-01-13 21:08 ` John Heffner
2014-01-13 21:28 ` Hannes Frederic Sowa
2014-01-13 21:50 ` John Heffner
2014-01-13 22:03 ` Hannes Frederic Sowa [this message]
2014-01-13 22:15 ` Hannes Frederic Sowa
2014-01-13 22:48 ` Florian Westphal
2014-01-13 23:18 ` Hannes Frederic Sowa
2014-01-13 22:12 ` 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=20140113220356.GL6586@order.stressinduktion.org \
--to=hannes@stressinduktion.org \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=fweimer@redhat.com \
--cc=johnwheffner@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=steffen.klassert@secunet.com \
/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