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: <CABrhC0n2AgHNQg-2nQk-sx1=k2=TvmGa+2seqoNT=XyDdz59yg@mail.gmail.com>
Date:	Mon, 13 Jan 2014 14:35:31 -0500
From:	John Heffner <johnwheffner@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	hannes@...essinduktion.org, 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 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
separate management and forwarding interfaces on a router, don't
practically solve this problem.  I'd also be curious to hear what
dedicated routing operating systems do, and why I haven't heard about
widespread fragmentation DoS attacks.

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

  -John
--
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