Re: [tcpm] TCP Long Options - Why not as payload in SYNs?

"Caitlin Bestler" <> Mon, 14 July 2008 19:45 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 5936B3A6BF4; Mon, 14 Jul 2008 12:45:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 339143A6B06 for <>; Mon, 14 Jul 2008 12:45:09 -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 eKlJAEXvxaJH for <>; Mon, 14 Jul 2008 12:45:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2F4EF3A67A4 for <>; Mon, 14 Jul 2008 12:45:00 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 14 Jul 2008 15:45:27 -0400
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703E66F37@nekter>
In-Reply-To: <>
Thread-Topic: [tcpm] TCP Long Options - Why not as payload in SYNs?
Thread-Index: AcjlqzMv4BdTSCxPTgm4HBfpZCNwWgAPpYIg
References: <>
From: Caitlin Bestler <>
To: Michael Scharf <>,
Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs?
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

> -----Original Message-----
> From: [] On Behalf
> Michael Scharf
> Sent: Monday, July 14, 2008 5:14 AM
> To:
> Subject: [tcpm] TCP Long Options - Why not as payload in SYNs?
> Hi all,
> I wonder whether "modern" TCP stacks indeed process application
> payload data in SYN segments.
> Even though RFC 793 explicitly allows payload in SYN segments, there
> are TCP stacks that just seem to ignore it. Couldn't this offer an
> opportunity to transport long TCP options in the payload of SYN
> segments, instead of expanding the header option space?
> Sorry if this question has already been answered elsewhere.
> Michael

Any stack that uses SYN Cookies, or wants the option to, will reject
any SYN that has payload.

If a stack were to decide to accept SYNs with Payload as part of an
optional enhancement then it would need a new method of defending from
SYN floods. Generally, any stack that obligates itself to retain state
in its memory on the basis of a single received SYN is a sitting duck
for a Denial of Service attack.

tcpm mailing list