netdev - Re: [net-next-2.6 PATCH v5 5/5 RFC] TCPCT part1e: initial SYN exchange with SYNACK data

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: <4AF98AAE.6000307@gmail.com>
Date:	Tue, 10 Nov 2009 10:45:50 -0500
From:	William Allen Simpson <william.allen.simpson@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
	Joe Perches <joe@...ches.com>
Subject: Re: [net-next-2.6 PATCH v5 5/5 RFC] TCPCT part1e: initial SYN exchange
 with SYNACK data

Eric Dumazet wrote:
> William Allen Simpson a écrit :
>> This is a significantly revised implementation of an earlier (year-old)
>> patch that no longer applies cleanly, with permission of the original
>> author (Adam Langley).  That patch was previously reviewed:
>>
>>    http://thread.gmane.org/gmane.linux.network/102586

> I really tried hard to understand what was going on, and failed, because I dont
> have much time these days...
> 
Thanks very much for your time.

As I just wrote in a previous message, this is the easy part.  It's going
to get much more complicated -- as you know, since I sent you the papers
with 30+ references....


> Lack of documentation maybe ? Some DATA flow could help...
> 
Where should that be?  In the commit messages?


> Please please, cook up elementatry patches to perform one action at a time,
> even if they are not fully functionnal ?
> 
Well, that's what I did with the (now) parts 1b, 1c, and 1d, but somebody
complained that the callers didn't exist yet.


> One patch to be able to send SYN + COOKIE (if we are the client)
> 
> One patch to be able to receive this SYN + COOKIE and answer a SYNACK + cookies (we are the server)
> 
I'll split them.  Remember, I started with a code base previously
submitted, and everything was in one *single* large patch.  I thought
that's what you (Linux folks in general) wanted.


> One patch to ... Receive the ACK from client (if we are the server) and check cookies
> 
> One patch to ...  Send the ACK (if we are the client)
> 
> Patches to receive FIN + cookies
> 
Maybe that's what you are missing, and why you're have difficulty
wrapping your mind around it.  None of that is there yet!

Receive the Ack options from the client is currently part 2.  I've also
lately divided part 2 into 4 sub-patches, although it all has to be
committed at one time:
   2a) extending the TCP option space,
   2b) receiving 64-bit timestamps,
   2c) receiving extended SACKs,
   2d) receiving the cookie pair.
Perhaps that could be split even further, although the order has to
stay the same.  A lot is written, although I gave up updating regularly
as the part 1 process has taken so long....

Send the Ack is currently part 3.

Handling FIN is currently part 4, although it might be split, too.

Handling RST is probably part 5.

Handling transactions was part 4 or 5, but could be a future part 6
instead (although it's rather tied up with both 4 and 5).


> One patch to ... enable the whole thing and setsockopt() bits
> 
Ummm, then there'd be no way to test.  This is TCP we're talking about.
It has to be tested extensively.  This stuff needs to work.  I need the
bits to initiate all the tests....

That's why I like to get all my data structures nailed down first, and
then incrementally add code and test.
--
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