Re: [tcpinc] AD review of draft-ietf-tcpinc-tcpcrypt

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Sat, 30 September 2017 17:18 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 C395F133226; Sat, 30 Sep 2017 10:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.627
X-Spam-Level:
X-Spam-Status: No, score=0.627 tagged_above=-999 required=5 tests=[HK_RANDOM_ENVFROM=0.626, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 WeblwqJnHYO0; Sat, 30 Sep 2017 10:18:28 -0700 (PDT)
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 194AC126B6D; Sat, 30 Sep 2017 10:18:28 -0700 (PDT)
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 v8UHIRuM019092; Sat, 30 Sep 2017 10:18:27 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v8UHIRbE005290; Sat, 30 Sep 2017 10:18:27 -0700 (PDT)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: "Mirja Kuehlewind \(IETF\)" <ietf@kuehlewind.net>, Daniel B Giffin <dbg@scs.stanford.edu>
Cc: draft-ietf-tcpinc-tcpcrypt.all@ietf.org, tcpinc <tcpinc@ietf.org>
In-Reply-To: <D78092B0-4C01-47D6-9B5D-9DB1DA5EFA83@kuehlewind.net>
References: <D38E22E9-FBB6-40D1-BF85-D5A77F5C2365@kuehlewind.net> <20170830223758.GA73969@scs.stanford.edu> <3a8ac0e0-cd41-57c8-85a4-79c5f179385f@kuehlewind.net> <20170929203434.GA73214@scs.stanford.edu> <D78092B0-4C01-47D6-9B5D-9DB1DA5EFA83@kuehlewind.net>
Reply-To: David Mazieres expires 2017-12-29 PST <mazieres-b6y844gfkp899wcr7iwrxxztue@temporary-address.scs.stanford.edu>
Date: Sat, 30 Sep 2017 10:18:27 -0700
Message-ID: <877ewgrtp8.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/89MsQhIKVEQFXr1cdANIR-fmLAg>
Subject: Re: [tcpinc] AD review of draft-ietf-tcpinc-tcpcrypt
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Sat, 30 Sep 2017 17:18:29 -0000

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> writes:

> Yes, it’s better. It doesn't redefines what to do with the FIN, so
> that’s good. For the first sentence it now sounds like this is
> independent of the FIN in the regular TCP. Is there a reason why you
> don’t want to go for a phrasing as I proposed where you say something
> like if TCP would set the FIN (as defined in RFC793) you also have to
> set the FINp?

Daniel and I discussed this, and our feeling is that even though FIN and
FINp have similar names and a related purpose (it's fair to say the FINp
bit protects the TCP FIN bit), it was actually more confusing to try to
explain their roles together.  In particular, the end of a TCP
connection could involve a TCP segment containing multiple tcpcrypt
frames, or a tcpcrypt encryption frame that spans multiple TCP segments.
So one could go down some complicated bifurcating analysis of what to do
in all cases, or just say set FINp on the last frame which seemed both
intuitive and correct.

We could add one sentence about what TCP does with FIN to say something
like the following:

        A sender MUST set the `FINp` bit on the last frame it sends in
        the connection (unless it aborts the connection), and MUST NOT
        set `FINp` on any other frame.

        TCP sets the `FIN` flag when a sender has no more data, which
        with tcpcrypt means setting `FIN` on the segment containing the
        last byte of the last frame.  However, a receiver MUST report
        the end-of-file condition to the connection's local user when
        and only when it receives a frame with the `FINp` bit set.  If a
        host receives a segment with the TCP FIN flag set but the
        received datastream including this segment does not contain a
        frame with `FINp` set, the host SHOULD abort the connection and
        raise an error condition distinct from the end-of-file
        condition; if there are unacknowledged segments whose
        retransmission could potentially result in a valid frame, the
        host MAY instead drop the segment with the TCP FIN flag set.

This is maybe a bit pedantic/redundant, but potentially clearer.  Do you
prefer this proposed language?

David