netdev - Re: [PATCH net-next v4 0/3] path mtu hardening patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140113220356.GL6586@order.stressinduktion.org>
Date:	Mon, 13 Jan 2014 23:03:56 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	John Heffner <johnwheffner@...il.com>
Cc:	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	steffen.klassert@...unet.com, fweimer@...hat.com
Subject: Re: [PATCH net-next v4 0/3] path mtu hardening patches

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@...essinduktion.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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html