netdev - Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie option, extend existing struct's

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:	Tue, 17 Nov 2009 14:38:42 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	David Miller <davem@...emloft.net>
cc:	eric.dumazet@...il.com, william.allen.simpson@...il.com,
	Netdev <netdev@...r.kernel.org>, joe@...ches.com
Subject: Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie
 option, extend existing struct's

On Tue, 17 Nov 2009, David Miller wrote:

> From: "Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
> Date: Tue, 17 Nov 2009 14:18:57 +0200 (EET)
> 
> > On Mon, 16 Nov 2009, David Miller wrote:
> > 
> >> From: Eric Dumazet <eric.dumazet@...il.com>
> >> Date: Mon, 16 Nov 2009 23:26:04 +0100
> >> 
> >> > So adding DATA to SYN packets might be problematic for part of our tcp 
> >> > stack. 
> >> 
> >> I can almost guarentee it won't work.  For one thing getting a SACK
> >> response to a SYN+DATA packet will explode quite nicely for one thing.
> > 
> > Now I'm really lost??? How can you get SACKs for that in the first 
> > place since they are either lost or delivered in unison???
> 
> Ideally, you're probably right.
> 
> However, it seems to me that the receiver can do whatever it likes
> with it's receive queue when it's under memory pressure.
> 
> It can chop packets up, partially free bits, and then send a SACK
> block back to you for the parts it tried to free.
> 
> If you'll recall, I wanted to put some tough restrictions into what is
> allowed with SACK so that we could optimize things on the sender side.
> But there was resistence and therefore we have to keep allowing all
> kinds of silly situations, the one we're talking about here merely
> being one of them :-)

Right, but we could be just as crazy and just drop such things and keep 
resending SYN+DATA without any harm?

-- 
 i.