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: <20140113204253.GI6586@order.stressinduktion.org>
Date:	Mon, 13 Jan 2014 21:42:53 +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 02:35:31PM -0500, John Heffner wrote:
> On Mon, Jan 13, 2014 at 2:25 PM, David Miller <davem@...emloft.net> wrote:
> > From: hannes@...essinduktion.org
> > Date: Thu,  9 Jan 2014 10:01:14 +0100
> >
> >> After a lot of back and forth I want to propose these changes regarding
> >> path mtu hardening and give an outline why I think this is the best way
> >> how to proceed:
> >
> > I'm not going to fight this any more even though I still disagree with
> > these changes.  John Heffner has not provided a coherent strong
> > argument for not doing this, in fact the counter arguments were
> > extremely vague.
> >
> > I am pretty sure that now my worst fears will be realized and every
> > single distribution will not use the kernel's default, and everyone
> > will get this behavior rather than adminstrators making well informed
> > decisions about how to defend against these kind of situations when
> > enabling routing, or whether they'd even be exposed to the issue at
> > all in a particular setup.
> >
> > Such is life.

:/

> My only comment would be not to look to me as the only source of
> reason not to include this change.  I've been largely disconnected
> from Linux development for several years and don't have time to get
> into a protracted discussion on this topic.
> 
> FWIW, I still have doubts as to whether this is the best approach to
> solving the underlying problem.  I still haven't heard any reason why
> firewall rules and other administrative best practices, such as using

Because we currently cannot easily filter icmp payloads and check whether
it is in a response for a local socket or a malicious one.

> separate management and forwarding interfaces on a router, don't
> practically solve this problem.

I don't think this is practiable, especially in times of small devices
doing routing (e.g. smartphones).

> I'd also be curious to hear what
> dedicated routing operating systems do, and why I haven't heard about
> widespread fragmentation DoS attacks.

My old Cisco didn't honour those pmtu packets (at least in default
configuration) and FreeBSD only accepts pmtu information for TCP sockets
where it also verifies the sequence number. It does not react to pmtu
notifications in response to icmp or udp payloads.

Routing path does use the pmtu values on FreeBSD, though. But it is much
harder to inject path mtu packets there because, as said, they are only
accepted for tcp.

> That said, this probably won't deeply break anything, but adds yet
> more complexity in the core of the network stack...

Actually I feel a bit emberrased how these changes went in. At first I
thought they wouldn't be that much of a problem. I'll try to improve my
communiation skills and try to listen more carefully.

Thank you, David and John!

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