Re: [tcpm] SYN/ACK Payloads, draft 01

Joe Touch <touch@ISI.EDU> Fri, 22 August 2008 17:06 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 3D3933A68E6; Fri, 22 Aug 2008 10:06:50 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99C123A6965 for <>; Fri, 22 Aug 2008 10:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yv4+AEH006CZ for <>; Fri, 22 Aug 2008 10:06:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ACB733A68E6 for <>; Fri, 22 Aug 2008 10:06:47 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m7MH5T2b026281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Aug 2008 10:05:32 -0700 (PDT)
Message-ID: <>
Date: Fri, 22 Aug 2008 10:04:32 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <>
References: <> <> <> <> <> <> <> <> <> <><> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: Adam Langley <>,
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hash: SHA1

Hi, Ananth,

Anantha Ramaiah (ananth) wrote:
> <snip>
>>>> I'm wondering why an implementation in user space would expect to 
>>>> find out anything about a TCP connection that hadn't finished 
>>>> handshaking, i.e., the accept call above
>>> This has been done in some stacks today (like ours). The 
>> incoming SYN 
>>> is reported to the application and the application can 
>> suggest whether 
>>> or not to accept the connection. If the application gives a nod, 
>>> proceed with the 3 way handshake else send an RST.
>> Does the app have access to the SYN options? If so, that 
>> seems outside the scope of what TCP should be exposing to the app.
> Ok, currently we don't pass TCP options upwards, we just pass the 4
> tuple (may be 5 tuple if you include VRF's) to the application. The
> application can decide whether to move forward with this connection or
> not. This is simply the access control at the application level for the
> incoming SYN.

That's roughly equivalent to having better resolution of listen() calls,
which seems OK.

(what's a VRF?)

>>> This is different from a 3
>>> way handshake happening (which involves the TCB and the associated 
>>> baggage creation) and then informing the application and 
>> applications 
>>> can reject this connection during accept(). Applications wishing to 
>>> use this special property would set a socket option indicating the 
>>> notification of SYN when the listener is created.
>>> The advantage is that you don't allocate the memory ahead 
>> of time if 
>>> the application isn't interested in accepting this connection.
>> It seems to me the app already sufficiently controls this in 
>> how/when it issues a accept(). On what basis is it making the 
>> rejection at the time of a SYN? (if by IP address, it could 
>> have done this via a different
>> listen() call).
> 4 or (5 tuple) mainly IP adresses and VRF since dest port and src port
> aren't of much help.. you could push the access control below, but if
> you want to factor in other application factors which could vary from
> application to application (like say # of connections etc.,) then it
> seems expedient to do the check at the application level. Consider the
> case where TCP is library linked to the application and it could
> register a callback to be invoked with the 5 tuple and accept/reject the
> connection synchronously which is efficient in terms of resource
> utilization, i.e, you drop the SYN once it is determined that it is
> "useless" rather than waiting the 3 way handshake to complete. At the
> least, it comes across as an optmization, but YMMV.

These sound like more sophisticated interfaces to the OS, in terms of
how deep to listen for calls, what patterns of ports/addrs to listen
for, etc. Although they're not implemented in the OS, they could be. The
fact that you're implementing them at the app layer isn't a big issue,
and can certainly be easier or a performance win, depending on the system.

This doesn't sound like the issue I'm concerned about - i.e., using
information that circumvents the TWHS.

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

tcpm mailing list