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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
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.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiu8aAACgkQE5f5cImnZrvBnQCeLXfhXFIEorj3q4an2jNwDt4E
b2gAoNfIwAOSFxc8uS0AC5EI7R5FTAaK
=+u5G
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm