netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Maciej Żenczykowski" <zenczykowski@gmail.com>
To: "Maciej Żenczykowski" <maze@google.com>,
	"David S . Miller" <davem@davemloft.net>
Cc: Linux Network Development Mailing List <netdev@vger.kernel.org>,
	Willem de Bruijn <willemb@google.com>,
	Lorenzo Colitti <lorenzo@google.com>,
	Sunmeet Gill <sgill@quicinc.com>,
	Vinay Paradkar <vparadka@qti.qualcomm.com>,
	Tyler Wear <twear@quicinc.com>, David Ahern <dsahern@kernel.org>
Subject: [PATCH v2] net/ipv4: always honour route mtu during forwarding
Date: Tue, 22 Sep 2020 21:51:43 -0700	[thread overview]
Message-ID: <20200923045143.3755128-1-zenczykowski@gmail.com> (raw)
In-Reply-To: <CANP3RGcTy5MyAyChUh7pTma60aLcBmOV4kKjh_OnGtBZag-gbg@mail.gmail.com>

From: Maciej Żenczykowski <maze@google.com>

Documentation/networking/ip-sysctl.txt:46 says:
  ip_forward_use_pmtu - BOOLEAN
    By default we don't trust protocol path MTUs while forwarding
    because they could be easily forged and can lead to unwanted
    fragmentation by the router.
    You only need to enable this if you have user-space software
    which tries to discover path mtus by itself and depends on the
    kernel honoring this information. This is normally not the case.
    Default: 0 (disabled)
    Possible values:
    0 - disabled
    1 - enabled

Which makes it pretty clear that setting it to 1 is a potential
security/safety/DoS issue, and yet it is entirely reasonable to want
forwarded traffic to honour explicitly administrator configured
route mtus (instead of defaulting to device mtu).

Indeed, I can't think of a single reason why you wouldn't want to.
Since you configured a route mtu you probably know better...

It is pretty common to have a higher device mtu to allow receiving
large (jumbo) frames, while having some routes via that interface
(potentially including the default route to the internet) specify
a lower mtu.

Note that ipv6 forwarding uses device mtu unless the route is locked
(in which case it will use the route mtu).

This approach is not usable for IPv4 where an 'mtu lock' on a route
also has the side effect of disabling TCP path mtu discovery via
disabling the IPv4 DF (don't frag) bit on all outgoing frames.

I'm not aware of a way to lock a route from an IPv6 RA, so that also
potentially seems wrong.

Signed-off-by: Maciej Żenczykowski <maze@google.com>
Cc: Eric Dumazet <maze@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: Sunmeet Gill (Sunny) <sgill@quicinc.com>
Cc: Vinay Paradkar <vparadka@qti.qualcomm.com>
Cc: Tyler Wear <twear@quicinc.com>
Cc: David Ahern <dsahern@kernel.org>
---
 include/net/ip.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/net/ip.h b/include/net/ip.h
index b09c48d862cc..c2188bebbc54 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -436,12 +436,17 @@ static inline unsigned int ip_dst_mtu_maybe_forward(const struct dst_entry *dst,
 						    bool forwarding)
 {
 	struct net *net = dev_net(dst->dev);
+	unsigned int mtu;
 
 	if (net->ipv4.sysctl_ip_fwd_use_pmtu ||
 	    ip_mtu_locked(dst) ||
 	    !forwarding)
 		return dst_mtu(dst);
 
+	/* 'forwarding = true' case should always honour route mtu */
+	mtu = dst_metric_raw(dst, RTAX_MTU);
+	if (mtu) return mtu;
+
 	return min(READ_ONCE(dst->dev->mtu), IP_MAX_MTU);
 }
 
-- 
2.28.0.681.g6f77f65b4e-goog


  reply	other threads:[~2020-09-23  4:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23  4:40 [PATCH] net/ipv4: always honour route mtu during forwarding Maciej Żenczykowski
2020-09-23  4:46 ` Maciej Żenczykowski
2020-09-23  4:51   ` Maciej Żenczykowski [this message]
2020-09-23  8:46     ` [PATCH v2] " Eric Dumazet
2020-09-23 14:36       ` David Ahern
2020-09-23 19:02         ` David Miller
2020-09-23 20:18       ` [PATCH v3] " Maciej Żenczykowski
2020-09-24  9:14         ` Eric Dumazet
2020-09-25  2:54         ` David Miller
     [not found] ` <202009240537.PKBbxi6l%lkp@intel.com>
2020-09-24  1:06   ` [PATCH] " Maciej Żenczykowski
2020-09-24  4:21 ` kernel test robot

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=20200923045143.3755128-1-zenczykowski@gmail.com \
    --to=zenczykowski@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=lorenzo@google.com \
    --cc=maze@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=sgill@quicinc.com \
    --cc=twear@quicinc.com \
    --cc=vparadka@qti.qualcomm.com \
    --cc=willemb@google.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;
as well as URLs for NNTP newsgroup(s).