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: <20131218.173442.336109133942416102.davem@davemloft.net>
Date:	Wed, 18 Dec 2013 17:34:42 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	hannes@...essinduktion.org
Cc:	netdev@...r.kernel.org, eric.dumazet@...il.com,
	johnwheffner@...il.com
Subject: Re: [PATCH net-next] ipv4: introduce ip_dst_mtu_secure and protect
 forwarding path against pmtu spoofing

From: Hannes Frederic Sowa <hannes@...essinduktion.org>
Date: Sun, 15 Dec 2013 03:23:36 +0100

> While forwarding we should not use the protocol path mtu to calculate
> the mtu for a forwarded packet but instead use the interface mtu.
> 
> We mark forwarded skbs in ip_forward with IPSKB_FORWARDED which was
> introduced for multicast forwarding. But as it does not conflict with
> our usage in unicast code path it is perfect for reuse.
> 
> I moved the functions ip_sk_accept_pmtu, ip_sk_use_pmtu and ip_skb_dst_mtu
> along with the new ip_dst_mtu_secure to net/ip.h to fix circular
> dependencies because of IPSKB_FORWARDED.
> 
> Because someone might have written a software which does probe
> destinations manually and expects the kernel to honour those path mtus
> I introduced a new per-namespace "forwarding_uses_pmtu" knob so someone
> can disable this new behaviour. We also use mtus which are locked on a
> route for forwarding.
> 
> Cc: Eric Dumazet <eric.dumazet@...il.com>
> Cc: David Miller <davem@...emloft.net>
> Signed-off-by: Hannes Frederic Sowa <hannes@...essinduktion.org>

Sockets aren't the only entity that create cached PMTU information
we might like to use during forwarding, tunnels do too.

I'm afraid what the side effects of this change will be in that
situation, because the dst_mtu() is exactly what will allow us
to relay the ICMP back to the pre-decapsulation source address
properly.

In any event, this code was made to explicitly behave this way
back in 2007 by John Heffner, maybe he has some opinions too.
--
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