netdev - GRE non-zero TTL and DF=1

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>] [day] [month] [year] [list]

Message-ID: <20220118213248.GA12520@ICIPI.localdomain>
Date:   Tue, 18 Jan 2022 16:33:04 -0500
From:   Stephen Suryaputra <ssuryaextr@...il.com>
To:     netdev@...r.kernel.org
Subject: GRE non-zero TTL and DF=1

Hi,

I'm trying to pinpoint the exact scenario that is being prevented by the
decision to set DF=1 when the tunnel parameter ttl is non-zero, i.e. in
this code snippet:

int ip_tunnel_ctl(struct net_device *dev, struct ip_tunnel_parm *p, int cmd)
{
	...
	switch (cmd) {
	...
	case SIOCADDTUNNEL:
	case SIOCCHGTUNNEL:
		...
		if (p->iph.ttl)
			p->iph.frag_off |= htons(IP_DF);
	...
	}
	...
}

There is a comment in ip_gre.c that it is to prevent recursive network
loop:

   "One of them is to parse packet trying to detect inner encapsulation
   made by our node. It is difficult or even impossible, especially,
   taking into account fragmentation. TO be short, ttl is not solution at all.

   Current solution: The solution was UNEXPECTEDLY SIMPLE.
   We force DF flag on tunnels with preconfigured hop limit,
   that is ALL. :-) Well, it does not remove the problem completely,
   but exponential growth of network traffic is changed to linear
   (branches, that exceed pmtu are pruned) and tunnel mtu
   rapidly degrades to value <68, where looping stops.
   Yes, it is not good if there exists a router in the loop,
   which does not force DF, even when encapsulating packets have DF set.
   But it is not our problem! Nobody could accuse us, we made
   all that we could make. Even if it is your gated who injected
   fatal route to network, even if it were you who configured
   fatal static route: you are innocent. :-)"

It seems to read that when there is a fragmentation, the inner
encapsulation is lost of non-first fragments, but my problems are:
1) I don't see where the inner encapsulation by the self node is being
   detected.
2) I don't understand how the tunnel mtu can degrades. In the case of
   looping, the mtu stays the same and packet is being recursively
   encapsulated and in the end the packets contain only the headers, but
   it's still looping forever (in the absence of the detection in (1)).
3) If (1) exists, then I think the looping is finite, e.g. eventually
   the node that tunnels will detect itself even in the presence of
   fragmentation because the non-first fragments is GRE encapsulated by the
   self node again.

Any example topology and scenarios that can shed lights into what the
comment concerns about? What am I missing?

Thanks,
Stephen.