[tcpinc] New draft of TCP-ENO

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Fri, 20 January 2017 20:05 UTC

Return-Path: <dm-list-tcpcrypt@scs.stanford.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 B42E41293E1 for <tcpinc@ietfa.amsl.com>; Fri, 20 Jan 2017 12:05:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] 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 DP5HgCPec6ZM for <tcpinc@ietfa.amsl.com>; Fri, 20 Jan 2017 12:05:56 -0800 (PST)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC42127735 for <tcpinc@ietf.org>; Fri, 20 Jan 2017 12:05:56 -0800 (PST)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v0KK5u2o087163 for <tcpinc@ietf.org>; Fri, 20 Jan 2017 12:05:56 -0800 (PST)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v0KK5ua4080733; Fri, 20 Jan 2017 12:05:56 -0800 (PST)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: tcpinc <tcpinc@ietf.org>
In-Reply-To: <20170120041448.GA1063@scs.stanford.edu>
References: <20170120041448.GA1063@scs.stanford.edu>
Date: Fri, 20 Jan 2017 12:05:56 -0800
Message-ID: <87mvelo5sr.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/frqYipXTh0_hYQSKjOrxACo_5SM>
Subject: [tcpinc] New draft of TCP-ENO
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: David Mazieres expires 2017-04-20 PDT <mazieres-v7b3262yqn33jbixwzk9qme55w@temporary-address.scs.stanford.edu>
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <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, 20 Jan 2017 20:05:57 -0000

There is a new draft of TCP-ENO, here:

        https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/

There are very few changes from the previous draft, and most of them are
just cosmetic improvements or clarifications.  At the last meeting,
there was some discussion about whether the draft should allow a host to
send an ENO option with zero suboptions.  Upon further reflection, it
appeared there was really nothing in the existing draft that would
prevent such usage.  Hence, the only action we took on this question was
to clarify the situation by adding the following paragraph to the end of
section 4.6:

        A host MAY send a _vacuous_ SYN-form ENO option containing zero
        TEP identifier suboptions.  If either host sends a vacuous ENO
        option, it follows that there are no valid TEP identifiers for
        the connection and hence the connection must fall back to
        unencrypted TCP.  Hosts MAY send vacuous ENO options to indicate
        that ENO is supported but unavailable by configuration, or to
        probe network paths for robustness to ENO options.  However, a
        passive opener MUST NOT send a vacuous ENO option in a SYN-ACK
        segment unless there was an ENO option in the SYN segment it
        received.  Moreover, a passive opener's SYN-form ENO option MUST
        still include a global suboption with "b = 1", as discussed in
        Section 4.3.

David