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

Joe Touch <touch@isi.edu> Fri, 29 July 2016 18:48 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 8DDE112D5FB for <tcpinc@ietfa.amsl.com>; Fri, 29 Jul 2016 11:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.187
X-Spam-Level:
X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 E7VwRwqeuP1P for <tcpinc@ietfa.amsl.com>; Fri, 29 Jul 2016 11:47:59 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 6565812D59A for <tcpinc@ietf.org>; Fri, 29 Jul 2016 11:47:59 -0700 (PDT)
Received: from [128.9.184.41] ([128.9.184.41]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u6TIlZ3u028504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 Jul 2016 11:47:36 -0700 (PDT)
To: David Mazieres expires 2016-10-26 PDT <mazieres-8yg7xbik8ffzygp85yi93qcefe@temporary-address.scs.stanford.edu>, Kyle Rose <krose@krose.org>
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> <579A8223.8050308@isi.edu> <CAJU8_nXSxr7ykC1TwptBmyP8pNccz52ozq=hF7-EYiaMdDeLBQ@mail.gmail.com> <8737mtqkf5.fsf@ta.scs.stanford.edu>
From: Joe Touch <touch@isi.edu>
Message-ID: <579BA4C5.2040004@isi.edu>
Date: Fri, 29 Jul 2016 11:47:33 -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: <8737mtqkf5.fsf@ta.scs.stanford.edu>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/qGFCl77ORryD7fHvag24s0-7ICE>
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: Fri, 29 Jul 2016 18:48:01 -0000

FWIW, IMO the best wording would:

- start with the simplest case, i.e., NOT trying to optimize EDO to use
SYN data

- present the use of SYN data with EDO as an optimization
        that optimization might be a MAY or SHOULD, but not a MUST

Otherwise, you're needlessly complicating your spec for an optimization.

Joe

On 7/28/2016 6:53 PM, David Mazieres expires 2016-10-26 PDT wrote:
> How about the following wording?
>
>    A SYN segment containing an ENO option MUST NOT include a TCP Fast
>    Open (TFO) option [RFC7413].  However, TEPs MAY specify the use of
>    data in SYN segments to achieve similar benefits to TFO.
>
>    The last TEP identifier suboption in host A's SYN segment is the _SYN
>    TEP_.  The SYN TEP governs the use of data in A's SYN segment.  If
>    the SYN TEP's specification does not define the use of such data,
>    then host A's SYN segment MUST NOT contain data and host B MUST
>    discard any such data.  Host B must also discard data in A's SYN
>    segment if either the SYN TEP differs from the negotiated TEP or host
>    B disables encryption.
>
>    The use of data in B's SYN-ACK segment is governed by the negotiated
>    TEP.  If the negotiated TEP's specification does not define the use
>    of such data, then host B's SYN-ACK segment MUST NOT contain data and
>    host A MUST discard any such data.  Host A MUST also discard any
>    received SYN data if it disables encryption.
>
>    When a host discards SYN data, it MUST NOT acknowledge the sequence
>    number of the discarded data.  Rather, it MUST acknowledge the other
>    host's initial sequence number as if the received SYN segment
>    contained no data.
>
>    Regardless of the SYN TEP and negotiated TEP, host A MUST NOT include
>    data in a SYN-only segment when in mandatory application-aware mode.
>    Moreover, in the event that host B is an active opener (because of
>    simultaneous open), host B's SYN-only segment MUST NOT include data.
>
>    Using data in SYN segments deviates from TCP semantics and can cause
>    problems with middleboxes or non-compliant TCP hosts.  Hence, all
>    TEPs SHOULD support a normal mode of operation that does not make use
>    of data in SYN segments.  Moreover, implementations SHOULD employ SYN
>    data only if explicitly requested by the application or in cases
>    where such use is highly unlikely to pose problems.
>
> David