netdev - Re: ip_forward_use_pmtu and forwarding to xfrm'ed gre

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]

Date:	Wed, 8 Jul 2015 21:51:56 +0300
From:	Timo Teras <timo.teras@....fi>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	netdev@...r.kernel.org
Subject: Re: ip_forward_use_pmtu and forwarding to xfrm'ed gre

Hi,

On Wed, 08 Jul 2015 19:39:58 +0200
Hannes Frederic Sowa <hannes@...essinduktion.org> wrote:

> On Wed, 2015-07-08 at 19:17 +0300, Timo Teras wrote:
> > On Wed, 08 Jul 2015 17:52:32 +0200
> > Hannes Frederic Sowa <hannes@...essinduktion.org> wrote:
> > 
> > > On Wed, 2015-07-08 at 16:30 +0300, Timo Teras wrote:
> > > If above idea does not work, we could simply add an option to gre
> > > driver to set skb->ignore_df, but I don't like that much.
> > 
> > This is not acceptable. The gre driver has two operating modes: DF
> > and non-DF mode (which is triggered by 'ttl inherit' or 'ttl
> > <number>' option on tunnel creation). The DF mode intentionally
> > sets DF on all tunnel packets so the pmtu is learned and relayed up
> > the stack. In non-DF mode the tunnel packets DF is derived from
> > encapsulated packet.
> > 
> > Basically this info could be used. If the target is gre1 in DF
> > mode, we
> > should be trusting the pmtu. Otherwise the existing internal
> > mechanism breaks.
> > 
> > Thoughts?
> 
> At least we know which interface the packet would leave. Should we
> override this behavior on a per-interface basis?

That would be one option. We could also make the exception just for GRE
interface in the DF mode. Or some sort of per-interface flag that is
set internally by the driver.

> (Although I am in favor of admins just correcting the mtu by hand and
> documenting this as you proposed earlier. I really don't know if it is
> worth the effort to propagate those information.).

The problem with GRE + DF is that the internal packet is no-DF and
potentially fragmented, but the tunneled packets (fragments) do have DF
set. So no interim router can defrag+frag if needed. This means pmtu
must be honored. And on nbma gre tunnels (target tunnel address depends
on encapsulated packet's address) the path mtu needs to be propagated
back to the sender.

In this configuration ip_forward_use_pmtu needs to be enabled (system
wide, per-interface config, or implicitly by interface flags). Or
alternatively the trusted pmtu needs to be propagated via alternate
mechanism. But that might be quite tricky to implement.

I believe other tunnels have similar mechanism. E.g. ipip tunnels seems
to share same DF vs. non-DF mode based on 'ttl' setting.
--
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