Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)

Eric Rescorla <> Mon, 13 November 2017 08:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CC2B1294F5 for <>; Mon, 13 Nov 2017 00:28:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cbEUv4O2hR-j for <>; Mon, 13 Nov 2017 00:28:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8ED771294E6 for <>; Mon, 13 Nov 2017 00:28:48 -0800 (PST)
Received: by with SMTP id g204so1122847ywa.6 for <>; Mon, 13 Nov 2017 00:28:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+3whxdfPOjizHrZ5li2Rj5pQ9fiml9GCuDfEmoajSXs=; b=A1nRVD7lLlJfbBdRq7Qk1i7jXG3uvjbgctVukzkaKN1I20NAV6/MRVFpnwHtjGpJCM X1G9YMIWvv1kFuq5G9JofU0y61geGea+io651ng8GFmfh6erHD6x1EMnUJlySgWDWuxR DVYiGif/6uMMzJUauZ1BCXITIy7t+RI77VBAWjEvmdgY6v29WVF9H2wj73O+E3T76qgv I777w3DxBLIfHBXH8O7XcncGnZTq9EkvcWXHILmDki/NynRaPNstvEXjVynxWcm8bbRp 8L1aO/i2nF8X2U5WnvGSlXw9/qjMQA0Pcll9w9Gu/7UwVpE7wuDWcL8lheHIVMgF/Ch3 lKcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+3whxdfPOjizHrZ5li2Rj5pQ9fiml9GCuDfEmoajSXs=; b=RKtVY3utxRBDJ51iqk0qlv1R8aCJFeW7wHtLueSopGtMKoQD9lu2XcLAxuFK5yBcXp eKjnJHPCwyK5E7WiK9dMPmPDheps0Z/dEuvf4uu7eNbYdvprLufUlx+h8PkbtKaUsyUS B0uKIPUq1ivM2C19PuVMcuOPRNpXLpDYPjUqnFzP6fTvbtrhbNIwx+ZEQdhZ1bQsO9Gj LJCbQjmaESDSKbmsPSO7StifsQfld7Fa4HEFt/6TsGgoTisTtJSTHifmVg3BYT1VqujQ xOprWasE/+SeUENmB9/V7W7mf5uOvVPjn2iAa539+3r23Y2YSc5Wuapoeh9JBx9wbqmg MznA==
X-Gm-Message-State: AJaThX77of7GgP02AjRNYrInVLdBX7XaOSA/uvkRvvdCnqs5p+vnfkmk cR2HK+lpp5pOVQ3Fm51reJpkaDxe6ShP6UTUOoDv0Q==
X-Google-Smtp-Source: AGs4zMbYoJQyy4z4l2y2DifmvzRMexnBWv+SBFqMLFOPyRfNRJkJi5/HDRosbRYZtKkcyJcutRUt/N7JF4/nnBwQ3+E=
X-Received: by with SMTP id n10mr5194594ywc.327.1510561727839; Mon, 13 Nov 2017 00:28:47 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 13 Nov 2017 00:28:07 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 13 Nov 2017 08:28:07 +0000
Message-ID: <>
To: David Mazieres <>
Cc: The IESG <>, tcpinc <>, "Black, David" <>,,
Content-Type: multipart/alternative; boundary="001a1147389433144c055dd90f11"
Archived-At: <>
Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Nov 2017 08:28:50 -0000

This seems fine to me.

On Mon, Nov 13, 2017 at 6:35 AM, David Mazieres <> wrote:

> David Mazieres expires 2018-02-10 PST
> <> writes:
> >> The problem is that "govern" is not very clear. It's clearer to link the
> >> requirement
> >> here to the specific feature of the packet.
> >
> > Okay, let me futz with the language a bit and try to get rid of or
> > clearly define the term govern.
> Okay, how about the following?
> Thanks,
> David
> 4.7.  Data in SYN Segments
>    TEPs MAY specify the use of data in SYN segments so as to reduce the
>    number of round trips required for connection setup.  The meaning of
>    data in a SYN segment with an ENO option (a SYN+ENO segment) is
>    determined by the last TEP identifier in the ENO option, which we
>    term the segment's _SYN TEP_.  A SYN+ENO segment may of course
>    include multiple TEP suboptionss, but only the SYN TEP (i.e., the
>    last one) specifies how to interpret the SYN segment's data payload.
>    A host sending a SYN+ENO segment MUST NOT include data in the segment
>    unless the SYN TEP's specification defines the use of such data.
>    Furthermore, to avoid conflicting interpretations of SYN data, a
>    SYN+ENO segment MUST NOT include a non-empty TCP Fast Open (TFO)
>    option [RFC7413].
>    Because a host can send SYN data before knowing which if any TEP the
>    connection will negotiate, hosts implementing ENO are REQUIRED to
>    discard data from SYN+ENO segments when the SYN TEP does not become
>    the negotiated TEP.  Hosts are furthermore REQUIRED to discard SYN
>    data in cases where another Internet standard specifies a conflicting
>    interpretation of SYN data (as would occur when receiving a non-empty
>    TFO option).  This requirement applies to hosts that implement ENO
>    even when ENO has been disabled by configuration.  However, note that
>    discarding SYN data is already common practice [RFC4987] and the new
>    requirement applies only to segments containing ENO options.
>    More specifically, a host that implements ENO MUST discard the data
>    in a received SYN+ENO segment if any of the following applies:
>    o  ENO fails and TEP-indicated encryption is disabled for the
>       connection,
>    o  The received segment's SYN TEP is not the negotiated TEP,
>    o  The negotiated TEP does not define the use of SYN data, or
>    o  The SYN segment contains a non-empty TFO option or any other TCP
>       option implying a conflicting definition of SYN data.
>    A host discarding SYN data in compliance with the above requirement
>    MUST NOT acknowledge the sequence number of the discarded data, but
>    rather MUST acknowledge the other host's initial sequence number as
>    if the received SYN segment contained no data.  Furthermore, after
>    discarding SYN data, such a host MUST NOT assume the SYN data will be
>    identically retransmitted, and MUST process data only from non-SYN
>    segments.
>    If a host sends a SYN+ENO segment with data and receives
>    acknowledgment for the data, but the SYN TEP in its transmitted SYN
>    segment is not the negotiated TEP (either because a different TEP was
>    negotiated or because ENO failed to negotiate encryption), then the
>    host MUST abort the TCP connection.  Proceeding in any other fashion
>    risks misinterpreted SYN data.
>    If a host sends a SYN-only SYN+ENO segment bearing data and
>    subsequently receives a SYN-ACK segment without an ENO option, that
>    host MUST abort the connection even if the SYN-ACK segment does not
>    acknowledge the SYN data.  The issue is that unacknowledged data may
>    nonetheless have been cached by the receiver; later retransmissions
>    intended to supersede this unacknowledged data could fail to do so if
>    the receiver gives precedence to the cached original data.
>    Implementations MAY provide an API call for a non-default mode in
>    which unacknowledged SYN data does not cause a connection abort, but
>    applications MUST use this mode only when a higher-layer integrity
>    check would anyway terminate a garbled connection.
>    To avoid unexpected connection aborts, ENO implementations MUST
>    disable the use of data in SYN-only segments by default.  Such data
>    MAY be enabled by an API command.  In particular, implementations MAY
>    provide a per-connection mandatory encryption mode that automatically
>    aborts a connection if ENO fails, and MAY enable SYN data in this
>    mode.
>    To satisfy the requirement of the previous paragraph, all TEPs SHOULD
>    support a normal mode of operation that avoids data in SYN-only
>    segments.  An exception is TEPs intended to be disabled by default.