netdev - Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility workaround

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080811.144421.234396007.davem@davemloft.net>
Date:	Mon, 11 Aug 2008 14:44:21 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	ilpo.jarvinen@...sinki.fi
Cc:	billfink@...dspring.com, fragabr@...il.com,
	thomas.jarosch@...ra2net.com, netdev@...r.kernel.org,
	kaber@...sh.net, sr@...urenet.de, netfilter-devel@...r.kernel.org,
	kadlec@...ckhole.kfki.hu
Subject: Re: [PATCH] tcp FRTO: in-order-only "TCP proxy" fragility
 workaround

From: "Ilpo_Järvinen" <ilpo.jarvinen@...sinki.fi>
Date: Fri, 8 Aug 2008 13:32:14 +0300 (EEST)

> On Fri, 8 Aug 2008, Bill Fink wrote:
> > A question then arises is if the bogus scenario has a TCP signature
> > that could be used to print a warning message for the unsuspecting
> > user so they could then take necessary corrective action.
> 
> Probably yes, but I need to add some state. I could probably also make it 
> to switch per flow to more robust approach on-demand when enough evidence 
> is gathered. ...I think I'll add 1-bit history counter per flow so that 
> it's possible to do print the warning and switch when there's third RTO in 
> a single window (while two first were found spurious). IMHO it's unlikely 
> enough that there will be three latency spikes (each longer than the 
> previous) within a single window to make the decision, I wouldn't trust 
> two enough because hand-overs can take time and have non-trivial effects.

Trying to come up with a signature for this bogus stuff is both time
consuming and having a risk of false positives.  And I really question
whether this thing is worth it.

The sane thing to do in this case is to declare the box inoperative
and that it needs to be fixed to avoid this behavior.

Any reasonable congestion control scheme is going to run into problems
trying to react to the packet patterns this thing creates.  It is
therefore not really limited to FRTO so it really shouldn't be treated
like an FRTO problem even though it shows up more pronounced when
FRTO is enabled.
--
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