Re: [tcpinc] AD review of tcp-eno

Joe Touch <> Thu, 27 July 2017 15:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12471131CC7; Thu, 27 Jul 2017 08:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NjYTR_-cs5JN; Thu, 27 Jul 2017 08:50:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EBA3812EC4B; Thu, 27 Jul 2017 08:50:55 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v6RFoDQU008087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Jul 2017 08:50:23 -0700 (PDT)
From: Joe Touch <>
To: "Mirja Kuehlewind (IETF)" <>
Cc:, tcpinc <>
References: <> <> <> <> <>
Message-ID: <>
Date: Thu, 27 Jul 2017 08:50:12 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [tcpinc] AD review of tcp-eno
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: Thu, 27 Jul 2017 15:50:57 -0000


On 7/27/2017 8:40 AM, Joe Touch wrote:
> ...
>>>>> 2) I’m wondering if it would make sense to specify at the beginning of section 4.7 another requirement that TEPs SHOULD only specify the use of SYN data if there is some a-priori knowledge that the other end is likely to support tcp-eno and the tep (e.g. due to previous successful connections aka session resumption, or application knowledge).
>>> That section does not appear to address the case where non-user data in
>>> the SYN is received by a legacy receiver, either because of first
>>> contact or in contacting a host that has changed configuration since
>>> last contact. In such cases, there is no way to support transparent
>>> fallback as required by RFC 1122 -- which is why it is avoided at all
>>> costs. AFAICT, this optimization is too hazardous to include at all.
>> It does. The initiator must reset the connection in this case.
> I would assume then that NO TCP connection is possible to that endpoint
> - i.e., by aborting the connection, you're saying that this endpoint is
> not reachable because it's "ENO or nothing".
> If so, that needs to be made very clear - especially that it is not
> appropriate for the TCP layer to try another connection without ENO
> (i.e., transparent fallback NEVER involves multiple connection attempts
> - otherwise you're violating RFC1122).

The text does address this case, but still a bit too vague IMO. I'd
appreciate an explicit statement highlighting interaction with legacy
receivers, including a note that even a previously-visited ENO node
might be legacy upon next contact, and stating that the connection abort
MUST NOT include an automatic subsequent attempt at fallback, e.g.,
because BOTH this violates the nature of ENO (once the client wants ENO,
it's ENO-or-nothing) *and* because automatic fallback would violate TCP