IETF Logo Mail Archive

Re: [tcpinc] TCP's treatment of data in SYN packets

Joe Touch <touch@isi.edu> Thu, 28 July 2016 22:07 UTC

Return-Path: <touch@isi.edu>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA45012D5CD for <tcpinc@ietfa.amsl.com>; Thu, 28 Jul 2016 15:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTmLGL2OonMi for <tcpinc@ietfa.amsl.com>; Thu, 28 Jul 2016 15:07:52 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AD312D187 for <tcpinc@ietf.org>; Thu, 28 Jul 2016 15:07:52 -0700 (PDT)
Received: from [128.9.184.214] ([128.9.184.214]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6SM7XME003802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2016 15:07:33 -0700 (PDT)
To: Kyle Rose <krose@krose.org>, David Mazieres expires 2016-10-26 PDT <mazieres-p7v7bih3ykqpkxv5e74y9er6ts@temporary-address.scs.stanford.edu>
References: <CAJU8_nU1WzQNFFUn_2o1cACutB01iyQ_hC29PHoutr8TRDKGnA@mail.gmail.com> <579A4669.7030600@isi.edu> <87lh0lselg.fsf@ta.scs.stanford.edu> <CAJU8_nUPrm9JJMrrMbL5+FpP-9CKC6EkidCry9UuZA5ZfyJtoA@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <579A8223.8050308@isi.edu>
Date: Thu, 28 Jul 2016 15:07:31 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CAJU8_nUPrm9JJMrrMbL5+FpP-9CKC6EkidCry9UuZA5ZfyJtoA@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: u6SM7XME003802
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/SYVeWdwKMg_DdCc_vy99JWC7d-4>
Cc: tcpinc <tcpinc@ietf.org>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Subject: Re: [tcpinc] TCP's treatment of data in SYN packets
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion list for adding encryption to TCP." <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2016 22:07:53 -0000


On 7/28/2016 3:01 PM, Kyle Rose wrote:
> I still don't have a good feel for what folks like Joe are
> recommending re: dealing with a B that doesn't understand ENO. If B is
> suddenly not ENO-aware, 
Not suddenly. During the SYN exchange.

Or are you not dealing with legacy endpoints that don't speak ENO? The
goal there is to fail gracefully - either fail to support ENO and
proceed, kill the connection, etc. But you should never start delivering
data to the application by accident - that's something you can't roll back.

BTW, you DO need to deal with an endpoint that spoke ENO before but does
not now (for two different connections). That could happen because of an
OS revision or because the connection configured differently anyway.

Joe

v2.37.1 | Report a Bug | By Email | System Status