netdev - Re: [PATCH 5/5] tcp: skip cwnd moderation in TCP_CA_Open in tcp_try_to

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: <alpine.DEB.2.00.1111291135510.31705@wel-95.cs.helsinki.fi>
Date:	Tue, 29 Nov 2011 12:33:12 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Yuchung Cheng <ycheng@...gle.com>
cc:	Neal Cardwell <ncardwell@...gle.com>,
	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>, nanditad@...gle.com,
	therbert@...gle.com
Subject: Re: [PATCH 5/5] tcp: skip cwnd moderation in TCP_CA_Open in
 tcp_try_to_open

On Mon, 28 Nov 2011, Yuchung Cheng wrote:

> On Mon, Nov 28, 2011 at 9:35 AM, Neal Cardwell <ncardwell@...gle.com> wrote:
> > On Sun, Nov 27, 2011 at 7:01 PM, David Miller <davem@...emloft.net> wrote:
> >> I'm apply this patch to net-next now, but Neil and Yucheng are on the hook
> >> to fully look into the issues Ilpo has raised.
> >
> > Thanks! We will spend some time looking into these issues.
> >
> Ilpo do you know any report on these types of cheating? I did some
> literature search but didn't find any.

No I know of, however, I'm not too surprised as so far such attacks have 
lacked a target at least among Linux endhosts. It is only possible to gain 
something now after you have one by one removed all safeguards which 
prevent such misuse :-). This possibility is certainly known to exists 
(even RFC3708 mentions it).

Besides, DSACK adoption, not to speak of adoption of any DSACK undo 
algorithm, is not that high as with SACK alone iirc.

> If the receiver simply responds DSACK on good (non-spurious)
> retransmits, the sender may increase dupthresh (tp->reordering) and
> slows down triggering fast-recovery? given the connection has real
> losses, the receiver may end up shooting his feet.

For some attack variants, yes. However, it is always "safe" to attack 
the current Linux sender with something that is past the acknowledgment 
number, there's only dummy counting done for that (trivial to arrange). If 
the attacker plays safe, no tp->reordering effect is ever imposed but 
attack eventually succeeds to hit the right number of undo_retrans no 
matter what if one keeps trying. This is what you just asked us to 
enable, unlimited attack window! Perhaps we could add a penalty of 
misguessing the number of rexmits but knowing the right number is not that 
hard anyway (and some caveats exist in such approach though to those who 
are hit by HW/path duping).

Btw, another thing that should be auditted now that this was applied: 
check that undo_marker checks do not behave bad due to 32-bit seqno 
wrap-arounds since its needs-to-be-valid period got just extented way 
beyond a single loss event.

-- 
 i.
--
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