Message-ID: <487BD791.4020203@isi.edu>
Date: Mon, 14 Jul 2008 15:47:45 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?S=E9rgio_Freire?= <sergio-s-freire@ptinovacao.pt>
References: <20080714121424.GA31382@ikr.uni-stuttgart.de>
 <396556a20807140648lb5f923x478665473667d807@mail.gmail.com>
 <487B6A79.2040608@isi.edu> <487B6EB1.6040308@isi.edu>
 <711EBBFA1DE9C64FB3CF8053A261C6FC05199B25@INOAVREX05.ptin.corpPT.com>
In-Reply-To: <711EBBFA1DE9C64FB3CF8053A261C6FC05199B25@INOAVREX05.ptin.corpPT.com>
Cc: andre.zuquete@ua.pt, tcpm@ietf.org
Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs?
Precedence: list
Content-Type: multipart/mixed; boundary="===============0366703310=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0366703310==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig1B2523492885B0E0ECE2DFB7"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1B2523492885B0E0ECE2DFB7
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

The deadline was last week for new individual submissions, but if useful =

we could just issue it when it's done anyway.

The question is whether the WG has interest... otherwise, we could wait=20
until after the IETF ;-)

Joe

S=E9rgio Freire wrote:
> Hi Joe et all,
> Yes, I think it would be a great idea to write an I-D concerning the us=
e of TCP options in the payload.. what is the deadline?
> Sergio
>=20
>=20
> -----Original Message-----
> From: Joe Touch [mailto:touch@ISI.EDU]=20
> Sent: segunda-feira, 14 de Julho de 2008 16:20
> To: Joe Touch
> Cc: andre.zuquete@ua.pt; tcpm@ietf.org; S=E9rgio Freire
> Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs?
>=20
> PS - if there's interest in this, we could pull together an I-D in time=
 for Dublin, but it won't (didn't) make the individual deadline...
>=20
> Joe
>=20
> Joe Touch wrote:
>> Adam Langley wrote:
>>> On Mon, Jul 14, 2008 at 5:14 AM, Michael Scharf=20
>>> <michael.scharf@ikr.uni-stuttgart.de> wrote:
>>>> Even though RFC 793 explicitly allows payload in SYN segments, there=
=20
>>>> are TCP stacks that just seem to ignore it. Couldn't this offer an=20
>>>> opportunity to transport long TCP options in the payload of SYN=20
>>>> segments, instead of expanding the header option space?
>> See Usenix 2008, "A TCP-layer Name Service for TCP Ports"
>> http://www.usenix.org/events/usenix08/tech/full_papers/freire/freire_h=

>> tml/index.html
>>
>>
>> The authors, Sergio and Andre (cc'd), therein combine options in the=20
>> SYN payload with other mechanisms in a port-names solution. I have=20
>> spoken with them about cleanly separating the idea of data as payload =

>> option space (i.e., removing other features that are distinct, e.g.,=20
>> use of port 0, changing ports after the SYN, etc.), and basically we c=
ame up with:
>>
>>     set a conventional option that says where the
>>     payload option ends, within the SYN segment
>>     (typically the end of that segment)
>>
>>     wait for an ACK indicating that option is set
>>     (could be set in advance), indicating the
>>     options will be processed correctly
>>         NB - the option is set in advance when
>>         a sender speaks the option but has no
>>         long options to send, or has long options
>>         to send and is doing so. EITHER WAY
>>         the option MUST occur, or the handshake
>>         will fail.
>>
>>     if the ACK does not confirm the ability to
>>     process options in the data, then RST the
>>     connection and retry without data options
>>
>> Note that this works only for the SYN segment, and it isn't clear how =

>> it might interoperate with SYN cookies. It also ALWAYS consumes option=
=20
>> space, and MUST occur in the existing options.
>>
>> ...
>>> And that suggests that it's not just those OSes which ignore SYNs=20
>>> with payloads - it's also those which reject the packet completely.
>> AFAICT, ACKing the SYN and not the data is compliant, but rejecting=20
>> the SYN entirely doesn't appear to be - it should be called a bug, IMO=
=2E
>>
>> Joe
>>
>=20


--------------enig1B2523492885B0E0ECE2DFB7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIe9eRE5f5cImnZrsRAr6AAKDKGD5JMeyzK5eOzCyJ1GV0mWwEvQCeOsmd
eqcVhUnTn9Wx2YCiQiwBCbA=
=/Ll4
-----END PGP SIGNATURE-----

--------------enig1B2523492885B0E0ECE2DFB7--

--===============0366703310==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--===============0366703310==--