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

Joe Touch <touch@ISI.EDU> Tue, 15 July 2008 00:35 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 18FDF3A694D; Mon, 14 Jul 2008 17:35:00 -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 170953A68EC for <tcpm@core3.amsl.com>; Mon, 14 Jul 2008 17:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.481
X-Spam-Level:
X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 imGnhBm6wgIt for <tcpm@core3.amsl.com>; Mon, 14 Jul 2008 17:34:56 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A1C503A6845 for <tcpm@ietf.org>; Mon, 14 Jul 2008 17:34:56 -0700 (PDT)
Received: from [127.0.0.1] (pool-71-106-110-19.lsanca.dsl-w.verizon.net [71.106.110.19]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6F0ZBjR028421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 17:35:13 -0700 (PDT)
Message-ID: <487BF0BE.1020605@isi.edu>
Date: Mon, 14 Jul 2008 17:35:10 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Adam Langley <agl@imperialviolet.org>
References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <78C9135A3D2ECE4B8162EBDCE82CAD7703E66F37@nekter> <487BAFCF.3020402@isi.edu> <487BBF1C.7000101@isi.edu> <487BCBCD.7030103@isi.edu> <396556a20807141642g4cb384e8v1a9065996908d30a@mail.gmail.com>
In-Reply-To: <396556a20807141642g4cb384e8v1a9065996908d30a@mail.gmail.com>
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="===============0974671938=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org


Adam Langley wrote:
...
> Extensions which involve SYN options thus need to cope with the case
> where they are ignored by a host under attack. (I've a draft, that
> I'll probably post tomorrow, that does exactly that.)

I don't think that's tenable. SYNs are where the presence of all 
capabilities are negotiated. TCP has no semantics for turning 
capabilities on after a connection is negotiated.

If you ignore options in the SYN, you're saying "I can't do that 
capability for the entirety of this connection". For options that are 
optional (i.e., that are disabled if not ACKd), that works fine, but 
then disables the feature for the rest of the connection.

For options that initiators want to require (e.g., TCP-AO, for one), if 
you ignore the option in the SYN-ACK, or forget that it was negotiated, 
the option will not work and the connection will be dropped.

That says you've hit a case where SYN cookies don't support TCP, not 
where your options aren't supported by SYN cookies, IMO.

Joe

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