IETF Logo Mail Archive

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

Joe Touch <touch@ISI.EDU> Mon, 14 July 2008 21:03 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5A7D28C1FF; Mon, 14 Jul 2008 14:03:52 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5A473A6B0C for <tcpm@core3.amsl.com>; Mon, 14 Jul 2008 14:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIrov2PB0kC4 for <tcpm@core3.amsl.com>; Mon, 14 Jul 2008 14:03:51 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id EC4743A6C78 for <tcpm@ietf.org>; Mon, 14 Jul 2008 14:03:42 -0700 (PDT)
Received: from [127.0.0.1] (228.sub-75-214-74.myvzw.com [75.214.74.228]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6EL3Pxi002196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 14:03:29 -0700 (PDT)
Message-ID: <487BBF1C.7000101@isi.edu>
Date: Mon, 14 Jul 2008 14:03:24 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <78C9135A3D2ECE4B8162EBDCE82CAD7703E66F37@nekter> <487BAFCF.3020402@isi.edu>
In-Reply-To: <487BAFCF.3020402@isi.edu>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, Caitlin Bestler <Caitlin.Bestler@neterion.com>
Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0722515407=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Hi, all,

Sorry if my response below was cryptic. Let me clarify...

Joe Touch wrote:
> 
> 
> Caitlin Bestler wrote:
> ...
>> Any stack that uses SYN Cookies, or wants the option to, will reject
>> any SYN that has payload.
> 
> Why couldn't it ACK the SYN but not the data, and compute the cookie 
> based on the header only (as with an 'empty' SYN?)

Note that this is a valid response only where the data is NOT 
interpreted as extended option space.

AFAICT, SYN cookies are incompatible with long options, and yes, 
rejecting them is the appropriate response if cookies are required for 
all connections.

Joe


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

v2.14.0 | Report a Bug | By Email