Re: [tcpinc] Benoit Claise's No Objection on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)

Daniel B Giffin <dbg@scs.stanford.edu> Fri, 17 November 2017 06:31 UTC

Return-Path: <dbg@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 185241200E5 for <tcpinc@ietfa.amsl.com>; Thu, 16 Nov 2017 22:31:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable 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 UWSVt3ABZqU9 for <tcpinc@ietfa.amsl.com>; Thu, 16 Nov 2017 22:31:58 -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 30B7C1200C1 for <tcpinc@ietf.org>; Thu, 16 Nov 2017 22:31:58 -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 vAH6VpLW020744; Thu, 16 Nov 2017 22:31:51 -0800 (PST)
Received: (from dbg@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id vAH6VoNt099954; Thu, 16 Nov 2017 22:31:50 -0800 (PST)
Date: Thu, 16 Nov 2017 22:31:50 -0800
From: Daniel B Giffin <dbg@scs.stanford.edu>
To: Benoit Claise <bclaise@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tcpinc-tcpcrypt@ietf.org, Kyle Rose <krose@krose.org>, tcpinc-chairs@ietf.org, tcpinc@ietf.org, wangzitao@huawei.com
Message-ID: <20171117063150.GD11150@scs.stanford.edu>
References: <151030381876.29951.5493226784893679063.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <151030381876.29951.5493226784893679063.idtracker@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/QnFV2b2HJDsYAs8BxlsGU_0e4EM>
Subject: Re: [tcpinc] Benoit Claise's No Objection on draft-ietf-tcpinc-tcpcrypt-09: (with COMMENT)
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: Fri, 17 Nov 2017 06:31:59 -0000

Benoit Claise wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Nothing against the publication of this document but ... as for any
> experimental RFCs, we must describe the criteria for a successful experiment
> (evaluation)?

Oh right!

I've added this section:

	9.  Experiments

   Some experience will be required to determine whether the tcpcrypt
   protocol can be deployed safely and successfully across the diverse
   environments of the global internet.

   Safety means that TCP implementations that support tcpcrypt are able
   to communicate reliably in all the same settings as they would
   without tcpcrypt.  As described in [I-D.ietf-tcpinc-tcpeno]
   Section 9, this property can be subverted if middleboxes strip ENO
   options from non-SYN segments after allowing them in SYN segments; or
   if the particular communication patterns of tcpcrypt offend the
   policies of middleboxes doing deep-packet-inspection.

   Success, in addition to safety, means that hosts which implement
   tcpcrypt actually enable encryption when they connect to each other.
   This property depends on the network's treatment of the TCP-ENO
   handshake, and can be subverted if middleboxes merely strip unknown
   TCP options or if they terminate TCP connections and relay data back
   and forth unencrypted.

   Ease of implementation will be a further challenge to deployment.
   Because tcpcrypt requires encryption operations on frames that may
   span TCP segments, kernel implementations are forced to buffer
   segments in different ways than are necessary for plain TCP.  More
   implementation experience will show how much additional code
   complexity is required in various operating systems, and what kind of
   performance effects can be expected.