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

Joe Touch <touch@ISI.EDU> Mon, 14 July 2008 21:57 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 43DD828C243; Mon, 14 Jul 2008 14:57:59 -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 430BB28C243 for <tcpm@core3.amsl.com>; Mon, 14 Jul 2008 14:57:58 -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=[AWL=0.000, 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 2GgXG4vhWxvP for <tcpm@core3.amsl.com>; Mon, 14 Jul 2008 14:57:57 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 75AF828C147 for <tcpm@ietf.org>; Mon, 14 Jul 2008 14:57:57 -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 m6ELvX9w016938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 14:57:39 -0700 (PDT)
Message-ID: <487BCBCD.7030103@isi.edu>
Date: Mon, 14 Jul 2008 14:57:33 -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> <487BBF1C.7000101@isi.edu>
In-Reply-To: <487BBF1C.7000101@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="===============1425733043=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org


Joe Touch wrote:
> Hi, all,
...
> AFAICT, SYN cookies are incompatible with long options, and yes, 
> rejecting them is the appropriate response if cookies are required for 
> all connections.

PS - one conclusion that we could draw here is that:

- we can show that there are NO versions of extending TCP options that 
are truly backward compatible
	i.e., that use a single SYN

- we can also show that there are NO versions of extending TCP options 
that are compatible with SYN cookies
	as long as the ISN is the same length, there's only so much
	place for state

Overall, that may imply that we cannot extend the TCP option space in a 
backward compatible way, at which point maybe we're back to Mark 
Allman's "let's double all the fields" proposal, i.e., a 'clean slate' 
TCPv2...

Joe

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