netdev - Re: [PATCH net-next] ipv4: introduce ip_dst_mtu_secure and protect forwarding path against pmtu spoofing

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: <20131219235338.GA32129@order.stressinduktion.org>
Date:	Fri, 20 Dec 2013 00:53:38 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	David Miller <davem@...emloft.net>
Cc:	johnwheffner@...il.com, netdev@...r.kernel.org,
	eric.dumazet@...il.com
Subject: Re: [PATCH net-next] ipv4: introduce ip_dst_mtu_secure and protect forwarding path against pmtu spoofing

On Thu, Dec 19, 2013 at 02:30:12PM -0500, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@...essinduktion.org>
> Date: Thu, 19 Dec 2013 13:17:57 +0100
> 
> > Networking software on the end system which wants to guard against
> > that kind of fragmentation can do so by using the various knobs to
> > limit pmtu notification processing or use IP_PMTUDISC_INTERFACE to
> > protect itself from sending fragments.
> 
> And that's part of where my irritation is coming from.
> 
> Applications have to opt-in to this new socket option based behavior,
> but you're making the routing thing default to on.
>
> And even if we default it to off, someone is going to cry and tell all
> the distributions to turn it on in /etc/sysctl.conf, just like they
> did for rp_filter.  And they will.  I don't have the strength and time
> to fight every person who makes these decisions at all the major
> distributions to explain to each and every one of them how foolish it
> would be.
> 
> No end host should have rp_filter on.  It unnecessarily makes our
> routing lookups much more expensive for zero gain on an end host.  But
> people convinced the distributions that turning it on everywhere by
> default was a good idea and it stuck.

Ack.

> I don't want to create a carrot for that kind of situation again.

I see your point. How should we proceed? I definitely see this as a problem.
I just want to point to RFC 1191 "4. Router specification", where it clearly
states that the MTU that should be considered is that of the next-hop network.
And the MTU carried in a fragmentation-needed notification should denote the
size so that the packet is not going to be fragmented at *this* router.

I am fine dropping the knob and just unconditionally ignoring the pmtu data in
the forwarding path? Is that what you wanted to suggest?

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